Предпосылки вопроса
В современной практике проектирования и внедрения программных комплексов, предназначенных для автоматизации различных функций, выполняемых в коммерческих компаниях, считается самоочевидной необходимость применения BPMN и других графических нотаций бизнес-процессов.
При этом остаются без внимания следующие обстоятельства:
в открытых источниках огромное количество информации о том, как правильно «описывать бизнес-процессы» с помощью нотации, но ничего нет о том, как затем использовать «правильные описания бизнес-процессов»;
нет примеров, как на основании информации, переданной через схему, можно принять какое-то решение, или что-то спроектировать, или решить какую-то конкретную управленческую или техническую задачу;
если схема BMPN считается некоей моделью, и она служит основанием для набора свойств проектируемого программного комплекса, то должны быть примеры однозначного сопоставления элементов этой модели с конкретными свойствами или элементами программы, но таких примеров тоже нигде нет;
если BMPN является инструментом для решения определенных задач, то должна была бы сохраниться история появления такой проблемы, которую нельзя было решить другими имевшимися средствами моделирования, а также сведения о том, чего именно не хватало для решения проблемы, и, соответственно, изначально сформулированные требования к новому инструменту, однако, ничего подобного в открытых источниках не найти.
Все выше перечисленное касается других нотаций тоже.
Процесс и система
Любой процесс, в том числе бизнес-процесс, всегда представляет собой непрерывную последовательность смены состояний определенной системы. Результат работы системы всегда оценивается по ее состоянию на определенный момент – абсолютному, или относительно к состоянию на другой момент. Состояние системы, взятое в определенный момент, характеризуется совокупным состоянием ее элементов, взятых на тот же момент.
Бизнес-система и бизнес-процесс
Система, смену состояний которой описывает бизнес-процесс (далее для простоты – бизнес-система) – это логическая система, включающая в себя исчисляемую совокупность информационных элементов, в которой каждый элемент с необходимостью является либо аргументом (основанием), либо значением (следствием) определенной функции, входящей в набор свойств рассматриваемой системы. В бизнес-системе функцией будет являться всякий, имеющий собственный смысл набор норм, применительно к определенному информационному элементу. Ниже в таблице для примера в упрощенном схематичном виде представлены некоторые функции бизнес-системы коммерческого банка:
Аргумент функции (основание) |
Значение функции (следствие) |
Что будет являться функцией |
Заявление клиента на получение кредита |
Решение банка о возможности выдачи кредита |
Методика оценки кредитоспособности заемщика |
Новый кредитный договор с клиентом физическим лицом |
Запись на соответствующую сумму по дебету счета 455 и по кредиту, например, 40817, в регистрах бухгалтерского учета |
Соответствующие нормы бухгалтерского учета |
Управляющая система
Управляющей системой по отношению к бизнес-системе является физическая система в виде группы индивидов, которая определяет значения вероятностных параметров для функций причинных связей в данной бизнес-системе. Указанные вероятностные параметры являются результатом оценочной работы управляющей системы и чаще всего имеют форму признака (атрибута) конкретного информационного элемента, который классифицирует данный элемент как основание для целевой функции. Иными словами, можно также сказать, что результат оценочной работы – это область определения для некоторой функции.
В приведенных выше примерах функций оценочным параметром будет являться признак, означающий успешный факт проверки назначенным сотрудником конкретного заявления или договора на соответствие всем критериям. Таким образом, примерами результатов оценочной работы управляющей системы для бизнес-системы могут послужить любые контрольные резолюции, распоряжения, согласования, решения уполномоченных органов, внутренние нормативные документы и т.д.
Модель бизнес-процесса
Состояние бизнес-системы всегда определено совокупным действием следующих факторов:
свойствами системы (функции, заданные для установления причинной связи между элементами разных типов),
набором значений оценочных (вероятностных) параметров для каждого случая применения функции причинной связи, и
состоянием элементов других систем, являющихся аргументами для функций данной бизнес-системы.
Соответственно, чтобы получить модель бизнес-процесса, необходимо смоделировать последовательный ряд смены соотношений указанных выше трех факторов.
Что моделирует BPMN
Если в BPMN
основным элементом моделирования является объект «Действие» (по смыслу можно соотнести с физической характеристикой работы, выполняемой для реализации функции причинной связи, но нельзя четко сопоставить с самой функцией), а
основным видом моделируемого отношения является хронологическая последовательность, то
единственное, что может показать схема в такой нотации, это – частный случай организационно-технологического сценария выполнения работы в отношении некоторого нечетко определенного набора информационных элементов. Почему частный случай, потому что такая нотация с одной стороны, не гарантирует, что других сценариев не может быть, а с другой – что описанный сценарий выполняется с логической необходимостью.
Поскольку в BPMN отношение причинности подменяется отношением последовательности, что является логической ошибкой (после – не значит вследствие), то её средствами нельзя полноценно смоделировать последовательный переход между состояниями системы.
Программный комплекс – логическая система
Любой программный комплекс представляет собой также логическую систему (общее свойство с бизнес-системой), состоящую из следующих элементов:
регистров хранения значений информационных элементов определенных типов и структуры с определенными свойствами;
логических и расчётных функций;
процедур;
интерфейсов для ввода оценочных (вероятностных) параметров функций;
интерфейсов для вывода значений функций в роли сигналов для управляющей системы.
С помощью свойств регистров и функций программного комплекса можно смоделировать отношения причинной связи, существующие между элементами бизнес-системы. Тогда для проектирования этого программного комплекса необходимо иметь информационную модель бизнес-системы, выражающую свойства элементов последней через свойства сопоставленных с ними информационных элементов.
Информационная модель
Ниже приведен примерный набор видов отношений, с помощью которых можно смоделировать свойства и состав бизнес-системы на информационном языке:
отношение включённости информационных объектов:
Элемент |
Включающая информационная совокупность |
Условие включения |
отношение подчинения:
Элемент |
Обобщающий класс объектов для данного элемента |
Условие отношения к классу |
отношение свойства:
Элемент |
Атрибутом какого объекта является |
При каких условиях |
отношение основания:
Элемент |
Источник значения |
Условие присвоения |
отношение состояний:
Состояние информационного элемента/совокупности |
В какое состояние может перейти из данного состояния |
Условие перехода |
функции:
Функция |
Вызывающее событие |
Аргумент функции |
С помощью информационной модели, сформулированной в терминах перечисленных выше отношений, можно однозначно определять свойства проектируемого программного комплекса. При этом важно логически разделять понятия:
саму бизнес-систему,
управляющую систему,
и программный комплекс, моделирующий свойства бизнес-системы.
Смешивание указанных систем и их свойств будет является источником логических ошибок, что и происходит в нотации BPMN.
Использование BPMN – карго-культ
BPMN, как и любая нотация бизнес-процессов, не позволяет передать ни один из видов отношений, перечисленных выше, и поэтому не может однозначно определять свойства проектируемого программного комплекса. То есть, имея модель BPMN, либо все равно придется делать информационную модель отношений, либо разработка будет вестись беспорядочно и хаотично с высоким уровнем затрат на переделку возникающих несоответствий функционала свойствам бизнес-системы, что чаще всего и происходит на практике.
Применение нотаций бизнес-процессов, в частности BPMN, очень похоже на карго-культ. Те, кто скажут, что знают «успешные примеры» применения нотации, не смогут показать, что успех этот был следствием именно использования нотации, и что успеха не было бы или он был бы меньше, если бы нотацию не использовали. Те, кто скажут, что неудача проекта была в том случае, когда использовали «не ту нотацию», или когда не было «описания бизнес-процессов» или «бизнес-процессы были описаны неправильно», не смогут показать, что эта неудача не была следствием совсем другой причины. Обстоятельства использования или не использования BPMN являются только сопутствующим явлением, а не причиной достижения или не достижения поставленной цели в проекте.
Среди основных факторов, способствующих распространению карго-культа по использованию нотаций вроде BPMN, можно назвать следующие:
за счет «красивости» схем, похожих на описание алгоритмов и наличия строгих «правил рисования», возникает иллюзия высокого уровня формальности и определенности;
эффект наглядности – большинство людей думают, что если наглядно, значит эффективно, при этом упуская из виду, что наглядная по форме информация совершенно не обязательно ценная по содержанию;
в силу сложившихся норм распределения ответственности между участниками проекта по разработке программного комплекса, у проектировщика всегда есть соблазн зарисовать механически умозрительную схему со слов пользователя, чем вникать в характер отношений между элементами бизнес-системы и затем моделировать их на информационном языке;
в силу сложившейся традиции корпоративного управления, когда новые функции в компании распределяются между структурными подразделениями не по объективным признакам, а путем «договорённостей» и «согласований» между их руководителями, последние хотят видеть будущие свои обязанности и обязанности «соседа» на самом раннем этапе проектирования, опять же впадая в логическую ошибку, полагая, что трудовые обязанности пользователя определяют свойства программного комплекса, а не наоборот.
Вывод
Если отказаться от использования BPMN и других графических нотаций для описания процессов, а вместо этого применять для моделирования бизнес-систем такие понятия как:
информационный элемент,
информационная совокупность,
класс,
атрибут,
состояние,
условие,
функция,
то можно сократить в несколько раз количество ошибок при реализации проекта, количество ресурсов и сроки внедрения.
При этом форма моделирования не играет критической роли, вполне достаточно табличных средств, но для большого объема нужны хорошие средства индексирования элементов модели.
Комментарии (33)
kpmy
07.08.2022 21:15+1Возможно, надо идти дальше и применять сразу аппарат категорий. Потому что с обычными классами, логикой и предикатами первого порядка не получится почти никуда не уехать в описании процессов, бизнесов и вообще человеческого. Дебет с кредитом свести - да, а вот понять, почему процесс подвис в воздухе и никто не среагировал и не ответил - нет.
pavel_raskin
07.08.2022 21:23+7BPMN никому не нужна сама по себе. Но с её помощью как минимум можно:
сделать формализацию в общедоступном виде;
наглядно документировать процессы и далее обучать новых сотрудников;
настраивать BPM/ECM системы, особенно если они lowcode.
Kotskin
07.08.2022 22:51+7Bpmn на имеет никакого отношения к разработке программных комплексов, не удивительно что он плох в этом смысле и что его не хватает, чтобы понять что делать ( не функций, не правил, не классов, не атрибутов там нет).
BPMN применяется для описания бизнес-процессов, что по описанию и является +- набором действий и их последовательностью (но не набором состояний) и определенным методологическим взглядом на то, как этот набор и последовательность сформировать и почему.
В 5% случаев при разработке софта окажется, что мы автоматизируем бизнес-процесс и можно подумать над тем, чтобы взять XML из bpmn и запихнуть в BPM-движок, но в 80% случаев хватит и FSM. Ни в каком из вариантов это не освобождает нас от описания и программирования функций, правил, классов и атрибутов.
Тем не менее BPMN в течение 12 лет разрабатывался и существует при поддержке OMG и организаций уровня HP, IBM, Accenture; они находят в его существовании ценность.
Думается, что последовательность действий и визуальный способ объяснить ее однозначно ценны сами по себе, особенно в тех организациях, которые применяют процессный подход.
В целом смысл существования Bpmn так и определен в самом стандарте:
Thus, BPMN creates a standardized bridge for the gap between the business process design and process implementation.
Ну и там же:
BPMN is constrained to support only the concepts of modeling that are applicable to Business Processes. This means that other types of modeling done by organizations for business purposes is out of scope for BPMN. Therefore, the following are aspects that are out of the scope of this specification:
• Definition of organizational models and resources
• Modeling of functional breakdowns
• Data and information models
• Modeling of strategy
• Business rules models
Так что в целом если кажется что BPMN не уместен в каком-то месте, то не кажется.
GreedyMan Автор
08.08.2022 21:33Понятие "действие" очень нечеткое, контекстуальное, и из-за этого неоднозначное, и понятие "последовательность действий" тоже. То есть нет общего базиса, относительно которого мы могли бы классифицировать "действия". Поэтому определение процесса через действия и последовательности несет риск разночтений, неточностей и ошибок при принятии каких-либо решений на основании таких описаний. Предложенное мной определение через состояния лишено таких недостатков.
Kotskin
09.08.2022 10:22Согласен, это и есть та методологическая часть, которая местами сроди магии и в которую очень сложно попасть. Но я в этом не вижу проблемы- ну есть разночтения, ну взял их устранил, уточнив описание или типа такого
nApoBo3
09.08.2022 11:52Понятие состояние ровно столь же неоднозначное, одно и то же состояние "реального процесса" может быть описано множеством способов, во множестве разрезов. Но самое неприятное, описание эти самых состояний в коде и их поддержка очень быстро становиться "адом", поскольку необходимо учитывать все состояния при создании нового или изменении существующего.
vagon333
07.08.2022 23:46+2По ходу прочтения складывается впечатление, что вы задались целью объяснить несостоятельность BPMN любой ценой. :)
Отсутствие общего языка между Бизнесом, Бизнес Аналитиком и Разработчиком приводит к неверной инерпретации поставленной задачи. Как следствие - результат отличается от ожиданий заказчика.
Для меня BPMN - это как раз тот самый общепонятный язык.
BPMN не уникален.
Еще помогают в понимании timeline, class, ERD диаграммы, но к статье не относятся.Другое дело - BPMN Engine, на который вы ссылаетесь.
Да, действительно BPMN Engine помогает в некоторых задачах, но зачастую и BPMN диаграмма достаточна.
Hivemaster
08.08.2022 00:15Насколько сложные бизнес-процессы вам доводилось автоматизировать?
GreedyMan Автор
08.08.2022 20:34Смысл моей заметки как раз в том, чтобы обратить внимание на логическую ошибку, которая возникает когда предметом автоматизации считают бизнес-процесс. Ошибка заключается в абсолютизации и опредмечивании сущности, которая не может быть самостоятельной. "Процесс" - это служебное слово, имеющее смысл только в составе сочетания "процесс чего-то". Процесс - как ход изменения состояния чего-либо есть результат выполнения либо заранее запрограммированных команд управляющей системы, либо актов реакции на какие-то внешние воздействия, в том числе случайные. Если смотреть на процесс с этой точки зрения (а в этом есть смысл), то некорректно говорить об автоматизации результата выполнения команд. Автоматизируются операции, выполняемые с каким-то предметом, в случае бизнес-процесса - с информацией.
GreedyMan Автор
09.08.2022 22:07уровень сложности - это различные участки работы банка и лизинговой компании, например, система обработки платежей, система учета договоров, кредитный конвейер, система документооборота и др.
cudu
08.08.2022 01:47+5А можно краткий пример описания бизнес-процесса в нотации BPM и в том, что описано тут?
GreedyMan Автор
08.08.2022 20:38можем сделать так: вы пришлете ссылку на интересующую вас схему, а я подготовлю модель отношений с пояснениями
cudu
09.08.2022 17:33https://infostart.ru/upload/iblock/330/330b8f0326f48225c8892194f8eb2241.png
Вот вроде довольно простой пример.
tmplts
08.08.2022 06:03+2Спасибо! Критика bpmn - это верно, у нотации много недостатков и делать из нее (карго)-культ и выдавать за панацею неправильно. Но как модель и абстракция bpmn работает. Ваши же заявления в финале с пролегоменами системы описания процессов как раз и демонстрируют, насколько тяжелым будет построение идеальной альтернативы нотациям такого типа.
Shiaju
08.08.2022 07:34+3TL:DR: бпмн и все остальные нотации плохие, я придумал новую нотацию, правда, не для людей
dim
08.08.2022 07:51+1Во многом согласен с автором, но.
У диаграмм, схем (любой нотации) главный критерий - наглядность.
Это вспомогательная функция, при описании систем, процессов. Да, рулят таблицы, но кто же их читает)
Поэтому, например, заказчику проще увидеть ошибку, противоречие на схеме, чем в глядя в многобукв.
BPMN и другие нотации нужны, но без фанатизма.
AlexGorky
08.08.2022 12:31+3Критикуешь? - предлагай.
Какие есть другие методики описания бизнес процессов, чтобы:
было понятно и менеджменту и разработчикам
Чтобы были готовые программные средства для визуализации
?
Мы рассматривали разные варианты - BPMN, ArchiMate, UML, просто вордовские документы и текстовые описания, IDEF*. В результате остановились на UML + текстовое описание.
Было бы интересно услышать мнение автора, какие альтернативы он считает наиболее кошерными.
GreedyMan Автор
08.08.2022 20:54UML наиболее приближена к тому, что предлагаю я, но я в ней вижу избыточность и опять же логическую ошибку в смешивании физических действий с информационными сущностями. Я не то чтобы критикую, просто хотел объяснить проблематичность всех популярных языков моделирования. К сожалению, за долгие годы работы в сфере "управления бизнес-процессами" и "автоматизации бизнес-процессов" не встретил ни одного примера, который бы говорил в пользу применения этих языков. А предложение, косвенно подразумеваемое в заметке, заключается в том, чтобы изменить предмет моделирования: чтобы не описывать бизнес-процессы, а моделировать систему, свойства которой однозначно определяют процесс. То есть процесс - это вторичное, а мы сразу пытаемся смоделировать это вторичное, минуя его основания.
менеджменту будет понятно, если мы четко скажем какие параметры будут у системы: ее производительность, какими механизмами гарантируется защищенность от ошибок, какие ресурсы нужны для ее сопровождения. При желании эти параметры детализируются
разработчикам по имеющемуся у меня опыту понятны термины объектов, состояний, атрибутов, информационных сущностей и т.д.
in_heb
08.08.2022 14:05-6Ставим лайк если пришли сюда по ссылке от Дениса Котова (самый известный в России человек, продвигающий BPMN)
akurmanbay
08.08.2022 14:19Если отказаться от использования BPMN и других графических нотаций для описания процессов, а вместо этого применять для моделирования бизнес-систем такие понятия как:
информационный элемент,
информационная совокупность,
класс,
атрибут,
состояние,
условие,
функция,
Очень похоже на конечный автомат, для которого тоже, кстати, есть визуальная реализация, которая имеет хорошее применение - Corezoid
aleexp
08.08.2022 14:22+1Судя по выводам, автор решил изобрести UML вместо BPMN.
Ощущение, что есть некий негативный опыт применения BPMN без должной подготовки, знания его назначения или разочарования из-за исходно завышенных ожиданий.
Могу предложить автору познакомиться с понятием цель моделирования и попытаться использовать BPMN для выявления пользовательских задач (для начала хотя бы) процессов, которые лягут в основу проектирования системы. Т.е. 1 прямоугольник - 1 пользовательская задача. Цепочка таких задач составляют процесс.
Любая система имеет много проекций. BPMN помогает только в описании проекции процессов деятельности, где, внезапно, может не использоваться ни одна инфосистема, а то и использоваться далеко не одна.
diflux
09.08.2022 01:18Мы используем Хаск-модель Зайцева (ioHasC) весь продукт декомпозируем на информационные графы в логистическом формате, где начало графа — это позиция того что имеем, конец графа — это цель и маршрут — как из А попасть в Б. Я сокращено это назвал АБВ (point A, point B, Way). Такой формат понимают и аналитики и дизайнеры и программисты и даже не имеющие отношение к решению люди, он прост, понятен и универсален, так как в этом формате можно описать любые процессы, алгоритмы, продукты, договора, интерфейсы и тд. Так же ABW является техзаданием, частью бэклога и даже документацией и комментариями к коду и дизайну. Не понимаю, зачем люди себе усложняют жизнь используя чужие методики )))
JohnRambo
09.08.2022 15:43Объясни мне как сделать так, чтобы бизнес процесс был сразу понятен всем кто с ним сталкивается? Разработчику, аналитику, тестировщику, директору, пользователю? В виде таблиц и описаний? Да ты с ума сошёл. Всегда, абсолютно всегда, самой понятной структурой является картинка с кубиками и стрелочками. Такие штуки рисовали ещё в каменном веке на скалах древние люди. Это и есть bpmn. Точнее bpmn это одна из разновидностей, но суть не в этом.
Я недавно пытался описать сложный бизнес процесс в коде, получилось некое подобие движка бизнес процессов. И очень быстро оказалось что поддерживать и развивать это без визуального редактора невозможно. Тогда мы быстро перешли на готовый инструмент bpmn.
diflux
09.08.2022 21:02+1Мне как дизайнеру ваши схемки абсолютно не понятны, (вы их уже привыкли строить, поэтому топите за схемки), но заполнить таблицу последовательности действий я могу и мне это просто. А по фен-шую делается эксперимент, берутся 3 разных бизнес-процесса и описываются разными способами, а потом тестируется понимание на разных пользователях. Сразу уберётся весь судейский субъективизм, с которым мы так боремся в автоматизации процессов :)
JohnRambo
09.08.2022 21:34Будет прикольно посмотреть как ты думаешь заполняешь таблицу последовательности действий со сложными ветвлениями в зависимости от условий.
Я кстати не привык строить схемы, но это единственная возможность понять что вообще происходит.
meirinkun
09.08.2022 18:23Предпосылки кажутся некорректными:
1. в открытых источниках огромное количество информации о том, как правильно «описывать бизнес-процессы» с помощью нотации, но ничего нет о том, как затем использовать «правильные описания бизнес-процессов»;
Во-первых, в такой формулировке - это проблема открытых источников, а не нотации. Вы например также не пишите как с использовать правильно описанные смены состояний в ваших категориях. Во-вторых, о том как использовать BPMN-модель процесса, вам смогут рассказать бизнес-аналитики (например, при их оптимизации и автоматизации) или разработчики систем BPMS, где автоматизируются последовательности выполнения задач и проверки условий. Из своей практики, описание БП хоть в какой нотации используется для того, чтобы показать бизнесу где дыры в ответственности или чтобы сам бизнес получил формализованное представление своих процессов. На этой же схеме, например, можно очертить границы проекта автоматизации.
2. нет примеров, как на основании информации, переданной через схему, можно принять какое-то решение, или что-то спроектировать, или решить какую-то конкретную управленческую или техническую задачу;
Это расширение первого вопроса. Можно просто погуглить "оптимизация БП BPMN".
Например, вот как это делается https://bpmn2.ru/blog/optimizacia-bizness-processov
3. если схема BMPN считается некоей моделью, и она служит основанием для набора свойств проектируемого программного комплекса, то должны быть примеры однозначного сопоставления элементов этой модели с конкретными свойствами или элементами программы, но таких примеров тоже нигде нет;
Вы делаете предположения, за которое BPM-схема не отвечает. Она отвечает за то, чтобы графически отобразить бизнес-процесс. Не свойства системы, не ее свойства, ни элементы программы, а то какая последовательность действий, распределение их между участниками этого процесса и условий позволит прийти к результату бизнес-процесса.
4. если BMPN является инструментом для решения определенных задач, то должна была бы сохраниться история появления такой проблемы, которую нельзя было решить другими имевшимися средствами моделирования, а также сведения о том, чего именно не хватало для решения проблемы, и, соответственно, изначально сформулированные требования к новому инструменту, однако, ничего подобного в открытых источниках не найти.
Что BPMN, что UML и пр. создаются не добрым и светлым сообществом, а большими софтверными компаниями или консорциумами. Они, главным образом, преследуют свои цели - автоматизацию процессов в своих больших компаниях, продажу ПО для проектирования ПО, использующих конкретную нотацию. При этом всячески давят конкурентов. И иногда просто не остается выбора, какую нотацию или какое ПО для проектирования выбрать.
UML - это эхо эпохи CASE-средств от IBM, когда в 90х решили, что программисты не нужны и проектирование бизнес-ПО можно отдать на откуп менеджерам/аналитикам, которые расставили бы элементы нотации в нужном порядке. Но не задалось.
BPMN - это визуализация языка BPEL (Business Process Execution Language) от Microsoft и IBM. Язык описывал оркестрацию веб-сервисов, к нему решили прикрутить визуализатор и получилась нотация. А вот тут задалось, пользуемся (почти) всем айти:)
Проектировать ПО/системы на основании только BPMN это бесперспективно. Но тут опять же вагон подходов в т.ч. в плане нотаций - от нотации "стрелочки и квадратики" до C4 и пр.
Плюс свой отпечаток накладывает все еще популярный Agile, при применении которого, наличие обширной документации с описанием "полноценно смоделированного последовательного перехода между состояниями системы" имеет меньший приоритет. Во многом поэтому умирает UML.
По итогу, BPMN крутая штука, если использовать ее по назначению и не добавлять ей новых смыслов. Она потому и простая в освоении нотация, потому, что в ней многого нет. А то, что есть позволяет решать некоторые задачи. Поэтому я все-таки не стал бы отказываться от нее.
GreedyMan Автор
09.08.2022 22:22+1просто я и есть бизнес-аналитик с приличным стажем) и с обязанностями своими всегда справлялся как минимум не менее успешно, чем другие бизнес-аналитики) оптимизацией бизнес-процессов занимался 10 лет, могу сказать, что собаку съел и не одну, в том числе выступал со стороны заказчика в оптимизационных проектах, где исполнителями были все самые крупные консультанты: макинзи, прайсы, янги, делойты. Знаком со всеми известными методиками, и не только для чайников) это я к тому, что содержание этой настоящей заметки не родилось в одночасье, а формировалось годами из своего и чужого опыта и из методических материалов, все не с бухты барахты, за каждым предложением в черновиках еще по 10 предложений осталось) над этой заметкой я работал недели две чистого времени)
meirinkun
10.08.2022 09:16Ссылка на статью для чайников - это не вам в укор, это первое, что попалось в гугле:) Так что прошу прощения, если зацепил.
То что для проектирования систем нужно ее описание более комплексное, чем дает BPM-схема процесса - без сомнений. Но вины BPMN тут нет. Даже не представляю, как только с помощью схемы процесса можно проектировать какие-то решения.
Предложенная информационная модель подходит для структурирования предметной области при ее исследовании, но и ее, как мне кажется, будет недостаточно для проектирования системы.
Я бы добавил к ней таблицу сценариев использования со ссылками на элементы модели. Так в модели появится некоторая динамика и понимание последовательности смены состояний и отношений ее элементов.
Didimus
получить нечеловекочитаемый документ, который не сможет согласовать заказчик всей этой автоматизации
GreedyMan Автор
не вижу проблемы придать человекочитаемую форму документу, содержащему четко структурированную информацию
sunnybear
Это и есть нотация, подобная BPMN :)
Fell-x27
Человеки плохо держат в уме абстрактные сущности, имеющие нифига не абстрактные связи, взаимное влияние и координаты во времени/логике.
Это все оч оч оч сложно для нашего мозга. А когда нужно ознакомиться с целой системой таких сущностей, да и не одной, да еще и за короткое время, да еще и с возможностью качественного анализа и сравнения... все, финита.
При этом наш мозг отлично заточен на обработку графической информации и выжимания максимума полезной нагрузки из картинки.
По этому условная круговая диаграмма для нас эффективнее сухой таблицы с числами. По этому и графические нотации эффективны.