Один язык, одна нотация, одна модель
В отличие от многих других сегментов ИТ-рынка, развитие которых определяют несколько вендоров, на рынке систем управления бизнес-процессами (Business Process Management System,BPMS) довольно велико. И если бы все они развивали собственные варианты представления бизнес-процессов, как это было на ранней фазе становления рынка BPMS, то рынок был бы сегментирован, а аналитикам и разработчикам пришлось бы постоянно переучиваться или быть очень узкими специалистами, привязанными к конкретному продукту. К счастью, рынок BPM избежал ловушки «vendor-lock» - во многом благодаря тому, что все специалисты «заговорили» на едином языке, когда нотация BPMN 2.0 стала стандартом де-факто в отрасли.
Но это произошло отнюдь не сразу, и дела обстоят не так хорошо, как хотелось бы. Диаграммы BPMN кажутся интуитивно понятными даже неспециалисту, и люди начинают рисовать процессы по наитию, хотя на самом деле BPMN - это жесткая нотация со строгими правилами, а не средство визуализации творческих идей. В итоге часто получается, что все стороны (сотрудники бизнес-подоазделений, аналитики и разработчики) общаются на языке, который каждый интерпретирует по-своему, что несет определенные риски.
Название «lingua franca», то есть «франкский язык», давно стало нарицательным - так говорят о языке, используемом для общения людей из разных стран, для которых он, как правило, не родной. Обычно такие языки формируются исходя из практической потребности, например, в торговле или в повседневном общении. Так случилось в Европе, когда после краха Римской империи многочисленным варварам пришлось коммуницировать между собой - и кроме латыни у них вариантов не было.
Поскольку сама идея, что бизнес-процессами надо управлять, восходит к Генри Форду с его знаменитым конвейером, то естественно, что за это время было придумано множество методологий и нотаций. Можно вспомнить IDEF, EPC, UML и старейшую из всех Flowchart, появившуюся аж в 1921 г. Когда концепция управления бизнес-процессами стала воплощаться в конкретных продуктах класса BPMS, то каждый из вендоров мог взять для своего продукта любое из «варварских наречий» (то есть, из имевшихся нотаций).
Такая «разноголосица» тормозила развитие рынка и, поэтому, в 2000 г. группа энтузиастов учредила некоммерческую организацию Business Process Management Initiative (BPMI), объявившую своей миссией создание и продвижение новых стандартов для моделирования, проектирования, исполнения и оптимизации бизнес-процессов. «Семантические различия между ведущими инструментами моделирования процессов и произвольные различия в визуальной нотации препятствуют распространению управления процессами на рынке», - заявили в BPMI.
Первый блин вышел комом: опубликованная в 2001 г. XML-спецификация языка BPML (Business Process Modeling Language) не получила широкого распространения. Среди разработчиков BPM-систем предпочтение отдавалось более простому BPEL (Business Process Execution Language), у которого был один существенный минус - изначально он создавался для взаимодействия веб-сервисов, а не людей.
Проведя работу над ошибками, в 2006 г. BPMI выпустила первую версию нотации BPMN (Business Process Modeling Notation), сделав ее действительно простой и понятной для восприятия. Однако, при всех своих достоинствах, BPMN 1.0, несмотря на то что ее сразу поддержало около двух десятков компаний, тоже не стала заметным явлением, изменившим правила игры. Но время шло, продуктов и внедрений BPM становилось все больше, модели процессов все сложнее. И естественно, что потребность в стандартизации все-таки возобладала.
BPMN 2.0 - язык для машин и людей
Почему ни один из процессных языков начала нулевых так и не стал «лингва франка» для всего сообщества, подобно тому, как в мире реляционных СУБД эту роль играет язык SQL? Потому что помимо людей, его должны были понимать и машины, чтобы процесс можно было нарисовать и сразу исполнить, и такого универсального языка для машин и людей не существовало. Обходной путь все же был: модель в BPMN можно было конвертировать в код на BPEL, но это не было достаточно универсальным решением. С другой стороны, была попытка «очеловечить» BPEL - сделать BPEL4People, консорциум OASIS (Organization for the Advancement of Structured Information Standards) даже выпустил в 2010 г. спецификацию, но получились слишком сложно и это решение тоже не прижилось.
Наконец, в 2011 г. вышла BPMN 2.0 - и это не была больше просто нотация. Теперь это была и нотация, и модель, что отразилось новой в расшифровке аббревиатуры BPMN: Business Process Model & Notation. Главным новшеством в ней стало появление метамодели, которая содержала подробное и однозначное описание реализации каждого элемента нотации. Иначе говоря, это было техзадание на разработку движка, способного исполнять процессы, в этой нотации спроектированные, что стало таким же прорывом, как появление концепции WYSIWYG в текстовых процессорах.
И процесс пошел. Почти одновременно со вторым релизом нотации Alfresco выпустила open source-движок Activity. Два года спустя появилась Camunda BPM (форк Activity), ставшая сегодня одной из самых популярных платформ управления процессами, а в 2016 г. Alfresco покинули разработчики Activity и создали на его основе движок Flowable. Даже один из старейших игроков на этом рынке, jBPM отказался от собственного языка jDPL на основе Flowchart и перешел на BPMN 2.0.
Можно считать, что эта часть истории завершилась принятием BPMN 2.0.1 в качестве международного стандарта ISO/IEC 19510:2013. Теперь официально аналитики, разработчики и бизнес-пользователи могли говорить на одном зыке.
Обосновавшиеся на обломках Римской империи варвары говорили отнюдь не на классическом языке Катулла и Цицерона, а на так называемой «вульгарной латыни», как умели, путая спряжения и падежи.
Ситуация с BPMN, к сожалению, во многом выглядит аналогично. По задумке авторов единая нотация должна была помочь установить понимание между аналитиками, бизнесом и разработчиками, но каждый понимает ее в меру своего разумения - что создает немало проблем в коммуникациях. Ни будущие менеджеры, ни программисты не изучают нотацию моделирования процессов в университетах. До сих пор считается, что это удел системных или бизнес-аналитиков. Конечно, BPMN - это не китайская грамота, вполне можно разобраться и самому. Но это если есть сильная мотивация, а она бывает редко. И выходит, что все сообщество людей, причастных к описанию, моделированию и внедрению систем управления бизнес-процессами, общается между собой не на строгом едином языке, а на его диалектах.
Пожалуй, ярче всего это проявляется в том, что существует два уровня моделей бизнес-процессов: «менеджерский» и «инженерный». С одной стороны, это выглядит логичным - бизнесу не нужно вдаваться в технические детали, главное, чтобы была ясна суть. Многие бизнес-аналитики также стоят на этой позиции, в результате чего появляются схемы процессов, которые BPM-движок не сможет исполнить. Одна из наиболее популярных вольностей - это то, как люди используют сообщения в BPMN: они видят иконку, на которой изображен конверт, и трактуют ее буквально как электронную почту или месседжинг. А на самом деле этот элемент нотации введен для организации межпроцессного взаимодействия. И таких нюансов еще достаточно много. Более того: иногда без устных пояснений вообще нельзя понять, что имел в виду автор диаграммы - в этом случае пасует не только сам движок, но и разработчики.
Обратная ситуация немногим лучше: модель процесса от инженеров, которая учитывает действительно все требования, становится слишком сложной для восприятия ее бизнесом. И даже если там все правильно, заказчику сложно под этим поставить свою подпись, ибо он не понимает, как это будет работать.
Суммируя сказанное, можно сделать вывод, что существует информационный разрыв между управленческим и техническим уровнями BPMN, и нет прозрачного механизма, чтобы установить четкое и однозначное соответствие между ними. То есть, схему процесса, утвержденную руководством, кто-то должен вручную переработать, чтобы она превратилась в исполняемую модель.
До настоящего времени такое разделение не было существенной проблемой: специально обученные люди (то есть, аналитики) переводили с менеджерского языка на инженерный, а затем разработчики правили код, и это всех устраивало. Пусть это было не слишком эффективно, зато каждый оставался в своем «домике», не обременяя себя знаниями из смежных областей. Однако рынки становятся все более динамичными, а порой и турбулентными, поэтому иногда требуется вносить изменения в информационные системы чуть ли не ежедневно.
Ответом на этот вызов стало появление концепции DevOps, в которой разработка, внедрение и эксплуатация завязаны в единый цикл. Чтобы это стало возможным, не только программное обеспечение, а вообще все компоненты информационной системы, включая конфигурации, контейнеры, виртуальные машины, сетевые настройки, права доступа, политики резервного копирования, процедуры развертывания и все прочее, представляли собой код, который лежит в некоем репозитории с контролем версий. Даже стали говорить «Everything as a code» - все как код.
Само собой напрашивается, что бизнес-процессы тоже должны попасть в этот список, чтобы их цикл обновления тоже был непрерывным и быстрым, чтобы наряду с DevOps заработал и ProcessOps. Технически к этому все готово - есть нотация, понятная и людям, и движкам; и есть модели, которые позволяют процессы исполнять. Те есть, фактически процесс уже есть код, благодаря BPMN.
Но из-за отсутствия всеобщей «процессной грамотности», причем не на уровне концепций, а так, чтобы каждый мог любые схемы «читать без словаря», эта практика пока не распространена широко. Наиболее передовые организации уже озаботились этим и реализуют внутренние образовательные проекты, чтобы BPMN действительно стал языком общих коммуникаций для всех заинтересованных сторон.