На блоге Gartner появилась заметка Janelle Hill “Do You Understand the Difference Between Workflow and BPM?“. Как замечено в комментариях, это хороший ответ тем, кто считает, что “BPM - это Workflow на стероидах”.

По мнению Gartner, идеальная BPMS реализует 10 технологий, из которых Workflow - всего лишь одна:

1. Процессный движок (Process Execution and State Management Engine) - компонента, реализующая Workflow.
2. Среда разработки, основанная на графических моделях (Model-Driven Development Environment). Но в workflow-системах тоже обычно есть графические средства моделирования. Менее мощные (обычно только оркестровка без хореографии), не следующие стандартам (BPMN), но есть. Получается не 1/10, а 2/10.
3. Управление документами и контентом (Document and Content Management). Спорно. На мой взгляд, есть структурированные данные, есть неструктурированный контент и есть процессы, и для управления ими придуманы, соответственно, DBMS, ECM и BPMS. Без необходимости границы лучше соблюдать, ничего не следует  делать “заодно” - ни управлять контентом в BPMS, ни управлять процессами в ECM. Мы же не включаем в BPMS управление данными, не дублируем DBMS - почему с контентом должно быть по-другому? 2/9.
4. Средства совместной работы пользователей и групп (User and Group Collaboration). Да, конечно, но рассматривать это как часть BPMS? А что, совместной работы вне процессов не бывает? Конечно бывает, например, в проектах. Получается, для процессов свои средства совместной работы, а для проектов - свои? Абсурд. 2/8.
5. Средства интеграции (System Connectivity). Действительно, в BPMS работа, выполняемая людьми, работа с документами и действия, выполняемые автоматизированными системами, трактуются единообразно, без перекоса в сторону первых (что характерно для систем human workflow) или вторых (системы docflow). Кстати, пункты 3 и 4 я бы поместил сюда - в виде средств интеграции с системами управления контентом и средствами совместной работы.
6. Бизнес-события, бизнес-аналитика и мониторинг (Business Events, BI and BAM). Строго говоря, к BPMS относится только последнее, а первые два могут использоваться независимо.
7. Имитационное моделирование и оптимизация (Inline  and Offline Simulation and Optimization). Похоже, только Gartner знает, что они имеют в виду под “inline and offline”, но по существу возражений нет.
8. Машина бизнес-правил (Business Rules Engine). В теории она может использоваться как единое хранилище глобальных переменных любой (лучше каждой) корпоративной системой. Но на практике в основном используется BPMS.
9. Средства управления и системное администрирование (System Management and Administration). В том или ином виде это есть в любой системе: 3/8.
10. Каталог-репозиторий процессных компонент (Process Component Registry/Repository). С одной стороны, в Workflow-системе тоже можно найти каталог процессов в том или ином виде. С другой стороны, репозиторий процессов в рамках BPMS, в отрыве от репозитория сервисов SOA, тоже не лучшая идея. 4/8.

Итоговый счет у меня получился не столь разгромный - 4:8, а не 1:10. Но сама идея подсчета очков порочна: на чашу весов BPM есть что положить кроме технологий. Прежде чем сравнивать BPMS с Workflow, надо сказать, что BPM != BPMS. BPM - это:

1. Методология: иерархия целей организации, цепочка создания ценностей, сквозные бизнес-процессы, выявление процессов, цикл непрерывного усовершенствования.
2. Реализация: программа, понимаемая как серия проектов; гибкая разработка (agile).
3. Технология (BPMS).

Если нет компетенции в методологии или реализации, проект BPM обречен даже с самой лучшей BPMS.

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

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

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

• Непрерывное улучшение? Ерунда, надо тщательнее проектировать, а главное - тщательнее составлять требования!
• Схема процесса? Настоящая программа - это код, а не “стрелки-квадратики”.
• Наше дело автоматизация, а что именно автоматизировать пусть скажет бизнес.
• Гибкая разработка? Наши пользователи не согласятся работать с системой, в которой нет всего что им нужно.

И поскольку Workflow - это только технология, то с ним им гораздо комфортнее, чем с непонятным, разрекламированным и переусложненным (с их точки зрения) BPM.

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

Так что сложность не в BPM - сложность в бизнес-процессах. Сложность BPM адекватна сложности бизнеса, а сложность Workflow - недостаточна. А так как сложность управляющей системы не может быть меньше сложности управляемой, в случае Workflow задача трансформации бизнеса неизбежно редуцируется до задачи автоматизации канцелярии.

