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