Elastyczny workflow w S/4

Rozwiązania workflow od wielu lat są powszechnie stosowane w systemach SAP. Najczęściej są implementowane do obsługi procesów związanych z zatwierdzaniem dokumentów. W obszarze zakupów są to przede wszystkim procesy zatwierdzania zgłoszeń zapotrzebowania, zamówień oraz faktur. W klasycznych systemach SAP ECC miejscem, w którym podejmuje się decyzje w ramach procesów workflow, jest transakcja SBWP w SAP GUI.

Choć są to sprawdzone rozwiązania, to technologicznie nie przystają już do dzisiejszych wymagań. Po pierwsze, nie oferują mobilnego zatwierdzania na urządzeniach przenośnych. Po drugie, są dość trudne do modyfikacji, np. zmiana polityki zatwierdzania wydatków wymaga często zaangażowania konsultanta, który dokona zmian konfiguracyjnych w ramach tzw. strategii zatwierdzania. Ponadto wzorce workflow dostępne w różnych obszarach systemu SAP ECC nie są ze sobą spójne, co również nie ułatwia implementacji i utrzymania takich rozwiązań.

Mobilne zatwierdzanie dla systemów SAP ECC jest dostępne za pomocą niezależnego serwera SAP Fiori Front-End Server.

Tradycyjny workflow jest wciąż dostępny w systemie SAP S/4HANA on-premise oraz private cloud. W wersji S/4HANA public cloud możliwe jest korzystanie wyłącznie z elastycznego workflow, a bardziej zaawansowane czy niestandardowe potrzeby workflow można implementować na platformie BTP (Business Technology Platform) w ramach komponentu BTP Workflow Management.

Projektując system SAP S/4HANA, jego twórcy zaplanowali w nim zupełnie nową funkcjonalność workflow, adresującą wymagania związane z zatwierdzaniem dokumentów, tzw. elastyczny workflow (flexible workflow). Elastyczny workflow oferuje funkcjonalności, które były dostępne w przeszłości, takie jak warunkowe uruchamianie procesów workflow (np. zamówienie przynależy do konkretnej jednostki gospodarczej i jest powyżej pewnej kwoty), swobodną determinację użytkowników (np. zakupy powyżej pół miliona złotych zatwierdza prezes), wieloetapowość itd. Jednocześnie oferuje zupełnie nową jakość ze względu na nowoczesny i przyjazny użytkownikom interfejs SAP Fiori, który zapewnia pełną mobilność out-of-the-box.

Decyzje związane z zatwierdzaniem podejmuje się w aplikacji My Inbox dostępnej jako kafelek na stronie startowej SAP Fiori Launchpad. Ponadto elastyczny workflow nie polega wyłącznie na konfiguracji, lecz raczej na ustawieniach traktowanych jak dane podstawowe. W przypadku zmiany polityki zatwierdzania wydatków ścieżki zatwierdzania edytuje użytkownik kluczowy. Warto również nadmienić, że elastyczny workflow stanowi generyczną funkcję systemu SAP S/4HANA, tzn. jest dostępny we wszystkich obszarach systemu. Procesy w innych modułach poza modułem zakupowym są opisane w dokumentacji systemu dostępnej na stronie help.sap.com.

Elastyczny workflow jest dostępny w każdej wersji systemu SAP S/4HANA, zarówno on-premise, private cloud, jak i public cloud.
W artykule omówimy następujące komponenty elastycznego workflow w systemach SAP S/4HANA:

• Konfiguracja bazowa;
• Aplikacja #1 Manage workflows – ustawienia elastycznego workflow na przykładzie zamówienia zakupu z dekretacją na miejsce powstawania kosztów (MPK);
• Aplikacja #2 Manage Teams and Responsibilities – tworzenie zespołów, w ramach których członkowie mają przypisane różne odpowiedzialności;
• Aplikacja #3 My Inbox – skrzynka, w której podejmowane są decyzje;
• Powiadomienia;
• Pozostałe informacje.

Konfiguracja bazowa

Aby skorzystać z elastycznego workflow w SAP S/4HANA, niezbędne jest aktywowanie środowiska workflow w niemal taki sam sposób, jak w SAP ECC (transakcja SWU3). Istnieją drobne różnice, np. w SAP S/4HANA użytkownik techniczny workflow to SAP_WFRT, a w SAP ECC to WF-BATCH. Ponadto nie ma potrzeby ręcznego harmonogramowania zadań wsadowych związanych z silnikiem workflow, ponieważ w SAP S/4HANA są one automatycznie planowane na podstawie definicji zadań standardowych (transakcja SJOBREPO).

