Как снизить риск при принятии решений в проектах организационных изменений? Автор представит пошаговую инструкцию, а также опыт реальной компании с оценкой эффектов.
1. 70% проектов организационных изменений терпят неудачу: как не попасть в их число?
В современном мире способность к изменениям - ключ к выживанию компании на рынке. Инертность и нежелание меняться чревато в долгосрочной перспективе деградацией и в итоге проигрышем более активным и гибким конкурентам. Однако, по данным McKinsey & Company, 70% попыток проведения изменений в компаниях проваливаются. Разногласия в руководстве компании ввиду отсутствия достоверного плана действий и вытекающее из этого недоверие со стороны сотрудников к принимаемым решениям эту статистику усугубляют.
Причины могут быть разные, однако чёткая программа по проведению изменений, сформулированная и поддерживаемая топ-менеджментом компании, создание у сотрудников ощущения уверенности в завтрашнем дне, привлечение их к выработке решений, и соответствующая компенсация участникам работ по изменениям могут существенно увеличить вероятность успеха. Решения, максимально учитывающие интересы всех сторон и принятые на основе объективных данных, а не исходя из умозрительных заключений, будут с меньшим сопротивлением встречены людьми, которых эти решения затрагивают, да и в команде менеджеров будет больше согласия. Выработка таких решений требует тщательного анализа и проектирования того, как отразятся изменения, сделанные в одной части системы, на остальных её участках и к чему в результате они приведут всю систему в целом (ключевая идея системного подхода к управлению).
Приведу пример из своей области: при оптимизации системы в одном месте, уменьшив количество тестировщиков (цель – пресловутая оптимизация ФОТ), можно ухудшить работу системы в целом: нагрузка на отделы технической поддержки и внедрения будет возрастать, что в итоге приведёт к увеличению расходов по ним. Далее начнётся отток недовольных клиентов, и в результате, вместо экономии, получим не только дополнительные расходы, но и удар по репутации.
Особенно отчетливо риски принятия управленческих решений при внедрении организационных изменений проявляются при усложнении бизнес-системы (увеличение масштаба бизнеса, появление новых продуктов, каналов сбыта и т.д). Элементарно увеличивается количество объектов управления, задействованных в бизнес-системе, их свойств, взаимосвязей и т.д. Этот объем со временем становится настолько большим, что обрабатывать его без средств автоматизации становится невозможно. Для проверки качества управленческих решений уже на этапе их проектирования (а не на этапе реализации!) в данной статье предлагается рассмотреть метод имитационного моделирования.
Обращаю внимание читателей на то, что все методические обобщения и рекомендации основаны на личном опыте использования заявленных управленческих технологий в проектах организационного развития (на примере ИТ-компании).
2. Краткая справка об имитационном моделировании
Метод позволяет виртуально «отработать» некоторый период времени с заданными параметрами деятельности и посмотреть, какие результаты получит компания за этот период.
За исходные данные в имитационном моделировании берутся результаты работы компании за прошедшие периоды. На основе них строится упрощённая модель, представляющая собой макет вашей компании, существующий только в электронном виде. «Работает» такая модель в десятки тысяч раз быстрее, чем ваши сотрудники. Таким образом, вы можете за несколько минут увидеть, как внесённые изменения отразятся на компании в целом и на каждом отдельном подразделении.
Таким образом можно, например, проверить, как предлагаемые решения повлияют на работу компании до начала их претворения в жизнь. Современные системы бизнес-моделирования позволяют провести несколько расчётов с различными параметрами и выбрать наиболее эффективный вариант из предложенных командой руководителей.
3. 8 шагов по совершенствованию деятельности с применением метода имитационного моделирования
Последовательность этапов по оптимизации работы компании представляется таким образом:
| Этап | Краткий комментарий |
|---|---|
| 1. Консолидация информации учётных систем компании | Для «оцифровки» деятельности компании предстоит собрать статистику по показателям процессов на основе учетных данных из информационных систем предприятия |
| 2. Описание процессов компании, создание модели деятельности. Проверка модели на основе данных из учётных систем компании | Для построения модели работы компании, её деятельность необходимо описать. Деятельность в целом можно представить в виде отдельных действий, а их взаимосвязи изобразить в виде схемы. В зависимости от детальности проработки, такая схема может содержать большие блоки, описывающие работы целиком, а может быть расписана каждая отдельная операция. Трудоёмкость описания и анализа бизнес-процессов можно снижать, используя современные системы бизнес-моделирования, предназначенные для автоматизации этой работы. |
| 3. Сбор предложений по оптимизации от руководителей и сотрудников | Технологии и подходы при реализации этого этапа могут быть различными в зависимости от специфики и масштабов деятельности компании. Главное - соблюсти принцип вовлеченности в процесс обсуждения всех заинтересованных сторон. |
| 4. Перепроектирование модели с учетом предложенных организационных изменений | Для оценки того, как предложенные меры скажутся на работе компании, предварительно нужно создать копию текущей бизнес-модели и внести изменения в ней. Для начала стоит рассмотреть изменения независимо по каждому решению, а далее повторить валидацию выбранных решений в комплексе, чтобы учесть возможное влияние их результатов друг на друга (системный подход). |
| 5. Проведение имитационного моделирования для прогнозирования результатов работы компании, и оценка эффекта от предложенных изменений | На данном этапе собственно запускаем «виртуальную» работу компании и оцениваем соответствие результатов моделирования текущим и предыдущим результатам работы фирмы. Проверку результатов моделирования после внесения изменений в бизнес-архитектуре можно сделать, сравнивая эти результаты с прикидками, сделанными при разработке предложений по этим изменениям. |
| 6. Разработка проекта изменений в компании | Тема проведения организационных изменений достаточно обширна, существуют многочисленные рекомендации по организации этого процесса, например, 8 шагов управления изменениями Джона Коттера. |
| 7. Проведение мероприятий согласно проекту изменений | В процесс проведения организационных изменений практически неизбежно Вы столкнетесь с сопротивлением заинтересованных сторон. Однако, чем внимательнее Вы отнеслись к интересам людей на предыдущих этапах, тем выше будет вероятность успеха в этом нелёгком деле! |
| 8. Оценка эффективности изменений. Возврат к п.3. | Когда изменения внедрены, необходимо провести ретроспективу: проанализировать результаты и ошибки, которые были допущены, внести коррективы в модель и в технологии работы по оптимизации. И запускать новый цикл улучшений! |
Для демонстрации актуальности представленной методики приведу пример реализации этих шагов в ходе проекта организационных изменений в компании, специализирующейся на разработке программного обеспечения.
4. Кейс по оптимизации производственного процесса с применением имитационного моделирования
В сфере ИТ бизнес-процессы особенно сложно поддаются описанию, а результаты работы — предсказанию. Это связано с тем, что работа в основном творческая, исследовательская. Однако, благодаря наличию методик распределения и определения порядка выполнения задач, таких как Scrum, появляется возможность описать основные бизнес-процессы. С учетом этой методики нам удалось построить модель ИТ-компании (разработчика ПО) для анализа и поиска путей оптимизации работы. В модели рассматривается параллельный выпуск двух продуктов: продукта для малого бизнеса и корпоративного продукта. В силу объема данной статьи не стану подробно описывать всю модель. Она доступна для всех желающих бесплатно на сайте businessstudio.ru в разделе "Магазин моделей и решений".
Поиск «точек роста»
Итак, основные процессы по созданию, продаже и поддержке продукта (с характеристиками ресурсов, плановыми оценками трудоемкости отдельных операций, параметрами производительности и т.д.) были построены в системе бизнес-моделирования на основе статистики сложности выполнения работ, полученной из корпоративных информационных систем. А для учёта нестабильности в сложности решаемых задач, в длительность выполнения многих работ в рассматриваемой модели введена случайная величина с законом распределения, заданным, исходя из тех же статистических данных.
Рассмотрим подробнее как имитации деятельности компании в системе бизнес-моделирования позволила выявить скрытые резервы повышения эффективности. Так на диаграмме Ганта, описывающей состояние компании «до оптимизации» видны уровни загрузки сотрудников и подразделений, периоды работы и простоя ресурсов компании. В примере ниже видно, что разработчики продукта между завершением работ по разработке продукта и началом работ по отладке продукта длительное время не заняты.
Результаты загруженности по видам работ до оптимизации:
Виден большой промежуток времени в 10 дней между завершением этапа разработки продукта и началом этапа отладки продукта, в который разработчики продукта оказываются не заняты на текущем проекте. Желательно их как можно скорее загрузить работой по исправлению ошибок, чтобы сократить время на переключение между задачами и исправить их «по свежим следам» быстрее.
Программа изменений
На основе модельных данных был проведен расчет экономического эффекта от различных вариантов оптимизации бизнес-процессов с использованием имитационного моделирования. Перечислю только те варианты оптимизации, которые были выбраны как наилучшие по результатам сравнения планового эффекта от них.
- Сократили ожидание готовности новой версии платформы и библиотек, и вместо ожидания завершения проверки результатов тестирования руководителем соответствующего подразделения, сделали этот отчётом уведомлением;
- Изменили приоритет операции «Описание ошибки» так, чтобы не сначала выполнялось тестирование, а только по его завершению описывались ошибки и передавались разработчикам на исправление, а по мере нахождения ошибок их сразу начинали исправлять;
- Добавили одного дополнительного тестировщика;
- Дали разработчикам больше времени на самостоятельное исправление ошибок в реализованном функционале до передачи на тестирование. Это уменьшило вероятность обнаружения ошибок в процессе тестирования и соответственно продолжительность процесса тестирования и исправления.
Полученные результаты
Ниже показаны результаты имитации по тем же видам работ после проведения программы изменений:
Из сравнения диаграмм видно, что интервал между завершением разработки продукта и началом его отладки сократился на 1 неделю и 1 день (в 4 раза) по сравнению с неоптимизированным бизнес-процессом.
Промежуток с начала работы над разработкой продукта для малого бизнеса и до завершения разработки, включая отладку продукта, библиотек и платформы, сократился на 12%.
Далее приводится расчет полученного эффекта в денежном эквиваленте:
Уменьшение простоя разработчиков продукта для малого бизнеса при неизменности их количества составило 12% на одну версию (2 месяца разработки) на одного сотрудника. Что в расчёте на всех 11 сотрудников отдела и в пересчёте на месяц при ФОТ сотрудника 200 000 рублей в месяц составило:
11 человек * 12% * 200 000 руб. = 264 000 рублей.
Для отдела разработки корпоративных продуктов такая же оптимизация даст экономию в месяц:
18 человек * 12% * 200 000 руб. = 432 000 рублей.
ФОТ добавленного тестировщика составит 160 000 руб.
Суммарная экономия в месяц:
264 000 + 432 000 – 160 000 = 536 000 руб.
Выражаться она будет в более частом (на 12% чаще: 1 месяц и 3 недели по сравнению с 2 месяцами) выпуске новых версий продуктов, а также в снижении стоимости выпуска каждой новой версии.
В рассмотренном выше примере, в результате моделирования мы имели возможность проверить, что при полученной экономии выполнено необходимое количество требований пользователей и успешно выпущена новая версия продукта. Также, для проверки того, что изменения не приведут к накладкам при продолжительной работе, мы провели моделирование на более длительном промежутке времени и убедились, что работа компании сохраняет стабильность, а экономия в рамках рассмотренного отдела также приводит к экономии в работе всей компании в целом.
5. Вместо заключения
Наш опыт по применению имитационного моделирования показал, что этот метод позволяет спрогнозировать работу компании в будущем, что помогает в выработке обоснованных управленческих решений. Использование этого инструмента в условиях ограниченных затрат позволяет находить пути оптимизации деятельности, максимально полно учитывающие особенности взаимосвязей всех процессов компании.
По результатам проекта организационных изменений с применением имитационного моделирования нам удалось отметить для себя следующие успешные практики:
1. Оптимизация бизнес-процессов за счет улучшения их структуры
Когда наглядно виден весь процесс, легче отслеживать его проблемные места, а найти проблему — это, как известно, наполовину её решить. Как вариант, при помощи усиления дополнительным сотрудником, можно избавиться от узкого места и тем самым повысить эффективность работы компании в целом.
2. Бенчмаркинг бизнес-процессов
Так, мы смогли реструктурировать бизнес на основе сравнения внутренних бизнес-процессов и аутсорсинга, и выбрать более эффективные варианты исполнения процессов. Часто менеджеры избавляются от тех процессов, в которых не разбираются или которыми просто не хотят заниматься, а не от тех, которые действительно эффективнее передать более компетентной в этом деле фирме. Использование объективных оценок позволяет реструктурировать бизнес и выполнять перераспределение ресурсов на более эффективные направления, с меньшими рисками улучшая его показатели.
3. Снижение рисков принятия решений при наличии большего объёма информации
Уменьшение рисков управленческих ошибок тесно связано с проверкой правильности выбранных методик, сделанных предположений и построенной модели. Очевидно, что модель компании - это упрощение, она строится, опуская многие детали, в частности, психологию людей. Также очевидно, что в модели могут содержаться ошибки. Поэтому слепо доверять результатам моделирования не стоит. Но и бояться ошибки в модели не нужно, — нужно уметь проверять результаты моделирования!
Также в результате выполнения этого проекта мы получили еще один сторонний результат, не связанный непосредственно с имитационным моделированием:
4. Снижение себестоимости выполнения бизнес-процессов за счет регламентации
Это еще один результат, не связанный непосредственно с применением имитационного моделирования, но полученный в ходе проекта. Когда работа описана в виде подробной инструкции, её может выполнять менее квалифицированный работник или даже, как упоминалось выше, робот. Это один из способов снижения себестоимости при выпуске продукции крупными партиями.
Опубликовано по материалам Журнал «Business Excellence» — № 6 (июнь) 2017
Июнь 2017 г.
Поделиться: