2. Что мы на самом деле автоматизируем?

Диалектика и структура автоматизации.

Оглавление

Постановка задачи

История развития автоматизации бизнеса представляет собой последовательную смену этапов: EAI, SOA, BPM и т.п. Каждый из них связан с новым походом и типом инструмента, и складывается впечатление, будто новый этап начинается, потому что вендоры придумывают новый продукт.

Но так ли всё просто? Или новый продукт появляется, потому что в нём назрела необходимость?

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

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

Замечание: дальнейшее рассмотрение является аналитической реконструкцией, а не хронологией, так как многие парадигмы развивались частично параллельно. Учитываются лишь те факты, которые помогают раскрыть внутреннюю логику эволюции.

Этапы эволюции автоматизации

Ранняя автоматизация: автоматизация действий

На ранних этапах автоматизировались отдельные действия: ввод данных, расчёты, оформление документов, учёт. Для этого внедрялись отдельные специализированные системы: CRM, АБС, биллинг и так далее — каждая автоматизировала свою часть деятельности.

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

Фокус автоматизации был направлен на автоматизацию отдельных действий.

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

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

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

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

Объект автоматизации: действия.
Инструмент: транзакционные системы.
Противоречие: масштабирование действий — данные «заперты» внутри систем.

(здесь и далее противоречие в формате: «потребность — проблема»)

Enterprise Application Integration (EAI)

Ответом стало появление парадигмы системной интеграции и интеграционных платформ как инструмента. Эти платформы предлагали средства для:

• создания адаптеров к системам;
• поддержки различных протоколов передачи;
• трансформации и маршрутизации данных;
• типовых сценариев интеграции.

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

Фокус автоматизации сместился к согласованию данных между системами.

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

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

Объект автоматизации: согласование данных.
Инструмент: интеграционные платформы.
Противоречие: автоматизации операций — функции «заперты» в разных системах.

Service Oriented Architecture (SOA)

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

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

Фокус автоматизации сместился на бизнес-операции

На операционном уровне зрелая SOA породила внутренне завершенную архитектуру и позволила автоматизировать значительную часть бизнес-операций.

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

Кроме того, изменились требования среды (в т.ч. и через влияние результатов предыдущего этапа):

• возросла скорость изменений;
• росли требования регуляторки и комплаенса.

Для системного ответа на эти изменения были необходимы:

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

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

Объект автоматизации: бизнес‑операции.
Инструменты: Service Registry, ESB, BPEL.
Противоречие: автоматизация процессов — процессы не являются объектом системы.

BPM

На данном этапе в систему было перенесено управление деятельностью организации (процессы). Теперь не человек управлял процессом, а система управляла человеком и автоматизированными операциями. Это открыло новые горизонты для оптимизации, повысило управляемость и гибкость деятельности.

Фокус автоматизации смещается на управление последовательностью задач — процесс

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

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

С точки зрения теории, это проявление практического предела формализма или, другими словами, проявление неопределённости, присущей реальным процессам — ряд аспектов процесса крайне сложно, нецелесообразно, или вовсе невозможно формализовать.

(об этом в отдельной статье)

На практике это могло проявляться так:

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

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

Это стало барьером для дальнейшего масштабирования автоматизации.

Объект автоматизации: процесс (последовательность задач).
Инструмент: BPMS, BPMN.
Противоречие: автоматизация процессов — предел формализма.

Dynamic Case Management (DCM)

DCM принял эту данность, отказался от попыток формализовать всё и признал принципиальную роль человека, как демпфера неопределённости. Теперь формализуется только то, что хорошо этому поддаётся, а всё прочее возвращается человеку (кейс-воркеру). В результате появляется новая структура деятельности (кейс), предусматривающая слоты неопределённости, в пределах которых человек может принимать решения с учётом ситуации: позвонить клиенту, выполнить действие, запустить процесс и так далее.

