CHaRM, czyli zmiany sprawne i udokumentowane

ChaRM (Change Request Management) został wykorzystany podczas replikacji rozwiązania SAP z Wielkiej Brytanii do centrali w Holandii. Projekt wspierany był przez SNP (aktualnie All for One Poland), miał na celu dostosowanie rozwiązań na systemach SAP ECC i SAP SRP (Supplier Relationship Management).

Niestandardowe środowisko

Wdrożenie w LeasePlan należało do interesujących pod względem środowiska, na jakim pracowano. Środowisko SAP zawierało w sobie 6 systemów, co pozwoliło na bezpieczne wdrożenie rozwiązania. Dzięki podzieleniu środowiska na dwa (utrzymaniowe i projektowe) uniknięto ryzyka wdrożenia zmian na systemach przeznaczonych do codziennej pracy. Dzięki kompletnemu odizolowaniu zmian wszelkie prace utrzymaniowe były prowadzone na bieżąco i nie oddziaływały na projekt.

Wszelkie zmiany projektowe po wcześniejszym zatwierdzeniu Wniosku o Zmianę były implementowane na systemie DEV`, od którego rozpoczynała się ścieżka projektowa, a następnie przechodziła przez wszystkie systemy w środowisku SAP. Dla zachowania spójności środowisk, transporty z systemu DEV były również przenoszone na systemy DEV` i QAS`.

Role w projekcie

SNP (aktualnie All for One Poland) w zakresie wdrożenia przyjęło kilka kluczowych ról w zakresie procesu Zarządzania Zmianą:

Deweloper – określony przez Change Managera podczas tworzenia dokumentu zmiany (Change Document). Na podstawie informacji przekazanych we wniosku o zmianę Developer wprowadza korekty w systemie rozwojowym.

Tester – weryfikacja rozwiązań w systemach testowych zgodnie z Test Case. Przekazanie zmian do IT Operatora.

Change Manager – pełni rolę decydenta w Zarządzaniu Zmianą. To na nim spoczywa odpowiedzialność za prawidłowe przeprocesowanie zmiany. Przeprowadza wstępną weryfikację wniosku, co pozwala stwierdzić, czy wszystkie wymagane informacje zostały prawidłowo przekazane przez Requestora.

IT Operator – odpowiedzialny za przenoszenie transportów pomiędzy systemami.

Wnioski o Zmianę

Każda zmiana wprowadzona na systemach SAP musiała wcześniej zostać zaakceptowana. Przygotowane wnioski o zmianę zawierały podstawowe informacje, takie jak: temat, opis zmiany, osoby uczestniczące, datę zmian, moduł jakiego dotyczyły zmiany. Wniosek w kolejnym kroku był zatwierdzany lub odrzucany przez osoby odpowiedzialne za dany moduł. Po zatwierdzeniu wniosku Change Manager mógł przygotować Dokument Zmiany dla wybranych deweloperów i przekazać zmianę do implementacji.

Faza dewelopmentu – środowisko projektowe – DEV`

Zmiany wprowadzane w środowisku projektowym zarządzane były przez Normal Change (NC), zmiany które nie wymagały transportów były dokumentowane oddzielnie. Informację w NC przygotowywano na bazie RfC, przypisywano odpowiednie osoby, wprowadzano informację na temat zmian, jakie będą implementowane, określano zespół deweloperów, jaki będzie brał udział w zakresie zmiany. Dokument Normal Change pozwala na bezpieczne przenoszenie transportów pomiędzy systemami z zastosowaniem mechanizmu Transport of Copies (ToC). W pierwszym kroku Change Manager określał zespół pracujący nad zmianą: deweloperów, testerów, administratora IT.  Następnie przekazywał zmianę deweloperom. Deweloperzy tworzyli z narzędzia ChaRM transporty i dopisywali zadania transportowe dla osób pracujących w zakresie transportów. Przy wprowadzeniu zmian deweloperzy byli cały czas informowani, czy zmiany na obiektach nie dotykają obiektów na systemie DEV ze środowiska utrzymaniowego. Dzięki mechanizmowi Cross System Object Lock (CSOL), deweloperzy mogli zostać poinformowani o konieczności weryfikacji oddziaływania zmian na środowisko utrzymaniowe. Drugi pomocny mechanizm przy implementacji czyli Downgrade Protection śledził zmiany w obrębie systemu DEV` i informował deweloperów, który transport wszedł w konflikt z ich zmianami. Deweloperzy mogli podjąć decyzję, czy transport zawarty w innym NC rzeczywiście oddziałuje na ich zmiany i wprowadzić zmiany jeszcze przed zwolnieniem transportu. Po zakończeniu implementacji na DEV` oznaczano zmianę jako gotową do testów, bez zwalniania transportów. Dzięki temu zmiana została przejęta przez mechanizm ToC i została przeniesiona na system QAS`.

Transport of Copies (ToC) jest narzędziem pozwalającym zredukować ilość transportów trafiających na system produkcyjny o ponad połowę. Wykonuje kopie transportu wraz z zawartością i przenosi zmiany na kolejny system w ścieżce transportowej. ToC przenoszony jest tylko i wyłącznie na kolejny system, po czym nie jest dostępny w buforze dla kolejnych systemów. Pozwala to na przeniesienie zmian na system testowy bez konieczności zwalniania transportu źródłowego i tworzenia nowych w przypadku wymaganych poprawek.

Faza testów – środowisko projektowe – QAS`

