Комментарии 47
НЛО прилетело и опубликовало эту надпись здесь

Business Process разумеется. Есть варианты прочтения буквы M, но обычно все-таки management.

ну очевидно же, что это beats per minute… вообщем что-то про Управление в музыкальной индустрии )
Надеюсь мой комментарий на сочтут за грубость,
What the fuck am I reading?

Не сочтут, но может все-таки поясните, в чем проблема?


На мой взгляд, если вы скажем не поняли, о чем пост — ну так и что? Есть много разных тем, далеко не все из них должны быть понятны всем — как и интересны, впрочем.

Мне показалось, что это было намёком о том, что статью было бы предпочтительнее разместить не в «Разработке», а хотя бы в «Управлении».

Я возможно плохо сформулировал, но этот пост ни разу не об управлении. Речь идет о вполне конкретных программных продуктах, на базе которых разрабатываются BPM системы. И о том, что сама эта парадигма процессов, которые пытаются рисовать в виде картинок, очень плохо годится для того, чтобы в ней разрабатывать. А если уж совсем просто — о том, что программировать в картинках получается как правило плохо.


Так что нет, это вовсе не про управление и совсем не для управленцев.

Сама-то по себе идея идет в верном направлении, т.к. человек мыслит больше образами, чем символами. К примеру, есть вполне работоспособные прикладные реализации «программирования мышкой» типа блюпринтов в «Unreal Engine». Только тут, при взаимодействиях, идет столкновение квалификаций. С одной стороны заказчик, которому до лампочки все эти абстракции. А с другой — код таки должен решать его проблемы и без понятий, которые не засунешь в картиночки, не обойтись. Лучше старых добрых «многабукаф» пока не придумали.
(Ну как бы графика — это фича BPM) BPM — инструмент управления автоматизацией бизнес-процессов таким образом, чтобы это управление осуществлялось силами сотрудников, не имеющими образования в сфере программирования. Там, где его не хватает, появляется еще что-то для расширения (или в обход) BPM. То есть, если формат, выбранный конкретной системой не решает задачу, программировать все же придется (к примеру, для интеграции с внешними системами, или для создания не предусмотренного изначальными разработчиками пользовательского интерфейса). И это не значит, что BPM отказалась от графики. Просто в конкретном случае пилят костыли.
Я бы так ответил — есть системы, где взаимоотношения между кодом и «картинками» более правильные для разработки. Например, тот же Apache Camel, где по сути мы имеем в основе т.н. EIP, Enterprise Integration Patterns, почти такие же диаграммы, что и в BPMN.

Разница в том, что первичным является DSL (как скажем java, так и xml), из которого строится диаграмма. А когда вы хотите на нее посмотреть — вы можете это сделать в виде картинки. Вы можете их в таком виде поотлаживать, или посмотреть статистику по квадратикам. А вот редактировать диаграмму в картинках совершено лишнее.
Это статья типа ещё один что-то не понял и решил этим незнанием поделиться. Ну не смогли экземляр процесса загнать в бесконечный цикл штатными средствами или продолжить выполнение потока по триггеру/событию — спросите где-нибудь, а не пишите в духе «bpm от а до я».

Я за три с половиной года всего-то поучаствовал примерно в десятке проектов для десятка банков РФ, начиная со Сбербанка и заканчивая Тиньковым, а по дороге еще Райффайзен с РСХБ например захватили. И все еще не понял. Ну зато вы-то видимо все поняли?


Можете поделиться своими сокровенными знаниями о том, как это круто? Как легко рефакторить диаграммы? Как быстро понять, какие измеения за неделю внесли в ваш процесс? Как слить две ветки изменний? Как легко писать юнит-тесты, наконец.


Я с радостью почитаю.

Вопросы дизайна и деплоя процессов решаются ещё «на берегу» при выборе bpm-инструментария. Если процесс внесения изменений в процесс состоит из сброса графических схем программисту, то это опять же, проблема самого процесса управления процессами, а не всей управленческой концепции BPM.

Ничего не понял из вашего ответа. Вы похоже про что-то другое говорите, совсем.