System SAP S/4HANA on-premise oraz private cloud może być używany tak samo jak SAP ECC, czyli poprzez aplikację kliencką SAP GUI. Elastyczny workflow jest jednak dostępny wyłącznie przez przeglądarkę i nowy interfejs użytkownika SAP Fiori. Dlatego muszą być aktywne wszystkie usługi związane z front-endem Fiori oraz opracowane odpowiednie role użytkownika zawierające katalogi oraz grupy lub przestrzenie SAP Fiori. Niezbędne jest również wykonanie kilku podstawowych ustawień modułowych (np. można aktywować framework elastycznego workflow dla wybranych rodzajów zamówień).

W niektórych klasycznych aplikacjach elastyczny workflow jest widoczny w trybie do odczytu, np. ścieżkę zatwierdzania widać w transakcjach ME22N/ME23N na zakładce Elastyczny Workflow. Jednakże tradycyjny workflow zaimplementowany na podstawie strategii zatwierdzania nie jest widoczny w SAP Fiori (nie ma zakładki Strategia zatwierdzania).

Aplikacja #1 Manage workflow

Aplikacja Manage workflow (Zarządzanie workflow) jest przeznaczona dla użytkownika kluczowego (nie dla konsultanta!), który zarządza procesami workflow w danym systemie. W aplikacji najpierw wybieramy obszar, dla którego chcemy ustawić workflow (w naszym przykładzie jest to Workflow dla zamówień). Po wybraniu obszaru pojawia się lista aktywnych i projektowanych procesów workflow (nieaktywne procesy mają status dokumentu tymczasowego).

Warto podkreślić, że ustawienia procesów workflow są traktowane jak dane podstawowe, a nie jak konfiguracja. Użytkownik kluczowy dokonuje edycji tych ustawień bezpośrednio na systemie produkcyjnym. Ustawione aktywne procesy workflow są sprawdzane przez system według kolejności od góry do dołu; kolejność oczywiście można swobodnie ustawiać. Chodzi o to, że dokument nowego zamówienia może spełniać warunki rozpoczęcia kilku procesów, ale zastosowany zostanie ten, który jest pierwszy. Aktywnego procesu workflow nie można edytować, ponieważ mogą być uruchomione egzemplarze procesów workflow. Jeśli chcemy zmodyfikować ustawienia danego procesu, należy stworzyć jego kopię, zmodyfikować ją według potrzeb, a następnie dokonać dezaktywacji poprzedniego procesu oraz aktywacji nowego.

Nowy proces workflow ustawia się na dwóch poziomach. Na pierwszym opracowuje się opis procesu, jego okres ważności oraz tak zwane warunki początkowe. Przykładowe warunki początkowe to np. przynależność zamówienia do danej jednostki gospodarczej, działu zaopatrzenia, kwota netto zamówienia w walucie dokumentu (większa niż, mniejsza lub równa), zastosowany rodzaj dokumentu zamówienia czy fakt użycia danej dekretacji w zamówieniu, np. miejsce powstawania kosztów czy projekt. Poszczególne warunki są traktowane łącznie, ale możliwe jest również dodanie warunków alternatywnych. Po opracowaniu warunków rozpoczęcia tworzone są kroki zatwierdzania.

Edycja ustawień danego kroku to niejako drugi poziom ustawień (inny dla każdego kroku). Dla każdego kroku ustawiana jest nazwa, opcjonalność kroku, wykluczeni użytkownicy (np. twórca zamówienia może zostać automatycznie wykluczony z konkretnego procesu akceptacji swojego zamówienia, jeśli na jakimś etapie jest jednocześnie wśród osób akceptujących) oraz oczywiście odbiorcy. Możliwe jest przypisanie odbiorców poprzez rolę lub bezpośrednio poprzez nazwę użytkownika. Niemniej określenie „rola” w kontekście elastycznego workflow jest czymś innym niż tradycyjnie rozumiana rola uprawnień edytowana w transakcji PFCG. W ramach elastycznego workflow jest pięć typów ról:

• Powiązane ze strukturą organizacyjną, np. przełożony, przełożony przełożonego, przełożony osoby na poprzednim etapie;
• Powiązane z obiektem dekretacji, np. właściciel miejsca powstawania kosztów, osoba odpowiedzialna za projekt;
• Powiązane z funkcjami w ramach zespołów, np. członek zespołu kupców operacyjnych lub kupców/key account managerów strategicznych;
• Administrator workflow;
• Niestandardowe ustalanie wykonawcy.

Bezpośrednie przypisanie użytkownika wymaga, aby był on powiązany poprzez infotyp 0105 z rekordem pracownika oraz by posiadał również rekord partnera biznesowego (BP) z rolą Pracownik. W S/4HANA on-premise oraz private cloud tworzy się te powiązania tradycyjnie w SAP GUI, a w S/4 HANA public cloud jest do tego przeznaczona dedykowana aplikacja SAP Fiori.

