Mierniki KPI bez kłótni: jak zbudować słownik metryk i governance w Power BI (praktyczny proces)

1. Po co słownik metryk (KPI) i governance w Power BI: cele, zakres i typowe problemy

Power BI świetnie skaluje raportowanie, ale im szybciej rośnie liczba raportów, zespołów i źródeł danych, tym częściej pojawia się pytanie: „który wynik jest prawdziwy?”. Słownik metryk (KPI) i governance nie są dodatkiem „dla porządku” — to mechanizmy, które ograniczają spory, przyspieszają decyzje i pozwalają utrzymać spójność, gdy raportów jest dużo, a odbiorców jeszcze więcej.

Słownik metryk to wspólne, uzgodnione definicje KPI: co mierzymy, po co, jak interpretować wynik i jakie są kluczowe założenia. Governance to zasady i odpowiedzialności: kto może zmienić definicję, jak wygląda akceptacja, jak komunikujemy zmianę, jak pilnujemy jakości i spójności w Power BI. Razem odpowiadają na dwie różne potrzeby: „co znaczy KPI” oraz „jak zarządzamy KPI w czasie”.

Główne cele: mniej kłótni, więcej decyzji

• Jedno znaczenie dla jednego KPI — spójność definicji między raportami, zespołami i kanałami (Power BI, Excel, prezentacje).
• Porównywalność wyników — te same metryki liczone w ten sam sposób, z tym samym kontekstem interpretacji.
• Szybsze wdrażanie i utrzymanie raportów — mniej „ustaleń ad hoc”, mniej poprawek po publikacji, krótszy czas od potrzeby do gotowego dashboardu.
• Kontrola ryzyka — ograniczenie sytuacji, w których decyzje biznesowe zapadają na bazie niejednoznacznych lub błędnie policzonych wskaźników.
• Wspólny język między biznesem a BI/IT — metryki opisane tak, by były zrozumiałe i weryfikowalne z obu perspektyw.

Zakres: co obejmuje słownik metryk i governance (a czego nie)

W praktyce słownik metryk obejmuje nie tylko „listę KPI”, ale również minimalny kontekst, który zapobiega błędnym porównaniom i interpretacjom. Governance z kolei obejmuje zasady pracy z metrykami w cyklu życia raportowania.

• Zakres słownika metryk: nazwa i cel KPI, opis biznesowy, podstawowe założenia i ograniczenia, zasady interpretacji wyniku, powiązania z procesami i obszarami (np. sprzedaż, finanse, operacje).
• Zakres governance: odpowiedzialności, reguły zmian i akceptacji, minimalne standardy jakości, sposób komunikacji zmian do użytkowników, uporządkowanie „źródła prawdy” w Power BI.
• Poza zakresem (typowo): pełna architektura danych całej organizacji, szczegółowe standardy modelowania i implementacji DAX, czy projektowanie wszystkich layoutów raportów — te elementy mogą być powiązane, ale nie są celem samym w sobie w tej sekcji.

Najczęstsze problemy, które słownik KPI i governance rozwiązują

• „Mamy dwa wyniki tej samej sprzedaży” — różne raporty liczą podobnie brzmiący KPI inaczej (inne filtry, inne źródła, inne założenia).
• Metryki bez właściciela — nikt nie czuje się odpowiedzialny za definicję, więc decyzje zapadają na bazie najgłośniejszej opinii albo „bo zawsze tak było”.
• Niejasny kontekst — KPI wygląda prosto, ale wynik zależy od tego, czy mówimy o dacie zamówienia czy wysyłki, o brutto czy netto, o aktywnych klientach czy wszystkich historycznych.
• Zmiany „po cichu” — definicja KPI zmienia się w datasetcie lub raporcie bez informacji do użytkowników; zaufanie do raportów spada.
• Różne poziomy szczegółowości — ktoś porównuje KPI z widoku dziennego do miesięcznego albo miesza poziom transakcji z agregatem, uzyskując sprzeczne wnioski.
• „Eksport do Excela” jako obejście — użytkownicy, nie ufając metrykom w raporcie, budują własne obliczenia poza kontrolą, mnożąc wersje prawdy.
• Przeciążenie KPI — zbyt wiele wskaźników bez priorytetów powoduje, że raporty nie wspierają decyzji, tylko generują dyskusje o liczbach.

Dlaczego w Power BI temat wraca szczególnie często

Power BI ułatwia szybkie tworzenie raportów i miar, co jest zaletą — ale bez uzgodnionych definicji i zasad zarządzania prowadzi do rozproszenia logiki obliczeń i duplikacji KPI. Gdy wiele zespołów równolegle tworzy podobne metryki, różnice pojawiają się naturalnie: w filtrach, w interpretacji, w doborze źródeł i w momentach „zamknięcia” danych. Słownik i governance nie ograniczają elastyczności Power BI — porządkują ją tak, aby szybkie dostarczanie raportów nie odbywało się kosztem spójności.

Efekt docelowy: wspólne KPI jako produkt, nie jako jednorazowe obliczenie

Najważniejsza zmiana mentalna polega na tym, że KPI przestaje być „miarą w raporcie”, a staje się zarządzanym elementem biznesowym: ma znaczenie, właściciela, uzgodnione reguły i kontrolowany sposób wprowadzania zmian. Dzięki temu rozmowy przesuwają się z „kto ma rację w liczbach” na „co wynika z liczb i jaką decyzję podejmujemy”.

2. Proces budowy słownika metryk: przygotowanie i warsztaty definicyjne (od potrzeb do backlogu KPI)

Słownik metryk nie zaczyna się od DAX-a ani od „listy KPI z prezentacji”. Zaczyna się od uporządkowania potrzeb decyzyjnych i dopiero potem przekłada je na spójny zestaw definicji. Najważniejsze w tym procesie jest rozdzielenie dwóch rzeczy: co organizacja chce mierzyć i dlaczego oraz jak będzie to liczone i dostarczone w Power BI. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj. W tej sekcji skupiamy się na praktycznym przebiegu prac od przygotowania do powstania backlogu KPI, bez wchodzenia w szczegóły ról, definicji technicznych czy kontroli zmian.

2.1. Przygotowanie: zanim zbierzesz ludzi na warsztat

Warsztaty definicyjne działają tylko wtedy, gdy uczestnicy mają wspólny kontekst i jasne granice. Przygotowanie ma więc dwa cele: ograniczyć chaos oraz wyłapać różnice w rozumieniu pojęć, zanim trafią na salę.