Фокус автоматизации смещается с управления последовательностью задач на управление ситуацией — кейсом.

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

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

Объект автоматизации: ситуация (кейс).
Инструмент: Dynamic Case Management Platform.
Новое противоречие: предпосылка — зависимость от человеческой интерпретации.

Decision Management (DM)

Параллельно развитию DCM происходил другой процесс, подталкиваемый давлением среды:

• скоростью изменений;
• регуляторкой;
• персонализацией;
• накоплением данных и необходимостью их использования при принятии решений;
• появлением новых классов задач: scoring, fraud detection, recommendation и т.п.

Это заставляло искать новые ответы и привело к осознанию в структуре деятельности повторяемых решений, которые характеризуются:

• формализуемостью;
• массовостью;
• изменчивостью.

Это не что-то новое, в традиционном BPM такие решения уже были, но они были «размазаны» по коду, что создавало ряд проблем:

• изменение требовало релиза;
• не было управления жизненным циклом;
• не было централизованного анализа и аудита;
• не было модели владения.

Противоречие: массовые изменяемые решения — правила не являются объектом системы.

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

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

Фокус автоматизации смещается на управление бизнес-правилами.

DCM + DM

Между парадигмами DCM и DM прослеживается определённая близость. Они являются двумя ответами на разные аспекты предела формализма:

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

То есть:

• DCM работает с уникальными ситуациями;
• DM — с массовыми решениями.

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

Можно сказать, что комбинация DCM и DM — это зрелая и внутренне согласованная архитектура, которая закрывает главные потребности в управлении структурой деятельности:

• BPM реализует координацию;
• DCM легализует неопределённость;
• DM реализует массовые решения.

Анализ эволюции

Если теперь посмотреть на рассмотренные этапы вместе, можно заметить важные закономерности.

Объект автоматизации

Закономерность 1: каждый этап автоматизации фокусируется на определённом аспекте деятельности — объекте автоматизации.

Закономерность 2: каждому объекту автоматизации соответствует свой инструмент.

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

Закономерность 3: последующие этапы не отменяют предыдущих, но несколько изменяют их роль, а именно, расширяют и развивают. Так, EAI и SOA не отменили легаси-системы, но из островков автоматизации превратили их в участников общего ландшафта автоматизации. BPM, трансформировавшись в DCM, не отменил формализованные процессы, но видоизменил их и структурировал в кейсы.

Выводы:

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

Архитектурные циклы

Однако смена объекта автоматизации — не единственная закономерность. Если посмотреть на структуру этих переходов, можно заметить ещё один повторяющийся паттерн.

Предпосылкой является наблюдаемая неравнозначность этапов:

• ранняя автоматизация и BPM переносят в систему новый элемент деятельности: действие и процесс;
• EAI разрешает возникшую архитектурную проблему: добавляет согласование данных;
• SOA, DCM и DM добавляют структурирование и развивают архитектуру до завершённости.

Откуда берётся такая асимметрия?

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

Этап EAI восстановил это несоответствие, а затем SOA выполнила архитектурный рефакторинг, выделив функции, что привело к завершённой архитектуре.

Аналогично, BPM перенёс управление деятельностью, но в неполной архитектурной форме, что вновь привело к архитектурному разрыву. Этапы DCM и DM устранили несоответствие, выделив кейсы и правила. И вновь была восстановлена завершённость архитектуры.

Таким образом, мы наблюдаем повторяющийся паттерн, который можно интерпретировать как цикл:

• ранняя автоматизация → EAI → SOA;
• BPM → DCM и DM.

Они выглядят немного по-разному, но имеют сходную логическую структуру:

• сначала происходит перенос нового вида деятельности;
• перенос оказывается неполным и перенесённый элемент плохо масштабируется;
• несоответствие устраняется и элемент теперь масштабируется;
• достигается завершённость архитектуры.

Архитектурная завершённость означает, что переносимый вид деятельности получает адекватное архитектурное представление в системе.

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

