В предыдущей статье мы поговорили о должностной инструкции (ДИ), как о документе.
Если в трудовом договоре нет обязанностей и нет ДИ, с которой работник ознакомлен и поставил свою подпись, то получается, что моя основная задача просто придерживаться режима работы: вовремя приходить и уходить?! Сложно уволить работника за невыполнение обязанностей, если они нигде не описаны. Попробуйте доказать, что именно я должна была что-то сделать, но не сделала. Да и почему я, а не кто-то другой 😁?
Меня же берут на работу для какой-то четко обозначенной работы, в трудовом договоре указывается зарплата именно за определенный в ТД или в ДИ функционал. Для выполнения такой работы у меня должен быть набор необходимых компетенций.
Если задачи выходят за рамки моей должности, то необходимо мое согласие на выполнение этой работы и по-хорошему еще и дополнительная оплата. О чем часто работодатели предпочитают умалчивать.
ТК РФ Статья 151. Оплата труда при совмещении профессий (должностей), расширении зон обслуживания, увеличении объема работы или исполнении обязанностей временно отсутствующего работника без освобождения от работы, определенной трудовым договором.
При совмещении профессий (должностей), расширении зон обслуживания, увеличении объема работы или исполнении обязанностей временно отсутствующего работника без освобождения от работы, определенной трудовым договором, работнику производится доплата.
Размер доплаты устанавливается по соглашению сторон трудового договора с учетом содержания и (или) объема дополнительной работы. (Ст.60.2.ТК РФ).
Но если обязанности нигде не описаны?
Почему -то вспомнился анекдот в тему:
В СССР самая высокая секретность. Во Франции на одном заводе не знают, что делают на другом в той же фирме. В Англии в одной лаборатории не знают, что делают в другой, в соседней. В США сотрудник не знает, что делают за другим столом. У нас сотрудник сам не знает, что он делает.
Много организаций, где нет четкого описания обязанностей работника. Только его должность указана в ТД. Годы идут, но есть в мире что-то постоянное😁. В некоторых организациях до сих пор иногда не понятно, чем занят или должен заниматься работник.
Со мной на работе был случай: когда я работала в должности ведущего аудитора по качеству, мой руководитель дала мне задачи, связанные с разработкой системы рисков в организации. Надо сказать, что у нас было отдельное подразделение по рискам, т.е. в мои обязанности это никак не входило. Я конечно выполнила работу, но все чаще стали прилетать задачи из соседних подразделений. Когда я поинтересовалась про доплату, мне сказали, что я и так получаю максимальную по своей должности и больше не положено. Аргумент руководителя меня убил, она сказала, что задач по качеству сейчас у меня почти нет, поэтому работаю за другие подразделения 🤣. По такой логике, если по моему направлению задач не было, то можно было бы меня и уборщицей, секретарем и пилотом сделать. Руководитель отвечала за 3 направления деятельности, поэтому подкидывала мне задачи со словами, что только у тебя есть необходимые компетенции. При этом дополнительная оплата не для меня. Не буду вдаваться в детали, но как итог: выгорание крайней степени и заявление на увольнение.
Вернемся к нашей теме, а то слегка отклонились от курса.
Сегодня бы хотелось коснуться жизненного цикла (ЖЦ) документа и kpi, которые с ним связаны.
Разработка
Напомню, что ДИ качественно разработать может только непосредственный руководитель. Только он знает зачем ему в подчинении та или иная должность, какие должны быть квалификационные требования к человеку, который будет занимать должность (чтобы работник в полном объеме мог выполнять функции, которые описаны в ДИ). Ни один HR не обладает даром ясновидения, чтобы принимать такие решения за руководителя, даже если он гениальный специалист. Задача HR может быть только описать правила игры, т.е. описать все требования к жизненному циклу ДИ, с учетом организационной структуры организации. Для облегчения разработки ДИ руководителями рекомендую разработать шаблон, в котором будут все стандартные поля указаны, причем лучше сделать их с нередактируемый полями, чтобы не перепроверять все время были ли внесены в стандартные пункты изменения или нет . Если для должности предусмотрены какие-то льготы, то все, кто как-то связан с назначением льгот должны участвовать в разработке требований к ДИ и в разработке шаблона, а затем и являться согласующими.
Для разных категорий и/или ролей в СУ могут быть разные шаблоны. Можно разрабатывать ДИ исходя из структуры организации, т.е. отдельные шаблоны с отдельным стандартным набором обязанностей и ответственности для высшего руководства, для руководителей среднего звена и для специалистов.
При разработке ДИ высшего руководства может пригодится информация из ГОСТ Р 72465-2025 Системы менеджмента. Требования к качеству и эффективности управленческой деятельности высшего руководства организаций.
Когда мы разрабатываем ДИ только с учётом иерархической модели, то получается сильно упрощенная модель.
В ней не всегда учитываются некоторые нюансы сквозных процессов. Даже если эти процессы не определены/выделены в организации, то они все равно есть. Допустим есть ещё система управления 3 и в подчинении царей 1 и 2 есть специалисты, участвующие в работе СУ 3. По хорошему, функционально в этих процессах боярин 1 и холоп 2 должны быть подчинены царю 3, архитектору СУ 3. И если процессы настроены, то взаимодействие простое и быстрое, нет ещё дополнительных лишних звеньев, которые сильно тормозят работу и усложняют коммуникацию.
Например, правила по охране труда устанавливают специалисты по охране труда, а мы все должны их соблюдать, так же и с пожарной безопасностью, гражданской обороной и т.п. Все перечисленные процессы существуют, потому что это обязательное требование законодательства и не выполнять их мы не имеем права. Не зря же при приеме на работу мы обязаны ознакомиться с документами, подставить подпись в журналах о том, что нам проведен инструктаж и мы обязуемся выполнять все требования. Но в более крупных организациях есть еще важные сквозные процессы, которые по-хорошему тоже должны быть отражены в ДИ, в зависимости от роли в системе или структурной организации. Например, процессы управления рисками, качеством, финансовое планирование.
На все эти процессы должны быть разработаны свои внутренние стандарты. Иначе сложно выполнять правила, которые нигде не описаны, но в ДИ на них ссылаются.
Да и наличие утвержденных документов - это еще не гарантия того, что все будет выполняться правильно. Мало создать требования и правила. Надо распределить роли по всей организации и это должен инициировать архитектор системы управления, а владелец системы управления должен расписать квалификационные требования к лицам, которые могут исполнять указанные роли в смежных и неподконтрольных подразделениях, а еще провести обучение тех работников, которым были назначены эти специфические роли и соседней СУ. Думаю не стоит упоминать, что это не единоразовая акция, а периодически актуализируемый и контролируемый процесс. Т.е. должен быть специалист в СУ, в обязанности которого входит контроль выполнение всех установленных СУ требований к персоналу и не только в смежных подразделениях.
Напомню картинку про иерархическую модель управления и процессную.
Допустим есть ещё Царь 3 - это наш архитектор СУ 3. Он понимает, что для того, чтобы в полном объеме функционировала его СУ, то у Царя 1 и у Царя 2 были его "засланные казачки", в хорошем смысле этого слова. Т.е. у других царей должны быть в подчинении специалисты, которые выполняют необходимые Царю 3 функции. Для этого он инициирует процесс назначения ролей во всех неподконтрольных ему подразделениях. И просит всех Царей 1 и 2 предоставить списки должностей и/или работников, которые будут эти роли выполнять. С одной стороны может возникнуть вопрос "зачем все это?". Ответьте себе на вопрос: как мы будем контролировать, что человек, выполняющий роль, в полном объеме знает и понимает, что от него требуется?
Если у нас не будут списков, то как мы будем знать кого и чему нам надо обучить, чтобы все работало, как задумывалось, а не как придумали они сами? Задача любого владельца СУ выстроить процесс, т.е. важна регулярность и актуальность всего происходящего, а не просто один раз запустить процедуру и забыть, но при этом надеяться, что все прекрасно работает.
Как мы видим, то процессная модель сил но упрощает управление, но весь дополнительный функционал должен быть отражен в ДИ работника. После того, как роли распределены, можно вносить изменения или дополнения к ДИ. Как вы думаете, почему я заговорила про дополнения, а не просто про изменения? Тут все просто: по-первых, на одной должности может работать 2 и более человек, а роль специфической СУ выполнять только один из них. В таком случае нужна только одна ДИ на всех специалистов на должности и одно дополнение тому, кто имеет дополнительный функционал. А во-вторых, считаю необходимым напомнить, что дополнительный функционал должен дополнительно оплачиваться (можно опираться на ст.151 ТК РФ), но часто работодатели этот нюанс упускают. Функций, т.е. обязанностей и ответственности навесили, а про оплату благополучно "забыли" 😃.
Так вернемся к ЖЦ ДИ. HR создает требования и правила. Руководители обязаны разработать ДИ на своих непосредственно подчинённых с учётом этих требований. Как вы думаете наличие утверждены и актуальных ДИ подразделений - это чей kpi: HR или руководителей, в чьей зоне ответственности находится разработка документов. Конечно это kpi руководителей, только от них зависит разработка ДИ, но это не говорит о том, что у HR нет своих kpi, связанных с этим процессом. Но к этому вернемся чуть позже.
Для начала разработки\актуализации ДИ должно произойти какое-то событие, триггер. Как вы думаете какое? Вариантов может быть несколько:
- Приказ о начале разработки, если до этого ДИ не было в организации и вот решили, что надо начинать.
- Любое изменение в штатном расписании: переименование должности, появление новой должности, сокращение существующей должности.
- Внесение изменений в функционал, обязанности или любой пункт, который указан в ДИ (квалификационные требования, подчиненность, режим работы и т.п.)
В приказах о необходимости разработки ДИ должны быть указаны сроки выполнения задачи, но как правило там указаны только конечные результаты: т.е. утвердить ДИ подразделений в срок до. Но до этого одни должны в определенные сроки разработать, другие провести оценку\согласование, если есть замечания, то отправить обратно разработчику для устранения замечаний, потом получить опять на согласование со всеми заинтересованными сторонами и это может быть хождение по кругу не один раз, и после того, как все замечания устранены, документы можно утверждать. Весь ЖЦ, т.е. алгоритм действий со сроками по каждому этапу,, должен быть четко определен во внутреннем документе. Так каждый участник процесса разработки , согласования и утверждения ДИ будет четко понимать свою роль и не будет вопросов, кто виноват, если kpi каждого участника процесса будет отслеживаться. Конечный результат, если он не радует, можно разложить на составляющие и увидеть на каком этапе ЖЦ ДИ возникают проблемы чаще всего и с этим уже дальше работать.
Итак, мы видим уже несколько участников ЖЦ ДИ:
- Разработчик.
- Согласующий (может быть не один, а несколько специалистов и разных областей).
- Утверждающий.
Согласование
Как только разработчик разработал ДИ, то он должен отправить ее на согласование со всеми заинтересованными лицами. Нет универсального набора согласующих. Все зависит от структуры организации, наличии льгот для должностей и самих процессов.
Процесс согласования тоже должен иметь свои сроки, он не должен длиться месяцами. Все согласующие независимо от уровня должности обязаны придерживаться этих правил и сроков. Исход согласования может быть разный: согласовано или есть замечания для устранения. Когда согласовано, то дальше документ разработчиком со всеми согласованиями передается на утверждение. Если были замечания, то их тоже необходимо устранить с определенные сроки и повторно отправить на согласование согласующим. Всем согласующим или только некоторым зависит от того, к каким пунктам были замечания. После уже можно отправлять на утверждение руководителю.
Утверждение
В качестве утверждающего могут быть разные должностные лица. В небольших организациях это может быть руководитель организации. В более крупных могут быть заместители руководителя по направлениям деятельности. В этом случае каждый заместитель утверждает ДИ только по своему направлению деятельности, т.е.ДИ своих подчинённых. При этом такая ответственность должна быть описана в документе о разработке ДИ. Иначе не понятно на каком основании руководитель принимает такое решение. Нотариальная доверенность в этом случае будет просто лишней.
Для утверждения тоже по-хорошему должны быть свои сроки, но как правило, документы уже никто не читает и не смотрит, смотрят только на согласование от заинтересованных сторон и и зачастую все утверждение - это просто нажать кнопочку или поставить подпись. Да и не каждый осмелится диктовать условия и ставить сроки утверждающему 😁. Серьезные люди такого не поймут.
Ознакомление
Один обязательный этап для ДИ - это ознакомление с подтверждением подписью. Без получения подписи - это все просто бумажка, которая при наличии спорных ситуаций не имеет значения. С точки зрения трудового законодательства только верно оформленные документы и все соблюденные процедуры имеют вес. Если в ДИ были внесены изменения, то необходимо обязательно ознакомить с ней работника. Но если в ДИ вносятся значительные изменения функционала, то нужно получить согласие работника. Подписал=согласен. Но если не подписать, то работодатель имеет право сократить или попросить уволиться по соглашению сторон, например. Тут уж каждый решает сам.
Kpi
У каждого участника процесса свой kpi.
Разработчик: должен разработать определенное количество ДИ, в соответствии со штатным расписанием, в определенные сроки (в течение .... После издания приказа или после изменения ШР) и отправить на согласование.
Согласующий: должен провести оценку пришедшего на согласование документа, например, не позднее 10 рабочих дней после наступления события. И его kpi зависит только от его работы. Т.е. от того, сколько специалист в установленные сроки провел оценок и согласований, в зависимости от количества документов которые пришли на согласование. Помните, что само по себе количество согласованных документов нам ни о чем не говорит (мы говорили об этом ранее)?
Утверждающий: в его зоне ответственности разработать ДИ на свое подразделение. Но личный kpi (kpi утверждающего) у него только по количеству утвержденных документов по отношению к количеству ДИ, пришедших на утверждение в определенные сроки.
Kpi процесса количество утвержденных документов, к количеству необходимых утвержденных. Т.е. если в подразделении 27 должностей, то должно быть утверждено в установленные сроки 27 ДИ.т.е. само по себе количество утвержденных ДИ нам ни о чем не скажет. У одного утверждающего, если их несколько, может быть 5 должностей в подчинении, а у другого 15. И если они оба утвердили по 5, то первый справился полностью, а второй явно не доработал.
Так что прежде чем, разрабатывать kpi для процесса или должностных лиц, надо убедиться, что они выставлены верно и ответственные весны правильно. Иначе ничего хорошего не ждите.