• Ustal zakres: jaki obszar biznesowy, jaki proces (np. sprzedaż, logistyka, obsługa klienta), jaki horyzont czasu i jaki poziom szczegółowości (zarządczy vs operacyjny). Zakres powinien być na tyle wąski, by domknąć pierwszą wersję słownika, ale na tyle ważny, by dawał realną wartość.
• Zbierz „źródła prawdy” i istniejące definicje: obecne raporty, arkusze z KPI, prezentacje, opisy w intranecie, definicje w systemach. Celem nie jest ich bezkrytyczne skopiowanie, tylko identyfikacja rozjazdów: te same nazwy liczone inaczej albo różne nazwy na to samo.
• Wypisz decyzje i pytania, które KPI mają wspierać: „kiedy reagujemy?”, „co uznajemy za sukces?”, „jak rozpoznajemy problem?”. To pozwala uniknąć metryk, które są łatwe do policzenia, ale nieużyteczne.
• Wstępnie sklasyfikuj kandydatów na KPI: rozróżnij metryki wynikowe (outcome) od sterujących (driver) oraz globalne od lokalnych. To nie jest jeszcze definicja, tylko porządkowanie dyskusji.
• Zidentyfikuj ograniczenia danych: gdzie dane są dostępne, gdzie są opóźnienia, jak wygląda kompletność i czy istnieją różnice definicyjne między systemami. Na tym etapie chodzi o świadomość ryzyk, nie o projekt techniczny.
• Dobierz uczestników: potrzebujesz osób, które rozumieją proces i jego wyjątki (biznes), oraz tych, które rozumieją dane na poziomie „skąd to się bierze” (data/BI). Bez tej mieszanki warsztat kończy się deklaracjami bez pokrycia albo technicznymi kompromisami bez akceptacji biznesu.

2.2. Warsztaty definicyjne: od potrzeb do wspólnego języka

Główny rezultat warsztatów to uzgodnione kandydatury KPI wraz z wstępną definicją biznesową i listą otwartych punktów. Nie próbuj na pierwszym spotkaniu dopiąć wszystkiego „na gotowo”. Lepiej wyjść z jasnym backlogiem niż z pozorną zgodą, która rozpadnie się przy wdrożeniu.

• Krok 1: mapowanie pytań decyzyjnych – zaczynasz od tego, jakie decyzje są podejmowane cyklicznie i ad hoc, jakie sygnały uruchamiają działania oraz jak mierzy się efekty. To naturalnie wyciąga potrzebne metryki i ich kontekst.
• Krok 2: inwentaryzacja KPI i „rozjazdów” – zestawiasz istniejące metryki, wykrywasz duplikaty, synonimy i różnice znaczeniowe. Na tym etapie warto wymusić proste pytanie: „czy dwie osoby, patrząc na ten sam raport, podejmą tę samą decyzję?”. Jeśli nie, metryka wymaga doprecyzowania.
• Krok 3: doprecyzowanie intencji metryki – dla każdego KPI uzgadniasz, co ma reprezentować (np. efektywność, jakość, wolumen), czy jest miarą celu czy diagnostyczną oraz czy jest „oficjalna” (porównywana między zespołami), czy lokalna (do zarządzania wewnątrz zespołu).
• Krok 4: ustalenie podstawowych wymiarów interpretacji – nie wchodząc w technikalia, ustalasz „oś podziału” wyników: na jakich poziomach analizujemy (czas, produkt, klient, region, kanał), jakie są minimalne przekroje i co jest ważne w porównaniach (np. rok do roku, plan vs wykonanie).
• Krok 5: identyfikacja wyjątków i sytuacji granicznych – tu zwykle rodzą się spory. Spisujesz typowe wyjątki (anulacje, zwroty, korekty, duplikaty, zmiany statusów) oraz ustalasz, które z nich mają wpływać na KPI. Jeśli nie da się rozstrzygnąć od razu, zapisujesz to jako punkt do decyzji, zamiast „zamieść pod dywan”.
• Krok 6: priorytetyzacja – wyłaniasz minimalny zestaw KPI do pierwszej iteracji i odkładasz resztę do backlogu. Priorytet nie powinien wynikać z głośności interesariusza, tylko z wartości decyzyjnej i częstości użycia.

2.3. Artefakty po warsztacie: co ma powstać, żeby praca nie zniknęła

Najczęstsza porażka to sytuacja, gdy po warsztacie zostają tylko notatki i „poczucie uzgodnienia”. Żeby słownik metryk był wykonalny i odporny na interpretacje, warsztat powinien zakończyć się zestawem uporządkowanych wyników.

• Lista kandydatów na KPI z jednoznacznymi nazwami roboczymi oraz opisem, do jakiej decyzji służą.
• Wstępne definicje biznesowe – krótkie, ludzkie opisy tego, co metryka oznacza i kiedy jest „dobra/zła”. Bez wzorów i implementacji, ale z jasnym sensem.
• Kontekst użycia – kto korzysta, jak często, na jakim poziomie szczegółowości, jakie podstawowe przekroje są kluczowe.
• Lista otwartych pytań i ryzyk danych – brakujące pola, niespójne statusy, niejednoznaczne definicje w systemach, znane ograniczenia jakości.
• Proponowany zakres pierwszej iteracji – co robimy teraz, co później oraz co jest poza zakresem (żeby nie rozszerzać projektu w nieskończoność).

2.4. Od listy do backlogu KPI: jak ustawić pracę na iteracje

Backlog KPI to most między językiem biznesu a pracą analityczno-wdrożeniową. Nie jest jeszcze słownikiem w pełnym sensie, ale jest listą elementów, które można planować, estymować i dowozić krokami.

