Czego się dowiesz z tego artykułu
Jedne dane, trzy działy, trzy różne perspektywy. Dlaczego spójność danych w finansach to problem systemowy, a nie raportowy?
W wielu organizacjach problem z danymi nie zaczyna się w momencie ich zbierania ani nawet w momencie ich importu z systemów źródłowych.
Zaczyna się dużo później – wtedy, gdy te same dane są wykorzystywane w różnych procesach decyzyjnych i raportowych.
HR patrzy na dane przez pryzmat struktur zatrudnienia, etatów i kosztów personalnych.
Controlling analizuje te same dane jako element większego modelu kosztowego.
Finanse interesuje natomiast to, czy wszystko się domyka, jest spójne między modułami i możliwe do obrony w audycie.
Każdy zespół ma rację. Problem polega na tym, że system bardzo często nie jest zaprojektowany tak, aby te różne perspektywy mogły współistnieć na jednym fundamencie danych.
Jak mówi Monika Kaśkow, Senior Consultant w FlexiSolutions, jednym z największych błędów projektowych jest myślenie, że skoro dane są wspólne, to również sposób ich prezentacji i poziom szczegółowości powinny być wspólne. W praktyce prowadzi to do nadmiarowych widoków, ręcznych obejść i niekontrolowanego kopiowania danych między narzędziami.
Ten same dane, różne potrzeby biznesowe
Z perspektywy architektury systemowej dane są neutralne. To, co nadaje im znaczenie, to sposób ich agregacji, kontekst analityczny oraz rola użytkownika, który z nich korzysta.
W HR naturalnym poziomem pracy jest poziom rekordu pracownika. Dane personalne, wynagrodzenia, składniki płacowe, zmiany etatów i przypisania organizacyjne muszą być widoczne w szczególe, bo bez tego nie da się prowadzić planowania ani analiz kadrowych.
Jednak w momencie, gdy te same dane trafiają do controllingu, szczegółowość zaczyna być problemem, a nie zaletą. Jak podkreśla Monika, controlling nie powinien mieć dostępu do informacji o tym, kto dokładnie, ile zarabia. Potrzebuje zagregowanego obrazu kosztów według MPK, działów, projektów czy centrów odpowiedzialności. Liczy się struktura, trend i odchylenie, a nie rekord jednostkowy.
Jeszcze inną rolę pełni dział finansów. Tu kluczowe są spójność modeli danych, jednoznaczność definicji i zgodność między modułami. Finanse patrzą na dane przez pryzmat księgi głównej, rachunku wyników i bilansu.
Jak mówi Monika:
Ten sam koszt może funkcjonować równolegle jako:
– pozycja kosztowa przypisana do pracownika w HR,
– agregat kosztów osobowych w controllingu,
– pozycja w rachunku wyników w finansach.
Każda z tych perspektyw jest poprawna, pod warunkiem że wszystkie opierają się na tym samym modelu danych i tych samych hierarchiach.
Dane wspólne, hierarchie wspólne, ale różne agregacje
Monika bardzo mocno akcentuje w rozmowie znaczenie danych wspólnych, np. MPK, produktów, klientów, struktur organizacyjnych. To są elementy, które mogą przenikać się przez różne moduły i działy.
Problem pojawia się wtedy, gdy te hierarchie są utrzymywane ręcznie w kilku miejscach albo w jednym systemie są aktualizowane automatycznie, a w innym wymagają ręcznej ingerencji. Wystarczy jedna niespójność, aby raporty zaczęły się rozjeżdżać.
Dlatego kluczowe jest rozróżnienie między spójnością danych a spójnością widoku. Dane bazowe i hierarchie muszą wzajemnie sobie odpowiadać. Natomiast agregacje, filtry i poziomy szczegółowości mogą być projektowane osobno dla HR, controllingu i finansów.
Excel maskuje problem, system go obnaża
W wielu organizacjach przez lata rolę warstwy integracyjnej pełni Excel. Pozwala ręcznie połączyć dane z różnych źródeł, dodać brakujące kolumny, poprawić hierarchie i dopasować raport pod bieżącą potrzebę. Przez pewien czas to działa i daje poczucie kontroli.
Problem polega na tym, że Excel maskuje niespójności, zamiast je rozwiązywać. Gdy dane są kopiowane między plikami, a logika biznesowa zaszyta w formułach, organizacja traci kontrolę nad tym, która wersja danych jest aktualna. Monika bardzo wyraźnie podkreśla, że największym ryzykiem są sytuacje, w których w jednym systemie coś zostało zautomatyzowane, a w innym nadal jest utrzymywane ręcznie. Wystarczy urlop, zmiana osoby w zespole albo brak informacji i nagle te same dane zaczynają funkcjonować równolegle w różnych wersjach.
System klasy EPM działa odwrotnie. Nie pozwala na prowizoryczne obejścia. Jeżeli hierarchia nie jest spójna albo dana nie istnieje w modelu, błąd jest widoczny od razu. To bywa bolesne na początku, ale w dłuższej perspektywie porządkuje sposób pracy z danymi.
Jeden fundament, wiele ról użytkowników
W dobrze zaprojektowanym systemie dane nie muszą być przechowywane w jednym modelu, jednak powinny tworzyć spójny i konsekwentny obraz. Dostęp do danych powinien być kontrolowany przez role i uprawnienia, a użytkownik końcowy – jak podkreśla Monika – nie powinien być konfrontowany z pełną złożonością systemu. Osoba odpowiedzialna za jedną formatkę nie musi rozumieć całej architektury danych. Co więcej, zbyt duża ekspozycja na złożoność bardzo często powoduje opór i poczucie chaosu.
Dlatego we wdrożeniach FlexiEPM tak duży nacisk kładzie się na role, uprawnienia i zakres odpowiedzialności.
HR widzi dane personalne, controlling widzi agregaty kosztowe, finanse koncentrują się na kompletności i zgodności danych z wymogami raportowymi oraz regulacyjnymi.
Każdy pracuje na tym samym fundamencie, ale w innym kontekście.
To podejście ma też bardzo praktyczny wymiar. Ułatwia onboarding nowych osób. Zamiast tłumaczyć sieć powiązanych arkuszy i historycznych obejść, nowy pracownik dostaje jasny zakres odpowiedzialności i zestaw narzędzi dopasowany do swojej roli. System prowadzi go przez proces, zamiast zmuszać do domyślania się, co z czego wynika.
FlexiEPM jako warstwa logiki biznesowej i danych
W projektach realizowanych w FlexiEPM bardzo szybko wychodzi na jaw, że raportowanie jest tylko ostatnim etapem. Prawdziwa praca odbywa się wcześniej – na poziomie modelu danych, definicji hierarchii i relacji między modułami.
FlexiEPM działa jako wspólny fundament danych dla controllingu, HR i finansów. Dane mogą być zasilane z różnych systemów źródłowych, ale logika biznesowa jest centralna i spójna. Dzięki temu Power BI czy inne narzędzia raportowe nie muszą „naprawiać” danych, tylko je prezentują.
Jak pokazują doświadczenia wdrożeniowe, organizacje zaczynają doceniać takie podejście w momencie, gdy skala rośnie. Gdy pojawia się więcej użytkowników, więcej raportów i więcej punktów decyzyjnych, ręczne uzgadnianie danych przestaje być możliwe.
Dane jako narzędzie współpracy, nie pole konfliktu
Na koniec warto podkreślić jedną rzecz, która bardzo mocno wybrzmiewa w rozmowach z zespołem wdrożeniowym. Dane same w sobie nie są problemem. Problemem jest brak wspólnego języka i architektury, która pozwala różnym zespołom pracować na tych samych informacjach bez wchodzenia sobie w drogę.
Dobrze zaprojektowany system nie zmusza organizacji do kompromisów między bezpieczeństwem, szczegółowością a użytecznością. Pozwala każdemu działowi widzieć to, co jest mu potrzebne, dokładnie w takiej formie, w jakiej tego potrzebuje.
I właśnie w tym miejscu FlexiEPM przestaje być systemem raportowym, a zaczyna być narzędziem porządkującym sposób myślenia o danych w całej organizacji.
