Szia, üdvözöllek a blogomon!

Az adatplatformok elején ritkán beszélünk költségről. Az első hetekben a fókusz inkább azon van, hogy „működjön”: legyen adat, legyen riport, legyen válasz a kérdésekre. Aztán a rendszer nő: több csapat, több adatforrás, több frissítés, több riport. És egyszer csak megjelenik a kérdés: mennyibe kerül mindez – és arányban van-e azzal, amit kapunk?

A Microsoft Fabric kapacitásalapú működésében számomra az a fontos, hogy az erőforrás-felhasználás egy ponton túl nem marad láthatatlan. A futó pipeline-ok, a számítások, a lekérdezések mind terhelést jelentenek. Ez önmagában nem baj. A baj akkor kezdődik, amikor a terhelés mögött nincs üzleti érték – csak megszokás, duplikáció vagy rossz döntések.

Képzelj el egy tipikus helyzetet: egy KPI-t több csapat is használ, de mindenki „csinál magának egy verziót”. Ugyanaz az adat három helyen van betöltve, ugyanaz a transzformáció háromszor fut le, és a riportok mégsem egyeznek mindig. Ilyenkor nem csak a bizalom sérül, hanem a költség is nő, és észrevétlenül fizetjük a rendszer széttöredezettségét.

A cost thinking nem azt jelenti, hogy „spóroljunk”. Inkább azt, hogy legyen tudatos:
– Hol történjen a számítás?
– Mit érdemes egyszer előállítani és újrahasználni?
– Mi az, amit tényleg minden frissítésnél újra kell számolni?
– Hol van duplikáció, és miért?

Elemzőként ez nekem egy új szint, mert eddig a helyes szám volt a cél, most viszont már az is, hogy fenntartható legyen az út, amin előáll. Ha egy riport csak úgy működik, hogy naponta kézzel ellenőrzünk mindent és közben felesleges futások mennek, az hosszú távon drága – akár pénzben, akár emberi energiában.

A 24. nap tanulsága számomra az, hogy a költség nem „pénzügyes téma”, hanem architektúra- és fegyelmi kérdés. A jó döntések nem csak stabilabb rendszert adnak, hanem hatékonyabbat is.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan

Szia, üdvözöllek a blogomon!

A legtöbb adatplatform nem egyik napról a másikra omlik össze. A szétesés ritkán látványos, inkább lassú, apró jelekből áll össze.

Először csak egy plusz tábla kerül be „ideiglenesen”. Aztán egy számítás duplikálódik, mert gyorsabb így, mint egységesíteni. Később ugyanaz a KPI több helyen él, kissé eltérő definícióval. Technikailag minden működik, de a rendszer elkezd repedezni.

Képzelj el egy Fabric környezetet, ahol:
– nincs egységes névkonvenció
– nincs dokumentált definíció
– nincs világos rétegzés
– a változtatások közvetlenül élesben történnek.

Egy darabig ez nem tűnik problémának. A riportok jönnek, a számok látszólag rendben vannak. Aztán megjelennek az első kérdések: „Miért más nálam?” „Ez a szám honnan jön?” „Melyik verzió az aktuális?”

A szétesés első jele nem technikai hiba, hanem a bizalom csökkenése, a kérdések számának növekedése.

A Microsoft Fabric eszköztára lehetőséget ad a strukturáltságra: workspace-ek, jogosultságok, rétegzés, deployment. De ezek csak lehetőségek. Ha nem élünk velük tudatosan, a rendszer ugyanúgy fragmentálódhat, mint bármely más platformon.

Elemzőként fontos felismerni a korai jeleket. Amikor egyre több manuális ellenőrzés történik. Amikor egyre több párhuzamos riport jelenik meg. Amikor a számok körül több a vita, mint a döntés.

A 23. nap tanulsága számomra az, hogy az adatplatform stabilitása nem statikus állapot, hanem folyamatos karbantartást és tudatos döntéseket igényel.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan

Szia, üdvözöllek a blogomon!

Az adatplatformok fejlődése gyakran észrevétlenül történik. Először csak egy riport készül, aztán kettő, majd egyre több üzleti terület kezd el támaszkodni ugyanarra a rendszerre. Egy ponton viszont felmerül a kérdés: vajon elég-e egyetlen környezetben működni?

