Rozważmy hipotetyczne wymaganie dotyczące kontroli zamówień, zatwierdzone już w ramach migracji SAP. Obecna implementacja odczytuje dane SAP, przeprowadza walidację i blokuje nieprawidłowe księgowanie. Przeniesienie tego kodu do zewnętrznej aplikacji może odpowiadać preferencjom architektonicznym, ale pozostawia zasadniczą kwestię bez odpowiedzi: czy proponowany projekt nadal pozwoli egzekwować kontrolę w wymaganej granicy transakcji?
Strategia rozszerzeń SAP clean core powinna zachowywać niezbędne działanie biznesowe za pomocą wspieranych mechanizmów, a nie przypisywać każde rozszerzenie do osobnego środowiska wykonawczego. Wytyczne SAP dotyczące rozszerzalności rozróżniają rozszerzenia ściśle powiązane z systemem i luźno powiązane aplikacje, wskazując dla nich różne opcje implementacji. Dla architektów i sponsorów migracji praktycznym rezultatem jest karta decyzji dla każdej funkcji biznesowej: co stanie się z obecną implementacją, dlaczego wybrano dane umiejscowienie i jakie nierozwiązane zależności uniemożliwiają zatwierdzenie.
Oddziel zachowywaną funkcję biznesową od obecnego kodu
Zatwierdzenie funkcji biznesowej nie oznacza zgody na migrację jej obecnej implementacji bez zmian. Arkusz zatwierdzania modyfikacji ERP porządkuje wcześniejszą decyzję: najpierw zatwierdź wymaganie, a dopiero potem wybierz implementację, uwzględniając stałą odpowiedzialność, interfejsy, testy i wsparcie. Tutaj zakładamy, że wymaganie przeszło już tę ocenę. Zadaniem jest ustalenie, jak powinno być realizowane w docelowym środowisku SAP.
Zacznij kartę decyzji od opisu biznesowego, a nie listy obiektów. Wskaż właściciela procesu, wymagany rezultat i warunek akceptacji. Następnie dołącz obecne zależności techniczne: obiekty niestandardowe, modyfikacje, implementacje rozszerzeń, odczyty i zapisy danych, przetwarzanie harmonogramowane, interfejsy oraz systemy korzystające z wyników. Poproś zespół techniczny o wykazanie, jak te zależności przyczyniają się do osiągnięcia zatwierdzonego rezultatu.
Przypisz implementacji jednoznaczną decyzję:
- Wycofać: usunąć zbędną implementację, zachowując zatwierdzoną funkcję biznesową w innym miejscu. Jeśli sama funkcja nie jest już potrzebna, przekaż tę decyzję ponownie właścicielowi biznesowemu.
- Zastąpić standardem: wykazać, że funkcjonalność i konfiguracja systemu docelowego spełniają warunek akceptacji, a następnie usunąć dedykowaną implementację.
- Dostosować w rdzeniu SAP: wskazać wspierany mechanizm rozszerzenia odpowiadający wymaganej bliskości danych, transakcji lub działania aplikacji.
- Przenieść do modelu side-by-side: potwierdzić, że wspierany zdalny dostęp i odrębny cykl życia operacyjnego odpowiadają wymaganiu.
- Zablokowane: pozostawić wybór jako wstępny i przypisać osobę odpowiedzialną za nierozstrzygniętą kwestię, zamiast przedstawiać preferencję architektoniczną jako zatwierdzony projekt.
Oddziel ustalenia techniczne od decyzji o dalszym losie implementacji. Dla każdego raportu analitycznego wykorzystywanego przy migracji kodu niestandardowego SAP zapisz jego zakres, założenia dotyczące systemu docelowego i udokumentowane ograniczenia. Wymagaj od zespołu wyjaśnienia biznesowych konsekwencji każdego ustalenia. Ustalenie techniczne powinno wspierać decyzję, ale nie zastępować akceptacji właściciela procesu ani stanowić dowodu, że zamiennik zachowuje wymagane działanie.
Uzależnij zatwierdzenie od modelu wdrożenia, wersji i wsparcia interfejsów
Sama nazwa produktu docelowego jest zbyt mało precyzyjna na potrzeby karty rozszerzenia. Określ, czy proponowane wdrożenie to Public Edition, Private Edition czy on-premises, wraz z wersją i istotnymi komponentami. Następnie wymagaj aktualnej dokumentacji proponowanego mechanizmu, właściwej dla tego środowiska. Nie przenoś zatwierdzenia mechanizmu z innego modelu wdrożenia lub wersji bez sprawdzenia, czy ma tutaj zastosowanie.
Wytyczne SAP dotyczące rozszerzalności ABAP kierują scenariusze ściśle powiązane z systemem ku rozszerzeniom key-user lub deweloperskim na stosie ABAP. Wśród przykładów wymieniają wspólną zmianę danych klienta i danych SAP z zachowaniem spójności transakcyjnej, rozszerzanie interfejsu użytkownika lub modelu danych aplikacji oraz implementację punktu rozszerzenia aplikacji. Uzasadnia to rozważenie rozwiązania na stosie ABAP. Nie potwierdza jednak, że wymagany punkt rozszerzenia istnieje dla konkretnej aplikacji i środowiska docelowego.
W przypadku rozwiązania na stosie ABAP sprawdź, czy wymaganie mieści się w dostępnym mechanizmie key-user, czy wymaga implementacji przez programistę. Zespół powinien wskazać konkretny punkt rozszerzenia i każdy obiekt SAP wykorzystywany przez projekt. Jeśli proponuje ABAP Cloud, wymagaj potwierdzenia obowiązujących ograniczeń języka, dozwolonych zależności i wymagań dotyczących obiektów dopuszczonych do użycia w środowisku docelowym. Nie zatwierdzaj projektu tylko dlatego, że propozycja posługuje się właściwą terminologią.
Taką samą dyscyplinę zastosuj do interfejsów API SAP dopuszczonych do użycia. Zapisz dokładny interfejs, wymagane operacje, dozwolony model korzystania, status dopuszczenia, obowiązujący kontrakt kompatybilności i udokumentowane ograniczenia. Interfejs do odczytu nie jest dowodem dostępności wspieranej operacji zapisu. Jeśli projekt zależy od zdarzenia, zweryfikuj jego znaczenie i wymagany późniejszy dostęp do danych, zamiast traktować powiadomienie jako kompletną integrację biznesową.
Rozstrzygaj te zależności równolegle z harmonogramem migracji. Wykorzystaj rejestr horyzontu wsparcia SAP ECC, aby powiązać decyzje dotyczące środowiska docelowego i interfejsów z szerszym planem przejścia. Nierozstrzygniętą zależność od API lub punktu rozszerzenia pokazuj jako przeszkodę w realizacji, z przypisaną osobą odpowiedzialną za decyzję, zamiast ukrywać ją w ogólnej estymacji prac programistycznych.
Niech granica transakcji wyznaczy wstępne umiejscowienie
Wybór miejsca implementacji staje się prostszy, gdy właściciel procesu określi, co musi zakończyć się powodzeniem albo niepowodzeniem łącznie. SAP wskazuje rozszerzalność side-by-side na SAP BTP jako domyślny wybór dla luźno powiązanych aplikacji, które korzystają z replikowanych danych lub zdalnych API i nie wymagają wspólnej transakcyjnej zmiany danych niestandardowych oraz danych rdzenia. To rozróżnienie jest bardziej użyteczne niż ogólny nakaz przeniesienia kodu niestandardowego poza rdzeń.
Przykład hipotetyczny: walidacja przed księgowaniem
Załóżmy, że wymagana kontrola musi odrzucić nieprawidłową transakcję biznesową przed zaksięgowaniem, korzystając z jej bieżących wartości. Potraktuj implementację na stosie ABAP jako wstępnego kandydata, ponieważ wymaganie zakłada ścisłe powiązanie transakcyjne. Zatwierdzenie nadal zależy od znalezienia wspieranego punktu rozszerzenia z dostępem do niezbędnych danych i odpowiednim momentem wykonania. Ani ten scenariusz, ani ogólne wytyczne dotyczące umiejscowienia nie potwierdzają istnienia takiego punktu.
Poproś zespół o zademonstrowanie zaakceptowanego i odrzuconego księgowania oraz wynikającego z nich stanu biznesowego. Jeśli zamiast tego proponuje walidację zdalną, wymagaj precyzyjnego opisu tego, co nastąpi przy opóźnieniu lub niedostępności odpowiedzi. Właściciel procesu musi zaakceptować sposób oczekiwania, zasady postępowania w razie awarii oraz objęcie kontrolą wszystkich istotnych ścieżek księgowania. Samo udane wywołanie zdalne nie jest wystarczającym testem akceptacyjnym.
Przykład hipotetyczny: zewnętrzny obieg weryfikacji dokumentów
Załóżmy teraz, że zewnętrzny zespół weryfikuje dokumenty uzupełniające po utworzeniu rekordu, a biznes akceptuje stan oczekiwania do zakończenia weryfikacji. Model side-by-side jest rozsądnym wstępnym wyborem, jeśli weryfikacja nie musi zostać zatwierdzona atomowo z pierwotną transakcją SAP. Przed akceptacją sprawdź wspierany dostęp do rekordu, wymaganą operację aktualizacji i dozwolony wzorzec komunikacji w konkretnym środowisku docelowym.
Przetestuj, co nastąpi, jeśli weryfikacja zakończy się po anulowaniu, aktualizacja zostanie odrzucona, odpowiedź zaginie lub to samo potwierdzenie zakończenia zostanie przesłane ponownie. Wymagaj wyjaśnienia obsługi duplikatów, uzgadniania stanów i uprawnień do działań naprawczych. Jeśli wymaganie zmieni się tak, że weryfikacja ma blokować pierwotne księgowanie, ponownie oceń umiejscowienie. Zmieniło się wymaganie transakcyjne, a nie tylko szczegół integracji.
Uzupełnij macierz decyzji dowodami gotowości operacyjnej
Diagram architektury nie wystarczy do przypisania odpowiedzialności za dalsze utrzymanie. Wytyczne SAP dotyczące wyboru opcji rozszerzalności rozróżniają zarządzanie cyklem życia zintegrowane z rdzeniem dla własnych rozwiązań ABAP i rozszerzeń key-user od odrębnego zarządzania cyklem życia rozszerzeń side-by-side. Stabilność cyklu życia rozwiązań side-by-side wiążą ze stabilnymi API i zdarzeniami, a nie z samym oddzieleniem od rdzenia.
Przełóż to rozróżnienie na zadania z jasno przypisaną odpowiedzialnością. Ustal, kto wdraża kolejne wydania rozszerzenia, kto sprawdza zgodność z docelowym środowiskiem SAP i kto akceptuje kompletny proces biznesowy po zmianie po dowolnej ze stron. Nie zatwierdzaj założenia o ograniczeniu prac aktualizacyjnych lub kosztów tylko dlatego, że implementacja zostaje przeniesiona w inne miejsce.
| Pole karty | Wymagany dowód lub decyzja |
|---|---|
| Funkcja i właściciel biznesowy | Zatwierdzony rezultat, warunek akceptacji i właściciel uprawniony do zaakceptowania zmienionego działania. |
| Obecne zależności | Inwentaryzacja techniczna powiązana z rzeczywistymi ścieżkami procesu, dostępem do danych i odbiorcami wyników. |
| Środowisko docelowe i decyzja | Model wdrożenia, wersja, istotne komponenty oraz decyzja: wycofać, zastąpić, dostosować, przenieść lub zablokowane. |
| Wspierane mechanizmy | Dokumentacja właściwa dla środowiska docelowego: punkty rozszerzeń, API, zdarzenia, kontrakty dopuszczenia i ograniczenia. |
| Transakcja i opóźnienia | Co musi zostać zatwierdzone łącznie, dozwolony sposób oczekiwania, aktualność danych i zmierzone wyniki testów akceptacyjnych. |
| Awarie i autoryzacja | Model tożsamości, uprawnienia biznesowe, odrzucone operacje, obsługa duplikatów i uprawnienia do działań naprawczych. |
| Monitorowanie i cykl życia | Wykrywanie wyjątków, odpowiedzialność za uzgadnianie stanów, wdrożenia, testy aktualizacji i usuwanie problemów. |
| Warunki wstępne i blokady | Weryfikacja środowiska wykonawczego, łączności, uprawnień do korzystania z usług i warunków handlowych; nierozstrzygnięte kwestie z przypisanymi osobami odpowiedzialnymi za decyzje. |
W zakresie autoryzacji wymagaj testów zarówno działań dozwolonych, jak i zabronionych, w tym wykonywanych w tle, jeśli ma to zastosowanie. W zakresie monitorowania poproś zespół o pokazanie, jak operator odróżni udane przesłanie komunikatu od pomyślnego zakończenia operacji biznesowej. Ustal, kto uzgadnia rozbieżność i kto może zatwierdzić działanie korygujące.
W przypadku propozycji side-by-side potwierdź wybrane środowisko wykonawcze i usługi, ich warunki wstępne, odpowiedzialność operacyjną oraz obowiązujące uprawnienia do korzystania przed zatwierdzeniem implementacji. Dołącz wyniki tej weryfikacji do karty decyzji. Technicznie prawdopodobne umiejscowienie powinno pozostać wstępne, dopóki organizacja nie będzie w stanie go wspierać i utrzymywać operacyjnie.
Zatwierdzaj prace migracyjne tylko przy jawnie wskazanych blokadach
Przekształć każdą zatwierdzoną decyzję w pakiet prac migracyjnych: usuń nieaktualne zależności, skonfiguruj zamiennik, dostosuj wspierane rozszerzenie lub zbuduj i podłącz aplikację zewnętrzną. Uwzględnij w tym pakiecie postępowanie z danymi, zmiany autoryzacji, procedury obsługi wyjątków i akceptację biznesową. Nie zamykaj go wyłącznie dlatego, że kod się kompiluje lub interfejs zwraca odpowiedź o powodzeniu.
Zapisz, co zmieniłoby rekomendację. Wykazana dostępność standardowej funkcji może wyeliminować potrzebę dedykowanego rozwiązania; brak wspieranej operacji zapisu może zablokować model side-by-side; wymóg atomowości może przemawiać za rozwiązaniem na stosie ABAP; a brak odpowiedzialności za działania naprawcze powinien uniemożliwić akceptację operacyjną. Utrzymuj uzasadnienie decyzji w formie umożliwiającej kontrolę, aby zmiana założenia uruchamiała ponowną ocenę.
Przed zatwierdzeniem kolejnego pakietu prac nad rozszerzeniem uzupełnij jego kartę decyzji wspólnie z właścicielem procesu i osobą odpowiedzialną za utrzymanie techniczne, a następnie rozstrzygnij blokadę, która z największym prawdopodobieństwem może zmienić umiejscowienie. Jeśli potrzebujesz pomocy w ocenie prac związanych z migracją kodu niestandardowego SAP lub we wdrożeniu wybranego podejścia, omów swoje wymagania z konsultantami funkcjonalnymi i specjalistami technicznymi SAP w Digiventi.