• Rozbij metryki na „pakiety”: zamiast wrzucać wszystko do jednego worka, grupuj KPI według obszaru procesu lub wspólnych zależności danych. To ogranicza ryzyko, że jedna brakująca tabela blokuje cały słownik.
• Zdefiniuj kryteria gotowości (DoR) dla KPI w backlogu: co musi być doprecyzowane, żeby metryka weszła do realizacji (np. uzgodniona intencja, właściciel po stronie biznesu, znane źródło danych albo decyzja, że metryka jest „tymczasowa”).
• Zdefiniuj kryteria akceptacji (DoD) na poziomie biznesowym: po czym użytkownicy poznają, że KPI jest „gotowy do użycia” (np. zgodność z oczekiwaniami na danych przykładowych, komplet przekrojów, opis). Szczegóły testów i ścieżek akceptacji będą rozwijane dalej, ale już tu warto zaznaczyć, że „gotowe” to nie tylko „policzone”.
• Ustal priorytety wprost: rankingi KPI powinny uwzględniać wartość decyzji, ryzyko interpretacyjne i trudność danych. Metryki kontrowersyjne często warto zrobić wcześniej, bo najwięcej uczą o definicjach i danych.
• Zaplanuj iteracyjność: pierwsza wersja słownika może być niepełna, ale musi być spójna. Lepiej dowieźć mniejszy, uzgodniony zestaw metryk niż obszerną listę, której nikt nie ufa.

2.5. Typowe pułapki w procesie i jak je neutralizować

• „Zróbmy wszystkie KPI naraz” – kończy się przeciążeniem i brakiem domknięcia. Odpowiedź: iteracje i wyraźny zakres pierwszego wydania.
• KPI jako kompromis polityczny – metryka staje się „bezpieczna”, czyli nic nie mówi. Odpowiedź: wracaj do pytań decyzyjnych i scenariuszy użycia.
• Nazwa zamiast definicji – wszyscy znają skrót, ale każdy rozumie go inaczej. Odpowiedź: każdą metrykę zmuszaj do prostego opisu „co to znaczy” oraz „co jest w środku, a co poza”.
• Ignorowanie wyjątków – spór wybucha dopiero po publikacji raportu. Odpowiedź: lista sytuacji granicznych jako obowiązkowy element warsztatu.
• Brak decyzji o priorytetach – zespół BI zaczyna realizować to, co akurat najłatwiejsze. Odpowiedź: jawny backlog z kolejnością i uzasadnieniem.

Dobrze przeprowadzony proces przygotowania i warsztatów sprawia, że słownik metryk przestaje być „dokumentem do podpisu”, a staje się praktycznym narzędziem: zrozumiałym dla biznesu, wykonalnym dla zespołu danych i gotowym do iteracyjnego dowożenia w Power BI.

3. Role i odpowiedzialności: właściciele metryk, Data/BI governance oraz RACI dla cyklu życia KPI

Najwięcej „kłótni o KPI” nie bierze się z DAX-a, tylko z braku jasności: kto definiuje sens metryki, kto odpowiada za obliczenia, kto zatwierdza zmiany i kto komunikuje je użytkownikom. W Power BI (gdzie jedna miara potrafi zasilać dziesiątki raportów) nieustalone role prowadzą do równoległych definicji, niespójnych wyników i przerzucania odpowiedzialności między biznesem a IT.

Kluczowe role w ekosystemie KPI

Poniżej zestaw ról, które najczęściej trzeba nazwać (nawet jeśli jedna osoba pełni kilka funkcji). Cel: rozdzielić odpowiedzialność za znaczenie od odpowiedzialności za implementację oraz ustanowić ścieżkę decyzyjną.

Właściciel metryki: co to znaczy w praktyce

Właściciel metryki to nie „osoba od Power BI”. To osoba (lub funkcja), która ma mandat, by powiedzieć: co mierzymy i jak ten wynik ma być interpretowany. Najczęściej jest to właściciel procesu, osoba odpowiedzialna za wynik biznesowy albo lider obszaru, który KPI opisuje.

• Odpowiada za sens i użycie KPI (np. do jakich decyzji służy, jakie są ograniczenia).
• Zatwierdza zmiany definicji oraz rozstrzyga spory interpretacyjne.
• Ustala priorytety korekt (np. czy ważniejsze jest doprecyzowanie definicji, czy szybkie „łatanie” raportu).

To rozdzielenie jest kluczowe: BI implementuje, ale biznes jest właścicielem znaczenia. Bez tego metryka staje się „czyjaś”, a nie „organizacyjna”.

Data governance vs BI governance: podobne, ale nie to samo

W praktyce potrzebujesz dwóch uzupełniających się perspektyw zarządczych:

W kontekście KPI te dwa światy spotykają się w jednym miejscu: metryka opiera się o dane, ale żyje w BI. Dlatego governance powinno jasno wskazać, kto jest „ostatnią instancją” dla sporów o dane, a kto dla sporów o interpretację i prezentację.

RACI dla cyklu życia KPI (minimalny szkielet)

RACI pomaga uciąć dyskusje typu „myślałem, że to oni”. Poniżej przykładowy, bazowy podział odpowiedzialności dla typowych etapów KPI. Warto go potraktować jako punkt startowy i dopasować do skali organizacji.

Legenda: R – Responsible (wykonuje), A – Accountable (odpowiada końcowo), C – Consulted (konsultuje), I – Informed (informowany).

Najważniejsze zasady, które warto przyjąć od razu

• Jeden KPI = jeden właściciel (A po stronie biznesu). Jeśli jest „wspólny”, wyznacz jednego decydenta i resztę jako C.
• Źródło prawdy ma właściciela: spór o to, co oznacza pole w danych, rozstrzyga Data Owner (A), nie zespół raportowy.
• BI nie „wymyśla” definicji: BI może zaproponować sposób policzenia, ale nie zatwierdza znaczenia.
• Administrator platformy nie jest właścicielem KPI: odpowiada za ramy (bezpieczeństwo/standardy), nie za treść metryk.
• Konsultacje nie mogą blokować decyzji: rola C dostarcza input, ale decyzja należy do A.

Tak ułożone role i RACI upraszczają codzienną pracę: spory trafiają do właściwej osoby, zmiany mają właściciela, a Power BI przestaje być miejscem „alternatywnych wersji prawdy” i staje się kontrolowanym kanałem dystrybucji KPI.

4. Definicje metryk: biznesowa vs techniczna, reguły obliczeń, kontekst filtrów i interpretacja

Najwięcej sporów o KPI w Power BI nie bierze się z DAX, tylko z nieprecyzyjnej definicji. Ta sama nazwa („Marża”, „Aktywni klienci”, „Sprzedaż”) bywa rozumiana inaczej przez działy, a różnice wychodzą dopiero przy porównaniu raportów. Dlatego każda metryka w słowniku powinna mieć dwa komplementarne opisy: biznesowy (co mierzymy i po co) oraz techniczny (jak dokładnie to liczymy i w jakim kontekście).