Sok kisebb szervezetnél minden egy helyen történik. Ugyanabban a workspace-ben fejlesztünk, tesztelünk és publikálunk. Gyors. Egyszerű. Kényelmes. Amíg nincs probléma.

Képzelj el egy konkrét helyzetet. Egy pipeline módosítás történik, mert optimalizálni szeretnénk a betöltési időt. A módosítás közvetlenül az éles környezetben történik. A következő frissítés után a riport számai eltérnek a megszokottól. Az üzlet azonnal reagál. A kérdés nem az, hogy a változtatás indokolt volt-e, hanem az, hogy miért nem látta senki előre a hatását.

A Dev–Test–Prod struktúra nem vállalati túlzás, hanem kontrollmechanizmus. A fejlesztői környezetben lehet kísérletezni. A teszt környezetben validálni lehet az üzleti logikát. Az éles környezet pedig stabil marad.

A Microsoft Fabric támogatja a deployment folyamatokat és a workspace-ek strukturált kezelését, de a több környezet használata nem automatikus, tudatos döntés szükséges hozzá.

Elemzőként számomra itt válik láthatóvá a rendszer érettsége. Nem attól lesz professzionális egy adatplatform, hogy hány komponense van, hanem attól, hogy a változtatás kontrolláltan történik-e.

A 22. nap tanulsága az, hogy a növekvő komplexitás növekvő fegyelmet igényel, illetve a több környezet nem lassítja a munkát, hanem hosszú távon biztonságot ad.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #Busin

Szia, üdvözöllek a blogomon!

Ahogy haladok előre a Microsoft Fabric világában, egyre inkább azt érzem, hogy a technológia mögött mindig szervezeti kérdések húzódnak meg. Az egyik legfontosabb ezek közül: ki a valódi adatgazda?

Elsőre könnyű rávágni, hogy az adat az üzleté. Vagy az IT-é. Vagy a riportkészítőé. De amikor konkrét helyzetbe kerülünk, a válasz már nem ennyire egyértelmű.

Képzelj el egy tipikus céges szituációt. Van egy KPI, amit minden terület használ: marketing kampányt optimalizál rá, pénzügy riportálja, operáció tervez vele. Egy idő után felmerül, hogy a számítás logikáját módosítani kellene. Ki dönt erről? Ki hagyja jóvá? Ki kommunikálja? És ha a változás miatt eltérnek a korábbi riportok, ki vállalja a felelősséget?

Ha nincs kijelölt adatgazda, akkor mindenki használja az adatot, de senki nem vállalja érte a végső felelősséget. Ilyenkor a vita nem a számról szól, hanem a hatáskörről.

A Fabric technikai értelemben támogatja a szerepkörök, workspace-ek és jogosultságok kezelését. De az eszköz nem fogja megmondani, hogy ki legyen a data owner. Ez szervezeti döntés.

Egy érettebb működésben legalább három külön szerepet érdemes tisztázni:
– Ki felel az adat forrásáért?
– Ki felel a definícióért?
– Ki felel a publikálásért és kommunikációért?

Ez a három szerep nem mindig ugyanaz a személy vagy csapat és ez így rendben is van.

Elemzőként számomra ez az a pont, ahol a technikai tudás már nem elég. Tudnom kell, kit kell bevonni, kivel kell egyeztetni, és kinek a döntése végleges. Az adatplatform nem csak adatút, hanem felelősségi térkép is.

A 21. nap tanulsága számomra az, hogy a stabil adatplatform nem ott kezdődik, hogy jól van-e felépítve a Lakehouse, hanem ott, hogy tiszták-e a felelősségi viszonyok.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan

Szia, üdvözöllek a blogomon!

Az elmúlt napokban külön-külön megnéztük az építőkockákat: OneLake, pipeline, rétegzés, semantic model. Ma viszont egy lépéssel hátrébb lépünk, és végigkövetünk egy teljes adatutat – forrástól egészen az üzleti döntésig.

Képzelj el egy webshopot. Beérkezik egy rendelés. Ez az esemény bekerül a forrásrendszerbe. Innen indul az adat útja.

