Biznes, transformacja, SAP

Transformacje środowisk SAP to niełatwe tematy, gdyż w grę wchodzą zmiany dotyczące jednocześnie warstwy aplikacyjnej SAP, danych w systemie, platformy technicznej, a także aspektów licencyjnych. Do zmian wymuszonych przez biznes dochodzą konieczne transformacje technologiczne, jak na przykład migracja do chmury czy przejście z SAP ERP/ECC na S/4HANA. Dodajmy do tego jeszcze skalę organizacji, których dotyczy wiele takich projektów – złożoność organizacyjną i prawnoformalną, rozległość funkcjonalną i technologiczną pejzażu SAP, wolumen danych, ilość pracowników, zaangażowanych w projekt…

Każda z tych transformacji może być wykonana sprawniej dzięki gotowemu, sprawdzonemu w tysiącach projektów, oprogramowaniu SNP. Nasz software  pozwala zautomatyzować liczne czynności projektowe, takie jak migrację danych czy testowanie procesów. To skraca czas projektu i redukuje ryzyko błędów.

Do tego unikalne podejście SNP Bluefield wspiera możliwość wykonania kilku różnych transformacji biznesowych i technologicznych środowiska SAP w ramach jednego projektu, z jednym harmonogramem i jednym go-live. To prawdziwa rewolucja w porównaniu do tradycyjnego podejścia, wymagającego realizowania kilku osobnych projektów.

Wszystko po to, by niższym kosztem i w krótszym czasie dokonać transformacji – z minimalnym czasem przestoju systemu dla biznesu (Near Zero Downtime).

Przypatrzmy się teraz wybranym scenariuszom transformacji biznesowych.

 Fuzje (ang. Merges)

Scalenie systemów lub części jego elementów jest jednym z najtrudniejszych procesów, z jakimi spotykają się analitycy. Łączyć możemy części systemu, całe systemy zarządzania IT, archiwa, a nawet same funkcje systemowe – czy to w kontekście całych aplikacji, czy ich części.

Decyzja o połączeniu systemów zazwyczaj zostaje podjęta naturalnie w przypadku, gdy jedno większe przedsiębiorstwo przejmuje inne lub kiedy kilka podmiotów zamierza się połączyć. Co ciekawe, połączenie systemów informatycznych nie zawsze wiąże się z połączeniem firm z punktu widzenia konsumenta. Jednostki gospodarcze, będące własnością nowego podmiotu, zostają połączone w jeden system korzystający fizycznie z tej samej infrastruktury, ale tak samo, jak przed zmianą, mogą pozostać niezależnymi firmami.

Trudność procesu scalenia wynika z faktu, że pomimo wspomnianej wyżej niezależności, niektóre z funkcji technicznych systemów IT muszą być współdzielone. Nachodząca na siebie numeracja dokumentowa, zduplikowane numery dostawców i klientów czy takie same indeksy materiałowe dotyczące fizycznie różnych produktów, to tylko niektóre z problemów wymagających często głębokiej analizy. Szczególnie utrudnionej, gdy dojrzałe przedsiębiorstwo korzysta z dobrodziejstw szerokiej gamy dostępnych modułów funkcjonalnych SAP i ma życzenie uwzględnić w migracji wszystkie dane historyczne.

Połączenia zazwyczaj są przeprowadzane na jednym z już istniejących systemów. Jeśli nie ma żadnych przeciwwskazań wynikających z istniejącej infrastruktury, jako system docelowy zazwyczaj wybiera się ten posiadający największy wolumen danych. Naturalnie wynika to z konieczności przeniesienia mniejszej ilości danych. System, z którego dane będą przenoszone, nazywamy wówczas systemem źródłowym.

Podziały (ang. Splits)

W odróżnieniu od fuzji, podział będzie jednym z łatwiejszych procesów pod kątem złożoności. Konieczność wydzielenia części danych z systemu przedsiębiorstwa może następować wówczas, gdy sprzedało ono część swojego biznesu lub uznało za niezbędne do dalszego działania rozdzielenie danych, na przykład z powodu decentralizacji infrastruktury.

System możemy podzielić, biorąc pod uwagę każdą dostępną jednostkę organizacyjną (lub kilka z nich). Wówczas część danych przenoszonych jest na nowy system (docelowy) na podstawie ściśle zdefiniowanych selekcji, a odpowiednie dane na systemie źródłowym są usuwane.

