Коллеги, друзья!

Хотелось бы в качестве мозгового штурма поработать в концептуальной моделью штатного расписания.

Причина такова. У нас в организации есть два несовместных продукта - одно решение для кадров (ОК) и другое для планово-финансового отдела (ПФО) для работы со штатным расписанием.

Исторически так получилось, что ПФО заказал себе разработку гораздо раньше отдела кадров. Внедрил ее и начал использовать. Но проблемы проявились мгновенно. Для ведения штатного расписания (ШР) потребовались и актуальные данные по отделу кадров. В результате в отделе ПФО получали приказы из ОК и вводили их (в самом общем виде по сути регистрировали) в своей системе. Это нужно было для формирования массы отчетов по факту, по среднесписочной численности и т.п.

Позже в ОК внедрили иную систему, поскольку то решение, которое было в ПФО совершенно не годилось и требовало значительной доработки. К тому же изучение этой конфигурации показало, что она разрабатывалась совершенно бездарно в угоду сиюминутной задаче.

После внедрение ОК проявились и неудобства отделения ОК от ведение ШР. На самом деле в системе, внедренной в ОК, штатное расписание есть и в целом оно организовано не плохо, но отличается от потребностей ПФО.

Решено адаптировать работу со ШР в системе, внедренной в ОК.

Определенная сложность заключается в том, что  организация перешла на так называемые профессиональные квалификационные группы и уровни. В системе ПФо как я уже говорил тот еще бардак, по сути все реализовано примерно так:
есть набор оторванных друг от друга справочников
 - справочник должностей
 - справочник подразделений
 - справочник видов персонала
 - справочник персонала зачем-то
 - справочник квалификаций - т.е. иерархический справочник профессиональных квалификационных групп и профессиональных квалификационных уровней
Штатное расписание имеет примерно такую структуру
(Подразделение, Должность, Персонал, Квалификационная группа, Квалификационный уровень, Кол.ставок, Список надбавок, Оклад)

Я пытаюсь придумать более качественную модель с учетом реализации для системы ОК, ниже представлена она.

Предлагаю высказаться

Для начала неплохо было бы расшифровать аббревиатуры на Д.

З.Ы. А что это за подчеркивания красным в примечаниях?

Для начала неплохо было бы расшифровать аббревиатуры на Д.

Расшифрую, просто у меня времени не оставалось, еле успел отправить.
Правда все аббревиатуры есть в тексте ПКГ - профессиональная квалификационная группа, ПКУ профессиональный квалификационный уровень

З.Ы. А что это за подчеркивания красным в примечаниях?

а вот так работает бета версия ЕА 8

Несколько комментариев/вопрос/соображений:

1) "вид персонала" просится стать enumeration
2) кое-где можно подумать про агрегации\композиции
3) Отношения в группе "Должность", "Подразделение", "Сотрудник", "Штатаная единица" скорее всего можно пересмотреть и нарисовать через многополюсную ассоциацию и может еще класс-ассоциацию. Будет понятнее и не потребуются пространные комментарии.

Несколько комментариев/вопрос/соображений:

1) "вид персонала" просится стать enumeration

Перечисление возможно. Правда мы привязываемся к реализации - а там это уже класс.

2) кое-где можно подумать про агрегации\композиции

Да это понятно, но пока это концептуальная модель

3) Отношения в группе "Должность", "Подразделение", "Сотрудник", "Штатаная единица" скорее всего можно пересмотреть и нарисовать через многополюсную ассоциацию и может еще класс-ассоциацию. Будет понятнее и не потребуются пространные комментарии.

Что такое многополюсная ассоциация? N-арная? Думаю это усложнит модель. К тому же их сложно реализовать. Класс-ассоциация тут не подходит. Дело в том, что по мимо наименования должности тут придется учитывать дополнительные идентифицирующие атрибуты, в частности идентификация по ПКГ и ПКУ, иначе придется иметь несколько должностей с одинаковы названием но разными ПКГ и ПКУ, может это будет правильнее?

Пока учитывая реализацию, это не совсем так

Так какая модель-то рисуется? концептуальная или модель реализации?

Так какая модель-то рисуется? концептуальная или модель реализации?

Ну по сути конечно концептуальная,хотя аспекты реализации в голове держаться.

Перечисление на мой взгляд тут не совсем корректно, поскольку у персонала могут быть дополнительные аспекты - тут не указанные.

Пока есть такая проблема:
1. Для штатного расписания нужно поддерживать историю изменения - пока этого явно нет
2. есть проблема правильного учета ПКГ и ПКУ, поясню на примере
   справочник должностей будет иметь код, наименование должности и возможно что-то еще. На мой взгляд должность должна быть уникальным элементом, например
    должности программист 1 кат. программист 2 кат - разные должности
   однако есть должности стеклодув, слесарь-сантехник, но возможна такая ситуация должность (ПКГ/ПКУ): стеклодув 2/3 и стеклодув 2/4
   Таким образом получается что одна и таже должность может иметь разные ПКГ/ПКУ, но в рамках одной профессиональной квалификационной группы! По сути эта самая проф. квал. группа - тип, вид, категория некоего персонала
  У меня получается, что все это следует учитывать только в штатном расписании для конкретной позиции

