Комментарии 62
Если отказаться от использования BPMN и других графических нотаций для описания процессов, а вместо этого применять для моделирования бизнес-систем такие понятия как:
информационный элемент,
информационная совокупность,
класс,
атрибут,
состояние,
условие,
функция,
то можно
получить нечеловекочитаемый документ, который не сможет согласовать заказчик всей этой автоматизации
не вижу проблемы придать человекочитаемую форму документу, содержащему четко структурированную информацию
Это и есть нотация, подобная BPMN :)
Человеки плохо держат в уме абстрактные сущности, имеющие нифига не абстрактные связи, взаимное влияние и координаты во времени/логике.
Это все оч оч оч сложно для нашего мозга. А когда нужно ознакомиться с целой системой таких сущностей, да и не одной, да еще и за короткое время, да еще и с возможностью качественного анализа и сравнения... все, финита.
При этом наш мозг отлично заточен на обработку графической информации и выжимания максимума полезной нагрузки из картинки.
По этому условная круговая диаграмма для нас эффективнее сухой таблицы с числами. По этому и графические нотации эффективны.
Больше половины людей - визуалы. Чтение схемы занимает намного меньше времени, чем документа, как бы он хорошо написан не был.
И да, есть системы, которые из схемы bpmn рожают документацию для сотрудников.
А как вы относитесь к графическим методам решения математических задач? Тоже от лукавого? :-)
Возможно, надо идти дальше и применять сразу аппарат категорий. Потому что с обычными классами, логикой и предикатами первого порядка не получится почти никуда не уехать в описании процессов, бизнесов и вообще человеческого. Дебет с кредитом свести - да, а вот понять, почему процесс подвис в воздухе и никто не среагировал и не ответил - нет.
BPMN никому не нужна сама по себе. Но с её помощью как минимум можно:
сделать формализацию в общедоступном виде;
наглядно документировать процессы и далее обучать новых сотрудников;
настраивать BPM/ECM системы, особенно если они lowcode.
Bpmn на имеет никакого отношения к разработке программных комплексов, не удивительно что он плох в этом смысле и что его не хватает, чтобы понять что делать ( не функций, не правил, не классов, не атрибутов там нет).
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 не уместен в каком-то месте, то не кажется.
Понятие "действие" очень нечеткое, контекстуальное, и из-за этого неоднозначное, и понятие "последовательность действий" тоже. То есть нет общего базиса, относительно которого мы могли бы классифицировать "действия". Поэтому определение процесса через действия и последовательности несет риск разночтений, неточностей и ошибок при принятии каких-либо решений на основании таких описаний. Предложенное мной определение через состояния лишено таких недостатков.
Согласен, это и есть та методологическая часть, которая местами сроди магии и в которую очень сложно попасть. Но я в этом не вижу проблемы- ну есть разночтения, ну взял их устранил, уточнив описание или типа такого
Понятие состояние ровно столь же неоднозначное, одно и то же состояние "реального процесса" может быть описано множеством способов, во множестве разрезов. Но самое неприятное, описание эти самых состояний в коде и их поддержка очень быстро становиться "адом", поскольку необходимо учитывать все состояния при создании нового или изменении существующего.
По ходу прочтения складывается впечатление, что вы задались целью объяснить несостоятельность BPMN любой ценой. :)
Отсутствие общего языка между Бизнесом, Бизнес Аналитиком и Разработчиком приводит к неверной инерпретации поставленной задачи. Как следствие - результат отличается от ожиданий заказчика.
Для меня BPMN - это как раз тот самый общепонятный язык.
BPMN не уникален.
Еще помогают в понимании timeline, class, ERD диаграммы, но к статье не относятся.
Другое дело - BPMN Engine, на который вы ссылаетесь.
Да, действительно BPMN Engine помогает в некоторых задачах, но зачастую и BPMN диаграмма достаточна.
Насколько сложные бизнес-процессы вам доводилось автоматизировать?
Смысл моей заметки как раз в том, чтобы обратить внимание на логическую ошибку, которая возникает когда предметом автоматизации считают бизнес-процесс. Ошибка заключается в абсолютизации и опредмечивании сущности, которая не может быть самостоятельной. "Процесс" - это служебное слово, имеющее смысл только в составе сочетания "процесс чего-то". Процесс - как ход изменения состояния чего-либо есть результат выполнения либо заранее запрограммированных команд управляющей системы, либо актов реакции на какие-то внешние воздействия, в том числе случайные. Если смотреть на процесс с этой точки зрения (а в этом есть смысл), то некорректно говорить об автоматизации результата выполнения команд. Автоматизируются операции, выполняемые с каким-то предметом, в случае бизнес-процесса - с информацией.
уровень сложности - это различные участки работы банка и лизинговой компании, например, система обработки платежей, система учета договоров, кредитный конвейер, система документооборота и др.
А можно краткий пример описания бизнес-процесса в нотации BPM и в том, что описано тут?
можем сделать так: вы пришлете ссылку на интересующую вас схему, а я подготовлю модель отношений с пояснениями
https://infostart.ru/upload/iblock/330/330b8f0326f48225c8892194f8eb2241.png
Вот вроде довольно простой пример.
да, простой, если не успею в будни, то на выходных сделаю и скину
сначала пара недостатков представленной схемы, которые сразу бросаются в глаза
1. Схема не дает информации, ведется ли в компании контроль статуса заказа покупателя.
2. Схема не гарантирует, что запрос в отдел закупки не будет выполнен, если товар есть в наличии.
3. Также не гарантирует, что запрос будет выполнен, если товара нет в наличии.
4. Схема не дает информации, как связан результат функции резервирования с учетом товара.
таким образом схема не несет самой важной информации для бизнес-процесса, а только дает «детское»объяснение как все работает. Невозможно представить ситуацию, в которой на основании этой схемы можно что-то предложить или изменить или принять какое-то решение.
на самом деле информационная модель бизнес-системы может быть следующая:
информационные элементы / информационные совокупности:
Товар – для учета движения и наличия товара,
соответственно учет движения Товара нужен в разрезе: покупателей, поставщиков
скорее всего понадобится следующее деление товара по категориям: в наличии, резерв, ожидает поставки.
Соответственно условия перехода товара между категориями будут зависеть от соответствующей характеристики сущности Заказ покупателя и Заказ поставщику, а также от их статусов.
Заказ покупателя – учет понадобится в разрезе покупателей, в разрезе менеджеров (для системы мотивации)
Состояния Заказа покупателя: получен, ожидает отгрузки, ожидает поставки, выполнен
Заказ поставщику – в принципе аналогично со своими особенностями, учет в том числе в разрезе поставщиков
Запрос на закупку отличается от упомянутых выше сущностей тем, что она может не быть самостоятельной сущностью. Если Заказ покупателя и Заказ поставщику – сущности для учета параметров взаимодействия с другими бизнес-системами, то Запрос на закупку – это внутренняя опосредованная сущность и может моделироваться через отдельное состояние самого Заказа поставщику. В данном случае, Запрос на закупку выполняет контрольную функцию для обеспечения разделения ответственности между работниками (участниками управляющей системы)
такой контроль моделируется через условие на Заказ на поставщику:
для бумажной технологии: полномочия подписи Заказа поставщику и подписи Заказа покупателя – взаимоисключающие
для электронной технологии (аналогично) функция создания объекта Заказ покупателя и Заказ поставщику взаимоисключающие в разрезе учетной записи пользователя.
Если мы хотим автоматизировать, то:
Функция резервирования: что делает: уменьшает категорию товара в наличии и увеличивает категорию товара зарезервированного на одну и ту же величину, инициирующее событие: переход Заказа покупателя в состояние «принят». Аргумент функции – количественная характеристика элемента Товар в Заказе покупателя
Если мы не хотим автоматизировать, то функция резервирования может быть описана примерно так: должен быть журнал с графами «В наличии», «Зарезервировано». «Заказано поставщику» где каждая новая запись показывает итоговое состояние. причем состояние графы Зарезервировано меняется только с состоянием В наличии. Запись сопровождается номером заказа и т.д.
все изложенное конечно можно изобразить более красиво, аккуратно и точно
основная идея, что переносим фокус с внешних несущественных признаков, таких как действие и последовательность, на логические связи элементов системы (не процесса), при наличии учета логических связей и свойств элементов, можно очень быстро моделировать любые изменения, в том числе автоматизацию. То есть модель должна быть такой, что взяв любой элемент, можно было одномоментно получить все его вхождения в состав сущностей, для какого элемента он является условием, а для какого – следствием и при каких условиях
Спасибо! Критика bpmn - это верно, у нотации много недостатков и делать из нее (карго)-культ и выдавать за панацею неправильно. Но как модель и абстракция bpmn работает. Ваши же заявления в финале с пролегоменами системы описания процессов как раз и демонстрируют, насколько тяжелым будет построение идеальной альтернативы нотациям такого типа.
TL:DR: бпмн и все остальные нотации плохие, я придумал новую нотацию, правда, не для людей
Во многом согласен с автором, но.
У диаграмм, схем (любой нотации) главный критерий - наглядность.
Это вспомогательная функция, при описании систем, процессов. Да, рулят таблицы, но кто же их читает)
Поэтому, например, заказчику проще увидеть ошибку, противоречие на схеме, чем в глядя в многобукв.
BPMN и другие нотации нужны, но без фанатизма.
Критикуешь? - предлагай.
Какие есть другие методики описания бизнес процессов, чтобы:
было понятно и менеджменту и разработчикам
Чтобы были готовые программные средства для визуализации
?
Мы рассматривали разные варианты - BPMN, ArchiMate, UML, просто вордовские документы и текстовые описания, IDEF*. В результате остановились на UML + текстовое описание.
Было бы интересно услышать мнение автора, какие альтернативы он считает наиболее кошерными.
UML наиболее приближена к тому, что предлагаю я, но я в ней вижу избыточность и опять же логическую ошибку в смешивании физических действий с информационными сущностями. Я не то чтобы критикую, просто хотел объяснить проблематичность всех популярных языков моделирования. К сожалению, за долгие годы работы в сфере "управления бизнес-процессами" и "автоматизации бизнес-процессов" не встретил ни одного примера, который бы говорил в пользу применения этих языков. А предложение, косвенно подразумеваемое в заметке, заключается в том, чтобы изменить предмет моделирования: чтобы не описывать бизнес-процессы, а моделировать систему, свойства которой однозначно определяют процесс. То есть процесс - это вторичное, а мы сразу пытаемся смоделировать это вторичное, минуя его основания.
менеджменту будет понятно, если мы четко скажем какие параметры будут у системы: ее производительность, какими механизмами гарантируется защищенность от ошибок, какие ресурсы нужны для ее сопровождения. При желании эти параметры детализируются
разработчикам по имеющемуся у меня опыту понятны термины объектов, состояний, атрибутов, информационных сущностей и т.д.
Ставим лайк если пришли сюда по ссылке от Дениса Котова (самый известный в России человек, продвигающий BPMN)
А я хотел написать про Котова тоже. Походу автор статьи хотел для всего bpmn использовать, но для описания всего bpmn не подходит, а только для бизнес процессов.
Ещё есть книжка от ассоциации практиков процессного управления — bpm cbook.
Простота bpmn, обманчива, вроде 3-4 символа изучил и можно описывать процессы. Но если в ваших статьях вы не читали про токены и экземпляр процесса, то это были лишь вводные материалы и нотацию вы не знаете.
Поэтому лучше по больше поизучать, покапать.. Котов Денис bpmn2.ru, bpm cbook.
Если отказаться от использования BPMN и других графических нотаций для описания процессов, а вместо этого применять для моделирования бизнес-систем такие понятия как:
информационный элемент,
информационная совокупность,
класс,
атрибут,
состояние,
условие,
функция,
Очень похоже на конечный автомат, для которого тоже, кстати, есть визуальная реализация, которая имеет хорошее применение - Corezoid
Судя по выводам, автор решил изобрести UML вместо BPMN.
Ощущение, что есть некий негативный опыт применения BPMN без должной подготовки, знания его назначения или разочарования из-за исходно завышенных ожиданий.
Могу предложить автору познакомиться с понятием цель моделирования и попытаться использовать BPMN для выявления пользовательских задач (для начала хотя бы) процессов, которые лягут в основу проектирования системы. Т.е. 1 прямоугольник - 1 пользовательская задача. Цепочка таких задач составляют процесс.
Любая система имеет много проекций. BPMN помогает только в описании проекции процессов деятельности, где, внезапно, может не использоваться ни одна инфосистема, а то и использоваться далеко не одна.
спасибо, негативный опыт отсутствует, завышенных ожиданий тоже не было, потому что я понимал, что с помощью такой нотации можно делать, подготовка тоже есть нормальная) мой подход в том, чтобы в основу проектирования системы брать не процессы (которые в том числе являются следствием применяемой технологии), а свойства бизнес-системы. И не использовать такие понятия как "пользовательская задача".
Мы используем Хаск-модель Зайцева (ioHasC) весь продукт декомпозируем на информационные графы в логистическом формате, где начало графа — это позиция того что имеем, конец графа — это цель и маршрут — как из А попасть в Б. Я сокращено это назвал АБВ (point A, point B, Way). Такой формат понимают и аналитики и дизайнеры и программисты и даже не имеющие отношение к решению люди, он прост, понятен и универсален, так как в этом формате можно описать любые процессы, алгоритмы, продукты, договора, интерфейсы и тд. Так же ABW является техзаданием, частью бэклога и даже документацией и комментариями к коду и дизайну. Не понимаю, зачем люди себе усложняют жизнь используя чужие методики )))
Объясни мне как сделать так, чтобы бизнес процесс был сразу понятен всем кто с ним сталкивается? Разработчику, аналитику, тестировщику, директору, пользователю? В виде таблиц и описаний? Да ты с ума сошёл. Всегда, абсолютно всегда, самой понятной структурой является картинка с кубиками и стрелочками. Такие штуки рисовали ещё в каменном веке на скалах древние люди. Это и есть bpmn. Точнее bpmn это одна из разновидностей, но суть не в этом.
Я недавно пытался описать сложный бизнес процесс в коде, получилось некое подобие движка бизнес процессов. И очень быстро оказалось что поддерживать и развивать это без визуального редактора невозможно. Тогда мы быстро перешли на готовый инструмент bpmn.
Мне как дизайнеру ваши схемки абсолютно не понятны, (вы их уже привыкли строить, поэтому топите за схемки), но заполнить таблицу последовательности действий я могу и мне это просто. А по фен-шую делается эксперимент, берутся 3 разных бизнес-процесса и описываются разными способами, а потом тестируется понимание на разных пользователях. Сразу уберётся весь судейский субъективизм, с которым мы так боремся в автоматизации процессов :)
Будет прикольно посмотреть как ты думаешь заполняешь таблицу последовательности действий со сложными ветвлениями в зависимости от условий.
Я кстати не привык строить схемы, но это единственная возможность понять что вообще происходит.
Текущие схемы не понятны не из-за визуальной формы, а из-за информационной неполноты. Графы тоже визуально отображаются в виде DAG-графов, это тоже схемы, просто без циклов. Смысл ioHasC в уходе от функционального описания к информационному, с указанием целей.
В схеме bpmn есть: клиент —> принятие заявки —> регистрация заказа —> принятие оплаты —> доставка —> закрытие заказа.
В ioHasC: Получить данные от пользователя —> Проверить наличие товара —> Получить оплату от пользователя —> Доставить товар
вообще, разработчика, аналитика, тестировщика, директора и пользователя будут интересовать совершенно разные аспекты, поэтому для меня странно предоставлять всем этим людям одинаковую информацию
Никто специально никому ничего предоставлять не будет. Ни у кого нет времени делать 10 разных схем и мапить их друг на друга. Есть одна схема, оркестрирующая бизнес процесс, и она либо понятна, либо не понятна. Если она в виде визульных кубиков со стрелочками, к бабке не ходи, что это а сто раз понятнее любого текстового описания без картинок.
Предпосылки кажутся некорректными:
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 крутая штука, если использовать ее по назначению и не добавлять ей новых смыслов. Она потому и простая в освоении нотация, потому, что в ней многого нет. А то, что есть позволяет решать некоторые задачи. Поэтому я все-таки не стал бы отказываться от нее.
просто я и есть бизнес-аналитик с приличным стажем) и с обязанностями своими всегда справлялся как минимум не менее успешно, чем другие бизнес-аналитики) оптимизацией бизнес-процессов занимался 10 лет, могу сказать, что собаку съел и не одну, в том числе выступал со стороны заказчика в оптимизационных проектах, где исполнителями были все самые крупные консультанты: макинзи, прайсы, янги, делойты. Знаком со всеми известными методиками, и не только для чайников) это я к тому, что содержание этой настоящей заметки не родилось в одночасье, а формировалось годами из своего и чужого опыта и из методических материалов, все не с бухты барахты, за каждым предложением в черновиках еще по 10 предложений осталось) над этой заметкой я работал недели две чистого времени)
Ссылка на статью для чайников - это не вам в укор, это первое, что попалось в гугле:) Так что прошу прощения, если зацепил.
То что для проектирования систем нужно ее описание более комплексное, чем дает BPM-схема процесса - без сомнений. Но вины BPMN тут нет. Даже не представляю, как только с помощью схемы процесса можно проектировать какие-то решения.
Предложенная информационная модель подходит для структурирования предметной области при ее исследовании, но и ее, как мне кажется, будет недостаточно для проектирования системы.
Я бы добавил к ней таблицу сценариев использования со ссылками на элементы модели. Так в модели появится некоторая динамика и понимание последовательности смены состояний и отношений ее элементов.
Вы слишком много хотите от обычной схемы)) Я лично bpmn использую исключительно для согласования верхнеуровнего описания автоматизируемого процесса, а даже уже идёт все то что вы перечисляет имя этому BRD и Functional/System specification. Не знаю от чего у вас такой зуб на BPMN его плюс в его простоте, например тот же IDEF0 который мне лично нравится больше гораздо сложнее для восприятия не подготовленного человека, а BPMN понимают почти все. Ещё важно понимать что в каждом проекте я сам описываю используемые элементы и их описание.
у меня нет зуба на BPMN) просто я считаю согласование такой категории как "верхнеуровневое описание автоматизированного процесса" некорректным действием, потому что процесс - это следствие свойств системы, но один и тот же по форме процесс при определенным условиях может быть следствием свойств разных систем. Поэтому, логическая ошибка может возникнуть, когда мы перейдем от следствия к основанию, но у этого основания окажутся еще и незапланированные негативные для нас следствия.
Если автоматизированного то да в этом смысла никакого нет, а если автоматизируемого, то схема очень неплохо снижает риски непонимания всеми участникам бизнес процесса итог по моему 12 летнему опыту стейкхолдеры обычно не имеют понятия о собственном процессе что создает огромные риски недокументированных требований
у меня тоже похожий опыт 13 лет) здесь я бы посоветовал разделять, что именно не понимают стейкхолдеры: технологию, методологию, или назначение отдельных элементов системы внутреннего контроля, поскольку все вместе они и определяют в конечном итоге процесс, но природа этих составляющих разная, а когда процесс "описывают", эти понятия смешиваются и информация о причинных связях теряется, из-за чего задачи могут решаться не очень эффективно
Система, смену состояний которой описывает бизнес-процесс (далее для простоты – ) – это логическая система, включающая в себя исчисляемую совокупность информационных элементов, в которой каждый элемент с необходимостью является либо аргументом (основанием), либо значением (следствием) определенной функции, входящей в набор свойств рассматриваемой системы.
Для кого пишутся подобные тексты?) Для избранных которые в теме? Для избранных которые могут из этого составить четкую картинку? А остальным типа меня что делать?
например, бизнес-система может включать в себя такие элементы: заказы, платежи, акты, договоры, графики, классификаторы и т.д. Где например, определенный статус платежа будет является основанием для перевода заказа в нужный статус. Или платеж будет являться следствием договора и т.д. Установление причинно-следственной связи между конкретными элементами выполняется с помощью функций. Например, это могут быть правила бухгалтерского учета: для каждого основания в виде договора или платежа или акта должна быть сделана определенная запись.
А я вот тихо мечтаю о времени, когда аналитики хотя бы какой-то спецификации будут придерживаться в своих "диаграммах".
В реальности я ежедневно встречаюсь с тем, что Visio используется аналитиками и, чего уж греха таить, нередко и архитекторами, как некий графический редактор с набором готовых пиктограмм где не существует никаких правил для визуализации своих фантазий.
Самое смешное, что чем больше картинок, "розовых слонов" и всякой дичи на представляемых "диаграммах", тем радостнее и живее они воспринимаются бизнесом.
Вы скажете, это не уровень...
Был у нас один "архитектор", который особо напирал на подобные методы создания диаграмм. Ушел уже давно. Консультировать одну очень крупную компанию в области финансовых решений :-).
Я подумываю, может начать собирать коллекцию "народного творчества" на ниве диаграммостроения?
Добрый день. Принятие решения об использовании того или иного средства (использования артефакта в пакете прочих документов) зависит от целей. Проектирование и внедрение программных комплексов, предназначенных для автоматизации различных функций это большой процесс, предполагающий наличие артефактов самого разного уровня. Начиная от высокоуровневых требований, заканчивая конкретикой для программиста / дизайнера.
Вопрос, из статьи не очень понятно для каких именно целей, на каких этапах разработки/внедрения, использовалась bpmn и это оказалось лишней тратой времени.
в моей практике bpmn использовался на этапе подготовки и согласования BRD
не совсем понятно, как артефакты делятся по уровням. Если мы говорим об информационных элементах, то любой элемент может (в определенном контексте) входить в состав другого. Если мы говорим про моделирование свойств системы артефактами программного комплекса, то наверно там не будет полного совпадения уровней да и особо незачем их сравнивать
конкретика для программиста / дизайнера должна иметь четкое сопоставление с элементами информационной и бизнес-системы, то есть таким образом, чтобы в любой момент можно было получить ответ, какими элементами программы реализуется данная функция бизнен-системы и наоборот, какие элементы системы и ее свойства обеспечивает данный артефакт
на этапе подготовки и согласования BRD, bpmn неплохо может себя проявить, если использовать его вкупе с другими вариантами описаний БП. Все таки мне нравится опираться на цели деятельности, кто будет читать итоговый документ и для чего. Банально, знаю людей которые очень плохо воспринимают текст и очень хорошо воспринимают схемы. Не совсем верно будет заявлять что от bpmn следует отказаться. И не совсем верно - заявлять что надо использовать во что бы то ни стало. Скорее к конкретному проекту - конкретное решение. Было бы интересно прочитать продолжение статьи с примерами. Например берем кейс, вот мы сделали визуал и не видим это, это, это. А вот мы сделали по другому - документ читабелен для всего круга заинтересованных лиц, потому что... Может это некорректное сравнение, но допустим человек который провел свою жизнь в жарких странах искренне недоумевает зачем нужна автомобилю какая нибудь шипованная резина, и тем она плохо и этим - отказаться от нее кажется наилучшим решением. Если такой человек планирует оставшуюся жизнь жить также в жарких странах - то это единственное верное решение. Но если волей случая его занесет еще куда, то хорошо если он будет знать об альтернативах и использовать эти знания.
Готов подписаться под каждым словом в этой статье. Более того, уже год собираю команду единомышленников для разработки системы киберуправления деятельностью на подобном принципе. Уже есть несколько единомышленников ( очень известные люди в узких кругах), и самое главное, - есть технологическая платформа, которая целенапавленно разрабатывалась конкретно под эту задачу более 20 лет.
GreedyMan, как можно с Вами связаться? Хотелось бы обсудить возможность сотрудничества.
если вы не шутите и не разыгрываете меня, а я не исключаю этого, потому что наверняка может возникнуть соблазн, если видишь что-то совсем непохожее на общепринятое, то, например, в телеграме я lesokolov. Я, правда, не знаю, можно ли здесь делиться контактами, не нарушает ли это правил сообщества. И пока конечно не представляю, чем бы я мог помочь, но пообщаться не против)
Почему следует отказаться от BPMN