Szczególną uwagę w takich przypadkach należy zwrócić na to, aby przeniesione zostały tylko właściwe dane wraz ze wszystkimi powiązanymi elementami pozwalającymi na ich poprawne działanie (dane konfiguracyjne + dane podstawowe + dane transakcyjne). W przypadku, gdy przeniesionych danych będzie zbyt mało – na nowym systemie mogą one być niekompletne, niespójne czy nawet całkowicie niedostępne. W przypadku, gdy przeniesiemy zbyt wiele danych, powstanie ryzyko, że dane dostaną się w niepowołane ręce. Niezwykle ważna w tym momencie będzie funkcjonalna wiedza konsultantów. Podczas fazy testowania powinni oni zidentyfikować wszelkie punkty wymagające dopracowania tak, aby tylko należyta ilość danych została ujęta w migracji.

Harmonizacje (ang. Harmonizations)

Podobnie jak fuzje, harmonizacje cechują się wysokim stopniem skomplikowania procesu. Dotyczą one zazwyczaj czynności wykonywanych w obrębie jednego, istniejącego już systemu. Zakładają uporządkowanie danych względem określonych reguł, wykonywanych w odpowiedniej, ściśle zdefiniowanej sekwencji. Harmonizacje mogą być wykonywane w przypadku, gdy w przedsiębiorstwie wymagana jest reorganizacja obiektów kontrolingowych, połączenie jednostek gospodarczych, przeniesienie zakładów, zmiana planu kont etc. Są one często wymuszane zmianą uwarunkowań prawnych w kraju, gdzie prowadzona jest działalność gospodarcza albo chęcią uporządkowania danych w celu zwiększenia efektywności raportowania. Mogą też służyć przygotowaniu przed inną dużą zmianą systemową.

Omawiając typy zmian organizacyjnych, wpływających na pejzaż systemów ERP, warto podkreślić, że nie jest to sztywny podział oferowanych przez nas usług. Wiele z wyżej wymienionych sposobów łączenia, rozdzielenia, przeniesienia czy harmonizacji danych może być stosowanych w sposób łączony i przeprowadzany w tym samym czasie. Harmonizacja danych kontrolingowych może przebiec równocześnie podczas procesu łączenia jednostek gospodarczych, a podniesienie systemu do S/4HANA podczas ich wydzielania.

Tworzenie różnego typu projektów hybrydowych jest możliwe i w zależności od skomplikowania determinuje czas projektu i zasoby potrzebne do jego przeprowadzenia. Na tym właśnie polega siła podejścia SNP Bluefield.

Przestoje systemowe i ich minimalizacja

Wspominając o dostępnych scenariuszach transformacyjnych, warto zwrócić również uwagę na problematyczne aspekty ich wprowadzania. Wszelkie modyfikacje, które mają być implementowane na nowym lub już istniejącym systemie, wymagają planu działań oraz czasu na ich implementację. O ile praca koncepcyjna może zostać przeprowadzona bez wpływu na system i użytkownika końcowego, o tyle sama implementacja na systemie produkcyjnym może powodować poważne przestoje wynikające z potrzeby jego wyłączenia z użytkowania na czas migracji.

W wielu firmach każda minuta niedostępności systemu produkcyjnego może zostać przeliczona na konkretną stratę. Lekiem na powyższe jest koncepcja NZD – Near Zero Downtime. Podejście znacznie skraca przestoje, gdyż wszelkie zmiany wprowadzane są na kopiach tabel, a ich implementacja może być wykonana w zaplanowanym wcześniej przestoju weekendowym.

Przegląd scenariuszy transformacyjnych

SNP, czyli porządek w transformacji

Aby opisywane powyżej zmiany mogły zostać skutecznie zastosowane w złożonym systemie, jakim jest SAP, jego struktura oraz procesy powinny zostać odwzorowane wraz ze wszelkimi występującymi zależnościami. Wówczas, stosując selekcje na wysokim poziomie organizacyjnym, możemy uwzględnić w migracji jedynie wymagane moduły i wszystkie zależne jednostki organizacyjne, minimalizując ryzyko niespójności lub niekompletności danych.

W tym celu stosujemy podejście polegające na sekwencyjnym procesie uprzednio zaprogramowanych czynności, które w połączeniu z funkcjonalną wiedzą konsultantów i gotowym oprogramowaniem gwarantują sukces przedsięwzięcia. Oferowane rozwiązania od 2019 r. są dostępne w ramach scenariuszy platformy CrystalBridge i wspierają:

