Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Galogen от 15 Февраля 2010, 21:02:50
-
Коллеги, друзья!
Хотелось бы в качестве мозгового штурма поработать в концептуальной моделью штатного расписания.
Причина такова. У нас в организации есть два несовместных продукта - одно решение для кадров (ОК) и другое для планово-финансового отдела (ПФО) для работы со штатным расписанием.
Исторически так получилось, что ПФО заказал себе разработку гораздо раньше отдела кадров. Внедрил ее и начал использовать. Но проблемы проявились мгновенно. Для ведения штатного расписания (ШР) потребовались и актуальные данные по отделу кадров. В результате в отделе ПФО получали приказы из ОК и вводили их (в самом общем виде по сути регистрировали) в своей системе. Это нужно было для формирования массы отчетов по факту, по среднесписочной численности и т.п.
Позже в ОК внедрили иную систему, поскольку то решение, которое было в ПФО совершенно не годилось и требовало значительной доработки. К тому же изучение этой конфигурации показало, что она разрабатывалась совершенно бездарно в угоду сиюминутной задаче.
После внедрение ОК проявились и неудобства отделения ОК от ведение ШР. На самом деле в системе, внедренной в ОК, штатное расписание есть и в целом оно организовано не плохо, но отличается от потребностей ПФО.
Решено адаптировать работу со ШР в системе, внедренной в ОК.
Определенная сложность заключается в том, что организация перешла на так называемые профессиональные квалификационные группы и уровни. В системе ПФо как я уже говорил тот еще бардак, по сути все реализовано примерно так:
есть набор оторванных друг от друга справочников
- справочник должностей
- справочник подразделений
- справочник видов персонала
- справочник персонала зачем-то
- справочник квалификаций - т.е. иерархический справочник профессиональных квалификационных групп и профессиональных квалификационных уровней
Штатное расписание имеет примерно такую структуру
(Подразделение, Должность, Персонал, Квалификационная группа, Квалификационный уровень, Кол.ставок, Список надбавок, Оклад)
Я пытаюсь придумать более качественную модель с учетом реализации для системы ОК, ниже представлена она.
Предлагаю высказаться
-
Для начала неплохо было бы расшифровать аббревиатуры на Д.
З.Ы. А что это за подчеркивания красным в примечаниях?
-
Для начала неплохо было бы расшифровать аббревиатуры на Д.
Расшифрую, просто у меня времени не оставалось, еле успел отправить.
Правда все аббревиатуры есть в тексте ПКГ - профессиональная квалификационная группа, ПКУ профессиональный квалификационный уровень
З.Ы. А что это за подчеркивания красным в примечаниях?
а вот так работает бета версия ЕА 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), Мес фонд оплаты по должн окладу, Мес фонд оплаты с выплатами
Расчетный фонд оплаты
"Наименование вида персонала, фонды оплаты труда"
"Численность персонала (ед.)"
"Сумма по должностным окладам (тарифным ставкам)"
Выплаты
"Месячный фонд оплаты труда (руб.)"
Пока есть проблема где определять принадлежность к ПКГ и ПКУ - у должности или у штатной единицы, в остальном пока проблем нет, но возможно участники форума могут их высказать по предложенной структуре
-
ШР - не отчет, а динамическая структура (дерево ну или список, если так проще). можно плодить версии этого дерева, можно распечатывать отчет = результат обхода в определенном (желательно всегда одном, хотя необязательно) порядке
при этом одна из версий всегда соответствует текущему (утвержденному) ШР, а другие либо могут быть предыдущими либо перспективными вариантами. тогда отчет мог бы отвечать на вопрос: какие затраты ФОТ будут при эдаком ШР. Т.е. можно будет использовать ШР для оптимизации затрат (например).
таким образом ШР состоит из "шапки", характеризующей общие параметры, типа даты ввода в действие, и позиций, которые являются оргединицами разных типов - подразделениями или должностями, у каждой могут быть свои особые атрибуты. про подразделения пока говорить не готов, т.к. у вас есть куча особенностей, а для каждой должности нужно иметь возможность задавать конкретного сотрудника, ее занимающего в течение некоторого периода. тогда можно будет вытянуть как историю перемещений сотрудника по различным должностям (даже с учетом совмещений), либо историю занятий должности кем-либо (например, для того, чтобы ответить на вопрос нужна ли вообще эта должность, раз она постоянно вакантна)......
расчеты месячного ФОТ с любыми вариантами - суть те самые отчеты
-
Вадим, спасибо за твой интерес к теме, но ты, как всегда, говоришь много. Что такое штатное расписание я понимаю.
И в данном конкретном случае я представил концептуальное его понимание с точки зрения нашей организации - вуза
-
я-таки не понимаю, в чем проблема?
-
я-таки не понимаю, в чем проблема?
Первая проблема где указать ПКГ и ПКУ - у самой должности в справочнике должностей или у штатной позиции.
Пока анализ данных показывает что конкретная профессия рабочего и должность должна быть отнесена к одной единственной профессиональной группе и иметь определенный уровень.
Есть неоднозначность для определенного класса должностей (профессий), когда его уровень зависит от штатной единицы и особенностей человека (сотрудника) занимающего данную должность
Представленная модель - набросок
-
Попытался изобразить как примерно реализовано в 1С, немного концептуализировано
-
так как приведенных нормативных документов не читал, то предположу, что квалификационный уровень - атрибут соответствующего сотрудника, а квалификационная группа - это набор возможных вариантов (или один единственный вариант) у должности. при этом сотрудник может занять должность, если его уровень соответствует одной из возможных квалификационных групп, подходящих для этой должности. причем, видимо, ставка работника зависит как раз от группы. про доплаты и т.п. ничего сказать не могу, IMHO они могут зависеть от чего угодно, здесь бы из как-то упорядочить сначала: что из них первично, и что от чего зависит.
как говорится, "чую, но обосновать не могу".
-
на картинку, вряд ли надбавка должна быть связана со штатным расписанием, скорее с должностью, квалификацией или подразделением или со всеми вместе или поотдельности. правда тогда это будут разные надбавки, пусть даже и похожие (структурно) сущности.
-
так как приведенных нормативных документов не читал, то предположу, что квалификационный уровень - атрибут соответствующего сотрудника, а квалификационная группа - это набор возможных вариантов (или один единственный вариант) у должности. при этом сотрудник может занять должность, если его уровень соответствует одной из возможных квалификационных групп, подходящих для этой должности. причем, видимо, ставка работника зависит как раз от группы. про доплаты и т.п. ничего сказать не могу, IMHO они могут зависеть от чего угодно, здесь бы из как-то упорядочить сначала: что из них первично, и что от чего зависит.
как говорится, "чую, но обосновать не могу".
Вся проблема в том, что нормативные документы не особливо тут помогают, т.е. есть некоторые общие рекомендации, а остальное как я понимаю творчество на местах. Я полазил по инету и обнаружил, что творчество на местах сильно зависит от места. Что указывает, что собственно ничего страшного, главное чтобы заплатили правильную зарплату:)
Однако во всех изученных мною документов проявляется между группой и уровнем именно та закономерность, что я изобразил на первой диаграмме:
пример для понимания:
ПКГ общеотраслевых должностей (профессий) рабочих - мин оклад 2400 р.
Первый уровень ПКГ (Группа 1) (без спец образования)
Квалификационный уровень 1 - 1.0
Квалификационный уровень 1 - 1.1
Квалификационный уровень 1 - 1.2
Второй уровень ПКГ (Группа 2) (со спец образования)
Квалификационный уровень 1 - 1.3
Квалификационный уровень 1 - 1.4
Квалификационный уровень 1 - 1.5
Можно также поглядеть тут (http://www.klgd.ru/docs/norms/texts/p1682_09.php)
на картинку, вряд ли надбавка должна быть связана со штатным расписанием, скорее с должностью, квалификацией или подразделением или со всеми вместе или поотдельности. правда тогда это будут разные надбавки, пусть даже и похожие (структурно) сущности.
Картинка не вряд ли, а то что есть в данный конкретный момент в реализации 1С. Не более не менее.
Насчет надбавок:
за ученую степень, за заведование кафедры, надбавка ППС (за должность), надбавка за вредность, за совмещение, за гос тайну, другие
за ученую степень надбавка дается в том случае, если работник имеет степень (кандидат 3000, доктор 7000) и работает на должности которая эту степень позволяет (преподы и наука)
за заведование кафедры - заведующему кафедры по сути по должности
за должность - понятное дело по должности - это у нас доценты - 40% и профессора - 60%, если работник работает в должности доцента и профессора соответственно
за вредность - реально определяется картой аттестации рабочего места и вероятно должна планироваться исходя из результатов аттестации рабочего места
за совмещение - тут я без понятия
за гос. тайну - опять же определяется спецификой рабочего места - работа с соответствующей информацией, сомнительно что определяется просто должностью, хотя кто знает
другие - ну это другие, например надбавка за ученое звание, если человек работает по той же должности по какой имеет звание(доцент, снс, профессор)
Как мы видим надбавки можно разделить на
должностные - определяемые самой должностью
индивидуальные - характеристиками сотрудника
позицией или местом (характером) труда - ну это вредность, гос тайна
В системе, которую использует кадровики - надбавки определяются в приказе на прием работника и при кадровом перемещении, а дальше корректируются в отделе расчета зарплаты
Поскольку для сотрудников работающих со штатным расписанием (т.е. сотрудников ПФО) требуется расчет фонда з/п как планового так и фактического, очевидно им требуется указывать надбавки при формировании ШР также
-
всегда было интересно, какой и почему именно такой порядок (т.е. последовательность) начисления различных надбавок. IMHO логичной выглядела бы последовательность начисления: надбавки, относящиеся к подразделению (месту), потом к должности, потом индивидуальные. как на деле я не в курсе - всегда считал, что лучше иметь одну большую зарплату, чем много-много надбавок к маленькой :о)))
и всё-таки в чем вопрос? ибо наш диалог приобретает следующий характер:
- Официант, вы можете приготовить яишенку с помидорчиками, ветчинкой, немного посыпать зеленью, и для аромата сбрызнуть лимонным соком
- можем-с
- тогда не надо, а картошечку пожарить с грибочками, лучком (только совсем немного), не так что бы пришкварилось, тихонечно помешивая, пока она подруманивается, подавать с холодной водочкой и огурчиком
- сделаем-с
- тогда мне стакан чаю без сахара и бутерброд с колбасой.
- колбасы нет-с
- что у вас за ресторан, мне его рекомендовали как солидное заведение.
:о))
-
всегда было интересно, какой и почему именно такой порядок (т.е. последовательность) начисления различных надбавок. IMHO логичной выглядела бы последовательность начисления: надбавки, относящиеся к подразделению (месту), потом к должности, потом индивидуальные. как на деле я не в курсе - всегда считал, что лучше иметь одну большую зарплату, чем много-много надбавок к маленькой :о)))
Вадим, я уже заметил, что у тебя на все свое личное логичное представление. Однако жизнь иная.
Каков порядок доплат не важно, важно что они есть и они различны. Факт размера зарплаты определяется министерством образования, а не работодателем. Вернее ректор - это не работодатель. Мы же не коммерческая организация
и всё-таки в чем вопрос?
Я не могу донести до тебя видимо, что вопрос в структуре данных:
- данные можно хранить разрознено и не парится на счет ее взаимного вляиния и ограничений целостности - т.е. отдать интерпретацию в руки того, кто будет работать с информацией
- можно хранить в таком структурном виде, чтобы работали либо стандартные либо особые процедуры целостности
- можно храниить как в первом случае, но целостность поддерживать алгоритмами приложения
второй и третий случай требует понимания того, что от чего и как должно зависеть
-
Вадим, я уже заметил, что у тебя на все свое личное логичное представление. Однако жизнь иная.
по обоим пунктам - это же хорошо!
Я не могу донести до тебя видимо, что вопрос в структуре данных:
- данные можно хранить разрознено и не парится на счет ее взаимного вляиния и ограничений целостности - т.е. отдать интерпретацию в руки того, кто будет работать с информацией
- можно хранить в таком структурном виде, чтобы работали либо стандартные либо особые процедуры целостности
- можно храниить как в первом случае, но целостность поддерживать алгоритмами приложения
я действительно не понимаю твоей формулировки вопроса. вопрос обычно включает "вопросительное слово" (слово "можно" к ним не относится, если не написано "можно ли"), например: как хранить такие-то данные - разрозненно или целостно? и почему так, а не иначе? в каком виде следует хранить данные - в структурном или нет? как лучше сделать - чтобы работали стандартные или чтобы работали особые процедуры целостности?
как-то в таком духе. плиз, почётче переформулируй именно вопросы.
хотя, насколько я тебя сейчас понял, проблема у тебя архитектурного свойства: так построить архитектуру целевой системы чтобы и рыбку съесть...
цена здесь будет измеряться в таких категориях: сложность взаимодействия и трудоемкость поддержки и изменения схемы данных и рабочих процессов при изменении внешних условий, а циферку на ценнике придется считать отдельно.
второй и третий случай требует понимания того, что от чего и как должно зависеть
с поправкой на формулировку вопросов этот вопрос становится более-менее понятным.
я бы посоветовал для начала обойтись стандартными процедурами поддержки целостности. и только если не получается, пробовать что-то специальное. из специального можно посоветовать рассмотреть варианты в таком порядке: на уровне БД, на уровне приложения. возможно, критерием будет способность поддерживать транзакционность на уровне приложения, а может и нет (если это не требуется).
-
Хорошо, начнем еще раз
Наша организация - вуз - перешла на отраслевую систему оплаты в прошлом году. Ее особенностью является то, что все должности отнесены к определенным квалификационным группам и квалификационным уровням.
Это потребовало внесения изменений в используемую систему кадрового учета. Анализ изменений, которые следует выполнить зашел в тупик. Проблема заключается в том, чтобы правильно формализовать и учесть требуемые изменения.
Вопрос заключается в том, где и как учесть наличие квалификационной группы (ПКГ) и квалификационного уровня (ПКГ).
С одной стороны анализ нормативных документов показывает, что каждая должность должна быть отнесена к определенной группе и определенному уровню.
Вместе с тем группа и уровень может зависеть от свойств работника, нанимаемого на конкретную штатную позицию.
Кажется, выходом из ситуации было бы указание конкретного ПКГ и ПКУ при формировании штатного расписания, т.е. работник отвественный за формирование ШР выполнял бы такие действия:
1. выбирает нужное подразделение
2. создает позицию
3. выбирает указывает должность
4. определяет квалификационную группу и квалификационный уровень
5. указывает оклад (либо система вычисляет его автоматически)
Другой способ - для каждой должности (в случае ее уникальности названия) в справочнике должностей явно задается принадлежность к группе и уровню. Но мне кажется это не совсем корректно.
Вопрос заключается в том, где и как учесть наличие квалификационной группы (ПКГ) и квалификационного уровня (ПКГ).
-
не знаю уж, правильно ли я понял термин "учесть" :о)) но IMHO есть два варианта:
1. вести отдельные (скорее всего иерархические, судя по твоему ответу) справочники ПКГ и ПКУ, а при задании (вводе) новой должности или корректировки параметров имеющейся указывать ПКГ/ПКУ, выбирая нужные значения из справочников. так как, судя по твоему ответу, они взаимосвязаны, может быть будет достаточно выбирать что-то одно (ПКУ), а всё остальное будет заполняться в должности автоматически
Сами справочники ПКГ и ПКУ придется вести в соответствующих отдельных режимах, возможно это будет плюс, а может лишний геморрой.
2. задавать значение ПКГ и ПКУ каким-нибудь кодом, тогда справочник не нужен, но нужно будет знать и правильно употреблять эти коды.
может быть возможен третий - что-то промежуточное.
в первом случае - ПКГ/ПКУ - отдельная сущность, во втором - это просто некоторый набор метаданных.
что касается привязанного к ПКГ оклада, то в случае со справочником, он будет задаваться в справочнике, в должность копироваться. во втором варианте циферки оклада придется задавать ручками прямо в должности. IMHO первый лучше, так как при исключении должности из ШР, будет оставаться информация об окладе, связанном с ПКГ. да и вообще система ПКГ/ПКУ может оказаться достаточно сложной и разветвленной, может быть неудобно вводить руками, хотя варианты можно придумать (составной код тот же)
может стоит попробовать на макете (хотя бы в виде paintbrush-программирования) оба варианта или какие там еще придумаются.
-
Вадим, что касается твоих предложений.
Тут есть некоторая странность, которую я не могу понять до конца.
Есть приказ министерства здравооохранения, в котором рекомендуется все должности и профессии разложить по 4 профессиональным квалификационным группам.
Однако поиски в инете и беседы с нашими сотрудниками приводят к следующему выводу: групп может быть больше.
При этом понятие группы сильно смахивает на понятие персонала (вида персонала). В настоящее время наши штатники разделяют это понятие, т.е. они делают так
Есть список видов персонала. Есть список профессиональных квалификационных групп.
При этом признаком квалификационной группы может быть вид персонала.
При этом названия группы может совпадать с названием вида персонала.
По сути предполагается, что у один вид персонала может покрывать несколько профессиональных групп.
При этом текущая реализация в 1 с разрешает для одной профессиональной группы задавать разные виды персонала, т.е.
ПКГ рабочих
ПКГ рабочих уровня 1 - Вид персонала ОПР
ПКГ рабочих уровня 2 - Вид персонала ОПР
Зачем так сделано не совсем ясно, однако если изучить список персонала, то видно, что есть например такие виды:
ОПР (внебюджет) или ППС (внебюджет), т.е. вид персонал некий дополнительный группирующий признак
Полное соотнесение конкретной должности к единственной группе и единственному уровню тоже на все 100 не получается.
пример: слесарь-сантехник - это профессия рабочего или его должность, но если раньше они указывали как дополнительный признак в штатной единице - разряд! то сейчас по сути он заменен (хотя и разряд остался) сочетанием ПКГ/ПКУ
Т.е. хранить эту информацию непосредственно у должности кажется неправильным, т.к. тогда придется скажем создавать две и более записей с одинаковым названием должности и разными ПКГ/ПКУ
Потому либо следует вести отдельно справочник должностей и отдельно справочник должностей по ПКГ/ПКУ из которого в свою очередь и выбирать данные для позиции в штатном расписании.
Дополнительная проблема возникает в случае, когда сотрудник принимается вне штата, т.е. обычно при приеме на работу используется штатное расписание, т.е. явно выбирается штатная позиция со всеми ранее определенными для нее признаками, но возможно и иначе, когда просто указывается подразделение, отдельно должность - во тут возникает неоднозначность нужно или нет дополнительно в приказе указывать ПКГ/ПКУ или просто указывать размер оплаты. Или может тут вовсе нет проблемы?
-
к сожалению, не обладаю достаточным временем чтобы вникнуть в тонкости. но если встречусь с министром здравоохранения, обязательно спрошу, вероятнее все-таки встреча с кем-то из заместителей (честно!).
из всего сказанного, вариант с ведением самостоятельно справочника ПКГ/ПКУ мне представляется наиболее целесообразным. при присвоении атрибутов для должности пара ПКГ/ПКУ (и возможно что-то еще) просто будет выбираться из этого самостоятельного справочника. это как раз позволит устранить ту коллизию о которой ты говоришь, а именно:
Т.е. хранить эту информацию непосредственно у должности кажется неправильным, т.к. тогда придется скажем создавать две и более записей с одинаковым названием должности и разными ПКГ/ПКУ
может быть будет еще правильнее задавать для должности не единственный вариант, а набор ПКГ/ПКУ? а когда сотрудник занимает должность, стоит ассоциировать с ним конкретный ПКГ/ПКУ? тогда возможные варианты останутся для вакантных должностей, что позволит претендовать на должность сотрудникам с разной (но подходящей!) квалификацией.
а вообще у должности в ШР может быть довольно много разных атрибутов, в зависимости от потребностей организации, а не только те, которые написаны в руководящих документах. а если среди них попадутся взаимозависимые - что ж? тем легче будет обходиться с ними при вводе: ввел/выбрал значение для одного атрибута - другие заполнятся автоматом. нужно только аккуратно отследить возможные состояния и операции изменений.
По поводу внештатников - только одно соображение: вести параллельно штатному расписанию отдельный учет всех (и штатных, и нештатных) сотрудников на уровне подразделения. соответственно, иметь возможность формировать отчеты, включающие все эти категории сотрудников (в какой надо форме, например, группируя отдельно штатных и отдельно нештатных сотрудников)
как-то так...
P.S. похоже, мы постепенно выходим за рамки тематики форума, может лучше в личку пойдем?
-
P.S. похоже, мы постепенно выходим за рамки тематики форума, может лучше в личку пойдем?
Не ну это как тебе хочется. Публичное изъявление может быть полезным, а может бесполезным. Не знаю.
По поводу всего сказаного.
Кажется пришло такое решение.
Будем держать справочник видов персонала для особой группировки должностей.
Нужен естествено иерархический справочник ПКГ/ПКУ
Для должности назначаем отдельный справочник, но вводим два признака: вид персонала: для фиксации некоторой принятой в организации классификации, и профессиональная квал. группа.
Таким образом мы отнесем некоторую должность (профессию) к определенной квалификационой группе и некоторому виду персонала.
Это не противоречит утверждениям
Должность должна быть отнесена к некоторому виду персонала
Должность не может иметь в качестве признака одновременно два вида персонала
Должность должна быть отнесена к определенной квалификационной группе
Должность может быть отнесена только к одной квалификационной группе
Факт, что должность может иметь разные квалификационные уровни определяется штатной позицией (план) и человеком занимающим данную штатную позицию (факт)
Ну и для визуализации мысле картинки.
-
Не ну это как тебе хочется. Публичное изъявление может быть полезным, а может бесполезным.
ОК, не вопрос.
Кажется пришло решение.
ну и хорошо! посоветую все-таки набросать макет, чтобы убедиться в соответствии решения ожиданиям.
-
Вот еще родилась концепция. Кто что скажет?
Некоторые факты.
ПКГ - профессиональная квалификационная группа
ПКУ - профессиональный квалификационный уровень
Профессиональная квалификационная группа объединяет должности разных видов (категорий) персонала.
Категория (вид) персонала может входить только в одну квалификационную группу
Одна и таже должность может иметь разные квалификационные уровни (стеклодув - 1.05 и 1.15, например)
В штатном расписании при указании должности следует указать и соответствующий ей ПКУ причем если их несколько, то только 1.