W czasie szkoleń Cognity ten temat bardzo często budzi ożywione dyskusje między uczestnikami – zwykle dlatego, że wszyscy używają tych samych słów, ale nie mają uzgodnionych reguł i kontekstu, w jakim KPI ma być liczone.

Biznesowa definicja metryki (język użytkownika)

Definicja biznesowa ma umożliwić użytkownikowi poprawną interpretację liczby bez zaglądania do modelu. Powinna być krótka, jednoznaczna i powiązana z decyzją, którą wspiera.

• Nazwa i cel: co metryka reprezentuje i do czego służy.
• Zakres: czego metryka dotyczy (proces, obszar, linia biznesowa) i czego nie dotyczy.
• Jednostka: PLN, szt., %, dni, liczba klientów; oraz oczekiwany kierunek („im wyżej tym lepiej”).
• Grain (poziom szczegółowości): na jakim poziomie logicznie istnieje (np. transakcja, zamówienie, klient, produkt).
• Warianty nazewnicze: dopuszczalne synonimy i skróty, by uniknąć dublowania.

Techniczna definicja metryki (język modelu danych)

Definicja techniczna ma zapewnić powtarzalność obliczeń w każdym raporcie. Odpowiada na pytanie: „Jak system ma to policzyć w Power BI?”.

• Źródła danych: tabela/tabele faktów, wymiary, ewentualne mapowania i zależności.
• Logika obliczeń: wzór, agregacje (SUM, DISTINCTCOUNT, AVG), warunki włączeń/wyłączeń.
• Obsługa braków i wyjątków: wartości puste, zera, rekordy anulowane, korekty.
• Format i typ danych: liczba całkowita, dziesiętna, procent; reguły zaokrągleń.
• Wydajność i preferowany wzorzec: wskazanie, czy liczymy z miary, kolumny, czy wymagany jest kontekst daty itp. (bez wchodzenia w implementacyjne detale).

Porównanie: definicja biznesowa vs techniczna

Reguły obliczeń: co musi być dopowiedziane

W słowniku metryk kluczowe są nie tylko „wzory”, ale reguły włączeń i wyłączeń. To one najczęściej powodują rozjazdy między raportami.

• Co liczymy: np. „sprzedaż” jako kwota netto/brutto; „zamówienia” jako liczba dokumentów czy pozycji.
• Jak agregujemy: suma, średnia, mediana, unikalne zliczenie; i na jakim poziomie (np. DISTINCTCOUNT klientów vs COUNT transakcji).
• Jak traktujemy statusy: anulowane, zwrócone, w realizacji; czy i kiedy wchodzą do KPI.
• Okres i data odniesienia: data faktury vs data zamówienia vs data wysyłki; zasada „która data steruje KPI”.
• Waluta i przeliczenia: kurs dnia, kurs miesiąca, waluta raportowania; czy KPI jest „w walucie transakcji” czy ujednolicony.
• Zaokrąglenia: na końcu czy w trakcie; liczba miejsc; spójność z finansami.

Kontekst filtrów w Power BI: dlaczego ta sama miara daje różne wyniki

W Power BI wynik miary zależy od kontekstu filtrów (selekcje w raporcie, wiersze/kolumny wizualizacji, relacje w modelu). Dlatego definicja metryki powinna jasno mówić, jakie filtry mają wpływ, a jakie powinny być ignorowane.

• Domyślny zakres: czy metryka jest liczona „dla aktualnie wybranego okresu”, czy ma zawsze domyślny horyzont (np. MTD/QTD/YTD).
• Wymiary, które filtrują: np. produkt, region, kanał; i czy filtr działa przez relacje czy wymaga mapowania.
• Wymiary, które nie powinny filtrować: typowy przykład to KPI „globalny” (benchmark), który ma być stały mimo filtrowania raportu.
• Data: czy miara ma reagować na wybór daty z kalendarza, oraz czy ma używać jednej czy wielu osi czasu (np. data transakcji vs data księgowania).

Minimalnym standardem jest dopisanie do metryki sekcji „Reaguje na filtry” oraz „Ignoruje filtry”. To często wystarcza, by uniknąć dyskusji typu: „u mnie jest inaczej, bo kliknąłem segment”.

Interpretacja i prezentacja: jak czytać KPI, żeby nie wprowadzał w błąd

Dobrze zdefiniowana metryka zawiera krótką instrukcję interpretacji: co oznacza wartość, kiedy jest porównywalna i jakie są typowe pułapki.

• Znaczenie wartości 0 i braku danych: „0” jako realny wynik vs brak rejestracji danych (BLANK).
• Porównania: z czym porównujemy (poprzedni okres, plan, średnia), oraz czy porównanie jest sensowne przy zmianie zakresu filtrów.
• Wrażliwość na sezonowość i strukturę: np. średnie vs sumy; wpływ miksu produktowego na marżę.
• Rekomendowana wizualizacja: liczba KPI, trend, udział procentowy; aby nie sugerować fałszywej precyzji.

Przykładowy zapis w słowniku: „Aktywni klienci”

Poniżej przykład, jak połączyć opis biznesowy z technicznym w jednej, czytelnej definicji (bez pełnej implementacji).

• Nazwa biznesowa: Aktywni klienci
• Opis biznesowy: liczba unikalnych klientów, którzy dokonali co najmniej jednej transakcji w wybranym okresie.
• Jednostka: liczba klientów (unikalnych)
• Reguły: transakcje anulowane nie wchodzą; zwroty nie liczą się jako aktywność (o ile nie ma sprzedaży).
• Data odniesienia: data transakcji
• Reaguje na filtry: okres (kalendarz), region, kanał, produkt
• Ignoruje filtry: (jeśli dotyczy) np. wybór sprzedawcy, jeśli sprzedaż jest przypisana do zespołów w innym wymiarze
• Definicja techniczna (skrót): DISTINCTCOUNT klucza klienta na faktach transakcji po odfiltrowaniu statusów wykluczonych.

// Uzupełniająco (fragment poglądowy)
Aktywni klienci =
CALCULATE(
    DISTINCTCOUNT('FaktTransakcje'[CustomerKey]),
    'FaktTransakcje'[Status] <> "Anulowana"
)

Najważniejsze: w słowniku ma być jasne co to znaczy „aktywny”, które statusy się liczą i jaka data steruje okresem. Sam zapis DAX bez tych ustaleń zwykle nie kończy dyskusji.