Скорее всего в конечном итоге схемы процессов преобразуются в XML, который и можно сравнивать. Я работал только с одним BPM-продуктом (ELMA), готового инструментария по сравнению там, к сожалению, нет. Но сами описания схем можно выгрузить из базы и сравнить.
Можно и чайником гвозди забивать, конечно. BPM имеет очень утилитарное назначение, которое некоторые энтузиасты наивно пытаются расширить. BPM это способ абстрагировать бизнес-логику взаимодействия с системой от реализации прикладного функционала. Ошибки в проектировании архитектуры и необоснованный энтузиазм разработчиков часто соблазняют заменить саму архитектуру неким BPM суррогатом. Если Вы не консультант-аналитик, внедряющий корпоративную систему, BPM — не Ваш инструмент. Разработчик должен уметь разрабатывать сервисы, модули и компоненты, управляемые BPM.
было дело участвовал в процессе интеграции одной из этих bpmn с банковской конторой, понял так;

например приходит новый работник к большую контору, можно ему выдать кучу инструкций как и в каком порядке выполнять свою работу, слать задания по мылу, скайпу, словами и тд… но как быстро он прочитает эти инструкции и запомнит все правильно.

либо занести юзера в bpmn систему, при выдаче ему нового задания оно появляется с списке заданий юзера, по мере выполнения этапов задание будет продвигаться, этапы могут зависеть от задач других юзеров и тд…

есть общий алгоритм работы предприятия, он разбивается на подзадачи, которые могут еще более мелко делиться, юзеры выполняют свои части и в итоге типа все знают что делать, отмечают ход выполнения заданий, либо не выполнения и причину.

получается еще один способ систематизировать большую сложную систему предприятия.
ну и для начала нужно правильно составить описание все процессов и разные связи

Вы смотрите на это с другой стороны. Да, для бизнеса все возможно так и выглядит. Я же рассказываю историю с точки зрения разработчика.


Во-первых, описание большого процесса нельзя составить сразу — оно строится постепенно, от версии к версии — как любой достаточно сложный программный продукт. Во-вторых, очень желательно, чтобы повторяющиеся куски процесса можно было оформить как готовый компонент, и потом переиспользовать их в других местах.


И вот со всем этим у схемок и картинок — большие проблемы.

я участвовал как разработчик, рассказываю свое понимание зачем нужны подобные системы.

по нормальному, составлять модели бизнес процессов должны люди которые в теме работы данного предприятия, а не разработчики.

эти картинки и схемы нужны на стадии как раз составления бизнес процессов, дальше их видеть не обязательно, юзеру приходят только его задания, абстракции вобщем.

А что изменится, если составлять будут люди в теме?


дальше их видеть не обязательно

Простите, но это означает, что процесс у вас никогда не меняется. А так не бывает.


Представьте скажем вот такой простой случай — сидят у вас два человека в теме, и рисуют диаграммы. Потом вы на них смотрите, и видите, что они делают в сущности одно и тоже. В нормальной среде разработки вы можете а) сравнить два куска кода между собой б) выполнить рефакторинг, выделив повторяющиеся куски в) натравить на код анализ, который например покажет вам copy&paste.


Так вот, ничего из этого вам для диаграмм (BPMN тут частный случай, с другими все примерно также) не доступно. А код, который развивается путем copy&paste, и не рефакторится, практически неизбежно со временем становится говнокодом. И перестает поддерживаться.

>Простите, но это означает, что процесс у вас никогда не меняется. А так не бывает.

походу понимание так и не пришло,
да хоть 100 раз в неделю пусть меняется, юзерам это пофик к ним приходят конкретные задания, а что там творится с диаграммами в целом они даже могут не знать.

Юзерам это да, пофиг. А вот IT и разработчикам — вовсе нет. Вот простой кейс, ваш процесс скажем сломался. Вчера работало. Перед вами стоит задача — найти причину и пофиксить.


В случае "нормального" классического кода я вам скажу, что буду делать — я залезу в Git, и посмотрю, какие коммиты были, кто и зачем их делал, какие части системы они затронули. Я тупо сравню код, наконец. А теперь расскажите мне, как вы сравниваете BPMN? Только очень прошу — не надо про то, что это XML, потому что это НЕ xml. Если вы вынуждены лезть на уровень xml, чтобы понять, что именно изменилось в процессе — ваша IDE для разработки процессов — барахло.


И имено про такие инструменты я и пишу. Которые не умеют скажем сравнивать две версии процесса.

что значит процесс сломался, ломается инструмент которым процесс создается и отслеживается.
Процесс — это, по сути, программа, выбирающая что юзеру показать, что у него спросить. Вчера после имени клиента спрашивала фамилию, а сегодня спрашивает сразу телефон.
Я бы понял, если вы обхаяли 1C, сравнив его с другими языками программирования. Но BPM это лишь концепция, описание.

