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

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

Для начала зададимся вопросом: какие методологии в области управления бизнес-процессами на сегодняшний день завоевали себе место под солнцем?

• Среди консультантов и людей бизнеса более всего на слуху Lean Six Sigma – продукт синтеза методологий Lean и Six Sigma.
• Lean – это методология бизнес-трансформации, выросшая из TPS (Toyota Production System – Производственная система Тойоты). Ее ключевые идеи – увеличение ценности для заказчика за счет сокращения всех видов потерь и повышения равномерности производственных и бизнес-процессов.
• Six Sigma (Шесть Сигм) – методология, разработанная в компании Моторолла и нацеленная на повышение ценности для заказчика за счет уменьшения дефектов и вариаций производственных и бизнес-процессов на основе использования строгих методов математической статистики.
• TOC (Theory of Constraints, Теория ограничений) рассматривает бизнес как систему взаимозависимых по входам-выходам процессов. Ключевая идея здесь сводится к тому, что производительность цепочки процессов равняется производительности самого медленного его звена, и методология в основном рассматривает следующие из этого выводы. Хотя эта методология уже по охвату, она привносит оригинальные и ценные с практической точки зрения идеи, поэтому неудивительно, что они завоевали широкое признание, в том числе в рамках Lean Six Sigma.
• Еще можно вспомнить получившую широкую известность TQM (Total Quality Management). Но эта методология уже стала частью истории, хотя основные ее идеи можно найти в тех же Lean и Six Sigma, а также в стандартах качества серии ISO 9000.

Плюс к этому отдельные компании и аналитики продвигают собственные, иногда достаточно интересные методологии. Но пожалуй только TQM, Lean, Six Sigma и TOC достигли уровня мэйнстрима, т.е. вокруг них оформились сообщества, по ним написано много книг, доступны учебные курсы. А с учетом того, что эти мейнстримовые методологии в значительной степени пересекаются между собой (а Lean и Six Sigma вообще сливаются в единое целое), мы вряд ли увидим, что какая-то новая методология внезапно завоюет всеобщее признание.

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

В рамках BPM следует говорить только о «тактической» методологии, тесно связанной с инструментарием. Например, BPMS позволяет очень эффективно выявлять бизнес-процессы, а быстрое прототипирование исполняемых процессов позволяет сократить дистанцию между бизнесом и ИТ и радикально повысить время реакции на изменение требований бизнеса (agility).

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

Какие практические выводы из этого следуют для компании, задумывающейся о реализации программы BPM?

1. Позаботьтесь о технологической и методологической составляющих вашего проекта. В части технологии вы должны определиться с BPMS, выработать соглашения по стилю моделирования бизнес-процессов, утвердить стандартный жизненный цикл бизнес-процесса. Аналогичным образом, в области методологии вы должны знать, например, по каким принципам, в рамках какой процедуры и кто конкретно выбирает процесс для очередного проекта в рамках программы BPM. Как фиксируются метрики процесса до начала проекта и как контролируется достижение целевых показателей по его окончании? Кто обеспечивает видимость процессов и возможность их повторного использования другими процессами? Кто отвечает за то, чтобы разрабатываемые процессы не оставались разрозненными островками субоптимизации, а соединялись в единую цепочку создания ценности?
2. Обопритесь на готовую BPMS и готовую методологию. Разработка собственной методологии, как и разработка собственной BPMS, уведет вас слишком далеко от конечных целей проекта – повышения эффективности вашего бизнеса. Не забывайте, что, как показывает история, разработка собственной оригинальной методологии под силам только таким гигантам, как Тойота (Lean), Моторолла (Six Sigma) или Ксерокс (TQM). Встаньте на плечи этих гигантов – потратьте время на литературу и учебные курсы, наймите консультантов с опытом внедрения процессного управления с использованием BPM. Причем этот совет ни в коем случае не означает призыва отказаться от творческого начала и слепо копировать чужой опыт. Ведь все методологии излагают только общие принципы и оставляют более чем достаточно места для адаптации их к условиям вашего конкретного бизнеса. И все они подчеркивают важность накопления собственной, а не приобретения чужой компетенции. Так что вам понадобятся талантливые и мотивированные личности, начиная с собственников и руководителей верхнего уровня компании, и у вас будет достаточно задач, адекватных их амбициям.

Альтернативное название: “Микроменеджмент”.

Типичное затруднение первого BPM-проекта: “на какую глубину копать”, до какого уровня детализировать бизнес-процесс?

В одном из первых наших первых проектов мы занимались процессом под названием “Заказ по трехстороннему договору”. Суть дела:

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

По-крупному процесс состоял из четырех этапов:

1. согласование заказа
2. подписание заказа
3. поставка товара
4. оплата и закрытие заказа

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

В первом приближении схема процесса выглядела так:

Затем схема стала усложняться. Во-первых, если в ходе согласования с производителем он сделал встречное предложение и мы приняли его за основу, то на следующей итерации с ним согласовывать уже не надо; аналогично и с покупателем. Далее было справедливо замечено, что процесс теоретически можно ускорить, если согласовывать его с производителем и покупателем не последовательно, а параллельно. Это тоже отразили в схеме. И так далее.

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

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

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

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

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

Нынешний финансовый кризис отрасли BPM не угрожает: ведь чтобы был кризис, надо чтобы сначала был бум, а у BPM его не было.

Этот бум призывали, называя BPM “The Next Big Thing”. Кто-то сделал на ожидание бума серьезные ставки - я имею в виду в первую очередь независимых разработчиков BPMS (”pure-plays”). Хотя и поставщики ПО широкого профиля (”stack vendors”) тоже врядли удовлетворены финансовыми результатами приобретения BPM-активов.

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

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

Как в различных реализациях BPMN выглядит шаг процесса, выполняемый людьми? Чисто для иллюстрации возьмем процесс “От обращения до заказа” (Inquiry to Order) с шагами “Сделай это” (Do This, системный), “Согласуй договор” (Negotiate Contract, человеческий), “Сделай то” (Do That, системный) и смоделируем при помощи нескольких популярных инструментов.

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

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

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

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

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

Современные BPMS позволяют и моделировать, и исполнять подобные схемы, и в этом их коренное преимущество перед традиционными workflow-системами. Другое дело, что аналитики осваивают такие схемы с большим трудом - см. например Bruce Silver, “BPMN to Requester: Get Outta My Pool”. Основная сложность тут не в нотации, а в развитии “асинхронного мышления”. Вы должны научиться вычленять из того, что бизнес преподносит вам как единый процесс, отдельные асинхронные процессы. Помогают разобраться в этом ответы на два вопроса: 1) с каким бизнес-объектом связан экземпляр процесса и 2) с какими событиями связаны начало и завершение экземпляра процесса.

Например, даже в таком относительно простом процессе, как прием сотрудника на работу, мы видим набор бизнес-объектов: 1) позицию штатного расписания, 2) заявку руководителя в кадровую службу о необходимости замещения вакантной позиции штатного расписания, 3) вакансию, объявленную по определенному каналу поиска кандидатов, 4) кандидат, 5) принятый сотрудник. Связаны они между собой не как 1:1, и их жизненные циклы не синхронны. Например, кандидаты присылают резюме, не заботясь о том, если ли у предприятия для них вакансия - дело кадровой службы оценить для какой вакансии (каких вакансий) его стоит рассматривать. Поэтому одним процессом вам врядли удастся обойтись; сколько их получится в итоге - зависит от конкретики вашего бизнеса.

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

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

Как-то сидя на лекции Переслегина и слушая его пророчества - апокалиптические, но все же при этом каким-то непонятным образом оптимистические - задал себе вопрос, который теперь меня не отпускает: а что по-крупному даст наша отрасль в обозримом будущем? Скажем, в ближайшие 10-20 лет (ближе загадывать неинтересно, дальше - бесполезно)? ”По-крупному” - имеется в виду такого, что бы всерьез изменило нашу жизнь.

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

1. Мобильные телефоны - бесспорно. Как мы раньше без них встречи назначали? А если еще в незнакомом месте - вообще мрак.
2. Интернет: паутина, почта, социальные сети, дистанционное обучение и т.д. (Или интернет на первом месте? Ладно, неважно.)
3. Компьютерное проектирование, станки с ЧПУ, роботизированное производство. Где-нибудь еще пользуются кульманами?
4. Бухгатерские программы - пожалуй, тот объем работы, который они сейчас делают, люди вручную уже и не осилят.
5. Компьютерные игры. Изменили сознание уже не одному поколению - засчитываем однозначно.
6. Навигатор в кармане - с натяжкой. Это скорее все же космос, чем компьютер.
7. Всяческие базы данных, хранилища нужных и ненужных документов? Опять-таки с натяжкой. Иногда кажется, что можно было бы и без них обойтись.
8. Глобальные финансы, биржи и т.п. Неочевидно. Ну да, по компьютерным проводам быстрее чем по телеграфу, но так ли это принципиально?
9. Автоматический перевод. Уже практически состоялся. Литературного перевода от компьютера ждать не надо, но уже сейчас американцы читают русские или китайские сайты и понимают что там написано.
10. Вещи в быту незаметные, но которые не стоит недооценивать: оружие. Хотя вояки на удивление мало взяли от ИТ. Системы наведения, криптография, “эшелоны” всякие… и все, что ли?

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

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