1. Для штатного расписания нужно поддерживать историю изменения - пока этого явно нет

Эдуард, я бы на твоем месте все-таки отделил предметную область от функциональных требований. Сейчас мы ведь предметную область пытаемся изобразить?

А сохранять историю изменений можно для всего чего хочешь.

Эдуард, я бы на твоем месте все-таки отделил предметную область от функциональных требований. Сейчас мы ведь предметную область пытаемся изобразить?

А сохранять историю изменений можно для всего чего хочешь.

Про историю это так.

Пока есть проблема осмысления всех этих ПКГ, ПКУ, должностей и позиций. Например нам не удалось найти внятных нормативных документов

Например нам не удалось найти внятных нормативных документов

IMHO правильнее все-таки начать с нормальных бизнес-требований применительно к обоим подразделениям. Т.к. описанный ранее бизнес-процесс затрагивающий их обоих (наверняка есть еще и кто-то третий, а то и четвертый).
Вам нужно понять "кто за кем идет", "чьи действия первичны" и т.п. Исходя из этого выстроить информационные потоки, сформировать требования к целевой информационной системе (независимо от того, будет ли это единая система или набор нескольких, пусть даже прежде независимых).
А чтобы не было трений, типа, "чёйта я буду их данные вводить", нужно выпустить приказ руководителя, с такого-то числа обязывающий работать в соответствии с новым распределением обязанностей. Если вдруг кто-то не захочет - решение еще более простое и очевидное...

IMHO правильнее все-таки начать с нормальных бизнес-требований применительно к обоим подразделениям. Т.к. описанный ранее бизнес-процесс затрагивающий их обоих (наверняка есть еще и кто-то третий, а то и четвертый).
Вам нужно понять "кто за кем идет", "чьи действия первичны" и т.п. Исходя из этого выстроить информационные потоки, сформировать требования к целевой информационной системе (независимо от того, будет ли это единая система или набор нескольких, пусть даже прежде независимых).
А чтобы не было трений, типа, "чёйта я буду их данные вводить", нужно выпустить приказ руководителя, с такого-то числа обязывающий работать в соответствии с новым распределением обязанностей. Если вдруг кто-то не захочет - решение еще более простое и очевидное...

Вадим, я уважаю твой системный подход, но в данном случае этого не требуется.

Пока нужно сложить картину обще структуры, модели хранимой информации.

Некоторая возможно полезная информация

Минимальная заработная плата (минимальный размер оплаты труда) - устанавливаемый федеральным законом размер месячной заработной платы за труд неквалифицированного работника, полностью отработавшего норму рабочего времени при выполнении простых работ в нормальных условиях труда. В величину минимального размера оплаты труда не включаются компенсационные, стимулирующие и социальные выплаты.

Оклад (должностной оклад) - фиксированный размер оплаты труда работника за исполнение трудовых (должностных) обязанностей определенной сложности за календарный месяц без учета компенсационных, стимулирующих и социальных выплат.

Базовый оклад (базовый должностной оклад, базовая ставка заработной платы) - минимальные оклад (должностной оклад), ставка заработной платы работника государственного или муниципального учреждения, осуществляющего профессиональную деятельность по профессии рабочего или должности служащего, входящим в соответствующую профессиональную квалификационную группу, без учета компенсационных, стимулирующих и социальных выплат.

Профессиональные квалификационные группы работников – группы профессий рабочих и должностей служащих, сформированные с учетом сферы деятельности на основе требований квалификации (уровню профессионального образования, профессиональной подготовки), необходимой для осуществления соответствующей профессиональной деятельности (далее – профессиональные группы);

Квалификационные уровни профессиональной квалификационной группы работников – профессии рабочих и должности служащих, сгруппированные внутри профессиональной квалификационной группы работников по уровню должностной (профессиональной) компетентности (совокупности знаний, умений, профессиональных навыков, ответственности в принятии решений), необходимой для выполнения работы (далее - квалификационные уровни);

Диапазоны окладов (должностных окладов, ставок заработной платы) по квалификационным уровням профессиональных квалификационных групп работников – минимальные и максимальные размеры окладов (должностных окладов, ставок заработной платы) по квалификационным уровням профессиональных квалификационных групп работников, в пределах которых определяются  размеры окладов (должностных окладов, ставок заработной платы) работников путем применения повышающих коэффициентов к базовым окладам  (базовым должностным окладам), базовым ставкам заработной платы (далее - диапазоны окладов);

Выплаты компенсационного характера – выплаты, обеспечивающие  работникам учреждений, занятым на тяжелых работах, работах с вредными и (или) опасными и иными особыми условиями труда,  в условиях труда, отклоняющихся от нормальных, на работах в местностях с особыми климатическими условиями, оплату труда в повышенном размере, а также иные выплаты, предусматриваемые  утверждаемым Правительством Российской Федерации перечнем выплат компенсационного характера;

