Предприятие реального времени

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

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

Конкуренция во времени

Вообще говоря, концепция конкуренции во времени (time-based competition, TBC), то есть борьба за минимизацию времени отклика на запросы клиентов и вывод новых товаров на рынок, известна уже не первый год. Но реализовать эту модель посредством компьютерной автоматизации процессов пытаются сравнительно недавно. Идея конкуренции во времени относится не только к изготовлению и дистрибуции товаров. История компании Progressive Insurance - яркий тому пример. Обращение Progressive Insurance к идеям конкуренции во времени началось более 10 лет тому назад, когда она создала группу "оперативного реагирования" - 2600 автомобилей, оборудованных ноутбуками, ПО сбора заявок о страховых случаях и беспроводным доступом, к внутренним системам компании. В большинстве компаний-конкурентов оценщики ущерба реагировали на заявления клиентов в течение семи-десяти дней, а Progressive Insurance сократила этот срок до девяти часов.

Но компания на этом не остановилась. В 1996 году Progressive Insurance предоставила клиентам возможность сравнивать цены в онлайновом режиме, а год спустя - и приобретать полисы по Интернету. В 1998 году открылся новый сайт компании, где клиенты получили возможность выполнять платежи, отслеживать состояние заявки и изменять информацию полиса. В 2001 году Progressive Insurance стала первой компанией, принимающей платежи от заказчиков по беспроводным средствам связи, в том числе через КПК и мобильные телефоны.

Результат этого постоянного наращивания инноваций налицо. Progressive Insurance увеличила свою капитализацию с 1,3 млрд в 1991 году до 13,4 млрд долларов в 2004 году. Progressive Insurance на деле доказала: как эластичность цен является мерой спроса, так и эластичность времени на обработку запросов позволяет компании перехватывать клиентов у более медлительных конкурентов на, казалось бы, давно устоявшемся рынке. Кроме того, экономя время клиента, Progressive Insurance укрепляет другое свое конкурентное преимущество - доверие, основу крепких взаимоотношений с клиентом.

Скорость модификации процессов

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

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

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

Три вопроса о реальном времени 1. Есть ли в компании четкое бизнес-видение предприятия реального времени? Есть ли цели и метрики в области ИТ, которые ориентируются на удовлетворение клиентов, эффективность цепочки поставок и другие стратегические цели, а не только на автоматизацию существующих процессов и транзакций? 2. Использует ли предприятие методики управления бизнес-процессами и BPM-системы для обеспечения гибкости и быстроты реакции на бизнес-события? Способны ли программные средства и ИТ-архитектуры должным образом обеспечить поддержку бизнес-процессов в различных подразделениях компании? 3. В состоянии ли ИТ-решения поддерживать темп изменений в процессах? Сквозные бизнес-процессы потребуют своевременной интегрированной информации на каждом этапе. Готово ли предприятие к этому?

Процессы на четвертом уровне

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

Большинство традиционных корпоративных приложений базируются на трехуровневой клиент-серверной архитектуре. Ориентированные на процессы ИТ-системы должны сформировать "четвертый уровень". Его задача - не столько учитывать данные и поддерживать большое количество отчетов, сколько реализовать бизнес-процессы реального времени. Конечно, бизнес-процессы, поддерживающие обслуживание запросов клиентов и вывод новых товаров на рынок, встроены в традиционные корпоративные системы, но они обычно "вморожены" в ERP-системы или другие приложения.

Однако бизнес-процессы четвертого уровня - это сквозные, межсистемные и кроссфункциональные процессы, которые работают непосредственно с клиентами и могут простираться далеко за границы компании. Процессы, ограниченные рамками традиционных ИТ-систем, могут представлять собой части сквозных бизнес-процессов. Но для их изменения обычно требуется много работ по программированию. С другой стороны, природа бизнес-процессов реального времени динамическая, и средства, используемые для их создания и обслуживания, должны обеспечивать быструю модификацию. Чтобы оставаться на плаву, компании постоянно инициируют новые программы и кампании. Запуск программы продвижения продукта, к примеру, требует процессов, предназначенных только для этой короткоживущей инициативы, а она обычно длится не более трех месяцев. Крупные компании могут иметь сотни или тысячи таких краткосрочных требований к процессам, вызванных к жизни насущными нуждами. Такие требования просто немыслимо реализовать, каждый раз переписывая унаследованные системы. На четвертом уровне необходимы другие ИТ-системы, например BPM-системы (business process management).

