Отсутствие теоретических работ, в которых исследуются проблемы создания корпоративных информационных систем, восполняется многочисленными методиками. Среди них «предприятие с нулевой задержкой», «предприятие реального времени», «предприятие, управляемое событиями», а также так называемый «мониторинг бизнес-процессов», или Business Activity Monitoring.

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

Отсутствие целостного видения не удивительно: это вполне типично для многих инженерных дисциплин на определенных этапах их развития. В инженерии — в отличие от научных дисциплин, которые исследуют явления, уже существующие в природе или обществе, — сначала нужно создать что-то новое, пройти тернистый путь экспериментов, переосмыслить и исследовать созданное, а уж потом применить новое знание на практике. Можно провести аналогию между кризисом доткомов и созданием кораблей, не способных плавать («Титаник»), и самолетов, не способных летать (Hughes XF-11 Ховарда Хьюза и построенный А.Н. Туполевым АНТ-20 «Максим Горький»).

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

Еще одну интересную метафору предложил Дэвид Лукхэм. Проблему целостного взгляда можно рассматривать с помощью введенного им броского термина «слепота ИТ» (IT blindness). В оригинале он трактуется как неспособность существующих технологий «увидеть» и оценить реальные процессы в той среде, в которую включена информационная система. Но данный термин допустимо интерпретировать и иначе — как неспособность увидеть, как из отдельных технологий может быть собрана целостная система управления.

Здесь впору вспомнить известную притчу о слоне и слепцах. Что делать в тех ситуациях, когда есть слон, но нет наблюдателя? Тогда-то и возникает проблема сборки из отдельных фрагментов того самого слона — единой системы управления предприятием. Как к панацее, сейчас обратились к сервис-ориентированным архитектурам (Service-Oriented Architecture), но SOA — всего лишь сумма технологий, обеспечивающих удобство интеграции приложений. А подходом, который действительно избавит ИТ от слепоты, может оказаться мониторинг бизнес-процессов (Business Activity Monitoring, BAM).

Gartner о BAM

Парадоксально, но факт: в условиях неопределенности, которая порождена «слепотой ИТ» и в которой еще не ясен способ сборки отдельных компонентов в корпоративные информационные системы, в роли провидцев и визионеров чаще всего выступают отнюдь не ученые, а отраслевые аналитики. Именно они предлагают новые обобщения и названия для них. Так, популярный ныне подход к архитектуре предприятия, основанный на учете происходящих событий (Event Driven Architecture, EDA), предложил Рой Шульте, аналитик Gartner. Соответствующий документ опубликован 9 июля 2003 года под длинным названием «Повышение значимости событий для интеграции приложений. В будущем приложения станут в большей степени управляться событиями, чем ныне. Пять движущих сил». Этот документ неожиданно быстро оказался в списке самых цитируемых работ по интеграции приложений, а его автор получил широкую известность среди специалистов. Шульте утверждает, что бизнес начнет использовать EDA в период с 2004-го по 2008 год, поскольку существующие технологии интеграции приложений, практически игнорирующие события, перестают соответствовать требованиям бизнеса.

У другой трехбуквенной аббревиатуры, BAM, тоже имеется точно датируемый день рождения — 1 апреля 2002 года. В этот особый день календаря вышло информационное письмо Gartner, озаглавленное «Мониторинг деятельности бизнеса: затишье перед бурей» (Business Activity Monitoring: Calm Before the Storm). С тех пор BAM прочно ассоциируется с редактором этого документа, вице-президентом Gartner Дэвидом Маккоем. EDA и BAM — это попытки приближения информационных систем к требованиям реально действующих предприятий. А авторы этих попыток нехотя, не называя их прямо, но все же приближаются к кибернетическим подходам к управлению.

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

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

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

В Gartner считают, что с 2004 года BAM превращается в одну из четырех основных движущих сил, способствующих приливу инвестиций в ИТ. Это возможно потому, что BAM может объединить в дееспособную систему такие не связанные между собой и не способные к взаимодействию приложения, как Customer Relationship Management (CRM), Supply Chain Management (SCM), Enterprise Resource Planning (ERP) и Business Process Management (BPM). В результате деления процессов на отдельные приложения не удается сформировать единый взгляд на события, происходящие на предприятии.

