Что значит «автоматизировать управление бизнес-процессами»

Научная организация труда, система управления качеством, реинжиниринг – процессная наука и практика развиваются под разными флагами уже свыше ста лет. Последняя волна интереса к бизнес-процессам поднялась в начале двухтысячных с появлением концепции BPM (Business Process Management – управление бизнес-процессами), вобравшей все лучшее из прежних наработок в этой области и одновременно давшей ответ на проблемы, которые к этому моменту назрели.

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

Организации, нацеленной на внедрение BPM, предстоит многому научиться: переосмыслить – что такое бизнес-процесс, изменить культуру взаимоотношений между бизнесом и IT, превратив их в партнерские, измерять показатели бизнес-процессов в реальном времени и принимать решения на основе этих показателей и т.д. Все это ради того, чтобы в итоге повысить удовлетворенность заказчиков (а значит, заработать больше денег), оптимизировать операции (сократить затраты, повысить отдачу имеющихся ресурсов) и стать более подвижными, научиться быстро реагировать на возможности, открывающиеся в бизнесе.

Что для этого надо делать? Очертим первые шаги, благо, здесь накоплено достаточно опыта и сформировались стандартные практики, которые рекомендует большинство поставщиков.

1. Повышение собственной компетенции

Делать что-то в области BPM, обладая нулевой собственной компетенцией, – дело рискованное, так как недобросовестный поставщик легко сможет вами манипулировать в своих интересах.

Применительно к BPM организации можно поделить на три категории, в зависимости от масштаба:

1) Малые. Эти компании не могут себе позволить держать в штате выделенного специалиста по бизнес-процессам. Тем не менее, и здесь есть примеры успешных проектов BPM – мотором в них становится кто-то из руководства, например, технический директор.

2) Средние. Могут себе позволить одного выделенного специалиста или небольшую группу специалистов (процессный офис). Зачастую они совмещают роли специалистов по бизнес-процессам и менеджеров проектов (совмещенный процессный и проектный офис).

3) Крупные. Эти организации имеют выделенное специализированное подразделение, например, департамент бизнес-технологий. Помимо специалистов по бизнес-процессам, они могут похвастаться бизнес-архитекторами.

Оцените свои возможности (финансовые и людские), разработайте перспективный план развития процессной компетенции, включающий прием на работу новых и/или переподготовку существующих специалистов. Разработайте программу обучения.

2. Выбор консультанта и поставщика BPMS

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

Если BPM для вас новая область, начините с исследования рынка: проведите поиск в интернете, походите на конференции по BPM, чтобы познакомиться с потенциальным партнером лично. Вам нужна компания, специализирующаяся на BPM-консалтинге (включая разработку, внедрение, обучение), и поставщик программного обеспечения класса BPMS. Предпочтительно получить и то, и другое из одних рук: это может быть компания-разработчик или сертифицированный партнер.

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

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

Несколько рекомендаций по процедуре выбора:

• Не доверяйте выбор IT-подразделению. Его голос обязательно должен быть услышан, но в первую очередь надо учитывать мнение бизнес-технологов, специалистов по управлению бизнес-процессами, бизнес-пользователей.
• Цена, конечно, важный критерий, но выбирать поставщика только по цене – большая ошибка. Компетенция может стоить дорого, но некомпетентность обходится намного дороже.
• Не делайте выбор исходя из числа плюсов в опросной форме. Помните: минус по одному важному критерию перевесит десять плюсов по малозначащим. Определитесь, что для вас критично, а что всего лишь желательно. Прежде чем формировать окончательный список вопросов и критерии оценки, выслушайте потенциальных поставщиков – что они считают самым ценным в своем предложении.
• Выберите одного-двух кандидатов.

3. Демонстрационный пилот (Proof of Concept)

Цель пилотного проекта – в максимально короткий срок получить полную информацию для принятия решения о приобретении системы и запуска ее в промышленную эксплуатацию, то есть избежать покупки «кота в мешке». Ключевое слово здесь – срок, а не функциональность. Обычный срок пилотного проекта BPM – два-три месяца. Не поддавайтесь соблазну расширить рамки пилота, тем самым удлиняя его: помните, что чем дольше длится пилот, тем позже вы начнете получать отдачу от инвестиций в BPM.

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

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

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

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

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

Специфика процессной работы такова, что чем больше вы работаете с процессом, тем лучше понимаете, как он должен быть устроен. Поэтому ТЗ проекта BPM будет меняться в ходе работы. Это может показаться непривычным, но в данном случае это единственно возможный путь.

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

Смету, которую представит поставщик, следует рассматривать как ориентировочную. Так как предполагается, что в ходе проекта может меняться ТЗ, то это повлечет за собой и корректировку сметы. Каждый раз, когда в ходе проекта появляются новые требования, надо либо отказаться от каких-то других требований, чтобы объем проекта остался приблизительно тем же, либо увеличивать смету. Большинство поставщиков выставляют счета и акты не по исходной ориентировочной смете, а по фактическим трудозатратам, исходя из стоимости человеко-часа или человеко-дня. (Это относится не только к пилотному проекту, но и к дальнейшей работе.)

Результатом пилотного проекта будет установленная и настроенная система BPMS и реализованный в ней бизнес-процесс, готовый к опытной эксплуатации.

4. Опытная эксплуатация

Определите круг участников опытной эксплуатации. Как правило, он включает ключевых сотрудников – исполнителей процесса, руководителей, бизнес-технологов.

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

Соберите мнения команды о целесообразности использования системы в промышленном режиме и о желаемых доработках. (Часть доработок поставщик может выполнить прямо в ходе опытной эксплуатации.)

5. Принятие решения

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

6. Запуск в промышленную эксплуатацию

Если на предыдущем шаге принято положительное решение, разработайте план-график следующего этапа проекта BPM, включающего в себя:

• определение числа пользователей на начальном этапе эксплуатации системы и приобретение лицензий;
• развертывание промышленной среды на оборудовании заказчика;
• доработку системы по результатам опытной эксплуатации;
• обучение пользователей;
• выпуск приказа и иные организационные мероприятия, сопутствующие запуску системы.

7. Расширение сферы применения системы

Тактика внедрения BPM строится на цепочке относительно коротких (порядка одного месяца) проектов, в каждом из которых какие-то процессы дорабатываются (оптимизируются), какие-то новые разрабатываются, запускаются в опытную и промышленную эксплуатацию.

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