Главная » Блоги Экспертов И ИТ-Компаний » Адаптивный кейс-менеджмент (ACM) в CompanyMedia (концепция, часть 1)

Адаптивный кейс-менеджмент (ACM) в CompanyMedia (концепция, часть 1)

 

 

Решил опубликовать в преддверии форума ИнтерТраст (9 октября 2012г.),где будет представлена новая версия СЭД CompanyMedia.

Адаптивный кейс-менеджмент (ACM) и CompanyMedia как ACMS (ACM-система)

Под адаптивными принято понимать такие системы, которые сами приспосабливаются к изменениям внешних условий, так что в итоге они всё-равно достигают своих целей. Считая, что в информационную систему входят не только "железо" и ПО аппаратное, программное и прочее обеспечение, но и все её пользователи, можно сказать, что она адаптивна, если пользователи сами подстраивают ее под свои потребности.

Адаптивность реализации кейс-менеджмента в CompanyMedia 4 достигается за счет "редактора кейсов" (РК), - относительно простого средства, доступного всем участникам работы с кейсами. РК в СМ4 позволяет задавать структуру информации и деятельности как для конкретных кейсов, так и для их типовых множеств (с помощью шаблонов). Важнейшая функция РК - создание "заготовок" любых объектов в структуре кейса (элементов кейса - документов, задач, событий, ролей,...) - доступна как на уровне шаблона, так и с конкретным экземпляром.

В будущих версиях CompanyMedia дополнительно обеспечивается прозрачная интеграция подсистемы кейс-менеджмента с подсистемой управления бизнес-процессами (BPMS). Тогдаможно будетуправлять степенью адаптивности кейс-менеджмента в широких пределах - от предопределенной по BPMN 2.0 схемы процесса выполнения кейса до полной свободы, когда план работы (состав и структура решаемых задач) определяется в процессе самой работы по кейсу. Также возможны и любые промежуточные варианты. Все это достигается за счет взаимодействия Workflow-движка с машиной состояний, управляющей стадиями ЖЦ кейсов и вложенных элементов. Вместе с каждым кейсом с момента его открытия стартует экземпляр процесса, соответствующий типу кейса. Процесс может быть крайне простым (практически "вырожденным"), а может быть и сколь угодно сложным: во-первых, возможности BPMN 2.0 весьма велики, во-вторых, состояние кейса и его элементов может влиять на ход процесса, в-третьих, процесс может менять состояние кейса и его элементов.

Структурирование информации и деятельности в кейсе

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

Кейсы позволяют структурировать такую деятельность с учетом особенностей предметной области, бизнес-правил организации, орг.структуры, при этом, в отличие от "обычных бизнес-процессов", не ограничивая свободу участников в выборе конкретной последовательности бизнес-операций. Для этого автоматизация обеспечивается за счет шаблонов, в которые вносится всё, что можно использовать многократно (в типовых кейсах), а свобода - за счет возможности для участников менять всё, что угодно, в конкретных кейсах.

Однако, в чём же здесь принципиальное отличие от BPM/Workflow? Ведь лучшие системы этого класса тоже позволяют модифицировать модели процессов (те же шаблоны) прямо в ходе их выполнения. Дело в том, что адаптивный кейс-менеджмент (в нашем понимании) рассматривает деятельность не с операционной/алгоритмической точки зрения, а со стороны ее информационного наполнения - бизнес-объектов, их структуры, взаимосвязей и жизненных циклов. Такой подход кардинально отличается от современного BPM по степени доступности для понимания непосредственными участниками автоматизируемой деятельности, а значит и для адаптации их же силами.

В кейсах могут быть структурированы:

  • Данные: документы, формы (структурированные документы), бизнес-сущности, контакты, иерархия папок для раскладки всего хозяйства в кейсе;
  • Цели: ожидаемые результаты, требования к ним - как по всему кейсу, так и для его стадий и "контрольных точек";
  • Деятельность: стадии/фазы ЖЦ кейса, "вехи" (контрольные точки), задачи/работы, события в ЖЦ кейса и его элементов;
  • Действия: функции, процессы, процедуры, операции, запускаемые из кейса;
  • Орг.структура - роли участников;
  • Коммуникации: уведомления, обсуждения, кейс как ПЯ, ...
  • Правила: нормы, ограничения, права доступа, ...
  • Время (привязка любых элементов к шкале времени относительно событий кейса).

 