5. Zarządzanie zmianą: wersjonowanie, workflow akceptacji, testy regresji i ścieżka audytu

Słownik metryk i governance mają sens tylko wtedy, gdy zmiany w KPI są kontrolowane: wiadomo kto zmienił definicję, dlaczego, od kiedy obowiązuje oraz jaki ma to wpływ na wyniki i raporty. Bez tego nawet dobrze zdefiniowane KPI szybko zaczynają „żyć własnym życiem” (różne wersje tej samej miary, niespójne liczby w raportach, spory o interpretację).

5.1. Co traktować jako „zmianę” KPI

Nie każda modyfikacja wymaga takiego samego procesu. Kluczowe jest rozróżnienie zmian, które wpływają na interpretację wyniku, od tych czysto porządkowych.

• Zmiana definicji biznesowej (np. co liczymy jako „aktywny klient”) – najwyższy wpływ, zwykle wymaga komunikacji do użytkowników.
• Zmiana logiki obliczeń (np. inny warunek filtrujący, inna agregacja) – wpływ na wartości i porównywalność w czasie.
• Zmiana źródła danych (np. inne pole, inna tabela, nowy pipeline) – ryzyko różnic i problemów jakościowych.
• Zmiana prezentacji (format, jednostka, opis) – mniejszy wpływ, ale nadal powinna być śledzona.
• Refaktor techniczny (optymalizacja, zmiana nazewnictwa w modelu) – zazwyczaj bez zmiany wyniku, ale wymaga sprawdzenia zależności.

5.2. Wersjonowanie: jak utrzymać porządek bez biurokracji

Wersjonowanie KPI to praktyka nadawania zmianom numeru/oznaczenia oraz rejestrowania ich w sposób pozwalający odtworzyć stan definicji na dowolny moment. W praktyce najczęściej wystarcza prosty schemat:

• Major – zmiana znaczenia KPI lub sposobu liczenia wpływająca na porównywalność historyczną.
• Minor – rozszerzenie lub doprecyzowanie bez zmiany znaczenia (np. opis, nowy wariant filtra jako osobna miara).
• Patch – poprawka techniczna bez zmiany wyniku (np. optymalizacja DAX, poprawa nazwy).

Kluczowe artefakty wersjonowania:

• Historia zmian przy KPI: co zmieniono, powód, data wejścia w życie, osoba odpowiedzialna.
• Status obowiązywania: np. „Aktywny”, „Wycofany”, „Zastąpiony przez …”.
• Reguła porównywalności: informacja, czy wyniki przed/po zmianie są porównywalne (tak/nie/warunkowo).

5.3. Workflow akceptacji: minimum kontroli, maksimum przewidywalności

Workflow akceptacji ma ograniczyć sytuacje, w których KPI zmienia się „po cichu” i zaskakuje użytkowników. Dobrą praktyką jest prosty przepływ od wniosku do publikacji:

• Wniosek o zmianę (kto zgłasza, co i dlaczego; oczekiwany efekt).
• Ocena wpływu (na raporty, model, inne miary, porównywalność trendów).
• Akceptacja biznesowa (czy zmiana ma sens merytoryczny i jest zgodna z definicjami).
• Akceptacja techniczna (czy implementacja jest poprawna, wydajna i bezpieczna dla modelu).
• Publikacja (wdrożenie + aktualizacja dokumentacji + komunikacja).

Warto rozdzielić dwa typy wdrożeń:

• Standardowe – w zaplanowanym cyklu, z pełnym testem i komunikacją.
• Pilne – szybka poprawka (np. błąd logiczny), ale nadal z rejestracją w historii i retrospektywną akceptacją.

5.4. Testy regresji: czy KPI nadal liczy się tak, jak powinien

Testy regresji w KPI to szybkie sprawdzenie, czy po zmianie (lub po aktualizacji danych/modelu) metryki:

• zwracają oczekiwane wartości na znanych próbkach,
• nie zmieniają się tam, gdzie nie powinny (np. przy refaktorze),
• nie psują innych miar zależnych i wizualizacji.

W praktyce najczęściej stosuje się kombinację:

• Testów punktowych – kilka ustalonych „scenariuszy” (np. wybrany miesiąc/region) z oczekiwanym wynikiem.
• Testów tolerancji – dopuszczalna różnica (np. ±0,1%) gdy dane źródłowe mogą się minimalnie zmieniać.
• Testów zależności – sprawdzenie kluczowych raportów/stron, które używają KPI.

Przykładowy (minimalny) zapis scenariusza testowego dla KPI może wyglądać jak „dane wejściowe → kontekst filtrów → oczekiwany wynik”. Jako uzupełnienie można utrzymywać techniczny test w formie zapytania kontrolnego, np. zwracającego wartości KPI dla kilku kontrolnych przekrojów.

// Pseudotest: zwróć KPI dla kontrolnych przekrojów
EVALUATE
SUMMARIZECOLUMNS(
  'Calendar'[YearMonth],
  "KPI_Value", [Twoja_Miara_KPI]
)

5.5. Ścieżka audytu: kto, kiedy i na jakiej podstawie

Ścieżka audytu to możliwość odtworzenia historii decyzji i wdrożeń. Jest niezbędna, gdy KPI wspiera decyzje finansowe, operacyjne lub jest raportowany cyklicznie. Dobrze zaprojektowana ścieżka audytu odpowiada na pytania:

• Kto zatwierdził zmianę i kto ją wdrożył?
• Co dokładnie zmieniono (definicja, logika, źródło, opis)?
• Kiedy zmiana weszła w życie (data publikacji i zakres danych, którego dotyczy)?
• Dlaczego zmiana była konieczna (uzasadnienie biznesowe/techniczne)?
• Jaki miała wpływ (np. informacja o nieporównywalności trendów, lista raportów do weryfikacji)?

Minimalny standard audytu to rejestr zmian KPI (np. w backlogu/issue trackerze) powiązany z wersją definicji. Im bardziej krytyczne KPI, tym większy sens ma formalne potwierdzenie akceptacji oraz przechowywanie wyników testów regresji jako dowodu kontroli jakości.

5.6. Zasady komunikacji zmian (żeby nie było „kłótni o liczby”)

Zarządzanie zmianą kończy się dopiero wtedy, gdy użytkownicy rozumieją, co się zmieniło. Wystarczą proste zasady:

