Nowe procesy i dostosowania muszą zostać gruntownie przetestowane. Aby spełnić te wymagania, struktury systemów składają się z kilku poziomów. Zapewnione są dedykowane systemy do prac rozwojowych, testowania, oceny, testów akceptacyjnych i wreszcie – dla systemu produktywnego, w którym następnie wdrażane będą produktywne procesy biznesowe. Testy, obejmujące wiele informacji, wymagają realistycznych danych, które w idealnym przypadku opierają się na rzeczywistych danych produktywnych.

Dane testowe – podjęcie wyzwania

Z dostarczaniem danych testowych wiąże się wiele wyzwań. W dobie dużych zbiorów danych (Big Data) wymagania dotyczące przestrzeni dyskowej i wynikające z tego koszty stale rosną. Aplikacje biznesowe rozwijają się bardzo dynamicznie, co również zwiększa złożoność samych aplikacji i ich wzajemnych relacji w procesach biznesowych.

To komplikuje testowanie, zmuszając zarówno działy biznesowe, jak i działy IT do bardzo elastycznego reagowania – od wdrażania projektu, poprzez zapewnienie infrastruktury i środowiska testowego. Środowiska testowe narzucają dodatkowe wymagania, ponieważ, w przypadku różnych projektów, konieczne są specyficzne środowiska testowe i dane, często wymagające wykonania wielu prac ręcznie.

Podsumowując, wszystkie te powody prowadzą do dużej liczby systemów, zwiększonych wymagań dotyczących pamięci masowej, a zatem bardzo wysokich kosztów operacyjnych.

Inteligentne produkty. Optymalne wyniki

By sprostać wymaganiom z niezbędną elastycznością i jednocześnie optymalizować koszty, potrzebujesz produktów, które idealnie wspierają projekt i w wysokim stopniu automatyzują działania. Nasze produkty SNP Data Provisioning & Masking (SNP DPM) oraz SNP Rapid Empty Shell Creation (SNP RESC) właśnie to zapewniają, pomagając w pełni sprostać aktualnym i przyszłym wymaganiom, aby zagwarantować elastyczność i konkurencyjność, które są istotnymi aspektami dla każdej firmy.

SNP DPM może dostarczyć danych testowych w celu optymalizacji procesów testowych. W czasie wdrożenia możliwość zmniejszenia objętości danych testowych za pomocą elastycznych kryteriów redukuje wykorzystanie pamięci systemu i znacznie obniża koszty operacyjne.

Funkcje maskowania danych podstawowych i danych transakcyjnych pomagają w prawidłowym spełnieniu wymagań dotyczących ochrony danych. SNP RESC stanowi doskonałe uzupełnienie SNP DPM. Podczas gdy SNP DPM aktualizuje i maskuje dane testowe w istniejących systemach, SNP RESC służy do szybkiego tworzenia nowych, nieproduktywnych systemów, które opierają się na istniejących systemach, na przykład w zakresie procesów DevOps. SNP RESC może wygenerować powłokę systemu – kopię systemu źródłowego bez danych podstawowych i danych transakcyjnych – w jednym kroku. To znacznie przyspiesza procedurę kopiowania, a jednocześnie znacząco zmniejsza wymagania dotyczące przestrzeni dyskowej dla nowo tworzonego systemu. Te systemy z powłokami mogą być tworzone regularnie lub na żądanie.

Połączenie obu tych produktów zapewnia ogromną elastyczność. Pierwszy krok to wykorzystanie SNP RESC do udostępnienia docelowego systemu jako systemu z powłokami. W drugim kroku SNP DPM selektywnie przesyła maskowane lub niemaskowane dane testowe do tego docelowego. SNP DPM może aktualizować te dane ponownie, wiele razy, po naciśnięciu jednego przycisku.

Wymagania w zakresie struktury