Понятие элемента кейса

В приведенном выше списке упоминается множество классов объектов, которые могут быть использованы в качестве элементов кейса. Но "элемент" кейса - это нечто большее, чем просто факт включения чего-то (например, документа) в контейнер (кейс-папку). Объект, помещенный в кейс как элемент, приобретает дополнительные свойства и возможности. Во-первых, можно определить "роль" этого объекта в этом кейсе. Для субъектов это уже привычное дело - сначала определяются роли, потом в конкретных случаях на них назначаются конкретные люди. Но то же самое имеет смысл для любых классов объектов.

Например, включая в кейс "доработка СЭД по требованиям заказчика" конкретный внутренний документ, можно определить, что именно этот документ содержит требования к доработке. Для человека в подобных случаях было бы достаточно подходящего заголовка документа или типа/вида документа, но для автоматической обработки нужна формализация этого понятия, то есть, именно для этого или для таких кейсов надо определить специфическую "роль" документа - "Техническое задание", а назначение на нее конкретного документа производить при добавлении подходящего документа в такой кейс.

Таким образом, "роль" - это свойство, применимое не только к субъектам - участникам кейса, но и к любым объектам в кейсе, а формально оно принадлежит сущности "элемент кейса".

Кстати, аналог этого понятия у нас уже давно есть: когда мы связываем с документом другой документ, мы выбираем из классификатора "тип связи", например, "в ответ на". Это и есть "роль" связываемогодокумента по отношению к исходному. Заодно получаем замечательную возможность - при использовании существующего механизма связей для добавления объектов в кейс вместо выбора типа связи из классификатора предлагать выбор из уже имеющихся (заранее заготовленных) элементов рассматриваемого кейса.

Иерархия элементов кейса = СДР (WBS)

Есть интересная особенность, характерная для всех "элементов", но не для папок. В отличие от папок, "элементы кейса" структурируют не только контент (информацию в кейсе), но и деятельность, т.к. с большинством элементов связана явно или неявно определенная работа кого-либо из участников кейса.

В то же время, между ними есть и нечто общее: также как папки организуются в иерархии, так и "работы" часто могут быть вложены друг в друга, тем самым показывая отношения делегирования и/или декомпозиции. Ведь именно так иерархически и строятся многие планы работ (например, этапы / подэтапы / работы), а всякие особые взаимосвязи между работами нужны относительно редко.

В управлении проектами этот подход/инструмент называется "иерархическая структура работ (ИСР)", она же "Структурная Декомпозиция Работ (СДР)", она же "Work Breakdown Structure (WBS)"(см. например,).

СДР (ИСР, WBS) - это иерархическая декомпозиция работ, которые должны быть выполнены проектной командой для достижения целей проекта и создания необходимых результатов проекта. Она структурирует и определяет общий объем проекта.

Уместно вспомнить, что "иерархические декомпозиции работ" давно применяются в СЭД (в частности в СМ), но только на уровне отдельных документов. Во-первых, это иерархия поручений в ходе исполнения документа, во-вторых - иерархия виз в процессе согласования. Есть и еще одна подходящая фича в СМ - процесс совместной подготовки документа, интересная тем, что чётко определен конечный результат - документ. Но только там у нас все участники редактируют один и тот же документ, а в жизни многие документы состоят из нескольких частей, которые готовят разные люди/подразделения, а итоговый результат/продукт получается сборкой/композицией составных частей. Т.е. декомпозирована на составные части может быть не только работа/задача, но и ее результат/цель. Причем, согласно многим источникам (например ), "Plan outcomes, not actions" = "планируйте результаты, а не работы" - это предпочтительный способ декомпозиции.

Таким образом, СДР можно понимать как Структурную Декомпозицию Результатов!

Такой подход - планирование прежде всего результатов (а работ - уже по мере необходимости) в кейс-менеджменте предпочтителен даже в еще большей степени, чем в управлении проектами.

Однако, пора наконец разобраться, не слишком ли много тут о проектах, и какое отношение они имеют к кейсам. На самом деле, всё это не зря. Они во многом похожи, прежде всего - ориентированностью на достижение цели, получение результата. Цели/результаты проектов часто бывают уникальными, но такие случаи оставим для «управления проектами». А мы занимаемся более-менее повторяющимися ситуациями, на них гораздо легче получить эффект от автоматизации. То есть, остаются типовые кейсы и проекты. Здесь повторяется почти всё: цели, структура документов, роли участников, состав этапов/стадий, события, контрольные точки. Однако, не повторяется и непредсказуем (в деталях) ход работ, в отличие от процессов.

