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

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

Вообще, говоря о плюсах Agile, стоит отметить, что при правильном использовании:

1. Происходит экономия сил, времени и ресурсов.

2. Продукт максимально ориентирован на конечного потребителя.

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

4. Реальные результаты работы видны практически сразу.

5. Принципы достаточно просты для понимания, чтобы в них быстро разобраться.

6. Методология прекрасно работает для разработки ПО.

Про минусы, правда, забывать тоже не стоит:

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

Например, строить мосты по Agile – плохая идея. Если Вы с первого раза установили опору неправильно, очень дорого, а часто просто технически почти невозможно достать ее из грунта и «переставить».

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

3. Алгоритмичных инструментов достаточно мало, в основном речь идет скорее о принципах и опыте их применения для решения различных задач.

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

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

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

Agile, как и любая методология разработки ПО и цифровизации, не может существовать сама по себя. Бессмысленно и бесполезно плодить цифровые решения, пока не будут проанализированы процессы и системы.

Я сам видел как три Agile-команды разрабатывали три приложения для одной и той же проблемы, которая была устранена организационными изменениями без всякой цифры по итогам анализа процесса.

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

6. Разработка процессов: DfLSS (Design for Lean Six Sigma).

Относительно молодая методология. Ее задача – не улучшать, а изначально создавать оптимальный процесс. Во многом она базируется на инструментах лин 6 Сигма, но при этом имеет много самобытных решений.

В Лин 6 Сигма для определения цели улучшения используется простой подход: «спроси клиента и сделай, как он хочет». Чаще всего при этом клиент отвечает, что «все плохо». Следовательно, это «плохо» нужно переводить в измеримые показатели. В Лин 6 Сигма не рассказывается, как это сделать. Рекомендация одна: думайте.

Основным отличием и плюсом в DFLSS является обработка желаний клиентов и определение их наиболее выгодного сочетания друг с другом на основе цифр. Для этого существуют даже специальные инструменты.

Логика подхода состоит в следующем:

1. Сначала определяется процесс, который необходимо разработать, исходя из текущего бизнес-контекста.

2. Собирают требования и пожелания клиентов. Они переводятся в набор измеримых показателей, по которым устанавливаются целевые значения. Потребности, выраженные в показателях, определенным образом ранжируются и соотносятся друг с другом так, чтобы:

a. Пожелания одних клиентов не входили в противоречие с пожеланиями других.

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

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

4. Концепт детализируется до конкретных операций с параллельным анализом и устранением возможных мест низкой эффективности. Происходит тестирование целевого процесса.

5. Создается система контроля и управления вновь созданным процессом.

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

Из плюсов методологии можно отметить следующие:

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

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

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

4. Изначально создает клиентоцентричный, без внутренних потерь процесс.

Говоря о минусах стоит отметить:

1. Сложность в освоении материала. При этом необходимо изначально быть экспертом в Лин 6 Сигма и управлении проектами, в противном случае многое будет непонятно.

2. Сроки проектов могут быть наибольшими из всех перечисленных методологий.

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

Пара слов про данные

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

Но и это еще не самое страшное. Как правило, требуемые цифры не входят в перечень регулярно собираемых метрик: например, длительность шага того или иного процесса или количество продукции, проходящей по конвейеру без доработок с первого раза[19].

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

Однако сообщить о количестве и причинах возврата конкретной модификации продукта, числе дополнительных согласований и среднем времени ожидания на складе никто не смог. Были только показатели, которые демонстрировали «крутизну» менеджеров: объем продаж, количество продаж на сотрудника в филиале и т. д. – и ни одного, который бы помог разобраться с проблемами.

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

Работать с ними было одно удовольствие, и при этом Заказчик смог:

1. Сэкономить, поскольку все данные были доступны и не пришлось нанимать дополнительный персонал для проведения замеров или дорабатывать ПО, чтобы выгрузить требуемую