Skip to main content

Jak zaprojektować model danych, który działa zarówno dla ludzi, jak i dla AI

Sześć zasad projektowych do budowy modelu danych controllera obsługującego jednocześnie ludzi (dashboard, raporty) i maszyny (agenty AI, zautomatyzowaną analitykę): pojedyncze ścieżki obliczeniowe, zarządzane hierarchie, zakodowany rozkład odchyleń, eliminacje wewnątrzgrupowe jako logika modelu, spójność temporalna i metadane semantyczne.

Kluczowe wnioski

  • Każda metryka potrzebuje dokładnie jednej ścieżki obliczeniowej w modelu — jeśli ten sam wynik można obliczyć na dwa sposoby, AI znajdzie ten zły.
  • Hierarchie i reguły sumowania muszą być w modelu, nie w konfiguracji dashboard — AI musi agregować tak samo jak ludzie.
  • Rozkład odchyleń (cena/wolumen/mix) musi być zakodowany jako logika modelu — doraźna analiza w arkuszu jest niewidoczna dla AI.
  • Reguły eliminacji wewnątrzgrupowych należą do modelu, nie do arkuszy zamknięcia — zautomatyzowana konsolidacja tego wymaga.
  • Każdy punkt danych musi nieść status temporalny (otwarty/prowizoryczny/finalny) — AI nie odróżni danych bieżących od zamkniętych okresów bez jawnych metadanych.
  • Definicje biznesowe muszą być metadanymi modelu, nie dokumentacją w PDF — AI czyta struktury danych, nie podręczniki ładu zarządczego.

Artykuł towarzyszący — Dlaczego większość AI w finansach zawodzi — wyjaśnia, dlaczego modele danych zaprojektowane pod dashboard łamią się, gdy AI zaczyna je konsumować. Ten odpowiada na kolejne pytanie: jak powinien wyglądać model danych controllera?

Sześć zasad. Obowiązują niezależnie od narzędzia BI, platformy chmurowej czy ERP. Definiują, co “gotowość na AI” oznacza dla infrastruktury controllingu.

1) Jedna ścieżka obliczeniowa na metrykę

Każda metryka — przychody, marża brutto , EBITDA, kapitał obrotowy — potrzebuje dokładnie jednej ścieżki obliczeniowej. Nie jednej formuły w ERP, drugiej w dashboard i trzeciej w zeszłokwartalnym Excelu.

Model jednego odbiorcy: Marża brutto w trzech wersjach. ERP stosuje koszty standardowe. Dashboard — koszty rzeczywiste z ręcznymi korektami. Excel controllera — trzecią metodologię. Ludzie wiedzą, której użyć. Liczby “się zgadzają”, bo człowiek porusza się między nimi.

Model dwóch odbiorców: Jedna formuła w warstwie semantycznej . Metodologię alokacji definiuje się raz. Dashboard, AI, każdy przyszły odbiorca — ten sam wynik. Marża kontrybucyjna po alokacji znaczy jedno, wszędzie.

2) Zarządzane hierarchie z jawnymi regułami sumowania

Centrum kosztowe → dział → jednostka biznesowa → grupa. Zdefiniowane w modelu, nie w konfiguracji drill-down dashboard. Hierarchia obejmuje reguły: które podmioty konsolidują się, które eliminują się wzajemnie, na jakim poziomie agreguje się raportowanie zarządcze.

Model jednego odbiorcy: Logika sumowania żyje w Power BI. Budżet w Excelu grupuje inaczej. Controller stosuje reguły z pamięci. AI odpytuje płaskie tabele bez świadomości hierarchii.

Model dwóch odbiorców: Jedna definicja hierarchii. Każdy odbiorca sumuje i drąży identycznie. AI zapytane “Jaka jest EBITDA działu produkcji?” podąża tą samą ścieżką co controller.

Dla grup wielopodmiotowych to przecina się z konsolidacją. Pięć spółek zależnych, trzy kraje — model definiuje, które podmioty konsolidują się, jakie relacje wewnątrzgrupowe istnieją, na jakim poziomie grupa raportuje. Łączy się z Zasadą 4.

3) Jawny rozkład odchyleń

Rozkład cena/wolumen/mix zakodowany jako logika modelu. Nie obliczany doraźnie w arkuszu co cykl.

Model jednego odbiorcy: Controller oblicza rozkład cena/wolumen/mix ręcznie w Excelu każdego miesiąca. Dashboard pokazuje łączne odchylenie — plan vs. wykonanie, bez dekompozycji. AI zapytane “Dlaczego spadła marża?” nie potrafi rozłożyć. Generuje “marża spadła o X%” albo zmyśloną eksplanację z korelacji.

Model dwóch odbiorców: Składniki odchyleń (cena, wolumen, mix, FX, koszty) to predefiniowane wymiary. Każdy odbiorca odpytuje dowolny składnik, dowolny okres, dowolny podmiot, dowolną linię produktową.

To zasada adresująca pytanie faktycznie zadawane przez controllerów: “Co spowodowało zmianę?” Kiedy logika dekompozycji jest w modelu, AI odpowiada z tym samym rygorem co controller — ale dla każdego produktu, regionu, okresu jednocześnie.

4) Reguły eliminacji wewnątrzgrupowych jako logika modelu

Transakcje wewnątrzgrupowe i ich eliminacja przy konsolidacji — zdefiniowane w modelu. Nie w arkuszu, który controller grupowy prowadzi podczas zamknięcia.

Model jednego odbiorcy: Eliminacje w skoroszycie Excela. Controller identyfikuje pasujące transakcje, nanosi zapisy eliminacyjne, tworzy widok skonsolidowany. AI zapytane “Jakie są przychody grupy?” sumuje wszystkie podmioty bez eliminacji sprzedaży wewnątrzgrupowej. Zawyża o pełną wartość transakcji wewnętrznych.