Внутри циклов траектория движения к цели может различаться. Так, в первом цикле эти фазы явно разделены, а во втором последние две фазы объединились в одну и включали сразу две парадигмы: DCM и DM. Это связано с тем, что DCM устраняя архитектурное несоответствие, в сочетании с DM делает это сразу в завершённой форме. Так что, приведённая выше структура является логической, а не хронологической.

Внутренние этапы цикла имеют разные объекты автоматизации, что отражает логику развития цикла.

Кроме того, в обоих циклах архитектурное представление перенесённого вида деятельности изменяется по мере развёртывания паттерна, что приводит к смене парадигмы и инструментов:

• автоматизированное действие в системе -> бизнес-сервис в SOA;
• бизнес-процесс -> кейс.

Общая картина выглядит так.

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

Дадим рабочее определение цикла.

Цикл автоматизации — это процесс переноса в систему нового вида деятельности.

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

Цикл заканчивается при достижении архитектурной завершённости.

Возникает вопрос: почему цикл начинается и завершается на определённых этапах, а не на других? скажем, на соседних?

Уровни организации деятельности

Анализ объекта автоматизации не даёт ответа на этот вопрос. Это означает, что циклы нельзя объяснить только через объекты автоматизации. И если они являются устойчивой структурой, то они опираются на более глубокую форму организации деятельности, чем просто объект автоматизации.

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

Сопоставляя этапы автоматизации с предполагаемой иерархией уровней деятельности, можно получить следующую цепочку уровней, возрастающих по сложности:

Первый цикл начинается с переноса действий, а заканчивается бизнес-операцией; второй цикл начинается с переноса процесса, а заканчивается кейсом:

• 1-й цикл: действие -> операция
• 2-й цикл: процесс -> ситуация

Если эта схема верна, то можно предположить, что:

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

Теперь картина выглядит так.

Типы организации деятельности

Объекты автоматизации и уровни деятельности объясняют внутреннюю структуру циклов, но не объясняют в полной мере их границ. Поэтому требуется ещё одно измерение для классификации.

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

• уровни действия и операции (цикл 1) — автоматизируют функциональные кирпичики;
• уровни процесса и ситуации (цикл 2) — автоматизируют управление деятельностью.

В течение первого цикла сам кирпичик меняется от действия к бизнес-операции, а второго — управляющий объект меняется от процесса к кейсу (ситуация). Развивается их форма, меняется уровень деятельности, но суть остаётся той же: кирпичик и управляющий объект.

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

Можно предположить, что это изменение свойств автоматизируемой деятельности и определяет границы этапов. Назовём этот уровень классификации типом организации деятельности. Он определяет, как устанавливается соответствие между ситуацией в наличии и действием.

На основе двух описанных циклов можно выделить два типа организации деятельности.

Тогда общая схема развития автоматизации выглядит так.

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

Таким образом, по-видимому, пределы цикла определяются переносимым типом организации деятельности, а его структура — уровнем.

Гипотеза о циклах

Тогда можно выдвинуть следующую гипотезу:

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

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

Если свернуть это в краткую форму, то логическая структура цикла выглядит так:

• перенос нового уровня деятельности в систему;
• архитектурный разрыв;
• коррекция архитектурного разрыва;
• архитектурная завершённость.

Концептуальная рамка

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

Что мы теперь можем сказать об этапе агентной автоматизации? Если выдвинутая гипотеза верна, то, по всей видимости, этап агентов:

• начинает новый архитектурный цикл, поскольку предыдущий цикл (BPM, DCM, DM) завершён;
• вызван внешним давлением и изменением среды, которое сделало архитектуру предыдущего этапа неэффективной;
• переносит в систему новый уровень организации деятельности;
• вероятно, он сделает это неоптимальным образом, и за ним последуют этапы архитектурной коррекции.

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

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

Этим мы займёмся в следующей статье.