Jedna definicja przychodu dla każdego raportu i agenta

Na posiedzenie zarządu trafiają trzy kwoty przychodu za ten sam miesiąc. Sprzedaż przynosi jedną z CRM: transakcje oznaczone jako wygrane. Finanse przynoszą drugą z księgi: wystawione faktury pomniejszone o korekty. Operacje przynoszą trzecią z systemu magazynowego: wysłane zamówienia. Każda jest poprawna według własnej definicji, a pierwsze dwadzieścia minut spotkania schodzi na ustalaniu, skąd różnice.

Teraz agent dostaje pytanie, jak przychód wygląda na tle planu. Której definicji użyje? W praktyce tej z tabeli, którą znajdzie jako pierwszą, a następnym razem być może innej.

Przyczyna jest taka, że definicje wskaźników biznesowych mieszkają w warstwie raportów: w formułach każdego dashboardu, w każdym arkuszu, w zapytaniach każdego analityka. Każdy odbiorca implementuje je od nowa, a implementacje rozjeżdżają się poprawka po poprawce. Agenci to pogarszają, nie dlatego, że są niestaranni, ale dlatego, że jest ich więcej, odpytują dane bezpośrednio i dają odpowiedzi szybciej, niż ktokolwiek zdąży sprawdzić stojącą za nimi definicję.

Uznana odpowiedź ma w business intelligence swoją nazwę: warstwa semantyczna. To wspólna warstwa, która raz definiuje wskaźniki i wymiary biznesowe nad surowymi danymi, tak że każde narzędzie prosi o „przychód” po nazwie, zamiast liczyć go od nowa. Kostki OLAP robiły wersję tego już dekady temu. Idea ma dziś większe znaczenie, bo wśród odbiorców jest oprogramowanie, które samo pisze zapytania.

Gdzie rozjeżdżają się definicje

Formuły skopiowane do raportów. Jedna kopia dostaje poprawkę, pozostałe nie, i liczby się rozchodzą, choć nikt o tym nie zdecydował.

Jedno słowo, kilka znaczeń. Przychód zakontraktowany, zafakturowany i rozpoznany to pojęcia uprawnione i różne. Nazywanie każdego z nich „przychodem” gwarantuje kłótnię.

Ciche filtry. Sprzedaż wewnątrzgrupowa wyłączona w jednym miejscu, a w innym nie. Korekty odjęte tu, a tam nie. Testowy klient, którego nikt nie usunął z jednego źródła.

Czas. Data zamówienia, data faktury albo data dostawy: ta sama transakcja wpada do różnych miesięcy, zależnie od tego, której daty używa raport.

Waluta i zaokrąglenia. Jaki kurs, z którego dnia, i gdzie zaokrąglony.

Agenci wybierający sami. Model językowy piszący zapytania do surowych tabel za każdym razem wybierze wiarygodną definicję. Wiarygodna to nie to samo co uzgodniona i nie ma gwarancji, że dwa razy będzie ta sama.

Zdefiniuj raz, u źródła

Nazwij każdy wariant. Przychód zakontraktowany, zafakturowany i rozpoznany stają się osobnymi, nazwanymi wskaźnikami, każdy z właścicielem i zapisaną definicją. Celem nie jest jedna definicja przychodu dla całej firmy, tylko dokładnie jedna definicja za każdą nazwą.

Definiuj wskaźniki na modelu biznesu, a nie na tabelach. Przychód zafakturowany definiuje się na fakturach i korektach jako obiektach w ontologii firmy, z ich stanami i relacjami, a nie na nazwach kolumn, które zmieniają się przy aktualizacji systemu źródłowego.

Niech wszystko pyta warstwę. Dashboardy, arkusze, eksporty i agenci proszą o wskaźnik po nazwie. Zwłaszcza agentom nie wolno składać wskaźnika biznesowego z surowych tabel; proszą o niego, a odpowiedź przychodzi razem z definicją.

Wersjonuj definicje i nadawaj im daty obowiązywania. Kiedy definicja się zmienia, zeszłoroczne liczby nadal da się odtworzyć tak, jak je raportowano, a zmiana jest widoczna jako zmiana.

Pokazuj definicję razem z liczbą. Każda odpowiedź mówi, jaki to wskaźnik, z jakimi filtrami, za jaki okres i według stanu na kiedy. Liczba bez tego to plotka z miejscami po przecinku.

W projekcie Hurukan wskaźniki są definiowane na obiektach warstwy Ontologia i czytane z jednego modelu danych w warstwie Dane, więc raport i agent zadający to samo pytanie dostają tę samą odpowiedź z tego samego powodu. Kontrola budżetu w module Finanse (plan, zaangażowanie, wykonanie i prognoza) jest zbudowana właśnie na takich nazwanych miarach. To jest w budowie.

Test na dziś

Poproś trzy osoby o kwotę przychodu za zeszły miesiąc i o to, jak do niej doszły: kogoś z finansów, kogoś ze sprzedaży i osobę, która przygotowuje materiały dla zarządu. Zapisz trzy liczby i trzy metody.

Jeśli Twoja firma ma już asystenta AI podłączonego do danych, zadaj mu to samo pytanie dwa razy, w dwóch osobnych sesjach, i zapisz, co odpowiada i w jaki sposób.

Jeśli w tych pięciu odpowiedziach masz więcej niż jedną liczbę i nie umiesz nazwać powodu każdej różnicy, potrzebujesz wspólnej definicji, zanim będziesz potrzebować kolejnego raportu. Szerszy argument za tym, żeby analitykę zaczynać od pytań, a nie od dashboardów, jest w tekście dashboard, którego nikt nie otwiera.