Dynamiczny rozwój Grupy Can Pack w ostatnich latach pozwolił jej dołączyć do czołówki producentów opakowań na świecie. Było to możliwe dzięki realizacji projektów inżynierskich i inwestycji o wartości setek milionów dolarów. W osiągnięciu tak znaczącej pozycji na rynku dużą rolę odegrał zakup nowoczesnych urządzeń, co pozwoliło osiągnąć światowy poziom w technologii produkcji opakowań. Rozwój biznesowy firmy pociągnął za sobą potrzebę reorganizacji usług IT. Jednym z elementów tej reorganizacji był projekt wdrożenia narzędzia Change Request Management, co pozwoliło na uporządkowanie istniejących procesów IT, zwiększenie efektywności procesowania oraz lepszą kontrolę wdrażanych zmian.
Change Request Management (potocznie nazywany ChaRM), jeden z komponentów SAP Solution Managera, jest narzędziem przeznaczonym do kompleksowego zarządzania zmianą – od niewielkich zmian konfiguracyjnych, po duże projekty wdrożeniowe i rozwojowe. ChaRM świetnie sprawdza się w firmach, które mają rozbudowany pejzaż systemów SAP i w których jest prowadzonych wiele projektów równocześnie. Może być wykorzystywany przy zarządzaniu następującymi projektami w SAP Solution Manager:
- maintenance – związane ze standardowymi zadaniami utrzymującymi systemy SAP w dobrej kondycji,
- implementation – projekty długoterminowe, związane z wdrożeniem nowych procesów biznesowych w danym środowisku,
- upgrade – projekty związane z aktualizacją istniejących systemów SAP,
- template – projekty, których celem jest tworzenie wzorców dla innych projektów, zawierających przypisane obiekty, takie jak dokumentacje i aktywności IMG.
W zakresie wdrożenia ChaRM w Grupie Can Pack wykorzystano następujące typy zmian:
- Request for Change,
- Normal Change,
- Urgent Change,
- Admin Change.
Request for Change
Zarządzanie zmianą rozpoczyna się od utworzenia przez Requestora (jedna z kluczowych ról w ChaRM) wniosku o zmianę w systemie. Requestor wprowadza podstawowe informacje, takie jak tytuł zmiany, proponowany priorytet, informacje o systemie i szczegółowy opis zmiany. Następnie wniosek zostaje przekazany do Change Managera, który jest pierwszą osobą weryfikującą zasadność wniosku. Do jego zadań podczas procesowania Request for Change należą określenie priorytetu, kategorii, zakresu systemów objętych zmianą, a także wskazanie grupy zatwierdzającej wniosek. W kolejnym kroku wniosek trafia do grupy Change Advisory Board, która zatwierdza bądź odrzuca wniosek.
Normal Change
Po zatwierdzeniu wniosku tworzony jest Change Document. Jedną z opcji jest Normal Change – tworzony dla zmian, które wymagają przejścia pełnego procesu akceptacji zmiany. Normal Change przechodzi szereg testów, zanim zostanie zaimportowany do systemu produkcyjnego. Zwykle ten typ zmiany jest związany ze standardowymi pracami nad utrzymaniem i rozwojem systemu. Podczas procesowania dokumentu Normal Change zaangażowani zostają Developer, Tester, IT Operator i Change Manager.
Urgent Change
Urgent Change wykorzystuje się w przypadku poważnych problemów lub awarii systemu, która dotyka dużej liczby użytkowników, kluczowych procesów oraz wymaga natychmiastowej reakcji ze strony osób zarządzających systemem. Ten rodzaj zmiany jest w pełni zoptymalizowany do szybkiego procesowania, z zachowaniem pełnego nadzoru przez osoby zaangażowane w realizację zmiany. Od Normal Change różni się automatyzacją fazy przeniesienia zmiany na system testowy i zmniejszeniem liczby kroków wymaganych od zaangażowanych osób.
Admin Change
Admin Change służy do procesowania zmian, w przypadku których niewykorzystywane są transporty. Ma na celu udokumentowanie zmian, które muszą być wprowadzone bezpośrednio na jednym z systemów w środowisku SAP: deweloperskim, testowym lub produkcyjnym.
Zarządzanie zmianą w Grupie Can Pack
Partnerem wdrożenia rozwiązania Change Request Management w Grupie Can Pack było BCC (aktualnie All for One Poland). Podczas projektu najważniejszym wyzwaniem było dostosowanie narzędzia ChaRM, tak aby w pełni dopasowało się do wymagań biznesu. Zakładano, że narzędzie będzie proste w użytku, a zarazem w pełni funkcjonalne. Pierwszym krokiem było stworzenie scenariusza, który pozwalałby dostosować ChaRM do obowiązującego w Grupie Can Pack procesu zarządzania zmianą.
System przystosowano w taki sposób, aby docelowo papierowa wersja wniosku o zmianę została w pełni zastąpiona formą elektroniczną, za pomocą rozszerzenia standardowego widoku ChaRM o dodatkowe pola, pozwalające identyfikować dokumenty zgodnie ze standardami Grupy Can Pack. Kolejnym krokiem było dostosowanie przebiegu zatwierdzania zmian. Obecnie każdy wniosek o zmianę trafia do wskazanego Change Managera, który weryfikuję go i przekazuje do osób odpowiedzialnych za zatwierdzenie zmiany w systemie. Strategia zatwierdzania została oparta na komórce organizacyjnej, z której wysłano zgłoszenie. Ma ona zapewnić zatwierdzenie każdej zmiany przez kluczowe osoby zarządzające systemem SAP oraz docelowo przez dyrektora komórki organizacyjnej zgłaszającej zmianę.
W kolejnym etapie zostały dostosowane dokumenty zmian. Zmiany normalne rozszerzono o możliwość automatycznego importu transportów z systemów deweloperskich do testowych, dzięki czemu ograniczono działania związane z zarządzaniem transportami przez zespół Basis.
Ciekawym rozwiązaniem było zintegrowanie Incident Management z ChaRM. Każdy z użytkowników ma obecnie możliwość zgłoszenia incydentu bezpośrednio z systemu SAP. Na podstawie danych zawartych w incydencie osoba zarządzająca może utworzyć wniosek o zmianę lub dokument zmiany.
W ostatnim etapie zostały dodane dodatkowe typy zmian: administracyjna i pilna. Do pełnej dokumentacji zmian, które nie wymagają transportów, wykorzystano zmianę administracyjną. Dostosowano ją do wymagań Grupy Can Pack analogicznie jak w przypadku wniosku o zmianę, zmiany normalnej i pilnej. Dzięki temu rozwiązaniu każdy typ zmian będzie w pełni udokumentowany.
Zmiany przejrzyste i uporządkowane
W związku z rosnącą liczbą zgłaszanych wniosków o zmianę w systemie SAP wynikła potrzeba implementacji narzędzia, które pozwoliłoby przyśpieszyć sposób rejestracji, jak również późniejszą obsługę wniosków. Do tej pory wnioski sporządzane były w formie papierowej, a następnie opisywane ręcznie przez osobę nimi zarządzającą. Aktualizowanie statusu wniosków, jak również tworzenie zestawień i analiz wykonywano manualnie, co często obarczone było błędem ludzkim.
W związku z procesowanymi zmianami prowadzone były dodatkowe ewidencje transportów, wyceny pracochłonności oraz specyfikacje potrzebnych działań na systemie, których pracochłonność była bardzo wysoka i nie mogła być realizowana za pomocą jednego narzędzia. Dodatkowym kryterium wyboru narzędzia była jego pełna zgodność z metodologią ITIL, zgodnie z którą zarządza się usługami IT w Grupie Can Pack.
Główne korzyści z wdrożenia ChaRM w Grupie Can Pack to uporządkowanie procesu zarządzania zmianą oraz jego lepsza kontrola. Sprzężenie ewidencji wniosków o zmianę bezpośrednio z dokumentami zmian i transportami zwiększyło bezpieczeństwo systemu (nie jest możliwe przeprocesowanie zmiany przez jedną osobę) oraz pozwoliło na raportowanie postępu prac nad zmianami w czasie rzeczywistym. Funkcjonalność Transport of Copies umożliwiła zmniejszenie liczby transportów przesyłanych na system produkcyjny, jak również uprościła wykonywanie testów, z uwagi na pracę na jednym transporcie do momentu uzyskania oczekiwanego rezultatu.
Z punktu widzenia osoby zarządzającej zmianą (Change Manager) główną korzyścią jest możliwość przejrzystej organizacji dokumentacji zmiany oraz lepsza kontrola procesu, do której we właściwy sposób został przygotowany system. Obecnie cała dokumentacja od momentu zgłoszenia wniosku, aż do jego zamknięcia znajduje się w jednym miejscu i dostępna jest dla każdej uprawnionej do tego osoby. W każdym momencie istnieje możliwość sprawdzenia etapu realizacji wniosku, jak również wykonanie raportów ze względu na zadane kryteria. Docelowo przejście na w pełni elektroniczną formę wniosku pozwoli na oszczędność czasu potrzebnego do jego rejestracji.
Firma BCC profesjonalnie przeprowadziła projekt zarządzania zmianą w Grupie Can Pack, na każdym etapie wdrożenia wychodząc na przeciw powstałym problemom i dostosowując rozwiązanie do naszych specyficznych wymagań. Prace były realizowane terminowo i zgodnie z przyjętą metodologią wdrożenia. Konsultant prowadzący projekt wykazał się dużą wiedzą na temat zagadnienia zarządzania zmianą, jak również całego systemu SAP Solution Manager.
Bartłomiej Krawczyk, Specjalista koordynator ds. systemu SAP, CAN-PACK S.A.
Obecnie wszystkie zmiany procesowane są w bardziej uporządkowany i efektywny sposób.
Do tej pory użytkownicy informowali dział IT o wymaganej zmianie za pomocą papierowej wersji wniosku, który musiał być ręcznie podpisany przez dyrektora komórki wnioskującej o zmianę. Na tej podstawie w systemie rejestrowany był wniosek i rozpoczynała się praca nad opracowaniem dokumentacji oraz jego dalsze procesowanie. Brak było centralnego miejsca składowania dokumentacji i potwierdzeń użytkowników, co powodowało w niektórych przypadkach chaos organizacyjny.
Dzięki wdrożonemu rozwiązaniu po utworzeniu incydentu w systemie SAP istnieje możliwość wygenerowania dokumentu następującego po incydencie, jakim jest np. wniosek o zmianę. Wniosek zawiera pełną historię incydentu dzięki podlinkowaniu go do wniosku o zmianę. Następnie, po weryfikacji oraz określeniu, jakiego dokładnie typu zmiany dotyczy wniosek, zarządzający zmianą przekazuje wniosek do zatwierdzenia, co odbywa się poprzez widok Web UI, który jest powszechnie dostępny.
Dzięki spersonalizowanym powiadomieniom mailowym ChaRM pozwala na przekazanie informacji o wymaganej czynności użytkownika, a poprzez załączony link, zatwierdzający mogą bezpośrednio zalogować się do ChaRM i przejść do zgłoszenia, w którym wymagane są ich działania.
Ponadto na systemie deweloperskim wprowadzono nowatorskie rozwiązanie w zakresie zarządzania transportami. Po zakończeniu działań deweloper zwalnia wykonane zadania transportowe, a jego zmiana zostaje automatycznie przesłana na system testowy w postaci Transport of Copies. Transport of Copies gwarantuje, że transport zostanie przeniesiony wyłącznie na system testowy. Import wykonuje się automatycznie, w zdefiniowanym oknie czasowym. Tester może wykonać weryfikację na systemie testowym i w przypadku niepowodzenia zdecydować o cofnięciu zmiany do systemu deweloperskiego, gdzie mogą być dodane kolejne zadania do transportu. Dopiero po zatwierdzeniu testów na systemie testowym właściwy transport zostaje zwolniony, automatycznie zarejestrowany na systemie testowym i może zostać zaimportowany przez zespół Basis do systemu produkcyjnego.
Rozwiązanie to pozwala ograniczyć problem zależności oraz zmniejszyć liczbę transportów, które trafiają do systemu produkcyjnego. Po zakończeniu zmiany informacja zostaje automatycznie przesłana do wniosku o zmianę, po czym zostaje on zamknięty lub rozszerzony o kolejne dokumenty zmian, w zależności od wymagań.