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

Ануар Ашимов, Иногда можно, иногда - нет.

Ануар Ашимов пишет: Чтобы каждый исполнитель был контролером для предыдущего,

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

Борис Зверев пишет: Маршрут может (а подчас - и должен) предусматривать итерационные петли - в чём тут проблема? Почему надо выбрасывать труд аналитика?

Труд аналитика выбрасывать не нужно. Просто необходимо понимать, что BPM-система решает определенный, ограниченный круг задач - логически выстраивает деятельность, которая зарегламентирована. Но это только часть деятельности в организациях. Есть еще творчество. Предельный случай - пользователь сам выстраивает последовательность выполняемых им действий. Имеет право на жизнь, но не всегда эффективно. Часто изобретается велосипед. Наиболее эффективный метод для автоматизации творческой деятельности где-то между BPMS и чистым творчеством: - иметь определенную начальную регламентированную последовательность действий; - иметь возможность в рамках этих действий запускать другие функции и процессы и изменять логику текущего процесса. Наиболее часто приводят примеры, где эффективно можно использовать ACM - работа врачей и юристов. Хотя в других областях деятельности таких задач тоже навалом. Например, управление наукоемкой деятельностью.

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

По поводу мрачных прогнозов ... Скорее есть потребность в дополнениях, но сама концепция BPM не требует изменение аббревиатуры, если происходит включение чего-то нового, т.к.. BPM - эклектика изначально ... И невозможность изменения аббревиатуры скорее является недостатком только с точки зрения маркетинга, т.к..каждые 3-5 лет можно было бы выводить на рынок новый продукт :)

Олег Захарчук пишет: BPM-система решает определенный, ограниченный круг задач - логически выстраивает деятельность, которая зарегламентирована ... Наиболее часто приводят примеры, где эффективно можно использовать ACM - работа врачей и юристов.

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

Олег Захарчук пишет: Есть еще творчество. Предельный случай - пользователь сам выстраивает последовательность выполняемых им действий. Имеет право на жизнь, но не всегда эффективно. Часто изобретается велосипед.

:) АРМ "Писатель". Предлагаются типовые модули - "Прозаик", "Фантаст", "Поэт-юморист". Возможна доработка нестандартных комплектаций под заказ :)

Борис Зверев пишет: АРМ "Писатель".

Вот Вы шутите, а между тем, Зарипов Рудольф Хафизович предложил алгоритм для сочинения сказок, если не ошибаюсь, еще лет 40 назад :)

Борис Зверев пишет: :) АРМ "Писатель". Предлагаются типовые модули - "Прозаик", "Фантаст", "Поэт-юморист". Возможна доработка нестандартных комплектаций под заказ :)

и Главный редактор, который не платит авторский гонорар ....

Александр Соловьев пишет:

Олег Захарчук пишет: BPM-система решает определенный, ограниченный круг задач - логически выстраивает деятельность, которая зарегламентирована ... Наиболее часто приводят примеры, где эффективно можно использовать ACM - работа врачей и юристов.

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

Полностью согласен свами и ещё рядом предыдущих авторов. Лично мне кажется, что это очередная "маркетинговая фишка". Т.е. это не плохо с точки зрения привлечения интереса, но надо быть аккуратней. Не хотел бы себя отнести к "ортодоксам BPM" (хотя почему бы и нет, в лучше смысле этого слова?), но лично мне кажется, что это просто попытка "поднять интерес" к BPM-теме новомодным словом. Ничего нового в ACM нет, поскольку это просто, "ответвление" процедур. Как делился мир на виды: - "циклические" (процессы и процедуры) - одноразовые (проекты и задачи) так и продолжает... И, как правильно тут говорили, ни без того, ни без другого не обойтись в управлении. Хоть ИТ, хоть просто деятельностью.

Олег Гончаров пишет: Не хотел бы себя отнести к "ортодоксам BPM" (хотя почему бы и нет, в лучше смысле этого слова?), но лично мне кажется, что это просто попытка "поднять интерес" к BPM-теме новомодным словом. Ничего нового в ACM нет, поскольку это просто, "ответвление" процедур. Как делился мир на виды: - "циклические" (процессы и процедуры) - одноразовые (проекты и задачи) так и продолжает...

Согласен с Вами!!! И ВРМ, и АСМ, и ERP, и ... это просто разные модели описания и управления деятельностью - плод разделения целого на части. В связи с этим, предлагаю продолжить обсуждение на http://www.e-xecutive.ru/forum/forum50/

Олег Захарчук пишет: В связи с этим, предлагаю продолжить обсуждение на http://www.e-xecutive.ru/forum/forum50/

http://www.e-xecutive.ru/forum/forum50/topic11377/messages/

А-фи-геть!
Прочитал и ахнул! ) Хотя ахнул тут слабо сказано )
Всем участниками дискуссии огромное спасибо за формализованные мысли!

Поможете начинающему ACM-исследователю в кое чем разобраться относительно предмета темы?

