ИНТЕГРАЦИЯ ПРИЛОЖЕНИЙ

Как построить КИС из "лучших экземпляров данного класса" и связывающего их ПО

В прошлом году ведущие экспертные группы предрекали наступление эпохи интеграции корпоративных приложений. Стройную череду трехсимвольных аббревиатур ERP (Enterprise Resource Planning), MRP (Material Requirements Planning/Manufacturing Resources Planning), CRM (Customer Relationship Management), SCM (Supply Chain Management) и т. д. поставщики ПО масштаба предприятия (IBM, Microsoft, Siebel, SAP, Oracle) продолжили аббревиатурами EAI (Enterprise Application Integration), EAS (Enterprise Application Suite), MOM (Message Oriented Middleware), ESA (Enterprise Service Architecture), UAN (Universal Application Network), ASI (Application Service Interfaces), ESB (Enterprise Service Bus) и другими.

Артак Оганесян

Российский рынок воспринял новую идею настороженно. Полномасштабное внедрение хорошо "раскрученных" ERP-систем не всегда оправдывает возлагаемые на них надежды, бума с CRM, как это было на Западе, у нас не наблюдалось, если не считать организации центров обработки звонков. Теперь вот вопрос - нужен ли нам EAI? (Обзоры по средствам EAI можно найти в PC Week/RE N 35/2003 с. 37, N 36/2003 с. 31, N 44/2003, с. 46, N 47/2003, с. 40). В стране талантливых программистов задача интеграции двух, трех, десятка программ не кажется особо сложной. У нас на каждом втором предприятии используется самописная АСУ или КИС (или, по крайней мере, готовые программные продукты дополнены собственными разработками). А сколько мостов, шлюзов, переходников, адаптеров и коннекторов создано "народными" умельцами! В былые времена опытные АСУшники подключали персоналки к унаследованным базам на "ЕС-ках", а недавно я посетил отдел в ведомственном НИИ, где "продвинутые" специалисты уже второй год создают свою универсальную интеграционную платформу.

Да, все это тоже интеграция. Значит, мы уже давно этим занимаемся. Такие задачи были и есть, и их будет больше, потому что внедряется все больше и больше информационных систем. Можно продолжать на ходу решать возникающие проблемы со связыванием одной программы с другой, но можно проектировать и строить общие решения...Ведь этот велосипед уже изобретен! Ведущие производители программного обеспечения - системного (например, как IBM и BEA), прикладного (SAP и Siebel), системно-прикладного (Microsoft и Oracle) - уже предложили рынку свои интеграционные платформы. В начале многих маркетинговых буклетов этих вендоров можно найти картинку, изображающую хаотическое переплетение связей приложений, с подписью типа "исторически сложившийся зоопарк", а в конце - другую, демонстрирующую схему упорядоченной интегрированной системы, способной работать в гетерогенной среде, эдакий "образцовый зоопарк". Естественно, все это сопровождается описанием методологии и технологий, которые необходимо использовать в проектах системной интеграции.

Будут ли они востребованы на российском рынке?

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

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

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

Приведу также два нетипичных примера интеграционных проектов, которые были выполнены нашей проектной командой.

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

 

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

 

· система построения плана-графика съемок с оптимизацией по самому дорогому из факторов (приглашение кинозвезды на главную роль, удаленные съемки, аренда помещений и т. п.);

 

· система учета реквизита с привязкой к плану-графику съемок и модулю снабжения;

 

· расширенный кадровый учет с вводом понятий временных работников и статистов, массовая обработка анкетных данных;

 

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

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

 

· стандартной ERP-системой;

 

· системой учета объектов наружной рекламы и управления нарядами на работы (монтаж, установка, обход, ремонт);

 

· геоинформационной системой (содержащей топологию размещения рекламных щитов и конструкций);

 

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

 

· CRM-системой, доработанной под отраслевые требования (прямые контракты и работа через медиа-агентства, резервирование и бронирование стендов и щитов, заказ сети объектов с покрытием различных территорий и т. д.).

В обоих проектах пришлось решать большое число интеграционных задач, чтобы объединить все программы, разработанные различными производителями! С помощью готовых интеграционных средств удалось сократить сроки, трудоемкость и риски этих проектов.

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

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

Попытки разработать отдельные мосты приводят к уже упоминавшейся картине с хаотическим переплетением взаимосвязей ("спагетти"), которой так любят пугать аналитики. Намерение построить свое интеграционное решение требует значительных инвестиций в создание базовых механизмов. Стоимость создания и сопровождения собственного инструментария может превысить затраты на саму автоматизацию. И такой подход чреват рисками при последующих поддержке и развитии, поскольку появляется зависимость от корпоративного отдела АСУ в целом и от отдельных индивидуумов в частности, кроме того, полученное решение будет уникальным и, как правило, без сопроводительной документации.

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

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

· большое число приложений;

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

· гетерогенная ИТ-инфраструктура;

· территориально распределенная среда;

· объемные потоки данных;

· тенденции к росту бизнеса и диверсификации (увеличение числа ИС для обеспечения новых процессов).

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

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

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

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

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

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

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

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

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

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

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

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

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

· предсказуемой, так как можно оценить воздействие изменений на смежные приложения, зная взаимозависимости систем;

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

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

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

С автором, менеджером по развитию бизнеса компании Vested Development Inc. (VDI), можно связаться по адресу: ArtakO@Moscow.vdiweb.com.