Istotnym ustawieniem w kontekście odbiorców jest również to, że można wskazać, czy decyzję ma podjąć jedna z osób określonych na danym etapie, czy wszystkie.

Kolejnym bardzo ważnym elementem jest możliwość opracowania warunków aktywacji kroku. Przykładowe warunki to użycie danej dekretacji: miejsce powstawania kosztów/projekt, użycie danej grupy materiałowej, rodzaj dokumentu, grupa zaopatrzeniowa, dział zaopatrzenia czy wartość netto zamówienia w walucie dokumentu (większa niż, mniejsza lub równa).

Po opracowaniu odbiorców, warunków aktywacji kroku możliwe jest jeszcze opracowanie terminów oraz akcji na wypadek podjęcia decyzji negatywnej w danym kroku. Na przykład w przypadku przekroczenia terminu możliwe jest po prostu oznaczenie zadania jako przeterminowanego lub wysłanie powiadomienia e-mail. W przypadku decyzji negatywnej może to być oznaczenie zamówienia jako odrzuconego lub odesłanie go z powrotem do twórcy zamówienia celem jego poprawy.

Na zrzucie ekranu zademonstrowano ustawienia przykładowej ścieżki zatwierdzania w jednostce gospodarczej 2610, dla zamówień powyżej 1000 złotych z dekretacją na miejsce powstawania kosztów. W ścieżce znajdują się trzy kroki zatwierdzania. Pierwszy to zatwierdzenie właściciela najbardziej obciążonego miejsca powstawania kosztów (zastosowanie wielu miejsc na jednym zamówieniu można ograniczyć), drugi krok to zatwierdzenie jednej z osób z zespołu zakupów (tylko gdy zamówienie przekracza 10 tys. zł), a trzeci to zatwierdzenie menedżera obszaru (tylko gdy zamówienie przekracza 50 tys. zł).

Aplikacje Fiori dla elastycznego workflow

Aplikacja #2 Manage Teams and Responsibilities

Aplikacja Manage Teams and Responsibilities (Opracowanie zespołów i odpowiedzialności) jest zupełnie nowym konceptem dostępnym w systemie S/4HANA. Jednym z zastosowań tej aplikacji jest obszar elastycznego workflow. W poprzedniej części wspomniano, że odbiorcami zadań mogą być osoby, które pełnią pewne funkcje (role) w ramach zespołów. W aplikacji użytkownik kluczowy może tworzyć zespoły i zarządzać zespołami, które odpowiadają za dany obszar. Zespół ma osobę odpowiedzialną, członków oraz tzw. definicję odpowiedzialności (np. zespół może być odpowiedzialny za dział zaopatrzenia 2610).

Należy zwrócić szczególną uwagę na to, że do każdego członka zespołu są przypisane funkcje. Rodzaje zespołów oraz funkcje mogą być swobodnie modelowane. Ponadto zespoły mogą być łączone ze sobą poprzez relacje nadrzędności/podrzędności, dzięki czemu możliwe jest odzwierciedlanie hierarchii zespołów.

W przykładzie na zrzucie ekranu zastosowano funkcję Zarządzanie operacyjne i przypisano ją do dwóch osób. Funkcja Zarządzanie operacyjne została wcześniej wybrana jako rola dla odbiorców w drugim kroku przykładowej ścieżki zatwierdzania.

Aplikacja #3 My Inbox

Aplikacja My Inbox (Mój folder wejściowy) jest miejscem, w którym podejmuje się decyzje workflow w środowisku SAP Fiori. Jej odpowiednikiem po stronie SAP GUI jest transakcja SBWP (Business Workplace). Zadania generowane przez elastyczny workflow są widoczne w SBWP, ale nie można ich stamtąd wykonać. Należy używać wyłącznie aplikacji My Inbox. Aplikacja po lewej stronie wyświetla listę zadań (pozycji roboczych workflow) do wykonania wraz z kluczowymi informacjami, np. numerem dokumentu, którego dotyczy zadanie. Po prawej stronie znajdują się szczegóły wybranego zadania/dokumentu. Obszar ekranu jest spory, zwłaszcza na desktopie, więc możliwe jest wyświetlenie całkiem dużej liczby informacji. Decyzje są podejmowane poprzez przyciski w prawej dolnej części ekranu.

Przede wszystkim można zamówienie zatwierdzić albo odrzucić. Ponadto możliwe jest wyświetlenie logu, przejęcie zadania na własność (gdy jest wysłane do wielu odbiorców na raz) czy przekazanie do innej osoby. Nowa skrzynka oferuje również funkcję opracowania swojego zastępcy oraz wyświetlenie informacji, czyim zastępcą się aktualnie jest.

