У нас возникло обсуждение темы разработки инструкций по обработке кейса. Выскажу свое мнение на этот счет, но сначала два предварительных замечания:
1. OMG уже пыталось навести порядок в этом вопросе и даже готовило RFP Case Management Process Modeling http://www.omg.org/cgi-bin/doc?bmi/2009-09-23 Согласованного результата не получилось. На мой взгляд, порядок обработки кейса существенно зависит от предметной области. В документообороте подход будет один, при обработке заявок – другой, а при решении инцидентов третий. Однако, некоторая база присутствует в RFP и предшествующих ему документах .
2. Обработка кейса имеет существенно итерационный характер. Одна и та же деятельность может повторяться многократно. Поэтому, нарисовать внятную модель обработки кейса в привычной нам форме — не простая задача. С другой стороны, кейсы легко группируются и наоборот распадаются на части. Так что говорить надо о некотором потоке работ, который связан с кейсом. Причем такая связь может и не быть постоянной.
Теперь про виды работ. Я проклассифицировал их следующим образом: предварительные, основные и вспомогательные.
Предварительные виды работ связаны с перехватом и регистрацией кейса. Они производятся однократно. Операции перехвата могут быть как очень простые (добавление заявки в базу), так и довольно сложные, включающие поиск дубликатов обращений, проверку их правомерности и т.д. Операция регистрации – это присвоение кейсу уникального идентификатора. Операция не такая безобидная, как это кажется на первый взгляд. Здесь очень важно не переусердствовать и не смешать операцию регистрации и классификации. Предположим мы получили заявку на предоставление сервиса от клиента X. Очень велик соблазн кроме уникального номера заявки включить в её идентификатор код клиента и код сервиса. Это ошибка. Завтра выяснится, что одни клиенты могут оформлять заявки по поручению других, заявка на предоставление сервиса – это попытка решить инцидент по уже предоставленному сервису и т.д. Одним словом идентификаторы типа «AБВ.123-ГД/22.05» не имеют право на существование.
Основные виды работ можно разделить на обогащение кейса, преобразование кейсов и планирование-реализацию-контроль. Обогащение заключается в связывание кейса с дополнительной информацией. В ходе этой деятельности мы привязываем к кейсу различные виды информации – документы, записи, неструктурированные данные. Частным случаем обогащения является классификация. Классификация – это такое обогащение кейса данными, когда информация берется из предварительно заполненных справочников: инициатор кейса из справочника клиентов, тип сервиса – из справочника сервисов и т.д. Адреса, даты, типы сервиса, группы клиентов… любая таксономия, которой мы располагаем. Обогащение – более общий случай классификации, т.к. при обогащении мы можем привязать к кейсу то, чего нет в наших справочниках. Еще один частный случай обогащения заключается в обращении за дополнительной информацией к клиенту. Назовем его уточнение. Уточнение может полностью или частично изменить достигнутые в ходе обработки кейса результаты. Клиент может просто прийти и закрыть кейс. Еще раз напомню, что все эти виды деятельности могут возникать в любой момент жизненного цикла кейса и повторяться произвольное число раз.
Следующий вид работ – преобразование кейсов, включает в себя группировку и расщепление. Т.е. кейс может войти составной частью в другой, более общий кейс, например при объединении заказов в один большой заказ, предполагающий хорошую скидку. С другой стороны кейс может расщепиться (доставляем то, что есть в наличии на складе, а остальное переносим в новый заказ).
Ну и, пожалуй, главное, что происходит при обработке кейса это выполнение работ. Мне кажется, здесь вполне уместны активности из цикла Деминга: планирование, реализация и контроль. Не буду на этом долго останавливаться, упомяну лишь, что данные активности тесно связаны с другими двумя: выделение ресурсов и их изъятие. Выделение ресурсов это и назначение ответственного за кейс в целом (case manager) и назначение ответственных на отдельные задачи. Завершение кейса можно рассматривать как частный случай изъятия ресурсов. Справедливости ради следует сказать, завершается не сам кейс, а связанный с ним поток активностей. Т.е. после закрытия кейса, мы можем продолжать его использовать. Это происходит при объединении кейсов, при поступлении новых запросов того же вида сервиса или от того же клиента и, что самое главное, при анализе наших процессов с целью их улучшения.
Вспомогательные процессы: трекинг, эскалация, улучшение. С трекингом все более-менее просто. Все изменения кейса должны фиксироваться. Это обычно происходит автоматически. На основании трекинга осуществляется формирование статистики по процессам и мониторинг. Единственное на что хочется обратить внимание – любая протоколируемая операция должна быть осмысленной. Помните, как у Алистера Коберна: каждый шаг основного сценария должен приближать главное действующее лицо use case-а к намеченной цели. Очень много информационных систем, особенно ECM систем этого не делают. Мы называем такие системы чатом. Люди в них мило общаются, пишут друг другу пространные комментарии, а стоит на месте. Эскалация – это один из механизмов повлиять на продвижение кейса. Если какое-то время с кейсом ничего не происходит, то значит требуется внешний по отношению к основному ходу событий механизм, чтоб заставить эти самые события двигаться. Улучшение процесса – еще одни важный момент, который можно включить в ходе выполнения кейса. Зачастую ничего не происходит именно потому, что процесс простроен неправильно. Не надо ждать окончания квартала для того, чтобы поулучшать процесс. Достаточно включить в реальный процесс его разработчика. Через процесс улучшения надо выстраивать заполнение справочников, доработку правил классификации, адаптацию программного обеспечения.