Возвращаясь к технологиям, я бы не сказал, что BPMS кладет Workflow на лопатки. Но это ему и не нужно, потому что тут есть еще один важный аспект: BPMS - это следующее поколение технологий. XML и Интернет, тонкий клиент, современные стандартные платформы (J2EE или .NET), стандартные нотации (BPMN, BPEL) вместо проприетарных. В быстро меняющемся мире ИТ даже относительно небольшое технологическое отставание фатально: если основная масса разработчиков начинает воспринимать какое-то направление как устаревшее, то оно достаточно быстро маргинализируется просто потому, что никто добровольно с ним работать не хочет. Поэтому нравятся вам Workflow-системы или нет - останутся жить только те из них, которые смогут влиться в мейнстрим: перейти на современную платформу, сменить нотацию, добавить недостающие функции из списка Gartner, т.е. превратиться в BPMS.

Первыми использовать BPM начали банки и телеком. Насколько опыт этих пионеров полезен другим отраслям?

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

В цеху тоже есть процессы - производственные. Но у них несколько иная проблематика, иные методы и технологии: станки с ЧПУ, поточные линии, АСУТП… Зато здесь нет проблем кросс-функциональных процессов - ведь это одна служба. Тут требуется не BPM, а производственная автоматика и робототехника.

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

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

Поскольку одной автоматизированной системой обойтись не получается, и к тому же необходимо взаимодействовать с системами других банков, в банковском “цеху” появляются процессы, понимаемые как координация действий, выполняемых в различных системах. Человек в них или вовсе не участвует (STP - straight-through processing), или только разбирается с относительно редкими исключительными ситуациями.

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

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

Так сложилось, что и системы, используемые для управления специфическими процессами в “цехах” банков и телекомов, и системы, предназначенные для “заводоуправлений”, называют BPMS. Это устраивает вендоров, избравшим для себя стратегию: сначала сделаем продукт, который банки у нас точно возьмут, а потом постараемся приспособить его для остальных.

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

Я не хочу сказать, что все внедрения в банках и телекоме таковы. Например, классика банковского BPM “выдача кредита физическому лицу” в части приема и рассмотрения заявления - типичный процесс “заводоуправления” с множеством исполняемых людьми шагов, сложной логикой; продолжительный, но с относительно низкой интенсивностью. После того, как выдача кредита одобрено и подписан договор, процесс продолжается в “цеху” - информация записывается в информационные системы, клиенту шлется уведомление по SMS и т.п.

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

Налицо путаница в классификации программных средств, используемых для управления бизнес-процессами:

• Инструментарий Enterprise Architecture (EA) предназначен для моделирования следующих аспектов корпоративной архитектуры:
  1. бизнес-архитектура - бизнес-цели, организационная структура, функции, процессы, роли и т.д.
  2. архитектура приложений - корпоративные системы и их интерфейсы
  3. архитектура данных - логическая и физическая
  4. технологическая инфраструктура - программно-аппаратное обеспечение и сети
• Инструментарий Business Process Analysis (BPA) в части моделирования является подмножеством EA, покрывая полностью или частично бизнес-архитектуру. Но, помимо моделирования, может содержать специализированные средства, например, имитационное моделирование бизнес-процессов или статистический анализ результатов исполнения.
• Business Process Management Suite (BPMS) в обязательном порядке включает моделирование бизнес-процессов, их исполнение (process engine, процессный “движок”) и мониторинг/анализ. Опционально может включать имитационное моделирование, движок бизнес-правил и многое другое.
• Некоторые вендоры используют для своих продуктов определение “BPM Software”. Обычно это означает, что система не дотягивает до BPMS - например, в ней нет исполняемого движка - но маркетинг хочет видеть в названии BPM.

Апологеты BPMS (я в том числе) верят в силу исполняемых бизнес-процессов, в принцип “what you model is what you run”. Соответственно, наличие процессного движка для них - необходимость, и EA инструментарием они обойтись не могут.

С другой стороны, корпоративные архитекторы не представляют, как можно оперировать бизнес-процессами в отрыве от организационной структуры и архитектуры приложений. И хотя многие BPMS позволяют моделировать организационную структуру, роли, внешние системы, все это делается фрагментарно, на уровне “проекта” - т.е., фактически, одного логического процесса (физически процессов в проекте может быть несколько), не покрывая организацию целиком. Следовательно, обойтись BPMS архитектор не может.

Как быть? Может это временные трудности, и через некоторое время либо BPMS дорастут до EA, либо EA включат функциональность BPMS?

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

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

1. изобразили BPMN-диаграмму средствами EA
2. дальше возможны два варианта:
   • если BPMS непосредственно исполняет BPMN, выполнили экспорт-импорт через XPDL
   • если BPMS поддерживает BPEL, выполнили трансляцию BPMN->BPEL

Например, нарисовали в ARIS - экспортировали в WebMethods. Или нарисовали в Casewise - транслировали в Oracle BPEL.

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

