Comments 47
What the fuck am I reading?
Не сочтут, но может все-таки поясните, в чем проблема?
На мой взгляд, если вы скажем не поняли, о чем пост — ну так и что? Есть много разных тем, далеко не все из них должны быть понятны всем — как и интересны, впрочем.
Я возможно плохо сформулировал, но этот пост ни разу не об управлении. Речь идет о вполне конкретных программных продуктах, на базе которых разрабатываются BPM системы. И о том, что сама эта парадигма процессов, которые пытаются рисовать в виде картинок, очень плохо годится для того, чтобы в ней разрабатывать. А если уж совсем просто — о том, что программировать в картинках получается как правило плохо.
Так что нет, это вовсе не про управление и совсем не для управленцев.
А есть такие BPM-системы, в которых отказались от графики в пользу кода?
Разница в том, что первичным является DSL (как скажем java, так и xml), из которого строится диаграмма. А когда вы хотите на нее посмотреть — вы можете это сделать в виде картинки. Вы можете их в таком виде поотлаживать, или посмотреть статистику по квадратикам. А вот редактировать диаграмму в картинках совершено лишнее.
Я за три с половиной года всего-то поучаствовал примерно в десятке проектов для десятка банков РФ, начиная со Сбербанка и заканчивая Тиньковым, а по дороге еще Райффайзен с РСХБ например захватили. И все еще не понял. Ну зато вы-то видимо все поняли?
Можете поделиться своими сокровенными знаниями о том, как это круто? Как легко рефакторить диаграммы? Как быстро понять, какие измеения за неделю внесли в ваш процесс? Как слить две ветки изменний? Как легко писать юнит-тесты, наконец.
Я с радостью почитаю.
например приходит новый работник к большую контору, можно ему выдать кучу инструкций как и в каком порядке выполнять свою работу, слать задания по мылу, скайпу, словами и тд… но как быстро он прочитает эти инструкции и запомнит все правильно.
либо занести юзера в bpmn систему, при выдаче ему нового задания оно появляется с списке заданий юзера, по мере выполнения этапов задание будет продвигаться, этапы могут зависеть от задач других юзеров и тд…
есть общий алгоритм работы предприятия, он разбивается на подзадачи, которые могут еще более мелко делиться, юзеры выполняют свои части и в итоге типа все знают что делать, отмечают ход выполнения заданий, либо не выполнения и причину.
получается еще один способ систематизировать большую сложную систему предприятия.
ну и для начала нужно правильно составить описание все процессов и разные связи
Вы смотрите на это с другой стороны. Да, для бизнеса все возможно так и выглядит. Я же рассказываю историю с точки зрения разработчика.
Во-первых, описание большого процесса нельзя составить сразу — оно строится постепенно, от версии к версии — как любой достаточно сложный программный продукт. Во-вторых, очень желательно, чтобы повторяющиеся куски процесса можно было оформить как готовый компонент, и потом переиспользовать их в других местах.
И вот со всем этим у схемок и картинок — большие проблемы.
по нормальному, составлять модели бизнес процессов должны люди которые в теме работы данного предприятия, а не разработчики.
эти картинки и схемы нужны на стадии как раз составления бизнес процессов, дальше их видеть не обязательно, юзеру приходят только его задания, абстракции вобщем.
А что изменится, если составлять будут люди в теме?
дальше их видеть не обязательно
Простите, но это означает, что процесс у вас никогда не меняется. А так не бывает.
Представьте скажем вот такой простой случай — сидят у вас два человека в теме, и рисуют диаграммы. Потом вы на них смотрите, и видите, что они делают в сущности одно и тоже. В нормальной среде разработки вы можете а) сравнить два куска кода между собой б) выполнить рефакторинг, выделив повторяющиеся куски в) натравить на код анализ, который например покажет вам copy&paste.
Так вот, ничего из этого вам для диаграмм (BPMN тут частный случай, с другими все примерно также) не доступно. А код, который развивается путем copy&paste, и не рефакторится, практически неизбежно со временем становится говнокодом. И перестает поддерживаться.
походу понимание так и не пришло,
да хоть 100 раз в неделю пусть меняется, юзерам это пофик к ним приходят конкретные задания, а что там творится с диаграммами в целом они даже могут не знать.
Юзерам это да, пофиг. А вот IT и разработчикам — вовсе нет. Вот простой кейс, ваш процесс скажем сломался. Вчера работало. Перед вами стоит задача — найти причину и пофиксить.
В случае "нормального" классического кода я вам скажу, что буду делать — я залезу в Git, и посмотрю, какие коммиты были, кто и зачем их делал, какие части системы они затронули. Я тупо сравню код, наконец. А теперь расскажите мне, как вы сравниваете BPMN? Только очень прошу — не надо про то, что это XML, потому что это НЕ xml. Если вы вынуждены лезть на уровень xml, чтобы понять, что именно изменилось в процессе — ваша IDE для разработки процессов — барахло.
И имено про такие инструменты я и пишу. Которые не умеют скажем сравнивать две версии процесса.
Какой вывод я для себя сделал — думаю вполне понятно. Буду держаться подальше от подобных инструментов, по мере возможности.
Я так понял, вы не будет теперь заниматься разработкой, связанной с автоматизацией бизнес-процессов?
Какой разработкой вы решили заниматься?
Вы название IBM BPM в самом начале видели? А конкретные версии? Это вовсе не концепция. Это конкретный продукт, платформа для создания систем. И все что тут написано, как вы выражаетесь, "для обхаивания" к нему относится в полной мере. Это в обсновном про него. Хотя насколько я знаю скажем Pega — там ровно тоже самое.
Да, и ответ на вопрос — отойдя в строну от решений IBM, в том числе от их "шины", которая входит в состав BPM в том числе, я практически сразу отметил для себя, что Open Source решения в данном случае совсем не уступают коммерческим. И уж точно намного удобнее в разработке. Например Apache Camel, в качестве основы для построения своей шины.
А будет позарез нужен BPM — возьму Activity. Даром. Там много чего нет, и там есть все теже присущие концепции недостатки, кстати. Но там все равно проще.
Вы знаете, а завидуйтека молча. 1С хают только те кто не умеет ей пользоваться. У меня она ни разу не вызывала негативных откликов. Разрабы платформы — да, язык и невероятно удобная среда разработки и отладки — нет. И многих преимуществ 1С весьма не хватает у всех остальных.
BPM может быть и концепция, но вот Oracle BPMN это уже таки реализация. И честно говоря — пост имеет своей целью «резюме».
Визуальное моделирование и выполнение бизнес-процессов — частично. Модель не отражает реальности для аналитика, и неудобна для разработчика.
Набор готовых компонент для построения гибких бизнес-процессов — нет. Средства создания компонентов неадекватны.
Поддержка версионности бизнес-процессов — частично. Средства неадекватны.
По первым двум пунктам согласен целиком, несмотря на то что работаю с продуктом Oracle. То что продается как «фишка» — участие аналитиков в разработке путем создания макета процесса, на деле оказывается сладкой упаковкой пустышки. Потому что после реализации конечная модель едва ли похожа на упрощенное представление аналитиков.
А вот простейший контроль версий, тот же Git, прикрученный к среде разработки — позволяет отследить кто когда что менял. Детали же проделанных изменений обязаны быть в сопроводительных документах. Если разработчики только меняют код, и не документируют его ни комментариями (что в BPMN нереально) ни дополнительной документаций — вините не среду разработки, а разработчиков.
можно выставить желаемые значения в узлы и ждать условия их появлений и тд…
Вы как будто пытаетесь меня убедить, что процессы и их формализация полезны.
Так я с этим и не спорю, что характерно. Я лишь пытался показать, что существующие инструменты работы с ними, в частности 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 такой фокус не проходит, эта проблемы переноситься с этапа поддержки, на этап проектирования. Это вызывает множество проблем, поскольку заказчику или сразу видно, что процесс не соответствует реальности, или что не читаем и содержит костыли на каждом шагу. Такое продать сложно, проще указать в ТЗ требования, а потом реализовать их через одно место и все довольны.
По остальным пунктам, единственно что соответствует действительности, это отсутствие средств рефакторинга.
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 никто и не собирался, а рисовать это всё руками не имеет смысла. Почему бы не сделать следующим образом.
- Логика процесса реализуется в коде приложения на разработанном для этих целей DSL, имеющем такие сущности как задача, условие, цикл, начало или конец процесса, подпроцесс. Контроль типов, статический анализ, отладка, тестирование, рефакторинг — всё на месте. Пример библиотеки для Python: viewflow. Не искал ещё аналога для Scala, — думаю, там можно сделать многократно красивее.
- Такие вещи, как определение текущего шага для данного пользователя, или вывод всей схемы в графическом виде с иллюстрацией её состояния в реальном времени — делаются автоматически, что резко упрощает документирование системы. Разумеется, возможны аннотации типа стилей схемы или расположения квадратиков, но в целом визуальная схема целиком определяется тем, что в коде написано.
У BPM есть одна (потенциальная) возможность, которая вроде бы есть шаг вперёд по сравнению с традиционной разработкой: если изменить процесс с версии 1 на версию 2, то в зависимости от возможности и необходимости можно либо 1) продолжать выполнять старые уже запущенные процессы на версии 1, а новые запускать уже на версии 2, — либо 2) перевести старые процессы на версию 2 прямо в процессе выполнения. Мне представляется, что такую возможность можно и без BPM реализовать, это зависит исключительно от того, насколько хорошо система разбита на компоненты и как они друг с другом взаимодействуют. Запустить две копии одного компонента, где в одной будет старый код, а в другой новый, и разделять по ним процессы — совсем не за гранью возможного. И всё это — с контролем типов, рефакторингом, etc.
Что вы думаете о таком подходе, и как вы относитесь к перспективам использования DSL в системах автоматизации бизнес-процессов в принципе?
Собственно, если мне придется сегодня делать бизнес-процессы снова, я примерно так и стал бы поступать, как вы предлагаете. Т.е., в виде BPMN/диаграмм вообще делать минимально необходимое для понимания пользователями описание процесса. А еще лучше — именно DSL. Показ схемы в виде картинок — на основе анализа кода. Т.е. схема — вторична, а код первичен. Это примерно то, что я сегодня имею например в Apache Camel.
И это тот вариант, к которому постепенно приходишь. Просто в рамках конкретной реализации и ему следовать было достаточно сложно.
Ну и насчет миграции. Далеко не всегда это возможно. Во-первых, запущенный процесс версии 1 может быть на таком шаге, которого в версии 2 вообще нет. И во-вторых, у новой версии процесса могут быть новые данные, которые старая версия не хранила. И взять их далеко не всегда возможно — скажем, потому, что предыдущих шагов, которые их создают, процесс не выполнял. Так что миграция — это не то чтобы миф, но далеко не всегда возможное в реальности действие.
Там выше упомянули 1С, это очень хороший пример того, что бизнес-аналитик может быть программером и это очень эффективное сочетание навыков. По факту любой более-менее опытный 1С-ник является бизнес-аналитиком, только еще и сам потом все это реализует в коде. Ну и ездит на машине подешевле и одет попроще.
Но большой бизнес хочет «больших» систем, просто таковы правила игры. Которые кстати уже трещат по швам.
Например, есть такие требования:
1)«для всех договоров из продукта1 делать проводки на счет 123»
2) «для всех договоров для физ лиц делать проводки на счет 456»
нужно что бы автоматически нашлось противоречие, так как могут быть договора продукта1 для физ лиц. Как делать проводки при этом — непонятно.
Это довольно сырая и неизученная область моделирования бизнес процессов, идейные вожди в этой области Aalst, Alonso. По ихнему мнению, при увеличении гибкости бизнес процессов, возрастает ихняя сложность, элементарная жизненная закономерность.
Из этого следует, чтоб увеличить гибкость процессов, необходимо разбить процесс на возможно простые и легко замещающие себя части.
Те чтобы добиться «гибкости» бизнес процессов, необходимо продумать стратегию борьбы со «сложностью».
Есть классификация бизнес процессов по возрастанию гибкости, соответственно ихней сложности:
http://static.flickr.com/5136/5531596297_7a1f3e3b1c.jpg
Соответственно Вам стало не комфортно на первом уровне и вы пытаетесь перескочить на следующий, уволакивая за собой уровень «сложности» с предыдущего, который не подходит к следующему.
Чтоб комфортно себя чувствовать на определенном уровне сложности, необходимо решить какая степень гибкости бизнес процессов необходима под поставленные задачи и отсюда решить хватит ли ресурсов решить проблемы со сложностью для данного уровня гибкости. Те необходимо соблюсти баланс этих двух понятий, выстроить мост между «сложностью» и «гибкостью» бизнес процессов.
Касательно описанных проблем, добавил бы необходимость проверки модели бизнес процесса после внесенных изменений на ее «живучесть», в эволюции не всегда без уродов. Дабы исключить при перескакивании на новую версию элементарных dead или livelock
Все что вы хотели узнать о BPM, но боялись спросить