Oferta

Rozwiązania międzymodułowe SAP

Jako rozwiązania międzymodułowe SAP należny rozumieć funkcjonalności służące do integracji procesów biznesowych, wstępujące w wilu modułach jednocześnie i umożliwiające zachowanie spójności systemu oraz integrację ze ‘światem zewnętrznym’ w stosunku do SAP.

Workflow

Pamiętam czasy z początku 21 wieku kiedy rozpoczynałem swoja przygodę z SAP Business Workflow. Ze względu na brak kwalifikacji na rynku polskim w celu odbycia szkolenia BC600 (Workflow Build and Use) musiałem udać się do Centrum Szkoleniowego w Londynie. Zdobyta wiedza natychmiast została przeze mnie zutylizowana na moim pierwszym samodzielnym projekcie Workflow (Energetyka Kaliska, rok 2001). Od tego czasu udało mi się zrealizować szereg projektów, gdzie Workflow był traktowany jako odrębny moduł i kompleksowo obsługiwane były scenariusze zarządzania przepływam pracy oraz informacji w różnych obszarach przedsiębiorstwa. W zależności od branży poprzez SAP Business Workflow automatyzowałem obsługę zarówno prostych (klasycznych) procesów typu zatwierdzanie dokumentów zaopatrzeniowych, obsługę wniosków urlopowych w SAP HR, przetwarzanie faktur zakupu, obsługę zawiadomień w modułach SAP QM, PM, CS, procesy związane z zarządzaniem danymi podstawowymi (materiały, BOM’y, kontrahenci), procesy wspomagające odbiór wykonania usług, procesy związane z ewidencją środków trwałych, obsługę błędów EDI i jeszcze parę innych. Zdarzały się też procesy nietypowe np. wsparcie obsługi towarów niebezpiecznych czy też ewidencja odzieży roboczej dla pracowników (przypominanie o terminie wymiany). Spośród tych różnych pól eksploatacji SAP Business Workflow na szczególną uwagę zasługują procesy związane z obsługą faktur zakupu. Oczywiście ma to związek z moimi kompetencjami z zakresu systemów firmy ReadSoft ale nie tylko. W przypadku faktur (nie tylko papierowych ale również faktur przesyłanych jako załączniki pdf w e-mailach, e-faktur czy też faktur przesyłanych jako klasyczne EDI) chyba mogę śmiało powiedzieć, że moja wiedza jest dogłębna. Kwestie integracji z mechanizmami skanującymi oraz rozpoznającymi treść faktur (OCR) są jak najbardziej mi bliskie. Również często wykorzystywane w tych procesach mechanizmy archiwizacji optycznej SAP ArchiveLink w różnych konfiguracjach (Early Archaving, Late Archiving, Archiving with Barcde) są mi znane.

Poza automatyzacją całych procesów biznesowych Workflow coraz częściej jest wykorzystywać ‘wewnątrz’ procesów głównych SAP działając ‘w tle’ – znajomość tej technologii znakomicie ułatwia życie konsultanta w przypadku problemów z działaniem tych mechanizmów. Ja też często w swoich projektach wprowadzam elementy Workflow w celu automatyzacji niektórych czynności czy też komunikacji z użytkownikami systemu w przypadkach zaistnienia zdarzeń wyjątkowych np. zadanie działające w tle w nocy zwróciło komunikat błędu.

Poprzez wszystkie lata mojej kariery w konsultingu oczywistym dla mnie jest to, że rozwiązania proste, czytelne dla użytkowników, najlepiej w ramach standardu SAP (minimalizacja ilości rozszerzeń i modyfikacji) sprawdzają się najlepiej. W przeciwieństwie do wielu konsultantów Workflow ja nie mam przeszłości programistycznej (konsultant ABAP) i nie dążę do zaspokojenia wymagań klienta 1:1, gdyż to często prowadzi do generowania rozwiązań niestandardowych wymagających kodowania. Podczas projektowania scenariuszy Workflow zawsze staram się wykorzystać w 100% możliwości SAP standard (istnieją setki predefiniowanych scenariuszy Workflow w SAP) i jeżeli trzeba staram się podpowiedzieć zmiany w procesach przed ich automatyzacją poprzez Workflow. Prawdziwe wydaje się twierdzenie, że “jeżeli procesy biznesowe nie są zdefiniowane prawidłowo to automatyzacja tych procesów poprzez Workflow przyniesie skutki przeciwne do oczekiwanych – będzie ten sam bałagan tylko działający szybciej”. Ponieważ posiadam bogate doświadczenie jako konsultant aplikacyjny w logistyce staram się wpierw zoptymalizować proces a w drugiej kolejności go automatyzować.