Első lépésként a nyers adat (raw réteg) változatlanul betöltésre kerül. Itt még nem döntünk, nem tisztítunk, nem számolunk. Csak megőrizzük az eseményt úgy, ahogy történt. Ez azért fontos, mert ha később vita van, van mihez visszanyúlni.

A következő lépés a curated réteg. Itt már történik feldolgozás: kiszűrjük a tesztrendeléseket, egységesítjük a dátumformátumokat, összekapcsoljuk az ügyféladatokkal, kiszámoljuk az árrést. Itt jelenik meg az első üzleti logika.

Ezután jön a semantic model réteg. Itt dől el, mit nevezünk „bruttó profitnak”. Ide tartozik, hogy a szállítási költség beleszámít-e, hogyan kezeljük a visszárut, milyen árfolyamot használunk. Itt már nem technikai adatokról beszélünk, hanem definíciókról.

Végül a riport rétegben vizualizáljuk az eredményt. Az üzlet itt találkozik a számmal. Itt születik döntés: növeljük a marketingbüdzsét? Emeljük az árat? Leállítunk egy kampányt?

Ha a szám nem stimmel, hol keresünk hibát? A forrásrendszerben? A pipeline-ban? A transzformációban? A definícióban? Ha nem látjuk a teljes láncot, csak találgatunk.

Ez az „end-to-end” gondolkodás lényege. Nem egyetlen eszközről szól, hanem az összefüggésekről.

Számomra itt válik igazán érthetővé, mit jelent a Microsoft Fabric szemlélete. Nem attól erős, hogy sok komponenst tartalmaz, hanem attól, hogy lehetőséget ad az egész folyamat átlátására.

És amikor már nem csak riportot látunk, hanem adatutat, akkor kezdünk el valóban adatplatformban gondolkodni.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan

Szia, üdvözöllek a blogomon!

Az elmúlt napokban többször előkerült az adatút gondolata. Ma egy olyan témát hoztam, ami elsőre talán technikai részletnek tűnik, de valójában az egyik legfontosabb stabilitási tényező: az adatrétegzés.

Sok rendszer ott kezd el instabillá válni, hogy minden adat „egy helyen” él. A nyers forrásadat, az előkészített adat és a riportot kiszolgáló struktúra nincs elkülönítve. Elsőre ez gyorsabbnak tűnik. Kevesebb objektum, kevesebb táblanév, egyszerűbb struktúra. Aztán jön az első változtatás – és elkezd borulni a dominó.

Vegyünk egy konkrét példát. Egy webshop rendelési adatait betöltjük a rendszerbe. A nyers (raw) réteg célja az, hogy az adatot változatlan formában megőrizzük. Itt még nincsenek számítások, nincsenek szűrések. Ez az „igazság pillanatképe”.

A curated rétegben kezdődik az értelmezés. Itt tisztítjuk az adatot, kiszűrjük a tesztrendeléseket, egységesítjük a pénznemeket, összekapcsoljuk az ügyféladatokkal. Ez már üzleti logikát tartalmaz, de még nem riportoptimalizált.

A reporting rétegben történik az optimalizálás. Itt már a cél a gyors lekérdezhetőség és az egységes definíciók kiszolgálása. Nem kísérletezünk, hanem stabilan szolgáljuk ki a riportokat.

Mi történik, ha ez a három réteg összemosódik? Egy apró változtatás – például egy új szűrés – azonnal érinti a riportot. Nincs visszalépési pont. Nem tudjuk megmondani, mi volt az eredeti adat. A hibák láncreakcióként terjednek.

A Microsoft Fabric architektúrája lehetőséget ad a tudatos rétegzésre, de nem kényszeríti ki. A döntés a miénk és ez már nem technikai kérdés, hanem kockázatkezelési döntés.

Elemzőként számomra a rétegzés nem „szép architektúra”, hanem biztosíték arra, hogy ha változtatunk, kontrolláltan tesszük. Ha hibázunk, vissza tudjuk követni. Ha vitás a szám, meg tudjuk mutatni az útját.

A rétegzés nem luxus, hanem az adatbizalom egyik alapfeltétele.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan

Szia, üdvözöllek a blogomon!

Egy adatplatform egyik legnagyobb dilemmája: hol helyezzük el az üzleti logikát?

A forrásrendszerben?
A transzformáció során?
A semantic model rétegben?
Vagy a riportban?

