Siebel CRM функционалност за инсталиране на нови версии на IncrementalОбединяване на хранилище (IRM)

Нова функционалност на Siebel CRM

Освен това Oracle разработи функция, която улеснява процеса на инсталиране на нови версии на Siebel CRM с пакети за иновации -IRM(IncrementalRepositoryMerge).

Ако преди 2013 г. изданията се пускаха веднъж на всеки 2-3 години, тогава в момента актуализациите на Siebel CRM се публикуват много по-често, поддържайки ясен график: незначителни издания (patchset) се пускат месечно, фундаментално нови версии (основни) - годишно. Преди това пускането на нова версия означаваше за клиента необходимостта от глобален ремонт и дори повторно внедряване на тяхната система. Използването на IRM обаче позволява на клиентите бързо и рентабилно да актуализират приложенията и да ги направят готови за използване от крайните потребители.

За да актуализирате CRM-системата (започвайки от версия 8.1.1.) до нова (основна) версия, е необходимо да актуализирате хранилището. Модифицираното от клиента хранилище се актуализира чрез обединяването му с хранилището на новата версия на системата.

Хранилището е метаданните на системата, т.е. схеми на всичко, което е функционалността на системата. По време на изпълнението на проекта разработчиците-консултанти на клиента (тоест всъщност потребителят на Siebel CRM) правят хиляди промени в хранилището. Тези промени обаче отсъстват в доставката на изданието от Oracle, включително самия Oracle, докато финализира системата, добавя нови метаданни или като цяло може напълно да преработи тази или онази схема на обекта. Ето защо беше взето решение за създаване на IRM хранилища.

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

Задачи, решени по време на IRM Upgrade:

  1. Подготовка на хранилища и среди за сливане.
  2. Директно сливане в DEV-среда (IRM).
  3. Анализ и разрешаване на конфликти.
  4. Регресионно тестване.
  5. Коригиране на всички дефекти при надграждане.
  6. Миграция към PreProd и Prod.

Ключът към успешно надграждане или измерване 7 пъти ...

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

Обединяването се извършва между три хранилища, IRM определя несъответствията в обекти и свойства, които присъстват в оригиналното хранилище, хранилището на клиента и хранилището на новата версия.

По време на определянето на несъответствията възникватконфликти, които са разделени накритичниинекритични.

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

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

Критични конфликтиса несъответствия на обекти между клиентското хранилище и новото хранилище.

За да бъде надстройката успешна, на първо място всеки разработчик трябва да следва методологията на Oracle. Прилагането на препоръките на Oracle от самото начало ще позволи рентабилни надстройки по-късно.

ДА СЕЗа съжаление, в 90% от проектите, когато изпълняват определени изисквания на клиента, най-добрите практики на доставчика се жертват. Например обичайно е да се променят потребителските ключове (UK) на стандартни таблици, което Oracle силно не препоръчва да се прави. Неспазването на това правило води до невъзможност за автоматично възстановяване на таблицата по време на миграцията към PreProd / Prod и ще изисква много ръчни манипулации с таблици и данни. Освен това промяната на ключа може да повлияе на производителността на новите процеси, разработени за новата версия на Siebel CRM.

Затова е важно системата да бъде внедрена под наблюдението на сертифицирани специалисти с богат опит.

Например, когато разработихме проект за управление на лоялността за компания, предоставяща маркетингови услуги и програми за лоялност за най-големите български търговски и сервизни предприятия, който започна в зората на IRM, планирахме надграждане предварително и това беше отразено в цялата последваща работа, извършена от нашия екип:

Впоследствие всичко това направи възможно извършването на повече от един ъпгрейд, включително самостоятелно от екипа на клиента.

Как иначе може да се използва IRM?

По време на изпълнението на проекта "Оперативен CRM" в голяма банка наш клиент излезе с предложение за комбиниране на функционалността на разработваната от нас версия 8.1.1.11 на Siebel с проекта, който се разработва паралелно от друг изпълнител на същата версия 8.1.1.11 - "Работа с просрочени задължения". Банката си е поставила за цел да създаде единен прозорец за своите потребители, да намали времето, прекарано в превключване между прозорците на системата, да създаде единна клиентска база за CRM и да намали времето, прекарано в изтегляне на данни от ABS на Банката към CRM.

Стандартният начин за прехвърляне на подобрения не пасва тук.Има хиляди обекти в хранилището на Siebel, изпълнителят можеше да промени стотици от тях, промените не бяха документирани на необходимото ниво и самият изпълнител не беше склонен да обсъжда промените, които е направил.

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

Задачи, които бяха решени от нашия екип по време на Merge:

  • Подготовка на хранилища и среди за сливане.
  • Тестване на обединени решения.
  • Директно сливане в DEV-среда (IRM).
  • Анализ и разрешаване на конфликти.
  • Регресионно тестване.
  • Коригиране на всички дефекти на сливането.
  • Миграция към PreProd и Prod.

Сливане и клопки

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

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

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

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

След извършване на тестово сливане в проект за банка се оказа, че всъщност това са две CRM системи на Siebel с напълно различна функционалност. Разликите бяха на ниво бизнес логика и на ниво данни, вариращи от фундаменталните разлики в използваните обекти до разликата в полетата и ключовете на таблиците.

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

Нека подчертаем най-значимите проблеми, възникнали по време на работата по такъв документ:

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

В допълнение към сериозните техническинесъответствия, идентифицирахме "философски" конфликти, например искахме да видим същността на "Действие" в нашия проект като "Задачи", а в паралелен проект - като "Задачи". Освен това анализаторите от всяка страна настояваха за собствената си версия.

Въпреки всички трудности, ние успешно комбинирахме и двете системи. Сега клиентът използва системата през единна входна точка, което е оптимизирало потребителското изживяване, намалило е разходите за притежание, хардуерните ресурси (хардуер) и разходите за поддръжка на унифицираното решение.

Ползи от надстройката за клиента:

  • Нов двигател: OpenUI - възможност за по-дълбоко персонализиране на интерфейса, което увеличава използваемостта (лекотата на използване) на системата.
  • Инструментът WebTools (инструмент за конфигуриране на системата) дава възможност да се правят промени в интерфейса и бизнес логиката на системата от браузър, без да се изисква рестартиране на сървъра, т.е. без престой (период на недостъпност) на системата.
  • Отделно можем да подчертаем поддръжката на технологията за интегриране на REST (стил на софтуерна архитектура за разпределени системи), която е добре приложима при интегриране с клиентски портали.

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