Что это означает на практике? После того, как схему процесса загрузили в BPMS, разработчик должен внести в нее правки и уточнения, необходимые для исполнения процесса движком. Но исходная схема процесса в EA тоже не остается неизменной - аналитик продолжает ее совершенствовать, ведь за это, собственно, мы и боролись! (Подробно эта проблематика рассмотрена в серии заметок на блоге Keith Swenson, начинающейся с “Model Strategy: Preserving vs. Transforming“. Русский перевод на bpms.ru.)

Таким образом, надо либо уметь передавать подробности физической реализации процесса в BPMS назад в EA и находить для них место в репозитарии (т.н. проблема “round-trip”), либо уметь объединять изменения, выполняемые в одной и в другой схемах (по образцу branch merging в системах контроля версий). Теоретически задача может быть и разрешима, но по факту за много лет решить ее не удалось. Будем ждать?

Предлагаю принять за аксиому, что:

1. водораздел между EA и BPMS есть и останется в обозримом будущем
2. удовлетворительной автоматической передачи артефактов между ними нет и в обозримом будущем не будет

Возникает вопрос: где следует проводить этот водораздел? Проводить его можно по-разному, так как инструментарии частично перекрывают друг друга. Очевидно, лучше там, где объем передаваемой информации будет минимальным.

Предложение: проводить его на уровне процесса -

• цепочка создания ценностей (value chain) и межпроцессное взаимодействие через события и/или данные моделируются средствами EA
• внутренняя логика процесса моделируется средствами BPMS

Тогда передавать из EA в BPMS придется только номенклатуру и интерфейсы процессов, а для этого автоматический экспорт-импорт не нужен, можно обойтись экспортом-импортом “через принтер”.

Бизнес-аналитик должен провести для себя красную черту: не использовать EA для моделирования бизнес-процесса при наличии BPMS.

Впрочем, для средств моделирования BPMN в EA тоже есть применение. Современные BPMS нацелены на моделирование внутренней логики процессов (оркестровка) и плохо подходят для моделирования межпроцессного взаимодействия (процессная хореография). Но одной оркестровкой можно решать только задачи уровня “автоматизации канцелярии”; как только вы поднимаетесь на уровень сквозных бизнес-процессов - т.е. процессов, за которыми стоят реальные деньги - вам не обойтись без хореографии. (См. на эту тему анти-паттерн “Оркестровка сквозного процесса”.)

Моделировать межпроцессное взаимодействие предлагается средствами EA, используя для этого т.н. “black box BPMN diagram” - технику моделирования, в которой каждый процесс отображается как пустой BPMN pool. Взаимодействие через сообщения моделируется при помощи message flow, взаимодействие через данные - при помощи association.

BPMN-диаграмма межпроцессного взаимодействия, создаваемая средствами EA, может выглядеть так:

Для каждого процесса на диаграмме вверху средствами BPMS создается BPMN-диаграмма, раскрывающая внутреннюю логику процесса:

Мне представляется, что роль KPI в проектах BPM преувеличена.

Распространенная точка зрения: если вы не замеряли показатели бизнес-процесса до выполнения проекта BPM, то вам не с чем будет сравнивать полученный результат, и следовательно, будет трудно доказывать эффективность проекта. В недавней заметке на Process Maker Blog “Top 3 BPM Software Pitfalls to Avoid” отсутствие контрольных замеров KPI названо самой распространенной ошибкой проектов BPM. В то же время в следующей заметке Process Maker Blog на эту тему “Are KPIs Necessary for BPM Success?” Ami пишет: “I imagine that a BPM project can be wildly successful without KPIs”. Что, с точки зрения формальной логики, означает отрицательный ответ на поставленный вопрос - KPI не является необходимостью.

Так в каких же именно ситуациях KPI не является необходимостью?

1. Если ставится задача не тонкой настройки процесса, а трансформации бизнеса

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

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

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

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

2. Если речь идет о запуске, а не о развитии проекта BPM

Когда речь заходит о KPI и о BAM, мы обычно говорим заказчикам: “чтобы дело дошло до аналитики, сначала нужно очень серьезно поработать”.

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

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

Правда, при рассмотрении более широкого контекста возникает вопрос: на что лучше направить усилия процессной команды - на дальнейшее “вылизывание” этого процесса или на то, чтобы заняться другим, в котором еще “конь не валялся”?

3. Если у компании проблемы с управляемостью

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

Тормоза и руль - это прямой канал управления, а спидометр и показатель остатка топлива - обратный. Прямой канал управления важнее обратного. Если у вас нет претензий к тормозам и к рулю, то можно порассуждать об эргономике приборной панели. Если такие претензии есть - никакой дизайн панели не спасет. А как вы оцениваете качество тормозов - замеряете тормозной путь? Да нет же - по ощущениям: “держат - не держат”.

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

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

4. Если первоочередной целью проекта является выявление бизнес-процесса

Как-то один знакомый директор поделился: “Понимаешь, бизнес вроде идет, но я все меньше понимаю как мы работаем. И это начинает меня беспокоить.”

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

Выявление бизнес-процесса - это точная наука и при этом увлекательнейшее занятие. От “happy path” к разбору нестандартных ситуаций, от примитивных блок-схем к взаимодействию асинхронно протекающих бизнес-процессов и пониманию механики взаимодействия различных служб внутри компании. Это не “to be” и не “as-is”, это “as really is”.

Практика доказала, что есть только один способ получить схему процесса “as really is” - исполнять то, что нарисовано. “What you model is what you run”  - это принцип работы BPM-системы. Простое же “рисование” схемы процесса - бесплодное занятие. Для сертификации по ISO годится, для принятия управленческих решений - нет.

Что может быть хуже отсутствия карты местности для военачальника? Только карта с ошибками.

5. Если руководитель непосредственно вовлечен в проект

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

Что может дать KPI такому руководителю? Во-первых, KPI дает информацию только о прошлом и о настоящем. А его интересует будущее. Во вторых, связь между KPI и итоговыми показателями не очевидна. Например, как упомянутая выше доля выполненных в срок заказов повлияет на прибыль? Или хотя бы на долю рынка?

Для контраста, случай из нашей практики. На совещании по результатам пилотного проекта BPM директор сказал: “За то время, пока мы выполняли проект, три заказа, которые по всем признакам должны были стать убыточными, стали прибыльными.” (Оптимизированный бизнес-процесс гарантировал точность калькуляции и быстроту составления спецификации, что для них является ключом для успешных переговоров с заказчиком.) Думаете, его убедили бы KPI? Сомневаюсь.

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

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

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

Оценивать BPM только исходя из сиюминутного выигрыша - а именно к этому подталкивает использование KPI - фундаментально неверно.

Резюме

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

Кто-то может возразить: “но если KPI - вещь полезная, то зачем от него отказываться, хуже ведь не будет”. Именно что будет хуже. Заниматься чем-то ненужным можно только за счет того, чтобы не заниматься чем-то нужным. Время в проекте BPM - ценный ресурс; неоправданные задержки приводят к потере энтузиазма заинтересованных лиц. Проект начинает тормозить, в результате еще сильнее снижается энтузиазм и т.д.

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

Пример:

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

В рассматриваемом примере мы как минимум должны предусмотреть три варианта:

1. платеж поступил
2. покупатель уведомил об отказе от оплаты
3. платеж или отказ не поступил в указанный срок

В BPMN специально для такой ситуации предусмотрена конструкция под названием “исключающая развилка, управляемая событиями” (exclusive event gateway):

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

К большому сожалению, поставщики BPMS склонны относиться к event gateway как к излишеству. Мне известно несколько систем, разработчики которых декларируют приверженность BPMN, но не поддерживают эту конструкцию.

Боюсь, это ошибка с их стороны - ведь задача обработки альтернативных сообщений никуда не денется! В отсутствие event gatway единственный путь - использовать параллельную развилку (parallel gateway). Но тут возникает проблема “гашения” остальных путей при приходе одного из сообщений, которую приходится решать при помощи искусственных конструкций в диаграмме и/или написания программного кода. Конечно, ни о визуальной наглядности процесса, ни о следовании стандарту речь при этом уже не идет.

Таким образом, рассматриваемый антипаттерн необычен тем, что источник его - не процессный аналитик, а разработчик BPMS. С другой стороны, в силах поставщиков BPMS сделать так, чтобы этот антипаттерн исчез - для этого им достаточно изменить свое отношение к поддержке event gateway.

Пока конкретная BPMS не поддерживает event gateway, нормально работать с сообщениями (message flow) в ней невозможно. Оркестровка в ней поддерживается, хореография - нет. На мой взгляд, такая система - это старый добрый workflow вне зависимости от наличия на нем лэйбла BPMN.

Извините за самонадеянность, но хочу дать несколько советов компаниям, у которых есть стремление к совершенствованию и ресурсы, чтобы это стремление реализовать.

Я вижу, как руководители, задумывающиеся о возможных путях усовершенствования для своей компании, буквально подавлены огромным числом разнообразных концепций, стратегий и рецептов в области бизнеса и менеджмента. Чтобы оценить масштаб стоящей перед ними проблемы выбора, взгляните на страницу Википедии с обзором современных бизнес-стратегий. Что лучше, что даст максимальную отдачу на инвестированный рубль - система Тойоты? процессное управление? ERP? CRM? система сбалансированных показателей? или может быть, какая-то из десятков других альтернатив?

Причем многочисленность возможных путей усовершенствования - это только часть проблемы. Плохо еще и то, что все эти концепции и методологии не укладываются в единую картину. Как правило, гуру менеджмента не любят очерчивать границы своих концепций и распространяться о смежных дисциплинах. Агрессивно и напористо каждый “продает” свой рецепт как всеобъемлющий и единственный заслуживающий внимания.

