ИТ-портал компании «Инфосистемы Джет»

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

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

Новый функционал 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 дней в проект на несколько месяцев.

Вернуться к списку статей
Оставьте комментарий
Мы не публикуем комментарии: не содержащие полезной информации или слишком краткие; написанные ПРОПИСНЫМИ буквами; содержащие ненормативную лексику или оскорбления.
О журнале

Журнал Jet Info регулярно издается с 1995 года.

Узнать больше »
Подписаться на Jet Info

Хотите узнавать о новых номерах.

Заполните форму »
Контакты

Тел: +7 (495) 411-76-01
Email: journal@jet.su