© 1995-2022 Компания «Инфосистемы Джет»
Гайд - как провести успешный апгрейд Siebel CRM с помощью IRM
Программное обеспечение Программное обеспечение

Компания Oracle разработала функционал IRM, облегчающий процесс установки новых версий Siebel CRM

Главная>Программное обеспечение>Как провести успешный апгрейд Siebel CRM
Программное обеспечение Тема номера

Как провести успешный апгрейд Siebel CRM

22.11.2016

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

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

Время просмотра: 2.8 мин.

Авторы

Автор
Максим Чугункин В прошлом - заместитель начальника Отдела проектирования Центра внедрения бизнес-систем компании «Инфосистемы Джет»
Автор
Роман Шевченко Руководитель группы разработки Центра внедрения бизнес-систем компании «Инфосистемы Джет»

Новый функционал Siebel CRM

 

Начиная с 2013 г. Oracle проводит кампанию по принципиальной модернизации системы Siebel CRM. За это время был разработан новый интерфейс OpenUI (с преимуществами CSS, HTML5, JavaScript), web-средство разработчика (WebTools), возможность внесения изменений без перезапуска серверов и многие другие усовершенствования в части производительности и привлекательности приложений.

 

 

В дополнение ко всему Oracle разработал функционал, облегчающий процесс установки новых версий Siebel CRM c пакетами инноваций, – IRM ( Incremental Repository Merge ).

 

Если до 2013 г. релизы выпускались один раз в 2–3 года, то на текущий момент обновления Siebel CRM публикуются намного чаще, выдерживая четкий график: минорные релизы (patchset) выходят ежемесячно, принципиально новые версии (major) – ежегодно. Раньше выход новой версии означал для клиента необходимость глобальной переработки и даже повторного внедрения своей системы. Однако использование IRM позволяет клиентам в краткие сроки и с минимальными затратами обновить приложения и подготовить их к работе для конечных пользователей.

 

IRM

 

Для того чтобы обновить CRM-систему (начиная с версии 8.1.1.) на новую (major) версию, необходимо провести обновление репозитория. Обновление модифицированного клиентом репозитория происходит путем его объединения с репозиторием новой версии системы.

Авторы

Репозиторий – это метаданные системы, т.е. схемы всего, что является функционалом системы. За время внедрения проекта разработчики-консультанты клиента (т.е. по факту потребителя Siebel CRM) вносят в репозиторий тысячи изменений. Однако в поставке релиза от Oracle эти изменения отсутствуют, в том числе сам Oracle, дорабатывая систему, добавляет новые метаданные или, вообще, может полностью переработать ту или иную схему объектов. Именно поэтому было принято решение о создании репозиториев IRM.

Очевидно, тут необходим механизм, который позволил бы безболезненно объединить изменения, совершенные потребителем системы с новыми разработками от Oracle. И нам в помощь был создан IRM.

 

Задачи, решаемые в ходе IRM Upgrade:

 

  1. Подготовка репозиториев и сред к объединению.
  2. Непосредственное объединение на DEV-среде (IRM).
  3. Анализ и разрешение конфликтов.
  4. Регрессионное тестирование.
  5. Исправление всех дефектов Upgrade.
  6. Миграция на PreProd и Prod.

 

Залог успешного апгрейда, или 7 раз отмерь…

 

Нужно понимать, IRM – это не волшебная палочка. Его функционал выполняет строго заданный алгоритм, а по факту, всего лишь определяет набор расхождений объектов репозитория и их свойств, позволяя на основе решения разработчика выбрать способ объединения объектов и на последнем этапе запустить процесс миграции обновленного репозитория с DEV на PREPROD/PROD среду.

 

Merge проводят между тремя репозиториями, IRM определяет расхождения по объектам и свойствам, которые присутствуют в оригинальном репозитории, репозитории клиента и репозитории новой версии.

 

В ходе определения расхождений возникают конфликты, которые делятся на критические и некритические.

Конфликт – это расхождение свойств объекта текущего репозитория с тем же объектом репозитория новой версии.

 

Некритические конфликты – это расхождения по объектам, которые не были затронуты клиентом, т.е. расхождение между оригинальным репозиторием и новым. 99% таких конфликтов решаются в пользу нового репозитория.

 

Критические конфликты – это расхождения по объектам между репозиторием клиента и новым репозиторием.

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

 

К сожалению, в 90% проектов при выполнении тех или иных требований заказчика лучшие практики от вендора приносятся в жертву. Например, зачастую изменяются пользовательские ключи (UK) стандартных таблиц, что Oracle настоятельно не рекомендует делать. Невыполнение этого правила приводит к невозможности автоматического перестроения таблицы в процессе миграции на PreProd/Prod и потребует проведения множества ручных манипуляций с таблицами и данными. Кроме того, изменение ключа может повлиять на работоспособность новых процессов, разработанных под новую версию Siebel CRM.

 

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

 

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

 

  • Каждое изменение стандартного объекта репозитория документировалось: фиксировалось исходное состояние, изменение комментировалось и давалось описание его назначения.
  • Максимально возможно использовался стандартный функционал.
  • Таблицы расширялись только в крайней необходимости, при этом максимально использовались стандартные таблицы расширения 1:1 и 1:M.
  • Были сохранены все стандартные ключи (UK) таблиц.
  • Проводилось обучение команды заказчика.

 

