Говорят, однажды, в возрасте девятнадцати лет, будучи студентом Мюнхенского университета, Макс Планк рассказал пожилому профессору Филиппу Жолли о своем намерении посвятить себя теоретической физике. Выслушав его, профессор воскликнул: «Молодой человек, зачем вы хотите испортить себе жизнь? Ведь теоретическая физика уже в основном закончена… Стоит ли браться за такое бесперспективное дело?!». Двадцать пять лет спустя Макс Планк выдвинул гипотезу дискретного излучения, ставшую основой принципиально нового направления — квантовой физики, которая перевернула многие сложившиеся представления физиков ХХ столетия и по сей день лежит в фундаменте современных представлений об устройстве мира.

С тех пор прошло около ста лет, наступил XXI век. Изобретено и используется множество подходов к описанию бизнес-процессов (IDEF0, IDEF3, CFD, EPC и другие). И всё же продолжают появляться новые стандарты описания процессов. В 2004-м году опубликована первая спецификация новой графической нотации описания бизнес-процессов BPMN (Business Process Modeling Notation). Зачем и кому нужен BPMN? Будет ли BPMN полезен при моделировании процессов ITSM? И сможет ли этот «новичок» совершить переворот в современной практике моделирования процессов?

Суть идеи

Подробно познакомиться с BPMN можно на сайте разработчика; я же приведу только краткое описание основной идеи — «своими словами близко к тексту».

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

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

Для описания таких сложных процессов стандарт BPMN вводит новые графические элементы, определяющие:

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

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

Как обеспечить выполнение процесса, если у нас имеется его точное описание в BPMN? Традиционный вариант — передать диаграмму процесса системному аналитику для реализации в используемой системе автоматизации (где-то для этого придется писать код, где-то — использовать графический редактор workflow, где-то — использовать редактор бизнес-правил, не требующий программирования). И этот подход вполне работает. Но если ваша система автоматизации поддерживает BPEL, то можно просто «транслировать» диаграмму BPMN в код BPEL и запустить его в работу — базовая автоматизация процесса готова. BPEL — это универсальный высокоуровневый язык исполнения бизнес-процессов (Business Process Execution Language).

Таким образом, BPMN предназначен для людей и используется для разработки точных описаний сложных процессов, а BPEL предназначен для машин, выполняющих автоматизацию этих процессов. Так про это и говорят: BPEL is not for people:)

BPMN и процессы ITSM

Итак, у нас есть стандарт BPMN, и его можно применять для описания различных процессов, в том числе процессов управления ИТ-сервисами. Но есть ли от этого какая-то польза? Оказывается, есть.

Дело в том, что процессы ITSM тоже содержат «сложные» участки, адекватное описание которых с использованием только базовых инструментов крайне громоздко. Типичные примеры таких участков — согласования изменений и документов, получение подтверждения пользователей о решении инцидентов, организация периодического контроля известных ошибок в рамках управления проблемами, то есть такие участки, где взаимодействие участников работ непосредственно поддерживается системой автоматизации.

Рассмотрим простейший пример: проверку инцидента перед закрытием.

• Если инцидент есть обращение пользователя, перед закрытием необходимо получить его подтверждение восстановления сервиса. Помимо телефонной связи, на практике для этого часто используют почтовые уведомления и web-интерфейс конечного пользователя. Причем если после уведомления пользователь не откликнулся в течение нескольких дней, инцидент может считаться исчерпанным и закрываться системой автоматически.
• Если же инцидент представляет собой системный сбой (например, отказ, зафиксированный системой мониторинга), перед его закрытием может потребоваться обработать все связанные с ним обращения пользователей, а может быть и подождать какое-то время — не появятся ли новые обращения, опровергающие наше предположение о том, что сбой устранен. Только если в течение заданного промежутка времени такие обращения не появятся, сбой переводится из статуса «Решен» в статус «Закрыт».

Как все это отобразить на диаграмме процесса так, чтобы представленная логика обработки инцидента на этапе закрытия была понятна? Применив BPMN, получим следующую диаграмму процедуры закрытия инцидента:

Чтение представленной диаграммы требует определенной привычки, однако схема определяет точную логику закрытия инцидента, устраняя разрыв между «теоретическим» описанием процесса и реальным порядком его исполнения. Глядя только на эту диаграмму, и не читая длинных описаний процедур, специалист увидит и оповещение пользователя, и возможность подтверждения по телефону, и ожидание ответа по e-mail, и автоматическое закрытие инцидента по таймауту.

Подобных примеров в процессах ITSM можно привести множество.

Выводы

Конечно, BPMN никого не спасет. По прежнему основные проблемы ITSM-проектов заключаются в полной подмене основной идеи — вместо проведения изменений в подходе к управлению зачастую выполняется просто внедрение системы автоматизации, сдобренной пачкой регламентов. Их не читают и не используют. Диаграммы BPMN в них никто не увидит и не оценит. Систем автоматизации ITSM-процессов, поддерживающих BPMN и BPEL, пока не появилось. Похоже, время Макса Планка в управлении ИТ еще не пришло…

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

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

Автор: Дмитрий Исайченко.