На смену BPM идет Adaptive Case Management (ACM)

Олег, из того что есть на сегодняшний день, идеологически ближе всех к ACM лежат системы СЭД. Разница только в том, что центральным понятем СЭД является не абстрактный "информационный ресурс", а вполне конкретный "электронный документ".

Соответственно, если Вам преимущественно надо работать с изображениями, видео-, или аудиоданными, то отечественные СЭД, к сожалению, пока слабо подойдут. Но мы работаем над этим :)

А можно пояснить что такое ACM на реальном примере, поскольку практической информации в интернетах что-то маловато. Меня интересует прежде всего для каких конкретно случаев (ситуаций, сценариев) пригоден ACM?

Марат Максумов пишет: А можно пояснить что такое ACM на реальном примере, поскольку практической информации в интернетах что-то маловато. Меня интересует прежде всего для каких конкретно случаев (ситуаций, сценариев) пригоден ACM?

Марат! На самом деле, по жизни бывает много ситуаций, когда приходится принимать решение по ходу выполнения деятельности. Вот самый простой пример. Вы смотрите результат работы подчиненного, который вам направлен из предыдущего действия процесса. Результат Вас не устраивает, и Вы хотите его отослать обратно. Но если в схеме процесса классической BPMS этот возврат не предусмотрен, то Вы не сможете это сделать.

Олег Захарчук пишет: Вот самый простой пример. Вы смотрите результат работы подчиненного, который вам направлен из предыдущего действия процесса. Результат Вас не устраивает, и Вы хотите его отослать обратно. Но если в схеме процесса классической BPMS этот возврат не предусмотрен, то Вы не сможете это сделать.

Из этого описания разве не вытекает, что ACM - это гибко (правильно) настроенная BPMS? Соответственно - никакого софта дополнительно писать не требуется, а ACM - это надстройка над фреймворком BPM (набор правил проектирования бизнес-процессов в нужной нотации)?

Марат Максумов пишет: Из этого описания разве не вытекает, что ACM - это гибко (правильно) настроенная BPMS? Соответственно - никакого софта дополнительно писать не требуется, а ACM - это надстройка над фреймворком BPM (набор правил проектирования бизнес-процессов в нужной нотации)?

Не вытекает. Если при проектировании процесса учитывать все возможные отклонения от основного русла, то схема утонет в частностях, за которыми не будет видна суть. Поэтому на практике предпочитают не отображать в схемах все исключения, а только те, которые строго регламентированы :) ACM предлагает "танцевать" от информационного ресурса: что с ним делать и в какой последовательности, решает сам пользователь. При этом могут использоваться (или не использоваться) жестко регламентированные процедуры, но в какой момент их стартовать (и стартовать ли) определяет, опять же, пользователь. А для BPM первичен процесс: пользователь принимает решения только там, где это определено процессом.

Евгений Кочуров пишет: Не вытекает. Если при проектировании процесса учитывать все возможные отклонения от основного русла, то схема утонет в частностях, за которыми не будет видна суть. Поэтому на практике предпочитают не отображать в схемах все исключения, а только те, которые строго регламентированы smile:)

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

Евгений Кочуров пишет: ACM предлагает "танцевать" от информационного ресурса: что с ним делать и в какой последовательности, решает сам пользователь. При этом могут использоваться (или не использоваться) жестко регламентированные процедуры, но в какой момент их стартовать (и стартовать ли) определяет, опять же, пользователь.

Я нашел описание ACM в картинках где показывается данное отличие BPM от ACM, но не понял как это выглядит (и что означает) на практике. Собственно я и просил привести пример из жизни, который бы послужил описанием такого сценария.

Евгений Кочуров пишет: А для BPM первичен процесс: пользователь принимает решения только там, где это определено процессом.

Разве это не логично?

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

BPM не повредит нигде, где есть хоть сколь-нибудь значительный масштаб операций.

Там, где требуется большая свобода действий ввиду того, что отсутствуют повторяющиеся операции (или их мало, или что более верно - повторяющие операции являются обеспечивающими, находятся на низком уровне управления как то: документооборот, бюджетирование, организация конкурсов и пр.), т.е. речь о некой степени свободы менеджера ввиду уникальности ПРОЕКТА вступают в силу системы управления проектами. И все вопросы, которые обозначены в этой теме ими же снимаются - жесткие процессы заменяются матрицами ответственности, контроллингом, бюджетированием. Информационные системы, автоматизирующие процессы управления проектами давно разработаны. Методологий управления проектами тоже навалом. Так может быть - идет подмена понятий и ACM заранее мертворожденная концепция?

Марат Максумов пишет: В обсуждаемом сценарии никакого множества отклонений нет - необходимо дополнение одним ветвлением (проверка результата работы подчиненного) и соответствующая "петля" в случае неудовлетворенности результатом. Стандартная схема BPM и не такие схемы может разрулить.

Теперь представьте процесс, в котором: - скажем, пять основных последовательных шагов, - за каждым из них идет контрольный шаг, - контролер (в данном случае - руководитель) может отправить на доработку любому из пяти исполнителей, причем после доработки должен произойти возврат в эту же точку Если это прорисовать на схеме, в любой нотации получится мрак.

