Бизнес-процессы: виды, владельцы и примеры

Сформулируйте результат изменения одним предложением. Назовите, кто принимает решение, в каких пределах и когда привлекает руководителя. Ориентиры: «Событие запуска» и «Последовательность».

Процесс начинается не с названия отдела, а с конкретной потребности, запроса или сигнала.

Для части «Событие запуска» нужен видимый результат. Формулировки «мы договорились» недостаточно, если сроки, качество или способ принятия решений не изменились.

Шаги превращают входные данные в результат и включают решения, передачу работы и контрольные точки.

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

Роли могут относиться к разным подразделениям; процесс показывает их общую ответственность за весь поток.

Если часть «Участники» работает только после напоминания руководителя, договоренность еще не стала частью обычной работы.

У результата есть получатель и критерии приемки, иначе невозможно отличить завершение от формальной активности.

Договоренность должна выдерживать обычную рабочую нагрузку. Если правило «Результат» обходят при первой срочной задаче, причина не устранена.

Владелец процесса видит показатели, исключения и изменения и обладает полномочиями улучшать всю последовательность.

Само наличие документа ничего не доказывает. Посмотрите, изменила ли договоренность «Управляемость» поведение команды в реальной задаче.

Опишите одну повторяющуюся ситуацию: где возникла задержка, кто ждал решения и к каким последствиям это привело для бизнеса.

Определите, какая часть работы дала сбой. Сначала проверьте «Событие запуска». Не пытайтесь одновременно исправить всю компанию.

Договоритесь о новом порядке действий, одном ответственном и пределах его самостоятельности. Отдельно согласуйте «Последовательность».

Проверьте договоренность в реальной работе. Посмотрите, как сработали «Участники», и сравните результат с исходным состоянием.

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

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

Проблема вернется, как только вырастет нагрузка. Перед запуском договоритесь, как команда работает с исключениями и кто может менять правило. Для исправления начните с части «Последовательность» и назначьте ответственного.

Первый сбой после изменения не доказывает, что подход ошибочен. Разберите причину, уточните границы и повторите проверку. Следующий шаг — выяснить, что именно не работает в части «Участники».

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

Перед изменением зафиксируйте несколько доступных показателей. Для первой проверки сосредоточьтесь на части «Событие запуска», а не создавайте большой отчет. Не делайте вывод по одному случаю: проверьте «Событие запуска» хотя бы на нескольких рабочих ситуациях.

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

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