Administracja i wsparcie administracji IT/SAP czy projekty z zakresu Basis to dla ludzi z biznesu czysta abstrakcja. Monitoring? Zarządzanie dostępem? Backupy? To zadania realizowane gdzieś w tle. Ale to działania niezbędne. Choć nie wszystko trzeba robić samemu. Warto weprzeć się stałą pomocą specjalistów.

W All for One Poland drużyna ponad 80 administratorów IT/SAP i konsultantów Basis czuwa nad dostępnością i ciągłością działania systemów klientów. Podzieleni na zespoły, specjalizujący się w różnych obszarach i technologiach codziennie nadzorują, ulepszają i rozwijają instalacje SAP klientów.

Rutynowe zadania codziennego monitoringu, projekty SAP Basis, prace przy konwersji do SAP S/4HANA czy migracja do chmury – konsultanci realizują prace zarówno dla międzynarodowych korporacji, klientów posiadających największe instalacje SAP w Polsce, jak i dla firm z sektora MŚP pracujących na jednosystemowych środowiskach. Nasz team wspiera dziesiątki instalacji utrzymywanych w SAP Managed Services, a także systemy zlokalizowane w siedzibie firmy czy u innych dostawców chmury dla SAP.

Usługi Managed Services nie zdejmują z szefa IT odpowiedzialności za SAP. Jednak delegowanie części lub wszystkich zadań do zewnętrznego partnera ułatwia codzienną pracę i „odsiewa” wiele niewdzięcznych, powtarzalnych czynności. A na urlopie naprawdę można wypocząć.

Poniżej nasi konsultanci opowiadają o zwykłych i niezwykłych zadaniach, codziennej rutynie administratora, a także złożonych projektach w wielosystemowych pejzażach SAP.

Teraz TechMon monitoruje

Paweł Janikowski

Niektóre procesy biznesowe naszych klientów są pozostawione same sobie i albo działają i problemów nie ma, albo problemy występują, o czym my, jako administratorzy systemu SAP, dowiadujemy się w chwili, gdy dany problem urośnie do wielkich rozmiarów i konieczne jest gaszenie pożaru. Czy tak zawsze musi być? Czy nie możemy tego jakoś uprawnić? Próbować zidentyfikować zagrożenie, zanim problem realnie wystąpi?

Z takim założeniem podszedłem do próby znalezienia rozwiązania dla zgłoszenia jednego z naszych klientów. Sam problem był dość trywialny (o czym niżej), natomiast wymagał dodatkowej konfiguracji, która nie była standardowo dostępna w Technical Monitoring SAP Solution Managera.
Pierwszym krokiem rozwiązania było zidentyfikowanie miejsca, w którym proces biznesowy „się przytyka”. To wymagało poznania logiki samego procesu.

Okazało się, że problem, z którym spotykał się klient, dotyczył prostego przetwarzania RFC pomiędzy systemami SAP PO a SAP ERP. Specyfika rozwiązania i bardzo duża liczba danych sprawiały, że potrzeba było więcej czasu na przetworzenie  – czasami wystarczało ok. 5 min. Dopiero po zakończeniu przetwarzania użytkownik mógł poprawie odczytać dane i korzystać z funkcjonalności.

Czas oczekiwana na wynik był dla użytkowników akceptowalny, jedynie brak informacji o tym, kiedy opóźnienie wystąpi i ile może potrwać, był czynnikiem dezorganizującym pracę. Z tego też względu podjąłem decyzję o wykonaniu dodatkowej konfiguracji w narzędziu Technical Monitoring, tak aby w przypadku wystąpienia „przytkania” na odpowiednio dużym, ustalonym wcześniej poziomie system informował dział techniczny za pośrednictwem wiadomości e-mail oraz SMS o możliwości wysokiego obciążenia systemu. A w przypadku gdy zaplanowane zadanie, które jest odpowiedzialne za transfer danych, wykonuje się dłużej niż zwykle, są informowane podmioty trzecie, że wyciągnięcie danych będzie możliwe z niewielkim opóźnieniem (15-minutowym).

To niestandardowe rozwiązanie do dzisiaj jest z powodzeniem wykorzystywane u klienta. To jeden z przykładów, jak w łatwy sposób możemy chociaż częściowo monitorować proces biznesowy.

Procedury ratujące IT

Daniel Hahn

W przypadków testów R&R (Restore and Recovery) często spotykanym problemem jest… ich kompletny brak.

