Тема адаптивного кейс-менеджмента продолжает набирать обороты. В прошлую среду, пока мы обсуждали ACM на семинаре BPMS.ru, интересная запись появилась в блоге лидера проекта Activiti. Tom Baeyens выразил свое видение развития проекта в направлении к кейс-менеджменту Unveiling Next Steps Of Alfresco’s Activiti Future
Но вернемся к семинару BPMS.ru Есть несколько мыслей, которые звучали в обсуждении и которые мне хотелось бы подчеркнуть
Как мы все хорошо понимаем, запуску экземпляра бизнес-процесса всегда предшествует определенное событие, например, поступление запроса от клиента. Но мы далеко не всегда можем четко классифицировать такое событие, а следовательно и запустить процесс, необходимый для обработки именно такого события. В качестве примера обратимся к процессам управления ИТ-сервисами. Существует, как минимум, три точки входа в ИТ: запрос на ИТ-услугу, инцидент – обращение связанное с нарушением уровня заказанного ранее сервиса и запрос на изменение. В реальной практике ИТ-подразделения пользователи довольно часто путают эти точки входа. Более того, в моей практике сами ИТшники не очень хорошо представляют границу между работами, которые можно осуществлять как ИТ-услуги и реальными изменениями. Безусловно, можно объединить все обращения в ИТ единым управляющим процессом и уже в ходе этого процента разбираться в том, что же за запрос мы получили. Но тогда возникнет сложность в задании свойств такого обращения. Либо мы дадим пользователю форму, которую он просто не сумеет заполнить либо вынуждены будем «добирать» свойства запроса по ходу его исполнения.
Я считаю, что поступать таким способом не следует. Намного проще разделить задачу на две: классификация обращения и его обработка. И резерв повышения эффективности, кстати, не столько в скорости проведения работ по исполнению запроса, сколько в качестве анализа конкретного обращения(случая, кейса). Кроме того, работы этапа классификации обращения заключаются не только в том, чтобы поместить запрос в ту или иную категорию (кстати, раскладывание сущностей по классам – одна из главных задач ИТ архитектора). При анализе обращений имеет смысл сопоставить его с другими обращениями из того же источника (поискать дубликаты), посмотреть что у нас происходит с предоставляемыми сервисами (аварии порождают, как правило, массовые инциденты) и т.д.
Другой момент, всплывший на состоявшемся семинаре. Мне кажется, наше представление о BPM содержит в себе определенное противоречие. С одной стороны, мы верим, что существует некий оптимальный процесс, приводящий нас к желаемому результату наилучшим путем (быстро, с минимальными ресурсными затратами и т.п.). С другой стороны мы не устаем говорить о том, что процессы должны быть гибкими, бизнес требует быстрых изменений, постоянной адаптации к новым реалиям и пр., т.е. по сути, отрицаем возможность существования этого самого «правильного» процесса. Двусмысленная позиция, согласитесь.
Одним словом, вопросов в управлении процессами остается намного больше чем готовых ответов. Так что, надеюсь, обсуждение темы ACM еще не однажды продолжится.