Перегруженность современных информационных систем фактами и данными вступает в противоречие с неспособностью к их интерпретации, что ярко продемонстрировали события 11 сентября 2001 года. Тогда спецслужбы имели на руках всю информацию, но не смогли ею воспользоваться. Из материалов Gartner: «Для построения эффективной системы BAM понадобится создать комбинацию данных, поступающих в режиме реального времени, и накопленных (исторических) сведений. Решение этой задачи потребует интеграции разнородной информации, источниками которой могут быть хранилища данных (data warehouse), хранилища оперативных сведений (operational data store) и базы данных приложений (application database). Следует опасаться тех вендоров, которые предлагают безразмерные решения ?из одной коробки?».

Необходимый комментарий

Я на протяжении многих лет размышлял о неизбежном идеологическом сближении систем управления, которые используются в бизнесе, с человеко-машинными системами, которые применяются для управления сложными техническими объектами. Принципы управления системами являются общими независимо от того, будь то технические, биологические или экономические системы. Правда, сложность экономических систем долгое время не позволяла выйти на тот уровень управляемости, который оказался легко достижимым в технике, а потому сложилось условное разделения на два лагеря. Однако рано или поздно, по мере развития поддерживающих управление технологий, начнется конвергенции систем двух типов. Сегодня еще трудно представить себе крупных администраторов (CEO, CFO, CKO, CIO...), сидящих перед специализированными экранами примерно так же, как операторы сложных технических систем, например, Центра управления полетами космических аппаратов. Но дело явно идет к тому [1]. Жизнь показывает, что обоснованная фантазия имеет полное право на существование и нередко реализуется раньше, чем это можно было предположить. Для изменений сложились необходимые и достаточные условия. При этом достаточным условием является уровень развития современных ИТ, а необходимым условием — изменившиеся требования со стороны бизнеса, которому служат системы управления. Результатом нового эволюционного витка могут стать системы, способные проводить мониторинг бизнес-процессов.

BAM и BI

Среди множества определений BAM, данных Gartner, можно найти и такое: «В самом широком смысле BAM можно рассматривать как конвергенцию бизнес-аналитики (Business Intelligence, BI) и интеграции приложений, выполняемых в режиме реального времени».

Действительно, самую простую интерпретацию BAM можно свести к утверждению «BAM — это BI, но в реальном времени». Чуть более сложная формулировка такова: «Концепция BAM — это BI, отражающая события, которые происходят в режиме реального времени, то есть некоторая смесь BI и EDA».

Системы класса BI (рис. 1) обычно состоят из ETL-сервера, который выполняет извлечение (extract), преобразование (transform) и загрузку (load) данных в хранилище, аналитических инструментов и средств отображения. Исторически первыми были технологии оперативной аналитической обработки (Online Analytical Processing, OLAP). Позже появились средства оценки производительности (performance management), позволяющие сравнивать фактические показатели бизнеса с прогнозировавшимися; на основе этого сравнения можно осуществлять управление, поэтому в название включено слово «менеджмент». Средства бизнес-аналитики позволяют создавать своего рода интеллектуальные учетные системы (actionable intelligence), результатом деятельности которых являются приспособленные для анализа формы представления данных (drillable scorecards). Можно также задавать правила сравнения желаемых и реальных результатов и в случае расхождения вырабатывать «сигналы тревоги». Помимо средств, предназначенных для реакции на уже случившиеся события, системы бизнес-аналитики включают в себя средства прогноза, которые позволяют работать на опережение.

При всех достоинствах BI, которые задействуют классические хранилища данных, они имеют существенный недостаток — статичность. В основном они пригодны для анализа данных, обеспечивающего принятие решений на тактическом уровне. Но если требуется более оперативная работа, дополнительно могут быть использованы хранилища оперативной информации (Operational Data Store, ODS), которые можно представить как буферную или кэш-память, расположенную перед хранилищем данных. ODS предназначены для хранения небольших фрагментов короткоживущих данных и могут обновляться с периодичностью одни сутки.

Рис. 2. Схема BAM

Мониторинг активности бизнеса можно рассматривать как следующий эволюционный шаг в развитии средств бизнес-аналитики, увеличивающий оперативность этой технологии. Поэтому и технологию BAM схематично можно представить (рис. 2) почти так же, как бизнес-аналитику, но с тем существенным отличием, что здесь появляется новый элемент — хранилище данных реального времени (Real-Time Store, RTS). Оно может захватывать события, которые происходят в аппаратном обеспечении и приложениях, и другие данные, непосредственно связанные с течением бизнес-процессов. Сервер BAM хранит эти данные в кэш-памяти и делает их доступными для аналитических инструментов и средств подготовки отчетов. Такая интерпретация идей BAM имеет право на существование, но является далеко не единственно возможной. Более того, она настолько упрощена, что ее можно рассматривать как иллюстрацию концепции BAM. Предпосылки к BAM можно найти в обработке сложных событий (Complex Event Processing, CEP) и в архитектурах, стимулированных событиями (Event Driven Architecture, EDA).