Ze względu na częste jednak potrzeby realizacji specyficznych wymagań Klientów poprzez rozszerzenia oraz dość nietypowe dla SAP standardy kodowania (makra, programowanie na obiektach BOR czy też na klasach) z czasem rozbudowałam swoją znajomość programowania w tym obszarze. O ile nie jetem programistą aplikacyjnym o tyle w Workflow programuję. Wielokrotnie maiłem okazję też prowadzić szkolenia z SAP Business Workflow (również programowanie Workflow czy też z technologii internetowych SAP WebFlow) w Centrum Szkoleniowym SAP Polska czy też szkolenia dedykowane w siedzibie Klientów.

W trakcie mojej przygody z Workflow wielokrotnie realizowałem też integrację SAP Business Workflow z zewnętrznymi systemami pracy grupowej (np. IBM Lotus) tak, że jeden scenariusz biznesowy był realizowany w kilku systemach informatycznych.

DMS

SAP DMS (Documet Managemet System) to wg mnie trochę niedoceniana funkcjonalność systemu. Nie wiem z czego to wynika, może z braku kadry konsultantów na rynku, może z charakteru tego rozwiązania, które samo w sobie nie obsługuje procesów biznesowych lecz pełni rolę wspomagającą dla innych obszarów aplikacji SAP. Podejrzewam, że firmy wdrażające SAP (zwłaszcza na rynku polskim) koncentrują się na obsłudze Core Business i często poprzestają na tym podczas wdrożeń SAP nie idąc krok dalej w stronę rozwiązań wspomagających często pozostawiając je w zewnętrznych systemach wyspowych niezintegrowanych z SAP.

W obecnych czasach w przedsiębiorstwach ilość dokumentów wszelkiego rodzaju jest ogromna. Problemem staje się kwestia ich składowania, indeksowania oraz wyszukiwania w sposób optymalny. Dla firm pracujących w środowisku SAP tym naturalnym i optymalnym sposobem dostępu do dokumentów jest interfejs systemu SAP tzn. chcąc np. obejrzeć skan faktury zakupu czy też zdjęcie uszkodzonego produktu przesłane wraz z reklamacją Klienta naturalnie dokumenty te powinny być dostępne z poziomu transakcji SAP odpowiednio do przeglądu faktury zakupu czy też zawiadomienia jakościowego od Klienta. System DMS pozwala na tego typu ‘kontekstowe’ łączenie obiektów aplikacji SAP (materiał, zlecenie sprzedaży, zawiadomienie) z dokumentami biznesowymi (rysunek techniczny, e-mail od Klienta, skan reklamacji Klienta). Moje doświadczania z DMS obejmują szereg tego typu przypadków łącznie z budową zaawansowanego Archiwum do zarządzania dokumentacją ISO w przedsiębiorstwie – rozwiązanie połączone z Workflow do zarządzania dystrybucją nowych i zmienionych dokumentów.

Nieodzowną częścią projektów DMS jest instalacja oraz konfiguracja połączenia z SAP zewnętrznych systemów klasy CMS (Content Management System). Wielokrotnie maiłem okazje instalować system produkcji SAP o nazwie HTTP Content Server w celu składowania dokumentów oraz ich udostępniania (poprzez interfejs www) w środowisku SAP. Produkty firm trzecich w tym zakresie (OpenText, FileNet, Documentum) również nie są mi obce.

Zagadnieniem, które mnie szczególnie interesuje jest kwestia integracji SAP DMS z systemami klasy CAD w celu sprawnego zarządzania danymi inżynierskimi w tym rysunkami technicznymi oraz zarządzania zmianami inżynierskimi (Engineering Change Management).
Warto wspomnieć, że moje doświadczenia w obszarze DMS obejmują również aplikację o nazwie SAP Easy DMS, która jest wersją ‘light’ instalowaną jako odrębny komponent (poza SAP GUI) z łatwym i przyjaznym interfejsem pozwalającym na intuicyjną archiwizację dokumentów (drag-and-drop) oraz ich wyszukiwanie i wyświetlanie w połączeniu z obiektami aplikacyjnymi SAP.”

