Czym jest Change Request Management?

Change Request Management (potocznie nazywany ChaRM) jest narzędziem przeznaczonym do kompleksowego zarządzania zmianą – od niewielkich zmian konfiguracyjnych, po duże projekty wdrożeniowe i rozwojowe. ChaRM idealnie sprawdza się w firmach, które mają rozbudowany pejzaż systemów SAP i gdzie prowadzonych jest 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.

Role użytkowników

Prawidłowe procesowanie zmian Change Request Management jest możliwe dzięki przypisaniu poszczególnym użytkownikom jednej z ról.

Requestor jest użytkownikiem rozpoczynającym proces. Na podstawie zaobserwowanych nieprawidłowości tworzy wniosek o zmianę. Jego kluczowym zadaniem jest przedstawienie szczegółowego opisu zmiany, określenie, jakiego dokładnie systemu dotyczy i zdefiniowanie priorytetu problemu.

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. Ponadto Change Manager wyznacza skład osobowy grupy Change Advisory Board.

Change Advisory Board to grupa osób, która jest odpowiedzialna za zatwierdzenie wniosku. Zwykle są to osoby z różnych działów firmy, odpowiedzialne za system z punktu widzenia np. finansów, IT, zarządu lub innych.

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

Tester – po wgraniu zmian na system developerski zostają one przekazane do systemu testowego, gdzie weryfikuje je Tester. Po zatwierdzeniu prawidłowego funkcjonowania danej poprawki, przekazuje zmianę IT Operatorowi.

IT Operator to osoba odpowiedzialna za procesowanie importów zmian na systemy testowe i produkcyjne.

Procesowanie zmian

Proces wprowadzenia zmiany wiąże się z utworzeniem wniosku o zmianę (Request for Change) i dokumentu zmiany (Change Document). W obrębie każdego z tych elementów wymagane są określone działania (zobacz schemat poniżej).

Request for Change

Zarządzanie zmianą rozpoczyna się od utworzenia przez Requestora wniosku o zmianę oprogramowania, upgrade systemu bądź wprowadzenia innych poprawek, które nie są związane z systemami SAP, jak np. naprawa laptopa lub drukarki. Wystarczy, że Requestor wprowadzi podstawowe informacje, takie jak tytuł zmiany, proponowany priorytet, informacje o systemie i szczegółowy opis problemu. Następnie wniosek zostanie 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, tworzona dla zmian, które nie są zbyt skomplikowane i pilne, zmian wymagających dobrej koordynacji i odpowiednich zatwierdzeń. Normal Change musi przejść szereg testów, zanim zostanie zaimportowana do systemu produkcyjnego. Zwykle ten typ zmiany jest związany ze standardowymi pracami nad utrzymaniem systemu. Podczas procesowania Normal Change zaangażowani zostają Developer, Tester, IT Operator i Change Manager.

Urgent Change

Urgent Change wykorzystuje się w przypadku poważnych problemów dotykających dużej liczby użytkowników oraz kluczowych procesów. Ten rodzaj zmiany jest w pełni zoptymalizowany do szybkiego procesowania, z zachowaniem pełnego nadzoru przez użytkowników zaangażowanych w realizację zmiany. Od Normal Change różni się automatyzacją fazy przeniesienia zmiany na system testowy i zmniejszeniem liczby kroków wymaganych od uczestników zmiany.

Retrofit

Retrofit to opcja pozwalająca na oddzielenie długoterminowych zadań w środowisku Development od zadań związanych z utrzymaniem systemu w środowisku Maintenance. 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 Maintenance powinny być również wprowadzone w taki sam sposób w środowisku Development, dla zapewnienia prawidłowego działania systemu produkcyjnego, do którego trafiają transporty z obu środowisk.

Wyszukiwarka, interfejs

Efektywne zarządzanie zmianą w Change Request Management umożliwia webowy interfejs: rozbudowany, lecz przejrzysty i ergonomczny, ułatwiający codzienną pracę ze zmianami. Jego największym atutem jest możliwość dopasowania go do potrzeb użytkownika.

Raportowanie

Do tworzenia raportów w ChaRM służy narzędzie ChaRM Reporting, które pozwala na generowanie raportów na podstawie daty utworzenia, wybranego projektu, priorytetu, typu zmiany, systemu i wielu innych dostępnych parametrów. Wyniki raportu są prezentowane w przejrzystej tabeli, w której widać podstawowe informacje o wniosku lub zmianie. Raporty mogą być również przedstawione w postaci graficznej.

Change Request Management – najważniejsze korzyści

Zastosowanie narzędzi Change Request Management w zarządzaniu zmianą pozwala wyeliminować najwięsze bolączki i ryzyka w całym procesie – od planowania, aż po przeniesienie zmian na system produktywny. Najważniejsze korzyści to:

  • zwiększenie wydajność dzięki zastosowaniu schematów zarządzania zmianami,
  • zmniejszenie kosztów zarządzania projektami i wykorzystania zasobów IT,
  • redukcja ryzyka wprowadzenia błędnych poprawek,
  • skrócenie fazy procesowania zmiany na systemach developerskich i testowych, a dzięki temu przyśpieszenie go-live,
  • automatyczne generowanie pełnej dokumentacji – od utworzenia wniosku, aż po zakończenie dokumentu zmiany.