Wymagania stawiane w projektach informatycznych oraz przez użytkowników stają się coraz trudniejsze do spełnienia w ramach struktury systemów. Różne systemy w strukturze podlegają automatycznie różnym wymaganiom w zakresie czasu wdrożenia i ilości wymaganych danych testowych. Różna jest również złożoność danych. Tylko dzięki korzystaniu z takiego oprogramowania jak SNP RESC i SNP DPM można zagwarantować niezbędną elastyczność, zmniejszyć koszty i zminimalizować zakres prac wykonywanych ręcznie poprzez zwiększenie automatyzacji.

Bardzo rozbudowane struktury systemowe SAP często składają się z dużych lub wielu zależnych systemów. Te struktury muszą optymalnie wykorzystywać istniejące oprogramowanie, a określone wymagania i środowiska systemowe należy brać pod uwagę od samego początku. W związku z tym zalecamy sformułowanie planu wykorzystania oprogramowania wspomagającego przez IT i dział projektowy przed rozpoczęciem projektu, ponieważ uwzględnione zostaną wszystkie wymagania. Przeprowadzenie szczegółowej analizy z wyprzedzeniem i wprowadzenie wynikającej z niej koncepcji może pomóc w zapobieganiu niespodziankom i problemom podczas użytkowania operacyjnego. Dzięki konfiguracjom SNP RESC i SNP DPM wdrożonym na początku, można ich używać na późniejszym etapie jako szablonów.

Podejście projektowe

Zalecamy następujące podejście przy przeprowadzaniu projektu danych testowych.

Krok 1: faza analizy

W fazie analizy identyfikujemy i oceniamy wszystkie wymagania odpowiednich działów oraz projektów. Wykorzystujemy również tę fazę, aby uzyskać pełny obraz zaangażowanych systemów. Jest to wykonywane za pomocą SNP System Scan. Oprogramowanie dostarcza wstępnych, wyczerpujących informacji na temat zaangażowanych systemów. Podczas gdy niektóre z tych informacji mają charakter techniczny, SNP System Scan dostarcza również informacji dotyczących stosowanych modułów i jednostek organizacyjnych, co okazuje się niezwykle przydatne również później – przy definiowaniu kryteriów redukcji.

Kolejna analiza tabeli z SNP DPM jest jeszcze bardziej szczegółowa. Dostarcza istotnych informacji o poziomach wypełnienia standardowych tabel SAP oraz o istniejących tabelach klientów lub tabelach innych firm. Pozwala to określić, czy nadal istnieje potencjał redukcji dodatkowych obiektów wykraczających poza standardowe kryteria redukcji przedziału czasowego lub jednostek organizacyjnych. Jest to szczególnie istotne w przypadku tabel klientów.

Ponadto należy rozważyć i ocenić odpowiednie procesy biznesowe wraz z zaangażowanym działem i wziąć te procesy pod uwagę przy opracowywaniu koncepcji danych testowych. SNP DPM może implementować podmioty i koncepcje przedstawiające obiekty biznesowe, a następnie przekazywać im dane testowe (w tym zależności) z systemu produktywnego do systemu nieproduktywnego w sposób dedykowany. Już teraz oferujemy dużą liczbę standardowych podmiotów i standardowych obiektów, które możemy ulepszyć, aby sprostać wymaganiom klientów.

Krok 2: faza projektowania

Faza projektowania wyjaśnia różne kwestie, w tym:

  • Jak możemy aktualizować dane w systemie rozwojowym?
  • Jak możemy aktualizować dane w systemach testowych?
  • Jak często powinniśmy w uzasadnionym zakresie tworzyć kopie w celu ponownej synchronizacji struktur i rozwoju?
  • W jaki sposób możemy skutecznie zredukować liczbę obiektów klienta?
  • W jaki sposób możemy połączyć przedział czasowy lub wybór poprzez jednostki organizacyjne, stosując podejście oparte na obiektach?
  • Czy powinniśmy skonfigurować obiekty dla dodatkowych obiektów biznesowych lub procesów biznesowych w SNP DPM?
  • Które dodatkowe obiekty należy zamaskować?
  • Jakie zależności musimy rozważyć pomiędzy poszczególnymi obiektami lub systemami?
  • Metody ekstrakcji.