• wizualizację danych, która pomaga w fazie analizowania systemu i planowania projektu,
• realizację projektu, np. SNP Empty Shell (obecnie moduł Shell), dzięki któremu szybko i łatwo stworzymy powłokę systemu docelowego bez danych,
• konwersję powłoki systemowej względem wymagań docelowego systemu bez negatywnego wpływu na migrowane w kolejnych krokach dane,
• migrację, np. SAP Landscape Transformation lub SNP Transformation Cockpit (obecnie narzędzia modułu Transformation platformy CrystalBridge), pozwalające na selektywne przenoszenie danych z możliwością ich modyfikacji „w locie”.

Dzięki SAP Landscape Transformation, w kilku krokach możemy przeprowadzić analizę systemową na podstawie rzeczywistych danych, oceniającą pracochłonność wydzielenia jednostki gospodarczej lub wymagane w tym celu zmiany konfiguracyjne. Wyniki są przedstawiane w formie czytelnego raportu, który można przedstawić klientowi. Narzędzie pozwala na skorzystanie z jednego z wielu zdefiniowanych wcześniej scenariuszy, które przewidują modyfikację wszystkich obszarów systemowych, których dotyczy planowana zmiana. Korzystając z dostępnych scenariuszy, możemy na przykład:

• przeprowadzić analizę zakresu numeracji w systemie,
• wykonać konwersję planu kont,
• przeprowadzić analizę kodu ABAP,
• przeprowadzić połączenie jednostek gospodarczych lub innych,
• porównać konfigurację systemową,
• oszacować czas przeprowadzenia danego projektu na podstawie rzeczywistych danych i zasobów,
• stworzyć własny scenariusz i zdefiniować określone kroki w zadanej kolejności.

Za pomocą SNP Transformation Cockpit, możemy prowadzić złożone projekty, mając pod kontrolą wszelkie dostępne selekcje oraz dostosowywać reguły migracji danych wedle życzenia klienta. Migracja odbywa się za pomocą obiektów, które są odniesieniem do konkretnych zakresów danych podzielonych na grupy wewnątrz każdego modułu funkcjonalnego SAP. Dzięki SNP Transformation Cockpit możemy w szybki sposób zastosować wszystkie niestandardowe wymagania klienta oraz monitorować efektywność migracji poprzez odpowiednie sterowanie zasobami systemowymi.

Case study: połączenie zakładów

Poprawna migracja danych jest niezbędnym warunkiem wymaganym do funkcjonalnego uruchomienia systemu. Niestety praktyka pokazuje, że bardzo rzadko udaje się przewidzieć wszystkie problemy, jakie mogą wystąpić podczas tego procesu. Korzystając ze specjalistycznych narzędzi, możemy jednak szybciej zlokalizować przyczynę nieprawidłowości i w łatwy sposób ją skorygować.

Jednym z ciekawszych przykładów praktycznego wykorzystania autorskich narzędzi SNP jest projekt połączenia zakładów w obrębie jednej jednostki gospodarczej w niemieckiej firmie produkcyjnej. Projekt został zaplanowany w trzech fazach przeprowadzonych równocześnie:

• analiza użycia domeny z zawartością (tzw. domain usage with content) wykrywająca, gdzie dotychczas wykorzystywane były łączone zakłady,
• skanowanie kodu ABAP pod kątem wymaganych zmian dla pola „zakład” lub dla wartości tego pola,
• analiza użycia tabel pod kątem spójności numeracji, wystąpienia duplikatów po zmianie wartości pola „zakład” i generalnej spójności danych podstawowych i transakcyjnych po konwersji.

Powyższe analizy zostały przekazane konsultantom funkcjonalnym, którzy na ich postawie rozpoczęli prace przygotowujące odpowiednie obiekty aplikacyjne w SNP Transformation Cockpit. Na podstawie analizy użycia domeny z zawartością, określili oni także zakres projektu oraz oszacowali czas potrzebny na prace przygotowawcze. Czas potrzebny na techniczne wykonanie konwersji został określony na podstawie dostępnych zasobów systemowych. Zostały dokładnie określone ramy czasowe wszystkich faz projektu i zaplanowana data uruchomienia (go-live date).

Skanowanie kodu ABAP było niezmiernie istotnym krokiem projektu. Każda linijka kodu użytego w systemie SAP została przeszukana pod kątem ciągu znaków określających techniczne pole „zakład” lub wspomnianej wyżej wartości tego pola przed i po konwersji. Analiza wskazała wszystkie miejsca w kodzie, które wymagały działania. Poprawki zazwyczaj dotyczyły klienckich programów, w których wykorzystana wartość w polu zakład została wpisana ręcznie (tzw. hardcoded). Każdy z programów został sprawdzony pod kątem spójności, a poprawki zostały uwzględnione w dokumentacji.

