Integracja FlexiEPM z SAP przez API

W projektach konsolidacji finansowej kluczowe znaczenie ma nie tylko samo narzędzie raportowe, ale również sposób zasilania go danymi z systemów ERP. W tym artykule pokazujemy przykład integracji FlexiEPM z SAP S/4HANA 2020 przez API na potrzeby pobierania danych z księgi głównej, ich dalszego przetwarzania oraz mapowania do grupowych struktur raportowych.

Integracja systemu EPM z ERP może być realizowana na kilka sposobów. Wybór modelu zależy od architektury systemu źródłowego, zakresu danych, częstotliwości odświeżania oraz uzasadnienia biznesowego.

Integracja z SAP nie powinna oznaczać kolejnego małego projektu developerskiego za każdym razem, gdy controlling potrzebuje nowych danych.

W jednym z projektów wdrożenia FlexiEPM jako systemu do konsolidacji finansowej wykorzystaliśmy integrację przez API do pobierania danych z SAP. 
W praktyce nie chodzi o jednorazowy mechanizm przypisany wyłącznie do jednego systemu ERP, ale o wzorzec integracyjny oparty na komponentach ETL FlexiEPM, który można dostosować do konkretnego systemu źródłowego, zakresu danych i architektury klienta.

FlexiEPM może być zasilany danymi z systemów ERP w różnych modelach, dobieranych do potrzeb organizacji i możliwości systemu źródłowego.

Najprostszy model to ładowanie plików wygenerowanych z ERP. Sprawdza się przy szybkim uruchomieniu projektu, w mniejszych spółkach, przy zagranicznych jednostkach zależnych, zewnętrznych biurach księgowych albo tam, gdzie automatyczna integracja nie jest potrzebna.

W wielu wdrożeniach stosujemy również integrację baza-do-bazy. To częsty scenariusz w środowiskach on-premise, szczególnie gdy system ERP nie udostępnia odpowiedniego API. Taki model wymaga jednak dobrej znajomości struktury danych i logiki biznesowej systemu źródłowego.

Coraz częściej wykorzystywanym podejściem jest integracja przez API. Jeżeli system źródłowy udostępnia odpowiednie interfejsy, API pozwala pobierać dane bez bezpośredniego odczytu struktur bazowych ERP. Jest to szczególnie istotne przy systemach chmurowych, ale może być również właściwym modelem integracji dla systemów on-premise, jeżeli API jest standardową warstwą udostępniania danych.

Wdrożenie FlexiEPM jako systemu do konsolidacji finansowej bardzo często wymaga zasilenia systemu danymi z księgi głównej. Chodzi przede wszystkim o dane potrzebne do przygotowania pakietów jednostkowych, czyli lokalnych danych finansowych, które następnie są mapowane do grupowych struktur raportowych i wykorzystywane w procesie konsolidacji.

Podstawowym zakresem danych są salda kont, najczęściej pobierane w formie obrotówki. To na ich podstawie można przygotować bilans i rachunek wyników jednostki, a następnie przemapować lokalny plan kont na układ raportowy grupy.

W wielu projektach sama obrotówka nie jest jednak wystarczająca. Dla potrzeb analityki menedżerskiej, uzgodnień oraz identyfikacji transakcji z jednostkami powiązanymi potrzebne są również zapisy księgowe wraz z referencją do dokumentów. W procesie konsolidacji ma to istotne znaczenie, ponieważ część informacji potrzebnych do eliminacji i analiz nie jest widoczna na poziomie samych sald kont.

W opisywanym projekcie jednostka dominująca korzystała z SAP jako systemu finansowo-księgowego, a zakres potrzebnych danych odpowiadał typowemu podejściu przy zasilaniu systemu konsolidacyjnego danymi z księgi głównej.

Kluczowy był wybór modelu technicznego integracji. Import plików nie dawał poziomu automatyzacji oczekiwanego przez zespół odpowiedzialny za raportowanie, a bezpośrednia integracja baza-do-bazy nie była właściwą ścieżką dla środowiska SAP.

Ponieważ po stronie systemu źródłowego dostępne było odpowiednie API, zasilenie FlexiEPM zostało oparte na kontrolowanym pobieraniu danych przez interfejs udostępniony po stronie SAP.

Po stronie SAP konieczne było zapewnienie dostępu do odpowiedniego API oraz mechanizmu uwierzytelnienia dla uzgodnionego zakresu danych. W praktyce szczegóły zależą od architektury systemu źródłowego i zasad bezpieczeństwa po stronie klienta. Może to oznaczać użytkownika technicznego, token, klucz, SSO, ograniczenia sieciowe lub inne mechanizmy kontroli dostępu.

