Adaptive Case Management (ACM)
Адаптивное ведение дел

Adaptive Case Management (ACM) — это концепция, альтернативная концепции BPM. Альтернативная — это значит, что решается та же самая задача эффективной организации бизнес-процессов, но другими средствами. Если совсем кратко, то идейное различие в подходах можно охарактеризовать следующим образом:

BPM идет от структуры процесса, состава шагов, которые необходимо совершить, чтобы достигнуть цели. Данные могут возникать в ходе процесса, являясь полностью ависимыми от него. ACM идет от информации и бизнес-данных, возникающих в ходе работы и необходимых для того, чтобы считать результат достигнутым . Процессы возникают в контексте данных, а не наоборот.

Файл:Адаптивный кейс-менеджмент.jpg

1. Место ACM среди других технологий

Начнем с того, что BPM, Project Management (PM), ACM и ряд других управленческих технологий, применяются для управления деятельностью организаций.

Чтобы показать, каким образом ACM встраивается в практическую деятельность и каковы отличительные черты этой технологии именно в практическом применении, я воспользуюсь очень простой моделью деятельности, в которой выделены:

• цель;
• действие, направленное на достижение этой цели;
• исполнитель, производящий это действие.

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

Далее, рассмотрим следующие свойства каждого элемента этой модели: повторяемость (как возможность многократного повторного использования одних и тех же описаний и моделей) и предсказуемость (как возможность предварительного планирования).

Здесь знаками `+` и `-` отмечены свойства, которые были бы предпочтительны или, соответственно, нежелательны для данной технологии. Знаком `?` отмечены свойства, наличие или отсутствие которых мало влияет на технологию.

В этой таблице есть один неочевидный момент. Почти во всех источниках ключевым достоинством ACM считается успешность борьбы с непредсказуемостью, но в таблице утверждается, что технология ACM хороша лишь при предсказуемых целях и более того — когда цели относительно постоянны и повторяются от кейса к кейсу. Обосную свою точку зрения доказательством от обратного. Для этого рассмотрим, к чему бы привели систематически непредсказуемые цели:

Когда меняются цели, меняются и требования к результату деятельности. Это значит, что статистика активностей пользователей, которую могла бы накапливать ACM-система, уже не сможет подсказывать, какие действия подходят к данной ситуации. Сравните, например, с проектным управлением, где непредсказуемость целей проекта компенсируется относительной предсказуемостью запланированных действий и исполнителей. Хорошо, пусть автоматизация в условиях полной непредсказуемости затрудняется. Тогда можно было бы попробовать сделать что-то на организационном уровне. Но и тут проблемы: в регламенте не удастся зафиксировать ни процесс, ни его результат, ни даже его цели. А регулярно писать регламент под каждую вновь появляющуюся цель — это уровень технологий, о котором в ACM даже не заикаются. Далее, положим, что можно и от регламента отказаться, уповая лишь на инициативу работников умственного труда (knowledge workers). Но кто сможет показать хоть одну компанию численностью более десятка человек, где сотрудникам предоставлена полная свобода в целеполагании, выборе средств и методов работы? Конец доказательства.

Метавселенная ВДНХ 3.4 т

Резюмируя вышесказанное: каждая из перечисленных технологий требует предсказуемости хоть в чем-то. Для ACM — это цель кейса.

Однако вернемся к `тотальной непредсказуемости`, охватывающей, в том числе, цели бизнес-процессов. Какой должна быть технология управления в таких условиях? Ответ на этот вопрос, включающий обоснование, мне встретился в книге Новиков А.М., Новиков Д.А. `Методология` — для непредсказуемых целей наиболее адекватен проектный стиль управления. Но при этом потребуется приготовиться к перестройкам плана и изменению команды уже в ходе проекта.

Еще один ракурс, для полноты картины. С точки зрения проектного управления `тотальная непредсказуемость` — это признак проектов высокой сложности, для которых ключевыми вопросами являются вовсе не технологии автоматизации, а… лидерские качества и воля руководства. Впрочем, вопрос о проектах высокой сложности хорошо раскрыт в серии статей Сергея Чурюмова.

2. Предельно конкретный пример

Есть процесс: обработка заявок, поступающих через сайт. Первый этап процесса — определить для каждой заявки, следует ли ее принять или отклонить. После всех автоматических проверок, для контроля оператором остается `всего` четыре условия. Задача: подготовить инструкцию для оператора по приему заявок.

