Koszty Microsoft Fabric pod kontrolą 📊 Jak przetrwać skokowe obciążenia BI

Skąd biorą się skoki kosztów w Fabric przy końcówkach miesiąca?

Skoki kosztów w Fabric pod koniec miesiąca zwykle wynikają z nagłego wzrostu zużycia mocy obliczeniowej w krótkim czasie, a nie z samej zmiany cennika czy jednorazowej opłaty. W praktyce na koniec okresu rozliczeniowego kumulują się operacje BI: odświeżenia modeli semantycznych, większa liczba uruchomień raportów, przeliczenia danych, intensywniejsze zapytania analityczne oraz równoległa praca wielu użytkowników na tych samych zasobach.

Najczęstszy mechanizm jest prosty: gdy wiele procesów uruchamia się jednocześnie, Fabric zużywa więcej jednostek obliczeniowych w tych godzinach, w których obciążenie jest najwyższe. Końcówka miesiąca jest szczególnie podatna na taki efekt, bo wtedy zespoły finansowe, controllingowe i operacyjne równolegle zamykają okres, aktualizują dane i generują raporty porównawcze. To powoduje pik wykorzystania capacity, a więc także wyższy koszt.

Kumulacja odświeżeń danych — harmonogramy uruchamiane są w tych samych oknach czasowych, często po dostarczeniu finalnych danych źródłowych.
Większa liczba użytkowników i zapytań — więcej osób jednocześnie otwiera raporty, filtruje dane i uruchamia analizy ad hoc.
Cięższe operacje niż w zwykłe dni — raportowanie miesięczne obejmuje zwykle większy zakres danych, porównania okresów i bardziej złożone przeliczenia.
Konkurencja o te same zasoby — różne workloady działające równolegle na jednej pojemności wzajemnie zwiększają presję na compute.

Warto rozumieć, że taki skok kosztów nie musi oznaczać błędu ani nieefektywności samej platformy. Często jest to naturalny efekt nierównomiernego profilu użycia: przez większość miesiąca obciążenie jest umiarkowane, a w kilku krytycznych dniach gwałtownie rośnie. To właśnie ta koncentracja aktywności na końcu miesiąca najczęściej odpowiada za widoczne wzrosty kosztów w Fabric.

Jak dobrać pojemność Fabric, gdy obciążenie jest sezonowe i nierówne?

Przy obciążeniu sezonowym nie dobiera się pojemności do absolutnego maksimum, bo prowadzi to do stałego przewymiarowania i niepotrzebnych kosztów. Punktem wyjścia powinien być realny profil użycia: jakie obciążenie występuje w typowych dniach, jak długo trwają piki oraz które procesy są krytyczne czasowo. W praktyce oznacza to analizę zużycia zasobów w podziale na okres bazowy i okresy szczytowe, na przykład koniec miesiąca, zamknięcie finansowe lub kampanie raportowe.

Najbezpieczniej dobrać pojemność tak, aby pokrywała stabilne, powtarzalne obciążenie bazowe, a nie rzadkie skoki. Jeśli szczyt trwa krótko i występuje przewidywalnie, bardziej racjonalne jest okresowe zwiększenie pojemności na czas piku niż utrzymywanie wyższego poziomu przez cały miesiąc. Kluczowe jest więc rozróżnienie, czy nierówność obciążenia wynika z krótkich, akceptowalnych wzrostów, czy z regularnych przeciążeń, które wpływają na czas odświeżeń, wykonywanie zapytań i dostępność zasobów dla użytkowników.

Przy doborze warto patrzeć nie tylko na średnie zużycie, ale przede wszystkim na percentyle i czas trwania przeciążenia. Średnia bywa myląca, bo maskuje momenty, w których wiele procesów uruchamia się jednocześnie. Jeżeli piki są krótkie, można zaakceptować pewien margines kolejkowania. Jeżeli jednak w okresach szczytowych regularnie dochodzi do opóźnień zadań, spadku wydajności raportów lub konfliktu między odświeżeniami a pracą użytkowników, to znak, że pojemność bazowa jest za mała albo harmonogram obciążeń jest źle rozłożony.

