© 1995-2022 Компания «Инфосистемы Джет»
Разбор проекта модернизации ИТ-системы в ЛИКАРДе и его итоги
Программное обеспечение Программное обеспечение

В статье мы расскажем о проекте внедрения CRM Oracle Siebel в ЛИКАРДе с использованием интеграционной шины Oracle Service Bus

Главная>Программное обеспечение>Проект модернизации ИТ-системы в ЛИКАРДе
Программное обеспечение Тема номера

Проект модернизации ИТ-системы в ЛИКАРДе

16.11.2016

Посетителей: 120

Просмотров: 105

Время просмотра: 2.3

Авторы

Автор
Алексей Полев В прошлом - архитектор Центра внедрения бизнес-систем компании «Инфосистемы Джет»
Автор
Дмитрий Овчаренко В прошлом — эксперт Центра управления данными компании «Инфосистемы Джет»

В этой статье мы расскажем о проекте модернизации ИТ-системы в компании «ЛУКОЙЛ-Интер-Кард» (ЛИКАРД).

  

 

ЛИКАРД – оператор отпуска нефтепродуктов по топливным картам «ЛУКОЙЛ», оператор Программы поощрения клиентов «ЛУКОЙЛ».

 

Новая система должна была отвечать требованиям производительности и гибкости, чтобы соответствовать стремительным темпам роста и большим планам по развитию бизнеса. Специалисты Центра внедрения бизнес-систем (ранее Департамента прикладных финансовых систем), изучив потребности заказчика, предложили команде ЛИКАРДа внедрить систему, центральным компонентом которой призвана была стать CRM на базе Oracle Siebel.

 

Oracle Siebel CRM демонстрирует быструю и стабильную работу на большом числе клиентов (более 6 млн), данный продукт построен на архитектуре, обеспечивающей быстрое развитие и перестройку под требования заказчика, меняющиеся в процессе развития бизнеса.

 

Стоящий в центре компонент обязан взаимодействовать со своим окружением. Тут в помощь Oracle Siebel пришла интеграционная шина на базе Oracle Service Bus (OSB), объединившая 10 систем и более 150 сервисов. Siebel обладает мощными механизмами интеграции: ему подвластны популярные стандарты WS- и REST-сервисов, по плечу разветвленная логика цепочек вызова – за счет механизма Workflow. Однако объемы интеграции предстояли обширные, а связывать веб-сервисы по принципу «точка–точка» с учетом затрат на разработку было бы очень расточительно и архитектурно неверно, поскольку такая реализация потребовала бы от веб-сервисов точного повторения процессинга в CRM, а это минимум 2 или 3 реальных вызова на одну логическую задачу, например, на запрос баланса баллов.

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

 

Совместная реализация интеграционного слоя на Oracle Service Bus позволила команде ЛИКАРДа сократить расходы на интеграцию и ускорить процесс внедрения за счет разделения труда специалистов, отвечающих за CRM, процессинг, пользовательские приложения, причем каждый занимался своей работой, в то время как команда шины организовывала их взаимодействие.

 

Интеграционная шина: гнемся, но не ломаемся

 

Siebel по праву главного взял на себя реализацию бизнес-процессов, а интеграционная шина – взаимодействие с внешними системами. Но ей был уготован не только безликий транспорт. Например, для личного кабинета B2C потребовался функционал, не входящий в задачи CRM, поэтому шина связала ЛК с отдельным менеджером клиентских сессий, отправителем СМС, процессингом с наибольшим удобством для ЛК. Было принято совместное решение строить сервисы на принципах возможности повторного использования. Когда у ЛИКАРДа появилось мобильное приложение «АЗС-Локатор», его интеграция с CRM и процессингом прошла так бесшовно, что обе системы об этом даже «не узнали».

 

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

 

Шина Oracle Service Bus позволяет даже динамически менять код сервисов в онлайн-интерфейсе, прозрачно для потребителей, однако в ЛИКАРДе из-за строгости релизной политики данная возможность на текущий момент не используется.

 

Мы говорим на вашем языке

 