Для автоматизации бизнес-процессов предприятия реального времени могут использоваться разные технологии. Но краеугольным камнем движения в направлении реального времени становятся BPM-системы. Вся суть BPM-систем состоит в том, что они играют роль слоя, способного управлять и поддерживать динамические сквозные процессы, невзирая на границы между разными ИТ-системами. Именно это BPM привносит в процесс реального управления информацией. Ведь очевидно, что для реализации реального времени критически важно обеспечить интеграцию приложений. На предприятии реального времени унаследованные системы никуда не исчезают - они задействуются как обязательные участники создания сквозных бизнес-процессов. Наглядный пример - компания Virgin Mobile. Когда британский предприниматель Ричард Брэнсон решил расширить область деятельности Virgin Group в США за счет проникновения на рынок мобильной связи, он изменил саму суть компании мобильной связи - у новой компании не было абсолютно никакой телефонной инфраструктуры, ни одной вышки связи. Но как же всего лишь за полгода Virgin вошла в десятку ведущих американских операторов мобильной телефонии? Компания создала новый тип кооперации с Sprint PCS, взяв на себя ее телефонные услуги и интегрировав ИТ-системы, поддерживающие свои бизнес-процессы (CRM-систему Siebel и ERP-систему J.D. Edwards) с ИТ-инфраструктурой Sprint. При таком подходе унаследованные информационные системы используются для поддержки сквозных бизнес-процессов.

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

Сервисная основа

Теперь перейдем от общей архитектуры к конкретным технологиям. Общий подход основан на аналогии с деревом. Находясь ниже уровня грунта, Web-сервисы формируют корневую систему. Практически любой программный компонент может предоставляться как Web-сервис, в том числе и сервисы, заимствованные от традиционной ERP-системы. Web-сервисы могут реализовать стандартные задачи автоматизации, такие как вычисление остатка на счете или отмена заказа, снижая, таким образом, затраты и относительно просто облегчая комбинирование нескольких компонентов для достижения цели более высокого уровня, что требуется для реализации SOA (Service-Oriented Architecture).

Доступ к композитным приложениям обеспечивается по ESB-шине (Enterprise Service Bus), которая служит базой для объединения дискретных, распределенных сервисов вокруг единой асинхронной, ориентированной на сообщения инфраструктуре. Так, банк First Command Financial Planning, использовал ESB-приложение для создания слоя, обеспечивающего обмен информацией между Web-порталом банка, созданным на основе продуктов BEA, и финансовыми приложениями сторонних поставщиков на платформе IBM iSeries. В результате клиенты получили возможность просматривать состояние своего счета в реальном времени. Web-сервисы и SOA следует считать технической базой для BPM-систем, которая, в свою очередь, является двигателем предприятия реального времени.

Здесь и сейчас

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

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

Бизнес-процессы в информационной системе должны отражать динамические по своей природе бизнес-инициативы, поэтому не следует рассматривать предприятия реального времени как всего лишь более крупные конструкции, созданные из того же материала, что и системы управления транзакциями. В основе предприятия реального времени - быстротекущее, динамическое, гибкое поведение, и это отчасти может быть предоставлено именно BPM-системами. BPM-системы подобны решениям для CAD/CAM-проектирования, но по отношению к процессам - они используют технологии, не являясь их частью. Проектировщикам автомобилей, создающим новый дизайн, не нужны программисты, - они используют CAD/CAM-системы для прямого управления деталями автомобиля. Аналогичным образом и бизнес-аналитики должны обходиться без программистов при создании своих проектов, самостоятельно управляя бизнес-процессами. Их не должны ограничивать рамки процесса сбора и определения требований, которые потом будут раскладываться по полочкам технологий - BPMN, UML, BPEL, BPEL-J, WSDL, SOAP и UDDI - и затем довольно долгое время программироваться. Требования бизнес-аналитиков должны выполняться немедленно - реализовываться "здесь и сейчас", не требуя бесчисленных преобразований при перемещении через все технологические слои. Когда бухгалтер создает электронную таблицу, она не проходит весь цикл спецификаций - "требования-проект-программирование". Она просто работает.

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

