Функціонал Siebel CRM із встановлення нових версій IncrementalRepository Merge (IRM)

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

На додаток до всього Oracle розробив функціонал, що полегшує процес встановлення нових версій Siebel CRM з пакетами інновацій, -IRM(IncrementalRepositoryMerge).

Якщо до 2013 р. релізи випускалися один раз на 2–3 роки, то на даний момент оновлення Siebel CRM публікуються набагато частіше, витримуючи чіткий графік: мінорні релізи (patchset) виходять щомісяця, принципово нові версії (major) щорічно. Раніше вихід нової версії означав клієнта необхідність глобальної переробки і навіть повторного впровадження своєї системи. Однак використання 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, ми заздалегідь запланували апгрейд, і це позначилося на всіх наступних роботах, які проводяться нашою командою:

Згодом усе це дозволило провести не один апгрейд, зокрема, самостійно командою замовника.

Як ще можна використовувати 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 днів на проект на кілька місяців.