Comments 46
Также было высказано подозрение, что теория процессного управления — по сути чистый пиар и маркетинг, не имеющий практической пользы.
Я вполне с этим согласен.
- в реальной жизни автоматизации хорошо поддаются только довольно примитивные (с точки зрения человека) процессы
- все языки моделирования BPMx достаточно неудобны, чтобы строить что-то реальное
- в результате нужен второй (третий) язык, чтобы созданная система взлетела
- как только появляется этот второй и третий языки, аналитики перестают понимать, как работает процесс
- созданные для аналитиков системы для рисования диаграмм программистам как правило категорически неудобны, а без программистов все это не работает
Ну т.е. не то чтобы это был чистый пиар, но большая часть маркетинговых материалов очень сильно преувеличивает достоинства, и замалчивает недостатки. Это факт.
в реальной жизни автоматизации хорошо поддаются только довольно примитивные (с точки зрения человека) процессы
Большинство автоматизируемых бизнес-процессов, действительно, простые. Однако, это не мешает получению финансового эффекта. На конвейере часто тоже простые операции выполняются, а финансовый эффект от конвейера — значительный.
Вообще бывают, хотя их и не много,
сложные бизнес-процессы
Ну, по сути то что автоматизируется — это и есть конвейер. Как правило.
На схеме очень хорошо видно, что циклы плохо ложатся на BPMN. А представленная схема не сколько сложна, сколько плохо описана и перегружена, отчего неочевидна и кажется сложной.
представленная схема не сколько сложна, сколько плохо описана и перегружена, отчего неочевидна и кажется сложной
Данную схему имеет смысл разбить на несколько подпроцессов (т.е. на несколько вложенных друг в друга схем). Тогда восприниматься она будет легче. Я не стал этого делать, т.к. при наличии подпроцессов трудно все объяснить или показать на одном скриншоте.
Но, в любом случае, схемы алгоритмов принятия решений в этом бизнес-процессе достаточно сложные по сравнению со схемами обычных бизнес-процессов. Эта сложность объективна, она останется даже, если разбить все на подпроцессы.
Ценность хорошей диаграммы в том что её легко понять, а не в том что можно «все объяснить или показать на одном скриншоте». Процесс можно представить с разным уровнем детализации, если на диаграмме более 20 объектов, значит уровень детализации следуют понизить, умело орудуя drilldown можно любую схему сделать понятной.
Представленная схема не кажется мне сложной, любая реальная схема «обрастает» подробностями, делая её ценнее, но не всегда имеет смысл эти подробности сразу выкладывать на верхнем уровне. Хотя должен признать «сложные схемы» выглядят солиднее, иногда это имеет свой положительный эффект.
Представленная схема не кажется мне сложной, любая реальная схема «обрастает» подробностями, делая её ценнее, но не всегда имеет смысл эти подробности сразу выкладывать на верхнем уровне. Хотя должен признать «сложные схемы» выглядят солиднее, иногда это имеет свой положительный эффект.
созданные для аналитиков системы для рисования диаграмм программистам как правило категорически неудобны, а без программистов все это не работает
В данном случае возможно взаимодействие аналитика с программистом. Это проверено на практике:
Аналитик «заказывает» у программиста нужные ему компоненты- графические элементы форм заданий, коннекторы к внешним хранилищам и т.п. — Программист реализует их и устанавливает в палитру среды разработки. После этого аналитик использует их в своих бизнес-процессах.
Моя практика показывает, что все равно получается плоховато. По ряду причин: основная из которых в том, что процессы это плохой вид повторно используемого компонента. Коннекторы — это да, это достаточно классический вид, широко используемый в других проектах. А вот сами процессы — это с трудом.
процессы это плохой вид повторно используемого компонента
С повторным использованием бывают сложности. Оно возможно, в частности, подпроцессы стараются разрабатывать так, чтобы они могли быть использованы в большом количестве процессов. В какой-то степени это напоминает процедурное программирование с повторно используемыми процедурами. А аналог объектной модели в бизнес-процессы пока еще не получилось интегрировать. Это приводит к необходимости дублировать часть функциональности в разных бизнес-процессах.
Но, несмотря на определенные сложности, процессный подход может принести качественные преимущества бизнесу. Например, специалисту, хорошо разбирающемуся в том, как при помощи изменения тарифных планов и предоставления скидок разным категориям клиентов повышать продажи, это дает возможность очень быстро управлять продажами, немедленно реагируя на изменения на рынке при помощи оперативной модификации находящиеся в эксплуатации бизнес-процессов. — Не надо каждый раз «дергать» программиста, можно самостоятельно видоизменить схему и параметры. К программисту в этом случае надо обращаться редко, для создания новых элементов бизнес-процессов.
Можете привести примеры кейсов из вашей практики, процессная реализация которых была неудачной?
Так ведь понятно, почему не получается переиспользовать. Во всяком случае пока для бизнес процессов нет нормальной модели, и устоявшейся практики, хотя бы такой, как для ООП.
Что до моей практики, то я бы так сказал — самая большая проблема при использовании конкретно BPMN состоит как раз в том, что из этого пытаются сделать язык программирования, и получается отвратительно. Т… е даже если все работает — это получается настолько невнятно, что сопровождать потом практически невозможно. Т.е. примерно так:
- переиспользование на ужасном уровне, хуже чем было во времена Фортрана
- отслеживание изменений — где-то примерно также. Хуже чем было при CVS
- тестирование, отладка — ужасно
- механизмы анализа кода, верификации, статического анализа — в зачаточном состоянии, если не сказать хуже
Языки описания бизнес-процессов пока все-таки не позиционируются как полноценные языки программирования. К ним нельзя предъявлять такие высокие требования. Но существует ли какая-то другая технология, не имеющая описанных выше сложностей, позволяющая специалисту предметной области, не знакомому с программированием, быстро и гибко модифицировать бизнес-логику и структуру приложения?
А такая возможность может существенно улучшать финансовые результаты автоматизируемого предприятия.
Многие широко используемые в настоящее время технологии сначала были несовершенны. Главное, чтобы здравая идея в технологии была. В новой технологии сложности обязательно будут. Но, если идея хорошая, с течением времени сложности будут преодолены.
А такая возможность может существенно улучшать финансовые результаты автоматизируемого предприятия.
Многие широко используемые в настоящее время технологии сначала были несовершенны. Главное, чтобы здравая идея в технологии была. В новой технологии сложности обязательно будут. Но, если идея хорошая, с течением времени сложности будут преодолены.
Эволюция развития BPMS и «естественный отбор» за примерно 15 — 20 лет привели к тому...
В новой технологии сложности обязательно будут. Но, если идея хорошая, с течением времени сложности будут преодолены.Есть у меня идея. Уже несколько лет зреет, написать статью о причинах и последствиях этой эволюции.
Когда я разрабатывал приложение для описания БП, то изначально намеревался воспользоваться BPMN, но чем больше я прикладывал эту нотацию к интерфейсу, тем больше осознавал насколько она ограничена и искусственна. В итоге оставил попытки и разработал собственную нотацию, что было спорным, но как сейчас уже понятно верным решением.
Попутно избавился от порока (с моей точки зрения) большинства систем управления процессами и проектами — процессный подход. Во всех диаграммах всегда фигурируют процессы, которые много и подробно расписаны, но нигде не отведено места целям исполнения процессов и необходимым для этого ресурсам. При изучении таких диаграмм складывается представление, что процессы существуют ради процессов, а цели достигаются сами по себе. Мне кажется это пошло от консультантов, которые были пионерами в описании процессов, они берут с клиентов за часы исполнения работ, поэтому крайне заинтересованы представлять суть работы именно в процессах, и крайне не заинтересованы акцентировать внимание на конечных результатах своей деятельности. Отчего во всей «процессной науке» случился перекос.
Да, и забавный нюанс, ещё не разу не встретился бизнес-аналитик который описывая какую-нибудь ситуацию не приводил бы аналогию с мерседесом :)
Попутно избавился от порока (с моей точки зрения) большинства систем управления процессами и проектами — процессный подход. Во всех диаграммах всегда фигурируют процессы, которые много и подробно расписаны, но нигде не отведено места целям исполнения процессов и необходимым для этого ресурсам. При изучении таких диаграмм складывается представление, что процессы существуют ради процессов, а цели достигаются сами по себе. Мне кажется это пошло от консультантов, которые были пионерами в описании процессов, они берут с клиентов за часы исполнения работ, поэтому крайне заинтересованы представлять суть работы именно в процессах, и крайне не заинтересованы акцентировать внимание на конечных результатах своей деятельности. Отчего во всей «процессной науке» случился перекос.
Да, и забавный нюанс, ещё не разу не встретился бизнес-аналитик который описывая какую-нибудь ситуацию не приводил бы аналогию с мерседесом :)
Процессный подход — это не только графическая нотация. Для исполнимых бизнес-процессов нужно еще определить механизм назначения исполнителей на роли, задать структуры данных и т.д.
BPMN — не единственная возможная нотация, применяющаяся в процессном подходе. Например, я иногда использую UML (Activity Diagramm), есть и другие «процессные» нотации. Но BPMN «продвигает» очень активная команда. Вполне возможно, что чисто «маркетинговыми» приемами остальные нотации будут вытеснены ей на периферию предметной области.
BPMN — не единственная возможная нотация, применяющаяся в процессном подходе. Например, я иногда использую UML (Activity Diagramm), есть и другие «процессные» нотации. Но BPMN «продвигает» очень активная команда. Вполне возможно, что чисто «маркетинговыми» приемами остальные нотации будут вытеснены ей на периферию предметной области.
ещё не разу не встретился бизнес-аналитик который описывая какую-нибудь ситуацию не приводил бы аналогию с мерседесом :)Я при объяснении процессного подхода часто привожу аналогию с велосипедом :)
Поделитесь разработанной нотацией. Хабр — идеальное место для обсуждения.
Можете посмотреть здесь, там на странице общее описание приложения inShort, но есть ссылка на pdf с документацией где сам формализм описан вполне подробно.
Слишком много народу паразитирует на этих системах.
А сами системы паразитируют на бизнесе. )
BPMN действительно мало применимы, пока. Все красивые интерфейсы как правило на работают в стоке и требуют длительного и мучительного допиливания. То что красиво на картинке и в презентации превращается в ад, для разработчиков.
Да и мегаграфики, часто рисуют те, кто ни разу не был на конкретном производстве и не понимает живой процесс.
Короче во всем здравый смысл и золотая середина, не ведемся на презентации, графики апробируем на живом процессе. Упрощаем систему, максимально, не строем сложных процессов, разбиваем их на несколько и т.д. Выбирая софт сразу узнаем сколько будет стоить допилить его под себя )
А сами системы паразитируют на бизнесе. )
BPMN действительно мало применимы, пока. Все красивые интерфейсы как правило на работают в стоке и требуют длительного и мучительного допиливания. То что красиво на картинке и в презентации превращается в ад, для разработчиков.
Да и мегаграфики, часто рисуют те, кто ни разу не был на конкретном производстве и не понимает живой процесс.
Короче во всем здравый смысл и золотая середина, не ведемся на презентации, графики апробируем на живом процессе. Упрощаем систему, максимально, не строем сложных процессов, разбиваем их на несколько и т.д. Выбирая софт сразу узнаем сколько будет стоить допилить его под себя )
Слишком много народу паразитирует на этих системах.
Да. Это, к сожалению, имеет место.
BPMN действительно мало применимы, пока. Все красивые интерфейсы как правило на работают в стоке и требуют длительного и мучительного допиливания. То что красиво на картинке и в презентации превращается в ад, для разработчиков.
Технология эта пока не совершенна. Работать в рамках этой технологии непривычно и тяжело как специалистам предметной области, так и программистам. Но эффект от ее применения есть. В ее основе лежит здравый подход. Не страшно, что пока «шелухи» разной вокруг нее очень много. С течением времени все это должно «рассосаться», текущие проблемы будут решены, технология должна стать широко используемой в бизнесе.
С течением времени все это должно «рассосаться», текущие проблемы будут решены, технология должна стать широко используемой в бизнесе.
За BPM системами я лет 15 слежу. Даже, все двадцать. Проблема BPMS в том, что разработчики процессного подхода пытаются повторить путь разработчиков информационных систем. Т.е. основателям BPMS нужно было бы изначально изучить Computer Science и уже затем бизнес.
А получилось, что ребята выучились на манагеров и пошли писать свой язык и его интерпретатор. Оделись в солидные костюмы, просят солидные финансы, а по факту их уровень алгоритмического мышления на уровне старшеклассника, и могут автоматизировать лишь не более 5% процессов предприятия, типа учета командировочных расходов, т.е. постфактум мелкий кусочек даже учетных систем. А когда речь заходит о планировании, о развитии предприятия, тут у них полный провал. Далее чеклистов согласования заявок мысль не работает. Поддержка версионности процессов вообще к хаосу ведет. А надо бы не шишки набивать, а детально изучить плюсы и минусы систем управления версиями и систем поддержки коллективной разработки ИС.
По мне так Adaptive Case Management и его совмещение с системами управления контентом, более полезное направления развития BPM в автоматизации постоянно эволюционирующих социальных процессов.
А за поднятую тему и детальный разбор плюс вам в карму и за статью!
Проблема BPMS в том, что разработчики процессного подхода пытаются повторить путь разработчиков информационных систем. Т.е. основателям BPMS нужно было бы изначально изучить Computer Science и уже затем бизнес.
Это — не простой вопрос. Можно придумать разные интересные и полезные технологии, которые никто не будет использовать в силу сложности их освоения. Данная технология предназначена для управленцев и разрабатывали ее тоже управленцы (менеджеры), поэтому она соответствует их мышлению и менеджеры, хотя и с трудом, готовы ей пользоваться. Похоже, что таким не «прямым» путем, постепенно улучшая и, с течением времени, заимствуя решения из Computer Science, можно широко внедрить этот подход в практику и сделать реально эффективным.
А если изначально сделать все «как надо», то менеджеры не поймут, изучать-использовать откажутся и все это будет не востребовано.
Думаю, зря вы подстраиваетесь под менеджеров. Например, современная системная инженерия (та что про разработку железа и бетона) — берет из Software Engineering практики пачками и адаптирует их себе во благо. Например, agile методологию.
… постепенно улучшая и, с течением времени, заимствуя решения из Computer Science, можно широко внедрить этот подход в практикуЭта точка зрения понятна и допустима, если бы не 15...20 лет эволюции BPMS. Очень похоже, что не туда эволюционирует.
Компания, где я работаю, также занимается автоматизацией бизнес-процессов. Но это одно из направлений нашей деятельности, мы автоматизируем не все подряд процессы, а только некоторый подкласс, но все описанные вами нюансы у нас встречаются.
У нас тоже был модуль, работавший как ваш BPMS-движок. Там можно было рисовать в графике процессы, состоявшие из заданий, соединять их стрелочками, и т.д. — все как у вас. Мы даже это внедряли, но потом отказались от этого подхода. Почему:
1) Реальный процесс получался из десятков задач. Диаграмма занимала несколько экранов, ходила петлями и змейками — жуть.
2) Все проблемы с переиспользованием и версионированием, о которых в коментах уже говорили.
3) Если на каком-то шаге возникала программная ошибка, то процесс падал и без участия программиста не оживал. Ну как пример: пользователь вбил адрес в каком-то новом формате, о котором аналитики не подумали. Код свалился с ошибкой, процесс остановился — ждем программиста. В результате пара человек просто сидела на поддержке 100% времени, разбирая целыми днями эти ошибки.
Но самый большой гвоздь в крышку гроба был забит, когда пришел очередной заказчик, и выдвинул такие требования:
— Хочу, чтобы некоторые задачи в некотором конкретном процессе можно было отменять.
— А еще некоторые задачи мне хочется менять местами — опять же, в конкретном инстансе конкретного процесса. Ну вот попался такой особый случай — менеджер должен иметь возможность кое-что перепланировать.
— А еще бывает, что менеджеру хочется в некотором конкретном случае добавить несколько дополнительных задач.
Самое ужасное, что эти требования — нормальные, если речь идет о длительном процессе с уникальными особенностями. Представьте, что вы автоматизируете бизнес строительной компании, которая строит коттеджи по уникальным проектам. Для каждого участка строительства надо предусмотреть разное количество задач. Если эти задачи еще и делаются в параллели, то средствами BPMS это не решается никак.
В итоге сейчас в нашей компании есть средство, которому эта задача «по зубам». Я не знаю, до какой степени об этом можно рассказывать. В википедии навскидку похожего не нашел. Скажу только, что конкретный вид процесса каждый раз генерируется автоматически. Если кому-то интересно — попробую сделать статью об этом и опубликовать через корпоративный блог.
У нас тоже был модуль, работавший как ваш BPMS-движок. Там можно было рисовать в графике процессы, состоявшие из заданий, соединять их стрелочками, и т.д. — все как у вас. Мы даже это внедряли, но потом отказались от этого подхода. Почему:
1) Реальный процесс получался из десятков задач. Диаграмма занимала несколько экранов, ходила петлями и змейками — жуть.
2) Все проблемы с переиспользованием и версионированием, о которых в коментах уже говорили.
3) Если на каком-то шаге возникала программная ошибка, то процесс падал и без участия программиста не оживал. Ну как пример: пользователь вбил адрес в каком-то новом формате, о котором аналитики не подумали. Код свалился с ошибкой, процесс остановился — ждем программиста. В результате пара человек просто сидела на поддержке 100% времени, разбирая целыми днями эти ошибки.
Но самый большой гвоздь в крышку гроба был забит, когда пришел очередной заказчик, и выдвинул такие требования:
— Хочу, чтобы некоторые задачи в некотором конкретном процессе можно было отменять.
— А еще некоторые задачи мне хочется менять местами — опять же, в конкретном инстансе конкретного процесса. Ну вот попался такой особый случай — менеджер должен иметь возможность кое-что перепланировать.
— А еще бывает, что менеджеру хочется в некотором конкретном случае добавить несколько дополнительных задач.
Самое ужасное, что эти требования — нормальные, если речь идет о длительном процессе с уникальными особенностями. Представьте, что вы автоматизируете бизнес строительной компании, которая строит коттеджи по уникальным проектам. Для каждого участка строительства надо предусмотреть разное количество задач. Если эти задачи еще и делаются в параллели, то средствами BPMS это не решается никак.
В итоге сейчас в нашей компании есть средство, которому эта задача «по зубам». Я не знаю, до какой степени об этом можно рассказывать. В википедии навскидку похожего не нашел. Скажу только, что конкретный вид процесса каждый раз генерируется автоматически. Если кому-то интересно — попробую сделать статью об этом и опубликовать через корпоративный блог.
1) Реальный процесс получался из десятков задач. Диаграмма занимала несколько экранов, ходила петлями и змейками — жуть.
Обычно путем декомпозиции, вынося участки схемы в подпроцессы, можно существенно улучшить понимаемость схем процессов. Если, например, бизнес-процесс состоит из 7 шагов, каждый из которых является подпроцессом, то на диаграмме процесса будет всего 7 элементов. Однако, при клике на любой из этих элементов, BPMS откроет схему этого подпроцесса. В случае четырех уровней вложенности для подпроцессов из 7 элементов, 4-ый уровень будет содержать 2401 задачу, при этом каждая схема будет состоять только из 7 элементов.
Для реальных бизнес-процессов, конечно, все не так просто. При декомпозиции надо учитывать не только количество элементов, но и бизнес-логику процесса. Но, в целом, путем декомпозиции понимаемость схем можно существенно улучшить.
2) Все проблемы с переиспользованием и версионированием, о которых в коментах уже говорили.
Эти проблемы пока не решены. Приходится иногда использовать дублирование, которого, конечно, хотелось бы избежать.
3) Если на каком-то шаге возникала программная ошибка, то процесс падал и без участия программиста не оживал. Ну как пример: пользователь вбил адрес в каком-то новом формате, о котором аналитики не подумали. Код свалился с ошибкой, процесс остановился — ждем программиста. В результате пара человек просто сидела на поддержке 100% времени, разбирая целыми днями эти ошибки.
Если такая ошибка связана с неправильно введенными данными, то многие BPMS позволяют исправить ее без программиста. — Администратор системы может изменить значение переменной конкретного экземпляра бизнес-процесса, при этом в историю действий с экземпляром процесса будет добавлена соответствующая запись.
Но самый большой гвоздь в крышку гроба был забит, когда пришел очередной заказчик, и выдвинул такие требования:
— Хочу, чтобы некоторые задачи в некотором конкретном процессе можно было отменять.
Для таких действий предусмотрен элемент «Бизнес-Исключение»
— А еще некоторые задачи мне хочется менять местами — опять же, в конкретном инстансе конкретного процесса. Ну вот попался такой особый случай — менеджер должен иметь возможность кое-что перепланировать
— А еще бывает, что менеджеру хочется в некотором конкретном случае добавить несколько дополнительных задач.
Это классическому процессному подходу не очень хорошо соответствует. Все же процессный подход появился как аналог конвейера. Во многих BPMS сделать такие изменения бизнес-процессов можно, но делать их будет неудобно и выглядеть они будут неестественно.
Для таких операций был придуман Adaptive Case Management, но он отличается от традиционного процессного подхода.
Самое ужасное, что эти требования — нормальные, если речь идет о длительном процессе…
В случае длительных процессов есть методы перевода экземпляров бизнес-процесса на новую версию определения бизнес-процесса. При этом в новый экземпляр бизнес-процесса переносятся данные и точки управления из старого экземпляра. Если версии не очень сильно отличаются, такое преобразование тоже можно сделать без участия программиста.
Представьте, что вы автоматизируете бизнес строительной компании, которая строит коттеджи по уникальным проектам. Для каждого участка строительства надо предусмотреть разное количество задач. Если эти задачи еще и делаются в параллели, то средствами BPMS это не решается никак.
Процессный подход не предназначен для решения таких задач. Для таких задач надо применять управление проектами. Для этого разработан другой класс программного обеспечения. Бизнес-процессы предполагают многократное выполнение одних и тех же цепочек действий. Проект предполагает однократное выполнение, контроль ресурсов, возможность существенного отличия фактических действий от плановых и т.п.
В проектном подходе можно использовать процессное управление как вспомогательное направление для автоматизации использующихся во многих проектах одних и тех же рутинных процедур. Но основным в этом случае все равно должно быть проектное управление.
В итоге сейчас в нашей компании есть средство, которому эта задача «по зубам». Я не знаю, до какой степени об этом можно рассказывать. В википедии навскидку похожего не нашел. Скажу только, что конкретный вид процесса каждый раз генерируется автоматически.
Если кому-то интересно — попробую сделать статью об этом и опубликовать через корпоративный блог.
Интересно. Поместите ссылку на блог.
Обычно путем декомпозиции, вынося участки схемы в подпроцессы, можно существенно улучшить понимаемость схем процессов. Если, например, бизнес-процесс состоит из 7 шагов, каждый из которых является подпроцессом, то на диаграмме процесса будет всего 7 элементов. Однако, при клике на любой из этих элементов, BPMS откроет схему этого подпроцесса. В случае четырех уровней вложенности для подпроцессов из 7 элементов, 4-ый уровень будет содержать 2401 задачу, при этом каждая схема будет состоять только из 7 элементов.
Для реальных бизнес-процессов, конечно, все не так просто. При декомпозиции надо учитывать не только количество элементов, но и бизнес-логику процесса. Но, в целом, путем декомпозиции понимаемость схем можно существенно улучшить.
У нас также использовались подпроцессы, все это было возможно. Однако я много раз смотрел товарищам через плечо и видел, как они скролят направо-налево и вверх-вниз какие-то змеиные кольца. С одной стороны, мир не идеален, и, если приложить усилия, наверняка можно было сделать процесс более читаемым. С другой стороны, эти люди не враги себе, наверняка есть большие сложности с тем, чтобы все упростить.
Но было бы интересно увидеть конкретные примеры с вашей стороны. В реальном решении, на сколько сложны бизнес-процессы?
Процессный подход не предназначен для решения таких задач. Для таких задач надо применять управление проектами. Для этого разработан другой класс программного обеспечения. Бизнес-процессы предполагают многократное выполнение одних и тех же цепочек действий. Проект предполагает однократное выполнение, контроль ресурсов, возможность существенного отличия фактических действий от плановых и т.п.
Из написанного можно сделать вывод, что процессы — это максимально упрощенная версия проектов.
«Проект предполагает однократное выполнение» — естественно, однократное выполнение не автоматизируется, но мой пример — строительство коттеджей по уникальным проектам — можно представить как процессы с вариабельными частями, либо типовые проекты. И это уже можно автоматизировать.
«контроль ресурсов» — тут не понял. При выполнении процесса легче легкого контролировать ресурсы. Как и другие показатели.
«возможность существенного отличия фактических действий от плановых» — что значит «существенного»? Если в процессе стоит ветвление по условию, это уже проект, или еще нет?
Ну и т.д.
«контроль ресурсов» — тут не понял. При выполнении процесса легче легкого контролировать ресурсы. Как и другие показатели.Рискну ответить за автора: Тут речь о смещении с контроля ресурсов на планирование порядка выполнения набора работ в условиях ограничения ресурсов. Например, для рытья котлована можно взять 1 экскаватор, а можно 5 шт. Система «управления проектами» выстраивает «критический путь», который в условиях имеющихся ресурсов позволяет оценить сроки и стоимость всего проекта.
«возможность существенного отличия фактических действий от плановых» — что значит «существенного»? Если в процессе стоит ветвление по условию, это уже проект, или еще нет?Вы наступили на любимую мозоль, начало истории которой можно найти в Древней Греции: Корабль Тесея — парадокс, который можно сформулировать так: «Если все составные части исходного объекта были заменены, остаётся ли объект тем же объектом?»
Ваш пример со строительством коттеджей ровно о том же.
Именно по этой границе происходит борьба автоматизаторов PM и BPM, особенно, если это две независимых команды. По мне так должна быть одна система, в которой гармонично переплетаются PM/BPM/ACM. И далее выясняется, что ИС должна быть тесно интегрирована с ERP & CRM.
Но было бы интересно увидеть конкретные примеры с вашей стороны. В реальном решении, на сколько сложны бизнес-процессы?
Я стараюсь использовать простые процессы. Часто вместо большого и сложного бизнес-процесса можно сделать набор относительно простых процессов, взаимодействующих друг с другом через данные или сообщения. Наиболее сложные процессы, которые я разрабатывал, содержали порядка ста элементов, разнесенных по четырем уровням вложенности подпроцессов. На одной схеме «промежуточного» процесса было два-три вызова подпроцессов.
пользователь вбил адрес в каком-то новом формате, о котором аналитики не подумали. Код свалился с ошибкой, процесс остановился — ждем программиста.Тут можно было бы сделать блокирвоку, что невалидная заявка не снимается с данного пользователя. Так и болтается в его списке задач. И еще продумать форму ввода адреса, чтобы не вбивали кривые адреса.
… если кому-то интересно — попробую сделать статьюКонечно интересно! Пишите!
Можно выстроить данные ИС-системы по оси PM-BPM. Первые могут быть и с генератором процесса (или браться из шаблонов), который затем вручную корректируются. Идеальная система должна быть где-то посередине, поддерживая обе парадигмы, как встраиваемые в друг-друга фрагменты. Похоже, у вас нечто похожее реализовано. Есть еще крайность Adaptive Case Management, который больше на чат с набором правил похож и накапливанием заполненных переменных.
Тут можно было бы сделать блокирвоку, что невалидная заявка не снимается с данного пользователя. Так и болтается в его списке задач. И еще продумать форму ввода адреса, чтобы не вбивали кривые адреса.
Ошибка может проявиться через много шагов после того, как были вбиты данные. Естественно, этого пытаются избежать, но мир не идеален и всякое бывает. Проблема еще и в том, что в том подходе, который описан в статье, задача отката не решается, если только специально не создавать точки отката. Впрочем, и с точками отката тоже не все ясно — ошибочный процесс мог поменять что-то вне своих локальных переменных — как это откатить?
Понятно, что откаты нужно отдельно прграммировать. Минимально, что можно сделать автоматически, это запустить процесс с прежней точки и попросить пользователей подтвердить свое прежнее решение. И для разбора полетов хранить всю историю изменения переменных.
ошибочный процесс мог поменять что-то вне своих локальных переменных — как это откатить?Опять же, универсальное решение вряд ли есть. Можно ограничить возможность редактирования переменных, а также хранить историю изменений. Можно реализовать механизм отката транзакций.
Можно все, хотелось бы пример реального решения.
Понятно, что откаты нужно отдельно программировать. Минимально, что можно сделать автоматически, это запустить процесс с прежней точки и попросить пользователей подтвердить свое прежнее решение.
Не совсем понятно, что делать, если кто-то не подтвердит свое прежнее решение.
Впрочем, и с точками отката тоже не все ясно — ошибочный процесс мог поменять что-то вне своих локальных переменных — как это откатить?
Для таких случаев было введено понятие «Компенсация». Если на этапе разработки бизнес-процесса для узла-действия известно, что после выполнения этого действия может быть откат, то с ним связывается цепочка действий, которая должна быть выполнена в случае отката (В нотации BPMN соединяется специальной пунктирной линией).
Например, если бизнес-процесс связан с оформлением турпоездки, то при изменении клиентом уже частично оформленного варианта может потребоваться отменить бронирование гостиницы, сдать билеты и т.п.
Вы немного не о том написали. Вы написали о бизнес сценарии «отмена турпоездки» или «изменение в планах поездки». Наша система тоже это умеет — надо заложить дополнительные правила по отмене ненужных действий. Система построит новый процесс, в котором будут шаги по отмене ненужных действий и совершению новых нужных (например, отменить бронирование гостиницы, забронировать яхту на эти же даты).
Но это просто дополнительные требования, которые могут быть, а могут и нет. Изначально я писал о том, что если произошла техническая ошибка (код выбросил исключение), то нет общего способа решить проблему без программиста. Предложили вариант откатиться на последнее ручное действие — это не подходит, т.к. отмена в общем случае не реализуема.
Пример. Процесс планирования турпоездки. Одно из действий — бронирование гостиницы — автоматизировано. Наша система посылает в систему бронирования запрос, система бронирования что-то отвечает. Внезапно интерфейс системы бронирования чуть-чуть поменяли, или решили забронировать какую-то нестандартную гостиницу. Ответ от системы бронирования пришел и был провалидирован, но на одном из дальнейших шагов (скажем, распечатка памятки для клиента) произошла системная ошибка — гостиница называлась корейскими иероглифами, для которых не нашлось шрифтов.
Автоматически подобные ошибки не решить: мы не знаем, какие шаги отменять. И как их правильно отменять. Если мы попробуем включить процесс «компенсации», то он тоже может упасть на каком-нибудь шаге вроде «распечатки квитанции об отмене».
Но это просто дополнительные требования, которые могут быть, а могут и нет. Изначально я писал о том, что если произошла техническая ошибка (код выбросил исключение), то нет общего способа решить проблему без программиста. Предложили вариант откатиться на последнее ручное действие — это не подходит, т.к. отмена в общем случае не реализуема.
Пример. Процесс планирования турпоездки. Одно из действий — бронирование гостиницы — автоматизировано. Наша система посылает в систему бронирования запрос, система бронирования что-то отвечает. Внезапно интерфейс системы бронирования чуть-чуть поменяли, или решили забронировать какую-то нестандартную гостиницу. Ответ от системы бронирования пришел и был провалидирован, но на одном из дальнейших шагов (скажем, распечатка памятки для клиента) произошла системная ошибка — гостиница называлась корейскими иероглифами, для которых не нашлось шрифтов.
Автоматически подобные ошибки не решить: мы не знаем, какие шаги отменять. И как их правильно отменять. Если мы попробуем включить процесс «компенсации», то он тоже может упасть на каком-нибудь шаге вроде «распечатки квитанции об отмене».
Если в эксплуатации проявилась ошибка в коде коннектора, обработчика или в логике бизнес-процесса, — это может вызвать проблемы.
Если ошибка в логике, — бизнес-аналитик ее исправляет и передает администратору BPMS новую версию бизнес-процесса для загрузки в систему. После установки новой версии, новые экземпляры данного бизнес-процесса уже будут нормально исполняться, но надо еще исправить старые экземпляры. Для этого применяются различные варианты действий:
Если ошибка в коде, то программист исправляет ее, собирает новый компонент и пишет заявку администратору BPMS на обновление компонента в системе. Иногда загрузки нового компонента достаточно, чтобы «зависшие» экземпляры пошли дальше. Если нет, то можно дополнительно применить описанные выше варианты действий.
При эксплуатации BPMS важно, чтобы программист и бизнес-аналитик работали с промышленной системой не напрямую, а через администратора, а также чтобы все корректирующие действия фиксировались и оформлялись соответствующими документами.
Иначе можно потерять контроль над системой — никто не будет понимать, почему система себя так ведет, надежны ли содержащиеся в ней данные и как можно исправить ошибки…
Если ошибка в логике, — бизнес-аналитик ее исправляет и передает администратору BPMS новую версию бизнес-процесса для загрузки в систему. После установки новой версии, новые экземпляры данного бизнес-процесса уже будут нормально исполняться, но надо еще исправить старые экземпляры. Для этого применяются различные варианты действий:
- Бизнес-аналитик пишет администратору BPMS заявку, в которой описывает, в каких экземплярах бизнес-процессов надо изменить переменные и указывает их правильные значения. Иногда этого достаточно, чтобы процессы пошли дальше
- Бизнес-аналитик разрабатывает специальную (корректирующую) версию бизнес-процесса, содержащую элементы, исправляющие логические ошибки в «зависших» процессах. Администратор загружает корректирующую версию бизнес-процесса в BPMS и обновляет на нее соответствующие экземпляры. При обновлении экземпляр заменяется на новый, в котором новая схема и переменные, точки управления автоматически переносятся со старой схемы на новую, значения старых переменных передаются в новые переменные. После этого обновленные экземпляры выполняются до завершения
- В сложных случаях часто помогает:
- Запустить для экземпляра бизнес-процесса бизнес-процесс его полной отмены
- Запустить отмененный бизнес-процесс заново, но уже для исправленной версии определения бизнес-процесса
Если ошибка в коде, то программист исправляет ее, собирает новый компонент и пишет заявку администратору BPMS на обновление компонента в системе. Иногда загрузки нового компонента достаточно, чтобы «зависшие» экземпляры пошли дальше. Если нет, то можно дополнительно применить описанные выше варианты действий.
При эксплуатации BPMS важно, чтобы программист и бизнес-аналитик работали с промышленной системой не напрямую, а через администратора, а также чтобы все корректирующие действия фиксировались и оформлялись соответствующими документами.
Иначе можно потерять контроль над системой — никто не будет понимать, почему система себя так ведет, надежны ли содержащиеся в ней данные и как можно исправить ошибки…
А какому виду относится комплекс ИС в составе PLM+PDP + ERP?
На мой взгляд, в реальном производстве, они работают именно как BPMS в изначальном своём понимании. Или я где то не прав?
На мой взгляд, в реальном производстве, они работают именно как BPMS в изначальном своём понимании. Или я где то не прав?
Кстати да. Есть сходство с BPMS.
Сходу могу предположить, что BPMS более социальные, а PLM/PDM более железные.
Сходу могу предположить, что BPMS более социальные, а PLM/PDM более железные.
Скорее не железные, а относящиеся к реальном сектору и к реальному производству, а не к финансам, ИТ и другому менеджменту.
Хотя никто не мешает использовать оба варианта в крупной компании одновременно ( хотя в такой компании, скорее всего уже есть SAP, на базе которого можно творить очень многое =) )
Хотя никто не мешает использовать оба варианта в крупной компании одновременно ( хотя в такой компании, скорее всего уже есть SAP, на базе которого можно творить очень многое =) )
<< Недавно на Хабре были опубликованы несколько статей ( раз, два ) на тему бизнес-процессов.
Напоминаю про пропущенную — третью: Бизнес-процессы: Как все запущено и запутано. Глава Третья. Общая классификация BPM и философия BPMS
Странно, что многим незаметна запутанность и запущенность в BPM*BPMS*[бизнес-процессах]*[«процессном управлении»].
Неужели не были очевидцами типового сценария при обсуждении BPM:
… часами обсуждают BPM-проблемы, затем когда всем становится очевидно, что беседа идет на разных языках и «о разных BPM» задаются вопросом: Что такое BPM? Далее приводят «книжные» термины – подходящие на все случаи жизни, которые еще более образуют «BPM — кашу» и «BPMSystem – системную кашу».
Причем одни доказывают, что докладчик внедрил именно BPM, а он считает, что что-то иное. И наоборот бывает: «я внедрил BPM», а ему: «какой же это BPM? Это не BPM ты внедрил, а …»
По терминам. Насколько я понял: Используемый Термин «процессное управление», он же «Процессный подход» — и есть «Управление бизнес-процессами» (просто процессами), т.е. BPM.
Часто в других книжках термины «процессный подход» и «процессное управление» понимают для иного – не как технологический аспект, а как структуру управления предприятием.
При этом «ломают копья», что лучше: Функциональная — матричная – процессная? В реальности редкая компания имеет явно выраженную функциональную структуру и в ней всегда есть элементы процессного управления. Полная (абсолютная) процессная модель управления предприятием – это утопия (это и показывалось в статьях по ссылкам).
Любое предприятие пронизано «процессами» и независимо от того, знают руководители и сотрудники такие слова как «процессное управление», «управление бизнес-процессами» они управляют этими процессами.
Сказать, что прочитав несколько книжек про BPM или послушав BPM-консалтера, они станут лучше управлять своими процессами – сомнительно. А может даже и вредно, т.к. часто «универсальный консалтер» (универсальный солдат) не знает (хотя утверждает всегда обратное) отраслевой специфики, а «учить чему-то все равно придется».
Процессный подход – он есть и при матричной структуре управления, он и при использовании инструментов BPM(s) и без них. Раз есть деятельность – активность, есть и процессы, реализующие эту активность. Если есть работающие процессы, то ими управляют (иначе — анархия).
Управление проектами
Также не понятно противопоставление процессного подхода (управления процессами) и управления проектами. Часто карты процессов рисуются стопками до потолка и потом автоматизируются («в полный рост») только для «разового» процесса, единственный экземпляр которого скорее всего никогда и не стартанет (например, отражение массированного удара баллистических ракет). Это значит уже не «процессное», а «разовое» и «вне процессного подхода»?
В теории управления проектами (PMBOK) показаны самые что ни на есть процессы. И в научной деятельности – тоже процессы. И процессы и управление ими – везде вокруг нас (или там уже не процессное управление?).
«К процессному управлению относится оперативное изменение схем и других элементов определений бизнес-процессов в ответ на изменение условий бизнеса предприятия» — change management вроде бы.
«косвенное административное влияние» — и т.п. все как то неконкретно и не точно, а технология управления процессами – должна быть точной инженерной дисциплиной.
В статье «Что такое исполнимые бизнес-процессы. Введение в предметную область» процессное управление вроде бы не противопоставляется матричному управлению, но чему тогда противопоставляется? Что значит «не процессное управление»?
Автоматизация – как таковая, возможна как при процессном так и «непроцессном управлении»? Автоматизация возможна как на основе текстовых описаний (пол века так делали), картинок в IDEF и EPC (BPA) или в BPMN (в исполняемой среде) –и только последние два из них «процессные» (см. «к двум разным сферам деятельности»)? А при отсутствии задач автоматизации (регламентация, реинжиниринг-оптимизация и т.п.) процессный подход исключен? Мне не понятно применяемые в статье термины такой «процессности».
Статья хорошая, но вот про «процессность» как-то нескладно.
Сравнительная табличка «Процессный и не процессный» помогла бы отделить «мух от котлет». Желательно с простыми тезисами и примерами (в мире BPM и так много запутанного).
Главный вопрос: прочитать бы где-нибудь — Как внедрили этот самый Процессный подход и как посчитали выигрыш от внедрения.
Напоминаю про пропущенную — третью: Бизнес-процессы: Как все запущено и запутано. Глава Третья. Общая классификация BPM и философия BPMS
Странно, что многим незаметна запутанность и запущенность в BPM*BPMS*[бизнес-процессах]*[«процессном управлении»].
Неужели не были очевидцами типового сценария при обсуждении BPM:
… часами обсуждают BPM-проблемы, затем когда всем становится очевидно, что беседа идет на разных языках и «о разных BPM» задаются вопросом: Что такое BPM? Далее приводят «книжные» термины – подходящие на все случаи жизни, которые еще более образуют «BPM — кашу» и «BPMSystem – системную кашу».
Причем одни доказывают, что докладчик внедрил именно BPM, а он считает, что что-то иное. И наоборот бывает: «я внедрил BPM», а ему: «какой же это BPM? Это не BPM ты внедрил, а …»
По терминам. Насколько я понял: Используемый Термин «процессное управление», он же «Процессный подход» — и есть «Управление бизнес-процессами» (просто процессами), т.е. BPM.
Часто в других книжках термины «процессный подход» и «процессное управление» понимают для иного – не как технологический аспект, а как структуру управления предприятием.
При этом «ломают копья», что лучше: Функциональная — матричная – процессная? В реальности редкая компания имеет явно выраженную функциональную структуру и в ней всегда есть элементы процессного управления. Полная (абсолютная) процессная модель управления предприятием – это утопия (это и показывалось в статьях по ссылкам).
Любое предприятие пронизано «процессами» и независимо от того, знают руководители и сотрудники такие слова как «процессное управление», «управление бизнес-процессами» они управляют этими процессами.
Сказать, что прочитав несколько книжек про BPM или послушав BPM-консалтера, они станут лучше управлять своими процессами – сомнительно. А может даже и вредно, т.к. часто «универсальный консалтер» (универсальный солдат) не знает (хотя утверждает всегда обратное) отраслевой специфики, а «учить чему-то все равно придется».
Процессный подход – он есть и при матричной структуре управления, он и при использовании инструментов BPM(s) и без них. Раз есть деятельность – активность, есть и процессы, реализующие эту активность. Если есть работающие процессы, то ими управляют (иначе — анархия).
Управление проектами
Также не понятно противопоставление процессного подхода (управления процессами) и управления проектами. Часто карты процессов рисуются стопками до потолка и потом автоматизируются («в полный рост») только для «разового» процесса, единственный экземпляр которого скорее всего никогда и не стартанет (например, отражение массированного удара баллистических ракет). Это значит уже не «процессное», а «разовое» и «вне процессного подхода»?
В теории управления проектами (PMBOK) показаны самые что ни на есть процессы. И в научной деятельности – тоже процессы. И процессы и управление ими – везде вокруг нас (или там уже не процессное управление?).
«К процессному управлению относится оперативное изменение схем и других элементов определений бизнес-процессов в ответ на изменение условий бизнеса предприятия» — change management вроде бы.
«косвенное административное влияние» — и т.п. все как то неконкретно и не точно, а технология управления процессами – должна быть точной инженерной дисциплиной.
В статье «Что такое исполнимые бизнес-процессы. Введение в предметную область» процессное управление вроде бы не противопоставляется матричному управлению, но чему тогда противопоставляется? Что значит «не процессное управление»?
Автоматизация – как таковая, возможна как при процессном так и «непроцессном управлении»? Автоматизация возможна как на основе текстовых описаний (пол века так делали), картинок в IDEF и EPC (BPA) или в BPMN (в исполняемой среде) –и только последние два из них «процессные» (см. «к двум разным сферам деятельности»)? А при отсутствии задач автоматизации (регламентация, реинжиниринг-оптимизация и т.п.) процессный подход исключен? Мне не понятно применяемые в статье термины такой «процессности».
Статья хорошая, но вот про «процессность» как-то нескладно.
Сравнительная табличка «Процессный и не процессный» помогла бы отделить «мух от котлет». Желательно с простыми тезисами и примерами (в мире BPM и так много запутанного).
Главный вопрос: прочитать бы где-нибудь — Как внедрили этот самый Процессный подход и как посчитали выигрыш от внедрения.
Главный вопрос: прочитать бы где-нибудь — Как внедрили этот самый Процессный подход и как посчитали выигрыш от внедрения.Доклады о реальных внедрениях процессного подхода проводятся, например, Ассоциацией BPM-профессионалов. Эти мероприятия свободные, участвовать могут все желающие:
о реальных внедрениях процессного подхода
судя по тому, что нет ответа на мой вопрос (см. предыдущий развернутый пост): Что же такое «процессный подход», говорить об эффективности внедрения этого «чего то» — сложно. Табличку сравнительную сделаете? «Процессный подход» versus «Вне процессное управление»?
Если интернет умалчивает о чем то (расчет эффективности внедрения) на протяжении десятилетий (BPM скорее стар, чем молод, а число его внедрений огромно), а эти тайные знания рассказывают только на семинаре некой Ассоциации, то возникает ассоциация с сектантством. Можете дать ссылку или рассказ про «выигрыш от внедрения»? Можно начать хотя бы с Методики подобной оценки.
В статьях про «BPM: как все запущено и запутано» говорилось что часто «лавры победы» образуются только потому, что что-то автоматизировали. И не важно как: с помощью С+++ или с помощью:
а) картинок BPNM (других нотаций BPMS) + много кода (скриптов) или
б) системы «Low code» \ «No code», где также в реальном внедрении все равно получится «плюс много кода».
Сложно занижать значение автоматизации, но благодарить за это BPM, BPMS и(или) процессный подход – не совсем правильно, т.е. «автоматизация-программирование на BPMN не равно BPM-процессное управление».
Когда речь идет о том, как взялся «айтишник внедрить в компании BPMS», то чаще всего это повествование как для автоматизации (обычно несложной задачи) было нарисовано много картинок в BPMN-BPMS и как это как-то заработало. Но если это и считать за «процессный подход» = BPM, то это и есть подмена понятий, о котором шла речь в «BPM: как все запущено и запутано» с первой по третью главе.
Итого:
А) инструмент BPMS (IBM BPM, Bizagi, Bonita и т.п.) — это не BPM и не инструменты BPM (ARIS и т.п.) и к «процессному подходу» (и не понятно какому) не имеют отношения;
Б) внедрение BPMS и программирование на нем какой либо задачи – это всего лишь проект автоматизации, а не BPM в более «старом» (строгом) понимании «процессного подхода». Кстати, новомодные «Low code» реализуют этот самый новый «процессный подход» (который следует из описания в Вашей статье)?
В) обычные (старые) ERP, CRM, ECM и др. в которых «теперь» есть «новый» (называть стали так – «как модно») «Embedded BPM».
Г) Простым языком про это сказано в комментарии: Throwable 16 декабря 2015 в 01:41 особенно в его концовке:
Вобщем, BPM — это исключительно инструмент бизнес-аналиста, и пусть таким и остается. А у нас, кодеров, свои приблуды …
Процессный офис и «процессный подход»
Что, по-вашему, делает «Процессный офис» в подобном представлении «процессного подхода»? Сидят все за компилятором «нового поколения» (BPMS) и автоматизируют бизнес-процессы на BPMN? Т.е. сотрудники этого офиса – некие «программисты нового поколения», которым уже не нужны java, С+++ и все «иже с ними»?
Как такая «процессная команда» реализуют Ваш «процессный подход»?
Мои вопросы к тому: как отделить «мух от котлет», включая технологии автоматизации от технологий управления процессами.
Табличку сравнительную сделаете? «Процессный подход» versus «Вне процессное управление»?Нет. В рамках этой статьи такое сравнение не предполагалось. Я решил описать только узкую область, связанную с бизнес-процессами, реально исполняемыми в компьютерной среде предприятия.
Если интернет умалчивает о чем то (расчет эффективности внедрения) на протяжении десятилетий (BPM скорее стар, чем молод, а число его внедрений огромно), а эти тайные знания рассказывают только на семинаре некой Ассоциации, то возникает ассоциация с сектантством. Можете дать ссылку или рассказ про «выигрыш от внедрения»?Число внедрений пока не очень большое, но они есть. Доклады о внедрениях публикуют в интернете очень неохотно, т.к. рассказ о своих бизнес-процессах может объяснить конкурентам компании, как в компании устроен бизнес.
Поэтому на мероприятиях ассоциации BPM-профессионалов принято для обсуждения кейсов внедрений, как правило, встречаться лично.
Но кое-что в интернете все-таки публикуют. Например, — Доклад от 18 июня 2015 г.
В статьях про «BPM: как все запущено и запутано» говорилось что часто «лавры победы» образуются только потому, что что-то автоматизировали. И не важно как: с помощью С+++ или с помощью...Особенностью BPMS является то, что схема бизнес-процесса не является независимой от кода картинкой. Программисты часто «доделывают» бизнес-процесс: кодируют сложные алгоритмы в условиях выбора перехода, пишут коннекторы к другим системам, разрабатывают графические интерфейсы для форм задний и т.п.
Но точки управления при этом движутся только по отображаемой пользователю схеме бизнес-процесса. Они не могут «существенно разойтись» с программным кодом. Это помогает управленцам лучше понимать что происходит на предприятии.
Процессный офис и «процессный подход»«Процессный офис» — это отдельная большая тема. В рамках данной статьи я ее не рассматриваю. «Процессный офис» подробно описан, например, здесь.
Что, по-вашему, делает «Процессный офис» в подобном представлении «процессного подхода»?
Как такая «процессная команда» реализуют Ваш «процессный подход»?В частности, там есть понятное разделение труда: управленцы «заказывают» программистам нужные им элементы. Далее из этих элементов собирается нужная управленцам конструкция.
Sign up to leave a comment.
Что такое исполнимые бизнес-процессы. Введение в предметную область