Какой вывод я для себя сделал — думаю вполне понятно. Буду держаться подальше от подобных инструментов, по мере возможности.

Я так понял, вы не будет теперь заниматься разработкой, связанной с автоматизацией бизнес-процессов?
Какой разработкой вы решили заниматься?

Вы название IBM BPM в самом начале видели? А конкретные версии? Это вовсе не концепция. Это конкретный продукт, платформа для создания систем. И все что тут написано, как вы выражаетесь, "для обхаивания" к нему относится в полной мере. Это в обсновном про него. Хотя насколько я знаю скажем Pega — там ровно тоже самое.

Да, и ответ на вопрос — отойдя в строну от решений IBM, в том числе от их "шины", которая входит в состав BPM в том числе, я практически сразу отметил для себя, что Open Source решения в данном случае совсем не уступают коммерческим. И уж точно намного удобнее в разработке. Например Apache Camel, в качестве основы для построения своей шины.


А будет позарез нужен BPM — возьму Activity. Даром. Там много чего нет, и там есть все теже присущие концепции недостатки, кстати. Но там все равно проще.

Ой, ну вот таки сразу 1С крайняя.
Вы знаете, а завидуйтека молча. 1С хают только те кто не умеет ей пользоваться. У меня она ни разу не вызывала негативных откликов. Разрабы платформы — да, язык и невероятно удобная среда разработки и отладки — нет. И многих преимуществ 1С весьма не хватает у всех остальных.

BPM может быть и концепция, но вот Oracle BPMN это уже таки реализация. И честно говоря — пост имеет своей целью «резюме».

Визуальное моделирование и выполнение бизнес-процессов — частично. Модель не отражает реальности для аналитика, и неудобна для разработчика.
Набор готовых компонент для построения гибких бизнес-процессов — нет. Средства создания компонентов неадекватны.
Поддержка версионности бизнес-процессов — частично. Средства неадекватны.

По первым двум пунктам согласен целиком, несмотря на то что работаю с продуктом Oracle. То что продается как «фишка» — участие аналитиков в разработке путем создания макета процесса, на деле оказывается сладкой упаковкой пустышки. Потому что после реализации конечная модель едва ли похожа на упрощенное представление аналитиков.
А вот простейший контроль версий, тот же Git, прикрученный к среде разработки — позволяет отследить кто когда что менял. Детали же проделанных изменений обязаны быть в сопроводительных документах. Если разработчики только меняют код, и не документируют его ни комментариями (что в BPMN нереально) ни дополнительной документаций — вините не среду разработки, а разработчиков.
Мы сравнивали много: IBM BPM, JBoss BPM Suite (jBPM), Pega, Activiti, Bonita. Кровавыми слезами разработчиков не заставляла плакать только Bonita, но и у неё есть все те же недостатки, которые описаны в статье.
еще существуют BPMN Process Simulation Tool, описывается модель процессов и запускается симуляция, это должно выявлять неоптимальные узлы.
можно выставить желаемые значения в узлы и ждать условия их появлений и тд…

Вы как будто пытаетесь меня убедить, что процессы и их формализация полезны.


Так я с этим и не спорю, что характерно. Я лишь пытался показать, что существующие инструменты работы с ними, в частности BPMN, страдают рядом принципиальных недостатков, которые мешают делать из диаграммы процесса работающий софт.

кого убеждать и зачем

>Если же у вас сложились другие впечатления о практической работе с BPM, или скажем SSIS, я предлагаю рассказать о них в комментариях, и надеюсь, что обсуждение будет нам все полезно.

вот этим я занимался и прочитать ссылку на sql.ru ниже стоит, многое прояснится
достаточно хорошо чел высказался по теме в этом сообщении, в целом там весь топик полезный имхо
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1141037&msg=18646109

Полностью согласен с изложенным. Сам неоднократно сталкивался с этой проблемой — в основном в визуальных инструментах ETL, но и в BPM системах тоже. Визуальный инструмент разработки красив на презентациях, обеспечивает быстрый quick start для людей, не имеющих опыта написания кода, но в мало-мальски сложном внедрении быстро становится ограничением — не хватает хорошей отладки, гибкости, абстракций. Кроме того, когда начинаешь дописывать код, часть системы, управляемая визуальным конструктором, обычно остается плохо документированным черным ящиком, с которым приходится работать методом проб и ошибок.