ArchiveLink

SAP ArchiveLink nie jest właściwie odrębnym modułem. To otwarty interfejs przygotowany przez firmę SAP w celu integracji zewnętrznych systemów klasy CMS. System SAP ECC (ERP) z definicji jest systemem transakcyjnym i ze względów wydajnościowych nie jest przygotowany do składowania dokumentów biznesowych w bazie danych (dokumenty MS office, skany, zdjęcia, korespondencja, wydruki, rysunki techniczne itd.). Budując interfejs firma SAP udostępniła również program dla firm partnerskich, które mogą dostosować a następnie certyfikować swoje rozwiązanie klasy CMS na zgodność z SAP wg protokołu ArchiveLink. Obecnie tych systemów na rynku jest bardzo dużo – na stronach SAP w zakładce APPLICATION DEVELOPMENT PARTNER DIRECTORY można znaleźć aktualna listę – lecza zasady ich integracji z aplikacją SAP ECC są zbliżone.
SAP ArchiveLink posiada mechanizmy archiwizacji zarówno dokumentów przychodzących (np. faktur zakupu) jak i wychodzących (np. certyfikaty jakościowe). Ze względu rożne formy automatyzacji procesów np. e-faktury często równolegle z generowanie dokumentu elektronicznego z SAP tworzony jest dokument klasyczny (pdf zgodny z wydrukiem) i archiwizowany w zewnętrznym repozytorium w celach późniejszego udostępniania organom kontroli skarbowej czy też audytorom. Podobnie jak SAP DMS również SAP ArchiveLink to funkcjonalność wspomagająca procesy biznesowe i w związku z tym niezbyt często wykorzystywana na projektach. Ostatnio widzę jednak spore zainteresowanie tą technologią, głównie z powodu zwiększonej liczby dokumentów w przedsiębiorstwach i potrzebą ich sprawnego zarządzania wraz z dostępem z poziomu aplikacji SAP.
Liczę, że SAP ArchiveLink wkrótce stanie się standardem w pracujących z systemem SAP ECC.

EDI/ALE

Aplikacja SAP posiada wiele mechanizmów pozwalających na rożne formy elektronicznej wymiany danych z systemami zewnętrznymi partnerów biznesowych. Termin EDI (Electronic Data Interchange) jest terminem uniwersalnym i wiele firm stosuje mechanizmy EDI w codziennej komunikacji. Przez lata wypracowanych zostało kilka standardów EDI z czego w Europie najczęściej stosowany jest standard EDIFACT. Jest to wspólny ‘język’ komunikacji w biznesie niezależny od systemu informatycznego czy też branży. SAP ALE (Application Link Enabling) to wewnętrzny mechanizm pozwalający na wymianę dokumentów biznesowych zwykle wewnątrz organizacji pomiędzy różnymi instancjami systemów SAP (połacznei na bazie technologi RFC). W obydwu przypadkach przesyłane dokumenty przed ich wysyłką/zapisem w SAP przyjmują formę tzw. IDOC czyli ustrukturyzowanego dokumentu elektronicznego w systemie SAP.

Moje doświadczenia z EDI dotyczą w większości obszaru SAP MM oraz SAP WM. W chwili obecnej wymiana dokumentów zaopatrzeniowych/faktur pomiędzy partnerami biznesowymi jest coraz częściej standardem. Wszelkie sprawy związane z generowaniem komunikatów EDI oraz ich integracją (również obsługą błędów poprzez mechanizmy Workflow) są mi znane i wielokrotnie zajmowałem się zarówno definicją (mapowaniem) jak i konfiguracją tych rozwiązań.

