Хочу вернуться к мартовскому обсуждению Архитектура Adaptive Case Management (самое интересное – как всегда в комментариях) но подойти немного с другой стороны. В предыдущем сообщении я сослался на замечательную зарисовку Адама Дина The ACM Unbirthday Party. Несколько комментариев к ней. Во-первых, ACM/DCM системы существуют это и OpenText и Pega и Eccentex и даже open source решение Nuxeo. Есть и другие решения, в том числе и у участников обсуждений в этом блоге. Во-вторых, мне очень не хотелось бы увидеть в развитии кейс-менджмента традиционный Gartner-овский сценарий. Когда появляется некоторое новое трехбуквенное сокращение. Затем наступает пик завышенных ожиданий. Одновременно мегавендоры начинают скупать решения данного класса и выводить их в отлаженную систему продаж. После продают эту технологию всем подряд, не задумываясь о её применимости, что неминуемо приводит к всеобщему разочарованию. И затем, единицы компаний, вдумчиво подошедшие к внедрению технологий, выводят её у себя на плато продуктивности.
Но если ACM/DCM это не класс систем, то, что же это такое? Я думаю, что кейс-менеджмент можно рассматривать как архитектуру. В первую очередь как бизнес-архитектуру. Т.е. вы не делите своих людей на тех, кто только придумывает бизнес-процессы и тех, кто их исполняет. Я уже не раз говорил о том, что архитектор бизнес-процессов должен участвовать в спроектированном им же процессе и, например, обрабатывать все исключения в нем возникающие. В реальной жизни нередко именно так и происходит. Когда у пользователя что-то не получается он идет к разработчику системы и заставляет делать его необходимую работу вручную. И это нормально. Только не всегда такая поддержка имеется. Во-вторых, кейс-менеджмент можно рассматривать как архитектуру информационных систем. BPMS принес нам очень хорошую идею: разделить приложения в которых хранятся данные и приложения, реализующую совместную работу людей с этими данными. Но вразумительной реализации этой идеи не случилось. Одна из причин этого заключается в том, что интеграцией BPMS с другими системами занимались люди, которые больше разбираются в BPM, чем в интеграции приложений.
Приведу один пример. Мне по долгу службы приходится довольно часто отвечать на вопрос: почему у нас в компании так много информационных систем. У меня есть простой ответ на этот вопрос. Я рассказываю о том, что новые системы появляются по просьбе пользователей. Случается это потому, что существующие приложения не могут удовлетворить их требования либо в силу технических ограничений либо потому, что команда развития не способна переварить поток запросов на изменения. И это все действительно так. Но у меня есть более честный ответ на этот вопрос. Дело в том, что в нашей компании под ИТ-системой понимают запись в базе данных конфигураций CMDB. И вокруг этой записи выстроены все ИТ-процессы в компании. Инцидент назначается на систему. Релиз – устраняет дефекты в системе и добавляет в неё новый запрошенный функционал. Люди, ответственные за развитие и эксплуатацию назначаются на конкретную систему. Поставщики выбираются на систему и т.д. Системы бывают большие и маленькие. Примеры больших систем это CRM, ERP, Mediation, а пример маленьких систем это отдельный веб-сайт или какой-нибудь несложный документооборот. Естественно, я сто раз задавал разработчикам маленьких систем вопрос: почему вы учитываете их как разные ИТ системы, и получал один и тот же ответ: наши процессы жестко связаны с понятием система. Например, невозможно задать инцидентам, заведенным на одну и ту же ИТ-систему разные сценарии обработки. Хочешь иметь различные сценарии – заводи в CMDB отдельную систему.
Такая картина складывается не только в процессах управления ИТ. Сплошь и рядом в учетных системах заводятся фиктивные сущности для того, чтоб использовать приколоченные к этим системам бизнес-процессы.
Так вот понятие кейс в кейс-менеджменте это способ обеспечения слабой связности между бизнес-процессами и данными той или иной предметной области. Это очень похоже на понятие сервис(услуга) в телекоме или ИТ. Сервис – это некоторая дополнительная сущность, которая связывает клиента, предоставляемую ему услугу и задействованные для этого ресурсы. Говоря языком UML кейс – это ассоциирующий класс. Например, сотрудник пишет заявку на услугу «предоставление рабочего места(компьютера)». Кейс объединяет человека, конкретный компьютер с серийным номером, услугу «рабочее место», а заодно и заявку. Завтра у человека сломается компьютер и мы отнесем его в ремонт, временно предоставив ему другой. Ресурс(системный блок) поменяется, сервис сохранится. Послезавтра человек захочет поменять стационарный компьютер на ноутбук и напишет новую заявку. Мы отберем у него стационарный компьютер и вручим ноутбук, но оставим монитор и клавиатуру, а системный блок передадим другому сотруднику. Очевидно, что нельзя жестко связывать заявки с конкретными ресурсами, отсюда и появилась идея сервиса. Аналогичную роль выполняет и кейс.
Но если вы погрузитесь в архитектуру существующих информационных систем, то поймете, что они сделаны совсем не так. В системах документооборота процесс строится вокруг документа. В ECM – вообще вокруг файла. Вы можете задавать свойства, доступы, workflow отдельному файлу, но столкнетесь с проблемами, если заходите объединить в общую сущность документ в формате WinWord, рисунок с скан-копией этого документа, файлы приложений к документу и пр. Категоризировать и согласовывать в ECM системах папки – задача не столь тривиальная. В трекерах все крутится вокруг тикета, в прочих системах ситуация аналогичная. Одним словом без кейсов крайне сложно обеспечить слабую связанность.
Была у меня когда-то заметка Изъяны бизнес-процессов прячутся в данных. К сожалению, верно и обратное утверждение.