Вчера прошел очередной семинар BPMS.ru: “Автоматизация процессов в вузе“. Интересен он был, на мой взгляд, не столько проблемами вузов, сколько элементами ноу-хау, которым поделилась Бизнес-Консоль, в частности:

1. Анализ цепочки создания ценности на основе стандартного фреймворка. Он нам нравится своей простотой (5 основных процессов, 4 вспомогательных) и универсальностью. Последнее как раз и иллюстрирует вузовский пример: если на фреймворк ложится деятельность такого специфического “бизнеса”, как университет, то нормальным компаниям - производственным, торговым, финансовым - и подавно подходит. Правда, оборотная сторона такой универсальности - фреймворк необходимо адаптировать для каждого бизнеса. Начиная с того, что переименовать каждый процесс (а строго говоря, прямоугольники фреймворка - это не процессы, а группы процессов), используя лексику данного бизнеса. Но это крайне полезное упражнение, которое, по хорошему, должно предшествовать любой BPM-инициативе. Благо трудоемкость его вполне разумна.
2. Паттерны моделирования B2C и B2B процессов. Традиционный жесткий workflow годится только для внутренних процессов: там все в нашей власти, всем участникам можно выдать жесткий регламент и исполнять процесс “на раз-два”. Но как только появляются контрагенты, правила игры меняются. К примеру, послали вы ему счет - а он его не оплачивает (об этом антипаттерн “Гарантированное получение сообщения”). Вместо оркестровки приходится реализовывать хореографию: асинхронное исполнение нескольких процессов, обмен сообщениями-сигналами… Вуз в этом смысле, опять-таки, интересный объект: там непредсказуемость очень велика. Студенты, что с них возьмешь. К примеру, нельзя закладываться на то, что абитуриент сначала заключит договор, потом оплатит, потом пройдет тестирование - последовательность будет любой. В ходе обсуждения рассмотрели несколько вариантов решений, в том числе конечный автомат обычный и многомерный.
3. Отдельно был рассмотрен новый паттерн с рабочим названием “продолжение с повтором”. Он пока еще нигде не докладывался, собираюсь написать о нем в отдельной статье здесь на блоге.

О планах дальнейших семинаров. Во-первых, обращаю внимание всех заинтересованных лиц: объявления о семинарах публикуются в виде RSS вместе с новостями сайта: http://bpms.ru/rss/news.xml, подписывайтесь.

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

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

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

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

Место проведения будет тем же (РосНОУ), регламент несколько другой - времени нужно больше, чем на семинар. Поэтому начнем в 6 вечера, а закончить рассчитываем ближе к 10. Регистрация на livents.ru.

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

Фактически речь идет о двух способах решения задач:

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

Какое-то мутноватое получается объяснение, не так ли? Добавляет путаницы то, что английские “template” и “pattern” зачастую оба переводят как “шаблон”, и смысл при этом частично теряется.

Думая о том, как это можно объяснить “на пальцах”, нашел аналогию в шахматах:

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

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

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

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

Паттерны в BPM - это типовые фрагменты процессов или межпроцессного взаимодействия (некоторые примеры).

Уместно спросить: от чего больше пользы? Мое мнение - от паттернов:

• Шаблоны специфичны (один процесс - один шаблон), паттерны универсальны. Хороший паттерн можно использовать в самых разных бизнес-процессах независимо от отраслевой специфики.
• Польза от шаблона на практике оказывается меньше ожидаемой. Как правило, позаимствовать удается только магистральный путь (happy path), а дьявол оказывается в деталях - в обходных путях, в обработке нештатных ситуаций.
• Эффект от использования правильного паттерна может быть очень большим. Например, в нашей практике был случай, когда процесс, изображенный на 6 склеенных друг с другом листах формата А4, за счет использования правильного паттерна удалось свести к изящной конструкции из 15 процессных шагов.
• Что касается антипаттерна, его польза в том, что в нужный момент он предостережет вас от ошибки. Цена ошибки теоретически может быть любой, и иногда реально большой.

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

На блоге 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 и переключиться на другой проект, тоже многообещающий. Поверьте, ему обычно есть из чего выбирать.

В этот раз доклады мне показались слабее, чем на предыдущем Круглом столе в ноябре. Было несколько докладов интересных и зрелищных, но… не относящихся к BPM. (Если конечно не считать, что все связанное с бизнес-процессами автоматически попадает в эту графу.)

Юлия Вагнер (которая, кстати, была модератором) опубликовала на bpms.ru подробный обзор докладов. С картинками!

Моя презентация:

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

Пример:

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

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

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.

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

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

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

В самом деле, представим себе бизнес-процессы, составляющие типовую цепочку создания ценностей компании:

1. от идеи до продукта
2. от продукта до обращения
3. от обращения до заказа
4. от заказа до оплаты
5. после продажи

Точно так же, как прочность цепи определяется прочностью одного самого слабого звена, производительность компании зачастую определяется производительностью “бутылочного горлышка” - наименее эффективного процесса (”ограничения” в терминах Теории ограничений Голдратта). Повышение производительности ограничения, скажем, на 10% повлечет повышение показателей компании примерно на те же 10%. Повышение же производительности остальных процессов в рамках модели “цепочки” не дает ничего. Отсюда следует экстремальная важность выбора правильной точки приложения для BPM-инициатив.

В современной экономике ограничителем, как правило, является рынок. Но в чем именно он нас ограничивает - в интенсивности первичных обращений (п.2)? Или может в нашей способности доводить обращение до заказа (п.3)? А может нам стоит обратить особое внимание на послепродажные процессы (п.5)? Ведь можно прекрасно отработать “на отлично” в рамках процесса продажи (п.4), но потерять и этого, и еще 10 потенциальных клиентов, потому что не отработан процесс работы с рекламациями.

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

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

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

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

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

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

А толчком к выводу в начале этой заметки - активнее продвигать изложенные идеи - стали опубликованные тезисы доклада аналитика Гартнер Билла Россера “Gartner Identifies Seven Major Guidelines to BPM Project Success” к предстоящей конференции по BPM (русский перевод на BPMS.ru). Цитирую:

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

Золотые слова!

18 февраля - очередной семинар BPMS.ru. Роман Ткачев (BI Telecom) обещает поделиться сокровенным

Следующий семинар BPMS.ru предварительно запланирован на 25 марта.

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

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