Po stronie FlexiEPM konfiguracja odbywa się w ramach komponentów ETL. Dla danego źródła danych określany jest adres API, sposób pobierania danych, struktura danych wejściowych oraz mapowanie pól źródłowych do struktur wykorzystywanych w FlexiEPM. Następnie takie źródło może zostać włączone do procesu ETL, który zasila odpowiednie obszary modelu konsolidacyjnego.

Istotne jest to, że nie budujemy w takim przypadku osobnego, jednorazowego skryptu integracyjnego. Wykorzystujemy sprawdzony wzorzec pracy z API w module ETL FlexiEPM i dostosowujemy go do konkretnego systemu źródłowego, zakresu danych oraz wymagań projektowych.

Dane pobrane z SAP nie są wykorzystywane w FlexiEPM wyłącznie w strukturze lokalnego planu kont. W procesie konsolidacji muszą zostać przemapowane na wspólny układ raportowy grupy, który w naszych wdrożeniach nazywamy Grupowym Planem Kont.

Grupowy Plan Kont pełni rolę wspólnego mianownika dla danych pochodzących z różnych spółek i systemów finansowo-księgowych. Do tego układu mapowane są niezależnie lokalne plany kont poszczególnych jednostek. Dzięki temu możliwe jest przygotowanie spójnych danych do bilansu, rachunku wyników oraz wybranych not objaśniających.

Na etapie mapowania rozwiązywane są również typowe problemy prezentacyjne, które nie wynikają bezpośrednio z samego pobrania danych z ERP. Przykładem są konta rozrachunkowe, które w zależności od salda powinny być prezentowane jako należność albo zobowiązanie.

Dlatego integracja techniczna jest tylko pierwszym etapem procesu. Równie istotne jest poprawne przetworzenie danych księgowych do struktury raportowej wymaganej przez grupę.

Opisany przykład dotyczy integracji z SAP S/4HANA 2020, ale nie jest zamkniętym mechanizmem przypisanym wyłącznie do jednego systemu ERP. W praktyce jest to wzorzec integracyjny oparty na komponentach ETL FlexiEPM, który można dostosować do konkretnego systemu źródłowego, zakresu danych i architektury klienta.

API staje się coraz ważniejszym modelem integracji, szczególnie tam, gdzie system ERP działa w chmurze albo gdzie producent systemu udostępnia API jako standardową warstwę dostępu do danych. W takich sytuacjach integracja przez API pozwala uniknąć bezpośredniego odczytu struktur bazowych, ogranicza zależność od wewnętrznej logiki tabel systemu źródłowego i może być bardziej odporna na zmiany wersji lub konfiguracji ERP.

Podobny model wykorzystujemy nie tylko przy integracji z SAP. Komponenty ETL FlexiEPM mogą być stosowane również przy pobieraniu danych przez API z innych systemów ERP i systemów dziedzinowych, o ile udostępniają one odpowiednie interfejsy oraz uzgodniony zakres danych. W naszych projektach wykorzystywaliśmy takie podejście m.in. przy integracjach z Teta ERP oraz Odoo.

W praktyce dotyczy to nie tylko danych finansowo-księgowych. W projektach FP&A, raportowania zarządczego i konsolidacji finansowej dane mogą pochodzić również z systemów sprzedażowych, produkcyjnych, CRM, workflow, timesheet albo innych rozwiązań dziedzinowych.

Z perspektywy FlexiEPM ważne jest jednak nie samo pobranie danych, ale ich dalsze wykorzystanie w modelu finansowym: walidacja, mapowanie, przeliczenia, uzgodnienia oraz prezentacja w strukturach raportowych grupy. Dlatego integracja z ERP lub innym systemem źródłowym jest pierwszym etapem procesu. O wartości wdrożenia decyduje dopiero to, czy dane można spójnie wykorzystać w konsolidacji, budżetowaniu, raportowaniu zarządczym lub innych procesach finansowych.

Integracja przez API nie zastępuje pozostałych modeli zasilania danych. Uzupełnia je tam, gdzie system źródłowy udostępnia odpowiednie interfejsy, a oczekiwany poziom automatyzacji uzasadnia ich wykorzystanie. W niektórych projektach właściwym wyborem pozostanie ładowanie plików, w innych integracja baza-do-bazy, a w kolejnych właśnie API. Istotne jest dobranie modelu integracji do realnej architektury systemów, jakości dostępnych danych i celu biznesowego wdrożenia.