Что у нас нового?
Ваш сотрудник одновременно учится под руководством куратора и выполняет реальную работу над Вашим бизнес-процессом. Часто курс окупается экономическим эффектом уже во время обучения.
→ Читать программу курса
Что это такое: Требования для исключения распространённых ошибок в тексте регламента. Как отличить хороший регламент от плохого?
При регламентации
описание бизнес-процессов должно проводиться таким образом, чтобы правила были понятны
сотрудникам, и их удобно было бы
выполнять.
Большинство методик, которыми сейчас пользуются специалисты, нацелены также на специалистов, то
есть — неудобны для пользования.
Мы пишем регламенты для людей. Свой опыт по итогам распространённых ошибок мы собрали в этом документе.
Формулировки операций
| Требование | Пример | |
| 1 | Одна операция — один
исполнитель. Человек, читая ТОЛЬКО СВОИ строчки, должен полностью понять, что он должен делать. |
Если в
строке у С1 (сотрудник 1), например, будет написано,
что должен делать С2, то С2 может даже никогда и не
узнать о том, что он, оказывается, это должен. (Люди внимательно читают только свои строки.) |
| 2 | Операция расписывается до уровня
рядовых исполнителей. Не только по своему подразделению, но по всем. Это дает более реалистичную картину того, чем заняты люди. Это позволяет (вынуждает) владельца процесса более хорошо узнать процесс, следовательно - лучше его настроить. |
|
| 3 | Операция - это когда кто-то что-то делает. За каждую операцию есть ответственный. | Наступило 5 число — это не операция. |
| 4 | Не описывать обобщенными словами. Операция должна быть описана так, чтобы можно было представить себе её выполнение и понять, сколько она занимает времени, а новый человек мог понять, что от него хотят. Это повышает прозрачность и возможности усовершенствовать процесс. Выносить в приложения описания операций можно ТОЛЬКО если всё там выполняется одним человеком. (Желательно выносить меньше). |
Вместо «проанализировать техзадание» нужно писать «вписать в каждую строку техзадания цену по проектам-аналогам» или «сравнить построчно цену из предложения с ценой по стандарту, и при отклонении более 25% сделать то-то». |
| 5 | Не описывать одно и то же в
разных местах. Те операции, которые где-либо описаны подробно (в инструкциях, других регламентах) могут быть описаны кратко. |
Так, если в регламенте документооборота описано, как регистрировать письмо, или как работать с замечаниями к документу, то в другом месте достаточно указать «зарегистрировать». Или «согласовать или дать замечания». |
| 6 | Передать/отправить — относится к предыдущей операции, не является отдельной операцией. | Так, например написал техзадание и оставил на своем компьютере — не имеет ценности такая операция, пока не передано следующему (Нельзя проверить, когда выполнено. Нельзя начать следующую операцию). |
| 7 | Если операция альтернативная, то надо писать: если да, то что И если нет, то что. | |
| 8 | Если сотрудник что-то делает в связи с
процессом, то это должно быть указано. 2
распространенных ошибки: А) не указывать, что участвуют другие подразделения Б) не указывать, что участвует Ваше подразделение |
Например, если сотрудник должен согласовать записку с руководителем, то операция есть не только у сотрудника, но и у руководителя есть операция «принять решение согласовать ли записку», и если да, то что и если нет, то что. |
| 9 | Если в процессе упоминается что-то, чего не было в наличии на момент начала процесса, то должно быть указано, откуда это берётся. | Например, если в пакете документов или при проверке упоминается пояснительная записка, то ранее должны быть операции «написать п.з. и отправить/вложить в пакет документов». |
| 10 | Описание операции отвечает на вопрос «что должен СДЕЛАТЬ ответственный». | «Заполнить заявку» а не
«заполнение заявки». Из такой формулировки
наиболее понятно, что человек САМ должен СДЕЛАТЬ
то что там написано, что речь идет о действии. Также это актуально для руководителей: что он делает сам, а что поручает подчинённым. |
Структура бизнес-процесса, нарезка процедур
| Требование | Пример | |
| 1 | Процесс должен быть описан в
хронологическом порядке процесса, а не
дня/месяца. (Представляем себе, как будто это самый
первый цикл процесса. Задаём себе вопрос — что
после чего.) Если действие совершается 2-го числа месяца, но в конце процесса — это действие должно быть в конце регламента, а не в начале. |
Не может финансовый план быть исполнен и помещен в архив, пока он не утверждён. Даже если утверждение, например, 13 числа, а финплан предыдущего месяца идет в архив 2 числа. |
| 2 | Вход — это что предшествует, запускает
процесс или процедуру. Вход не пишется в качестве
первой операции, он уже произошел раньше. Вход — это событие, или результат других процессов, или дата. И наоборот — первая операция не может быть входом, так как она не произойдет сама по себе. |
Например, неправильный вход «появление заявки на совершение платежа», потому что заявка не возникает из других процедур или сама по себе. Это как раз первая операция — заполнить заявку на платеж. Входом может быть «возникновение потребности в платеже», или «наступление срока подачи заявок». |
3 |
Сначала пишутся процедуры,
которые происходят всегда (основные), а после них
пишутся те, которые бывают иногда (напр.
инициируются в ходе самого процесса). Все
процедуры, которые происходят параллельно,
пишутся рядом. Если процесс разветвленный, то структуру процедур лучше нарисовать графически. Если линейный, то необязательно. |
|
| 4 | Деление на процедуры условно и
делается для того, чтобы описать процесс
минимумом операций и избежать повтора
одинаковых частей в разных процедурах. Процедура, как правило, вся укладывается в один временной цикл, например, еженедельно или ежемесячно. Вкрапление туда действий с другим циклом, как правило, означает, что надо выделить эти действия в отдельную процедуру или прикрепить к другой. |
Если
некий набор операций повторяется в конце
нескольких процедур, то его надо «отрезать» и
создать из него отдельную процедуру.
Если нечто уже сделано в другой процедуре (предшествующей по схеме процесса), то это не пишем ещё раз. |
| 5 | Графическую структуру процедуры рисуем, если она НЕ линейная (нет параллельных операций). Если линейная, то не надо (в т.ч. если есть стандартный цикл — дать замечания/устранить, тоже можно не рисовать, так как этот цикл одинаковый везде, и нормально читается с таблицы). |
Отсылки и наименования
| Требование | Пример | |
| 1 | Одно и то же правило/требование/процедура не может писаться в разных регламентах. В таких случаях надо делать ссылку. Иначе получится, что в одном месте поменяем, а в другом - оставим по-старому и будут действовать одновременно две противоречащие друг другу нормы. Ссылка включает И номер И название процедуры (номер тоже может подвинуться). | |
| 2 | Ссылки на приложения. Каждому документу надо дать имя и ссылаться на имя, а не на номер, так как нумерация приложений может меняться, и человек никогда не запомнит их. | «Дай мне форму
приложения 3 к регламенту тендера» или «дай мне
форму техзадания»? «Приложение 2 к приложению 3», или «график к договору генподряда»? |
| 3 | Если документ относится к двум
регламентам — в одном из них надо делать ссылку. |
Например, если заявка на финплан относится к двум регламентам — исполнение и разработка, то она не может быть приложением к обоим (2 формы, 2 номера приложений). Иначе может оказаться 2 разных формы финплана. |
4 |
Называть документ/подразделение надо везде одинаково, для чего и есть общий глоссарий. | Либо ОУ, либо ОУУ, но везде одинаково. |
Контрольные точки
Контрольная точка — это момент, когда
проверяется состояние процесса.
То есть это такая же ОПЕРАЦИЯ, но результат
которой кто-то проверяет.
| Требование | Пример | |
| 1 | Должен быть предусмотрен способ, как будет обнаружено невыполнение КТ. | Обычный способ — это отправка копии контролеру бизнес-процессов и контроль по контрольной таблице. |
| 2 | За КТ есть ответственный (кто будет виноват в ее нарушении). Нет смысла в контроле, если нет ответственного лица. | |
3 |
Там, где нужны копии контролеру бизнес-процессов, это должно быть указано. | |
4 |
КТ в разных процедурах должны быть с РАЗНЫМИ номерами. Сквозная нумерация уменьшает путаницу для читателей. | В 1 регламенте
не может быть 2 разные КТ 2. Удобнее отсылки делать, а то о какой кт 1 идет речь — в 1, 2, или 7 процедуре?? |
Задачи владельца процесса / разработчика регламента. Содержание регламента
| Требование | Пример | |
| 1 | Отсутствие обходного пути. Не
должно быть 2 способа сделать одно и то же, при
которых разные требования к материалам. |
Например, если ведется проверка заявки на финплан в ходе разработки и в ходе исполнения ФП, то необходимо, чтобы критерии проверки и условия СОВПАДАЛИ. Т.е. независимо от того, подается ли платеж с полными или неполными данными, в итоге всё равно должны быть полные данные и одинаковая проверка. |
| 2 | Увязка по срокам со смежными процессами (уже утвержденными или уже действующими). | Например, надо регламент разработки финплана наложить на регламент приемки работ, выявить момент получения выполнений, когда именно они будут получены, чтобы увидеть, в какой момент люди на самом деле могут сделать заявки. Также состыковать по срокам с регламентом разработки плана продаж, и если ПП готов раньше, то можно его раньше получать и проверять. |
| 3 | Согласование с
исполнителями/руководителями их подразделений.
Это строго обязательно! Каждый имеет право давать замечания по своим ячейкам. По чужим только так, для сведения, т.е. их имеет право ВП не принимать. Без этого возрастает сопротивление и кроме того часто упускаем значимые вещи. Если не договориться — то решаем вопрос по подчиненности, идём к общему начальнику. Если не читают — идём к ним, берем за руку и зачитываем им вслух. Обсуждаем с ними, какие их специалисты и как выполняют их операции, из 1 операции может появиться 5 после такого обсуждения. |
|
| 4 | Учесть возможные проблемы, отклонения от прямого пути. Значимые отклонения нужно включать как дополнительные процедуры (если нужен контроль сроков) или включать в правила (если нужно просто закрепить как действовать). | Например, о ситуации с нехваткой поступлений — в каком случае финплан становится неактуальным и что с ним делать? В каких случаях старый финплан не требует корректировки, в каких корректировка не требует приостановки оплат, а в каких требует? |
| 5 | Разработка критериев и требований. Когда что-то кем-то может быть принято/не принято, на что-то проверяется, нужно давать исчерпывающее описание того, что один дает другому и на что проверяется и что может быть основанием отказа. | |
| 6 | Иногда работа над регламентом выводит на более глубокие нерешенные проблемы, которые нельзя решить в рамках регламента и ограниченного времени. Эти проблемы надо хотя бы обозначить и сформировать по ним задачу с конкретным сроком решения, в этом случае можно в регламенте умолчать или «сделать заплатку». | |
| 7 | Не добавлять ненужную работу другим подразделениям, искать более рациональные решения, в том числе с привлечением к поиску решений других участников процесса. | Есть
одна печальная традиция в перекладывании
ответственности. Так например если ответственность за отчет, например, возложена на подразделение 1, то это подразделение, будучи владельцем процесса, просто пишет другим подразделениям операцию «сделать отчет и прислать», потом у себя эти отчеты объединяет и отправляет адресату. При этом трудозатраты исполнителей из других подразделений - по 2 часа на каждое, а подразделения 1 — 15 минут. И кто эту операцию делает? |
Владелец процесса должен сделать регламент таким, который может быть выполнен
непосредственно после его подписания.
Также он должен вписать регламент в общую систему регламентов.
При этом владелец
процесса должен заниматься НЕ только своим
подразделением и даже НЕ только своим
процессом!!!, а всем, чем надо, чтобы процесс
заработал так как надо.
(Когда регламенты разрабатываем мы, это всё делаем мы).
