Plug-and-play в бизнес-процессах

Требования по повышению конкурентных преимуществ компании противоречат проблемам, создаваемым унаследованными приложениями, сложными для интеграции, особенно если речь идет о сквозных бизнес-процессах. На выручку приходит SOA. Ориентированные на сервисы решения помогли компаниям Owens & Minor, TransUnion, Pfizer и MasterBrand Cabinets построить новые бизнес-процессы быстро и с небольшими затратами.

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

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

Ориентированная на сервисы архитектура (Service-Oriented Architecture, SOA), в основе которой лежат слабосвязанные программные компоненты, использующие стандартизированные интерфейсы Web-сервисов, должна позволить упростить интеграцию приложений и управление процессами. Ориентированный на сервисы подход можно использовать для компоновки новых процессов, которые можно изменять, не модифицируя код и не волнуясь о возможной несовместимости платформ. "Если вам нужны более гибкие, адаптивные бизнес-процессы, перенесите свои ИТ-приложения в SOA-архитектуру", - советует Джанелл Хилл, аналитик из Meta Group. Но так ли это на самом деле?

Быстрота и гибкость

На момент своего появления в конце 1990-х термин "Web-сервисы" вызывал определенное непонимание. Многие полагали, что речь идет о предоставлении бизнес-сервисов через Web. А на самом деле этот термин означал распределенные прикладные компоненты, основанные на Web-технологиях. Основная идея Web-сервисов заключается в предоставлении компаниям возможности собирать новые решения, используя приложения из различных источников. Предполагалось, что по мере необходимости новые компоненты-сервисы можно будет находить в Интернете, используя язык WSDL для их описания, UDDI (Universal Description, Discovery and Integration) - для поиска и SOAP (Simple Object Access Protocol) - для связи, а также расширяемый XML для "склеивания" всего этого в единое решение.

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

В Owens & Minor, компании-дистрибьюторе медицинских и хирургических инструментов, ориентировались в первую очередь на модернизацию ИТ-среды, когда затевали 4-летний проект преобразования корпоративной информационной инфраструктуры в SOA. Как говорит Дэвид Гузмен, старший вице-президент и ИТ-директор компании, проект инициировали из-за того, что в унаследованных приложениях, созданных с использованием технологий 70-х и 80-х, было очень сложно что-либо менять, а компании потребовалось добавить новые бизнес-сервисы, такие как управление цепочками поставок и комплектация персоналом локальных офисов.

В компании изучали возможность установки ERP-решения, но Дэвид Гузман и другие руководители знали, что копирование нестандартных функций унаследованных приложений потребует огромных усилий. Руководство предпочло использовать решение для модернизации ПО компании Relativity, которое позволяло анализировать унаследованный код, выявляя основные бизнес-правила, и помогало перестроить архитектуру ПО в виде сетевых сервисов. Проект завершился в 2004 году, теперь сервисы работают на серверах приложений BEA.

В ходе SOA-проекта в Owens & Minor увидели, что в результате получалась не просто современная корпоративная архитектура, но многоуровневая, компонентноориентированная среда, которая позволяла усовершенствовать процессы. И руководство занялось поисками инструмента, который позволил бы увязывать такие компоненты. В начале 2004 года Owens & Minor остановила свой выбор на BPM-решении компании Fuego. Выбор поставщика, утверждает Дэвид Гузмен, обусловлен способностью решения построить процессы, создать интеграционный код и обеспечить мониторинг автоматизированных процессов.

Сначала BPM-решение задействовали для двух некритически важных процессов и еще для одного процесса, такого плохого, по словам Дэвида Гузмена, что сотрудники были готовы на любые перемены. Этот третий процесс назывался "процедура дебетования" и предусматривал удаление со складов устаревших продуктов и, если возможно, возвращение их производителям в зачет будущих поставок. Внедренное ранее решение от Manugistics для управления цепочкой поставок создавало отчет о складских запасах с указанием товаров, срок которых истекал. Отчет направлялся на все 42 склада компании, где сотрудники вручную находили устаревший товар, связывались со штаб-квартирой, чтобы узнать политику возврата конкретных производителей и выяснить, какие товары можно возвратить. Затем сотрудники обращались к производителям за разрешением вернуть товар, создавали распоряжения на возврат в отдельной системе управления складом и уведомляли о зачете бухгалтеров, ответственных за кредиторскую задолженность.

