Требования к описанию бизнес-процесса

Что это такое: Требования для исключения распространённых ошибок в тексте регламента или иного описания процесса. Как отличить хорошее описание бизнес-процесса от плохого?

При регламентации описание бизнес-процессов должно проводиться таким образом, чтобы правила были понятны сотрудникам, и их удобно было бы выполнять.
Большинство методик, которыми сейчас пользуются специалисты, нацелены также на специалистов, то есть — неудобны для пользования теми, кто не прошёл обучение.

Мы создаём описания процессов для людей. Свой опыт по итогам распространённых ошибок мы собрали в этом документе.

Формулировки операций

Одна операция — один исполнитель.
Человек, читая ТОЛЬКО СВОИ строчки, должен полностью понять, что он должен делать.

Если в строке у С1 (сотрудник 1), например, будет написано, что должен делать С2, то С2 может даже никогда и не узнать о том, что он, оказывается, это должен.
(Люди внимательно читают только свои строки.)

Операция расписывается до уровня рядовых исполнителей.
Не только по своему подразделению, но по всем.

Это дает более реалистичную картину того, чем заняты люди. Это позволяет (вынуждает) владельца процесса более хорошо узнать процесс, следовательно — лучше его настроить.

Операция — это когда кто-то что-то делает. За каждую операцию есть ответственный.

Наступило 5 число — это не операция.

Не описывать обобщенными словами.
Операция должна быть описана так, чтобы можно было представить себе её выполнение и понять, сколько она занимает времени, а новый человек мог понять, что от него хотят.
Это повышает прозрачность и возможности усовершенствовать процесс.
Выносить в приложения описания операций можно ТОЛЬКО если всё там выполняется одним человеком. (Желательно выносить меньше).

Вместо «проанализировать техзадание» нужно писать «вписать в каждую строку техзадания цену по проектам-аналогам» или «сравнить построчно цену из предложения с ценой по стандарту, и при отклонении более 25% сделать то-то».

Не описывать одно и то же в разных местах.
Те операции, которые где-либо описаны подробно (в инструкциях, других регламентах) могут быть описаны  кратко.

Так, если в регламенте документооборота описано, как регистрировать письмо, или как работать с замечаниями к документу, то в другом месте достаточно указать «зарегистрировать». Или «согласовать или дать замечания».

Передать/отправить — относится к предыдущей операции, не является отдельной операцией.

Так, например написал техзадание и оставил на своем компьютере — не имеет ценности такая операция, пока не передано следующему (Нельзя проверить, когда выполнено. Нельзя начать следующую операцию).

Если операция альтернативная, то надо писать: если да, то что И если нет, то что.

Если сотрудник что-то делает в связи с процессом, то это должно быть указано. 2 распространенных ошибки:
А) не указывать, что участвуют другие подразделения
Б) не указывать, что участвует Ваше подразделение

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

Если в процессе упоминается что-то, чего не было в наличии на момент начала процесса, то должно быть указано, откуда это берётся.

Например, если в пакете документов или при проверке упоминается пояснительная записка, то ранее должны быть операции «написать п.з. и отправить/вложить в пакет документов».

Описание операции отвечает на вопрос «что должен СДЕЛАТЬ ответственный».

«Заполнить заявку» а не «заполнение заявки». Из такой формулировки наиболее понятно, что человек САМ должен СДЕЛАТЬ то что там написано, что речь идет о действии.
Также это актуально для руководителей: что он делает сам, а что поручает подчинённым.

Отсылки и наименования

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

Отправить на согласование в соответствии с регламентом документоооборота, процедура "Согласование приказа".

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

«Дай мне форму приложения 3 к регламенту тендера» или «дай мне форму техзадания»?
«Приложение 2 к приложению 3», или «график к договору генподряда»?

Если документ относится к двум регламентам — в одном из них надо делать ссылку.

Например, если документ "финансовый план" относится к двум регламентам — исполнение и разработка финплана, то он не может быть приложением к ним обоим (2 формы, 2 номера приложений). Иначе может оказаться 2 разных формы финансового плана.

Называть документ, подразделение, термин надо везде одинаково, для чего и предназначен общий глоссарий. Туда удобнее вынести и определения, которые загромождают документы и, как правило, смысла не несут.

Отдел управленческого учёта, например, можно называть либо ОУ, либо ОУУ, но везде одинаково.

Задачи владельца процесса / разработчика регламента. Содержание регламента

Отсутствие обходного пути. Не должно быть 2 способа сделать одно и то же, при которых разные требования к материалам и действиям (сложный и простой путь).

Например, если ведется проверка заявки на платёж в ходе разработки и в ходе исполнения финплана, то необходимо, чтобы критерии проверки и условия СОВПАДАЛИ. Т.е. независимо от того, подается ли платёж с полными или неполными данными, платится вовремя или срочно, в итоге всё равно должны быть полные данные и одинаковая проверка.

Увязка по срокам со смежными процессами (уже утверждёнными или уже действующими).

Например, надо регламент разработки финплана наложить на регламент приемки работ, выявить момент получения выполнений, когда именно они будут получены, чтобы увидеть, в какой момент люди на самом деле могут сделать заявки. Также состыковать по срокам с регламентом разработки плана продаж, и если ПП готов раньше, то можно его раньше получать и проверять.

Согласование с исполнителями/руководителями их подразделений. Это строго обязательно!
Каждый имеет право давать замечания по своим ячейкам. По чужим только так, для сведения, т.е. их имеет право ВП не принимать.
Без этого возрастает сопротивление и часто упускаем значимые вещи.

Если участники не могут договориться — то решаем вопрос по подчинённости, идём к общему начальнику. Если не читают — идём к ним, берём за руку и зачитываем им вслух. Обсуждаем с ними, какие их специалисты и как выполняют их операции, из 1 операции может появиться 5 после такого обсуждения

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

Например, о ситуации с нехваткой поступлений — в каком случае финплан становится неактуальным и что с ним делать? В каких случаях старый финплан не требует корректировки, в каких корректировка не требует приостановки оплат, а в каких требует?

Разработка критериев и требований. Когда что-то кем-то может быть принято/не принято, на что-то проверяется, нужно давать исчерпывающее описание того, что один даёт другому, и на что второй проверяет, и что может быть основанием отказа.

Иногда работа над регламентом выводит на более глубокие нерешённые проблемы, которые нельзя решить в рамках регламента и ограниченного времени. Эти проблемы надо хотя бы обозначить и сформировать по ним задачу с конкретным сроком решения.

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

Есть печальная традиция в перекладывании ответственности.
Так например если ответственность за отчёт, например, возложена на подразделение 1, то это подразделение, будучи владельцем процесса, просто пишет другим подразделениям операцию «сделать отчёт и прислать к такому-то числу», потом у себя эти отчеты объединяет и отправляет адресату. При этом трудозатраты исполнителей из других подразделений — по 2 часа на каждое, а подразделения 1 — 15 минут.
И кто эту операцию делает?

Владелец процесса должен сделать регламент таким, который может быть выполнен непосредственно после его подписания.
Также он должен вписать регламент в общую систему регламентов.

(Когда регламенты разрабатываем мы, это всё делаем мы).