Специалисты ЛИКАРДа предложили в рамках внедрения CRM-системы часть несвойственных процессингу функций, в основном связанных с вводом исходных данных, вынести в CRM. Исходя из предоставленных требований выяснилось, что разработка API со стороны процессинга оказалась на критическом пути проекта внедрения. Для оптимизации времени и затрат на разработку интеграции было принято решение использовать «родной» формат низкоуровневого обмена сообщениями с процессингом. Такой подход позволил перераспределить интеграционные усилия команд внедрения в сторону шины/CRM, сняв нагрузку со стороны разработчиков конечной системы. Однако при использовании свойственного процессингу интерфейса xml over http мы столкнулись с рядом особенностей, которые пришлось учитывать по ходу проекта.

 

1) XSD-схемы

 

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

 

2) Генерация уникальных идентификаторов

 

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

 

3) Поля, не приведенные к первой нормальной форме

 

Одной из возможностей расширения стандартной функциональности в процессинге является создание так называемых тегированных полей, когда значением поля является комбинация пар: «наименование_атрибута = значение_атрибута», разделенных точкой с запятой. Использование таких полей разработчиком конечной системы утяжеляет обработку и формирование интеграционных сообщений, так как привносит дополнительные операции по обработке текста.

 

4) Особенности объектной модели данных конечной системы

 

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

 

5) Ограниченные возможности по доработке нативного интерфейса

 

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

 

Итог проекта

 

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

В качестве плюсов можно отметить:

 

  • готовый или минимально дорабатываемый набор функциональности на стороне конечной системы;
  • хорошо отлаженный механизм.

 

К минусам стоит отнести:

 

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

 

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

 

А что дальше?

 

Oracle Service Bus: интеграция людей

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

 

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

 

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

 

Oracle Service Bus: интеграция процессов

 

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

 

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

 

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

 

Делай больше, делай лучше!

 

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

 

Однако в процессе реализации проектных задач образуется огромное количество рабочего материала, который будет использован в будущем. Схемы данных, служебные процедуры, функции доступа к справочникам, библиотеки логирования, модули работы с бинарными файлами (word, excel), адаптеры к прикладным системам (Siebel, SAP), механизмы развертывания функционального и нагрузочного тестирования – весь этот набор ускоряет реализацию новых проектов, а модернизируясь и развиваясь, он составляет базу наработок, которая становится конкурентным преимуществом перед лицом новых задач.

Уведомления об обновлении тем – в вашей почте

Специальный комплекс услуг по сервисному обслуживанию ИТ-инфраструктуры Банка Русский Стандарт

О заказчике   ЗАО «Банк Русский Стандарт» – одна из крупнейших в России банковских структур, занимающая первое место среди частных банков страны по объемам кредитования населения и предлагающая услуги мирового уровня, ориентированные на ...

Oracle Scorecard and Strategy Management

Oracle Scorecard and Strategy Management расширяет линейку продуктов Oracle BI Enterprise Edition, предоставляя организациям возможность согласования стратегических целей с ежедневной активностью и мониторинга прогресса в их достижении.

Защита систем дистанционного банковского обслуживания на базе решения Oracle Adaptive Access Manager

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

Аутсорсинг СУБД - отдать, нельзя оставить

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

Хранить или не хранить: больше не вопрос …

Все в нашей жизни меняется: меняется рынок, меняются сами банки, меняются требования, которые банки выставляют к своим информационным системам, меняются и сами информационные системы.

Наши проекты: «Внедрение системы управления взаимоотношениями с клиентами на основе Oracle Siebel CRM в КБ «Транспортный»

ООО КБ «Транспортный» создан в 1994 г. и осуществляет банковскую деятельность в Москве и Центральном Федеральном округе. Банк является универсальным коммерческим банком, предоставляющим своим клиентам весь спектр современных банковских услуг.

Оптимально, основательно, OLAP

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

Инструменты лидера

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

Оптимизация информационных систем на основе СУБД Oracle

Если в основе информационной системы (ИС) лежит СУБД Oracle и возникает недовольство пользователей недостаточной производительностью ИС, то, как правило, усилия по исправлению ситуации направляются на оптимизацию СУБД. При этом иногда ...

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня