Обо всем понемногу

Тема адаптивного кейс-менеджмента продолжает набирать обороты. В прошлую среду, пока мы обсуждали ACM на семинаре BPMS.ru, интересная запись появилась в блоге лидера проекта Activiti. Tom Baeyens выразил свое видение развития проекта в направлении к кейс-менеджменту Unveiling Next Steps Of Alfresco’s Activiti Future

Но вернемся к семинару BPMS.ru Есть несколько мыслей, которые звучали в обсуждении и которые мне хотелось бы подчеркнуть

Как мы все хорошо понимаем, запуску экземпляра бизнес-процесса всегда предшествует определенное событие, например, поступление запроса от клиента. Но мы далеко не всегда можем четко классифицировать такое событие, а следовательно и запустить процесс, необходимый для обработки именно такого события. В качестве примера обратимся к процессам управления ИТ-сервисами. Существует, как минимум, три точки входа в ИТ: запрос на ИТ-услугу, инцидент – обращение связанное с нарушением уровня заказанного ранее сервиса и запрос на изменение. В реальной практике ИТ-подразделения пользователи довольно часто путают эти точки входа. Более того, в моей практике сами ИТшники не очень хорошо представляют границу между работами, которые можно осуществлять как ИТ-услуги и реальными изменениями. Безусловно, можно объединить все обращения в ИТ единым управляющим процессом и уже в ходе этого процента разбираться в том, что же за запрос мы получили. Но тогда возникнет сложность в задании свойств такого обращения. Либо мы дадим пользователю форму, которую он просто не сумеет заполнить либо вынуждены будем «добирать» свойства запроса по ходу его исполнения.

Я считаю, что поступать таким способом не следует. Намного проще разделить задачу на две: классификация обращения и его обработка. И резерв повышения эффективности, кстати, не столько в скорости проведения работ по исполнению запроса, сколько в качестве анализа конкретного обращения(случая, кейса). Кроме того, работы этапа классификации обращения заключаются не только в том, чтобы поместить запрос в ту или иную категорию (кстати, раскладывание сущностей по классам – одна из главных задач ИТ архитектора). При анализе обращений имеет смысл сопоставить его с другими обращениями из того же источника (поискать дубликаты), посмотреть что у нас происходит с предоставляемыми сервисами (аварии порождают, как правило, массовые инциденты) и т.д.

Другой момент, всплывший на состоявшемся семинаре. Мне кажется, наше представление о BPM содержит в себе определенное противоречие. С одной стороны, мы верим, что существует некий оптимальный процесс, приводящий нас к желаемому результату наилучшим путем (быстро, с минимальными ресурсными затратами и т.п.). С другой стороны мы не устаем говорить о том, что процессы должны быть гибкими, бизнес требует быстрых изменений, постоянной адаптации к новым реалиям и пр., т.е. по сути, отрицаем возможность существования этого самого «правильного» процесса. Двусмысленная позиция, согласитесь.

Одним словом, вопросов в управлении процессами остается намного больше чем готовых ответов. Так что, надеюсь, обсуждение темы ACM еще не однажды продолжится.

Реклама

3 responses to “Обо всем понемногу

  • AS

    I think that the both of your examples have no relation to the current BPMs vs. ACM discussion. They are related to the architecture of an enterprise BPM system.

    1. ITIL v3 is talking about those different entry points into IT. Also some classification of an external request is the normal old practice, e.g. 1/3 of requests for a loan can be approved fully automatically, 1/3 of them require a short human intervention and 1/3 require the work of a specialist. They are DIFFERENT processes. And requests from the same requester are treated differently….

    2. Are you talking about adaptation of templates or instances? Very often the business is happy that «next time» that work will be done better. So, ALWAYS qualify «process template» vs «process instance» — this will help you to avoid «Двусмысленная позиция».

    Thanks,
    AS

    • Максим Смирнов

      Спасибо за комментарий. Мы, действительно, отошли от дискуссии BPMs vs. ACM и больше говорили об архитектуре. В частности о том, что благодаря спецификации WS_BPEL бизнес-процессы превратились в сервисы, которые могут быть вызваны из любого приложения. А ACM «подобрал» эту возможность, включив бизнес-процессы в папку с данными и контентом.

      Что касается «process template» vs «process instance» — отдельная большая тема. Подозреваю, что разрыв между template и instance намного серьезней, чем мифический разрыв между ИТ и бизнесом 🙂

  • Johnker

    «BPMs vs. ACM» — противопоставление или интеграция?
    Ответ на этот вопрос зависит от позиционирования ACM. Я наблюдаю 2 тенденции среди экспертов

    Немного утрирую для наглядности.

    Одни считают, что ACM это «Pidgin-BPM», примитивная версия BPM, вульгарным способом решающая те же проблемы, что и BPM. «Серьезные специалисты», отдавшие годы BPMN, BPEL etc., принять такую концепцию ACM не готовы, максимум, на что они вынуждены идти — это считать ACM опцией, дополнительным «бантиком» к BPM. Что интересно, большой вклад в популяризацию такой концепции ACM оказывают посты некоторых известных «продавцов папируса» :), считающих, что «Adaptive /Case Management/ does not suppose collaboration» (sic!)

    Результатом такого подхода является ненужный антагонизм между ACM и BPM

    Другие считают, что ACM это collaborative BPM, social BPM, agile BPM, в которой следующий шаг процесса определяется в социальной среде решением человека. А этот как раз то «недостающее звено» по выражению Макса, чего не хватает традиционному BPM и почему изобретаются BPEL4People etc. В такой интерпретации ACM это как раз то, чего жаждет BPM, я бы сказал, без чего BPM не сможет развиваться, чтобы наконец стать эффективным инструментом. И интеграция BPM и ACM в этом случае расширяет сферу применения BPM, делает BPMs более привлекательными и эффективными. И те вендоры и интеграторы BPM, кто начинает интегрироваться с ACM, получают конкретные конкурентные преимущества

    BPM без ACM «выражает одну из основных черт буржуазного мировоззрения — его бесчеловечность, стремление превратить трудящихся в придаток машины, заменить живого, мыслящего, борющегося за свои интересы человека машиной» (1954, Краткий философский словарь о кибернетике) 🙂

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s