Как идут дела у адаптивного управления делами

В начале сентября, в рамках конференции BPM1012, проходившей в эстонском Таллине, состоялся первый международный workshop по Adaptive Case Management. В ходе самой конференции также было еще несколько мероприятий посвященной теме кейс-менеджмента (Adaptive? Dynamic?, впрочем не важно). К сожалению, на конференции я не был, но к счастью в сети достаточно информационных материалов с ней связанных. И пожалуй наиболее удачным преддверием очередного обсуждения ACM явилась заметка в блоге Адама Дина о вечеринке относительно дня нерождения ACM

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

Безумный Шляпник: (об Adaptive Case Management) Это фантастическая методология.
Мартовский Заяц: (кивает) Это фантастическая методология … но её никто не использует.
Алиса: Что за вздор! Как так можете быть, чтоб никто не использовал методологию, которая всем нравится. Если бы она была, действительно так хороша то, безусловно, поставщики BPM, CRM и ECM решений уже бы её использовали.
Мартовский Заяц: Как раз наоборот. ACM это фантастическая методология и потому её никто не использует.

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

И разумеется, на конференции не могли не затронуть тему использования графических нотаций для отображения процессов. В июле месяце Кит Свенсон написал довольно большую статью BPMN is Incompatible with ACM. Мысль Кита достаточно проста. Он не ругает BPMN за сложность, а обращает внимание на одну банальную вещь. Рисование картинок осуществляется на этапе проектирования процесса или ИТ решения и делается это специально обученными людьми. Затем картинки отдаются разработчикам, которые реализуют их в коде и(или) настройках информационной системе. Люди, работающие в процессе, не модифицируют эти рисунки(Скорее всего они их даже никогда не увидят). Адаптивный кейс-менеджмент предполагает другой жизненный цикл. Разработка бизнес-процесса и его исполнения совмещены во времени. Кейс-уокер создает процесс «на лету» и нуждается для этого в более простых и эффективных инструментах, чем красочный редактор BPMN.

Словно в продолжение этой темы на конференции была представлена концепция Process Cloud Concept for Case Management. Концепция “Open Process Clouds” не имеет ничего общего с облачными вычислениями. Она просто предлагает расширить нотацию BPMN символом облачка, обозначающим некоторую активность участников бизнес-процесса. Кто и что делает в облаке бизнес-аналитику не известно, зато он может связать с ним набор входящих и исходящих сигналов.

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

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

Как идут дела у адаптивного управления делами: 6 комментариев

  1. Максим, добрый день.
    Спасибо за перевод кусочка текста – как мне кажется, самое важное из него Вы ухватили, оригинал можно и не читать уже 🙂 Мне лично очень понравилось словосочетание “фантастическая методология”. Сразу напрашиваются параллели с “научно-фантастической литературой”. Казалось бы, все понятно объясняют – звездолет на фотонной тяге, тау-реактор производит мю-мезоны, из коих и возникает устремление ввысь. Но собрать действующую модель по мотивам описания не получается – все время не хватает чего-то…
    Это я не от нелюбви к (*)CM говорю. Наоборот, считаю подход очень перспективным и пытаюсь забазироваться на нем в некоторых будущих наработках (stay tuned, как говорится 🙂 кстати, было бы интересно поделиться с Вами и услышать реакцию интересующегося практика). Но вот методологией в этой области, ИМХО, пока не пахнет – никто из ораторов не может взять за руку и довести “от двери до двери”. Чего-то не хватает всегда. Вот и на картинке, которую вы опубликовали – как-то волюнтаристски все. Нет, например, граничных условий для перехода из одного состояния в другое. Хотя задел интересный. Глядишь, и будут фотонные корабли бороздить просторы Мирового океана….

    1. Олег, спасибо за комментарий. У BPM за плечами добрый десяток лет развития workflow систем. WfMC существует с середины девяностых и еще в те времена сформировала модель предметной области. Тогда же появились первые системы. Мне кажется ACM пройти этап разработки ИТ-систем “в гараже”, потом появятся продуктологи и завернут его в красивую обертку, а затем флаг подхватят мегавендоры, умеющие продавать решения.

      Пока всего это не произошло АCM будет существовать в виде некоторого архитектурного подхода, паттерна приложений. Собственно уже сейчас заказные разработки, ориентированные на адаптивное взаимодействие людей, надо делать именно так. Потому мне как архитектору и интересна эта тема. А вот года через 2-3 её придется отдавать продавцам 🙂

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

    Вот полностью согласен с этим подходом. Год работы показал, что оно правда работает. Единственное, у нас сейчас все порождаемые задачи и дочерние бизнес-процессы “неблокирующие”. То есть можно завершить головную задачу, не дожидаясь их. Но это вопрос того, что “блокировки” задизайнили, но предметного повода реализовать еще не было.

    1. Интересная тема. Есть еще такая фишка, как автоматическое закрытие по завершению дочерних задач (одной или нескольких). Другая связная тема – решение инцидента посредством workaround-а. В практике такое часто бывает. Есть проблема, требующая срочного решения. Её как-то решают. Понятно что потом, когда спешка спадет, должен кто-нибудь прийти и сделать не “как-то”, а правильно. Но инцидент хочется поскорей закрыть, т.к. сроки его решения непосредственно влияют на KPI

      1. Про автоматическое закрытие не думал как-то. Но это может следствие моего восприятия, что у задачи должен быть owner, иначе концов потом не найдешь. И этот owner-координатор в конечном итоге принимает решение “ок, имеет вот такую картину, считаем закрытым, последствия на моей совести”.

        А вот workaround’ы более чем понятны. 🙂 Они нормально решаются теми самыми “неблокирующими” связанными процессами. Если координатор видит, что горячая проблема снята, можно запустить дочерний процесс “а теперь реализовать по уму”, после чего закрыть задачу. Дочерний процесс “сделать хорошо” остается жить своей жизнью, хотя родительский уже завершен.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *