Работа консультанта по изменениям, а сейчас и членство в жюри конкурса проектов по автоматизации однозначно свидетельствует о том, что не боги горшки обжигают. Автоматизация может быть успешной и тогда, когда делается силами самой компании, и когда для этой цели приглашаются аутсорсеры. И, к сожалению, она может оказаться неуспешной как в первом, так и во втором случае.
Встает вопрос: так в чем же залог успешности автоматизации бизнес-процессов? Отрефлексировав свой опыт, можем сказать, что и компетентность заказчиков, и опыт, и обязательность исполнителей, и вовлеченность руководства – все это необходимо для успешности проекта. Но еще важна и технология, простая и примитивная пошаговая технология продвижения. Сейчас модно говорить об Agile или о Scrum как о том, что вновь появилось на горизонте управления. Однако эти «новинки» являются таковыми лишь для сферы IT, но не для управления изменениями, где и работа в малых группах на общий результат, и постоянные встречи с заказчиком, чтобы сверить часы, и распределенные роли – давно известные моменты. Именно поэтому хочется еще раз напомнить о том, какой же должна быть технология работы по автоматизации бизнес-процессов, которая есть лишь частный случай общего подхода к управлению изменениями.
Шаг 1. Диагностика существующего положения дел
В IT этот этап называется «анализ as is». Результатом этапа должно стать понимание со стороны заказчика и исполнителя, какую часть бизнес-процесса (БП) предстоит автоматизировать. И здесь, конечно же, должны появиться цели по времени, по эффекту, по тем параметрам, которые предстоит улучшить в результате процесса автоматизации. Тут же появляется график и бюджет проекта, распределяются роли его участников. Появляется руководитель проекта, который будет отвечать за намеченные результаты. Кстати, крайне редко эффективными руководителями проектов оказываются айтишники. И самые мудрые из них предпочитают выбирать для себя роль исполнителя, отдавая ответственность за проект руководству компании или бизнес-заказчику.
Шаг 2. Формирование образа будущего
На этом этапе изучается бизнес-процесс «to be» – каким он должен стать. И вот возникает засада: программисты некомпетентны, чтобы сказать, каким должен быть бизнес-процесс. Чтобы это определить, необходимо привлекать либо бизнес-аналитиков, либо использовать компетенции людей бизнеса, бизнес-заказчиков, опыт которых позволяет это сделать. Однако, как показывает практика, в компаниях часто отсутствует и та экспертиза, и другая. И если руководство компании доверяется в этот момент только программистам, проект, скорее всего, будет провален.
Шаг 3. Согласование образа «to be» с подразделениями компании
В первую очередь речь идет об автоматизации тех бизнес-процессов, которые затрагивают несколько подразделений компании, если не все сразу. Даже автоматизация такой простой функции как оформление командировки – и то предполагает участие бухгалтерии, отдела кадров и бизнеса. Что уж говорить о внедрении складских систем или систем управления клиентскими отношениями. Именно на этом этапе рабочие группы становятся основным средством работы. Разнопрофильные команды собираются для обсуждения видения будущего бизнес-процесса, согласуя свои представления о том, каким он должен стать.
Шаг 4. Программирование
Написание программных кодов, как это ни звучит парадоксально, – самый простой процесс в этой работе. Главное, чтобы была правильно поставлена задача, под которую IT-специалисты составляют алгоритм – как повара готовят еду, а машинист ведет поезд. Безусловно, чем грамотнее и опытнее эти люди, тем быстрее они сделают продукт, который можно будет тестировать в реальном процессе.