С другой стороны, понятно, откуда это все берется — любой заказчик старается избегать кода при внедрении, и для вендора проще сделать визуальный конструктор (причем в некоторых случаях реально абы-как), чем объяснять, как должен выглядеть зрелый процесс поддержки конфигурации системы.


Допускаю, что могут быть кейсы, где визуальные конструкторы хороши, но они тогда должны покрывать 95% нужной функциональности — а это точно не про enterprise внедрения.

ИМХО или автор не разобрался или работал с плохими инструментами. У BPM есть проблемы, но со статьей они коррелируются слабо.

Визуальное моделирование не преследует цель во всех подробностях изобразить процесс. Его задача мост между кодом и бизнес процессом. Всегда есть компромисс между сокрытием деталей реализации в коде и отображении их в процессе. Если мы его не соблюдаем, мы получил или не читаемый процесс перегруженный деталями реализации или не понятный процесс с целый слоем бизнес логики сокрытым на уровне кода. При разработке «классических» приложений с бизнес логикой в коде, такой проблемы нет, бизнес логика скрыта от пользователя всегда, и как это не прискорбно, очень часто представляет из себя нагромождение костылей. Почему так, потому что когда мы пытаемся формализовать процесс выплывает такая куча нюансов, что учесть их все в стройной не противоречивой модели очень и очень сложно, вот их и закапывают в код. Потом это становиться не поддерживаемой, или поддерживаемой за безумные деньги, системой. С bpm такой фокус не проходит, эта проблемы переноситься с этапа поддержки, на этап проектирования. Это вызывает множество проблем, поскольку заказчику или сразу видно, что процесс не соответствует реальности, или что не читаем и содержит костыли на каждом шагу. Такое продать сложно, проще указать в ТЗ требования, а потом реализовать их через одно место и все довольны.

По остальным пунктам, единственно что соответствует действительности, это отсутствие средств рефакторинга.
Bpmn это не диаграмма, и не графический файл, а текст, xml подобный документ, все доступное для любого текста доступно и для bpm, версионность, jira, find and replace, все естественно есть.
Нужны плагины, не устраивает IDE, нет проблем пишите плагины или вообще напишите полностью свой инструмент. Для примера BPMN можно «разрабатывать» в eclipse.
В используемом нами движке есть не только версионность процесса, на уровне git, но и параллельное исполнение процессов разных версий и средство миграции процессов с одной версии на другую.

Покрытие тестами. Хм, с тем движком с которым работаем мы bpm процесс замечательно покрывается тестами.

Оценка трудозатрат на рисование bpm диаграммы вообще странный пункт, а как вы оцениваете в своих проектах трудозатраты на документирование и описание бизнес процессов заказчика. Это собственно говоря одно и тоже, за исключение специфического языка описания.

Асинхронное взаимодействие, чем оно будет отличаться от аналогичного в «классическом» приложении? В bpm это будет выглядеть или как сервис таск плюс ожидание сообщения, или как отправка и получение сообщения. За ним стоит повесить любую очередь, хоть то же rabbitMQ. Пример с сортировкой списка вообще странный, сортировка списка не есть часть бизнес процесса, она замечательно скрывается на уровне кода.

Похоже или у автора инструменты из кровавого энтерпрайз в которых сюда нельзя туда нельзя и все посыпано сверху SAP'ом, или он не умеет их готовить.

Как мне кажется, главная проблема bpm это высокая сложность описания процесса с сохранением его читабельности. Плюс восприятие, код не нужен, что в корне не верно.


Хм. Я честно говоря, даже не знаю, что вам ответить. С одной стороны, вы вроде считаете, что автор не разобрался, и как бы возражаете ) А с другой — изложенные вами в последнем абзаце проблемы — это по сути и есть те проблемы, о которых я пытался написать, только в профиль, с другой точки зрения.


Плюс восприятие, код не нужен, что в корне не верно.

Ну вот скажем эта. Имено что код нужен, что диаграммы сами по себе не являются законченным работающим процессом. В тех процессах, что я видел и делал, кода было процентов 80% наверное. И только в виде кода можно делать компоненты, которые потом можно повторно переиспользовать — попытки делать их в виде процессов приводят к ужас-ужас.


Ну и так, для ясности — я все-таки излагал свой опыт работы на IBM BPM, и он довольно не новый (я это написал почти три года назад). Если на вашем движке сейчас все уже не так — остается только порадоваться.