Анализ унаследованных сервисов позволил Owens & Minor создать новую процедуру дебетования меньше чем за месяц. Теперь BPM-cистема Fuego получает отчет о складских запасах и, используя систему правил, в котором уже содержится информация о политике возврата всех производителей, создает список с указанием приоритетов для сотрудников склада. Механизм управления процессом автоматически генерирует сообщения электронной почты в адрес производителей с запросом на возврат, создает распоряжения на отгрузку, уведомляет отдел кредиторской задолженности и отслеживает сообщения о кредите. Сотрудникам склада нужно всего лишь найти нужные товары и организовать поставку.

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

SOA и BPM-системы, которые отлично вписались в архитектуру, помогли Owens & Minor быстро автоматизировать все три целевых процесса. "Ключевое преимущество - скорость", - говорит Дэвид Гузмен. Четыре года назад подобный проект занял бы девять месяцев - теперь на него затратили всего три недели.

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

До проекта в TransUnion работала workflow-система для управления различными требованиями к собираемым данным. Однако, она располагалась на мэйнфрейме и не позволяла компании воспользоваться ориентированной на сервисы структурой нижележащих приложений. "С точки зрения архитектуры наш бизнес всегда строился по централизованной модели, - говорит Ричард Е. Карлберг, вице-президент и ИТ-директор TransUnion. - Проблема в том, что возможности "центра" ограничены".

В начале 2004 года в компании развернули BPM-решение BusinessManager компании Savvion, которое сегодня служит магистралью и базой обработки практически всей бизнес-информации TransUnion. "Это дает нам возможность быстро подключать новые сервисы, практически по механизму plug-and-play, - говорит Ричард Карлберг. - Я могу добавлять и удалять сервисы, не нарушая работы всей инфраструктуры".

На внедрение BPM ушло полгода. TransUnion использовала обе системы параллельно, чтобы проверить на прочность новые системы и минимизировать риски прежде, чем вывести из строя старую workflow-систему. Ричард Карлберг утверждает, что инвестиции окупаются, хотя и не называет конкретных цифр. Способность быстро развертывать новые кредитные продукты - самое большое преимущество SOA-архитектуры и BPM-системы, развернутой в TransUnion. "Лишь за один месяц мы добавили примерно десять новых продуктов, что было невозможно в старой системе, - комментирует Ричард Карлберг . - На это потребовались бы многие месяцы".