Firma opracowuje i wdraża w procedury i standardy IT zapewniające bezpieczeństwo i ciągłość biznesu w razie awarii serwerów. Następnie zamawia audyt zewnętrzny. Audytorzy sprawdzili, wydali stosowne certyfikaty i pojechali. Procedury zostały stworzone poprawnie.

A potem nikt ich nie weryfikuje przez kilka kolejnych lat.

To niestety dość powszedni grzech w organizacjach IT. Popełnił go też jeden z naszych klientów. Procedury R&R zostały uruchomione raz, tuż po ich stworzeniu. Potem nigdy nie zostały powtórzone. Do zespołu administratorów dołączyli nowi ludzie, starzy odeszli, a procedury zostały zapomniane.

A tymczasem przez lata praktycznie nieprzerwanej pracy serwer bazodanowy, a konkretnie bazy danych bardzo się rozrosły. Gdy wreszcie z naszym udziałem przeprowadzono testy R&R według starych procedur, okazało się, że odtworzenie serwera nie jest możliwe na wcześniej wskazanych zasobach. Po prostu zabrakło miejsca.

Tym razem był to tylko „próbny alarm”. Klient zgodnie z naszymi rekomendacjami zamówił dodatkowy sprzęt i zwiększył dostępną przestrzeń. Kolejną naszą rekomendacją było cykliczne przeprowadzanie testów R&R oraz ich weryfikacja i aktualizacja.

Procedury bezpieczeństwa IT są jak sprzęt ratunkowy. Warto, by zawsze był sprawny i łatwo dostępny.

Misja: centralizacja

Grzegorz Zieliński

Jeden z naszych klientów, którego środowisko systemów SAP znacznie się rozrosło, zaobserwował znaczny wzrost czasu obsługi użytkowników przy tworzeniu kont, zarządzaniu uprawnieniami oraz odblokowywaniu i zmianie haseł. Przy rosnącej liczbie systemów/mandantów użytkownicy biznesowi zaczęli już zauważać wzrost czasu obsługi.

Klient zgłosił się do nas, oczekując rozwiązania problemu z administracją użytkownikami.

Zaproponowaliśmy rozwiązanie centralnego zarządzania użytkownikami (Central User Administration). Obecnie dzięki CUA administratorzy klienta mogą w łatwiejszy, tańszy i szybszy sposób zarządzać użytkownikami na wszystkich systemach SAP. Z jednego miejsca tworzą konta, zarządzają uprawnieniami oraz mogą zmieniać hasła czy odblokować konta. Zcentralizowane zarządzanie uprawnieniami jest dużo wydajniejsze. Poprawiło się także bezpieczeństwo, jeśli chodzi o uprawnienia dostępu do systemów i danych.

No i jeszcze jedno – co bardzo spodobało się naszemu klientowi – by korzystać z CUA, nie trzeba instalować dodatkowego systemu ani wykupywać nowych licencji.

Jeden zespół, jeden administrator bezpieczeństwa – z jednego miejsca może równocześnie wykonać zmianę dla użytkowników na wielu systemach. Zmiany wykonane w systemie centralnym są automatycznie przesyłane na systemy satelitarne za pomocą technologii SAP application link enabling (ALE). Nie ma już potrzeby logowania się na każdy system/mandant osobno.

Także zmiana w danych podstawowych konkretnego użytkownika (np. numer telefonu, nazwisko) jest automatycznie propagowana na wszystkie systemy, na których występuje.

CUA jest bardzo przydatne przy zarządzaniu zespołami, wdrażaniu nowych rozwiązań, zastępstwach pracowników itp. Ułatwia również zarządzanie licencjami przydzielonymi poszczególnym użytkownikom i pozwala mieć pełną nad nimi kontrolę.

Misja: Single Sign On

Michał Lorek

Integracja systemów SAP to temat znany od lat. Producent oprogramowania do integracji SAP proponuje narzędzia takie jak Central User Administration lub SAP SSO. Każde z nich ma jednak swoje ograniczenia – patrz CUA, lub wymaga zakupienia dodatkowej licencji – jak SAP SSO.

Co jednak, jeżeli przedsiębiorstwo posiada już narzędzie do logowania za pomocą Single Sign On i chciałoby dokonać integracji z systemem SAP, tak by zniwelować konieczność kilkukrotnego logowania?