Ну вот скажем эта. Имено что код нужен, что диаграммы сами по себе не являются законченным работающим процессом. В тех процессах, что я видел и делал, кода было процентов 80% наверное. И только в виде кода можно делать компоненты, которые потом можно повторно переиспользовать — попытки делать их в виде процессов приводят к ужас-ужас.


А зачем делать их в виде процессов? BPMN существует не для замены языкам типа java.

Ну как бы вопрос стоит немного иначе — при опредеделенном размере процессов (а мы на такой размер вылезали на каждом первом проекте) конструкция в целом перестает быть обозримой. Я согласен, что частично это последствия того, что у IBM (Lombardi) принято делать в виде BPMN диаграмм все подряд, включая например обработчики событий UI. И возможно на других движках все было бы приличнее. Диаграммы более компактные, логика — в java, или веб-сервисах.


Но так или иначе — повторяющиеся фрагменты процессов на практике все равно бывают, и хочется их как-то оформить. То как это можно сделать — не всегда адекватно потребностям.

Мне не приходилось внедрять BPM на практике, изучал его только теоретически — читал книги, спецификацию BPMN, смотрел продукты типа BizAgi, читал ругательные статьи о том, что BPMN не имеет под собой математического формализма, — и пытался понять, как всё это может быть мне полезно. Так что этот комментарий можно считать диванным теоретизированием.


Статья перекликается с постом The Churn by Robert C. Martin: http://blog.cleancoder.com/uncle-bob/2016/07/27/TheChurn.html Среди всего прочего, Роберт Мартин указывает на то, что всякий новый язык или технология неизбежно лишены тех средств разработки, анализа кода, тестирования и рефакторинга, что уже созданы для языков предыдущего поколения, и потому продуктивность разработки на новом языке по определению ниже. Ну, для BPM проблема усложняется ещё и добавлением дополнительных измерений, как вы указали.


А теперь следующий вопрос. А почему, собственно, нужно бросаться из крайности в крайность и отказываться от нормальных средств разработки? BPMN-диаграмма — это исполняемая программа, написанная на визуальном языке. Пользователи и аналитики в большинстве случаев не могут изменять эту диаграмму так, чтобы при этом покрывать изменения юнит-тестами и гарантировать, что в остальных частях системы ничего не сломается. Таким образом, модифицирующая функция BPM не очень работает. Но зато визуальная схема, то есть, — функция документирования и мониторинга, — сама по себе была бы очень полезна для понимания логики системы и происходящих в ней сию секунду процессов даже в самых простых системах, где внедрять BPM никто и не собирался, а рисовать это всё руками не имеет смысла. Почему бы не сделать следующим образом.


  1. Логика процесса реализуется в коде приложения на разработанном для этих целей DSL, имеющем такие сущности как задача, условие, цикл, начало или конец процесса, подпроцесс. Контроль типов, статический анализ, отладка, тестирование, рефакторинг — всё на месте. Пример библиотеки для Python: viewflow. Не искал ещё аналога для Scala, — думаю, там можно сделать многократно красивее.
  2. Такие вещи, как определение текущего шага для данного пользователя, или вывод всей схемы в графическом виде с иллюстрацией её состояния в реальном времени — делаются автоматически, что резко упрощает документирование системы. Разумеется, возможны аннотации типа стилей схемы или расположения квадратиков, но в целом визуальная схема целиком определяется тем, что в коде написано.

У BPM есть одна (потенциальная) возможность, которая вроде бы есть шаг вперёд по сравнению с традиционной разработкой: если изменить процесс с версии 1 на версию 2, то в зависимости от возможности и необходимости можно либо 1) продолжать выполнять старые уже запущенные процессы на версии 1, а новые запускать уже на версии 2, — либо 2) перевести старые процессы на версию 2 прямо в процессе выполнения. Мне представляется, что такую возможность можно и без BPM реализовать, это зависит исключительно от того, насколько хорошо система разбита на компоненты и как они друг с другом взаимодействуют. Запустить две копии одного компонента, где в одной будет старый код, а в другой новый, и разделять по ним процессы — совсем не за гранью возможного. И всё это — с контролем типов, рефакторингом, etc.


Что вы думаете о таком подходе, и как вы относитесь к перспективам использования DSL в системах автоматизации бизнес-процессов в принципе?