W praktyce poprawny dobór opiera się na trzech danych: obciążeniu codziennym, przewidywalnym maksimum oraz tolerancji biznesu na spowolnienie. Jeśli organizacja wymaga niezmiennie krótkiego czasu odpowiedzi także w końcówce miesiąca, pojemność trzeba dobrać bliżej poziomu szczytowego. Jeżeli dopuszczalne są krótkie opóźnienia poza godzinami krytycznymi, można utrzymywać niższą bazę i zwiększać zasoby tylko wtedy, gdy rośnie ruch.

Dobrą decyzję potwierdza dopiero obserwacja po wdrożeniu: czy w okresach sezonowych zadania kończą się w wymaganym czasie i czy użytkownicy nie odczuwają degradacji wydajności. Jeśli nie, pojemność należy skorygować na podstawie rzeczywistego wzorca użycia, a nie jednorazowego piku ani deklaratywnych szacunków.

💡 Dobieraj pojemność Fabric do stabilnego obciążenia bazowego, a nie do pojedynczego maksimum — sezonowe piki zwykle taniej obsłużyć czasowym skalowaniem. Patrz na percentyle i czas trwania przeciążeń, bo średnia łatwo ukrywa realne problemy wydajnościowe.

Co da się zoptymalizować w modelach semantycznych Power BI, żeby zużywać mniej zasobów?

Największy wpływ na zużycie zasobów mają trzy obszary: rozmiar modelu w pamięci, złożoność obliczeń wykonywanych przy zapytaniu oraz koszt odświeżania. W praktyce oznacza to, że warto ograniczać ilość danych ładowanych do modelu, upraszczać strukturę i przenosić część pracy z warstwy DAX do przygotowania danych tam, gdzie to uzasadnione.

Po stronie rozmiaru modelu najwięcej daje usunięcie niepotrzebnych kolumn i tabel, ograniczenie liczby wierszy do realnie potrzebnego zakresu oraz używanie właściwych typów danych. Szczególnie kosztowne są kolumny tekstowe o wysokiej unikalności, bo słabo się kompresują. Jeśli dana kolumna nie jest używana w relacjach, filtrach, osiach wizualizacji ani w obliczeniach, nie powinna być ładowana do modelu. Pomaga też trzymanie modelu w układzie zbliżonym do gwiazdy, bo nadmiar relacji i zbędne denormalizacje zwiększają koszt przetwarzania.

Po stronie zapytań kluczowe jest ograniczenie drogich obliczeń wykonywanych dynamicznie. Miary oparte na złożonych iteratorach, częstym przechodzeniu po dużych tabelach i rozbudowanych warunkach filtrujących zużywają więcej CPU niż proste agregacje. Warto unikać sytuacji, w których logika biznesowa jest wielokrotnie liczona na poziomie raportu, jeśli może zostać przygotowana wcześniej jako prostszy atrybut lub agregat. Jednocześnie lepiej preferować miary niż kolumny obliczane, gdy celem jest ograniczenie pamięci, bo kolumny są materializowane i zwiększają rozmiar modelu.

Istotna jest też optymalizacja odświeżania. Jeśli model przelicza całą historię przy każdym odświeżeniu, zużycie zasobów rośnie skokowo. Dlatego warto ograniczać zakres przetwarzanych danych, stosować partycjonowanie lub podejście przyrostowe tam, gdzie dane mają naturalny wymiar czasu. Korzyść jest podwójna: krótsze odświeżenie i mniejsze obciążenie pojemności w godzinach szczytu.

Ogranicz dane w modelu — usuń nieużywane kolumny, zmniejsz zakres historii, pilnuj typów danych, redukuj kolumny tekstowe o wysokiej unikalności.
Uprość model — trzymaj się schematu gwiazdy, ogranicz zbędne relacje i zduplikowane tabele, nie materializuj logiki bez potrzeby.
Usprawnij obliczenia — upraszczaj DAX, unikaj kosztownych iteratorów na dużych tabelach, przenoś ciężkie transformacje do wcześniejszego etapu przygotowania danych, jeśli to daje prostszy model.
Zmniejsz koszt odświeżania — przetwarzaj tylko to, co się zmieniło, zamiast pełnej historii przy każdym cyklu.

W skrócie: mniej zasobów zużywa model mniejszy, prostszy i mniej dynamicznie przeliczany. Jeśli trzeba wybrać priorytet, najpierw warto redukować objętość danych i liczbę kosztownych obliczeń, bo to zwykle daje największy efekt zarówno dla pamięci, jak i CPU.