Podczas wdrożenia SAP Fiori klient poprosił nas o zweryfikowanie możliwości wykorzystania platformy autoryzacyjnej, której używał przy dostępie do innych, wewnętrznych systemów do logowania do SAP FIori Launchpada. Wystarczyło podanie służbowego adresu e-mail i jednokrotne wpisanie hasła i już użytkownik uzyskiwał dostęp do innych systemów w przedsiębiorstwie. Integracja pozwala nam uniknąć konieczności wykonania ponownego logowania. Bez dwóch zdań – to zwiększyłoby komfort użytkowania SAP Fiori.

Z pomocą przyszedł nam protokołu SAML2, który jest wykorzystywany do pośredniczenia w uwierzytelnianiu i automatycznym przekazywaniu między systemami i aplikacjami informacji o uprawnieniach użytkownika. Warto podkreślić, że do logowania można wykorzystać aplikację każdego dostawcy tożsamości (IdP) pozwalającego na wykorzystanie SAML (np. Azure ADFS, Google).

Podstawowa konfiguracja rozwiązania w systemie SAP ogranicza się do aktywacji odpowiednich węzłów ICF (Internet Communication Framework) oraz utworzenia tzw. Local Providera po stronie systemu SAP i dostawcy tożsamości, a także wymiany danych dotyczących providerów za pomocą wygenerowanych plików *.xml).

Później należało tylko skonfigurować mapowanie pola, po którym użytkownik będzie rozpoznawany w systemie SAP. Może to być np. nazwa użytkownika, adres e-mail, nazwisko lub inne pole.

I już. Teraz pracownicy naszego klienta mogą cieszyć się działającym logowaniem SSO.

Myśl przyszłościowo

Józef Kurnatowski

Cykl życia środowiska SAP we wszystkich przedsiębiorstwach jest mniej więcej podobny. Pierwszy i drugi rok po wdrożeniu to okres, gdy po pomyślnym przeprowadzeniu projektu system działa stabilnie i satysfakcjonująco. W tym czasie klient buduje zespół, który zdobywa i rozwija kompetencje. W trzecim i czwartym roku zwiększająca się świadomość biznesu prowokuje mnóstwo zmian, kolejne wdrożenia nowych funkcjonalności angażują dotychczasowy zespół w sposób przekraczający jego możliwości czasowe. W nieskończonym czasie można zrobić wszystko. Szkopuł jednak tkwi w tym, że czas jest jedyną skończoną i nieprzedłużalną wartością. Możliwości rozbudowy zespołu w wielu płaszczyznach są często po prostu fizycznie niemożliwe (brak specjalistów, ograniczony budżet itp.).

Jeśli stajesz przed jednym z tych wyzwań: kompetencje, skala, złożoność – to dobra widomość jest taka, że z podobnymi wyzwaniami mierzyli się już inni. Nie znam co prawda uniwersalnego rozwiązania dla wszystkich. Wiem jednak, że zespół, który tworzymy, poradził sobie z bardzo ciekawymi i trudnymi sytuacjami. A to za sprawą ciągłego doskonalenia na każdej płaszczyźnie.

Kompetencje to ustawiczny wyścig zbrojeń. Jak już opanujemy dane zagadnienie czy technologię, to okazuje się, że SAP ją rozwinął, zmienił, poprawił czy wręcz wywrócił do góry nogami – mobilizując nas do nauki. Szkolenie ADM100 nazywa się tak samo od lat, ale zawartość i treści są nie do poznania. Treści są nie do poznania. Podobnie infrastruktura. A złożoność projektów wdrożeniowych? Dekadę temu był to po prostu SAP ERP. Dziś mamy S/4, CRM, GW, Fiori, WebDispatcher, SAC. Do tego HANA, IaaS, SaaS…

Potrzeby biznesu będą coraz większe. Warto w tym momencie skoncentrować się na głównym pytaniu – jaki jest core działania naszej firmy? Jeśli nie jest to IT, to niemal z definicji szkoda energii na próbę wynajdowania koła na nowo. Oczywiście nie chodzi o to, że mała, średnia czy duża organizacja nie potrzebuje specjalistów IT. Wręcz przeciwnie, potrzebuje ich, są niezbędni do koordynowania prac. Nikt nie zastąpi ich znajomości organizacji i procesów biznesowych. To dzięki ich wiedzy współpraca z organizacją serwisową taką jak nasza jest możliwa na satysfakcjonującym dla wszystkich poziomie.