Собственно, если мне придется сегодня делать бизнес-процессы снова, я примерно так и стал бы поступать, как вы предлагаете. Т.е., в виде BPMN/диаграмм вообще делать минимально необходимое для понимания пользователями описание процесса. А еще лучше — именно DSL. Показ схемы в виде картинок — на основе анализа кода. Т.е. схема — вторична, а код первичен. Это примерно то, что я сегодня имею например в Apache Camel.


И это тот вариант, к которому постепенно приходишь. Просто в рамках конкретной реализации и ему следовать было достаточно сложно.


Ну и насчет миграции. Далеко не всегда это возможно. Во-первых, запущенный процесс версии 1 может быть на таком шаге, которого в версии 2 вообще нет. И во-вторых, у новой версии процесса могут быть новые данные, которые старая версия не хранила. И взять их далеко не всегда возможно — скажем, потому, что предыдущих шагов, которые их создают, процесс не выполнял. Так что миграция — это не то чтобы миф, но далеко не всегда возможное в реальности действие.

Я некоторое время назад перешел из классической разработки в разработку под одну bpm-платформу в компании-интеграторе. Задачи у заказчиков на самом деле абсолютно те же что и в любом другом бизнесе. Только отличается масштаб и стоимость на 2-3 порядка. И есть некоторые правила игры, которые кроются за загадочным, одетым в дорогой костюм, словом «бизнес-аналитик». На самом деле эти ребята ничего такого сверхъестественного не знают и не умеют — системное мышление, знание практик и обязательно трендовых кодовых словечек, вроде BPM, BI, SFA, шины, которые сыпятся из их ртов как из рога изобилия. Зачарованный заказчик отдает немалые деньги, а потом самые обычные программеры седеют, пытаясь понять чего нужно делать, успеть во «вчерашние» сроки, обойти все грабли и стены в платформе чтобы впилить нужную заказчику «хотелку».

Там выше упомянули 1С, это очень хороший пример того, что бизнес-аналитик может быть программером и это очень эффективное сочетание навыков. По факту любой более-менее опытный 1С-ник является бизнес-аналитиком, только еще и сам потом все это реализует в коде. Ну и ездит на машине подешевле и одет попроще.

Но большой бизнес хочет «больших» систем, просто таковы правила игры. Которые кстати уже трещат по швам.
Интересно, есть ли в природе инстументарий, который проверяет непротиворечивость требований бизнеса?

Например, есть такие требования:
1)«для всех договоров из продукта1 делать проводки на счет 123»
2) «для всех договоров для физ лиц делать проводки на счет 456»
нужно что бы автоматически нашлось противоречие, так как могут быть договора продукта1 для физ лиц. Как делать проводки при этом — непонятно.
Этим занимаются системы класса BRMS (Business Rule Management Systems). Там обычно по приоритету применяются правила. Ну или задается стратегия разрешения конфликтов.
Рекомендовал бы вам посмотреть тематику «Ad-hoc process» и «Ad-hoc Workflow».

Это довольно сырая и неизученная область моделирования бизнес процессов, идейные вожди в этой области Aalst, Alonso. По ихнему мнению, при увеличении гибкости бизнес процессов, возрастает ихняя сложность, элементарная жизненная закономерность.

Из этого следует, чтоб увеличить гибкость процессов, необходимо разбить процесс на возможно простые и легко замещающие себя части.

Те чтобы добиться «гибкости» бизнес процессов, необходимо продумать стратегию борьбы со «сложностью».

Есть классификация бизнес процессов по возрастанию гибкости, соответственно ихней сложности:
http://static.flickr.com/5136/5531596297_7a1f3e3b1c.jpg

Соответственно Вам стало не комфортно на первом уровне и вы пытаетесь перескочить на следующий, уволакивая за собой уровень «сложности» с предыдущего, который не подходит к следующему.

Чтоб комфортно себя чувствовать на определенном уровне сложности, необходимо решить какая степень гибкости бизнес процессов необходима под поставленные задачи и отсюда решить хватит ли ресурсов решить проблемы со сложностью для данного уровня гибкости. Те необходимо соблюсти баланс этих двух понятий, выстроить мост между «сложностью» и «гибкостью» бизнес процессов.

Касательно описанных проблем, добавил бы необходимость проверки модели бизнес процесса после внесенных изменений на ее «живучесть», в эволюции не всегда без уродов. Дабы исключить при перескакивании на новую версию элементарных dead или livelock
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.