Ostatnio pracując jako Architekt Rozwiązań Logistycznych miałem okazje uczestniczyć w budowie rozbudowanych modeli wymiany danych w przedsiębiorstwach oraz ich otoczeniu biznesowym. Drugim bardzo znaczącym obszarem wykorzystania EDI w moich projektach jest kwestia integracji z dostawcami usług logistycznych (LSP). W rozbudowanych łańcuchach dostaw zwłaszcza w branży FMCG coraz częściej firmy decydują się na outsourcing usług magazynowania oraz transportu w centrach dystrybucyjnych. Firmy LSP posiadają zwykle własne systemy klasy WMS zaś integracja dokumentów związanych z awizacją przyjęć czy też wysyłka realizowana jest jako komunikaty EDI z systemu firmy będącej właścicielem zapasów. Do tej pory realizowałem kilka takich projektów we współpracy z wiodącymi firmami LSP (np. Raben, DHL, Yusen) i każdy projekt był inny. Rozwiązania EDI są zwykle dostosowywane do konkretnych potrzeb biznesowych oraz środowiska IT. Jako środowisko IT mam tu na myśli różnego rodzaju formy komunikacji oraz aplikacje klasy EDI Middelware służące do zarządzania przepływem plików oraz mapowaniem ich struktury pomiędzy standardem SAP (IDOC) a standardem firmy LSP.

Mówiąc o EDI nie sposób wspomnieć o e-fakturach, które również są zwykle ‘konwertowane’ do formatu IDOC a następnie integrowane do SAP mechanizmami ALE. Komunikacja elektroniczna w kontekście moich ostatnich doświadczań nabiera również coraz szerszego znaczenia jako narzędzie wewnętrznej wymiany i synchronizacji danych w przedsiębiorstwie. Zwłaszcza mam to na myśli zarządzanie danymi podstawowymi w środowiskach heterogenicznych. W dużych firmach międzynarodowych, które pracują na różnych systemach (rożne instancje SAP bądź też różne aplikacje biznesowe) scentralizowane zarządzania danymi podstawowymi znakomicie ułatwia komunikację oraz raportowanie korporacyjne. Dane podstawowe typu indeksy materiałowe czy też nr pracowników HR często są tworzone centralnie a następnie replikowanie do systemów rozproszonych – SAP EDI/ALE świetnie się nadają do obsługi tego typu wymagań.”

Migracja danych

Migracja danych jest nieodzowną częścią każdego projektu wdrożeniowego. Kwestia jakości i kompletności danych (zwłaszcza podstawowych) w systemie klasy ERP jest jednym z kluczowych elementów sukcesu projektu. Istnieje wiele mechanizmów oraz sposobów realizacji tego zadania. Ze względu na złożoność zagadnienia często podczas projektów wdrożeniowych powołuj się odrębne zespoły do pozyskania, czyszczenia oraz załadowania danych do systemu docelowego. Zadnie to jest wielowątkowe i wymaga zróżnicowanych zdolności organizacyjnych, technicznych (bazy danych) jak i kompetencji czysto SAP-owych (n. LSMW). Wielokrotnie w mojej dotychczasowej karierze zajmowałem się tym zagadnieniem. Kwestie migracji danych we wszystkich modułach wymienionych powyżej w zakresie moich kompetencji są mi dogłębnie znane. Jeżeli chodzi o kwestie technicznej migracji do systemu SAP to moja znajomość obejmuje technologie typu LSMW, CAT, IDOC, BAPI (własne programy), SXDA oraz specjalistyczne programy dedykowane SAP do poszczególnych obiektów np. migracja zapasów na poziomie HUM.

Od wielu lat jestem posiadaczem i użytkownikiem programu firmy Winshuttle o nazwie TransactionalSHUTTEL. Jest to zewnętrzne narzędzie pozwalające na sprawne pozyskiwanie i ładowanie danych z/do systemu SAP do/z aplikacji MS Access czy też MS Excel. Wielokrotnie na moich projektach wykorzystuję to narzędzie, gdyż w znakomity sposób upraszcza i automatyzuje ono kwestie migracji danych. Moja znajomość aplikacji MS Access zdobyta w bardzo wczesnym okresie kariery zawodowej (jeszcze zanim zostałem konsultantem SAP) jest bardzo pomocna w przypadku zarządzania dużymi zbiorami danych.

Ostatnio na kilku projektach miałem okazję pracować jako Cutover Manager gdzie kwestie zarządzania procesem pozyskania, czyszczenia i ładowania danych wchodziły w zakres moich obowiązków. Musze stwierdzić, że koordynacja całego procesu migracji danych jest zadaniem trudnym i wymagającym zdolności czysto managerskich. Pewnie nie jest to obszar, który nie szczególnie odpowiada moim predyspozycją (raczej jestem osobą o kompetencjach technicznych) jednak sądząc po efektach (udane Go Live) muszę stwierdzić, że koordynacja prac związanych z migracją danych to obszar mi znany, w którym realizowałem szereg odpowiedzialnych zadań w przeszłości.