К чему это приводит?

• Синдром буриданова осла: руководитель, склонный к перфекционизму, впадает в ступор и не предпринимает ничего, так как он не в состоянии сделать оптимальный выбор.
• Синдром “серебряной пули”: руководитель с авантюрной жилкой принимает за руководство к действию первую теорию, которая его “зацепила” и для реализации которой хватает ресурсов. Что, в общем, является стратегией лучшей, чем первая. Побольше лидерских качеств и здравого смысла, поменьше фанатизма - и практически с любой теорией можно добиться успеха.

Для сравнения посмотрим на смежную область программного обеспечения для бизнеса и ИТ-консалтинга.

ИТ-шников тоже есть за что критиковать, и их обещания тоже надо делить на 4 (если не на 16), но есть существенное отличие: информационные технологии структурированы. Есть общепринятый т.н. стэк информационных технологий, который выглядит примерно так:

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

Но ведь примерно это зачастую происходит при выборе концепций бизнеса и менеджмента! Поэтому для них крайне полезно ввести понятие стэка управленческих компетенций. (Мне кажется, термин “компетенция” тут более уместен, чем “технология”, поскольку в бизнесе и менеджменте по сравнению с ИТ сильнее гуманитарная составляющая.)

Некоторые примеры:

• управление отношениями с клиентами, производственное планирование, бюджетирование находятся на уровне функционального управления (относясь к продажам, производству и финансам соответственно)
• BPM находится на уровне процессного управления (не путать с программным обеспечением BPMS, которое принадлежит уровню промежуточного программного обеспечения стэка ИТ)
• система Тойоты, Lean, Шесть сигм и Теория ограничений находятся на уровне концепций

Взаимосвязь между уровнями тут та же, что и в ИТ: нижний уровень без верхнего лишен смысла, верхний без нижнего - технологичности.

• Глядя сверху-вниз, нижний уровень является для верхнего обеспечивающим. Это “приводной ремнень”, преобразующий абстрактные идеи в конкретную деятельность конкретных людей, тем самым доводя эти идеи до практического результата.
• Глядя снизу-вверх, верхний уровень - это то, что придает смысл деятельности нижнего уровня и повышает его отдачу.

Проиллюстрирую эти взаимосвязи примерами:

• Нормальная компания не может существовать, если она не обладает компетенциями в области продаж, производства или оказания услуг (функциональный уровень).
• Компании, достигшей определенного размера и уровня зрелости, необходимо прилагать дополнительные усилия для координации деятельности функциональных подразделений в рамках сквозных бизнес-процессов или проектов (уровень процессного и проектного управления). Иначе функциональные подразделения все больше и больше начинают работать не на клиента, а на себя.
• Теория цепочки создания ценностей (уровень концепции) задает цель для проектов в области бизнес-процессов (уровень процессного и проектного управления). Дело ведь не только в том, чтобы все делать как положено и без простоев (”do things right”), но и в том, чтобы делать то, что востребовано (”do the right things”). Процессное управление, лишенное концептуального уровня, тяготеет к тому, чтобы бесконечно шлифовать бизнес-процесс, не задаваясь вопросом - а то ли вообще этот процесс дает на выходе?
• Теория ограничений (уровень концепции) предлагает алгоритм (”пять шагов”) поиска и выбора такого бизнес-процесса, усилия по повышении производительности которого дадут максимальную отдачу с точки зрения итоговых показателей компании, т.е. прибыли в настоящем и в будущем. Без концептуального уровня процессная инициатива вырождается, например, в анализ и моделирование бизнес-процессов на шести уровнях иерархии - занятие само по себе увлекательное, но бесплодное с точки зрения итоговых показателей.

Итак, компетенции нижних уровней обеспечивают реализацию компетенций верхних уровней. Уместен вопрос: а есть ли польза от компетенций верхних уровней в отсутствие нижних?

Полагаю - есть, но ограниченная:

• Вы можете начать внедрять процессное управление, не имея полноценного управленческого учета, но ваши успехи на этом пути окажутся ограниченными (если вообще они будут): вы быстро выясните, что любой бизнес-процесс оперирует бизнес-объектами, поддерживаемыми базами данных и корпоративными системами. Например, если вы возьметесь за процесс “от обращения до заказа”, не имея CRM-системы (обеспечивающей функциональную компетенцию), то через некоторое время вы обнаружите, что в рамках проекта BPM вы разрабатываете собственную CRM-систему. (Что, кстати, иногда бывает оправдано, но все же надо отдавать себе отчет, что собственная разработка, скорее всего, будет уступать готовым CRM-системам по функциональности.) BPM - это в основном для тех, у кого ERP и CRM уже есть, а счастья еще нет.
• Вы можете начать внедрять Lean, не обладая компетенцией в области процессного управления. В этом случае вы можете добиться успехов на уровне отдельных подразделений, но при попытке распространить эту методологию на компанию в целом у вас возникнут проблемы, так как ключ к разрешению противоречий между подразделений - это кросс-функциональные бизнес-процессы и BPM.

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

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

