Адаптивный кейс-менеджмент и основные данные

Перед отпуском я написал серию сообщений о SOA, ESB, EDA и Master Data Management. Потом я написал о том, как собрать это все вместе. А по возвращении из отпуска позволил себе добавить в эту конструкцию еще и BPM. Но честно говоря, я еще не сказал главного, о чем мне и напомнил доклад Анатолия Левенчука “Между проектами и процессами: адаптивное управление кейсами”. Настоятельно рекомендую его послушать.

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

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

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

А это уже является задачей архитектуры

Дополнение 31.10.2011: Почему идея совместного рассмотрения ACM и MDM продуктивна? Про ACM понятно, зачем он нужен, но не очень понятно как его строить. По сути, кроме совета использования чек-листов и протоколирования операций, что именно следует реализовывать в системе кейс-менеджмента, практически никто говорит. С MDM ситуация противоположная. Ясно, что именно надо делать, но не ясно зачем. Вроде все данные уже пристроены в учетных системах, так что может и начинать не стоит. Потому берем MDM-ые механизмы и творчески их прикручиваем к ACM, ну например:

1. Для поддержания актуального состояния объекта, MDM синтегрирован со всеми корпоративными информационными системами. Кейс болтается сам по себе. Вроде бы он должен перехватывать события во внешней среде, а case worker на эти события реагировать, но какие события, где их брать и как перехватывать не очень понятно. Пользуемся MDM-ом (интеграцией данных, управляемой событиями архитектурой… не важно, как это называть), просто берем за правило, что все, что происходит с объектом в информационных системах компании должно найти отражение в его кейсе. Например, сотрудник давно уволился, а мы ему заявление на отпуск согласуем – непорядок. Одним словом, вспоминаем про публикацию-подписку, назначаем кейсу адрес электронной почты и т.д.

2. Объекты находятся в отношениях. Как моделировать такие отношения мы хорошо знаем. Как делать запросы – более-менее тоже: кто работает в проекте А? В каких проектах работает сотрудник B? А что за продукт они там проектируют? А не этот ли продукт улучшается у нас проекте С? А участвует ли в проекте С сотрудник B или там у нас кто-то другой? А какие системы дорабатываются в проектах А и С и почему это разные системы если продукт у нас один. Я уж не говорю про всякие иерархии

3. Кейсы должны не только перехватывать события но и посылать их дальше, связанным кейсам (ну и людям, чтоб тем было что почитать на досуге с мобильных устройств). Если отношения между кейсами выстроены, то понято кому и что надо отправить. Возможно, отношения надо вообще вытаскивать в отдельную базу и рассматривать события, как появление-изменение-удаление того или иного отношения. Это, кстати, уже получится tibbr

В общем, дальше все это можно продумывать и передумывать еще довольно долго, вопрос в соотношении между целесообразностью и фантазией

Адаптивный кейс-менеджмент и основные данные: 4 комментария

  1. клиент = кейс?! Очень странная трактовка.

    Кейс – это процесс без предопределенной схемы. Но у него, как и у процесса, есть триггер, у него есть результат, KPI, задачи, бизнес-правила и прочая и прочая.

    А также и у процесса, и у кейса есть контекст – структурированные данные и/или неструктурированные документы. Структурированные жестко а-ля реляционная или не жестко (адаптивно) а-ля семантическая база данных.

    Контекст можно представить в виде бизнес-объекта. Это ресурс, который процесс/кейс перерабатывает: заявка, обращение, заказ… Причем как правило входной ресурс один.

    Но это не объект MDM, а объект, ссылающийся на объект MDM:

    кейс ресурс < мастер-объект

    Как-то так.

    1. Анатолий, спасибо за комментарий!

      По законам драматургии, я должен театрально вскинуть руки и воскликнуть:
      – Помилуйте, какой же это процесс?! Процесс это когда что-то происходит, бурлит, шипит, горит, окисляется… в общем, когда ртуть превращается в золото. Кейс – ни разу не процесс. Кейс – это объект. Его можно открыть, закрыть, дополнить данными. Кейс можно передать от одного человека другому, вложить в другой кейс и т.д. Одним словом, кейс – это совсем не процесс, скорее это ресурс.

      Потом мы будем долго спорить о том, является ли кейс частицей или волной ресурсом или процессом и так ни о чем и не договоримся. Вон Кит Свенсон уже рассказывает об открытии Квантовой Организации Taming The Unpredictable: Real-World Adaptive Case Management. На самом деле, двойственная природа адаптивного кейс-менеджмента была понятна с самого начала. Еще в первой работе Forrester Research была картинка о том, что кейс-менеджмент находится на пересечении ECM, BPM, аналитики и социального ПО
      Наверное, в этой дуальности адаптивного кейс-менеджмента и заключается самое интересное

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

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