Po każdej zakończonej fazie osoby pełniące jedną z kluczowych ról w procesie Zarzadzania Zmianą tj. Deweloper, Tester, Change Manager, IT Operator mogą śledzić zmiany i weryfikować z poziomu ChaRM w przygotowanym interfejsie WebUI. Widoczne są podstawowe informacje odnośnie zadań, które wymagają ich uwagi i akcji. W fazie testów wykonano weryfikację wcześniej wprowadzonych zmian. W przypadku jakichkolwiek problemów zmiany były cofane do poprzedniej fazy, gdzie wprowadzano poprawki w obrębie tego samego transportu i ponownie były przenoszone jako ToC na kolejny system. Testerzy, którzy zatwierdzili zmiany na systemie QAS` automatycznie wymuszali zwolnienie transportu na systemie DEV`. Dzięki temu wszystkie transporty ustawiały się automatycznie w kolejce importu. Moment zwolnienia transportu w ChaRM jest kluczowym momentem pozwalającym na odpowiednie ustawienie transportów w kolejce, dzięki czemu trafiają w odpowiednim porządku na kolejne systemy. Ułatwiło to znacznie implementacje podczas projektu LPC. Ostatecznie na system produkcyjny trafiło prawie 100 transportów, a mogło trafić nawet 3x więcej bez wykorzystania ToC.

Retrofit

Po zatwierdzeniu testów, zmiany zostały przeniesione przy wykorzystaniu mechanizmu Retrofit na środowisku utrzymaniowe. Retrofit to opcja pozwalająca na oddzielenie długoterminowych zadań w środowisku projektowym od zadań związanych z utrzymaniem systemów w środowisku utrzymaniowym. Zmiany wprowadzane w obu środowiskach nie oddziałują na siebie, co pozwala na uniknięcie konfliktów. Każdy z procesów może być procesowany w odrębnym środowisku, przez różne zespoły. Wszelkie mniejsze zmiany wprowadzone w środowisku utrzymaniowym powinny być również wprowadzone w taki sam sposób w środowisku projektowym, dla zapewnienia prawidłowego działania systemu produkcyjnego, do którego trafiają transporty z obu środowisk.

Faza Testów – środowisko utrzymaniowe

W tej fazie zweryfikowano, czy nowa implementacja nie wpływa na obecne rozwiązania w środowisku utrzymaniowym. W przypadku konfliktów dostosowywano ponownie zmiany i ponownie weryfikowano na systemie QAS.

Faza Preprodukcyjna – środowisko utrzymaniowe

Ostateczna faza pozwoliła na końcową weryfikację i dostosowanie dokładnego planu do Go-Live. W planie Go-Live zawarto informację, jakie transporty zostaną przeniesione, w jakiej kolejności, a dzięki wcześniejszym implementacjom można było określić dokładne czasy przeniesienia zmian i dostosowań. Dzięki zastosowaniu czwartego systemu w kolejce uzyskano pewność bezpieczeństwa wprowadzanych zmian i zweryfikowano rozwiązania na najbardziej aktualnych danych z systemu produkcyjnego.

Faza Go-Live

Przeniesienie zmian na system produkcyjny z rozwiązaniem ChaRM przebiegł sprawnie i bez komplikacji. Wszystko to dzięki narzędziom wspierającym proces Zarządzania Zmianą i wyeliminowaniu wszelkich konfliktów pomiędzy obiektami we wcześniejszych fazach.

Eelco Roeten, Global GFS Architect, LeasePlan Corporation

Projekt dobrze zaplanowany
Rozwiązanie ChaRM, wykorzystujące mechanizm Retrofit, pozwoliło nam zsynchronizować złożony krajobraz. Zmiany w systemie produkcyjnym zostały wdrożone w sprawny i zorganizowany sposób. Dzięki systemowi Zarządzania Zmianą projekt został przeprowadzony w sposób w pełni zaplanowany i zarządzany.
Eelco Roeten, Global GFS Architect, LeasePlan Corporation