Вероятный сценарий:

1. Предположим, что некая компания A добилась впечатляющих успехов в трансформации своего бизнеса. Сведения об этих успехах стали достоянием публики.
2. Консультанты, принимавшие участие в проекте компании A, обобщили опыт, превратив его в новую методологию X, и стали интенсивно рекламировать себя и методологию X, действительно принесшую успех компании A. Примерно по этой схеме появились на свет TQM (Ксерокс), Lean (Тойота), Шесть сигм (Моторола).
3. Компания Q решила воспользоваться методологией X и повторить успех компании A. Но книги, посвященные X, достаточно скупо освещают необходимость ее обеспечения компетенциями Y и Z - во-первых, потому, что для компании A это слишком очевидно, чтобы об этом говорить, а во-вторых, любые предварительные условия негативно отразятся на продажах услуг, связанных с X.
4. В результате проект компании Q проваливается. Успех A и провал Q объясняется тем, что у A наличествовали компетенции нижних уровней, а Q решила не тратить время на их приобретение, а идти к “успеху” кратчайшим путем.

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

Резюмируя, обещанные рекомендации:

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

В бизнесе нельзя мыслить только одноходовками - иногда надо просчитывать комбинации, как в шахматах. Думать не только о выигранном материале (сегодняшних прибылях), но и о позиции (приобретении базовых компетенций), и о темпе (способности бизнеса быстро перестраиваться).

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

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

Но, подозреваю, главный вопрос - как быть, если жизнь берет за горло? Что ж, “выживают только параноики”. У остальных вечно получается так, что сначала слишком рано, а потом вдруг уже слишком поздно.

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

Следующие заметки развивают предложенную концепцию стэка управленческих компетенций:

• Отделить бизнес-методологию от процессной дисциплины
• Прямой и обратный каналы управления
• Выбор между компетенциями одного уровня
• Собственная или заемная компетенция
• Разрыв между бизнес- и ИТ-консалтингом

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

А возник он потому, что я не в первый встречаю компанию-заказчика или потенциального заказчика, во главе которой стоит молодой, амбициозный, энергичный и - что самое главное - грамотный руководитель. Казалось бы, здорово! Действительно радует, что не приходится тратить время на рассказ о том, что такое бизнес-процессы и BPM - человек уже подготовлен, в том числе благодаря нашему bpms.ru.

Но потом сталкиваешься с проблемой: руководители такого типа склонны не ставить задачу, а диктовать решение. Мы ожидаем, что нас позвали разобраться с проблемой и предложить решение, а оказывается, на нас смотрят как на “автоматизаторов”.

» читать дальше

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

Пример 1: процесс заключения договора. Ближе к завершению процесса договор должен быть подписан с нашей стороны директором:

Хотя бы из уважения к директору дайте ему возможность не подписать договор - предусмотрите развилку (gateway) сразу за шагом “подписать договор”.

Пример 2: в процессе выполнения заказа клиента компания-посредник размещает заказ у партнера:

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

Тут возникает вопрос меры: с одной стороны, никто не отменял рекомендацию начать моделирование процесса с т.н. “happy path” - максимального гладкого варианта протекания процесса. И в happy path приведенные диаграммы вполне уместны.

С другой стороны, а бывают ли вообще шаги с предопределенным результатом - может быть, надо проверять результат работы после каждого шага?

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

BPM осваивает новую территорию, которую называют по-разному: dynamic processes, unstructured processes, knowledge worker processes, barely repeatable processes, case management. (На русский не перевожу - так как термины относительно новые, перевод только запутает дело.)

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

Но только “особо одаренные” считают, что жестко структурировать можно любой процесс:

Оставляя в стороне крайности - полностью структурированные и полностью ситуативные (ad-hoc) процессы - получаем два варианта сочетания тех и других. Либо структурированный процесс обращается к ситуативному, либо наоборот:

