Critical Capabilities for Composite Content Applications

Меня попросили написать комментарий к статье об adaptive case management в применении к  системам электронного документооборота. Комментарий я пока не написал, но освежил в памяти некоторые работы относительно ECM и ACM. В частности гартнеровскую Critical Capabilities for Composite Content Applications: Case Management.

Gartner занимается исследованиями кейс-менеджмента уже довольно давно. Тем не менее, в hype cycle 2011 кейс-менеджмент все еще не достиг пика завышенных ожиданий (см. рисунок). Т.е.за прошедшие пару лет тема ACM особо никуда и не сдвинулась. На мой взгляд, причина этого в том, что разговоры о кейс-менеджменте до сих пор носят слишком общий характер. Да, ACM – это инструмент для совместной деятельности работников умственного труда. Да « конвейерный» подход, целесообразный для рутинных операций, в кейс-менеджменте не применим, но чем мы его заменим?

Кейс-менеджмент еще не существует как методология. Его еще надо конструировать. Несколько моих(с) мыслей на этот счет:

Мы отказываемся от четко заданной последовательности работ. Но мы не отказываемся от понятия элементарной работы и не отказываемся от специализации сотрудников (т.е. функций – набора знаний и навыков, позволяющих хорошо проделать работу определенного вида). На самом деле, представление о том, какими могут быть эти функции уже давно присутствует в информационных системах. Правда его не разглядишь с горизонта кейс-менеджмента или с горизонта ECM или BPMS. Но это представление заметно, если мы говорим о платформе композитных приложений в целом. У такой платформы обычно есть отдельные модули (рабочие места) для отчетности, администрирования и т.д. Идея состоит в том, что для работы с кейсом необходимо выделение нескольких ролей, ответственных за определенный аспект работы. Назначение конкретных задач для каждой роли. Это позволит нам разграничить зоны ответственности, сохранив совместную работу сотрудников над общей задачей. В этой идее нет ничего нового. Вы найдете её в любом руководстве по управлению ИТ проектами. Сами роли достаточно хорошо проработаны в книжках по организации командной работы. Роли, например, могут быть следующими:

Координатор. Осуществляет первичный анализ кейса. Видит загруженность службы в целом и распределяет кейсы между исполнителями с учетом текущей загрузки, специализаций и предпочтений исполнителей.

Завершитель. Отвечает за среднюю температуру по больнице. Просматривает нерешенные кейсы. Уточняет у case workers в чем причина задержки. Отменяет ненужные задачи. Одним словом, стремится закрыть кейсы в срок.

Контролер. Назло завершителю следит за наиболее полной и качественной отработкой кейса. Назначает дополнительные задачи исполнителям. Следит за правильностью оформления кейса, корректностью ссылок и полнотой ассоциаций. Придумывает дополнительные бизнес-правила

Аналитик. Объединяет несколько кейсов в один или разбивает кейс на несколько. В схожих инцидентах пытается увидеть общую проблему. Отменяет устаревшие бизнес-правила. Вводит новые виды работ.

Руководитель. Устанавливает и изменяет приоритеты. Ставит кейсы на hold. Перераспределяет ресурсы. Обеспечивает своевременное проникновение в систему событий из внешней среды. Разбирается с исключительными ситуациями.

Безусловно, в конкретных предметных областях найдется еще множество специальных ролей: технологи, владельцы бюджета, финансовые контролеры и пр. На мой взгляд, кейс-менеджмент, вернее композитные приложения на основе кейс-менеджмента, должны двигаться примерно в этом направлении.

И в завершении анекдот:

Два человека работают в парке. Один выкапывает ямки, а другой их закапывает. Так они трудятся целый день. Ближе к концу рабочего дня к ним подходит прохожий и спрашивает: «зачем вы занимаетесь этой бессмысленной работой?». На что один из рабочих отвечает: Мы всегда так делаем, и еще никто не называл нашу работу бессмысленной. Он выкапывает ямки, а я – закапываю. Правда с нами обычно еще работает третий. Перед тем как я закапываю ямку, он вставляет в неё какую-то проросшую палку. Но сегодня он заболел и поэтому мы работаем вдвоем»

Реклама

2 Comments

    1. MBO — это правильно. Идеи Друкера — замечательны. Но как это положить в программный продукт не очень понятно. Из утверждения о том, что цели должны каскадироваться и измеряться сложно получить набор требований к ACM. Вообще, набор таких требований пока носит слишком общий характер.

      Или я про MBO где-то и что-то не дочитал?

      Ответить

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s