BAM и сложные события

В рассуждениях о BAM обычно упускается из виду то, что сами системы управления предприятиями и условия, в которых они работают, логически на порядки сложнее самых сложных технических систем. Основными причинами сложности являются огромный объем данных и сложность выделения в этом объеме того, что на самом деле является событием. Наивные представления о возможности автоматизировать управление предприятием или осуществлять мониторинг лишь на основании сведений, получаемых от индикаторов производительности (KPI) или из хранилища данных реального времени, не подтверждаются достоверной оценкой реальных объемов и свойств данных, которые могут поступать от объекта управления. Тем не менее подобных взглядов придерживаются немало аналитиков. К числу тех немногих, кто осознает сложность задачи и аргументированно говорит на эту тему, можно отнести профессора Стэндфордского университета Дэвида Лукхэма [2].

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

Чтобы оценить «размер бедствия», требуется классифицировать события, их источники и средства работы с ними.

  1. Единичные важные события. Такого рода события (например, аварийные сигналы) действительно могут поступать от выделенных датчиков KPI или в форме какого-то документа. Для их обработки может быть подготовлен специализированный инструмент, действующий по заранее определенным планам и правилам.
  2. Вычисляемые события, поступающие в режиме реального времени. Это означает, что есть детерминированный источник данных, снабженный датчиком KPI, и что данные могут быть измерены, обработаны и без излишних проблем представлены в графической форме.
  3. Потоковые случайные события. Сведения о таких событиях поступают в режиме реального времени, причем их номенклатура заранее известна, но время поступления неопределенно. Например, это могут быть сведения, поступающие с фондовой биржи, которые нельзя непосредственно, в исходном виде, рассматривать как показатели деятельности предприятия. При их анализе необходимо установить соответствие между событием и вызвавшей его причиной. Следовательно, инструмент, работающий с ними, должен уметь работать и с потоками, и с достаточно простыми образами, выделяемыми из входного «облака».
  4. Сложные события, предполагающие существование известного образа. Поток единичных событий может складываться в такое сложное событие, образ которого заранее известен. Образ сложного события состоит не только из простых событий, но и из связей между ними. Инструмент должен выбрать из «облака» этот образ, то есть решить в режиме реального времени задачу распознавания образа и предпринять соответствующие действия.
  5. Формирование образов событий. Высший уровень работы с событиями состоит в том, чтобы в случайном потоке сообщений усматривать факты возникновения новых событий. Пока это в основном удается делать лишь человеку, в чем, собственно, и состоит искусство управления.

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

BAM и корпоративные пульты управления

В последние годы начал формироваться рынок корпоративных пультов управления (enterprise dashboard). Их основными поставщиками являются компании, работающие в области бизнес-аналитики. Это в первую очередь Business Objects, Cognos, Hyperion и Micro-Strategy. Близкие задачи решают нишевые игроки, специализирующиеся исключительно на пультовых решения и не привязанные к определенной бизнес-технологии, в том числе iViz Group, iDashboards, Noetix, QPR Software и Theoris.

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

  • Рост объемов обрабатываемых данных. Опыт показывает, что закономерность, отмеченная Муром в приложении к возрастанию числа транзисторов на подложке, вполне применима к росту количества обрабатываемых данных.
  • Качественное изменение состава данных. По мере сближения технологий с управлением бизнесом изменяется состав данных и возникает необходимость участия человека в работе с этими данными. Данные можно разделить на три категории: традиционные табличные, ради работы с которыми были созданы реляционные СУБД; данные, подготавливаемые системами последнего десятилетия (CRM, ERP и им подобные); данные от систем управления бизнес-процессам (BPM), систем мониторинга деятельности предприятий (BAM) и систем электронной коммерции. Статистика показывает, что заметный количественный рост наблюдается в последней категории данных.
  • Изменение состава специалистов, работающих с данными. С данными первой категории обычно работают исполнители нижнего уровня, со второй категорией — менеджеры среднего звена, а с «новыми» данными — представители элитной группы, принимающей решения.
  • Переход к работе в режиме реального времени. Термин «реальное время» был атрибутом технических систем, но в последние годы создание корпоративных систем реального времени стало одной из наиболее обсуждаемых тем. А при необходимости управлять в режиме реального времени возникает и необходимость в пультах управления.