Model dwóch odbiorców: Relacje par podmiotów i reguły eliminacji w modelu. Widoki skonsolidowane i nieskonsolidowane jako wymiary modelu. AI zapytane “Jaka jest EBITDA grupy?” stosuje eliminacje automatycznie.

Dla grupy ze spółkami w Polsce, Czechach i na Słowacji — każda na innym ERP (np. Comarch ERP Optima, enova365, Symfonia), ze sprzedażą wewnątrzgrupową, opłatami zarządczymi, usługami shared service — logika eliminacji to ekspertyza controllera grupowego. Przekształcenie jej z logiki arkuszowej w logikę modelu umożliwia konsolidację wspomaganą przez AI.

5) Spójność temporalna — stany cyklu zamknięcia

Każdy punkt danych niesie metadane temporalne: otwarty, prowizoryczny lub finalny. Na podmiot, na okres.

Model jednego odbiorcy: Controller wie, że marzec jest zamknięty, a kwiecień prowizoryczny — trzy spółki zamknęły okres, dwie nie przesłały danych. Ta wiedza żyje w głowie controllera lub mailu ze statusem. Dashboard pokazuje oba miesiące identycznie. AI traktuje prowizoryczne liczby kwietnia jako finalne.

Model dwóch odbiorców: Flaga statusu w modelu. AI zapytane “Jakie były przychody w kwietniu?” odpowiada: “Kwiecień jest prowizoryczny — 3 podmioty zamknęły okres, 2 wciąż otwarte. Przychody z zamkniętych podmiotów wynoszą X EUR.”

Zapobiega najczęstszemu trybowi awarii AI w raportowaniu zarządczym : prezentowaniu niekompletnych danych jako kompletnych.

6) Definicje semantyczne jako metadane modelu

Co znaczą “przychody”, jak oblicza się “EBITDA”, co obejmuje “FTE” — dołączone do modelu jako metadane. Nie w PDF-ie ze słownikiem. Nie na Confluence. Nie w polityce ładu zarządczego zatwierdzonej dwa lata temu.

Model jednego odbiorcy: Definicja przychodów w podręczniku finansowym. Różni ludzie interpretują ją nieco inaczej. Nowy controller uczy się metodą prób i błędów. AI nie ma dostępu do definicji i zgaduje z nazw kolumn.

Model dwóch odbiorców: Każda metryka niesie definicję, formułę, lineage źródłowy i właściciela jako metadane. AI zapytane “Jak oblicza się marżę brutto?” odpowiada z modelu.

Zamyka pętlę. Zasady 1-5 zapewniają poprawność obliczeń. Zasada 6 zapewnia, że każdy odbiorca rozumie, co model oblicza i dlaczego.

Co to zmienia

Te zasady nie tylko umożliwiają AI. Poprawiają też sposób pracy ludzi z tymi samymi danymi.

Raportowanie do zarządu staje się deterministyczne. Ta sama liczba w dashboard, pakiecie zarządczym i podsumowaniu AI. Bez uzgodnień.

Cykle zamknięcia zyskują przejrzystość. Wszyscy widzą ten sam status zamknięcia. Bez maili o statusie.

Analiza odchyleń skaluje się. Cena/wolumen/mix dla każdej linii produktowej, każdego regionu — praca, która wcześniej wymagała dni arkuszy na cykl.

AI generuje wiarygodne odpowiedzi. Nie inteligentniejsze AI. Lepsze fundamenty. Proces równoległy znika.

Roland Berger: 25% skrócenie czasu zamknięcia miesiąca dzięki AI — tam, gdzie fundamenty danych natywnie to wspierały. GoodData: 50-80% redukcja złożoności semantycznej dzięki zarządzanym warstwom semantycznym. Nie lepsze AI. Lepsza infrastruktura.

Od czego zacząć

Nie roczny projekt. Decyzje projektowe wdrażane przyrostowo.

Zacznij od Zasady 1 — zaudytuj, które metryki mają wiele ścieżek obliczeniowych. Jeśli marżę brutto oblicza się inaczej w ERP, narzędziu BI i arkuszu — to pierwsza rzecz do naprawienia.

Potem Zasada 6 — dołącz definicje do modelu. Nawet podstawowe metadane (formuła, właściciel, data ostatniej walidacji) zmieniają sposób interakcji ludzi i AI z danymi.

Zasady 2-5 w miarę jak złożoność tego wymaga. Grupy wielopodmiotowe potrzebują zarządzania hierarchiami i eliminacji wewnątrzgrupowych wcześnie. Jednopodmiotowe firmy mogą ich nie potrzebować.

Test: czy organizacja potrafi generować spójne odpowiedzi bez heroicznego kontekstu ludzkiego? Jeśli tak, model jest dual-consumer. Jeśli nie, tych sześć zasad wskazuje, gdzie są luki.


Źródła: AtScale — Why AI Redefined the Semantic Layer , GoodData — How to Modernize Your BI for the AI Era , KPMG — Rebuilding Data Governance in the Age of AI , Roland Berger — Mastering AI in the Finance Function

Powiązane kompetencje

Ład danych finansowych — definicje, kontrole, odpowiedzialność

Zobacz, jak ta koncepcja wpisuje się w nasze podejście.

Poznaj

Zaczynamy!

Zmień swój controlling finansowy

Od fundamentów raportowania po kompleksowe usługi zarządzania — pomagamy zespołom finansowym widzieć wyraźnie, decydować pewnie i działać zdecydowanie.

Umów bezpłatną konsultację