• Widoczna notatka o zmianie przy KPI: od kiedy obowiązuje i czy wpływa na porównania historyczne.
• Jedno źródło prawdy dla aktualnej wersji definicji (bez równoległych opisów w wielu miejscach).
• Jasny komunikat „co robić”: czy należy zaktualizować interpretację, cele/targety, porównania miesiąc do miesiąca itp.

6. Dokumentacja i implementacja w Power BI: model semantyczny, miary DAX, opisy, metadane, lineage

Słownik metryk staje się użyteczny dopiero wtedy, gdy jest spójnie osadzony w modelu semantycznym i da się go łatwo odczytać: w miarach DAX, opisach, metadanych i powiązaniach (lineage). Celem tej sekcji jest pokazanie jak przełożyć definicje KPI na artefakty Power BI tak, aby użytkownik nie musiał „domyślać się” znaczenia liczb, a zespół mógł je utrzymać i audytować w codziennej pracy.

Model semantyczny jako „źródło prawdy” dla KPI

W praktyce to nie raport jest miejscem, gdzie „mieszka” definicja KPI, tylko dataset / model semantyczny. Raport jedynie prezentuje metryki, a model zapewnia ich jednolite obliczanie w wielu raportach.

• Miary (measures) są podstawową implementacją KPI — centralnie zarządzane, ponownie używalne.
• Model gwiazdy (fakty + wymiary) ułatwia jednoznaczne filtrowanie i interpretację wyników metryk.
• Jedno miejsce definicji: unikanie duplikowania logiki w wizualach, kalkulowanych kolumnach „na szybko” i w wielu plikach PBIX.

Miary DAX: implementacja definicji bez „kreatywnej” interpretacji

Miara DAX powinna możliwie wiernie odzwierciedlać definicję KPI ze słownika: co liczymy, na jakich danych i w jakim kontekście filtrów. Na tym etapie kluczowe jest, aby logika była:

• jednoznaczna (bez ukrytych założeń typu „domyślnie ostatni miesiąc”),
• czytelna (nazewnictwo, struktura miar bazowych vs pochodnych),
• porównywalna (te same definicje w różnych raportach dają te same wyniki).

Minimalny wzorzec, który pomaga w utrzymaniu, to rozdzielenie miar bazowych i złożonych:

-- Miara bazowa
[Przychód] = SUM ( 'FaktSprzedaż'[Kwota] )

-- KPI jako miara złożona
[Marża %] = DIVIDE ( [Marża], [Przychód] )

To nie jest „szablon na wszystko”, ale pokazuje kierunek: KPI budowane z mniejszych, testowalnych elementów są łatwiejsze do opisu i weryfikacji.

Opisy i właściwości obiektów: dokumentacja „wbudowana”

Power BI pozwala dokumentować metryki bezpośrednio tam, gdzie są używane — w modelu. Zamiast osobnych plików i notatek warto utrzymywać opisy (description) i podstawowe właściwości obiektów.

• Opis miary: definicja biznesowa w 2–4 zdaniach + kluczowe warunki (np. wykluczenia, waluta, zasady zaokrąglania).
• Format: spójne formatowanie (%, waluta, liczba miejsc) jako część kontraktu KPI.
• Jednostka i semantyka: nazwa miary powinna komunikować, czy to jest wartość, % czy wskaźnik (np. „… %”, „… na klienta”).

Dzięki temu użytkownik widzi kontekst metryki w panelu pól i tooltipach, a zespół nie musi „tłumaczyć ustnie” znaczenia każdej liczby.

Metadane i słownik w praktyce: jak powiązać KPI z katalogiem

Słownik metryk zwykle żyje w narzędziu do dokumentacji (repozytorium, wiki, katalog danych). W Power BI warto zapewnić most między miarą a wpisem w słowniku, aby dało się szybko przejść od liczby do definicji.

Najczęstsze, lekkie w utrzymaniu podejścia:

• Konwencja nazewnicza: stały prefiks/sufiks lub identyfikator KPI w nazwie miary albo w opisie (np. „KPI-023”).
• Opis z linkiem: URL do wpisu w słowniku w polu opisu miary (jeśli organizacja dopuszcza linkowanie).
• Tabela „KPI Dictionary” w modelu: techniczna tabela metadanych (ID, nazwa, definicja skrócona) używana jako referencja w raportach dokumentacyjnych.

Nie chodzi o budowanie „drugiego katalogu” w Power BI, tylko o to, by użytkownik i analityk mieli krótką ścieżkę do definicji.

Lineage: skąd się bierze liczba i gdzie jest używana

Wdrożenie KPI bez przejrzystego pochodzenia prowadzi do sporów typu „u mnie jest inaczej”. Dlatego warto wykorzystywać możliwości Power BI do śledzenia zależności:

• Lineage w workspace: widoczność relacji między źródłami, datasetami i raportami (co korzysta z czego).
• Jednoznaczne zależności miar: KPI jako miary, nie jako logika rozproszona po raportach — ułatwia wykrycie wpływu zmiany.
• Opis zależności: wskazanie w dokumentacji, które tabele/kolumny są krytyczne dla KPI (na poziomie „co”, nie „jak”).

Minimalny standard implementacyjny (do przyjęcia jako „Definition of Done”)

Żeby słownik KPI nie był tylko deklaracją, przydaje się prosty, powtarzalny standard publikacji metryki w Power BI:

Taki zestaw nie rozwiązuje wszystkich problemów governance, ale zapewnia fundament: metryka jest policzona raz, opisana raz i używana wielokrotnie — a spory o KPI zamieniają się w sprawdzalne pytania o definicję, kontekst i zależności.

7. Udostępnianie i kontrola jakości: certyfikacja/promowanie datasetów, standardy raportów i komunikacja do użytkowników

Nawet najlepsze definicje KPI nie ograniczą „kłótni o liczby”, jeśli użytkownicy nie wiedzą którym danym ufać, gdzie ich szukać i jak je interpretować. Dlatego governance w Power BI powinno kończyć się praktyką operacyjną: jasnym sposobem udostępniania zatwierdzonych źródeł, kontrolą jakości publikowanych artefaktów oraz konsekwentną komunikacją do odbiorców.

Certyfikacja i promowanie datasetów: po co i kiedy