Zbierając doświadczenia własne, ale także od wielu klientów, jestem przekonany, że opcja, w której istotne dla bezpieczeństwa i optymalnego działania systemów działy infrastruktury IT i SAP Basis są outsourcowane, a energia kluczowych specjalistów IT skierowana jest na rozwój i koordynację, jest optymalna.

Gotowi na S/4

Tomasz Czubaszek

Zadanie: aktualizacja trójsystemowego pejzażu systemów SAP non-unicode EHP4 for SAP ERP 6.0 do EHP8 for SAP ERP 6.0. Ograniczenia techniczne wymusiły w pierwszym kroku konwersję SAP do standardu unicode.

Konwersja implikuje wykonanie migracji systemów, zatem zostały one przeniesione na nowy system operacyjny (Windows Server) oraz najnowszą wersję bazy danych (MS SQL Server).

Pejzaż systemów SAP tego klienta miał już swoją historię – liczne dostosowania, rozwiązania własne oraz produkty innych dostawców. W konsekwencji konwersja wymagała koordynacji współpracy konsultantów technicznych, aplikacyjnych oraz dostawców rozwiązań autorskich, które miały działać także po migracji.

Wielkość wyjściowej bazy danych systemu produkcyjnego oraz długość okna serwisowego narzuciły scenariusz równoległego eksportu i importu. Poziom wypełnienia bazy danych oscylował około 1.7 TB. Cała faza niedostępności oraz testy musiały zmieścić się w weekendowej przerwie serwisowej. Ze względu na wielkość bazy danych, liczbę zadań i zaangażowanych stron nie było miejsca na błędy i opóźnienia.

Dużym wyzwaniem okazała się migracja ogromnej tabeli będącej częścią działającego produktu innego dostawcy. Stanowiła ona prawie połowę wielkości całej bazy systemu. Zarówno jej wielkość, jak i binarna zawartość wymusiła konieczność manualnej optymalizacji procesu jej migracji. Dzięki elastyczności w przypisywaniu zasobów, jaką umożliwiło utrzymywanie systemów w modelu Managed Cloud, optymalizacja była możliwa na kopii systemu w odseparowanym środowisku. Mogliśmy też istotnie powiększyć zasoby maszyn na czas migracji, bez generowania dodatkowych kosztów dla klienta. Ostatecznie system został zmigrowany pomyślnie, z dużym zapasem czasu serwisowego.

W pierwszych dniach produkcyjnego użytkowania system był objęty dedykowanym wsparciem pomigracyjnym naszych konsultantów. W kolejnej fazie wykonaliśmy upgrade techniczny do EHP8.

Obecnie system spełnia wymagania do ewentualnej konwersji do S/4HANA w modelu one-step approach, którego podstawowym wymaganiem jest system źródłowy w standardzie unicode.

SAP NetWeaver 7.40 był ostatnim wydaniem wspierającym standard non-unicode. Z tego względu upgrade’y starszych systemów pociągają za sobą konieczność wykonania konwersji jako krok poprzedzający projekt zmiany wersji oprogramowania SAP.

W 2020 r. firma SAP wydłużyła standardowe wsparcie dla systemów SAP Business Suite do końca 2027 r. W ten sposób dała swoim klientom dodatkowy czas na przesiadkę na S/4HANA. Mając na względzie niepewne czasy, dominujące w firmach roczne cykle budżetowe, czas trwania projektów migracji do S/4HANA oraz możliwe ich spiętrzenie na rynku usług, warto ten czas dobrze wykorzystać.

Trafić w oczekiwania

Szymon Grzegorek

Przyjęło się, że głównym zadaniem koordynatora usługi serwisowej jest wysłuchiwanie narzekań klienta na jakość i czas obsługi zgłoszeń serwisowych, a potem wystawianie faktur za zrealizowane zadania lub dostarczane zasoby. Nie u nas. W All for One Poland stworzyliśmy własną definicję roli koordynatora klienta. To reprezentant, adwokat klienta w naszych strukturach, wyposażony w szereg narzędzi i kompetencji, koniecznych, by trafić w oczekiwania klienta.