Получается, "наши кейсы" = типовые проекты? Всё-таки не совсем. Проекты - это уже на границе нашей области применения. А нам нужно охватить кейс-менеджментом ту часть управленческой деятельности организации, которая, лежит в области, ограниченной в двух измерениях (сложность и повторяемость) следующим образом:

  • по сложности - между простыми взаимодействиями в объеме одного документа (одно письмо + несколько поручений) с одной стороны и реальными проектами - с другой;
  • по предсказуемости/повторяемости - между бизнес-процессами с одной стороны и уникальными проектами - с другой.

Получаем некий треугольник (надеюсь, не бермудский) с вершинами: проекты, процессы, директивы (ДОУ).
А почти вся его внутренняя часть - это кейсы! И ведь эта огромная область всё еще не охвачена единой методологией управления и целостным подходом к автоматизации. До сих пор всё решается либо путем сведения к крайностям (проекты, процессы, директивы), неэффективным для кейсов, либо "кусочной автоматизацией" - тысячами приложений и систем для частных случаев.


Таким образом, область применения ACMS - это ситуации (случаи, кейсы, вопросы, проблемы, инциденты,...), которые:

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

Последний пункт я специально добавил после того, как на моё замечание в FB о том, что кейсы похожи на типовые проекты, Максим Смирнов написал (комментарий в FB): ACM - это о том, как добиваться поставленных целей при помощи более простых, но и более адаптивных моделей.

И еще на ту же тему из GTD: "...большая часть приложений, предназначенных для упрощения проектного планирования требуют слишком большой тщательности и скрупулезности, которые в большинстве наших проектов вовсе не нужны. На протяжении многих лет я видел, как эти программы пробовали и отвергали, а не использовали как полезный инструмент. Они используются только в том случае, если были разработаны на заказ и удовлетворяют весьма специфичным требованиям того или иного производства или организации.
Я предполагаю, что в ближайшие годы появятся менее структурированные и более функциональные приложения, основанные на методах естественного планирования. А пока, пользуйтесь каким-нибудь простым и хорошим планировщиком."

В этой связи вернемся к понятию СДР, взятому из прожект-менеджмента. Не слишком ли это сложно? Однако, СДР проще диаграммы Ганта, это буквально "иерархическая структура" (результатов или работ - здесь не важно), и ничего больше. Например, "перечисленные в ней действия не связаны временной последовательностью...". Наш опыт внедрений CompanyMedia показывает, что иерархия поручений/отчетов в ходе исполнения документа не только не слишком сложна для пользователей, но и является весьма востребованной функцией системы. А как насчет согласования, да еще и комбинированного (с последовательными и параллельными этапами), да еще и со спец. параметрами для отдельных этапов/участников? Да не вопрос! Наши пользователи и к этому уже привыкли.

Главное, чтобы сложность системы, как она видна пользователям, была адекватна (не сложнее) предметной области, ну и понятия у нее должны быть близкими к реальной жизни. В этом смысле у СДР гораздо больше шансов, чем у BPMN и даже диаграммы Ганта.

(продолжение следует...)


Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.
Комментарии
Другие публикации
RU, Москва
http://www.intertrust.ru , Главный архитектор
+7(495) 956-79-28
Информационные технологии

Компания «ИнтерТраст» предоставляет Заказчикам весь комплекс услуг по созданию современных информационных систем электронного документооборота, включая консалтинг в области информационных технологий, разработку, внедрение и сопровождение программного обеспечения, обучение пользователей и сотрудников ИТ подразделений... http://www.intertrust.ru

Инициатива "CompanyMedia - Строим открыто!"
http://www.facebook.com/
http://opendev.cnews.ru/
http://club.cnews.ru/ИнтерТраст




Забыл пароль?
Авторизоваться через
Зарегистрируйся сейчас!
Присоединяйся к нашему обществу для того чтобы познакомиться с новыми людьми, создать собственный блог, публиковать анонсы событий и объявления, а также участвовать в обсуждении публикаций CNews. Мы создали единое пространство для общения специалистов рынка информационных технологий и всех, кто интересуется современными технологиями. Регистрация =>