Jak zaplanować odświeżenia i ograniczyć równoległość, żeby nie generować „pików”?

Najważniejsza zasada jest prosta: nie uruchamiać wielu ciężkich odświeżeń w tym samym oknie czasowym. „Piki” pojawiają się wtedy, gdy kilka datasetów, dataflowów lub procesów ETL startuje równolegle i przez krótki czas kumuluje zapotrzebowanie na zasoby. W praktyce planowanie powinno polegać na rozłożeniu zadań w czasie, tak aby obciążenie było możliwie płaskie, a nie skokowe.

Najpierw warto podzielić odświeżenia według wagi i pilności. Procesy krytyczne biznesowo oraz te, które trwają najdłużej, powinny dostać osobne sloty czasowe. Lżejsze odświeżenia można umieszczać pomiędzy nimi, ale bez nakładania ich na największe zadania. Jeśli kilka raportów korzysta z tych samych danych źródłowych, lepiej zsynchronizować je tak, aby najpierw odświeżał się wspólny element pośredni, a dopiero potem zależne modele. Ogranicza to jednoczesne odpytywanie tych samych źródeł i zmniejsza ryzyko zatorów.

Ograniczenie równoległości oznacza świadome sterowanie liczbą procesów działających jednocześnie. Zamiast dopuszczać pełną konkurencję, lepiej ustalić maksymalną liczbę równoległych odświeżeń dla danego okna i trzymać się kolejki. To zwykle wydłuża całe okno odświeżania, ale znacząco zmniejsza chwilowe zużycie mocy obliczeniowej. W środowiskach z przewidywalnym obciążeniem bardziej opłaca się mieć dłuższy, stabilny przebieg niż krótki, ale generujący skoki.

Dobrą praktyką jest też unikanie uruchamiania odświeżeń dokładnie o pełnych godzinach, bo wtedy najłatwiej o niezamierzoną kumulację z innymi zadaniami harmonogramu. Przesunięcie startów o kilka lub kilkanaście minut często wystarcza, by rozbić jeden duży pik na kilka mniejszych. Jeśli koniec miesiąca oznacza większe wolumeny danych, harmonogram dla tego okresu powinien być osobny, a nie identyczny jak w zwykłych dniach.

Pełna odpowiedź wymaga jeszcze jednej zasady: planować na podstawie rzeczywistego czasu trwania i zużycia zasobów, a nie deklaracji zespołów. Jeżeli odświeżenie nominalnie trwa 20 minut, ale w dniach zamknięcia miesiąca trwa 50 minut, harmonogram trzeba budować dla wariantu obciążonego. Tylko wtedy ograniczenie równoległości rzeczywiście zapobiegnie pikom, zamiast jedynie przesunąć problem na później.

💡 Rozłóż ciężkie odświeżenia w czasie i ogranicz liczbę procesów uruchamianych równolegle, aby uniknąć krótkich, kosztownych pików zużycia zasobów. Harmonogram buduj na podstawie rzeczywistych czasów trwania w okresach szczytowych, a nie na bazie nominalnych założeń.

Kiedy opłacają się agregacje i cache, a kiedy to tylko maskuje problem?

Agregacje i cache opłacają się wtedy, gdy rzeczywisty wzorzec użycia polega na wielokrotnym wykonywaniu podobnych zapytań do tych samych danych, zwłaszcza na wyższym poziomie szczegółowości niż potrzebują użytkownicy. W praktyce ma to sens przy raportach z dużą liczbą odczytów, powtarzalnych filtrach, analizie trendów, KPI i przekrojach po czasie, regionie, produkcie czy kliencie, jeśli większość odbiorców nie potrzebuje schodzić do pełnego detalu przy każdym odświeżeniu widoku. W takim scenariuszu agregacja zmniejsza ilość danych przetwarzanych przy zapytaniu, a cache ogranicza liczbę ponownych obliczeń, więc realnie redukują zużycie zasobów i stabilizują działanie w godzinach szczytu.

To rozwiązanie jest szczególnie uzasadnione wtedy, gdy koszt wynika głównie z warstwy odczytu, a nie z wadliwego modelu lub nieefektywnego procesu ładowania danych. Jeżeli ten sam zestaw wizualizacji jest otwierany setki razy pod koniec miesiąca, a logika biznesowa jest stabilna i przewidywalna, to preagregacja i dobrze wykorzystany cache są normalnym mechanizmem optymalizacji, a nie obejściem problemu.