Впоследствии все это позволило провести не один апгрейд, в том числе самостоятельно командой заказчика.

Как еще можно использовать IRM?

 

В ходе внедрения проекта «Операционный CRM» в крупном банке наш заказчик вышел с предложением объединить разрабатываемый нами функционал 8.1.1.11 версии Siebel с параллельно разрабатываемым другим подрядчиком проектом на той же 8.1.1.11 версии – «Работа с просроченной задолженностью». Банк поставил перед собой цели сделать единое окно для своих пользователей, сократить время, затрачиваемое для переключения между окнами систем, создать единую базу клиентов для CRM и сократить время, затрачиваемое для загрузок данных из АБС банка в CRM.

 

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

 

Мы предположили, что можно воспользоваться средством IRM для объединения двух идентичных версий Siebel CRM с различными конфигурациями. Продумали методологию, настроили тестовый стенд и провели тестирование. Результат побил все ожидания!

 

Задачи, которые были решены нашей командой в ходе Merge:

 

  • Подготовка репозиториев и сред к объединению.
  • Тестирование объединяемых решений.
  • Непосредственное объединение на DEV-среде (IRM).
  • Анализ и разрешение конфликтов.
  • Регрессионное тестирование.
  • Исправление всех дефектов Merge.
  • Миграция на PreProd и Prod.

Merge и подводные камни

 

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

 

Отдельно имеет смысл заказать аудит у Oracle, чтобы выяснить, какие нарушения методологии и технические ошибки реализации допустил разработчик. Аудит проводят специалисты Oracle, результаты фиксируются в виде специализированных протоколов Oracle Siebel CRM:

 

  1. отчет о конфигурации (ошибки или нарушения в конфигурации бизнес-логики);
  2. отчет об интеграции (ошибки или нарушения в интеграционных объектах);
  3. отчет о скриптах (ошибки или нарушения в программируемых модулях);
  4. ошибки в процессах (ошибки в workflow и автоматизированных функциях).

 

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

 

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

 

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

 

Выделим наиболее значимые проблемы, возникшие в ходе работы над таким документом:

 

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

 

Помимо серьезных технических расхождений мы выявили «философские» конфликты, например, сущность «Action» в нашем проекте хотели видеть как «Задания», а в параллельном проекте – как «Задачи». Причем аналитики каждой стороны настаивали на своем варианте.

 

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

 

Польза апгрейда для заказчика:

 

  • Новый движок: OpenUI – возможность более глубокой настройки интерфейса, повышающий usability (удобство использования) системы.
  • Средство WebTools (средство настройки системы) дает возможность вносить изменения в интерфейс и в бизнес-логику системы из браузера, не требуя перезагрузки сервера, т.е. без даунтайма (периода недоступности) системы.
  • Отдельно можно выделить поддержку технологии интеграции REST (стиль архитектуры программного обеспечения для распределенных систем), которая хорошо применима при интеграции с клиентскими порталами.

Очевидно, что залог победы – это правильный подход к разработке своего проекта, начиная с первого внесенного изменения в репозиторий. Гарантом будет привлечение опытных консультантов, которые способны предусмотреть, чем обернутся последствия изменений объектной модели Oracle Siebel CRM в дальнейшем для развития системы. Порой неправильно выбранный ключ интеграции для таблицы может повлечь широкомасштабную переработку ключевых процессов. Важно понимать, что нарушение методологии разработки может превратить банальное обновление системы за 5-10 дней в проект на несколько месяцев.

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

«Внедрение CRM – это только начало…»

О внедрении CRM в «АК БАРС» Банке рассказала в интервью Jet Info руководитель проекта Наиля Азатовна Гарифуллина

Автоматизация бизнес-процессов? Siebel Task UI спешит на помощь

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

Тестирование функций виртуализации платформы SPARC на Oracle SPARC T7-2

В начале этого года у нас на тестировании побывал сервер Oracle SPARC T7-2. Основной целью тестирования было знакомство с новыми технологиями аппаратного ускорения работы СУБД Oracle средствами нового процессора Oracle M7, на базе которого построен сервер.

Что за зверь Oracle Exadata?

Что предлагает нам корпорация Oracle? Ответом, наверное, будет: «Давайте рассматривать базу данных как сервис, а этот сервис мы разместим на ПАК Exadata!». Exadata – это единый программно-аппаратный комплекс, на котором предлагается обслуживать множество пользовательских баз данных.

Проектировщики. Балансировщики нагрузки: практические аспекты внедрения

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

Кластерные СУБД

Направление развития информационных технологий все чаще затрагивает кластеризацию или разделение БД по нескольким серверам.

«Урал — не Москва»: ИТ в региональном банке с федеральной сетью

Как оформить кредит, не подписывая никаких бумаг? Сколько дней вендоры везут ИТ-оборудование на Урал? Почему СКБ-банку был нужен аудит CRM-системы?

Бизнес-приложения – опыт «эксплуататора»

Эксплуатация бизнес-приложений как услуга – какие сервисы включает в нее Сервисный центр компании «Инфосистемы Джет»

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





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







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







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







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








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

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

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

            Спасибо!

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

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