В компании есть процесс, который давно просит ремонта.

Не катастрофа. Не пожар. Просто работа каждый день цепляется за одно и то же место.

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

Все уже понимают, что так неудобно.

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

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

Дальше вопрос в том, как превратить предложение в принятое изменение процесса.

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

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

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

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

Очень удобная конструкция для вечного обсуждения.

Сбой часто видят все.

Но между «надо поправить» и «теперь работаем иначе» у компании нет понятного маршрута.

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

Но для управления процессом нужен ещё один маршрут.

Маршрут изменений.

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

Вопрос не в том, чтобы выдать кому-то волшебное право всё менять.

Вопрос в том, чтобы компания понимала, как изменение проходит от «здесь что-то не работает» до «теперь работаем иначе».

При этом изменение нужно оценивать по результату всего процесса: локальное улучшение в одном месте не должно создавать новую проблему в другом.

А новый порядок нужно зафиксировать так, чтобы через неделю он не превратился в устное «мы вроде договаривались». Без этого процесс можно описать, согласовать и даже внедрить. Но любое изменение снова будет проходить через чаты, личные договорённости и обход всех руководителей.

Система управления в режиме «обойдите всех и принесите мне финальную версию».

Описать процесс недостаточно. Компания должна понимать не только, как по нему работать, но и как его менять.

Я бы проверял это простым вопросом. Если завтра станет понятно, что правило мешает работе, понятно ли в компании, как его изменить?

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

Но управлять его изменениями всё ещё приходится вручную.

Ещё больше обо мне | sergey-suslov.ru