Марат Максумов пишет: У меня ощущение, что мы говорим о ситуациях, которые разруливаются системами управления проектов.

Это верно, сходство есть.

Марат Максумов пишет: Так может быть - идет подмена понятий и ACM заранее мертворожденная концепция?

Трудно сказать, время покажет. Есть в этой теме пара тонкостей, которые сейчас не решаются ни системами управления проектами, ни СЭДами, ни прочими. Если сторонники ACM разрешат их, технология, может быть, и выстрелит.

Собственно, не решенные на сегодня "тонкости":
1. Управление обратимостью действий. В частности, необратимые действия, по возможности, надо откладывать.
2. Управление приоритетами действий. Это когда при смене внешних обстоятельств автоматически меняются приоритеты у внутренних задач.
3. Управление частично определенными процессами. Это, собственно, и есть ключевая "фишка" ACM - заставить каким-то образом работать не полностью определенные процессы.

Насколько мне известно, на перечисленное нет ни хороших теорий, ни реализаций. Если кому-то что-то попадалось - буду очень признателен за ссылки.

Евгений Кочуров пишет: Теперь представьте процесс, в котором: - скажем, пять основных последовательных шагов, - за каждым из них идет контрольный шаг, - контролер (в данном случае - руководитель) может отправить на доработку любому из пяти исполнителей, причем после доработки должен произойти возврат в эту же точку Если это прорисовать на схеме, в любой нотации получится мрак.

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

Евгений Кочуров пишет: 1. Управление обратимостью действий. В частности, необратимые действия, по возможности, надо откладывать.

Пример можно? Я что-то не улавливаю о чем Вы говорите.

Евгений Кочуров пишет: 2. Управление приоритетами действий. Это когда при смене внешних обстоятельств автоматически меняются приоритеты у внутренних задач.

Очень похоже на управление рисками в управлении проектами.

Евгений Кочуров пишет: 3. Управление частично определенными процессами. Это, собственно, и есть ключевая "фишка" ACM - заставить каким-то образом работать не полностью определенные процессы.

Это как раз таки фишка управления проектами. Вы говорите о Work Breakdown Structure - механизме борьбы со сложностью и неопределенностью проекта.

Марат Максумов пишет: Евгений, во-первых, если есть мрак в описании бизнес-процесса, то наверное есть мрак в управляемости этим процессом. Это как бы может служить неким звоночком.

Реально работающие в системах автоматизации схемы сложных процессов никто, кроме разработчиков и бизнес-аналитиков, прочитать не может. А в регламентах используют упрощенные схемы (если вообще используют). Задумайтесь - почему так происходит?

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

Вот именно, для того, чтобы описать элементарную вещь нужно аж 5 подпроцессов. А это мы еще не подключали экспертов, которым контролеры по ходу дела вопросы задают, и не перескакивали через необязательные этапы :) Кстати, об этом я как-то уже писал раньше: «Ахиллесова пята» процесса

Марат Максумов пишет: У меня ощущение, что мы говорим о ситуациях, которые разруливаются системами управления проектов.

Я тоже так думаю. Тем более, что этот вопрос уже поднимался в дисуссии: http://www.e-xecutive.ru/forum/forum43/topic5750/messages/

Марат Максумов пишет: Пример можно? Я что-то не улавливаю о чем Вы говорите.

Например: увольнения, публикации в СМИ, проведение оплаты входящих счетов - такие шаги должны по возможности откладываться, т.к. переиграть в случае чего сложно либо невозможно. Это несколько противоречит обычному подходу к оптимизации проектных работ, когда работы выполняются, как только выполнены все необходимые для старта условия.

Евгений Кочуров пишет: Очень похоже на управление рисками в управлении проектами.

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

Марат Максумов пишет: Это как раз таки фишка управления проектами. Вы говорите о Work Breakdown Structure - механизме борьбы со сложностью и неопределенностью проекта.

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

Евгений Кочуров пишет: Реально работающие в системах автоматизации схемы сложных процессов никто, кроме разработчиков и бизнес-аналитиков, прочитать не может. А в регламентах используют упрощенные схемы (если вообще используют). Задумайтесь - почему так происходит?

Низкая квалификация персонала? Противодействие со стороны персонала навязыванию механической системы контроля? Невовлеченность руководства? Убогость реализованной системы нотации? Неудобство инструментария? Отсутствие мотивации? Гадать можно сколько угодно, но перечисленное будет присутствовать в большинстве случаев.

Евгений Кочуров пишет: Вот именно, для того, чтобы описать элементарную вещь нужно аж 5 подпроцессов. А это мы еще не подключали экспертов, которым контролеры по ходу дела вопросы задают, и не перескакивали через необязательные этапы

Мне интуитивно кажется что: 1) "задавание вопросов экспертам" никак не накладывается на БП, разве что как описание отдельного БП; 2) необязательные этапы лягут в те пять диаграмм или же рассматриваемый БП необходимо пересматривать на другом уровне - на уровне целесообразности. Я честно говоря, не понимаю, чем поможет ACM в предлагаемых к рассмотрению ситуациях. Давайте вот это обсудим, а? Я честно - не понимаю, что такое ACM. Можно ведь банальный Sharepoint поднять, и что - это ACM?