В продолжение статьи «Сила регламентов» разберём более детально механику написания. Сокращу повествование из расчёта на то, что читатель уже писал и работал с регламентами, и постараюсь сосредоточиться и показать различия и обозначить принципы.

Шаг 1. «Зачем?» Перед написанием регламента нужно понять, а зачем он вам нужен. И вот тут подробнее. Несмотря на кажущуюся очевидность ответов из разряда «для контроля», «для качества», «для ответственности» и прочее, это всё вторично. А вот истинные мотивы в прямом контексте мне так и не попадались, хотя, если разобраться, они очевидны. Регламент нужен для устранения конфликта. Да, так просто. Вы спросите почему? Потому что для выполнения поставленных задач два человека без проблем могут договориться и нарисовать для себя приемлемые зоны ответственности без всяких регламентов. Проблемы начинаются там, где сотрудники не могут нормально договориться, из-за чего начинает страдать работа или проект. Безусловно! Сначала идут все возможные управленческие мероприятия, направленные на то, чтобы люди начали работать друг с другом. Но, как и в знаменитой пословице, «можно привести лошадь к водопою, но нельзя заставить её пить». Не всех сотрудников можно «подружить». Вот именно в этом случае на сцену выходит регламент, устраняя все споры. Лично автор всегда фиксирует в разделе «Введение» или другом общем разделе то, что делает или решает данный регламент.

Шаг 2. «Что писать?»

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

2. Отработка. На этом этапе мы описываем то, как исполнитель должен отработать «заявку» в зависимости от самой заявки. То есть критерии принятия решения. Например: «Исполнитель, получив типовую “заявку” на разработку, подготавливает решение в течение необходимого (или оговорённого в заявке) времени. Проект решения направляется посредством корпоративной почты на согласование руководителю. Руководитель, получив проект решения, выставляет замечания в течение определённого времени и пересылает их сотруднику ответным сообщением. Все замечания должны выдаваться единовременно и только в формате ответного сообщения. Устные указания руководителя по той или иной корректировке проекта, в устной форме, выполняются сотрудником на его усмотрение»… И так далее. Заметили разницу? Не «все выполняемые сотрудником работы должны быть согласованы с руководителем», а чёткий алгоритм, исключающий многие вещи, начиная от травли сотрудника и заканчивая тем, что эти процессы при желании уже можно частично нормировать, регулируя нагрузку.

3. Завершение. Описав процесс отработки, не менее важно описать, как, в каком виде и куда должна быть передана информация о выполненной работе. Конечно же, с перечислением основных критериев, как в пункте 1. Потому что «выходная» информация для вас является «вводной заявкой» для следующего после вас в цепочке.

Если вы пишете длинный регламент, то просто повторяете пункты 2 и 3 столько, сколько нужно. Я работал с разными регламентами: по договорной работе, расчёту ОКР, работе конструкторов, технологов, ПДО, отдела продаж, внедрению ИТ-продуктов и другим. И этот алгоритм показал себя более чем хорошо.

Если у вас всё ещё остались вопросы, пишите в лс, и давайте становиться эффективнее вместе!