Оптимизатор бизнес-процессов 2.0. Лучшие инструменты повышения эффективности организаций, команд и систем - Александр Александрович Сорочан

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

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

Утро после праздника

Одним из самых не воспетых в бизнес-литературе ляпов в управлении проектами стал «эффект затухания». Что это такое? Представьте себе картину. Ваша команда успешно завершила и презентовала результаты проекта. Например, цель была снизить длительность процесса производства столов на 15 %. Цель достигнута. Процесс улучшен и на бумаге выглядит просто шикарно. Более того, Вы даже прогнозируете, что при сохранении текущих темпов повышения эффективности через четыре месяца срок сократится аж на 30 %.

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

Через год Вы идете по цеху и попадаете на производство столов. И… ужасаетесь. Все происходит совсем не так, как Вы думали. На всякий случай делаете замеры. А они демонстрируют, что время на производство одного стола не просто выросло, но и стало дольше, чем до начала Вашего проекта. Например, длительность увеличилась на 20 % по сравнению с начальными замерами.

Говоря проще, все стало еще хуже, чем было до Вашего вмешательства в процесс. Это и называется «эффектом затухания».

Но почему так происходит? Давайте как уже опытные «улучшайзеры» искать корневые причины:

1. После нас хоть потоп.

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

2. Люди приходят и уходят.

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

Если целевой процесс не описан, если новый способ работы не заключен в прочную броню стандарта, то все, что у Вас остается, – знания, которые передаются из уст в уста и со временем искажаются.

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

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

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

3. Стандарт не описан или описан недостаточно подробно.

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

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

4. Нет данных или их слишком много.

У любого процесса есть метрики и показатели (более подробно см. главу 3). Если меняется процесс, то, по логике вещей, должны меняться и метрики. Или хотя бы допуски – значения, при которых мы понимаем, что ситуация ухудшается.

Даже если сотрудники выполняют процесс идеально, нам все равно требуется некая информация, чтобы понимать, как самочувствие пациента.

Представьте себе, что Вы – врач, который может на глаз определить любой требуемый показатель, но при этом не знает, нормально ли то или иное значение? Пациент жалуется на боль в ноге. Вы измеряете его температуру и получаете 36,8. Это нормально или нет? Имеет ли отношение к жалобе или нет?

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

5. Нет плана эвакуации.

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

Только нигде не прописано, что делать в случае, если ситуация начинает ухудшаться. Много раз на защите будущие кандидаты в Черные Пояса проваливались у меня после вопроса: «Ок, ситуация после улучшения снова стала швах. И что делать дальше?» Чаще всего на ухудшение любого из выбранных показателей я получал ответ «надо проанализировать ситуацию» или «соберем совещание». Я так и представляю людей, у которых горит заказ, сломался станок или не вышла половина сотрудников, а у них просто нет готовых процедур на подобный случай [28].

6. Все меняется.

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

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

Давайте посчитаем, уважаемые кроты…

Хорошо, а что же делать? Как противодействовать эффекту затухания? Какие действия нужно предпринимать?

1. Стандартизация. Все решения, какими бы простыми и понятными они бы ни были на Ваш взгляд, должны быть зафиксированы в удобном стандарте.

Здесь очень подходит Стандартная операционная процедура (СОП). По сути это карта целевого процесса только для одной роли с максимально подробным описанием требуемых действий (см. рис. 5).

Рис. 5. Пример Стандартной операционной процедуры (СОП)

На одном из недавних проектов заслуженные сотрудники подняли на смех саму идею СОПов.

– Зачем это нужно? Мы 20 лет делаем эти действия. Ну, поменяли, но и так все понятно.

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

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