Поправьте мои тезисы если я ошибаюсь (тезисы взял из блога М.Смирнова из Билайна и данной темы, т.к. это 2 источник понятной информации):
1. ACM - это предмет который еще находится на стадии становления в стройную теорию и пока в нем больше вопросов чем ответов
2. ACM - предполагает ориентир на гибкость исполнителя по процессу, отдавая ему больше прав на выбор, но фиксирующий ключевые нормы, требуемые для достижения ожидаемого результат
3. Если говорить о словестном описании процесса то это может быть инструкция в которой описывается порядок действий в качестве реакции участников на какое либо событие. Например: поступило входящее письмо или выявлена проблема вызывающая сбои
4. Если говорить о графическом описании, то тут можно применять любые нотации, будь то BPMN или EPC. А можно вообще не применять графику. Досаточно текста из п.3
5. Если говорить об аппартном обеспечении (компьютеры и ПО) то лучше всего подходит такой зверь как SemanticWeb.
5.1. Где SemanticWeb - в моем понимании это Web-программа с гибкими возможностями по регистрации записей БД и гибкими возможностями классификации по категориям или тегам. Ну и как положено современным Web-программам она выполняется в облаке. А может и не в облаке.
5.2. Как пример SemanticWeb можно взять WordPress с его универсальными тахономиями, позволяющими создавать любые виды записей и любые виды классификации записей

Ну и спускаясь с высот абстрактных мудрствований, рассмотрим конкретный пример:
1. Но вот я хочу наладить управление технической поддержкой (где то выше как я понял это было названо управление бизнес-процессами), а еще хочу наладить управление проектами, а еще хочу наладить управление кейсами. Тут нужно разобрать пример каждого понятия:
1.1. Техническая поддержка: возникают мелкие инциденты и их нужно устранять. Операции трудоемкостью 1-2 часа ну или бывают и 8 часов.
1.2. Управление проектами: нужно перевести организацию на новую систему CRM. Операции трудоемкостью от 1 недели.
1.3. Кейс? Что это за зверь?
1.3.1. Как я понял предмет ACM, п.2.1. и п.2.2. при желании можно назвать кейсом.
1.3.2. Но давайте для пример скажем что Кейсом будем называть те операции которые нам религия не позволит отнести к тех.поддержке или к проекту, и будем считать Кейсом операции по середине, трудоемкостью более 2-х часов, но менее недели.
1.3.3. Тогда кейсом можно назвать операции в части рассчета зарплаты или поступление больного в приемное отделение поликлиники
--- я взял примеры из разных отраслей, т.к. ACM это универсальная технология.