W ekosystemie Power BI często współistnieją: oficjalne modele semantyczne, lokalne kopie danych oraz „szybkie” datasety powstałe pod konkretny raport. Bez prostego sygnału wiarygodności użytkownicy wybierają najszybciej dostępne źródło, a nie to właściwe. Mechanizmy promowania i certyfikacji pozwalają zbudować czytelną hierarchię zaufania.

• Promowane – dobre jako etap przejściowy: dataset jest wartościowy i rekomendowany do użycia, ale może jeszcze nie spełniać wszystkich rygorów formalnych (np. pełnej walidacji lub pełnego pokrycia definicji). Pomaga porządkować „co jest preferowane”, zanim organizacja dojrzeje do pełnej certyfikacji.
• Certyfikowane – stosuj dla źródeł „jednej wersji prawdy” dla KPI i kluczowych wymiarów. To sygnał, że dataset przeszedł uzgodnione kontrole (jakości, zgodności definicji, bezpieczeństwa) i ma właściciela, który odpowiada za utrzymanie.

Kluczowe jest, by te etykiety nie były „naklejkami marketingowymi”, tylko wynikały z procesu i kryteriów jakości. W przeciwnym razie szybko tracą znaczenie i wracają spory o to, co jest oficjalne.

Higiena publikacji: gdzie udostępniać i jak ograniczać chaos

Kontrola jakości zaczyna się od prostego porządku w publikacji: użytkownik ma łatwo znaleźć właściwy artefakt i zrozumieć, do czego służy. W praktyce pomaga rozdzielenie obszarów na: środowiska do pracy i eksperymentów oraz przestrzenie do konsumpcji biznesowej.

• Minimalizuj liczbę „oficjalnych” datasetów – lepiej mieć mniej, ale dobrze utrzymanych, niż wiele częściowo pokrywających się modeli.
• Stawiaj na współdzielenie przez dataset zamiast kopiowania danych do każdego raportu – zmniejsza to ryzyko rozjazdów definicji KPI.
• Ustal zasady nazewnictwa i opisu (dataset, raport, aplikacja) tak, aby już po tytule i krótkim opisie było wiadomo: zakres, właściciel, status i przeznaczenie.
• Kontroluj uprawnienia tak, by użytkownicy mogli korzystać z zatwierdzonych źródeł, ale nie musieli mieć nadmiernych praw edycyjnych w miejscach „produkcyjnych”.

Standardy raportów: spójność, która obniża liczbę dyskusji

Użytkownicy często kwestionują KPI nie dlatego, że formuła jest zła, ale dlatego, że raporty prezentują je w różnym kontekście i w różny sposób. Standardy raportowe nie muszą być rozbudowane, ale powinny być konsekwentne i widoczne.

• Jednolite definicje wizualne kluczowych wskaźników: te same nazwy, jednostki, formaty liczb i okresy porównawcze w całej organizacji.
• Konsekwentna praca z kontekstem: użytkownik ma jasno widzieć, jakie filtry/segmenty wpływają na KPI i kiedy wynik jest „globalny”, a kiedy „dla zaznaczenia”.
• Widoczna informacja o świeżości danych i zakresie: kiedy ostatnia aktualizacja, jaki okres obejmują dane, jakie są istotne wyłączenia.
• Minimalny zestaw elementów zaufania: wskazanie źródła/datasetu, właściciela merytorycznego oraz link do opisu metryk.

Efekt uboczny standardów jest bardzo praktyczny: mniej „alternatywnych” raportów budowanych od zera i mniejsze ryzyko, że różnice wynikają z formatowania, filtrów lub interpretacji.

Kontrola jakości: co weryfikować przed udostępnieniem

Kontrola jakości w kontekście KPI to nie tylko poprawność obliczeń, ale też przewidywalność zachowania w typowych scenariuszach użytkowania. Warto myśleć o QA jako o krótkiej liście kontrolnej, która zabezpiecza najczęstsze źródła rozbieżności.

• Zgodność z definicją KPI: czy raport pokazuje metrykę w tym samym znaczeniu i na tym samym poziomie szczegółowości, co uzgodniono.
• Spójność na przekrojach: czy wyniki nie „zmieniają znaczenia” po przejściu między stronami raportu i po zastosowaniu filtrów.
• Kontrole brzegowe: okresy bez danych, wartości zerowe/ujemne, przypadki „dziel przez zero”, brakujące kategorie.
• Wydajność i stabilność: czy raport nie wymusza zachowań prowadzących do długiego oczekiwania i błędów odświeżania.
• Bezpieczeństwo i prywatność: czy sposób udostępnienia nie pozwala obejść ograniczeń dostępu do danych.

Najważniejsze: QA powinno być przewidywalne i powtarzalne, żeby użytkownicy widzieli, że „certyfikowane” rzeczywiście znaczy „sprawdzone”.

Komunikacja do użytkowników: jak budować zaufanie i adopcję

Governance nie działa, jeśli jest niewidoczny. Użytkownik ma korzystać z właściwych KPI z własnej woli, bo to jest najprostsza i najbezpieczniejsza ścieżka. Tu kluczowa jest prosta komunikacja produktu danych: co jest oficjalne, jak tego używać i gdzie zgłaszać problemy.

• Jedno miejsce prawdy o KPI: łatwy link z raportu do opisu metryk (definicja, interpretacja, ograniczenia).
• Ogłoszenia zmian: krótkie, rzeczowe komunikaty o aktualizacjach KPI, nowych wersjach raportów i skutkach dla interpretacji.
• Jasna ścieżka zgłoszeń: użytkownik powinien wiedzieć, gdzie zgłosić błąd liczby, prośbę o nowe pole lub pytanie o interpretację.
• Ustalony język: odróżnianie „raportu eksperymentalnego” od „raportu oficjalnego” oraz „metryki lokalnej” od „KPI organizacyjnego”.

Gdy użytkownicy widzą spójne wskaźniki, zrozumiałe konteksty i jednoznaczne oznaczenia zaufanych datasetów, dyskusje o KPI przesuwają się z „kto ma rację” na „co możemy poprawić w procesie i danych”. To jest praktyczny cel udostępniania i kontroli jakości w Power BI.

8. Praktyczne artefakty: szablon karty metryki (pola) oraz przykładowa macierz RACI

Żeby ograniczyć dyskusje „co autor miał na myśli” i skrócić czas wdrożenia KPI do Power BI, warto używać dwóch prostych artefaktów: karty metryki (czyli ustandaryzowanego opisu KPI) oraz macierzy RACI (czyli jasnego podziału odpowiedzialności w cyklu życia KPI). Pierwsza pilnuje spójnej definicji i interpretacji, druga pilnuje spójnego procesu decyzyjnego.