Vegyünk egy példát. A „nettó árbevétel” számításába bizonyos kedvezmények beleszámítanak, mások nem. Ha ezt a logikát a riportban implementáljuk, minden riportban újra kell írni. Ha a semantic modelben, egységes lesz. Ha túl korán, a raw rétegben döntünk, elveszítjük a rugalmasságot.

Itt nem technikai kérdésről van szó, hanem architektúra döntésről.

A Fabric lehetőséget ad több réteg használatára. A kérdés az, hogy tudatosan használjuk-e őket.

Elemzőként ez az a pont, ahol valódi értéket tudunk hozzáadni. Nem csak számolunk, hanem döntünk a számítás helyéről.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan

Szia, üdvözöllek a blogomon!

A legtöbb szervezetben a monitoring addig nem téma, amíg minden működik. Aztán jön egy hiba, és mindenki a riportot hibáztatja.

Pedig a kérdés nem az, hogy van-e riport. Hanem az, hogy látjuk-e, mi történik a háttérben.

Egy pipeline futás sikeres volt? Mennyi ideig tartott? Volt-e figyelmeztetés? Elcsúszott-e az ütemezés?

Monitoring nélkül az adatplatform vakrepülés.

A Fabric egyik erőssége, hogy a futások, pipeline lépések, státuszok láthatók. De a láthatóság nem egyenlő a tudatossággal. Ha senki nem nézi, nem értelmezi, nem reagál rá, akkor csak egy dashboard marad.

Elemzőként számomra a monitoring nem IT-feladat. Ez a rendszer egészségi állapotának figyelése. És ha komolyan vesszük az adatvezérelt döntést, akkor a rendszer működését is komolyan kell venni.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan

Szia, üdvözöllek a blogomon!

Az adatplatformok egyik legkevésbé látványos, mégis legkritikusabb kérdése a verziózás. Nem az, hogy elmentjük-e a fájlt, hanem hogy tudjuk-e, mi változott, mikor és miért.

Képzelj el egy helyzetet: egy KPI számítás módosul. Valaki finomít a logikán, mert „így pontosabb”. A riport frissül, a számok változnak. Az üzlet észreveszi, de senki nem kommunikálta a változást. A bizalom meginog.

A probléma nem technikai. A probléma a kontroll hiánya.

Egy érett rendszerben a változás:
– dokumentált
– visszakövethető
– indokolt
– és kommunikált

A Fabric környezetben a workspace-ek, a deployment logika és az objektumstruktúra lehetővé teszi, hogy a változások ne „észrevétlenül” történjenek. De a technológia önmagában nem oldja meg a fegyelmet.

Elemzőként itt jön be a felelősség. Nem elég, hogy működik a számítás. Azt is tudni kell, mikor és miért változott.

A verziózás nem adminisztratív teher, hanem bizalmi mechanizmus.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan

Szia, üdvözöllek a blogomon!

Az adatplatformok egyik legkevésbé látványos, mégis legkritikusabb része a jogosultsági rendszer. Erről ritkán beszélünk, mert nem „szexi” téma. Pedig itt dől el, hogy egy rendszer hosszú távon fenntartható-e.

Képzelj el egy helyzetet, ahol mindenki mindenhez hozzáfér. Elsőre kényelmesnek tűnik. Gyors. Nincs akadály. De idővel elmosódik a felelősség. Ki módosította az adatot? Ki törölte a táblát? Ki változtatta meg a definíciót?

A másik véglet az, amikor túl szigorú a rendszer, és minden apró változtatáshoz IT-jegy szükséges. Itt a rugalmasság sérül.

A Fabric egyik fontos erőssége, hogy a workspace és a szerepkörök révén strukturált jogosultsági modellt kínál. Ez nem csak biztonsági kérdés. Ez felelősségi modell.

Elemzőként ez azt jelenti, hogy nem csak adatot használok, hanem rendszerben gondolkodom. Tudnom kell, ki fér hozzá, ki módosíthat, ki publikálhat.

A jogosultság nem adminisztrációs részlet, hanem az adatbizalom alapja.

Köszönöm, hogy elolvastad! Legyen szép napod!

#MicrosoftFabric #100DaysOfLearning #DataAnalytics #BusinessAnalyst #TanulásNyilvánosan