Ускорение исполнения заказов в Sappi Fine Paper Когда вы производите 1,3 млн. тонн мелованной бумаги в год, вам требуется очень серьезная система управления и исполнения заказов. Два года назад в североамериканском отделении компании Sappi Fine Papers использовали конгломерат из "доморощенных" приложений и работающего на мэйнфрейме унаследованного ПО, чтобы справляться со спросом на свои продукты. Клиенты Sappi - это дистрибьюторы бумаги. Чтобы сохранить конкурентные преимущества, в 2002 году компания повысила уровень сервиса, гарантировав поставку на следующий день после заказа. Это далось непросто, так как из-за несогласованности EDI-форматов требовался повторный ручной ввод многих заказов. Дополнительно усложняло ситуацию то, что Sappi планировала перевести свои четыре американских завода с унаследованных приложений на мэйнфреймах на SAP R/3. Решив использовать Web-сервисы для интеграции и управления процессами, руководство североамериканского отделения Sappi выбрало продукт Gentran Integration Suite компании Sterling Commerce, чтобы построить сквозной процесс управления заказами и снизить затраты на внедрение SAP R/3. В первом, пробном проекте, призванном проверить верность выбранного курса, в конце 2002 года были созданы сервисы, поддерживающие управление всеми процессами заказа на пополнение, складскими запасами и заказами от клиентов в четырех региональных центрах дистрибуции и на одном складе. Проект завершился в I квартале 2003 года, и к июню еще три склада компании были подключены к дистрибутивным центрам. Были созданы отдельные сервисы для решения каждой из задач - от преобразования данных и обработки ошибок до эскалации заказов. Далее эти сервисы были собраны в законченный сквозной процесс. "До того как что-либо предпринять, мы создаем карту процессов, и все, что мы делаем, управляется посредством моделей бизнес-процессов", - говорит Марджори Боулс, менеджер по системной интеграции Sappi. Новый процесс управления заказами сокращает почти на 40% время поддержки клиентов за счет наличия более полной информации, в том числе инструкции по обработке, в самом заказе. К августу 2003 года были созданы сервисы, призванные решить проблему с несогласованностью EDI-форматов и устранить дорогостоящую и отнимающую много времени работу по вводу данных, а также ставший ненужным EDI-сервер, на обслуживание которого уходило 40 тыс. долл. в год. Но самое важное то, что время обработки заказа сократилось на 30-45 минут. "Это дало нам возможность сместить время окончания приема заказов с 15:30 на 16:00, и это существенно, так как большинство заказов приходит в последние два часа рабочего дня", - комментирует Марджори Боулс. ПО Gentran Integration Suite помогло Sappi быстро увязать унаследованные системы с SAP R/3 и подключить другие приложения, избежав существенного программирования в R/3. "Отчет по выверке, который дал нашим пользователям именно то, что требовалось, сделал один человек за две недели, - говорит Марджори Боулс. - На решение аналогичной задачи в SAP R/3 потребовались бы двухмесячные усилия целой команды разработчиков, так как пришлось бы извлекать данные из множества различных модулей".

Повторное использование

Возможность повторного использования Web-сервисов во многих процессах - еще одно преимущество SOA в BPM-инициативах. Эту истину открыл для себя гигант фармацевтической промышленности Pfizer. Три года назад в Pfizer стартовал проект модернизации корпоративной ИТ-архитектуры. Как и в Owens & Minor, в компании позже распознали преимущества объединения готовых сервисных компонентов для управления бизнес-процессами.

В начале прошлого года в Pfizer внедрили BPM-решение TeamWorks компании Lombardi. Главная цель состояла в улучшении неэффективного процесса поощрения сотрудников. Выездные менеджеры по продажам - всего их 13 тыс. человек - обычно использовали электронную почту для отправки сообщений в систему расчета компенсаций и стимулирования. Процесс занимал целый месяц, и сотрудникам приходилось часто справляться о состоянии расчетов с компанией. Не было никакого способа проследить путь отдельных отчетов, чтобы выяснить, какие из них прошли одобрение.

Используя TeamWorks, в Pfizer создали карту процесса, определили этапы, поддающиеся автоматизации, создали сервис, отвечающий за маршрутизацию, и организовали интеграцию с базовой системой расчета вознаграждений и хранилищем документов. "Создав отчет о компенсации, система сразу направляет его на одобрение, прослеживая состояние отчета на всем пути до конечного состояния, - говорит Род Эколс, старший архитектор Pfizer. - Выездные менеджеры по продажам теперь удовлетворены, поскольку получают вознаграждение быстрее, а ошибок при этом случается меньше. Это хороший стимул для сотрудников, которые самым непосредственным образом влияют на доходы компании". Проект занял меньше трех месяцев, а продолжительность процесса сократилась до одной недели.

Pfizer планирует задействовать тот же сервис маршрутизации в других процессах, таких как корпоративные процедуры одобрения образовательных и поощрительных грантов. "Мы можем повторно использовать один набор Web-сервисов при появлении новых приложений", - говорит Абди Одей, другой старший архитектор компании.

Повторное использование компонентов приложений - далеко не новая концепция в ИТ, но в прошлом использовался плохо задокументированный процесс подключения повторно используемых компонентов. "В результате часто оказывалось, что один и тот же отрезок кода, слегка модифицированный "по месту", работал в разных местах, - говорит Дэвид Гузман из Owens & Minor. - Когда требовалось обновление, приходилось находить все экземпляры такого кода". Подобное обновление занимало значительное время и представляло определенный риск.

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