Сокращение времени реакции на запросы клиентов Компании Molson Coors, одному из ведущих мировых производителей пива, потребовалось несколько лет, чтобы определиться в своем отношении к управлению бизнес-процессами и технологии BPM. Но результаты внедрения новой стратегии не заставили себя ждать — уже теперь компания сообщает о 75-процентном сокращении времени обработки заказов. Компания реализовала BPM в масштабах всего предприятия, а новый порядок оценки производительности ориентирован в первую очередь на сокращение времени процессов. До BPM-инициативы, которая увидела свет в 2000 году, Molson Coors страдала от беспорядочной фрагментации процессов по подразделениям. Одни процессs поддерживались в SAP-системе, другие — в различных унаследованных системах, и напрочь отсутствовал какой-либо план соединения вместе отдельных фрагментов этой головоломки. Больше всего в усовершенствовании процессов нуждалась цепочка поставок. «По сообщениям дистрибьюторов, мы находились в самом низу рейтинга по качеству обслуживания клиентов, особенно если речь шла об исполнении заказов и соблюдении сроков поставки, — говорит Боб Боначчи, директор по управлению бизнес-процессами Molson Coors. — Это было реальной проблемой». В попытках решить эту проблему Боб Боначчи возглавил рожденный в недрах ИТ-подразделения проект реорганизации цепочки поставки. Однако его ИТ-команда слабо взаимодействовала с бизнес-пользователями. Примерно тогда же, в июле 2001 года, в Molson Coors пришла Дебра Бойкин — бизнес-архитектор. Ее пригласили для реализации проекта по внедрению системы ARIS компании IDS Scheer и документированию и бизнес-процессов. Однако поначалу руководство компании не видело необходимости координировать эти два проекта. «Я практически самостоятельно пыталась реализовать подход «сверху вниз», в то время как Боб со своей командой двигался в направлении снизу вверх. Бизнес-пользователи не знали, чего ожидать от проектов, — объясняет Дебра Бойкин. — Подходы никак не стыковались». К началу 2003 года оба топ-менеджера вышли с инициативой создания модели общих бизнес-процессов, поэтому команда Дебры Бойкин присоединилась к группе Боба Боначчи, и вскоре они приступили к созданию всеобъемлющей ИТ-архитектуры для реализации сквозных процессов, охватывающих отделы менеджмента, маркетинга, продаж, поставок и оперативного управления. В качестве языка моделирования и описания процессов был выбран язык XBML (Extended Business Modeling Language) компании BusinessGenetics. «XBML помог нам общаться и связывать процессы с потребностями бизнеса», — говорит Боб Боначчи. Работая с ответственными за процессы и экспертами в предметной области со стороны бизнес-подразделений, команда смогла четко описать связанные с процессами операции, временные рамки, места, роли, информацию и потоки. Первый реализованный проект запустили в сентябре 2003 года — это был новый процесс цепочки поставок. По словам Боба Боначчи, на стабилизацию потребовалось полгода, но уровень обслуживания клиентов возрос несоизмеримо. «До внедрения нового процесса дистрибьюторам приходилось заказывать товар за четыре недели вперед. Теперь достаточно разместить заказ за неделю до поставки», — говорит Боб Боначчи. Короткий срок поставки товара важен, так как теперь Molson Coors может синхронизировать поставки с маркетинговыми кампаниями и местными мероприятиями, например массовыми спортивными соревнованиями. Сейчас в самом разгаре разработка процессов в маркетинговом и производственном отделах, а в отделах управления и продаж только начинается этап документирования и моделирования. На следующем этапе планируется развернуть модуль ARIS Process Performance Manager (PPM) компании и SAP NetWeaver. PPM обеспечит поддержку ключевых показателей производительности процесса, а NetWeaver будет использоваться для мониторинга, конфигурирования, контроля и реализации бизнес-процессов. Совершенствование управления процессами и непрерывное сокращение временных циклов позволит компании, по словам Дебры Бойкин, «приблизиться к модели предприятия реального времени».