Выплаты стимулирующего характера – выплаты, предусматриваемые системами оплаты труда работников учреждений с целью повышения мотивации качественного труда работников и их поощрения за результаты труда, в соответствии с утверждаемым Правительством Российской Федерации перечнем выплат стимулирующего характера;
Выплаты социального характера - осуществляемые за счет средств фонда оплаты труда выплаты работникам, направленные на их социальную поддержку, но не связанные с осуществлением ими трудовых функций;


Еще приложил презентацию. Это для погружения в предметную область.

так что модель за ваших аналитиков нарисовать? а где гарантия, что условия задачи сформулированы ими правильно?
IMHO проще взять давно существующий на рынке продукт. Вопрос, что подойдет для вашего вуза?

P.S. не в обиду, презентация - пустая, кроме перечисления нормативки никакой полезной информации, мессаджа нет, что с этим (ну изменили и изменили) делать дальше неясно. что из перечисленного является прерогативой вуза, а что вышестоящих органов (правительства, минобра, рособразования и т.п.)
про оформление не придираюсь.

так что модель за ваших аналитиков нарисовать? а где гарантия, что условия задачи сформулированы ими правильно?
IMHO проще взять давно существующий на рынке продукт. Вопрос, что подойдет для вашего вуза?

P.S. не в обиду, презентация - пустая, кроме перечисления нормативки никакой полезной информации, мессаджа нет, что с этим (ну изменили и изменили) делать дальше неясно. что из перечисленного является прерогативой вуза, а что вышестоящих органов (правительства, минобра, рособразования и т.п.)
про оформление не придираюсь.

Это не моя презентация, презентация скачанная в инете.

Я не прошу ничего рисовать за меня, я уже нарисовал диаграмму (драфт).
Готовый продукт нам брать не надо, нам следует адаптировать существующий

Тем более готовых продуктов, которые работают с квалификационными группами и уровнями, мне не известны

пардон, тогда мне непонятна роль участников форума в данной ситуации.

насчет технических особенностей существующих продуктов они вряд ли помогут. IMHO в любом случае нужно иметь бизнес-описание того, что должно получиться (в новом варианте) и как потом с этим будут работать сотрудники. при составлении этого (с позволения сказать) описания бизнес-процесса на мой взгляд нужно абстрагироваться от текущих функциональных возможностей имеющегося продукта и в некотором смысле от возможностей его адаптации.
Далее, имея описание бизнес-уровня "переводим" его в описание технического уровня, те же диаграммы сущность-связь и т.п. По возможности это тоже следует изолировать от внутренностей продукта, хотя полностью этого сделать не удастся (да-да, как ни напрягай аналитиков).
А потом тупо (или нетупо) делается мэппинг того что надо, на то что есть. Тем самым формируется проект (как угодно можно называть эскизный или технический) того, что должно быть сделано, чтобы переделать то, что есть в то, что надо (по-нашему, по-бразильски: путь из AS IS в TO BE).
Далее, приоритизация отдельно взятых задач по переделке в целях, например, быстрее выдать в законченном варианте какой-то значимый кусок (= бизнес-процесс). В ходе работы контролировать ситуацию, отклонения, внешние воздействия - в общем всё как обычно, чтобы "довести свой поезд в целости и сохранности до конечной станции".
Обращу внимание на правильную расстановку приоритетов. Это очень важно. Т.к. сейчас существуют определенные проблемы (бизнес-уровня), которые одним махом не решить. Все ваши потребители это в целом понимают, но каждый по-своему. Так вот, нужно выбрать и последовательно реализовать цепочку так называемых квиквинов (quick wins - промежуточных результатов), уверенное и последовательное появление которых будет подтверждать правильность выбранного пути и делом доказывать реализуемость "этого призрачного проекта".
Ну и менеджер проекта нужен хороший, в идеале еще и архитектор не помешал бы.

или что-то другое нужно? типа, диаграмму поправить? IMHO проблема не в диаграмме, а как раз в подходе.

или что-то другое нужно? типа, диаграмму поправить? IMHO проблема не в диаграмме, а как раз в подходе.

Да все так конечно, но пока идет стадия анализа.

Управление ШР само по себе отдельная задача и она будет решена.

Мы исходим из результатной информации, а именно:

Штатное расписание - т.е. отчет содержащий такие данные:
Профессиональную квалификационную группу (вид персонала) как заголовок
Наименование подразделения - как группирующий фактор
Таблица содержащая:
наименование должности, количество штатных единиц, ПКГ/ПКУ (отношение вида 1/1 1/2 1/3 2/4 и т.п.) Должностной оклад, Выплаты (всего 5), Мес фонд оплаты по должн окладу, Мес фонд оплаты с выплатами

Расчетный фонд оплаты
"Наименование вида персонала, фонды оплаты труда"
"Численность персонала (ед.)"
"Сумма по должностным окладам (тарифным ставкам)"
 Выплаты
"Месячный фонд оплаты труда (руб.)"

Пока есть проблема где определять принадлежность к ПКГ и ПКУ - у должности или у штатной единицы, в остальном пока проблем нет, но возможно участники форума могут их высказать по предложенной структуре