Zaczynają maskować problem wtedy, gdy są używane do ukrycia błędów projektowych. Typowe przypadki to zbyt wysoka kardynalność modelu, niepotrzebnie szerokie tabele, zła relacja między tabelami, kosztowne obliczenia wykonywane przy każdym zapytaniu, nadmiar wizualizacji na stronie, DirectQuery kierowane do wolnego źródła albo brak kontroli nad tym, kto i jak często uruchamia ciężkie raporty. Wtedy cache może chwilowo poprawić odczucie szybkości, ale po wygaśnięciu pamięci podręcznej albo przy zmianie filtrów problem wraca. Podobnie agregacje nie pomogą, jeśli użytkownicy i tak stale schodzą do poziomu transakcji albo jeśli większość kosztu generuje sam proces odświeżania danych, a nie zapytania użytkowników.

Najprostsze kryterium jest takie: jeśli po wdrożeniu agregacji lub cache maleje liczba kosztownych operacji bez pogorszenia jakości analizy i bez mnożenia wyjątków w modelu, to optymalizacja jest uzasadniona. Jeśli natomiast trzeba budować coraz więcej specjalnych wyjątków, utrzymywać wiele równoległych ścieżek danych, a zużycie zasobów spada tylko pozornie lub krótkotrwale, to najpewniej nie rozwiązujesz przyczyny, tylko odsuwasz ją w czasie.

W kontekście skokowych obciążeń BI pod koniec miesiąca warto traktować agregacje i cache jako narzędzia do obsługi przewidywalnego popytu na powtarzalne analizy, a nie jako remedium na każdy problem wydajnościowy. Najpierw trzeba ustalić, czy obciążenie generują powtarzalne odczyty tych samych danych, czy raczej nieefektywny model, zapytania i sposób użycia raportów. Dopiero wtedy wiadomo, czy to realna optymalizacja kosztu, czy tylko jego chwilowe ukrycie.

Jak monitorować zużycie i przypisać koszty do zespołów (showback/chargeback)?

Podstawą jest rozdzielenie dwóch warstw: pomiaru zużycia oraz reguł alokacji kosztu. Showback oznacza raportowanie kosztów do zespołów bez formalnego obciążania budżetu, a chargeback to już przypisanie realnej kwoty do właściciela obciążenia. W praktyce najpierw trzeba wiedzieć, które obciążenia pochodzą z jakiego obszaru: workspace’u, rozwiązania, procesu odświeżania, użytkownika lub jednostki biznesowej. Bez spójnego mapowania właścicieli nawet dokładne metryki zużycia nie dadzą wiarygodnego rozliczenia.

Najlepszy model to przypisywanie każdego zasobu do jednoznacznego właściciela kosztu już na etapie organizacji środowiska. Oznacza to standard nazewnictwa, tagowania i utrzymywania słownika, który mówi, do jakiego zespołu należy dany workspace, pipeline, model lub raport. Następnie trzeba regularnie zbierać dane o wykorzystaniu pojemności i aktywności obciążeń: czasach wykonania, liczbie uruchomień, intensywności odświeżeń, zapytaniach użytkowników oraz zużyciu zasobów w określonym przedziale czasu. Dopiero połączenie tych danych z właścicielem pozwala zbudować raport showback/chargeback.

Najważniejsze jest ustalenie jednej, zrozumiałej metody alokacji. Jeśli obciążenie da się przypisać bezpośrednio, koszt warto przypisać według rzeczywistego zużycia danego zespołu. Jeśli zasób jest współdzielony, potrzebny jest uzgodniony klucz podziału, na przykład według udziału w czasie przetwarzania, liczby odświeżeń albo procentowego wykorzystania pojemności. Nie należy mieszać wielu metod bez jasnych zasad, bo wtedy raport przestaje być obronny finansowo i operacyjnie.

W kontekście skokowych obciążeń pod koniec miesiąca szczególnie istotne jest raportowanie w krótkich interwałach, a nie tylko miesięcznej sumy. Zespół może wyglądać „tanio” w ujęciu średnim, a jednocześnie generować bardzo kosztowne piki w kilku dniach zamknięcia okresu. Dlatego w showbacku warto pokazywać nie tylko koszt łączny, ale też koszt w czasie, udział w szczytach obciążenia oraz które procesy odpowiadały za skoki.

