3 ноября выступаю на конференции CNews “Перспективы BPM в России”.

Помните старый анекдот про Эйнштейна? Перед экзаменом ассистент у него спрашивает: “Как же так, профессор, у вас экзаменационные вопросы те же, что и в прошлом году? - Спокойно, все в порядке. Вопросы те же, но ответы в этом году другие!”. Да, было время в физике… Так вот, на подобных конференциях обычно бывает наоборот: вопросы разные, а ответы большей частью одни и те же - независимо от подзаголовка конференции доклады на 3/4 представляют собой презентации продуктов.

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

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

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

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

Да, существенный момент: участие для всех, кроме представителей ИТ-компаний, бесплатно! Но число мест там реально небольшое, так что если заинтересовало - поторопитесь!

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-вендоров больше, чем требуется рынку. И тут появляется новый фронт для соперничества: динамические процессы. Фронт очень обширный, если рассматривать все аспекты динамичности, так что прикрыть его нелегко, и боюсь, в текущей экономической ситуации под силу это будет не всем. Зато те, кто в итоге смогут предложить всестороннюю поддержку динамических процессов, получат в глазах пользователей отчетливо видимое преимущество.

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

Бизнесмен: мы принимаем решения на основе предварительной оценки окупаемости или возврата на инвестиции (ROI).

Шахматист: конечно надо считать когда и сколько материала - пешек, фигур - ты выиграешь в результате того или иного хода. Мы тоже считаем комбинации. Только у нас партия состоит не из одних комбинаций. Бывают ходы вынужденные, когда думаешь не о том, чтобы побольше съесть чужих пешек и фигур, а о том, чтобы не съели твои. Бывают ходы, улучшающие позицию. Бывает, что жертвуют материалом, чтобы улучшить позицию  - “получить игру”. Ведь если позицию не развивать, то просто не будет возможности развернуть атакующую комбинацию и ни до какого ROI дело вообще не дойдет.

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

Бизнесмен: у нас тоже есть стратегия компании.

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

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

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

Военный: мы тоже считаем темпы операций. Классический пример: время мобилизации и развертывания в начале войны стали краеугольным камнем знаменитого плана Шлиффена немецкого Генштаба на войну, которую потом назвали Первой мировой. Загонять противника “под флажок” мы тоже умеем: наводнить его штабы противоречивой информацией и дезинформации, совершать ходы, которых он не ожидает, чтобы он не успевал переваривать информацию и в результате постараться добиться паралича управления войсками.

Бизнесмен: так, кажется я начинаю понимать что это за business agility, о которой в последнее время столько разговоров…

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

Кирилл Курышев рассказал о бизнес-процессе “Управление заявкой на предоставление услуги связи”, которым команда bpexpert занималась в одной крупной телекоммуникационной компании.

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

Почему я назвал доложенный проект образцовым: в нем все делалось как положено -

1. Отсутствие четко сформулированных требований на входе проекта. В настоящих проектах BPM по-другому не бывает. Начиная, ты никогда не знаешь какой процесс у тебя получится в результате. Выявление процесса (process discovery) в ходе проекта, пять итераций схемы процесса от старта проекта до запуска процесса в эксплуатацию - это классика.
2. Разработка в стиле agile: короткими циклами, с постоянной обратной связью с заказчиком. Говорим BPM - подразумеваем agile!
3. Добротный инструмент Oracle BPM Studio (aka BEA AquaLogic BPM). Бывает так, что основное содержание проекта - борьба с инструментом. Но не в данном случае. Докладчик отметил: были моменты, когда у них возникали затруднения с реализацией в Oracle требований заказчика. В этих случаях они поступали очень правильно: не насиловали инструмент, а пытались работать в том стиле, который он предлагает. В частности, им удалось обойтись “малой кровью” в решении задач, связанных с авторизацией, ролями, делегированием, замещением и т.п. (п.8 моей недавней заметки). Удалось заинтересовать заказчика возможностями имитационного моделирования (simulation), действительно неплохими в Oracle.
4. Удалось принести пользу “заказчику заказчика”, т.е. клиентам компании: среднее время обработки заказа уменьшилось с 5 до 3 дней. В рамках пилотного, по сути, проекта, этого добиться удается не часто.
5. Использование eTOM не как инструкции - “делай раз - делай два”, а как справочника. Т.е. живешь, все-таки своим умом, но время от времени сверяешься с образцом. Такая сверка позволяет существенно повысить ценность решения при незначительном расширении проекта, что и было наглядно нам продемонстрировано.
6. Стремление сделать протекание процесса если не полностью автоматическим (т.е. довести его до STP, straight-through process), то максимально гладким. Похоже, проектная команда интуитивно нашла известный, в общем-то, магистральный путь: направлять человеку только те задания, которые не удалось обработать автоматически. Т.е. использовать человека в качестве “обработчика бизнес-исключений”.
7. И главное: всего за 20 рабочих и 30 человеко-дней им удалось запустить процесс в промышленную эксплуатацию. Скептики посрамлены!
8. Причем есть одна пикантная подробность: на самом деле это была вторая попытка компании-заказчика чего-то добиться при помощи BPM. Причем в первой попытке BPM-система была та же самая, только исполнитель другой. Как я и говорил однажды на конференции: прежде чем критиковать BPM, убедитесь сначала, что то, что вы делаете - это действительно BPM. По-видимому, первая попытка как раз и не была попыткой BPM. И тем ценнее результат команды bpexpert, ведь добиться успеха после фальстарта вдвойне труднее.
9. И последнее - то, что стало предметом оживленной дискуссии после доклада: удалось не только успешно выполнить проект, доведя его до промышленной эксплуатации; по утверждению докладчика, им удалось передать заказчику и компетенцию, и интерес к тому, чтобы продолжать работать над процессом все в большей и большей мере самостоятельно. Этим могут похвастаться очень немногие проекты, а ведь без этого, положа руку на сердце, тоже нельзя говорить о BPM в полном смысле слова.

Должен признаться, у меня даже не получается как положено выдать порцию критики (хотя обычно с этим проблем нет). Ну разве что по мелочи:

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