1. Машина времени

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

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

Кстати, можно совместить одно с другим: представьте себе тысячи добровольных Шерок-Холмсов, сидящих дома и выслеживающих, скажем, угонщика машины. Опять-таки, нечто подобное уже делается: в Штатах гражданам предложили стать виртуальными рейнджерами - следить за мексиканской границей со своего компьютера и докладывать властям о нарушениях. Желающих будет более чем достаточно. А что - все лучше, чем шпионить за соседями в окошко.

2. Всеобщая идентификация

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

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

Странно что до сих пор RFID не встроили в банкноты. Думаю, уже скоро. Так исчезнет последний островок свободы - наличные деньги. Должно быть, найдутся достаточно влиятельные люди, которым это придется не по вкусу, но и они смогут только оттянуть момент.

3. Распознавание речи

Реально полезная вещь, и вроде уже решение близко. А то записывать научились, но ведь прослушивать записи - это мучение, а расшифровывать - еще хуже. Вот у нас в институте лекции по матану читал Кудрявцев - один-в-один по своему учебнику. Ну и смысл ходить на лекции? Я быстро понял, что учебник читаю раз в 5 быстрее.

Вот сейчас сижу, стучу по клавиатуре, наживаю себе артроз. Нафига, спрашивается? Лучше бы я сидя в массажном кресле надиктовал, а потом поправил текст в редакторе.

Конечно, в результате, как сейчас молодое поколение (да и не только они) предпочитает аудиокниги, так следующее разучится уже и писать. Но зато риторика расцветет, и люди снова научатся говорить.

4. Смерть шахмат

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

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

Определение:

• Процессом масштаба предприятия (”enterprise process”) или, что то же самое, сквозным (”end-to-end process”) называется бизнес-процесс, замкнутый по входу и выходу на внешнего заказчика и проходящий через более чем одно подразделение верхнего уровня.

Аксиома:

• Инициатива BPM окупится только если вы беретесь за сквозные процессы.

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

Типичные ошибки:

1. BPM-вендоры любят иллюстрировать возможности своих продуктов на вспомогательных процессах типа “Прием на работу” или “Отчет о командировочных расходах” и тем самым провоцируют заказчиков заниматься тем же самым. Для тренировки сгодится, но за подобными процессами просто слишком мало денег, чтобы оправдать затраты на проект масштаба компании. А иным проект BPM не может быть по определению.
2. Половина потенциальных клиентов предлагает заняться процессом “Заключение договора”. Тут с ценой вопроса все в порядке, но это, как бы сказать, не вполне процесс. Правильнее рассматривать его как фрагмент сквозного процесса “Продажа товара/услуги”. Ведь заказчика интересует конечный результат, т.е. показатели процесса в целом, и не факт, что именно этот фрагмент процесса критичен. (Такое сужение “рамки” и называется субоптимизацией.)
3. И совсем тяжелый случай: “Вот у нас тут есть процесс, мы его хорошо знаем и уже автоматизировали, давайте для сравнения сделаем его в BPM.” То есть давайте устроим соревнование лучшего с хорошим. Если вы хотите, чтобы ваш проект оценило руководство, вы обязаны не просто реализовать какой-то процесс в BPM, но добиться в результате этого существенного улучшения его показателей. Врядли вы этого добьетесь на процессе, с которым уже основательно поработали.

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

Применительно к позаказному производству, процесс ”От заказа до оплаты” укрупнено может состоять из подпроцессов получения аванса, производства, отгрузки, расчетов:

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

Но бизнес не работает по принципу “раз-два-три”!

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

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

Определения:

• Последовательность и логика выполнения задач в рамках одного процесса называется оркестровкой (”process orchestration”).
• Логика асинхронного, координируемого при помощи сообщений выполнения нескольких процессов называется хореографией (”process choreography”).

Теорема:

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

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

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