Dobrze działający model rozliczeń powinien odpowiadać na trzy pytania: kto wygenerował zużycie, ile zasobów zużył i według jakiej reguły przeliczono to na koszt. Jeżeli te trzy elementy są jawne i powtarzalne, showback pomaga ograniczać nadużycia i planować optymalizacje, a chargeback może być podstawą realnego rozliczania zespołów bez sporów o metodologię.

W praktyce warto zacząć od showbacku, bo pozwala zweryfikować jakość danych, poprawność przypisań i akceptację modelu przez właścicieli biznesowych. Dopiero gdy dane są kompletne, a zasady stabilne, można przejść do chargebacku. Najczęstszy błąd to próba obciążania kosztami bez wcześniejszego uporządkowania właścicieli zasobów i bez uzgodnienia, czy rozliczany jest koszt rzeczywistego zużycia, rezerwacji pojemności, czy udziału w szczytowym obciążeniu.

Jakie szybkie zasady governance najbardziej obniżają koszty bez blokowania analityki?

Największy efekt dają proste reguły, które ograniczają marnowanie mocy obliczeniowej, ale nie utrudniają pracy analitykom. W praktyce chodzi o to, by kontrolować kto może uruchamiać kosztowne operacje, gdzie mogą być uruchamiane i jak często mają się wykonywać. Dobrze ustawione governance nie polega na blokadach „na wszelki wypadek”, tylko na odseparowaniu pracy eksperymentalnej od produkcyjnej oraz na usunięciu automatyzmów, które generują koszty bez realnej wartości biznesowej.

Oddziel środowiska i pojemności według krytyczności – produkcja BI, development i eksperymenty nie powinny współdzielić tych samych zasobów. To ogranicza sytuacje, w których testy, ad hoc notebooki lub jednorazowe przeliczenia podbijają koszty i pogarszają wydajność raportów używanych biznesowo.
Wprowadź zasadę minimalnych uprawnień do tworzenia i planowania obciążeń – nie każdy użytkownik powinien móc zakładać pipeline, ustawiać częste harmonogramy odświeżeń, publikować duże modele czy uruchamiać intensywne zadania. Dostęp do konsumpcji danych może pozostać szeroki, ale prawo do generowania kosztu powinno być zawężone.
Standaryzuj harmonogramy i limity – szybka oszczędność zwykle wynika z ograniczenia nadmiarowych odświeżeń, równoległych uruchomień i niekontrolowanych retry. Zasada jest prosta: odświeżaj dane zgodnie z realną potrzebą biznesową, a nie „jak najczęściej”. Dla wielu zbiorów wystarcza rzadszy harmonogram, odświeżanie przyrostowe albo uruchamianie tylko po zmianie danych źródłowych.
Obowiązkowe tagowanie i prosty przegląd kosztów właścicielskich – każdy workspace, pipeline czy model powinien mieć właściciela i cel biznesowy. Jeśli zasób nie ma właściciela albo nikt nie potrafi uzasadnić jego użycia, to najczęściej jest kandydatem do wyłączenia, konsolidacji lub przeniesienia poza godziny szczytu.

Jeżeli trzeba zacząć od minimum, najbezpieczniejszy zestaw to: rozdzielenie produkcji od eksperymentów, ograniczenie uprawnień do planowania ciężkich zadań oraz przegląd harmonogramów odświeżeń. Te trzy zasady zwykle obniżają koszty najszybciej, a jednocześnie nie blokują analityki, bo użytkownicy nadal mają dostęp do danych i raportów — tylko mniej przypadkowo uruchamiają drogie operacje.

Kluczowe jest też to, by governance opierał się na wyjątkach, a nie na powszechnych zakazach. Jeśli zespół potrzebuje większej częstotliwości odświeżania lub mocy do zamknięcia miesiąca, powinno to być możliwe, ale jako świadoma decyzja właściciela procesu, a nie domyślna konfiguracja dla wszystkich.

Majczęściej zadawane pytania i odpowiedzi odnośnie Koszty Fabric pod kontrolą: jak przetrwać skokowe obciążenia BI pod koniec miesiąca

Czy skoki kosztów Fabric pod koniec miesiąca zawsze oznaczają zły dobór pojemności?

