Бизнес-процессы выполняются не в какой-то абстрактной среде, а всегда в конкретной организации. Иначе говоря, они погружены в организационный контекст. Что это значит? Исполнителями задач назначаются не Маши, Пети или Васи, а сотрудники, занимающие определённые должности. Для этого нам надо связать процессные роли с организационными единицами.
В самом стандарте BPMN ничего для этого не предусмотрено. Максимум, что у вас есть из штатных средств, — это комментарии, в которых можно указать исполнителя. Минусы такого подхода очевидны: комментарий — это произвольный текст, поэтому гарантировать консистентность и непротиворечивость назначений невозможно.
Логичным выходом из положения становится использование компонента управления оргструктурой, который бесшовно интегрируется со средой моделирования процессов. Подобные модули есть во многих BPMS, зарубежных и российских: Bizagi, Appian, Pega, Bonita, Comindware, ELMA, Directum RX. Но это всё системы, скажем прямо, тяжеловатые для аналитика.
Если посмотреть именно на средства моделирования процессов, то здесь картина совсем печальная. Популярный Camunda Modeler предельно аскетичен и нацелен скорее на разработчиков, чем на аналитиков. Не менее известный Bizagi Modeler предоставляет доступ к оргструктуре только когда используется в составе всей платформы. Отечественная Business Studio имеет в своём составе оргмодель, но стоит несколько особняком: это система моделирования предприятия, которая охватывает значительно более широкие рамки, чем только моделирование процессов, и тоже может оказаться избыточной.
А как же Stormbpmn? Здесь всё в порядке: в продукте есть встроенный модуль управления оргструктурой, о котором и поговорим подробнее.
Оргструктура в Stormbpmn
Stormbpmn смотрит на оргмодель организации через свою особую призму: «Для процессов важны не подразделения и их иерархия, а роли и должности». Потому что исполняют задачи не отделы и департаменты, а работающие в них люди. Это несколько отличается от модели, принятой в большинстве ERP или BPMS, где основным строительным блоком оргмодели являются юниты, а уже в них определяются руководители и вводятся другие должности.
Сначала это кажется непривычным, но если вспомнить, что одним из приоритетов Stormbpmn является создание максимально эффективного UX, то такой подход выглядит оправданным: так можно сократить число кликов и при построении оргструктуры, и при назначении исполнителей в её контексте.
Напомним коротко, что говорится об оргструктуре в документации:
Stormbpmn позволяет моделировать оргструктуру предприятия, соединять её с ролями на бизнес-процессах и конкретными сотрудниками. Такая связь может однозначно ответить, что именно делает конкретная должность или даже сотрудник в бизнес-процессах.
Основные принципы построения оргструктуры таковы:
- у задачи может быть только одна роль;
- должность может выполнять сколько угодно ролей;
- роль может выполняться каким угодно количеством должностей;
- сотрудник может быть назначен на любое количество должностей;
- сотрудник не может быть назначен на задачу напрямую.
Давайте рассмотрим их подробнее. Во-первых, надо разобраться с ролями. На первый взгляд всё просто: согласующий, утверждающий, ответственный и так далее — что человек в задаче делает, так роль и называется. Но такой подход быстро приведёт к хаосу, потому что это слишком абстрактные роли, за которыми теряется бизнес-смысл. Например, согласующий в процессе оформления отпусков и согласующий в процессе подписания договоров с клиентами выполняют совершенно разные действия и обладают разным набором полномочий, поэтому их не следует объединять в одну роль.
Пока у вас не было оргструктуры, это было не так заметно. Но теперь, когда вы свяжете с этой ролью должности, искусственность такого объединения станет очевидна: отпуска согласуют руководители подразделений, а договоры с клиентами — юрист, коммерческий директор и главный бухгалтер. А теперь представьте, что все они связаны с одной ролью…
Итак, роль — это не исполнитель схожих по названию задач, а бизнес-функция, не зависящая от конкретного процесса и связанная с компетенцией или ответственностью. Например, финансовый контролёр, владелец продукта, работник склада и тому подобное.
Теперь наша схема становится понятнее. Действительно, в организации может быть несколько похожих подразделений, например региональные офисы: должности будут разные, а роли в процессе одинаковые. При этом вполне возможно, что какой-то сотрудник совмещает несколько должностей.
На практике может получиться, что роли почти зеркально отражают должности. Например, могут быть такие роли-должности: бухгалтер, юрист, аналитик, инженер, директор, менеджер… Для небольших и средних организаций это нормально, когда роли совпадают с зонами ответственности. В этом случае роли просто формализуют должности в терминах процессов.
Но масштаб имеет значение: в крупной организации даже в рамках одной должности появляются специализации, и это различие надо учитывать в процессных ролях. Например, один бухгалтер занимается зарплатой, другой — расчётами с клиентами, а третий — налогами. С точки зрения процессов это разные роли. Если в таком случае вы увидите роль просто «Бухгалтер», то это тревожный сигнал.
И последнее: в реальной жизни довольно часто роли персонифицируются, особенно когда человек работает в должности долго. На бытовом уровне это можно понять — так проще договариваться. «Где нам найти новую Марью Ивановну?» — может спросить гендиректор у кадровиков, подразумевая главного бухгалтера. Но организационно-ролевая модель не позволит вам назначить Марью Ивановну исполнителем задачи: допустима только роль, связанная с одной или несколькими должностями.
Практический пример
Давайте смоделируем простую организацию, которая оказывает некие сервисные услуги. Назовём её «Супер-Сервис».
Сразу следует сказать, что неявно Stormbpmn подразумевает существование единственной организации. Поэтому корневым элементом оргмодели по умолчанию объявляется руководитель.
Далее мы выстраиваем отношения подчинённости: непосредственно под гендиректором находятся финансовый и технический директор, а у них в подчинении — соответственно, финансовый и технический департаменты.
Важное замечание: оргмодель Stormbpmn имеет целью связать должности с сотрудниками и процессными ролями. В этом контексте сами подразделения не очень-то важны — вы же не можете назначить департамент или отдел исполнителем задачи, верно? Поэтому подразделения моделируются просто как группы, как уровень агрегации.
Итак, наша оргмодель готова. Её также можно отобразить в табличном виде:
Дальше смоделируем процесс. Легенда такова: в организацию поступают заявки, которые могут касаться технических или финансовых вопросов. На первом этапе диспетчер проверяет, настоящая это заявка или просто спам, а потом, в зависимости от типа, заявки отправляются в финансовый или технический департамент на исполнение.
И главное, что хотелось показать: на каждую задачу назначается соответствующая роль (это цветные плашки), которая связана с должностью в оргструктуре (цвет тоже можно выбрать, при условии, что он серый).
В данном примере должности как раз совпадают с ролями — для простых процессов это нормально. Если представить себе процесс, более приближенный к реальной жизни, то скорее всего у вас появятся более разнообразные роли, отражающие специфику разных кейсов.
Заключение
Оргмодель в Stormbpmn решает не абстрактную организационную задачу, а вполне практическую: она связывает процессные роли с должностями и сотрудниками так, чтобы назначение исполнителей было понятным, непротиворечивым и удобным для работы. В простых процессах роли могут почти совпадать с должностями, но по мере роста организации ценность этой модели проявляется особенно заметно. Именно поэтому оргструктура — это не вспомогательная деталь, а важный слой процессного моделирования, без которого процесс быстро теряет связь с реальной организацией.
