16 октября 2019 г.
Лирическое вступление
Автоматизация бизнес-процессов организации — тема, набирающая актуальность огромными темпами. Многие компании уже внедрили у себя BPM-системы различных производителей, но еще больше тех, которые только собирается автоматизировать процессы и с интересом впитывает любую информацию по уже реализованным проектам. Существует тренд на автоматизацию процессов со ссылками на успешный опыт иностранных коллег. Но при этом компании, уже внедрившие у себя BPM, часто не ощущают никакого прилива адреналина и иногда даже задают вопрос: «Зачем мы потратили на это деньги?». В данной статье я постараюсь привести примеры основных ошибок, приводящих к разочарованию на пути внедрения процессного подхода в организации.
Основные шаги по внедрению BPM
Давайте рассмотрим цикл Деминга, в приложении к внедрению BPM в компании (см. рис.). Возможно, есть другие способы и последовательности для реализации проектов по автоматизации BPM, но цель статьи — поделиться личным опытом автора и интегратора, успешно завершившего несколько проектов по автоматизации бизнес-процессов в ритейле и крупнейших российских банках. Постараюсь привести примеры и обоснованно показать, как исключение любого элемента из этой схемы приводит к печальным последствиям.
Ошибка 1: отсутствие стадии выявления процесса
Автоматизируем процесс прохождения Заявки.
В компании, привыкшей работать на базе учетной системы, очень часто под бизнес-процессом понимают движение документов между сотрудниками. Например, решили автоматизировать процесс прохождения заявки на командировку. Процесс всем очевидный, и можно сразу перейти к документированию деталей. Следующие шаги тоже не вызовут проблем, и мы благополучно достигнем стадии реализации, имея на руках модель AS IS, а также заключение аналитиков с моделью процесса TO BE. Первые дни внедрения тоже не вызывают вопросов, особенно если на предыдущие шаги было потрачено достаточно времени и средств. Но...
В какой-то момент становится понятно, что решение класса BPMS (BPM-система) крайне неэффективно реализует такой процесс и вообще явно предназначено для чего-то другого и всем мешает.
Проблема в том, что процесса прохождения заявки на командировку не существует. Существует процесс оформления командировки, который состоит из последовательности действий сотрудников, а учетных документов там несколько: заявка, приказ, билет, бронь гостиницы и подтверждение бюджета. Допущенная в самом начале работы ошибка была в том, что мы пытались автоматизировать не процесс, а что-то другое. Поэтому на самом первом шаге необходимо вдумчиво подойти к выявлению процесса и потратить время на выделение самого Процесса из мутных информационных потоков, описывающих деятельность компании. Автоматизация НеПроцесса — один из самых надежных способов разочароваться в BPMS.
Ошибка 2: отсутствие документирования модели AS IS
Зачем тратить время на плохое? Сделаем сразу хорошо!
Экономить на стадии документирования модели процесса AS IS — очень популярная ошибка. Чем же плоха такая экономия? На первый взгляд, надо делать «правильно» и не оглядываться на старые ошибки. Но, к сожалению, «просто правильных» процессов фактически не бывает. В отсутствие модели AS IS мы остаемся без базы для анализа: что хорошо, а что плохо для конкретного процесса в конкретной организации. Приходится опираться на мнение менеджеров, которые хорошо знают потребности бизнеса. Но по факту люди склонны привыкать к постоянным неудобствам, глаз «замыливается», и проблемой считается только новая беда, а старая рана — уже не такая болезненная. Первоначально незадокументированный процесс, который был описан свежим взглядом AS IS, имеет очень слабые шансы получить эффективную модель TO BE. Исключением может являться успешный революционный подход, но о проблемах революционеров я скажу чуть позже.
Ошибка 3: анализ ради анализа
Я знаю что я делаю.
Необходимость стадии анализа мало кто оспаривает. Часто анализ проводится лишь на базе личного опыта и авторитета аналитика. Но анализ эффективности процесса всегда должен основываться на требованиях владельцев процесса. Не сотрудников и менеджеров, а тех людей, которые пользуются результатами процесса. И если в течение предыдущих шагов вы не узнали, что надо именно этим людям — «выгодоприобреталям» процесса, то вас могут ждать очень неприятные сюрпризы в конце пути. Например, при автоматизации оформления командировок все, с кем вы общаетесь, в один голос говорят об уменьшении срока процесса в 2 раза. И ваш личный опыт говорит о том же. Успешно составив модель TO BE и реализовав ее в промышленной эксплуатации, можно ожидать цветов и подарков. Но...
На одном из совещаний приходит HR-директор и говорит, что в принципе срок в 5 дней компанию устраивал, но вот издержки были очень большие и надо бы их уменьшить, а вы сокращаете срок до
Очень серьезной ошибкой на этой стадии является неправильное определение желаний настоящих владельцев процесса. Только их мнение должно учитываться для определения главных критериев и направления работ аналитика.
Ошибка 4: революция вместо эволюции
Сейчас все будет!
Вот мы и добрались до стадии рационального предложения: что надо делать. Очень хочется сделать все и сразу хорошо. Но такой революционный подход таит в себе огромное количество рисков.
Смоделируем ситуацию: вы выявили 10 проблем, которые надо устранить для выстраивания идеального процесса. Можете устранить 1 дефект и реализовать новую версию процесса. Когда осталось 9 проблем, вы решаете запустить еще 1 цикл внедрения и устранить еще 1 дефект. В этот раз на выходе можно получить 12 проблем. Ничего страшного! Через 20 циклов вы почти наверняка получите
Большой ошибкой будет попытка устранить все 10 и сразу. Это может привести к удручающему результату из 20 новых проблем на выходе! Также будет очень трудно определить, какое именно изменение вызвало новую проблему. В дополнение к перечисленным трудностям, на стадии реализации таких больших изменений вы встретите очень серьезное сопротивление со стороны всей компании. Просто довести такие изменения до конца часто становится непосильной задачей. Дальше вспомните, что бывает с революционерами-неудачниками, и хорошо подумайте, насколько оправдан такой подход в вашей ситуации.
Ошибка 5: реализация без автоматизации
Мы тут на ARIS eEPC процессы в Visio описали.
Многие годы люди искали способы, как облегчить внедрение процессного подхода в организации, чтобы стать такой же крутой компанией, как Toyota, но дешевле. Тогда в 1981 году была придумана очень удобная нотация IDEF, а в 1993 году еще более удобная ARIS eEPC. А еще тогда были «джинсы-варенки» и женщины делали «химию».
В 2009 году консорциум OMG, в который входят 800 ведущих ИТ-компаний мира создал нотацию BPMN специально для автоматизации процессов. Ее основным преимуществом является агрегированный опыт огромного количества аналитиков и автоматическое формирование базового кода для автоматизации процессов. Создание нового стандарта привело к постоянному ежегодному увеличению спроса на автоматизацию процессов. Именно этот новый подход и новый стандарт уже 10 лет показывает свою эффективность, так как позволяет оперировать не картинками, а исполнимыми схемами, которые доступны людям из разных сфер бизнеса. Подстраиваясь под BPMN, «ленивым» разработчикам остается делать только свою работу и не задумываться над бизнес-логикой автоматизируемого процесса.
Использование других стандартов не дает таких преимуществ в автоматизации. Для отличных от BPMN нотаций все равно придется писать подробное и детальное техническое задание и надеяться, что разработчики правильно поймут логику конкретного бизнеса, который нужно автоматизировать. Перечисленные выше стандарты устарели, и подход с картинками процессов, Visio, ARIS, джинсами-варенками и химической завивкой использовать 2019 году не стоит.
Ошибка 6: отсутствие контроля = бессмысленный проект
Ура, заработало! Расходимся...
Иногда считают, что результатом проекта по автоматизации процессов является работающий автоматизированный процесс. Нельзя сказать, что это плохо, но такой результат недостаточен для успешного перехода на процессное управление бизнесом.
Если через пару лет начался новый проект по автоматизации того же процесса, значит вы пропустили самое главное — реализацию функции контроля и управления изменениями процессом. Автоматизация процесса является первой половиной задачи автоматизации. Вторая половина — необходимость реализовать возможность мониторинга, сбора статистики, оперативного изменения или версионирования процесса. Фактически целью автоматизации должен являться не сам процесс, а цикл Деминга с рисунка к статье. Автоматизация этого цикла позволит компании поддерживать процессы в актуальном состоянии, а также быстро и эффективно реагировать на внешние изменения. Компании, успешно автоматизирующие цикл поддержки своих процессов, уже не задают вопрос «Зачем мы потратили на это деньги?». А как дела обстоят у вас? Опишите свой опыт автоматизации бизнес-процессов в комментариях.
Заключение
«Одним словом, Панург знал не только, как уже было сказано, шестьдесят три способа добывать деньги, но и целых двести четырнадцать способов их тратить, не считая расходов на замаривание червячка» (Франсуа Рабле. «Гаргантюа и Пантагрюэль»).
Источник: Сергей Новиков, CEO BPMteam