Хотя унаследованные системы управления заказами были разъединены, каждая решала поставленную перед ней задачу, объясняет Дэвид Мьюэс, вице-президент и ИТ-директор MasterBrand. "Мы не хотели переходить на ERP-систему, а стремились извлечь данные о заказах и задействовать их в одном процессе, отдельном от приложений, - говорит Дэвид Мьюэс. - Наши конкуренты развернули у себя ERP-решение, полностью удалив старые системы, и это отрицательно сказалось на производительности, скорости обработки заказов и всем бизнесе. Мы не хотели так рисковать".

Проектная команда MasterBrand использовала решение интеграции бизнес-процессов компании Vitria для создания архитектуры, которая в конечном счете смогла бы обеспечить поддержку клиентов и цепочки поставок, в том числе управление заказами. Выбрав, как выразился Дэвид Мьюэс, "неагрессивный" подход, команда использовала Web-сервисы для предоставления и интеграции пяти независимых систем обработки заказов. Поскольку такой подход предусматривал изменение архитектуры унаследованных программ, а не простое добавление BPM-решения в существующую SOA-архитектуру, проект занял десять месяцев. К концу года MasterBrand развернула, как в компании это назвали, систему "одного касания", которая обеспечивала единую точку ввода и исполнения заказов. В результате клиенты взаимодействуют только с одним менеджером независимо от числа и ассортимента заказанных продуктов. Менеджеры используют единую Web-систему управления заказами. Она станет основой портала самообслуживания для клиентов, который сейчас разрабатывается в компании.

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

Сложности

Однако, не думайте, что создание полноценного SOA-решения дается быстро и дешево. Owens & Minor, TransUnion, Pfizer и MasterBrand - все они успешно внедрили BPM-решения за считанные месяцы, но постоянная работа над SOA продолжалась годы. Дэвид Гузмен из Owens & Minor говорит, что альтернативное решение, предусматривающее удаление унаследованных систем и переход на ERP-систему, "было бы намного дороже". О каких суммах идет речь? Согласно данным BPM-поставщика Relativity, компании, относящиеся к списку Fortune 500, обычно тратят 400 тыс. долл. на внедрение 50-пользовательской версии ПО Modernization Workbench, а крупные SOA-проекты с привлечением системных интеграторов обычно "стоят" от 1,5 до 2 миллионов. С другой стороны, в соответствии результатами исследования Delphi Group за 2003 год, затраты на BPM-проекты составляют в среднем 300 тыс. долл.

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

"Есть вещь, которую я бы сделал по-другому, - предоставил больше времени на передачу знаний от консультантов сотрудникам ИТ-отдела, - добавляет Дэвид Мьюэс из MasterBrand. - Мы все еще зависим от внешних ресурсов, если речь идет о разработке нашей инфраструктуры".

***

SOA выгодно не только в применении к BPM, но и в управлении данными, торговле и порталах. Чтобы инвестиция в SOA оправдалась, выявите области, где SOA окажет максимальное влияние. "Если стратегия компании заключается в максимально быстром выводе продуктов на рынок, стоит обратить внимание на приложения, используемые для разработки, проектирования, представления на рынке и маркетинга продуктов, - говорит Джанелл Хилл из Meta Group. - Именно здесь SOA понадобится в первую очередь".

Потенциальные проблемы 1. Технология еще молода. Новая SOA-парадигма еще не прошла "проверку боем" в критически важных приложениях. Организациям, которым требуется высокий уровень доступности, надежности и безопасности, нужно очень тщательно проверить SOA, прежде чем внедрять эту технологию в промышленной среде. 2. Унаследованные взаимоотношения. При строительстве новой SOA-архитектуры надо решить проблемы смены культуры взаимоотношений в компании. Не все пользователи унаследованных систем захотят объединяться. Реализация процессов, затрагивающих много разных подразделений компании, часто требует спонсора на уровне топ-менеджмента. 3. Человеческий фактор. Основанные на SOA BPM-решения могут принести пользу только в полностью автоматизированных процессах. Пока не совсем понятно, годятся ли SOA и BPМ для решения задач повышения эффективности процессов, в которых очень сильно задействованы люди.