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

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

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

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

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

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

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

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

Чтобы апгрейд был успешным, прежде всего, каждый разработчик должен следовать методологии 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 (стиль архитектуры программного обеспечения для распределенных систем), которая хорошо применима при интеграции с клиентскими порталами.