Opisane funkcjonalności są analogiczne do tych znanych z transakcji SBWP. W ocenie autora jedną z najciekawszych nowych funkcji jest możliwość zbiorczego podejmowania decyzji (np. użytkownik ma w skrzynce 12 zamówień do zatwierdzenia i chce je zatwierdzić na raz). W przypadku systemów ECC dla takiego wymagania konieczne było pisanie w języku ABAP dedykowanych kokpitów. W My Inbox ta funkcjonalność jest dostępna out-of-the-box. Dostępna jest również aplikacja My Outbox (Mój folder wyjściowy) prezentująca historię podjętych w przeszłości decyzji. Na zrzutach zaprezentowano zadanie akceptacji zamówienia na ekranie komputera stacjonarnego i to samo zadanie w trybie emulacji urządzenia mobilnego.

Powiadomienia

W każdym środowisku workflow szczególnie istotne są powiadomienia (notifications). Są to komunikaty skierowane do osób zaangażowanych w proces workflow dostarczane do nich innym kanałem komunikacji niż sam workflow, głównie e-mailem. Powiadomienia mają na celu poinformowanie o podjętej w procesie decyzji lub przypomnienie, że należy wykonać jakieś zadanie workflow. W elastycznym workflow rozróżniamy dwa rodzaje powiadomień:

• Powiadomienia wysyłane na e-mail;
• Powiadomienie typu push.

Dla powiadomień e-mail dostępne są cztery typy (w scenariuszu dla zatwierdzania zamówień):

• Powiadomienie o oczekującym zadaniu;
• Powiadomienie o decyzji pozytywnej (akceptacja);
• Powiadomienie o decyzji negatywnej (odrzucenie);
• Powiadomienie o przekroczeniu terminu na wykonanie zadania.

Powiadomienia e-mail aktywuje się w ten sposób, że kopiuje się odpowiedni szablon dostarczony w standardzie przez producenta (dla różnych scenariuszy są oczywiście dostępne różne szablony). Aktywowany szablon można poddać edycji i dostosować go do własnych potrzeb. Warto zaznaczyć, że szablon przygotowuje się w technologii HTML5/CSS, a zatem można zaprojektować szablony np. dostosowane do firmowej szaty graficznej.

W szablonach można również używać dostępnych zmiennych, np. aby wyświetlić numer zamówienia, kwotę netto, datę utworzenia dokumentu itp. Przygotowanie szablonu, podobnie jak opracowanie ustawień ścieżek workflow, można wykonać bezpośrednio na systemie produkcyjnym.

Nowy elementem, często określanym mianem alertów, są powiadomienia typu push. Są one automatycznie publikowane na stronie startowej SAP Fiori Launchpad (ikona dzwonka). Z poziomu takiego powiadomienia można bezpośrednio przejść do aplikacji My Inbox i podjąć wymagane decyzje.

Pozostałe informacje

Nie sposób opisać wszystkich szczegółów elastycznego workflow, niemniej poniższe aspekty wydają się istotne z perspektywy osoby planującej wdrożenie tego rozwiązania:

• Aplikacje mogą być rozszerzane o dedykowane pola;
• Aplikacje mogą być rozszerzane o dedykowaną logikę, w szczególności:
  • Można implementować własne algorytmy determinacji osób do zadań decyzyjnych;
  • Można implementować własne kryteria aktywacji oraz algorytmy ich ewaluacji;
  • Można implementować własne algorytmy powodujące restart procesu zatwierdzania;
• Ustawienia workflow mogą był tłumaczone na różne języki;
• Ustawienia workflow – mimo że domyślnie są jak dane podstawowe – mogą być przenoszone z systemów developerskich na jakościowe i produkcyjne (tak jak tradycyjnie).

Dostępne są też aplikacje dla administratora workflow.

Dla firm posiadających wdrożone procesy na podstawie tzw. strategii zatwierdzania w module MM istotne jest to, że przed uruchomieniem elastycznego workflow należy ten klasyczny wyłączyć. Rozwiązania się bowiem wykluczają i należy używać tylko jednego.

Elastyczny workflow w zakupach – pozostałe opcje

W niniejszym artykule opisany został elastyczny workflow na przykładzie zatwierdzania zamówień. Pozostałe dostępne dokumenty w tym obszarze, dla których możliwa jest aktywacja ścieżek zatwierdzania, to między innymi:

• Zapytania ofertowe (RFQ);
• Oferty;
• Umowy terminarzowe (forma ramowego zamówienia);
• Kontrakty;
• Zgłoszenia zapotrzebowania;
• Arkusze akceptacji usług;
• Faktury;
• Projekty sourcingowe;
• Listy dostawców dla sourcingu;

W dokumentacji rozwiązania pojawiają się również określenia takie jak centralne zamówienia, centralne zgłoszenie zapotrzebowania itp. Dotyczy to scenariuszy, w których system S/4HANA jest ustawiony jako centralny hub zakupowy (tak jak dotychczas SAP SRM).