Для внедрения процессного управления в компании обычно открывается BPM-проект и создается команда из бизнес-аналитиков и специалистов ИТ-подразделений, а иногда и с привлечением внешних консультантов и разработчиков. И хотя это может показаться странным, именно такой подход может оказаться губительным. Главная причина в том, что сама концепция BPM, в основу которой заложены принципы непрерывности и цикличности, идет вразрез с определением проекта, имеющего четко установленные границы. Другими словами, проект конечен, а BPM нет. Как сочетать одно с другим и реализовать второе без первого?

Цели

Открывая проект BPM, руководство компании не всегда четко представляет, с какой целью создается проект. Цель «внедрить процессное управление» столь же замечательна, сколь и абстрактна — это как «достичь светлого будущего». И задавая подобные цели, с большой вероятностью можно получить деятельность ради деятельности.

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

Специфика процедуры перехода к процессному управлению заключается в том, что это не одноразовое действие, а повторяющаяся последовательность действий, воспроизводящих жизненный цикл процесса, именуемый также циклом PDCA (Play-Do-Check-Act). Поэтому логично представлять внедрение и развитие BPM не как один проект, а как программу из серии проектов, первый из которых начинается с момента принятия решения о внедрении BPM, а каждый следующий будет начинаться по завершении предыдущего. Как правило, один проект BPM связан с одним процессом или какой-то значимой частью сложного процесса. Для каждого такого проекта определяется конечная цель — внедрение (ввод в эксплуатацию) разрабатываемого процесса либо достижение обозначенных для данного процесса показателей.

Почему нельзя обойтись одним проектом BPM? Согласно определению (например, ISO 21500), «проект — это уникальный набор процессов, состоящих из скоординированных и управляемых задач с начальной и конечной датами, предпринятых для достижения цели. Достижение цели проекта требует получения результатов, соответствующих определенным заранее требованиям, таким как время, деньги и ресурсы». Управление само по себе не может быть проектом, и тем более не может иметь ограничений по срокам или ресурсам — нельзя «управлять процессами до 1 января» и нельзя «управлять процессами на 100 рублей». Управление бизнес-процессами — один из способов управления. Создать «проект управления» не позволяют ни проектная, ни процессная методология. А вот концепция постоянного совершенствования как раз позволяет выделить отдельные вехи, нацеливаясь на улучшение конкретных показателей. И каждая такая веха — это один из проектов BPM, поэтому если нужен реальный результат, а не имитация деятельности, то надо создавать проекты с определенными целями и сроками.

Реализация

Первый проект BPM часто называют пилотным, но, несмотря на то что слово «пилотный» иногда ассоциируется со словом «пробный», правильнее было бы считать его не пробным, а начальным, отправной точкой. И именно к пилотному проекту следует относиться с максимальной ответственностью, поскольку от его результатов во многом зависит судьба всех процессных инициатив в организации. Как правило, в первом проекте у команды и у организации еще нет достаточного опыта, поэтому сразу браться за решение сложной задачи опасно — есть риск, что задача либо не будет решена, либо не будет понята и принята заказчиком. Лучшее решение — это разбивать проекты на более короткие и менее сложные. Каждый из проектов разделяется на несколько этапов.

Этап 1 — предпроцессный анализ

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

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

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

Этап 2 — моделирование процесса

Модель процесса включает в себя схему процесса и модель данных (атрибуты процесса) и создается в специальном графическом редакторе, например в Microsoft Visio или в BizAgi Process Modeler. В первоначальном варианте схема процесса должна отражать его текущее исполнение, с устранением явных недостатков. Такой процесс, скорее всего, будет далек от идеала, но на начальном этапе требуется понять, в чем именно его недостатки и где его узкие места. Все улучшения в процессе должны производиться на основании статистических данных, которые могут быть получены только в ходе его многократного исполнения. Стремление создать «идеальный процесс» с первого раза может привести к тому, что он будет так далек от реальных действий исполнителей, что его внедрение станет невозможным.

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

Этап 3 — запуск процесса в эксплуатацию

Модель процесса сама по себе не гарантирует ее исполнения. Маршруты потоков управления могут быть настолько сложными, что контроль исполнения заданий, соблюдения сроков и регламентов будет достаточно трудоемким, а если учитывать, что этот контроль осуществляется руководителем высшего звена, то задача становится слишком дорогостоящей. Вполне закономерно, что исполнение процессов стремятся автоматизировать, используя как программное обеспечение собственной разработки, так и специализированные системы BPMS. Большинство современных BPMS имеют встроенный графический дизайнер процессов, исполнительный движок, средства мониторинга и анализа процессов. Все системы открыты к интеграции с внешними системами. Унифицированных требований к составу компонентов BPMS не существует — обычно этот состав формируется под влиянием рыночного спроса. Единственный стандарт, который де-факто принят большинством ведущих производителей, — это стандарт BPMN (Business Process Model & Notation). BPMS может присутствовать как отдельный компонент в линейке продуктов производителей, предлагающих платформы BPM (Oracle BPM или IBM BPM), или же как отдельный продукт (например, BizAgi BPM Suite). При выборе системы BPMS следует исходить из таких требований: максимальная гибкость при минимальном количестве кода, открытость к интеграции и поддержка стандартов. Продолжительность третьего этапа напрямую зависит от выбора инструмента.

Как правило, автоматизация процесса занимает большую часть времени всего проекта BPM. Частично это связано со временем разработки процессного приложения, но сложнее всего, как показала практика, проходит ввод процесса в эксплуатацию. Этот этап, в свою очередь, подразделяется на два этапа — тестовую и промышленную эксплуатацию.

Тестовая эксплуатация — это режим повышенной нагрузки на исполнителей, когда, помимо основной деятельности, сотруднику приходится осваивать новое программное обеспечение (в случае пилотного проекта) или новую функциональность. Как известно, человеческий фактор всегда является самым опасным для любого проекта, поэтому при внедрении системы или вовлечении новых исполнителей в процесс необходимо создавать условия, при которых сотрудник будет заинтересован в работе с системой. Вопреки официальной версии, согласно которой автоматизация облегчает работу пользователям, на самом деле жизнь некоторых сотрудников может существенно усложниться — автоматизированная система требует аккуратности, организованности, а когда речь идет о BPMS, то еще и дисциплинированности (любые задержки в работе всегда становятся видны руководителю). И если компания не готова к тотальному обновлению штата, то ей следует позаботиться о правильной мотивации: разъяснить сотрудникам цели, показать перспективы, поощрить за достижения.

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

Ввод процесса в промышленную эксплуатацию можно считать завершением проекта.

Результаты

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

***

Управление бизнес-процессами — это уже не дань моде, а осознанная необходимость, и вопрос не в том, есть в организации процессы или нет, а в том, позволите ли вы им оставаться бесконтрольными или будете ими управлять.

Юлия Вагнер (julia@b-k.ru) — директор по продуктам BPM, компания «Бизнес-Консоль», вице-президент ABPMP Russia (Москва).