Do tej pory największym zadaniem jakie kiedykolwiek realizowałem była kwestia migracji danych podstawowych materiałów u polskiego nadawcy publicznego TV, gdzie baza indeksów miała 120 000 rekordów.

Archiwizacja danych

Archiwizacja danych w SAP często mylona jest z archiwizacją optyczną (patrz ArchiveLink) aczkolwiek są to zupełnie różne obszary funkcjonalne. Archiwizacja danych to proces ‘odchudzania’ bazy danych SAP z obiektów (danych podstawowych, dokumentów), które już nie są potrzebne lub są na tyle rzadko używane, że dostęp do nich nie musi być bezpośredni z bazy danych lecz poprzez archiwum. Oczywiście najczęstszym powodem uruchamiania projektów archiwizacji danych w SAP są powody wydajnościowe czy szybkość pracy aplikacji SAP (dostęp do dokumentów) czy to pojemność dysków systemowych. Często ważnym powodem dla archiwizacji danych są wymagania prawne np. w Polsce dokumenty księgowe powinny być dostępne w systemie informatycznym dla organów kontroli skarbowej przez okres 5 lat. Każdy konsultant SAP zna transakcję SARA, poprzez którą można zrealizować proces archiwizacji danych jednak proces ten jest zwykle o wiele bardziej skomplikowany niż się wydane na pierwszy rzut oka. Po pierwsze należy przygotować (zainstalować oraz połączyć z SAP) zewnętrzny system archiwum danych (poprzez protokół ArchiveLink). System ten powinien spełniać wszelkie wymogi dla tej klasy narzędzi np. posiadać technologię archiwizacji na nośniki magnetyczne czy też sprawny plan zarządzania kopiami zapasowymi.

Zwykle projekt archiwizacji poprzedzony jest analizą mającą na celu selekcję obiektów wymagających archiwizacji np. analiza, które obiekty powodują największy przyrost w bazie danych. Na tej podstawie dokonywana jest zwykle analiza obiektów zależnych (powiązanych), które różnie muszą być archiwizowane w celu zapewnienia spójności danych w archiwum oraz w przypadku przewracania danych z archiwum do SAP. Są to procesy skomplikowane wymagające nie tylko zdolności technicznych ale również kompetencji biznesowych, modułowych w celu sprawnego ustalenia zależności obiektowych i rozwiązywaniu konfliktów pomiędzy obiektami.

Ostatni krok czyli fizyczna archiwizacja to tylko zwieńczenie poprzednich o wiele bardziej pracochłonnych kroków.
Obecnie ze względu na stosunkowo tanie pozyskiwanie nowych mocy obliczeniowych oraz zasobów dyskowych (oraz coraz szersze wkraczanie technologii In-Memory SAP HANA) projekty archiwizacji danych są odkładane na później. Jednak wcześniej czy później większość systemów SAP w przedsiębiorstwach będzie musiało zmierzyć się z tematem archiwizacji danych.

Jednym z najtrudniejszych projektów w jakich kiedykolwiek uczestniczyłem był projekt związany w wydzieleniem części przedsiębiorstwa do odrębnej spółki (akwizycja) działającej na odrębnym systemie SAP. Założeniem projektu był sklonowanie istniejącego systemu SAP na odrębna instancję a następnie ‘wyczyszczenie’ danych wrażliwych dotyczących wydzielonej części przedsiębiorstwa w oryginalnym systemie SAP oraz podobne działanie z danymi na systemie sklonowanym. Dane wrażliwe to indeksy materiałowe, ceny sprzedaży, dokumenty sprzedaż, dane kontrolingowe, HR itd. jako metodę ‘czyszczenia’ danych wrażliwych wybrano archiwizację danych w SAP. Będąc liderem tego przedsięwzięcia doskonale poznałem mechanizmy rządzące archiwizację danych w SAP ich złożoność i współzależności. Cała trudność projektu polegała na tym, aby nie zarchiwizować za dużo w poszczególnych systemach. Projekt był częścią jednej z większych akwizycji w ostatnich latach gdzie amerykańska spółka Kraft przejmowała spółkę Cadbury.