2. Как будет выглядеть система управления построенная по принципам ACM?
2.1. Ставим WordPress. У него уже есть стандартные типы записей и таханомий, позволяющие делать обычный блог. Этот типовой функционал можно использовать как хорошую базу знаний. Сохранять сюда разные статьи, инструкции, классифицировать их по любым категориям. Потом быстро находить материалы щелкая по какой либо категории или тегу. Или просто забивая слова поиска.
2.2. Прежде чем перейти к настройке БД WP по принципу SemanticWeb, остановимся на описании процессов.
2.2.1. Инструкции пишем словами. На каждое значимое событие прописываем инструкцию в которой указываем порядок действий сотрудников.
2.2.1.1. Скажем поступил инцидент - делаем так и так.
2.2.1.2. Появилась необходимость в реализации проекта, пусть это будет внедрения CRM, или любая другая крупная задача, соответственно человек должен быстро найти инструкцию по этому событию и увидеть требуемый порядок действий. Тут нужно заметить что действия не в плане внедрения CRM, а в плане организации проекта. А что там в этом проекте будет, CRM, ECM или строительство моста через речку, не суть важно. Проекты на то и проекты чтобы реализовывать уникальные задачи без наличия отлаженных технологий.
2.2.1.3. Поступил больной - делаем то и то.
2.2.2. Тут нужно еще остановиться на том моменте, что по ходу выполнения этих инструкций само собой будут возникать связанные события типа "Отправить письмо", "Заказать машину" ... Эти события будут стартовать другие инструкции, которые потребуют реакции других подразделений и сотрудников.
2.2.2.1. Скажем при подготовке к внедрению CRM нужно будет стартануть пару процессов по отправке исходящих писем, или заключения договоров. На все эти процессы у соответствующего подразделения должны быть свои инструкции.
2.2.2.2. По сути получаем цепочку событий и реакций по инструкциям.
2.2.3. При желании, но только если есть понимание дела, можно к этим словестным инструкциям прописать графические схемы в любимых нотациях, будь то EPC или BPMN или что то еще.
2.2.4. Самое главное чтобы сотрудник при возникновении события знал какую инструкцию ему выполнять, какой от него требуется порядок действий, кто и в какой ситуации ему может помочь, какие могут возникнуть исключения, в каких случаях и как нужно делать записи в информационной системе. Это все ну или большую часть исключений можно и нужно прописать в инструкции по событию.
2.3. И вот теперь переходим к допиливанию WP под возможность учета всех этих операций:
2.3.1. Добавляем тип записи "Тикет", к нему делаем таханомии для классификации всех возможных Тикетов. Если не нравится слово Тикет, можно его заменить словом Задача, Обращение, Операция. По вкусу в общем. Главное что эта запись отражает какую то мелкую операцию по текущей деятельности. Которую нам нужно измерять в целях управления.
2.3.2. Добавляем тип записи "Проект", к нему делаем свои таханомии.
2.3.3. Добавляем тип записи "Кейс", ну или тут я не уверен. При желании под кейсы можно использовать как п.2.3.1. так и 2.3.2. На скорость полета не влияет. Управляемость и качество будет одинаковое.
2.4. И теперь моделируем конечную ситуацию:
2.4.1. Поступил инцидент, в инструкции сказано что в этом случае нужно создать запись Тикет, назначить ответсвенного, в зависимости от ситуации указть категории, например: Приоритет, Тип услуги, Объет услуги и т д
2.4.2. Захотели реализовать проект. Добавили запись Проект, указали все категори.
2.4.3. Поступил больной, создаем либо Тикет, либо какой то другой тип записи, если нам так хочется.
2.5. Что дальше?
2.5.1. У нас есть список всех Тикетов, мы видим кто за них отвечает, какие у них приоритеты, какой статус, видим всю историю по ходу выполнения. Это позволяет управлять процессом, контролировать, подключаться к решению если возникают затруднения. Давать ссылки на базу знаний.
2.5.2. По проектам тоже все хорошо. Видим список проектов, кто и за какие проекты отвечает, в каком состоянии находятся проекты.
2.5.3. Ну и любые другие виды кейсов можно построить и организовать на этой базе.
2.6. Тут следует остановиться на особенностях:
2.6.1. Само собой информационная система не ограничивается только возможностями WP
2.6.2. При решении Тикетов, специалист может подключаться к другим ИС, будь то КонсультантПлюс, ICQ, Facebook, Ответы@mail.ru, 1С CRM ...
2.6.3. По проектам еще веселее. Кроме того что для реализации проекта можно использовать любые ИТ, так тут еще и не знаешь на какие хитрости тебе придется пойти в отношении с людьми. Бывает нужно и секретаршу соблазнить, переспать с ней, только бы заполучить встречу с нужным человеком, добиться какого то решения в целях достижения результата по проекту. В проектах нет конкретных технологий, часто приходится искать решения в полете и надется лишь на собственную смекалку. Главное чтобы результат был достигнут. Как частный случай, скажем регистрацию мы сделали в WP, но WP не позволяет структурировать все задачи, и мы можем регистрацию задач вести в MS Project или в Мегаплане или где либо еще.

Вот такой кошмар у меня в голове :)
1. Описал конкретные примеры. Само собой тот же WP можно заменить практически любой зрелой ECM. Главное чтобы были развитые возможности по классификации задач.
2. В инструкциях мы указываем как нам классифицировать ту или иную операцию (кейс), ну и в зависимости от того как мы ее классифицировали, по инструкции могут возникать те или иные правила выполнения. Скажем если при классификации мы указали что приоритет у Тикета - высокий, то по инструкции будет сказано что такие приоритеты нужно решить в срок 4 часа.
3. Ну а отчетность у таких систем просто ягодка! Шлеп в конце месяца, и у тебя полная картинка. Кто и сколько тикетов сделал, нарушены или нет сроки, кто и сколько проектов ведет, сколько итераций было, какие проблемы возникли.
4. Ну и само собой, типовые семантические возможности WordPress позволяют делать супер гибкие базы знаний, превосходящие по удобству даже WiKi-движки.

Прошу прощения за кашу. Но мне ее как то надо расхлебать. И буду благодарен за помощь, поправки, критику, подсказки :)

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

Система ELMA к вашим услугам.. что касается ACM то нужно еще 100 раз отмерить)

Когда я изучал литературу про Adaptive Case Management, было впечатление дежавю. Ведь это же функциональный подход revisited! Функциональный подход как раз и направлен на лучшее (гибкое) использование ресурсов, в частности информационных. Ради этого он пренебрегает важностью горизонтального согласования действий в организации.

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

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

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

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

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

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

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

В чем сущностная разница между старыми модулями и новыми объектами? А между старыми библиотеками процедур и новыми сервисами? Между старыми прерываниями и новыми асинхронными вызовами?

Меняется исполнение - методы остаются. Каждая реализация развивается по спирали, комбинируя на верхнем уровне то последовательный, то параллельный подход. Что-то сверху должно быть :)

Какую хрен вы тут пишите... Все модели - это операционный бизнес, внутрихоззяйствнная деятельность. И еще в 1998 в своей работе Эндик Уайп четко разделил технологичесие процессы внутри компании и вне ее, показатели ее оценки внутри в виде KPI и вне как BSS. Совремнные модели компаний в рыночной среде с соответствющей математической формулировкой можно отнести к различным моделям. Ноне к тем что ы указали Это деньги выброшенные на ветер ГОСПОДА!