Казалось бы, при взгляде сверху, все просто. Но при погружении в детали начинаются `неприятности»:

• Иногда решение можно принять после проверки одного-двух условий, и остальные уже не требуется проверять.
• В разных случаях удобна разная последовательность проверки условий, жестко фиксировать последовательность нельзя.
• В некоторых случаях часть условий можно проверить только с обращением к эксперту, но желательно этого избегать без необходимости.

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

И словесный алгоритм, и блок-схема не помогают оператору толком разобраться, как же все-таки следует правильно отличать корректные заявки от некорректных. Точно также они не помогают контролировать оператору свою работу, поскольку не содержат наглядно сформулированных требований к результату.

Посмотрим, что изменится, если не пытаться описывать процесс, а попытаться описать результат, который требуется получить?

Если выписать все возможные комбинации результатов проверки злополучных четырех условий, пометить каждый вариант признаком `Принять` или `Отклонить`, свести варианты в таблицу и отсортировать их по наиболее часто проверяемым условиям, то получится… готовый к употреблению `чек-лист` (условия обезличены, так как это выдержка из документа ДСП):

Такую таблицу остается только дополнить требованиями и рекомендациями, которые формулируются линейным списком и предельно просто, поскольку уже нет нужды описывать ветвления. Здесь, в отличие от запутанных схем, оператор достаточно легко разберется, что от него требуется, и сам найдет наиболее удобный для себя стиль работы. И, что тоже важно, в сложных случаях оператор всегда сможет быстро себя перепроверить по такой таблице.

Уже на этом микро-примере, хорошо видно, насколько меняется результат (в данном случае — организация работы оператора), если переместить фокус внимания со структуры процесса на структуру обрабатываемой информации. Также на этом примере видно, что применение `новейшей` концепции, на практике может приводить к уже известным решениям. Как говорится, `все новое — хорошо забытое старое`.

Также здесь можно упомянуть еще один пример построенной по принципам ACM инструкции, опубликованный Анатолием Юмашевым, а также замечательный пост Максима Смирнова об одной реализации бизнес-процессов чек-листами . Хотя, на мой взгляд, контрольный список действий — это не единственная из возможных реализаций чек-листов, но описана она очень хорошо.

3. Взгляд со стороны нормативной документации

Далее, предлагаю подняться с микроуровня организации бизнес-процессов на самый ее верх и оценить, какие выводы можно сделать, глядя на всю систему регламентирующей документации через призму идей ACM?

Естественно, здесь наиболее интересны аспекты, связанные с изменчивостью бизнес-процессов и изменчивостью их составных элементов. По результатам анализа систем корпоративных стандартов ряда компаний, удалось выделить следующие пять аспектов:

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

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

• Оценивать систему автоматизации — на предсказуемость каких компонент бизнес-процессов она рассчитывает.
• Оценивать, насколько автоматизируемые бизнес-процессы устойчивы к изменениям.
• Дробить схемы процессов и стремиться к их переиспользованию. Чем меньше схема — тем меньше шансов, что она будет меняться при очередном обновлении регламентов.
• Выявлять переменную часть процедур и выносить ее в область настройки, которую могли бы выполнять сами пользователи, а не только бизнес-аналитики и программисты.
• Вычисления бизнес-правил должны выражаться в бизнес-значимых терминах, чтобы улучшить их переиспользование и сопровождаемость.
• Точная спецификация бизнес-значимых параметров бизнес-процессов, которой должны удовлетворять реализации процессов в системе. Это упрощает процессы изменений.
• Там где это оправдано, формулировать регламенты не в виде схем процессов, а в виде чек-листов.

4. Взгляд со стороны текущей деятельности сотрудников

Нормативная документация дает представление о принятой модели деятельности в данной организации. Но модель процессов — это не то же самое, что делается на самом деле. Думаю, всем знакомы ситуации, когда регламенты расходятся с реально действующей практикой либо не раскрывают существенных ее аспектов. Поэтому следующим шагом предлагаю посмотреть, что ценного можно извлечь из `цифровых следов` деятельности — журналов аудита фактических действий пользователей.

Некоторое время назад в своем посте `Ахиллесова пята` процесса я поднимал вопрос о поисках альтернатив процессному управлению, когда речь идет о неустойчивых процессах. И, как по заказу, вскоре появился ACM, позиционируемый именно как такая альтернатива. Основной идеей тогда было — выявить устойчивые компоненты в неустойчивых процессах и найти способ автоматизировать устойчивую часть процессов. Теперь эту идею можно сформулировать более конкретно:

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

Решая первую задачу, можно предложить следующую технологию анализа статистики пользовательских действий. Каждое зафиксированное событие инициации задачи сопровождается набором атрибутов, среди которых выделяются три важных группы:

• Инициатор и его место в оргструктуре предприятия. Дает ответ на вопрос: кому нужен шаблон?
• Объект системы и его свойства, от которого инициируется задача. Отвечает на вопрос: в каком месте системы нужна инициация задачи по шаблону?
• Структура задачи. Отвечает на вопрос: какие ситуации может охватить данный шаблон?

Весь массив информации о событиях анализируется в трех перечисленных разрезах. При этом порядок, в котором происходит погружение в данные, влияет на получаемые результаты. Приведу несколько примеров:

• Структура задачи/Вложение — где была бы полезна кнопка на быстрый старт задачи?
• Структура задачи/Вложение/Исполнители — можно ли сразу заполнить маршрут задачи?
• Структура задачи/Вложение/Инициатор — кому показывать эту кнопку?
• Инициатор/Структура задачи — кому мы можем помочь с устранением рутины?
• Структура задачи/Инициатор — кому будет интересен данный шаблон?

Выводы, которые можно получать с помощью такого анализа:

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

Заключение

В статье я попытался представить тему ACM с четырех различных углов зрения. Закономерно, что результаты, получаемые в каждом случае, внешне значительно отличаются друг от друга. Это говорит о том, что концепция ACM достаточно нетривиальна.

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

• Источник - Гибкие процессы