Удивительно, что идея применения пультов для управления бизнесом была озвучена не техническим специалистами, а теоретиками менеджмента Робертом Капланом и Дэвидом Нортоном — авторами методологии стратегического управления Balanced Scorecard. Эта методология наряду с другими подходами направлена на реализацию концепции Business Performance Management, конечная цель которой состоит в объединение стратегии организации и системы показателей в единую систему управления.

Каплан и Нортон нашли следующую незамысловатую аналогию: «Индикаторы, которые расположены перед пилотом в кабине, дают ему полный объем информации, необходимой для управления самолетом. Индикаторы сохраняются даже в самых современных машинах, хотя существуют наземные средства навигации, облегчающие процесс управления. Почему же мы считаем, что менеджерам, управляющим предприятием, для принятия решений не требуется аналогичный инструментарий? А ведь условия, в которых они работают, гораздо менее определенны, управлять предприятием не проще, чем летательным аппаратом, и у них нет наземной системы навигации. Менеджеры, как пилоты, нуждаются в приборах, информирующих о состоянии среды, параметрах производительности и других показателях деятельности вверенного им объекта».

Специфика управления в бизнесе определяется иным подходом к оценке актуальности данных. В технических системах выбор управляющих воздействий на технические объекты чаще всего соответствует показаниям приборов на текущий момент. Здесь в полном смысле можно говорить о реальном времени, а в системах управления бизнесом, даже работающих в режиме реального времени, текущих данных может не хватать для принятия решений. Порой имеет значение история данных, а кроме того, может возникать необходимость в анализе их динамики, в уточнениях и еще какие-то нюансах, а потому пульты должны быть более интеллектуальными. Для обозначения качеств «пультов управления бизнесом» используется акроним IMPACT, составленный из первых букв следующих слов.

  • Interactive («интерактивность»). Необходимо прослеживать изменение какого-то параметра во времени. Если бы, например, подобную возможность имел пилот, то, обнаружив пониженный уровень топлива, он сумел бы построить график потребления и обнаружить момент начала утечки.
  • More data history («более глубокая история данных»). Учет такого показателя, как курс акций, может потребовать анализа данных за год или даже больший период.
  • Personalized («персонализация»). Пульт должен быть «открыт» для адаптации к требованиям и ограничениям того или иного исполнителя.
  • Analytical («аналитика»). Пульт должен позволять исследовать изменения показателя в альтернативных условиях (анализ типа «что — если»).
  • Collaborative («коллаборативность»). Должна быть предусмотрена для обеспечения совместной работы пользователей, находящихся за разными пультами.
  • Trackability («сохранение следов»). Пользователь должен иметь возможность выбора режимов для сохранения необходимых параметров и управляющих воздействий.

Для того чтобы снабжать пользователей полезной информацией, бизнес-пульты, как и технические пульты, должны получать сведения от датчиков, которые в данном случае называют «ключевыми индикаторами производительности» (Key Performance Indicator, KPI). Те же Нортон и Каплан сравнивают KPI с установленными на самолете датчиками скорости, высоты полета, состояния атмосферы, местоположения и т.д. Однако подобная аналогия не вполне правомочна. Даже в сложных технических системах вывод на операторские пульты всех контролируемых физических параметров приводит к перегрузке операторов.

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

BAM + BPM = управляемая система

Если перевести то, что сейчас происходит в области систем управления бизнесом, в термины теории автоматического управления, то сложится картина, внушающая определенный оптимизм. Многочисленные и, казалось бы, разрозненные технологии выстраиваются в единую вполне жизнеспособную схему. Прежде всего, это относится к BPM и BAM, а архитектура SOA, язык BPEL, корпоративная сервисная шина, архитектура «предприятий реального времени», обработка сложных событий и другие методики играют роль поддержки.

С одной стороны, BPM можно рассматривать как философию менеджмента, позволяющую сфокусировать внимание на процессах и производительности выполнения процессов. С другой (при переходе на более низкий уровень, приближенный к ИТ), можно сказать, что это — набор методов и средств для более эффективной организации бизнес-процессов. Обзор подходов, отражающих первую точку зрения, с достаточной полнотой представлен в [3]. Попытка представить технологический аспект BPM была предпринята в [4].

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

Литература
  1. Леонид Черняк, «На пути к предприятию, управляемому в реальном времени». «Открытые Системы», 2002, № 12.
  2. Леонид Черняк, «Сложные события и мониторинг бизнеса». «Открытые системы», 2005, № 2.
  3. John Vinturella, Anthony Patti, Business Process Management (BPM): Must Have? www.jbv.com/mb/mb-BPM.doc.
  4. Леонид Черняк, «BPM: близкие перспективы и далекие горизонты». «Открытые системы», 2004, № 11.