К веку процессов

Как электронные таблицы используют сами пользователи без участия ИТ-специалистов, так же и BPM-системы должны использоваться бизнес-аналитиками без посторонней помощи. Но одной возможности быстро реализовывать уникальные бизнес-процессы, отличающие компанию от конкурентов, недостаточно. Об этом Progressive Insurance узнала на собственном опыте - когда стала конкурировать в области минимизации времени. Компания продолжает вводить инновации, сокращающие время процессов, и это приводит в восторг ее клиентов. Но чем дальше, тем больше встречает трудностей. Если использовать общепринятые методы разработки ПО, даже если задействовать ориентированные на сервисы методики, скоро во всем мире не найдется достаточно программистов, чтобы спроектировать и запрограммировать ориентированные на процессы системы.

Гибкие и быстрые процессы нуждаются в собственной архитектуре и парадигме, и парадигма ИТ-систем, ориентированных на данные, здесь не работает. Чтобы создать предприятие реального времени, недостаточно одной только технической SOA-архитектуры - нужна ориентированная на процессы POA-архитектура (process oriented architecture). То есть то, что специалист по бизнес-методикам Мартин Ульд описывает как архитектуру, ориентированную на "единицы работы", а не на "единицы технологии". POA - это черновая идея. По отношению к BPM-системе она является тем же, что SOA представляет собой по отношению к ESB. ИТ-архитекторы считают единицами работы дискретные транзакции - бизнес-архитекторы мыслят в терминах наборов процессов, объединенных для решения поставленных задач и предоставления новых возможностей клиентам. CIO предприятия пора обозначать единицы работы в терминах бизнеса. Разработчики программ годами использовали диаграммы на языке UML для определения и проектирования ПО. Но UML не хватает бизнес-семантики, ведь этот язык сферы разработки ПО, а не мира моделирования бизнес-процессов, для которого, вообще говоря, этот язык и никогда и не предназначался.

Мартин Ульд пишет в свой последней книге "Управление бизнес-процессами: строгий подход" (Business Process Management: A Rigorous Approach): "Нынешний верный последователь текущей моды в разработке ИТ-систем скорее всего будет общаться с бизнесом на языке UML и использовать один из многих подходов к разработке, основанных на UML. Однако я не согласен считать BPM-системы всего лишь еще одним видом ИТ-систем". Ведь ориентированные на информацию языки и методы разработки развивались в направлении сохранения, поиска и изменения информации, но не динамического мира процессов. "Мы движемся от века информации к веку процессов, - пишет далее Мартин Ульд. - Нам нужны специально созданные для работы с процессами методы, чтобы заменить существующие способы работы с информацией".

***

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

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

Три шага к реальному времени 1. Разработайте полное бизнес-представление процессов компании. Топ-менеджмент, бизнес-аналитики и ИТ-архитекторы должны видеть лес, а не отдельные деревья - это позволит лучше понимать, как устранять временные препятствия на пути к динамическому, активному поведению компании. 2. Воспользуйтесь основанным на SOA и XML подходом к интеграции. Если на пути к интеграции приложений и данных потребуется слишком много усилий на преодоление границ частных решений, подумайте об использовании отраслевых стандартов. 3. Ориентируйте доработку ПО на процессы. BPM-системы не только являются продолжением традиционного стека корпоративных приложений - они должны находиться на другом уровне, ближе к бизнес-стратегии. Разработчики должны понимать это различие, чтобы моделировать и строить открытые сквозные процессы, которые обеспечивают ведение бизнеса в реальном времени.