Nie, skoki kosztów Fabric nie zawsze oznaczają zły dobór pojemności. Często są naturalnym skutkiem krótkiego, przewidywalnego wzrostu aktywności BI przy zamknięciu miesiąca. Problem pojawia się dopiero wtedy, gdy piki regularnie powodują opóźnienia odświeżeń, spadek wydajności raportów albo konflikt między zadaniami a pracą użytkowników.

Po czym poznać, że lepiej czasowo skalować Fabric zamiast utrzymywać wyższą pojemność przez cały miesiąc?

Czasowe skalowanie ma sens wtedy, gdy szczytowe obciążenie jest krótkie i przewidywalne. Jeśli przez większość miesiąca zużycie pozostaje umiarkowane, a wzrost pojawia się głównie w końcówce okresu, stałe utrzymywanie wyższej pojemności zwykle prowadzi do przewymiarowania. Decyzję warto opierać na czasie trwania pików, ich powtarzalności i tolerancji biznesu na krótkie spowolnienia.

Jakie objawy wskazują, że problemem są harmonogramy odświeżeń, a nie same raporty?

Najczęstszym sygnałem są przeciążenia pojawiające się głównie w oknach odświeżeń. Jeśli spadki wydajności zbiegają się z uruchamianiem wielu procesów naraz, przyczyną zwykle jest zła organizacja harmonogramu. Typowe objawy to:

nakładanie się ciężkich odświeżeń,
wydłużanie czasu zadań pod koniec miesiąca,
opóźnienia raportów w godzinach przetwarzania.

Czy zmniejszenie liczby odświeżeń może obniżyć koszty Fabric bez pogorszenia analityki?

Tak, ograniczenie nadmiarowych odświeżeń często obniża koszty bez realnej straty dla użytkowników. Wiele zbiorów danych nie wymaga odświeżania tak często, jak wynika z domyślnych ustawień lub przyzwyczajeń zespołów. Jeśli dane biznesowo zmieniają się rzadziej, lepiej dopasować harmonogram do faktycznej potrzeby niż utrzymywać częste cykle generujące niepotrzebne obciążenie.

Kiedy warto najpierw optymalizować model semantyczny Power BI, zamiast zwiększać pojemność Fabric?

Najpierw warto optymalizować model wtedy, gdy koszt wynika z jego rozmiaru, złożoności lub drogiego odświeżania. Zwiększenie pojemności może tylko zamaskować nieefektywną konstrukcję. Dobrym kandydatem do optymalizacji jest model zawierający nieużywane kolumny, zbyt szeroką historię danych, kosztowne obliczenia DAX albo pełne odświeżanie tam, gdzie możliwe jest podejście przyrostowe.

Jakie błędy najczęściej powodują niepotrzebne piki kosztów w Microsoft Fabric?

Najczęstsze błędy to równoległe uruchamianie zbyt wielu ciężkich procesów i brak kontroli nad tym, co naprawdę generuje koszt. W praktyce problem zwykle wynika z kilku powtarzalnych decyzji:

identycznych okien startu dla wielu odświeżeń,
przewymiarowanych modeli semantycznych,
współdzielenia zasobów produkcyjnych z eksperymentami,
braku właściciela dla workspace'u lub procesu.

Czy agregacje i cache pomagają także wtedy, gdy użytkownicy często otwierają te same raporty na koniec miesiąca?

Tak, agregacje i cache mogą realnie pomóc, jeśli wiele osób powtarza podobne odczyty tych samych danych. W takim scenariuszu zmniejszają liczbę kosztownych operacji wykonywanych przy każdym otwarciu raportu. To ma sens szczególnie dla powtarzalnych analiz KPI, trendów i przekrojów, o ile użytkownicy nie schodzą stale do pełnego poziomu transakcyjnego.

Od czego zacząć showback kosztów Fabric, jeśli organizacja jeszcze nie ma dojrzałego governance?

Najlepiej zacząć od przypisania każdego zasobu do jednoznacznego właściciela i prostego raportu zużycia. Bez tego nawet dokładne dane techniczne nie przełożą się na wiarygodne rozliczenie. Na początku wystarczy uporządkować nazewnictwo, workspace'y i odpowiedzialność za modele, raporty oraz pipeline'y, a dopiero potem łączyć zużycie z regułami alokacji kosztu.