Предпосылки вопроса
В современной практике проектирования и внедрения программных комплексов, предназначенных для автоматизации различных функций, выполняемых в коммерческих компаниях, считается самоочевидной необходимость применения BPMN и других графических нотаций бизнес-процессов.
При этом остаются без внимания следующие обстоятельства:
в открытых источниках огромное количество информации о том, как правильно «описывать бизнес-процессы» с помощью нотации, но ничего нет о том, как затем использовать «правильные описания бизнес-процессов»;
нет примеров, как на основании информации, переданной через схему, можно принять какое-то решение, или что-то спроектировать, или решить какую-то конкретную управленческую или техническую задачу;
если схема BMPN считается некоей моделью, и она служит основанием для набора свойств проектируемого программного комплекса, то должны быть примеры однозначного сопоставления элементов этой модели с конкретными свойствами или элементами программы, но таких примеров тоже нигде нет;
если BMPN является инструментом для решения определенных задач, то должна была бы сохраниться история появления такой проблемы, которую нельзя было решить другими имевшимися средствами моделирования, а также сведения о том, чего именно не хватало для решения проблемы, и, соответственно, изначально сформулированные требования к новому инструменту, однако, ничего подобного в открытых источниках не найти.
Все выше перечисленное касается других нотаций тоже.
Процесс и система
Любой процесс, в том числе бизнес-процесс, всегда представляет собой непрерывную последовательность смены состояний определенной системы. Результат работы системы всегда оценивается по ее состоянию на определенный момент – абсолютному, или относительно к состоянию на другой момент. Состояние системы, взятое в определенный момент, характеризуется совокупным состоянием ее элементов, взятых на тот же момент.
Бизнес-система и бизнес-процесс
Система, смену состояний которой описывает бизнес-процесс (далее для простоты – бизнес-система) – это логическая система, включающая в себя исчисляемую совокупность информационных элементов, в которой каждый элемент с необходимостью является либо аргументом (основанием), либо значением (следствием) определенной функции, входящей в набор свойств рассматриваемой системы. В бизнес-системе функцией будет являться всякий, имеющий собственный смысл набор норм, применительно к определенному информационному элементу. Ниже в таблице для примера в упрощенном схематичном виде представлены некоторые функции бизнес-системы коммерческого банка:
Аргумент функции (основание) | Значение функции (следствие) | Что будет являться функцией |
Заявление клиента на получение кредита | Решение банка о возможности выдачи кредита | Методика оценки кредитоспособности заемщика |
Новый кредитный договор с клиентом физическим лицом | Запись на соответствующую сумму по дебету счета 455 и по кредиту, например, 40817, в регистрах бухгалтерского учета | Соответствующие нормы бухгалтерского учета |
Управляющая система
Управляющей системой по отношению к бизнес-системе является физическая система в виде группы индивидов, которая определяет значения вероятностных параметров для функций причинных связей в данной бизнес-системе. Указанные вероятностные параметры являются результатом оценочной работы управляющей системы и чаще всего имеют форму признака (атрибута) конкретного информационного элемента, который классифицирует данный элемент как основание для целевой функции. Иными словами, можно также сказать, что результат оценочной работы – это область определения для некоторой функции.
В приведенных выше примерах функций оценочным параметром будет являться признак, означающий успешный факт проверки назначенным сотрудником конкретного заявления или договора на соответствие всем критериям. Таким образом, примерами результатов оценочной работы управляющей системы для бизнес-системы могут послужить любые контрольные резолюции, распоряжения, согласования, решения уполномоченных органов, внутренние нормативные документы и т.д.
Модель бизнес-процесса
Состояние бизнес-системы всегда определено совокупным действием следующих факторов:
свойствами системы (функции, заданные для установления причинной связи между элементами разных типов),
набором значений оценочных (вероятностных) параметров для каждого случая применения функции причинной связи, и
состоянием элементов других систем, являющихся аргументами для функций данной бизнес-системы.
Соответственно, чтобы получить модель бизнес-процесса, необходимо смоделировать последовательный ряд смены соотношений указанных выше трех факторов.
Что моделирует BPMN
Если в BPMN
основным элементом моделирования является объект «Действие» (по смыслу можно соотнести с физической характеристикой работы, выполняемой для реализации функции причинной связи, но нельзя четко сопоставить с самой функцией), а
основным видом моделируемого отношения является хронологическая последовательность, то
единственное, что может показать схема в такой нотации, это – частный случай организационно-технологического сценария выполнения работы в отношении некоторого нечетко определенного набора информационных элементов. Почему частный случай, потому что такая нотация с одной стороны, не гарантирует, что других сценариев не может быть, а с другой – что описанный сценарий выполняется с логической необходимостью.
Поскольку в BPMN отношение причинности подменяется отношением последовательности, что является логической ошибкой (после – не значит вследствие), то её средствами нельзя полноценно смоделировать последовательный переход между состояниями системы.
Программный комплекс – логическая система
Любой программный комплекс представляет собой также логическую систему (общее свойство с бизнес-системой), состоящую из следующих элементов:
регистров хранения значений информационных элементов определенных типов и структуры с определенными свойствами;
логических и расчётных функций;
процедур;
интерфейсов для ввода оценочных (вероятностных) параметров функций;
интерфейсов для вывода значений функций в роли сигналов для управляющей системы.
С помощью свойств регистров и функций программного комплекса можно смоделировать отношения причинной связи, существующие между элементами бизнес-системы. Тогда для проектирования этого программного комплекса необходимо иметь информационную модель бизнес-системы, выражающую свойства элементов последней через свойства сопоставленных с ними информационных элементов.
Информационная модель
Ниже приведен примерный набор видов отношений, с помощью которых можно смоделировать свойства и состав бизнес-системы на информационном языке:
отношение включённости информационных объектов:
Элемент | Включающая информационная совокупность | Условие включения |
отношение подчинения:
Элемент | Обобщающий класс объектов для данного элемента | Условие отношения к классу |
отношение свойства:
Элемент | Атрибутом какого объекта является | При каких условиях |
отношение основания:
Элемент | Источник значения | Условие присвоения |
отношение состояний:
Состояние информационного элемента/совокупности | В какое состояние может перейти из данного состояния | Условие перехода |
функции:
Функция | Вызывающее событие | Аргумент функции |
С помощью информационной модели, сформулированной в терминах перечисленных выше отношений, можно однозначно определять свойства проектируемого программного комплекса. При этом важно логически разделять понятия:
саму бизнес-систему,
управляющую систему,
и программный комплекс, моделирующий свойства бизнес-системы.
Смешивание указанных систем и их свойств будет является источником логических ошибок, что и происходит в нотации BPMN.
Использование BPMN – карго-культ
BPMN, как и любая нотация бизнес-процессов, не позволяет передать ни один из видов отношений, перечисленных выше, и поэтому не может однозначно определять свойства проектируемого программного комплекса. То есть, имея модель BPMN, либо все равно придется делать информационную модель отношений, либо разработка будет вестись беспорядочно и хаотично с высоким уровнем затрат на переделку возникающих несоответствий функционала свойствам бизнес-системы, что чаще всего и происходит на практике.
Применение нотаций бизнес-процессов, в частности BPMN, очень похоже на карго-культ. Те, кто скажут, что знают «успешные примеры» применения нотации, не смогут показать, что успех этот был следствием именно использования нотации, и что успеха не было бы или он был бы меньше, если бы нотацию не использовали. Те, кто скажут, что неудача проекта была в том случае, когда использовали «не ту нотацию», или когда не было «описания бизнес-процессов» или «бизнес-процессы были описаны неправильно», не смогут показать, что эта неудача не была следствием совсем другой причины. Обстоятельства использования или не использования BPMN являются только сопутствующим явлением, а не причиной достижения или не достижения поставленной цели в проекте.
Среди основных факторов, способствующих распространению карго-культа по использованию нотаций вроде BPMN, можно назвать следующие:
за счет «красивости» схем, похожих на описание алгоритмов и наличия строгих «правил рисования», возникает иллюзия высокого уровня формальности и определенности;
эффект наглядности – большинство людей думают, что если наглядно, значит эффективно, при этом упуская из виду, что наглядная по форме информация совершенно не обязательно ценная по содержанию;
в силу сложившихся норм распределения ответственности между участниками проекта по разработке программного комплекса, у проектировщика всегда есть соблазн зарисовать механически умозрительную схему со слов пользователя, чем вникать в характер отношений между элементами бизнес-системы и затем моделировать их на информационном языке;
в силу сложившейся традиции корпоративного управления, когда новые функции в компании распределяются между структурными подразделениями не по объективным признакам, а путем «договорённостей» и «согласований» между их руководителями, последние хотят видеть будущие свои обязанности и обязанности «соседа» на самом раннем этапе проектирования, опять же впадая в логическую ошибку, полагая, что трудовые обязанности пользователя определяют свойства программного комплекса, а не наоборот.
Вывод
Если отказаться от использования BPMN и других графических нотаций для описания процессов, а вместо этого применять для моделирования бизнес-систем такие понятия как:
информационный элемент,
информационная совокупность,
класс,
атрибут,
состояние,
условие,
функция,
то можно сократить в несколько раз количество ошибок при реализации проекта, количество ресурсов и сроки внедрения.
При этом форма моделирования не играет критической роли, вполне достаточно табличных средств, но для большого объема нужны хорошие средства индексирования элементов модели.