Artykuł powstał we współpracy z naszym ekspertem Łukasz Lelwic, Solution Architect w DataRiseLab.
Podsumowanie: W wielu organizacjach definicja marży nie znajduje się w jednym miejscu. Część logiki jest ukryta w zapytaniach SQL, część w arkuszach Excel, a część w miarach Power BI. Dopóki osoby, które tworzyły raporty, są dostępne, wynik można wyjaśnić. Problem pojawia się przy zmianie zespołu, wdrożeniu nowej spółki lub budowie kolejnej analizy. W DataRiseLab traktujemy definicję marży jako element architektury danych, a nie wiedzę ukrytą w narzędziach lub głowach pojedynczych osób.
Większość firm potrafi podać aktualną marżę. Znacznie mniej firm potrafi odpowiedzieć na prostsze pytanie:
Jak dokładnie została policzona?
Na pierwszy rzut oka odpowiedź wydaje się oczywista. W końcu marża widnieje w raporcie, dashboardzie lub prezentacji zarządczej. W praktyce jej definicja często jest rozproszona pomiędzy kilka różnych miejsc:
-
-
zapytanie SQL przygotowane kilka lat temu,
-
arkusz Excel zawierający dodatkowe korekty,
-
miarę w Power BI,
-
ustalenia, które nigdy nie zostały formalnie zapisane.
-
Przez długi czas taki model może działać poprawnie. Organizacja ufa wynikom, ponieważ osoby odpowiedzialne za raportowanie wiedzą, skąd pochodzą liczby. Problem pojawia się wtedy, gdy firma rośnie. Nowa spółka trafia do grupy. Powstaje kolejny raport. Zespół przechodzi zmiany organizacyjne. W pewnym momencie pojawia się pytanie:
Która definicja marży jest właściwa?
A jeszcze częściej:
Czy wszystkie raporty pokazują ten sam wynik?
Dlaczego ta sama marża może opowiadać różne historie?
W wielu firmach marża jest traktowana jak obiektywny wskaźnik. Wystarczy spojrzeć na raport i wiadomo, który produkt jest bardziej rentowny. W praktyce odpowiedź zależy od tego, jakie koszty uwzględniamy i w jaki sposób je przypisujemy.
Rozważmy uproszczony przykład. Produkt A i produkt B generują po 100 tys. zł przychodu. Każdy posiada również po 60 tys. zł kosztów bezpośrednich.
Na tym podobieństwa się kończą. Oba produkty wymagają 100 godzin pracy produkcyjnej, ale są wytwarzane w inny sposób.
Produkt A powstaje w dwóch dużych seriach. W ciągu miesiąca wymaga dwóch przezbrojeń maszyny po pięć godzin każde. Produkt B realizowany jest w krótkich partiach. Aby wyprodukować tę samą wartość sprzedaży, potrzebnych jest osiem przezbrojeń po pięć godzin.
Oznacza to, że Produkt B wymaga znacznie większej liczby przezbrojeń niż Produkt A.
Załóżmy dodatkowo, że firma musi rozliczyć koszty pracy maszyn oraz koszty przezbrojeń. Jeżeli koszty pośrednie zostaną rozdzielone proporcjonalnie do przychodu, oba produkty otrzymają podobne obciążenie kosztowe. W efekcie raport pokaże taką samą marżę dla każdego z nich.
Co pokaże tradycyjny raport?
Jeżeli całą pulę kosztów pośrednich, czyli 40 tys. zł, rozdzielimy według przychodu, oba produkty otrzymają identyczne obciążenie:
-
-
Produkt A: 20 tys. zł
-
Produkt B: 20 tys. zł
-
W efekcie raport pokaże dokładnie ten sam wynik. Marża każdego produktu wyniesie 20%. Na pierwszy rzut oka oba produkty wyglądają równie atrakcyjnie.
Co się stanie, gdy uwzględnimy rzeczywiste wykorzystanie zasobów?
Załóżmy teraz, że koszty pracy maszyny rozliczamy według godzin pracy, a koszty przezbrojeń według czasu przezbrojeń. Ponieważ oba produkty wykorzystują po 100 godzin pracy produkcyjnej, każdy otrzymuje po 10 tys. zł kosztów pracy maszyny.
Inaczej wygląda sytuacja w przypadku przezbrojeń. Łączny czas przezbrojeń wynosi 50 godzin:
-
-
10 godzin dla Produktu A
-
40 godzin dla Produktu B
-
W rezultacie:
-
-
Produkt A otrzymuje 4 tys. zł kosztów przezbrojeń
-
Produkt B otrzymuje 16 tys. zł kosztów przezbrojeń
-
Marża zmienia się istotnie:
-
- Produkt A: 26%
- Produkt B: 14%
Co ważne, całkowity wynik firmy pozostaje taki sam. Nie zmieniły się przychody. Nie zmieniły się koszty. Zmienił się wyłącznie sposób przypisania kosztów do produktów.
Warto jednak pamiętać, że sama zmiana sposobu alokacji kosztów nie tworzy oszczędności. Ograniczenie liczby przezbrojeń może najpierw jedynie uwolnić zdolność produkcyjną. Rzeczywista wartość pojawi się dopiero wtedy, gdy firma wykorzysta odzyskany czas, ograniczy nadgodziny lub rzeczywiście uniknie kosztu.
Marża po alokacji kosztów nie powinna być też jedyną podstawą decyzji o przyjęciu nowego zlecenia. Równie ważne są koszty przyrostowe oraz dostępna zdolność produkcyjna.
Dlaczego taki przykład?
Ponieważ dobrze pokazuje, że marża nie jest wyłącznie wynikiem działania matematycznego. Jest efektem zestawu decyzji biznesowych.
Musimy zdecydować:
-
-
które koszty uwzględniamy,
-
jakie zdarzenia biznesowe chcemy odwzorować,
-
według jakiego klucza rozliczamy koszty,
-
jaki poziom szczegółowości uznajemy za właściwy.
-
To właśnie dlatego pytanie: „Jaka jest marża produktu?” często powinno zostać poprzedzone innym pytaniem: „Jak dokładnie została policzona?”
Najtrudniejszy moment pojawia się wcześniej niż obliczenie marży
ERP zna produkty, zlecenia produkcyjne, koszty i sprzedaż. MES lub ewidencja produkcyjna zna przebieg pracy maszyn, postoje i przezbrojenia. Problem polega na tym, że te systemy często opisują te same zdarzenia w różny sposób.
W naszym przykładzie koszt przezbrojenia musi ostatecznie trafić do konkretnego produktu. Zanim jednak będzie można go przypisać, trzeba odpowiedzieć na kilka praktycznych pytań:
-
-
Którego zlecenia dotyczyło przezbrojenie?
-
Czy przygotowanie maszyny przypisujemy do rozpoczynanej partii?
-
Jak obsłużymy jedno zdarzenie obejmujące kilka zleceń?
-
Co zrobić z brakującym końcem zdarzenia albo nakładającymi się przedziałami czasu?
-
Jeżeli organizacja nie uzgodni sposobu łączenia tych informacji, dwa poprawne źródła danych mogą prowadzić do dwóch różnych wyników.
Dlatego projektowanie sposobu liczenia marży nie powinno zaczynać się od raportu. Powinno zaczynać się od modelu danych.
Dlaczego ten problem często wychodzi na jaw podczas migracji do Microsoft Fabric?
Wiele organizacji przez lata rozwijało swoje środowiska raportowe w oparciu o hurtownie danych, raporty i procesy tworzone przez różne zespoły.
Dopiero migracja z legacy Data Warehouse do Microsoft Fabric pokazuje, jak wiele definicji biznesowych jest rozproszonych po organizacji.
Część logiki biznesowej znajduje się w procedurach SQL. Część w procesach ETL. Część została zaszyta bezpośrednio w raportach lub arkuszach Excel.
W praktyce migracja nie polega więc wyłącznie na przeniesieniu danych. To również moment uporządkowania definicji biznesowych i ustalenia jednej wspólnej wersji prawdy dla całej organizacji.
Gdzie powinna znajdować się definicja marży?
W wielu organizacjach odpowiedź brzmi: „w Excelu”, „w SQL-u” albo „u kontrolera”. To działa do momentu, gdy pojawia się kolejny raport, nowa spółka lub zmiana w zespole. Nasze podejście zakłada, że wiedza o tym, jak liczymy wynik, powinna należeć do organizacji, a nie do pojedynczych narzędzi czy osób.
Dlatego definiujemy ją na kilku poziomach architektury.
W Microsoft Fabric pozwala nam to oddzielić dane źródłowe od logiki biznesowej oraz od sposobu prezentacji wyników w raportach. Dzięki temu definicje mogą być rozwijane i kontrolowane niezależnie od pojedynczych dashboardów.
Silver porządkuje znaczenie danych
Zanim zaczniemy liczyć marżę, musimy mieć pewność, że wszyscy mówią o tych samych produktach, klientach i jednostkach organizacyjnych.
Na poziomie Silver porządkujemy tożsamość danych oraz historię zmian. W wielu projektach realizujemy to z wykorzystaniem podejścia Data Vault, które pozwala zachować historię obiektów biznesowych, relacji oraz zmian zachodzących w czasie. Dzięki temu produkt, klient czy jednostka organizacyjna zachowują swoją spójną tożsamość niezależnie od zmian w systemach źródłowych. To tutaj rozwiązujemy problemy związane z różnymi identyfikatorami produktów, zmianami struktur organizacyjnych czy rozbieżnościami pomiędzy systemami źródłowymi.
Dzięki temu organizacja może opierać dalsze analizy na wspólnym i spójnym modelu danych.
Gold definiuje logikę biznesową
Kolejnym krokiem jest określenie ziarnistości danych, czyli tego, co właściwie reprezentuje pojedynczy rekord.
Sprzedaż, koszty, zlecenia produkcyjne i zdarzenia operacyjne często funkcjonują na różnych poziomach szczegółowości.
To właśnie tutaj powstają reguły pozwalające odpowiedzieć na pytania:
-
-
Jak przypisujemy koszty transportu do sprzedaży?
-
Jak rozliczamy koszty przezbrojeń?
-
Jakie koszty uwzględniamy w marży?
-
Jak obsługujemy wspólne pule kosztowe?
-
Koszt transportu rozliczany miesięcznie również wymaga jawnej reguły przypisania do sprzedaży. Bez niej różne raporty mogą pokazywać różne wyniki mimo wykorzystania tych samych danych źródłowych.
To ważne, ponieważ nawet poprawne dane źródłowe mogą prowadzić do błędnych wyników, jeśli zostaną połączone w niewłaściwy sposób. Przykładowo miesięczna pula kosztów połączona bezpośrednio z każdym zdarzeniem produkcyjnym może zwielokrotnić przypisane wartości, mimo że wszystkie dane źródłowe są poprawne.
Dlatego w modelu oddzielamy pule kosztowe od reguł alokacji i jasno określamy, według jakich zasad koszty są przypisywane do produktów, klientów czy zleceń.
Sama zgodność sum kontrolnych nie oznacza jeszcze poprawnego wyniku biznesowego. Możemy poprawnie rozliczyć całą pulę kosztów i jednocześnie przypisać część kosztów do niewłaściwych produktów, klientów lub zleceń. Dlatego reguły alokacji wymagają nie tylko kontroli technicznej, ale również biznesowej walidacji przez finanse i operacje. W praktyce każda taka reguła powinna mieć właściciela biznesowego, określony zakres zastosowania oraz jasno zdefiniowany sposób obsługi wyjątków.
Architektura powinna być powtarzalna, a logika biznesowa elastyczna
W DataRiseLab wykorzystujemy Cairn for Fabric jako zestaw wzorców i komponentów, które pomagają budować platformę danych w powtarzalny sposób. Framework zapewnia wspólny sposób organizacji warstw danych, integracji źródeł, kontroli jakości i procesów analitycznych
Specyficzna wiedza biznesowa pozostaje natomiast w regułach alokacji, słownikach pojęć, konfiguracjach modeli oraz kontraktach danych. Dzięki temu organizacja nie musi za każdym razem budować architektury od początku, a jednocześnie zachowuje pełną kontrolę nad własnymi definicjami biznesowymi.
Model semantyczny przechowuje definicję wyniku
Dopiero na tym etapie definiujemy miary wykorzystywane przez raporty biznesowe.
-
-
Marża
-
Rentowność
-
Koszt jednostkowy
-
Przychód
-
To właśnie model semantyczny Power BI staje się miejscem, w którym biznes otrzymuje uzgodnione definicje wykorzystywane we wszystkich raportach.
Dzięki temu kolejny dashboard nie oznacza tworzenia kolejnej wersji prawdy.
Co się dzieje, gdy zmienia się sposób liczenia marży?
Wyobraźmy sobie, że firma przejmuje nową spółkę. Pojawiają się nowe produkty. Finanse decydują o zmianie sposobu alokacji kosztów. Zmienia się definicja wyniku.
W wielu organizacjach taka zmiana jest praktycznie niewidoczna. Ktoś modyfikuje zapytanie SQL, poprawia formułę w Excelu albo aktualizuje raport. Po kilku miesiącach niewiele osób pamięta już, kiedy i dlaczego wprowadzono zmianę. A przecież definicja marży ma bezpośredni wpływ na decyzje biznesowe.
Dlatego warto traktować ją tak samo jak kod aplikacji. Model zapisany w TMDL pozwala przeglądać i wersjonować definicje miar wykorzystywanych przez Power BI. W praktyce wersjonowaniu podlega nie tylko model semantyczny. Zmianom podlegają również zapytania SQL, konfiguracje alokacji kosztów oraz mapowania wykorzystywane podczas transformacji danych. Każda zmiana wymaga również określenia, czy obowiązuje wyłącznie dla nowych okresów, czy powinna zostać zastosowana także do danych historycznych.
Dopiero połączenie tych elementów pozwala odtworzyć sposób obliczenia wyniku w konkretnym momencie czasu. Zmiana sposobu liczenia marży staje się zmianą, którą można wskazać, omówić, przetestować i w razie potrzeby odtworzyć. To oznacza większą przejrzystość i większe zaufanie do raportowanych wyników.
Prawdziwa wartość nie polega na budowie kolejnego raportu
Wiele projektów danych rozpoczyna się od pytania: Jakie raporty chcemy zobaczyć? Znacznie rzadziej pojawia się pytanie: Czy wszyscy rozumiemy wynik w taki sam sposób? A właśnie tutaj często znajduje się największe źródło problemów. Jeżeli każdy raport korzysta z innej definicji marży, organizacja będzie poświęcać czas na wyjaśnianie rozbieżności.
Jeżeli definicja jest wspólna, udokumentowana i możliwa do prześledzenia, rozmowa może szybciej przejść do tego, co naprawdę istotne – do decyzji.
To szczególnie istotne w środowiskach Microsoft Fabric, gdzie te same dane są wykorzystywane jednocześnie przez raporty Power BI, procesy analityczne i rozwiązania wykorzystujące sztuczną inteligencję.
AI może bardzo szybko wygenerować odpowiedź. Nadal jednak potrzebuje jednoznacznych definicji biznesowych, aby odpowiedź była poprawna.
Najważniejszy wniosek
Wiedza o tym, jak liczymy marżę, powinna należeć do organizacji. Nie do autora raportu. Nie do osoby, która napisała zapytanie SQL. Nie do pojedynczego eksperta, który pamięta, skąd wzięła się definicja wyniku.
Definicja wyniku powinna mieć właściciela, miejsce w architekturze danych oraz możliwość prześledzenia sposobu obliczeń. Dzięki temu kolejny raport korzysta z tej samej wiedzy, nowi pracownicy nie muszą odtwarzać historycznych ustaleń, a nowa analiza, nowy dashboard czy nowo dołączona spółka mogą korzystać z tej samej uzgodnionej definicji wyniku. Organizacja może szybciej przejść od tłumaczenia liczb do podejmowania decyzji.
Gdy wiedza o sposobie liczenia wyniku staje się częścią architektury danych, kolejny raport, nowa analiza czy nowo dołączona spółka korzystają z tej samej definicji. Dzięki temu rozmowa o rentowności może szybciej przejść od wyjaśnień do decyzji.