Narzędzia SNP pozwalają na wprowadzanie zmian w tabelarycznym systemie SAP. Jednak tylko te zmiany, które nie naruszają spójności danych, zapewnią poprawne działanie aplikacji. Analiza użycia tabel pod kątem wymaganych zmian pozwoliła na uniknięcie problemów związanych z duplikatami w tabelach na poziomie pól kluczowych czy nachodzących na siebie numeracji związanych ze zmienianym zakładem.

Przemyślana koncepcja projektu sprawiła, że klient otrzymał dokładne ramy czasowe projektu. Został poinformowany o wszystkich wymaganych zmianach i konsekwencjach, jakie się z nimi wiążą. Wszystkie powyższe czynniki miały istotny wpływ na sukces projektu oraz wysoki poziom zadowolenia klienta.

Case study: harmonizacja planu kont

W przypadku, gdy znaczący producent kosmetyków planował przeprowadzić harmonizację planu kont w swoim systemie, SNP rekomendowało użycie rozwiązania SAP Landscape Transformation. Narzędzie umożliwia zdefiniowanie szablonu projektu, który będzie gotowy do wykorzystania po odpowiednim przygotowaniu systemu.

Sugerowany szablon projektu to zbiór ustandaryzowanych metod, programów i tabel. Wykorzystanie ich w określonej sekwencji zdefiniowanej w aplikacji, umożliwia przeprowadzenie czynności odnoszących się do wykorzystywanego planu kont:

• zmiany nazwy planu kont, samych kont i/lub elementów kosztowych,
• połączenie planu kont, kont i/lub elementów kosztowych,
• przypisanie planu kont do innej jednostki gospodarczej.

Powyższe działania mogą być kombinowane i stosowane w zależności od zakresu projektu, życzenia klienta lub specyfikacji systemowej.

Zanim jednak przeprowadzona została konwersja testowa, klient musiał odpowiedzieć sobie na kilka pytań. Pierwsze z nich odnosiło się do rozmiaru bazy danych systemu i tego, jaki miała ona wpływ na konwersję systemu produkcyjnego. SAP LT pozwolił na przeprowadzenie analizy szacującej czas wykonywania konwersji. Dzięki temu klient mógł zaplanować przerwę w działaniu systemu produkcyjnego, a jeśli wynik analizy określający długość wymaganej przerwy przekroczyłby dopuszczalną przez niego długość, mógł rozważyć użycie innego narzędzia. Kolejne pytanie odnosiło się do zakresu projektu. Analiza archiwów identyfikowała wszystkie przebiegi archiwizacyjne w celu określenia powiązanych tabel i struktur związanych z konwertowanym planem kont. Natomiast analiza na poziomie aplikacji i wariantów wskazała wszystkie elementy używane w rozwiązaniach branżowych i klienckich, które podlegały konwersji. W kolejnym kroku został również przeprowadzony szczegółowy skan kodu systemowego. Posłużył on analizie wszystkich programów i miejsc wymagających zmian. Opracowane wyniki analiz zostały przedstawione klientowi. Wszelkie wymagane poprawki zostały naniesione na system, a klient świadomy zmian, mógł przekazać raporty zainteresowanym użytkownikom końcowym.

Wszystkie powyższe działania przygotowawcze sprawiły, że projekt przebiegł bez większych problemów, a uporządkowany system wpływa pozytywnie na wydajność w codziennie wykonywanych czynnościach przez użytkowników na całym świecie.

SAP Landscape Transformation Portfolio

Korzyści z transformacji

W dynamicznym otoczeniu rynkowym wygrywa ten, kto pierwszy dostrzeże zmianę. Aby jednak dostosowanie się do niej przyniosło korzyści, adaptacja przedsiębiorstwa powinna przebiec w sposób sprawny i przemyślany. Specyfika migracyjnych narzędzi SNP pozwala na przeprowadzanie zmian przy minimalizacji ryzyka niepowodzenia oraz dokładne oszacowanie pracochłonności projektu. Koncepcje projektów tworzone są z dbałością o spójność danych, aby funkcjonalny start systemu przebiegł płynnie, a klient mógł cieszyć się sprawnym systemem zaraz po wprowadzeniu wymaganej zmiany.