Opracowujemy koncepcję poprzez uzupełnianie poszczególnych punktów lub wszystkich punktów w zależności od potrzeb, biorąc pod uwagę odpowiednie wymagania różnych zespołów testujących. Pozwala nam to na mapowanie odmiennych wymagań dla poszczególnych poziomów systemu (rozwojowy, testowy itp.) poprzez definiowanie różnych kontekstów, które następnie wdrażamy jako szablony w fazie wdrożenia.

Krok 3: faza wdrożenia

Szczegółowa konfiguracja SNP RESC i SNP DPM rozpoczyna się w fazie wdrożenia. Na podstawie standardowych szablonów wdrażamy w produktach niestandardowe kroki konfiguracyjne. Ponieważ proces ten wymaga konfiguracji, a nie prac rozwojowych, osoby zaangażowane muszą dysponować jedynie odpowiednią wiedzą o produkcie.

Ustawienia konfiguracyjne są realizowane w postaci kontekstów klienta. Dzięki temu można ich używać wielokrotnie, a przyszłe przebiegi aktualizacji lub ponowne tworzenie struktury systemu mogą być przeprowadzane przy użyciu tych samych scenariuszy. Pozwala to również na wysoki stopień automatyzacji.

Faza wdrożenia zwykle odbywa się w ramach zdefiniowanej struktury systemu pilotowego, który jest dostępny dla wdrożeń testowych. Powinna być reprezentatywna dla większości istniejących struktur systemowych klienta, aby zapewnić wdrożenie pilotowe, mające charakter informacyjny.

Krok 4: etap testów

Na etapie testów sprawdzamy opracowane scenariusze, które zostały wdrożone w SNP RESC oraz SNP DPM w fazie wdrożenia. W tym celu przeprowadzamy przebieg testowy w strukturze systemu pilotowego, co umożliwia sprawdzenie ustawień i przeglądanie informacji dotyczących czasów wykonania.

Możemy również testować różne metody ekstrakcji w celu określenia optymalnych procedur. Wyniki maskowania danych są weryfikowane w taki sam sposób jak zależna ekstrakcja danych aplikacji. Po przebiegu ekstrakcji przeprowadzane są specyficzne testy procesów, aby sprawdzić spójność wyekstrahowanych i zamaskowanych danych.

Krok 5: rollout

Po zakończeniu i akceptacji etapu testów następuje zatwierdzenie odpowiednich definicji scenariuszy. Następnie stosujemy opracowane scenariusze do odpowiednich struktur systemowych i konfigurujemy je w centralnym systemie sterującym SNP DPM. Dzięki temu są one dostępne dla aktualizacji różnych struktur systemowych. Ponadto w tej fazie możemy zdefiniować i wdrożyć niezbędne działania w zakresie automatyzacji.

Krok 6: faza stabilizacji

Faza stabilizacji obejmuje intensywne monitorowanie procesów i jest ukierunkowana w szczególności na początkową fazę po wdrożeniu. Zapewnia to sprawne działanie zautomatyzowanych procesów w strukturach systemowych oraz prawidłowe ustawienia scenariuszy. W razie potrzeby na tym etapie można zidentyfikować dodatkowy potencjał optymalizacji.

Przebieg testowy w strukturze systemu pilotowego – określenie optymalnych procedur

Testy procesów po przebiegu ekstrakcji

Konieczna wysoka jakość danych testowych

Firmy muszą inwestować coraz więcej, aby utrzymać sprawne środowisko biznesowe oraz szybko, niezawodnie i elastycznie reagować na nowe wymagania. Muszą one sprawnie wdrażać nowe procesy i projekty, aby zachować konkurencyjność. Ma to sens tylko wtedy, gdy testy są bardzo dokładne i zapewniona jest wysoka jakość danych testowych. Zwłaszcza firmy działające na globalnym rynku muszą podjąć kroki w celu zagwarantowania zgodności z przepisami i zmniejszenia ryzyka wynikającego z naruszania danych – nawet w środowisku nieproduktywnym. Coraz ważniejsze staje się również szybkie dostarczanie danych testowych lub systemów w różnych centrach danych lub w chmurze. Takie wymagania muszą być w miarę możliwości zautomatyzowane.