1. Паттерн “помощь зала”: структурированный процесс обращается к ситуативному подпроцессу. Пример: процесс “от обращения до заказа” в компании - системном интеграторе. Менеджер по продажам встречается с потенциальным заказчиком и предположим, встреча прошла удачно: удалось нащупать одну или несколько “болевых точек” клиента - проблем, за решение которых он в принципе готов заплатить. Следующий шаг процесса - поиск такого решения. Однако проблемы клиента могут лежать в очень широком диапазоне (заметим, что ценность интегратора как раз и заключается в том, что он способен решать широкий круг задач). Начиная от простейшей ситуации, когда нужен коробочный софт, и заканчивая сложными, комплексными проектами. В последнем случае процесс пойдет по извилистой, заранее неизвестной траектории, которая может вовлекать архитектора, разработчика, менеджера по продажам, системного инженера, техподдержку вендора и т.д. Средствами традиционной BPMS можно разве что назначить задачу одному ответственному исполнителю, а с остальными пусть он разбирается сам (см. пост “Процессный антипаттерн: Театр одного актера“). Решение не самое лучшее, так как неизвестно кто занимается проблемой в данный момент, что уже сделано и когда можно рассчитывать получить решение.
2. Обратная ситуация, паттерн “набор процессных инструментов”: на верхнем уровне процесс протекает  непредсказуемо, но на нижнем он сводится к набору достаточно хорошо формализуемых подпроцессов-инструментов. Пример: адвокатская контора. Процесс верхнего уровня - дело клиента. В какую сторону повернется дело предсказать абсолютно невозможно - например, в любой момент в нем может появиться новый документ, представленный противной стороной, который кардинально поменяет и ход дела, и наши планы действий. Но в то же время, в рамках дела ведущий его адвокат инициирует те или иные действия, которые большей частью стандартны, могут быть типизированы и формализованы в виде подпроцессов. В основном это подготовка исковых заявлений и других документов. Такие подпроцессы выполняются соответствующими специалистами, не привязанных к определенному делу в отличие от адвоката, который его ведет, а являющимися разделяемым ресурсом. С точки зрения компании интересно контролировать показатели эффективности на уровне не только дела в целом, но также подпроцессов и использования ресурсов.

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

• На конференции Гартнер BPM’2009 была озвучена следующая оценка: до 60% процессов в организации являются неструктурированными и как следствие, неконтролируемыми, неуправляемыми, невидимыми и не регулируемыми правилами. Эти 60% похожи на среднюю температуру по больнице, но “невидимость” этих процессов действительно может быть основной проблемой с точки зрения бизнеса.
• “Обращение к коллективному знанию будет двигать вперед неструктурированные процессы” - Джим Синур (Гартнер) предсказывает, что задействование технологий накопления знаний, отраслевых и социальных сетей приведет к новой волне фундаментальных изменений в BPM и BPMS. Еще один его пост на эту же тему: “Белые воротнички и неструктурированные процессы подходят друг к другу как сыр к вину“.
• То, как стремительно приобрели популярность социальные сети (те же “одноклассники”), подталкивает к мысли позаимствовать наработанные в них подходы для организации общения в рамках динамических процессов - см. доклад о спектре возможных применений social software в BPM на BPM-конференции в Ульме. Скажем, сталкиваясь с проблемой, я публикую вопрос в корпоративной сети (”помощь зала”). Его видят мои “френды” (в числе которых менеджер проекта и тим-лид). Автор лучшего ответа получает бонус.
• SAP предлагает использовать для совместной работы технологию Google Wave - но не для исполнения процесса, а для его проектирования. SAP Gravity представляет собой реализацию BPMN-редактора в среде Google Wave. Что касается исполнения, то надо понимать, что возможность проектирования процесса “на лету”, в ходе его исполнения, является важным аспектом динамичности, поэтому SAP создает задел не только для выявления, но и для исполнения динамических процессов.
• Oracle тоже говорит о collaborative BPM и dynamic BPM и при этом подчеркивает свою приверженность архитектуре SCA, позволяющей комбинировать различные процессные составляющие с бизнес-правилами, аналитикой и т.д. Что ж, учитывая, что за два года Oracle приобрел 50 компаний, продукты которых необходимо интегрировать, для них это особенно актуально.
• HandySoft, ActionBase и другие вендоры заявляют о поддержке динамических процессов в последних версиях своих продуктов.
• Самые авторитетные специалисты отрасли собираются, чтобы обсудить проблемы динамических процессов и в частности, их поддержку в BPMN.

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

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

Сторонники BPM любят подчеркивать, что, в отличие от типичных ИТ-проектов, проекты BPM дают быструю финансовую отдачу. Например, по данным Gartner, которые приводит Джим Синур, половина проектов BPM демонстрируют возврат инвестиций на уровне 20% и больше. Он встречал «сумасшедшие» показатели в 220% и даже 360%, которые ему пришлось отбросить, чтобы не исказить среднее.

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

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

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

Как показал Э.Голдратт в своей книге «Necessary but Not Sufficient» (в русском переводе «Цель-3»), большая часть обычно декларируемой эффективности ERP –  повышение прозрачности и производительности, привлекательность для инвесторов, сокращение материальных запасов – иллюзорная. Для достижения итоговых экономических результатов корпоративная система – условие необходимое, но недостаточное. Да, ERP обладает потенциалом повышения экономической эффективности компании. Но только когда ERP дополняется BPM, этот потенциал превращается в реальность.

