Мы довольно хорошо умеем находить проблемы в процессах. Умеем строить AS IS, показывать узкие места, писать списки улучшений.
Но вот что происходит дальше — каждый раз выглядит как импровизация.
— кто-то начинает «оптимизировать»
— кто-то предлагает автоматизацию
— кто-то вообще решает всё перепроектировать.
И часто это больше похоже на интуицию, чем на метод.
За последние годы работы с процессами я заметила одну повторяющуюся вещь.
Большинство изменений в процессах начинается не внутри процесса, а вне его.
Меняется среда:
— новая технология
— новый регулятор
— новая бизнес-модель
— рост или падение нагрузки
И процесс, который раньше работал нормально, внезапно начинает ломаться.
Из этого наблюдения постепенно родился один подход, который я сейчас оформляю как методологию.
Я называю его MSPC — Model of Systemic Process Change.
Идея очень простая:
изменения в процессах нельзя проектировать, пока не понятно что именно изменилось в среде процесса и как это изменение влияет на его внутреннюю структуру.
На практике это приводит к очень интересной вещи.
У процессов есть всего несколько логичных исходов:
➡️ автоматизировать
➡️ оптимизировать
➡️ перепроектировать
➡️ или удалить
Но выбрать правильный вариант можно только после системной диагностики.
Я сейчас оформляю MSPC как полноценную методологию и хочу показать её подробнее:
— с примерами
— с диагностическими вопросами
— и с тем, как она помогает проектировать изменения без хаоса.
Пока интересно другое.
А как у вас обычно происходит переход от «мы нашли проблему» к «вот решение»?