Karta metryki (szablon pól)

Karta metryki działa jak „jedno źródło prawdy” dla KPI: łączy perspektywę biznesową z minimalnym zestawem informacji potrzebnych do późniejszej implementacji i utrzymania. Poniżej zestaw pól, które najczęściej wystarczają, aby uniknąć sporów o znaczenie, zakres i sposób użycia metryki.

• Nazwa metryki (krótka, jednoznaczna) oraz aliasy/synonimy (jak bywa nazywana w organizacji)
• Cel biznesowy (po co mierzymy; jaka decyzja ma być wsparta)
• Opis biznesowy (co mierzy metryka i czego nie mierzy)
• Właściciel metryki (osoba/rola biznesowa decydująca o znaczeniu i priorytetach)
• Odbiorcy (kto używa; poziom: operacyjny/taktyczny/strategiczny)
• Częstotliwość odświeżania (jak często dane i metryka powinny się aktualizować)
• Poziom szczegółowości (na jakim ziarnie ma działać: transakcja, dzień, miesiąc, klient, produkt itp.)
• Jednostka miary (np. %, szt., PLN) oraz typ metryki (licznik/udział/średnia/indeks itp.)
• Zakres obowiązywania (organizacja/obszar/proces; gdzie metryka ma sens)
• Reguły włączeń i wyłączeń (co liczymy, a co wykluczamy; definicje brzegowe)
• Wymiary analizy (typowe przekroje: czas, region, kanał, produkt, segment)
• Kontekst interpretacji (ważne założenia; kiedy wynik może być mylący)
• Filtry domyślne i ograniczenia (domyślny horyzont czasu, waluta, statusy itp.)
• Docelowy poziom/target (jeśli dotyczy) oraz progi (np. zielony/żółty/czerwony) i ich logika
• Przykłady i scenariusze (2–3 krótkie przykłady „jak czytać wynik”)
• Źródła danych (systemy/obszary; bez wchodzenia w implementację)
• Ograniczenia jakości danych (znane braki, opóźnienia, ryzyka)
• Raporty/produkty analityczne, gdzie KPI występuje (gdzie jest używany i w jakiej roli)
• Status metryki (proponowana / w trakcie / zatwierdzona / wycofana)
• Wersja i data obowiązywania (od kiedy definicja jest aktywna)
• Historia zmian (krótko: co się zmieniło i dlaczego)
• Osoby do konsultacji (np. data steward, BI owner) oraz kanał zgłaszania zmian/błędów

W praktyce karta metryki ma dwa zastosowania: standaryzuje język biznesu (żeby wszyscy mówili o tym samym) oraz ogranicza ryzyko wdrożeniowe (żeby implementacja nie zaczynała się od zgadywania definicji).

W Cognity łączymy teorię z praktyką – dlatego takie podejście do definicji KPI rozwijamy także w formie ćwiczeń na szkoleniach.

Przykładowa macierz RACI dla cyklu życia KPI

RACI porządkuje, kto wykonuje pracę, kto zatwierdza decyzje, kogo należy konsultować i kogo informować. Kluczowe jest, by dla każdego etapu istniała jedna rola A (Accountable) — inaczej spory wracają przy każdym wdrożeniu.

Role (typowe w BI/Power BI):

• Właściciel KPI (biznes)
• Data Owner (odpowiedzialny za domenę danych/źródło)
• Data Steward (pilnuje definicji, jakości i zgodności w domenie)
• BI Owner / Governance (standardy, priorytety, spójność portfela KPI)
• Power BI Developer / Modeler (implementacja w modelu semantycznym i raportach)
• QA/Tester (walidacja, testy porównawcze, odbiór jakościowy)
• Użytkownicy biznesowi (konsumenci i dostawcy feedbacku)

Etapy i przykładowe przypisania RACI (bez tabel):

• Zgłoszenie potrzeby KPI: R – Właściciel KPI; A – BI Owner/Governance; C – Użytkownicy biznesowi, Data Steward; I – Power BI Developer
• Warsztat definicyjny i doprecyzowanie znaczenia: R – Właściciel KPI; A – Właściciel KPI; C – Data Steward, Data Owner, BI Owner; I – Power BI Developer, Użytkownicy biznesowi
• Ocena wykonalności i dostępności danych: R – Data Owner; A – Data Owner; C – Data Steward, Power BI Developer; I – Właściciel KPI, BI Owner
• Priorytetyzacja i decyzja o wdrożeniu: R – BI Owner/Governance; A – BI Owner/Governance; C – Właściciel KPI, Data Owner; I – Power BI Developer, Użytkownicy biznesowi
• Implementacja metryki (model/miary/raport): R – Power BI Developer/Modeler; A – BI Owner/Governance; C – Data Steward, Właściciel KPI; I – Użytkownicy biznesowi, Data Owner
• Walidacja i akceptacja biznesowa: R – QA/Tester; A – Właściciel KPI; C – Power BI Developer, Data Steward; I – BI Owner, Użytkownicy biznesowi
• Publikacja i komunikacja: R – BI Owner/Governance; A – BI Owner/Governance; C – Właściciel KPI, Power BI Developer; I – Użytkownicy biznesowi, Data Owner, Data Steward
• Utrzymanie i monitoring jakości: R – Data Steward; A – Data Owner; C – BI Owner, Power BI Developer; I – Właściciel KPI, Użytkownicy biznesowi
• Zmiana definicji (change request): R – Właściciel KPI; A – Właściciel KPI; C – BI Owner, Data Owner, Data Steward, Power BI Developer; I – Użytkownicy biznesowi
• Wycofanie KPI: R – BI Owner/Governance; A – BI Owner/Governance; C – Właściciel KPI, Użytkownicy biznesowi, Data Owner; I – Power BI Developer, Data Steward

Te dwa artefakty razem działają jak „kontrakt”: karta metryki ogranicza niejednoznaczność, a RACI ogranicza przeciąganie decyzji i dublowanie odpowiedzialności.

Claude Code w DevOps: co psuje większość pipeline’ów CI/CD i jak AI pomaga to naprawić 05 czerwca 2026

Claude Code w IT: jak automatyzacja dokumentacji technicznej naprawdę skraca czas projektów 03 czerwca 2026