Александр Радаев , cnews.ru

С необходимостью интеграции приложений в процессе роста сталкивается каждая крупная компания. Решается эта задача по-разному, но далеко не все подходы оказываются в состоянии обеспечить требуемую эффективность и качество работы. Как избежать подводных камней на пути к эффективной интеграции и управлению бизнес-приложениями? Этому вопросу был посвящен круглый стол CNews “Интеграция бизнес-приложений на уровне корпорации – дополнительный источник развития бизнеса и уменьшения затрат”.

Интеграция приложений на предприятии

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

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

“Попарное связывание приложений, то есть построение интерфейсов по принципу “точка-точка”, хорошо зарекомендовало себя в тех случаях, когда данные сосредоточены в небольшом количестве систем, а также, когда требования к интеграции ограничиваются синхронизацией данных между системами, – отмечает Артем Асанов, менеджер компании Accenture. – Однако с ростом бизнеса, увеличением количества взаимодействующих приложений, их усложнением, системная архитектура компании становится все более сложной и, зачастую, запутанной. Реализация бизнес-процессов фрагментируется по разным системам, отсутствует их сквозная видимость и, следовательно, управляемость. Нередко одни и те же бизнес-функции дублируются в разных системах в силу технологических ограничений интерфейсов, изначально ориентированных на синхронизацию данных. Замена кого-либо приложения влечет за собой практически полную переработку всех интерфейсов, в которых оно было задействовано”.

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

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

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

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

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

Уровни интеграционного решения

Источник: Accenture

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

Проблемы проектов интеграции

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

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

“Одна из наиболее серьезных и, в то же время, часто встречающихся проблем состоит в неправильном позиционировании проекта интеграции перед бизнесом – поясняет менеджер Accenture Филипп Майзенберг. – Проект “продается” как исключительно технологический, при этом не оцениваются, а главное не объясняются на доступном языке, те количественные и качественные преимущества, которые получает бизнес от внедрения проекта”.

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

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

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

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

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

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

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

“У нас имеется опыт управления и создания моделей бизнес процессов в быстрорастущих компаниях, в которых прирост составляет более десяти процентов ежегодно. Если вы расширяете штат на 4 человека в неделю, на перестройку бизнес-процессов уходит много времени. Попытка излишней детализации бизнес-процессов не всегда необходима, а зачастую и экономически нецелесообразна. Достаточно лишь описания первого уровня. Иначе это может быть практически нескончаемым процессом” – заметил Виктор Голиков, специалист “Инженерного центра Энергоаудитконтроль”.

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

Вообще, выбор прикладных систем и их интегратора – чрезвычайно сложный процесс. Довольно часто можно столкнуться с подходом “все самое лучшее”, когда закупаются лучшие в своем классе продукты, а затем проводится их интеграция. Другие предпочитают воспользоваться решениями от одного вендора, рассчитывая, что это значительно снизит затраты на интеграцию. Часть компаний стараются переложить весь груз ответственности за выбор, наладку и последующее сопровождение на интегратора, другие считают разумным создать собственную ответственную группу, которая бы контролировала подрядчиков. Вариантов много, и сказать, что какой-либо из них предпочтительнее – сложно.

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

Особенно важно понять, кто несет ответственность за проект. “Никто не знает, что произойдет через пять лет. Существующая платформа и все остальное могут, например, исчезнуть. Допустим, решение принято, начата реализация проекта, и мы собираемся в течение 5 лет его реализовывать. А через два года появляется новое, более эффективное решение стоимостью 5 миллионов. И что делать? Я занимаюсь прогнозированием, работаю в соответствующих структурах и могу сказать, что ни один прогноз в ИТ отрасли не сбылся, вообще ни один” – уверен Виктор Голиков.

“У нас было три отдельных проекта, мы решили их интегрировать – это четвертый проект. Кто несет за него ответственность? Идея отдать все на откуп интегратору была определена как риск. В результате была создана внутренняя команда со своим архитектором. И вопрос интеграции и ответственности за нее несла наша компания. А не тот, кто поставлял решение” – делится опытом Никита Кузьмин.

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

Основные проблемы, с которыми сталкиваются компании при интеграции бизнес-приложений

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