Комментарии 49
«Старику ARIS» (в части классического моделирования процессов) на пенсию бы (не смотря на добавленные круглую цифру 10 и магическое слово «cloud»), но похоже перемены придут еще совсем не скоро и светлое будущее «обычного» BPM откладывается …
А есть ли вообще будущее у BPM (у методологии, самой по себе, без исполнимых процессов (без «S»))? Просто это же немного разные подходы — в первом случае аналитики рисуют диаграммы и консультируют топов по узким местам в процессах (и поэтому BPM может не работать, т.к. рекомендации могут так и остаться «в столе»). А в случае исполнимых процессов — необходимо перенести процессы в систему так, чтобы BPMS в организация таки заработала (если она не заработает — это будет явно видно — либо процессы будут исполняться в обход системы (и это будет видно в системе, в виду отсутствия движения по процессу), либо система будет тормозить деятельность организации).
Я это к тому, что ARIS, BPWin, Business Studio, Visio — это же инструменты моделирования процессов (без намека на исполнение), а основная движуха в BPM (имхо) как раз в S — BPMS — в том, что можно заставить процессы исполняться (и поэтому инструменты недотягивают).
Из Open-Source BPMS не так плохи Camunda (https://habr.com/ru/company/tinkoff/blog/455860/, bpmn.io), RunaWFE (https://habr.com/ru/post/308200/, runawfe.ru/BPMS_RunaWFE_Free)
1. BPM, BPMS – который для формализации процессов и всякое «исполняемое», что BPMS, low code и все подобное, включая «программирование без программирования» – это параллельные вселенные (еще на многие годы). Они хоть и пересекаются, но очень мало и, как правило, «по недоразумению».
2 BPM, BPMS – который для формализации процессов (базовая часть Process Engineering), это не только «аналитики рисуют диаграммы и консультируют топов по узким местам в процессах». Это вообще куда более глубокий пласт, нежели «всего лишь» автоматизация. Если уж «про топов», то это и взгляд с высоты птичьего полета на процессы: процессы в «крупную клетку» и там не «про узкие места» в процессе, а про целостность и концептуальность.
Ключевая задача – это формализация как текущих, так и планируемых процессов. Причем как на эскизном (нечетком, предварительном, общая концепция), так и детальном (рабочая документация) уровне. Это та же инженерия процесса, подобная ЕСКД, начиная от схемы деления на составные части чего-то большого (мега процесса) и кончая электрической принципиальной схемой, т.е. до самого маленького резистора (в нашем случае, до крохотного процесса). Здесь и текущие регламенты компании и проектная деятельность. Можно много продолжать.
Причем «процесс» – это только «общее название», т.к. область понятий понимается намного шире, включая всё окружение процесса, документооборот, включая бумажный, ресурсы HR и не HR (демоны, роботы и т.п.), алгоритмы, бизнес-правила. Это если брать процессо-центричный подход (т.е. во главе всего – Процесс).
3 Camunda и «компания» — очень хорошие продукты, но они пока не заменят, указанное в пункте 2.
К тому, же если бы они были такими идеальными, как многие их представляют, то они бы давно вытеснили классические системы разработки ПО. Но пока в части Software Engineering господствуют другие платформы, а в части Process Engineering – их флагман = BPMN2 не может обеспечить даже понимаемого неАйтишнику описания процесса. В прошлых статьях я останавливался на этом моменте.
2 BPM, BPMS – который для формализации процессов (базовая часть Process Engineering), это не только «аналитики рисуют диаграммы и консультируют топов по узким местам в процессах». Это вообще куда более глубокий пласт, нежели «всего лишь» автоматизация. Если уж «про топов», то это и взгляд с высоты птичьего полета на процессы: процессы в «крупную клетку» и там не «про узкие места» в процессе, а про целостность и концептуальность.
Ключевая задача – это формализация как текущих, так и планируемых процессов. Причем как на эскизном (нечетком, предварительном, общая концепция), так и детальном (рабочая документация) уровне. Это та же инженерия процесса, подобная ЕСКД, начиная от схемы деления на составные части чего-то большого (мега процесса) и кончая электрической принципиальной схемой, т.е. до самого маленького резистора (в нашем случае, до крохотного процесса). Здесь и текущие регламенты компании и проектная деятельность. Можно много продолжать.
Причем «процесс» – это только «общее название», т.к. область понятий понимается намного шире, включая всё окружение процесса, документооборот, включая бумажный, ресурсы HR и не HR (демоны, роботы и т.п.), алгоритмы, бизнес-правила. Это если брать процессо-центричный подход (т.е. во главе всего – Процесс).
3 Camunda и «компания» — очень хорошие продукты, но они пока не заменят, указанное в пункте 2.
К тому, же если бы они были такими идеальными, как многие их представляют, то они бы давно вытеснили классические системы разработки ПО. Но пока в части Software Engineering господствуют другие платформы, а в части Process Engineering – их флагман = BPMN2 не может обеспечить даже понимаемого неАйтишнику описания процесса. В прошлых статьях я останавливался на этом моменте.
Давайте будем честными. Все эти рассуждения про формализацию — это просто красивое название для распила бюджета.
Я не слышал ни про один пример, когда сложное описание (без автоматизации) было настолько близко к реальности, чтобы с ним можно было делать хоть что то реально полезное.
Поэтому никому это по большому счету и не интересно.
Освоить бюджет можно и с Visio.
А когда нужны реальные результаты — работают с BPMS / BPMN.
"один пример, когда сложное описание (без автоматизации) было настолько близко к реальности, чтобы с ним можно было делать хоть что то реально полезное."
Что понимается под "реально полезное" (тег серьезно)?
Кстати "нереально полезное" — это видимо "еще более полезное" (тег сарказм).
Годится не только для придания веса документации по проекту. )))
Не совсем понял, «про честность», но про формализацию процесса немного поясню.
Я ранее тоже скептически относился к идее формализации процессов.
Однако, мне попадаются редкие руководители, которые сами делают выбор в пользу схем.
Обычно выбор такой: или текстовый регламент на 250 страниц, который никто кроме автора (и ряда ключевых исполнителей) понять «в целом» не в состоянии. Или примерно тоже, но в виде ЕРС и примерно на 50 страницах (кстати объектов на листе иногда до 40 доходит). Отдельные бизнес-правила прямо на листе схемы. В случае ЕРС – есть понимание, где процесс начинается, куда впадает, что на выходе, кто делает и какими инструментами.
Выверить 250 — страничный текстовый регламент (а он далеко не один) – нереально, в нем всегда будут не стыковки, противоречия и «повисающие» в воздухе ветки процесса. Вообще русский язык настолько богатый, что два человека читают один текст, но выводы «что делать» по алгоритму – могут быть разные. Иногда только автор может пояснить, что он имел ввиду.
Несмотря на то, что схематично получается формализовать с меньшими деталями, но схемы могут понять люди с намного меньшими временными затратами и однозначно и не искать продолжение алгоритма, внезапно оборвавшегося на 69 странице текстового регламента.
Речь про автоматизацию не идет, все давно автоматизировано. Часто нужно что-то переделывать, но не менять «в целом».
Я ранее тоже скептически относился к идее формализации процессов.
Однако, мне попадаются редкие руководители, которые сами делают выбор в пользу схем.
Обычно выбор такой: или текстовый регламент на 250 страниц, который никто кроме автора (и ряда ключевых исполнителей) понять «в целом» не в состоянии. Или примерно тоже, но в виде ЕРС и примерно на 50 страницах (кстати объектов на листе иногда до 40 доходит). Отдельные бизнес-правила прямо на листе схемы. В случае ЕРС – есть понимание, где процесс начинается, куда впадает, что на выходе, кто делает и какими инструментами.
Выверить 250 — страничный текстовый регламент (а он далеко не один) – нереально, в нем всегда будут не стыковки, противоречия и «повисающие» в воздухе ветки процесса. Вообще русский язык настолько богатый, что два человека читают один текст, но выводы «что делать» по алгоритму – могут быть разные. Иногда только автор может пояснить, что он имел ввиду.
Несмотря на то, что схематично получается формализовать с меньшими деталями, но схемы могут понять люди с намного меньшими временными затратами и однозначно и не искать продолжение алгоритма, внезапно оборвавшегося на 69 странице текстового регламента.
Речь про автоматизацию не идет, все давно автоматизировано. Часто нужно что-то переделывать, но не менять «в целом».
50 страничную схему выверить тоже нереально. :)
И большие текстовые регламенты, и красивые картинки описывают схему «как оно есть в нашем воображении». К реальности все эти картинки имеют примерно такое же отношение, как рисунок 7 летнего ребенка к строению тела человека — есть очень способные дети, есть не очень способные, но даже у очень способных с деталями беда.
И возникает резонный вопрос — а нафига вот это все?
Для попила бюджета — ок. Но там и Visio с головой.
А какая еще польза от этих «в виде ЕРС и примерно на 50 страницах»?
Для постановки ТЗ — не годится.
Исполнители в повседневной работе тоже не используют.
А в чем тогда ценность всех этих бумажек?
Я не про выбор между 250 страничным текстовым описанием и 50 страничной ЕРС диаграммой.
А про выбор — делать вообще эти бумажки или нет.
И большие текстовые регламенты, и красивые картинки описывают схему «как оно есть в нашем воображении». К реальности все эти картинки имеют примерно такое же отношение, как рисунок 7 летнего ребенка к строению тела человека — есть очень способные дети, есть не очень способные, но даже у очень способных с деталями беда.
И возникает резонный вопрос — а нафига вот это все?
Для попила бюджета — ок. Но там и Visio с головой.
А какая еще польза от этих «в виде ЕРС и примерно на 50 страницах»?
Для постановки ТЗ — не годится.
Исполнители в повседневной работе тоже не используют.
А в чем тогда ценность всех этих бумажек?
Я не про выбор между 250 страничным текстовым описанием и 50 страничной ЕРС диаграммой.
А про выбор — делать вообще эти бумажки или нет.
А про выбор — делать вообще эти бумажки или нет.
Такого нет. Или текстом 250 листов или схема. Третьего не дано. Таковы правила во многих серьезных компаниях.
И здесь не столько важна информация — «как нужно делать». Исполнители наизусть знают каждый свой шаг. Больше важен вопрос «граница ответственности» между взаимодействующими ролями.
Если «что то» пошло не так, то на основе регламента должен быть явно определен виновный. Однозначно определен и так как регламент утвержден, то и наказан.
Применений схем — регламентов много, например, контролеры могут указать где и как минимизировать риски, например, расставить прямо на схеме контрольные процедуры и текстом в отдельной табличке расписать каждую «до винтика».
Если процессы простые и не критические, то наверное можно и без регламентов. В небольших компаниях, продающих, условно стельки — они точно не нужны.
Такого нет. Или текстом 250 листов или схема. Третьего не дано. Таковы правила во многих серьезных компаниях.
Я про это и говорю. :)))
Это просто не имеет никакой практической ценности.
Я ведь и сам одно время в Арисе схемы рисовал. Причем не потому, что «третьего не дано». Мы реально хотели это использовать в проекте внедрения ЕРП. Но…
Практика показала, что не работает подход.
Очень быстро набросать высокоуровневую схему — да, можно. Очень иногда имеет смысл.
А детализацию имеет смысл делать только в BPMN. Не потому, что нотация сильно лучше. А потому, что она — исполнимая.
Наши Арисовские диаграммы устаревали еще до того, как мы прописали половину процессов. Можно было напрячься, обновить — но зачем? Практической пользы — ноль.
Вот эти все ваши рассуждения про применимость регламентов — они за уши притянуты.
Если «что то» пошло не так, то на основе регламента должен быть явно определен виновный. Однозначно определен и так как регламент утвержден, то и наказан.
Ага, «разберусь, кто виноват, и накажу кого попало». :)))
Вам самому не смешно такие доводы приводить?
Тут ведь все взрослые люди, и прекрасно знают, как в «серьезных компаниях» назначают виноватых в косяках.
Вот это всё, что вы написали типичный подход людей не понимающих о чём вообще BPMN и как с его помощью также в разы, сократить затраты времени на разработку (не все задачи решаются с помощью BPMN, т.е. забивать гвозди микроскопом или катаной — зло).
50 страничная BPMN схема, — это ширакрный, нереальный, ненужный, беслопезный, и очень дорогой бред неквалифицированного аналитика процессов. Изучаем декомпозицию и учимся как в процессы встраиваются другие процессы. Учимся слона есть по частям.
Любые большие текстовые регламенты, — это профанация. Процессы должны быть простыми и эффективными. Любой конвейер имеет одну единственную цель: провести декомпозицию операций и сократить трудозатраты, оптимизиовав то что можно. А если вы целый завод в одну линию впихнуть хотите, —идите в жопу.это будет стоить отдельных денег, будет очень дорого в эксплуатации, это будет невозможно поддерживать и поэтому это не будет использоваться.
Вот этот ваш подход, и есть сплошное пиление, оно происходит от неграмотности и не понимания того «что и для чего» использовать.
Именно так, пилят бюджеты и превращают конвейеры, призванные сделать сложное простым, в регламентных монстров, которые есть только для галочки и вносят дополнительные трудозатраты вместо удешевления.
50 страничная BPMN схема, — это ширакрный, нереальный, ненужный, беслопезный, и очень дорогой бред неквалифицированного аналитика процессов. Изучаем декомпозицию и учимся как в процессы встраиваются другие процессы. Учимся слона есть по частям.
И большие текстовые регламенты, и красивые картинки описывают схему «как оно есть в нашем воображении».
Любые большие текстовые регламенты, — это профанация. Процессы должны быть простыми и эффективными. Любой конвейер имеет одну единственную цель: провести декомпозицию операций и сократить трудозатраты, оптимизиовав то что можно. А если вы целый завод в одну линию впихнуть хотите, —
Для попила бюджета — ок. Но там и Visio с головой.
Вот этот ваш подход, и есть сплошное пиление, оно происходит от неграмотности и не понимания того «что и для чего» использовать.
Именно так, пилят бюджеты и превращают конвейеры, призванные сделать сложное простым, в регламентных монстров, которые есть только для галочки и вносят дополнительные трудозатраты вместо удешевления.
50 страничная BPMN схема, — это ширакрный, нереальный, ненужный, беслопезный, и очень дорогой бред неквалифицированного аналитика процессов.
Читайте внимательнее, речь про другую нотацию и с декомпозицией там тоже всё хорошо.
Для общего понимания, пример интерфейса (хороших примеров больших процессов не нашел): www.bpm.processoffice.ru
Обсуждать что-то с людьми, которые считают себя намного умнее других, как правило, — пустая затея, поэтому переубеждать Вас не стану.
Я не слышал ни про один пример, когда сложное описание (без автоматизации)
Можно уточнить, что такое "сложное описание (без автоматизации)"?
Всё ниже написанное относится к конкретной стране и городу в котором я работаю.
Уже лет 7 у меня не проходит удивление от того, что такой замечательный инструмент как BPMN, превращают в плохой миф. Некомпетентные архитекторы и менеджеры делают всё, чтобы BPMN был практически не применим к использованию.
Я очень сильно удивляюсь тому:
1 что медеджеры BPMN не знают, и воспринимают его как сктеч, который «примерно так» демонстрирует процесс, который потом будет расписан в бумажках и регламентах и никогда на самом деле работать не будет;
2 никто вообще, кроме тех кто пользуется купленым у IBM движком (банки), не понимают, что диаграмма в BPMN это сразу автоматизированный процесс;
3 банки не воспринимают BPMN как инструмент управления процессами на предприятии и инструмент автоматизации процессов, а воспринимают только как инструмент разработки
4 никто не знает о нормальных инструментах как презентации так и исполнения BPMN (кроме случаев с банками), которые по факту ничего о BPMN не знают
5 никто не знает о существующих open source инструментах работы и исполнения BPMN, и когда им об этих инструментах рассказываешь — им пофигу (пилить нечего)
Особые претензии у меня к Террасофт с их BPM online, который они массово продают во все возможные организации, и этот инструмент к BPMN вообще никакого отношения не имеет, однако все кто купил BPM online и продукты на нём построенные, свято уверены, что у них есть BPMN, и это сложно и дорого.
Для тех кому интересно, обратите внимание на TWE: Together Workflow Engine (Enhydra Shark) и Together Workflow Editor.
Готовый продукт использующий TWE: CMDBuild
Разработка под CMDBuild — создать роли для процесса, создать новый процесс (пустой), экспортировать шаблон и открыть его в редакторе TWE, в lanes разложить роли, создать сам процесс со всеми скриптами (рисуем сову), сохранить файл, импортировать процесс в CMDBuild. Всё. Можно использовать. Далее идут отладка тестирование и коррекция этого процесса, а потм можно запускать в продакшн. Для сложнго бизнес поцесса с кучей участников, от момента совместного создания процесса, до запуска в эксплуатацию — максимум 2 недели.
И вот это -2 недели, это плохо, т.к НА ЭТОМ НИЧЕГО НЕ ЗАРАБОТАШЬ. Каждый мэнеджер понимает, что он не сможет отжать нормальных денег на этой фигне.
Примечания:
1. Visio — рисовалка, а не инструмент для BPMN.
2. Любая рисловалка, результат рисования которой не возможно выполнить в BPMN движке, — это не инструмент для работы с BPMN.
Даже если бизнесу нужен BPMN, который упростит цикл Дёминга и вообще позволит процессы автоматизировать, никогда не получит нужного результата. Т.к. все участники цепочки, — пиявки. Им либо всё равно, либо хочется поживиться, либо они вообще изменений не хотят, либо хотят иметь мутные процессы, что-бы и ответственность размазать и аудит надуть и поживиться в мутной водице, либо просто представления о BPMN не имеют.
Накипело…
Уже лет 7 у меня не проходит удивление от того, что такой замечательный инструмент как BPMN, превращают в плохой миф. Некомпетентные архитекторы и менеджеры делают всё, чтобы BPMN был практически не применим к использованию.
Я очень сильно удивляюсь тому:
1 что медеджеры BPMN не знают, и воспринимают его как сктеч, который «примерно так» демонстрирует процесс, который потом будет расписан в бумажках и регламентах и никогда на самом деле работать не будет;
2 никто вообще, кроме тех кто пользуется купленым у IBM движком (банки), не понимают, что диаграмма в BPMN это сразу автоматизированный процесс;
3 банки не воспринимают BPMN как инструмент управления процессами на предприятии и инструмент автоматизации процессов, а воспринимают только как инструмент разработки
4 никто не знает о нормальных инструментах как презентации так и исполнения BPMN (кроме случаев с банками), которые по факту ничего о BPMN не знают
5 никто не знает о существующих open source инструментах работы и исполнения BPMN, и когда им об этих инструментах рассказываешь — им пофигу (пилить нечего)
Особые претензии у меня к Террасофт с их BPM online, который они массово продают во все возможные организации, и этот инструмент к BPMN вообще никакого отношения не имеет, однако все кто купил BPM online и продукты на нём построенные, свято уверены, что у них есть BPMN, и это сложно и дорого.
Для тех кому интересно, обратите внимание на TWE: Together Workflow Engine (Enhydra Shark) и Together Workflow Editor.
Готовый продукт использующий TWE: CMDBuild
Разработка под CMDBuild — создать роли для процесса, создать новый процесс (пустой), экспортировать шаблон и открыть его в редакторе TWE, в lanes разложить роли, создать сам процесс со всеми скриптами (рисуем сову), сохранить файл, импортировать процесс в CMDBuild. Всё. Можно использовать. Далее идут отладка тестирование и коррекция этого процесса, а потм можно запускать в продакшн. Для сложнго бизнес поцесса с кучей участников, от момента совместного создания процесса, до запуска в эксплуатацию — максимум 2 недели.
И вот это -2 недели, это плохо, т.к НА ЭТОМ НИЧЕГО НЕ ЗАРАБОТАШЬ. Каждый мэнеджер понимает, что он не сможет отжать нормальных денег на этой фигне.
Примечания:
1. Visio — рисовалка, а не инструмент для BPMN.
2. Любая рисловалка, результат рисования которой не возможно выполнить в BPMN движке, — это не инструмент для работы с BPMN.
Даже если бизнесу нужен BPMN, который упростит цикл Дёминга и вообще позволит процессы автоматизировать, никогда не получит нужного результата. Т.к. все участники цепочки, — пиявки. Им либо всё равно, либо хочется поживиться, либо они вообще изменений не хотят, либо хотят иметь мутные процессы, что-бы и ответственность размазать и аудит надуть и поживиться в мутной водице, либо просто представления о BPMN не имеют.
Накипело…
Любая более-менее продвинутая нотация, способная описывать реальные процессы в виде моделей — это сложно. Освоение нотации, плюс освоение инструмента требует массы усилий и времени. IMHO по затратам сопоставимо с изучением нового ЯП + IDE (естественные языки сложнее в изучении на порядок). Для большинства людей такие затраты ресурсов просто неприемлемы.
Нет там ничего сложного. От слова совсем. BPMN прост как 3 копейки. И сделан для того, чтобы чётко и ясно отображать и автоматизировать процессы. Разверните в докере Activiti, CMDBuild, или интегрируйте TWE в свои продукты, и наслаждайтесь простотой BPMN.
SQL тоже изначально разрабатывали для того, чтобы обычные менеджеры могли САМИ получать нужные им отчеты из базы данных.
Лично я не считаю SQL сложным.
SQL прост как 3 копейки. И сделан для того, чтобы чётко и ясно отображать информацию.
Но многие, в том числе и профессиональные разработчики, со мной не согласны. ))
ЛЮБОЙ инструмент, предназначенный для автоматизации процессов — будет сложным. Просто потому, что процессы сложные.
ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%BD%D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%D0%B3%D0%BE_%D1%80%D0%B0%D0%B7%D0%BD%D0%BE%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%B8%D1%8F
Лично я не считаю SQL сложным.
SQL прост как 3 копейки. И сделан для того, чтобы чётко и ясно отображать информацию.
Но многие, в том числе и профессиональные разработчики, со мной не согласны. ))
ЛЮБОЙ инструмент, предназначенный для автоматизации процессов — будет сложным. Просто потому, что процессы сложные.
ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%BD%D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%D0%B3%D0%BE_%D1%80%D0%B0%D0%B7%D0%BD%D0%BE%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%B8%D1%8F
Вы зря ссылку привели. Никого не интересует сложность скрытая под капотом. Да интеграция того-же TWE в ваш продукт, может быть сложным процессом, однако создание и использование процессов многократно упрощаются.
Я много лет пользовался интегрированным в CMDBuild TWE, что-бы его освоить на уровне разработки процессов мне потребовалось два дня и два документа (API Reference, Admin Guide).
В 15-м году 2 совершенно разных человека пришедших в фирму (начинающий совсем зелёный парнишка джавист, и дядька под 50 разработчик на C++), сделали тоже самое за те-же 2 дня (джуниору конечно приходилось помогать объяснять какие-то базовые концепции, ревью процессов вместе с ним делать). Факт, junior за месяц разработал 4-е необходимых фирме процесса(включая все согласования и совместные ревью и отладку), один из них был невероятно сложным по структуре.
Я много лет пользовался интегрированным в CMDBuild TWE, что-бы его освоить на уровне разработки процессов мне потребовалось два дня и два документа (API Reference, Admin Guide).
В 15-м году 2 совершенно разных человека пришедших в фирму (начинающий совсем зелёный парнишка джавист, и дядька под 50 разработчик на C++), сделали тоже самое за те-же 2 дня (джуниору конечно приходилось помогать объяснять какие-то базовые концепции, ревью процессов вместе с ним делать). Факт, junior за месяц разработал 4-е необходимых фирме процесса(включая все согласования и совместные ревью и отладку), один из них был невероятно сложным по структуре.
Базовые «элементы» могут быть простыми. А вот процесс создания из простых элементов системы автоматизации процессов — будет сложным.
Это примерно как выучить алфавит и написать с помощью алфавита «Войну и мир».
Это примерно как выучить алфавит и написать с помощью алфавита «Войну и мир».
Опять не верно. Базывые элементы в BPMN это представление — самам схема, сложность скрыта в движке процессов.В движок лазить не нужно. Незачем.
Система автоматизации складывается из автоматизированных процессов. Как завод складывается из конвейерных линий. Каждый процесс должен быть прост, сокращать трудозатраты и ускорять производство.
Склеивать из маленьких процессов-конвейеров, один большой завод, задача решаемая. Т.е. время и деньги, как и во всём остальном.
Система автоматизации складывается из автоматизированных процессов. Как завод складывается из конвейерных линий. Каждый процесс должен быть прост, сокращать трудозатраты и ускорять производство.
Склеивать из маленьких процессов-конвейеров, один большой завод, задача решаемая. Т.е. время и деньги, как и во всём остальном.
Написать запрос на SQL и схему на BPMN — задачи плюс минус одного уровня сложности. Есть как очень простые запросы (схемы), так и очень сложные.
Я и то и то умею делать и делаю.
И то и то — решаемая задача и не очень сложная. По крайней мере для меня и многих моих знакомых. :)))
Но у многих решать эти задачи не получается. Дело не в инструменте. Надо для начала в голове «выстроить» способ получения нужного результата, а потом реализовать с помощью инструментов. И вот на первом этапе у многих проблемы возникают.
Я и то и то умею делать и делаю.
И то и то — решаемая задача и не очень сложная. По крайней мере для меня и многих моих знакомых. :)))
Но у многих решать эти задачи не получается. Дело не в инструменте. Надо для начала в голове «выстроить» способ получения нужного результата, а потом реализовать с помощью инструментов. И вот на первом этапе у многих проблемы возникают.
«Надо для начала в голове «выстроить» способ получения нужного результата, а потом реализовать с помощью инструментов.»
Вы сейчас описали основную причину проблем, большинства людей в любой области.
Вы сейчас описали основную причину проблем, большинства людей в любой области.
Мне поэтому и смешно читать про «волшебные» инструменты, которые облегчат написание кода.
Облегчение возникает, когда человеку вообще не надо писать код. Тогда легко. Как в современных фотоаппаратах — нажал на кнопку — получил снимок. И вообще не думаешь про выдержку, диафрагму, ISO и прочие ненужные вещи.
А когда тебе надо НАПИСАТЬ код — инструменты могут помочь, но главную проблему они не решат.
Облегчение возникает, когда человеку вообще не надо писать код. Тогда легко. Как в современных фотоаппаратах — нажал на кнопку — получил снимок. И вообще не думаешь про выдержку, диафрагму, ISO и прочие ненужные вещи.
А когда тебе надо НАПИСАТЬ код — инструменты могут помочь, но главную проблему они не решат.
Точно. N лет назад возникли такие штуки как кодогенераторы, рисуешь диаграмму классов, описываешь переменные, нажимаешь кнопочку и вжух — у тебя готовый класс, знай себе добавляй логику. Не взлетело, дешевле (проще и быстрее) набить код в IDE и модифицировать если что. Сейчас такую-же штуку пытаются сделать на уровне бизнес процессов, нарисовал схему процесса, нажал кнопочку — вжух и в твоей системе появился новый БП. Какую-то небольшую долю рынка они возьмут, но imho проблему сложности решат только в какой-то узкой области, так-же как и разные codeless системы. Универсальный решатель проблем еще ждет своего изобретателя )))
На самом деле BPMS (которые системы) сильно облегчают автоматизацию. Возможность представить ключевые взаимосвязи в графическом виде — очень полезна.
Но это не отменяет того, что:
1. BPMN — это, фактически, язык программирования, и требует обучения и навыков для применения;
2. Программировать на других языках все равно надо и много. BPMN — это скорее «клей», который позволяет более удобно совмещать разных исполнителей — разные программные «боты» и людей. :)
И все эти low code — то же самое, только в профиль. Если задача не сводится к «выбрать готовый алгоритм из списка», а надо алгоритм писать — это сразу становится задачей, требующей квалификации.
Но это не отменяет того, что:
1. BPMN — это, фактически, язык программирования, и требует обучения и навыков для применения;
2. Программировать на других языках все равно надо и много. BPMN — это скорее «клей», который позволяет более удобно совмещать разных исполнителей — разные программные «боты» и людей. :)
И все эти low code — то же самое, только в профиль. Если задача не сводится к «выбрать готовый алгоритм из списка», а надо алгоритм писать — это сразу становится задачей, требующей квалификации.
По сути это еще один уровень абстракции (между уровнем описания бизнес-процесса и его реализацией в коде) и основной вопрос тут — нужен ли это дополнительный уровень и снижает ли его добавление стоимость разработки (время и деньги)?
Я бы сказал, что это графическая часть описания бизнес процесса, а не дополнительный слой.
Во многих случаях — очень полезно.
Ближайший аналог — ER диаграмма для баз данных. Можно и без нее, но когда больше 20-30 таблиц — с ней НАМНОГО удобнее.
Во многих случаях — очень полезно.
Ближайший аналог — ER диаграмма для баз данных. Можно и без нее, но когда больше 20-30 таблиц — с ней НАМНОГО удобнее.
Частично согласен, но база это статичная вещь. Поэтому по ER-диаграмме можно сгенерировать полный скрипт для создания базы, а из базы можно сгенерировать диаграмму. Бизнес процесс это скорее граф и его можно описать текстом или картинкой, но кода его не восстановишь.
ER диаграмма (которая картинка на мониторе) не содержит тех же триггеров, индексов, хранимых процедур и т.д. Поэтому по ней НЕЛЬЗЯ «сгенерировать полный скрипт для создания базы». Да и информацию о типах полей обычно не выводят.
Опять же, часто в реальной жизни не прописывают ограничения внешних ключей на уровне базы, и из такой базы также НЕЛЬЗЯ сгенерировать ER диаграмму. Разумеется, это плохая практика и так делать не надо — но ведь делают. (((
Вот прямо сейчас работаю с этим:
globalqss.com/idempiere/6.2_20190709/schemaspy/Accounting/tables/fact_acct.html
(Там чуть ниже списка полей таблицы — ER диаграмма)
Создать скрипт для создания базы по этой картинке — нельзя. А использовать для понимания структуры базы при написании запросов — очень даже можно.
Примерно то же с BPMN диаграммой.
В ряде случаев — очень полезно. Но полного представления о всех нюансах не дает.
И если уж делать графическое описание — то исполняемое, чтобы не было разницы между нарисованной картинкой и реальным процессом.
То же справедливо для ER диаграммы — надо прописывать внешние ключи на уровне базы и генерировать её автоматически на основе реальной структуры базы. Тогда это будет реально полезно и не тратится куча времени на согласование картинок и реальной структуры базы.
Опять же, часто в реальной жизни не прописывают ограничения внешних ключей на уровне базы, и из такой базы также НЕЛЬЗЯ сгенерировать ER диаграмму. Разумеется, это плохая практика и так делать не надо — но ведь делают. (((
Вот прямо сейчас работаю с этим:
globalqss.com/idempiere/6.2_20190709/schemaspy/Accounting/tables/fact_acct.html
(Там чуть ниже списка полей таблицы — ER диаграмма)
Создать скрипт для создания базы по этой картинке — нельзя. А использовать для понимания структуры базы при написании запросов — очень даже можно.
Примерно то же с BPMN диаграммой.
В ряде случаев — очень полезно. Но полного представления о всех нюансах не дает.
И если уж делать графическое описание — то исполняемое, чтобы не было разницы между нарисованной картинкой и реальным процессом.
То же справедливо для ER диаграммы — надо прописывать внешние ключи на уровне базы и генерировать её автоматически на основе реальной структуры базы. Тогда это будет реально полезно и не тратится куча времени на согласование картинок и реальной структуры базы.
ЛЮБОЙ инструмент, предназначенный для автоматизации процессов — будет сложным. Просто потому, что процессы сложные.
Никого не интересует сложность скрытая под капотом.
Полагаю, что приближается момент, когда критическая «подкапотная» масса позволит создавать приложения (или схожее, но с иным названием) любой «кухарке» (бизнес-пользователю). Примерно, как сейчас (точнее уже давно) создаются сайты-визитки.
Это дело времени, т.к. постоянно что-то в этом направлении (программирование без программирования) создается, тот же DataExpress. Многое можно делать в Excel без программирования, а на VBA – вообще почти любые фантазии без всякого SQL. Кнопка «запись макроса» в помощь, разные мастера.
Может появится «BPMN для кухарки», который будет «безумно прост». Помню у меня была видеокамера Sony. Возможностей — море. Поэтому там была куча настроек, опций и т.п. Вообще ничего не понять было (деталей не помню, т.к. очень давно было), а если выбрал «не то», то снимает плохо.
Спасала волшебная кнопка «easy», которая позволяла забыть все сложности, убрать всё «под капот», и «просто снимать» видео.
Нет там ничего сложного. От слова совсем. BPMN прост как 3 копейки.
Попробуйте пенсионеру — бухгалтеру показать схему или студентке-секретарше. И спросить: узнаешь свой процесс? Покажи, где стрелочка неверно показана?
В этом плане все равно, что Вы им покажете: BPMN, листинг на фортране или ассемблере.
BPMN — это только для «специально обученных».
К этой теме: помню, что лет двадцать назад обучали BPMу аж боевых генералов, чтобы они понимали, что мы им «понарисовали – то» (кучу квадратиков и кружков, запиханых в альбомчики А3 с позолоченными буковками на толстенной обложке) и за что они отвалили такую «кучу бабла».
Вот именно, для вас — несложно, но. Все нотации и схемы созданы для описания и понимания в первую очередь для менеджеров. А им этого не надо, от слова «совсем».
UPD: по крайней мене я таких не встречал. Внутри IT-фирм схемы используются, на стороне клиента — это лишь дополнительные иллюстрации к тексту.
UPD: по крайней мене я таких не встречал. Внутри IT-фирм схемы используются, на стороне клиента — это лишь дополнительные иллюстрации к тексту.
Это сложно (не настолько сложно, как выучить ЯП — скорее как освоить IDE), но эта сложность инкапсулируется в бизнес-аналитике, который работает в организации. Рядовой пользователь будет видеть только список задач — как, например, в Todoist — и список действий к каждой задаче — «Согласовать», «Подтвердить» и т.п. Конечно, будет хорошо, если владельцы процесса (мененджмент) будут понимать нотации бизнес-процессов (BPMN) в BPMS, но скорее всего они будет менять процессы через прокси (бизнес-аналитиков).
т.е. по методичке любой более-менее тупой студент/сотрудник освоит более-менее сложную BPMS (и, соответственно, нотацию, в которой пишутся исполняемые процессы в этой системе — BPMN, например)
Согласен, что это настолько просто, что усвоит практически любой соображающий человек. Но всё ещё проще. Не нужно «писать» в BPMN нотации. Нужно визуально как в Visio создавать модель процесса в редакторе BPMN. Скрипты на любом языке который поддерживается движком, вносятся в скрипты как части процесса (в этом редакторе), если они нужны. С этим справится любой студент.
"Особые претензии у меня к Террасофт с их BPM online, который они массово продают во все возможные организации, и этот инструмент к BPMN вообще никакого отношения не имеет, однако ..."
Почему это не bpmn?
https://top10-bpm.ru/
Т.к. у них нет своего движка BPMN, и они очень долго обещали интегрировать Bizagi (хороших денег стоит), не знаю интегрировали или нет (1.5 года уже про них ничего не знаю и знать не хочу). Почему не интегрировали тотже Activiti? Ждадность?
Все разработки под BPM online которые я видел, не имеют редактора BPMN и интегрированного движка BPMN. Весь код в ручную на C#. Сплошная маркетинговая профанация (по крайней мере полтора года назад была). В любом случае не нужно. На Activiti или с CMDBuild процессы строятся на порядки быстрее и дешевле.
Все разработки под BPM online которые я видел, не имеют редактора BPMN и интегрированного движка BPMN. Весь код в ручную на C#. Сплошная маркетинговая профанация (по крайней мере полтора года назад была). В любом случае не нужно. На Activiti или с CMDBuild процессы строятся на порядки быстрее и дешевле.
Не защищаю terrasoft, но, кажется, год назад у них появился таки появился импорт из .bpmn (редактор вроде как у них тоже есть, онлайн, визуальный).
Тоже не защищаю terrasoft, но:
www.terrasoft.ru/company/news/66962
Вообще назвать свой продукт «bpm’online» — это очень не красиво. Видимо хотели что бы в поисковиках запросы о BPM в онлайн сразу на них шли.
Стандартизация управления бизнес-процессами. Мультифункциональный дизайнер процессов обеспечит полное соответствие требованиям нотации BPMN 2.0.
www.terrasoft.ru/company/news/66962
Вообще назвать свой продукт «bpm’online» — это очень не красиво. Видимо хотели что бы в поисковиках запросы о BPM в онлайн сразу на них шли.
Это BPMS (система управления бизнес-процессами). А BPMN — это нотация описания исполнимых бизнес-процессов (еще есть EPC, IDEF0 и т.п. — но эти нотации не описывают исполнимые бизнес-процессы). Но не знаю, насколько их [terrasoft bpm] нотацию можно относить к BPMN — у них какая-то своя, кастомная, BPMN-подобная (визуально).
Даже если бизнесу нужен BPMN, который упростит цикл Дёминга и вообще позволит процессы автоматизировать, никогда не получит нужного результата. Т.к. все участники цепочки, — пиявки. Им либо всё равно, либо хочется поживиться, либо они вообще изменений не хотят, либо хотят иметь мутные процессы, что-бы и ответственность размазать и аудит надуть и поживиться в мутной водице, либо просто представления о BPMN не имеют.
Вроде как, что участники процесса, наоборот, освобождаются от того, чтобы изменять процесс — они тупо делают то, что есть в системе (это, по идее, хорошо, т.к. вряд ли рядовой участник будет мыслить в масштабе бизнес-процесса, организации), а владельцы процесса могут менять его вдоль и поперек в любой момент времени — для рядовых участников процесса это будет незаметно. Т.е. тут два профита — людям приходится меньше думать (думать приходится в рамках операции бизнес-процесса, а не в рамках всего процесса) и увеличивается скорость изменений в организации.
Но всё это, конечно, влажные мечты — достижимо только при условии, если в организации уже внедрена система управления бизнес-процессами и владельцы процесса мыслях в терминах процессного подхода (т.е. я обновляю и деплою процесс в продакшен — самостоятельно / через бизнес-аналитиков — и деятельность организации изменяется автоматически).
владельцы процесса мыслях в терминах процессного подхода
Очень философская фраза. Пару абзацев приведите, чтобы расшифровать. Хотя, думаю и целой книжки будет мало.
Даже кто такой владелец процесса — очень сложный вопрос. Обычно все говорят: «чур не я».
Формально: тот, кого назначили владельцем процесса, в документах. Аля материально-ответственное лицо. Практически — тот, кто несет ответственность за результат, связанный с процессом. Если процесс сквозной (затрагивает несколько подразделений), слышал, что обычно ставят лицо, которогое обладает большинством полномочий, связанных с процессом (например, если процесс застрагивает нескольких топов, то владельцем процесса будет генеральный).
Вопрос сложный, но в первой части комментарии имел в виду конкретно того, кто обновляет исполняемый процесс в редакторе и деплоит его в BPMS (с обновлением версий существующих процессов, либо без) — своими руками / через прокси (бизнес-аналитика) — т.е. скорее всего какого-то менджера, с которого спросят за результат. Возможно, участников этой ситуации можно называть не «владельцами процесса», а по-другому — речь про инициативу по изменению бизнес-процесса и конкретное физическое действие по обновлению бп в системе.
А во второй части комментария имел в виду то, что и в первой + то, что миддл менеджеры / топы / etc понимают, что у них есть BPMS, есть организация, в которой есть определенные бизнес-процессы (часть из этих процессов в BPMS, часть из них неявные), и, чтобы произвести какое-либо изменение — я меняю и деплою процесс (физически, в редакторе, как в первой части комментария), вместо того, чтобы подписывать приказ и доводить его до сотрудников по цепочке.
Т.е. еще раз прорезюмируя: очень узкий и специфичный кейс (скорее применимый для крупных организаций / процессов), который я как-то видел воочию — BPM-система является источником заданий для сотрудников и изменение процесса в BPM-системе мгновенно влияет на деятельность организации (у сотрудников добавляются/исчезают задания, изменяется содержание заданий + появляются новые процессы для запуска). И в итоге имеем очень сильный профит от (1) высокой скорости изменений, (2) снижения когнитивной нагрузки у исполнителя (вся информация, нужная для задачи — будет в интерфейсе + из-за этого не нужно иметь представление о всём процессе) и того, что (3) можно понимать, что в данный момент происходит с каждым процессом (какое конкретное физическое действие сейчас выполняется и каким исполнителем, сколько заняло выполнение предыдущих и т.п.).
Вопрос сложный, но в первой части комментарии имел в виду конкретно того, кто обновляет исполняемый процесс в редакторе и деплоит его в BPMS (с обновлением версий существующих процессов, либо без) — своими руками / через прокси (бизнес-аналитика) — т.е. скорее всего какого-то менджера, с которого спросят за результат. Возможно, участников этой ситуации можно называть не «владельцами процесса», а по-другому — речь про инициативу по изменению бизнес-процесса и конкретное физическое действие по обновлению бп в системе.
А во второй части комментария имел в виду то, что и в первой + то, что миддл менеджеры / топы / etc понимают, что у них есть BPMS, есть организация, в которой есть определенные бизнес-процессы (часть из этих процессов в BPMS, часть из них неявные), и, чтобы произвести какое-либо изменение — я меняю и деплою процесс (физически, в редакторе, как в первой части комментария), вместо того, чтобы подписывать приказ и доводить его до сотрудников по цепочке.
Т.е. еще раз прорезюмируя: очень узкий и специфичный кейс (скорее применимый для крупных организаций / процессов), который я как-то видел воочию — BPM-система является источником заданий для сотрудников и изменение процесса в BPM-системе мгновенно влияет на деятельность организации (у сотрудников добавляются/исчезают задания, изменяется содержание заданий + появляются новые процессы для запуска). И в итоге имеем очень сильный профит от (1) высокой скорости изменений, (2) снижения когнитивной нагрузки у исполнителя (вся информация, нужная для задачи — будет в интерфейсе + из-за этого не нужно иметь представление о всём процессе) и того, что (3) можно понимать, что в данный момент происходит с каждым процессом (какое конкретное физическое действие сейчас выполняется и каким исполнителем, сколько заняло выполнение предыдущих и т.п.).
В объекте "функция" предусматриваются три "Connection Point" (visio):
- вверху и внизу объекта "функция" (и "события") — для указания структуры потока (очередность действий, событий);
- слева в овале "функция" два коннектора: один вход, второй выход (общие для docflow и потока материалов и т.п.);
- справа два коннектора: для исполнителя функции и инструмента, который используется для реализации функции.
Такой подход позволит легче читать схему ЕРС,
Не уловил, а чем это принципиально отличается, в плане читаемости, от:
?
Ну или так можно сделать, с "детализация — проваливаемся в низ" (Archi):
Archi 4 штука забавная, но кроме как рисовалку пока не мог освоить.
По поводу Archi EPC: РИСУЕМ EPC В ARCHI
Сила и одновременно слабость Archi: в нем нет правил построения схем по нотациям. Как в нем реализовать то, что я в статье указал? Хотя бы проверку соблюдения правил нотации ЕРС, например, нельзя же к объекту «событие» (пусть будет «бизнес-событие») приклеивать роли, документы и всё — что хочешь. Событие «зашло солнце», как и любое другое событие может быть связано только с функцией (как вариант, через логический элемент).
Как сделать блокировку «неправильных» соединений? Как сделать хотя бы Definition\ Occurrence и Smart Disigner. Всё это есть в АРИС, можно сделать в visio (что-то просто, что-то с применением VBA), но вот в Archi как?
Хотя бы как в Archi сменить значки на более ЕРС-похожие (форма-геометрия, цвет), а то схема совсем как не ЕРС выглядит.
Ну и в Вашем примере не увидел главного: связь функций (workflow).
По поводу Archi EPC: РИСУЕМ EPC В ARCHI
Сила и одновременно слабость Archi: в нем нет правил построения схем по нотациям. Как в нем реализовать то, что я в статье указал? Хотя бы проверку соблюдения правил нотации ЕРС, например, нельзя же к объекту «событие» (пусть будет «бизнес-событие») приклеивать роли, документы и всё — что хочешь. Событие «зашло солнце», как и любое другое событие может быть связано только с функцией (как вариант, через логический элемент).
Как сделать блокировку «неправильных» соединений? Как сделать хотя бы Definition\ Occurrence и Smart Disigner. Всё это есть в АРИС, можно сделать в visio (что-то просто, что-то с применением VBA), но вот в Archi как?
Хотя бы как в Archi сменить значки на более ЕРС-похожие (форма-геометрия, цвет), а то схема совсем как не ЕРС выглядит.
Ну и в Вашем примере не увидел главного: связь функций (workflow).
Ну и в Вашем примере не увидел главного: связь функций (workflow).
Да это я стрелочку забыл нарисовать. Кстати, для следования нужным правилам потенциально можно применить jArchi – Scripting for Archi.
По поводу "главного". Я так я не уловил, почему "Такой подход позволит легче читать схему ЕРС"? Хотелось бы посмотреть на пример "легче читаемой схемы".
По поводу «главного». Я так я не уловил, почему «Такой подход позволит легче читать схему ЕРС»? Хотелось бы посмотреть на пример «легче читаемой схемы».
Если про «главное» — про отсутствие стрелок между функциями (событиями), то стрелки «потока» — ключевой элемент схемы.
Про «легче читать схему ЕРС», — это когда она рисуется из стандартных ЕРС — примитивов, т.е. которые как АРИС, так и визио (скругленный прямоугольник зеленого цвета, красноватый шестиугольник и т.п.). Читать ЕРС схему из иных элементов — тяжело.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Хорошие BPM — инструменты, которых нет и нет. Моделирование процессов