Далее, предположим, что внедрение ERP обошлось в один миллион, а проект BPM – в двести тысяч. Если мы признали ERP-систему необходимой, то достигнутый в итоге экономический эффект по справедливости следует отнести к суммарным понесенным затратам. А если отнести отдачу только к затратам на BPM, то мы как раз и получим те самые «сумасшедшие» 220 и 360% возврата на инвестиции. Если прибегнуть к аналогии из области телекоммуникаций, то ERP – это бэкбон, а BPM – решение для последней мили. Никому ведь, кажется, не приходит в голову улучшать показатели эффективности услуги предоставления интернета за счет игнорирования затрат на бэкбон?

И конечно полный абсурд – пытаться обойтись без бэкбона. Бывает, недобросовестный интернет-провайдер обещает клиенту подключение на скорости 10 Мбит/с, умалчивая о том, что это только скорость канала до его сети, а реальная скорость подключения клиентов к интернету в десять раз меньше. А бывает, что заказчик говорит: «Я слышал, что ERP – это уже не круто, и вообще там проблемы с окупаемостью. Вы говорите, что BPM – это такая замечательная вещь, может, мне лучше вместо ERP внедрить BPM?» Увы, «вместо» не получится, только вместе! BPM, под который не подведен фундамент в виде корпоративной информационной системы – это старый добрый документооборот: слабо структурированные данные, которые невозможно обработать, найти или извлечь в нужное время и в нужном виде.

Еще раз вернусь к телекоммуникационной аналогии. Когда вы собираетесь протянуть к себе домой интернет, вы ведь не обращаетесь к оператору, владеющему магистральными линиями передачи данных в вашем регионе? Теоретически он мог бы протянуть к вам домой оптоволоконную линию и даже помочь настроить домашний компьютер. Но это вам обошлось бы в копеечку, и поэтому вы обращаетесь к местному провайдеру, который специализируется на «последней миле». Так вот, пытаться «протянуть» ERP до каждого рабочего места в вашей компании – это примерно то же самое: консультанты по ERP могут это сделать, но вообще-то это не их профиль. Обычно они предпочитают не вникать в специфику вашего бизнеса, а предлагают вам перестроить бизнес под ERP. А адаптация системы к вашим бизнес-процессам обходится очень дорого. Причем, в отличие от подключения к интернету, которое делается один раз, бизнес-процессы предполагают постоянное усовершенствование, а значит, вам придется обращаться к программистам снова и снова. Поэтому многие компании приходят к выводу, что реализация бизнес-процессов внутри ERP-системы неээфективна, и делают выбор в пользу BPMS, в которой проектирование бизнес-процессов выполняют собственные бизнес-аналитики без участия программистов.

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

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

Конечно, нельзя однозначно сказать какой путь лучше – внедрение единой системы от одного поставщика («single vendor») или интеграция различных систем («best of breed»). Но все же тенденция последних лет – рост популярности второго подхода. Связано это, во-первых, с совершенствованием и удешевлением технологий интеграции - ESB, MDM. А во-вторых, единая система оказывается миражом, недостижимым идеалом: как только вы наконец-то внедрили ERP, оказывается, что вам необходим CRM, система клиент-банк, ПО для мобильных сотрудников, работающее на смартфонах или, предположим, ПО для мониторинга автотранспорта через GPS+GPRS. И вы опять возвращаетесь к ситуации нескольких систем.

Выводы:

1. Экономический эффект проекта BPM определяется тем, сколько до этого предприятие потратило на создание корпоративной системы: чем больше эта сумма, тем больший возврат инвестиций может продемонстрировать BPM. Но эти цифры – лукавые, ведь вы просто отнесли львиную долю затрат на проект ERP, а большую часть полученного роста доходов и сокращения издержек – на проект BPM.
2. Чтобы реально повысить отдачу от инвестиций, надо рассматривать не отдельные проекты ERP или BPM, а вложения в совершенствование управления или, если хотите, в трансформацию бизнеса. Прочность цепи определяется прочностью слабейшего звена: если вкладывать только в ERP, то вы получите информационный бэкбон, не дотягивающийся до потребителей. А если вкладывать только в BPM, то первые успехи сменятся разочарованием, когда информационные потоки от бизнес-пользователей упрутся в неэффективную корпоративную систему.

Учтите, что слабым звеном могут быть не технологии, а люди. Толку от внедрения самых совершенных систем не будет, если сотрудники не готовы творчески пересматривать то, как они работают. Много ли у вас в компании сертифицированных специалистов по теории ограничений (Theory of Constraints), бережливому производству (Lean) и шести сигмам (Six Sigma)? Движущей силой внедрения системы управления бизнес-процессов и корпоративных информационных систем могут быть только хорошо мотивированные и подготовленные специалисты. Причем не только ИТ-специалисты, но и специалисты по современным методам управления. А что, в свою очередь, приводит в движение этих людей? Очевидно, высшее руководство компании.