Po pierwsze stawiamy na stały kontakt, który buduje relacje zaufania. Służą temu regularne spotkania (choć teraz raczej w formie telekonferencji). Po drugie naszą ambicją jest zaawansowana znajomość środowiska systemów klienta, zdobywana nie tylko „w boju”, przy rozwiązywaniu problemów czy stawianiu czoła wyzwaniom rozwoju środowiska. Tworzymy i utrzymujemy aktualną dokumentację wspieranych systemów. Nie możemy polegać tylko na naszej pamięci.

Doświadczony koordynator potrafi rozpoznać potrzeby klienta, zanim on sam stanie się ich świadomy, i wesprzeć go w odpowiednim kreowaniu oczekiwań wobec partnerów zewnętrznych, a czasem wręcz ograniczać koszty planowanych inwestycji, wskazując inne efektywne rozwiązania.

Ale system to tylko narzędzie. Liczy się biznes. Koordynator będący w stałym kontakcie z klientem dobrze zna specyfikę pracy klienta i potrafi pogodzić konieczne prace serwisowe z wymaganiami procesów biznesowych.

Cenne też nieszablonowe podejście do problemu – a szczególnie jego efekty. Jeden z naszych klientów borykał się z problemami wydajnościowymi na systemie SAP w narzędziu stworzonym przez jego zespół programistów. Aplikacja była całkowicie niezależna od standardu systemu i z tego powodu proces analizy kodu nie mógł być zgłoszony do SAP. Klient, korzystający z naszych usług administracji SAP, poprosił nas o tę analizę. Koordynator wyszukał w organizacji konsultanta o odpowiednich kompetencjach i zaangażował go do tego niestandardowego zadania. W czasie analizy konsultant doszedł do wniosku, że przyczyną problemu z wydajnością był silnik bazy danych SAP Adaptive Server Enterprise. Zgłosiliśmy to do producenta oprogramowania. Po niespełna tygodniu SAP wydał poprawkę dla Sybase, która wyeliminowała problem. Początkowo dostępna tylko dla naszego klienta, poprawka została następnie umieszczona w oficjalnym Service Path tej bazy danych.

Siła wiedzy

Radosław Owczarzak

Jedna z firm będących naszym klientem przeprowadzała zmiany organizacyjne. To zawsze wiąże się z potrzebą utworzenia nowych autoryzacji oraz ról, które będą odzwierciedlały nową strukturę. Administratorzy SAP u klienta często dokonują drobnych zmian w ramach istniejących już na systemie ról, nie mają jednak doświadczenia w projektowaniu i tworzeniu ról od podstaw. To zadanie warto też wykonać według dobrych, przetestowanych metod, a ich znajomość nie jest powszechna wśród adminów SAP.

Tak też było w tym przypadku, dlatego klient zgłosił się do nas z prośbą o pomoc w utworzeniu nowych ról. Zadanie przypadło mi. W zasugerowałem, jakie procedury będą najbardziej przydatne do sprawnego utworzenia ról oraz pomogłem w technicznym aspektach ich implementacji.

Administratorzy często korzystają z transakcji SU53. Nieźle się sprawdza przy mniejszych zmianach, jednak gdy zachodzi potrzeba dokonania większych zmian lub utworzenia ról od podstaw, okazuje się, że to narzędzie nie jest wystarczająco wydajne. Zamiast tego poinstruowałem administratorów klienta, jak mogą wykorzystywać trace z transakcji STAUTHTRACE. Narzędzie to służy głównie do prześledzenia, jakie obiekty autoryzacyjne są sprawdzane przez SAP, kiedy użytkownik wykonuje swoją pracę.

Chcąc stworzyć role za pomocą tego narzędzia, administrator tworzy użytkownika testowego z pełnymi uprawnieniami. Następnie pracownik wykonuje swoje zadania na użytkowniku testowym. W dalszej kolejności administrator na podstawie zapisanych danych jest w stanie utworzyć rolę odpowiadającą stanowisku zajmowanemu przez danego pracownika. Wymaga to oczywiście pewnego doświadczenia, ponieważ analiza wyników trace potrafi być dość złożona.

W tym przypadku pomagałem administratorom klienta w analizie oraz przeszkoliłem ich pod tym kątem, tak by w przyszłości byli w stanie korzystać z transakcji STAUTHTRACE w swojej pracy.

Efekt tego zgłoszenia serwisowego jest następujący: nie tylko utworzyłem w systemie klienta potrzebne role, ale przekazałem też wiedzę, która zdecydowanie przyda się jego administratorom w sprawniejszym wykonywaniu ich zadań.