Egy táblázat, amely az energiafogyasztást tartalmazza telephelyenként, önmagában nem probléma. A probléma a következő lépésben keletkezik: hogyan vonják össze ezeket a sorokat azzá a számmá, amely a jelentésben szerepel. Ez a lépés gyakran egy formulában, egy pivot táblában, vagy - rosszabb esetben - annak a személynek a fejében történik, aki évente frissíti a táblázatot. Senki más nem tudja pontosan, mely sorok kerültek bele, melyek maradtak ki, és miért.
Az aggregálás számolásnak hangzik, de valójában egy sor választás. Beleszámítja azokat a telephelyeket, amelyek az év egy részében zárva voltak? Figyelembe veszi a bérelt helyszíneket, vagy csak a tulajdonban lévőket? Naptári évvel vagy üzleti évvel számol? Minden választás megváltoztatja a végső számot, és egy táblázatban ezek a választások általában nincsenek külön rögzítve. Egy formulába vannak beépítve, amely cellákra hivatkozik, anélkül hogy lenne egy olvasható sor, amely azt mondja: ez az aggregációs szabály, és ezért van így.
Amint valaki átveszi a táblázatot, vagy amint egy controller egy évvel később egy hasonló számot próbál reprodukálni, ez a magyarázat hiányzik. A formula még működik, de senki nem tudja már megítélni, hogy még helyes-e az idei helyzetre nézve.
A táblázatban lévő nyers sor és a jelentésben szereplő szám között általában több lépés van: a releváns sorok kiválasztása, átszámítás egy egységre, összeadás vagy súlyozott átlag, és néha egy korrekció a hiányzó hónapok vagy telephelyek miatt. Minden lépésnek lehet saját szabálya, és minden szabály megváltozhat anélkül, hogy ez bárhol rögzítve lenne.
Az a kérdés, amely ekkor számít: ha egy controller megkérdezi, hogyan épült fel ez a szám, meg tudja mutatni egyenként a lépéseket? Nem az eredményt visszafejtve, visszafelé haladva a formulán, hanem magukat a szabályokat megmutatva.
Egy aggregációs szabály, amely csak egy formulában létezik, nem ellenőrizhető és nem átadható. A rögzítés azt jelenti: a táblázattól függetlenül feljegyezni, milyen aggregációt alkalmaztak, milyen kiválasztáson, milyen kivételekkel, és ki állította fel ezt a szabályt. Ez nem egy külön dokumentum a táblázat mellett, ez az a magyarázat, amely a táblázatot egyáltalán használhatóvá teszi forrásként egy jelentéspont számára.
Ennek a magyarázatnak a hiányában egy aggregációs szabály észrevétlenül megváltozik. Valaki hozzáad egy telephelyet a listához, módosítja a formulát, és az idei szám már nem hasonlítható össze a tavalyi számmal. Nem azért, mert a mögöttes adatok megváltoztak, hanem azért, mert az összeadás módja csendben megváltozott.
Az aggregáció egyike azoknak a helyeknek, ahol a táblázatok aggregációs hibákat rejtenek, de nem az egyetlen. Hasonló kérdések vonatkoznak az egységekre és a definíciókra: lásd hogyan rögzíti a normalizálást, ha a forrás egy táblázat azt a lépést, amely gyakran az aggregáció előtt következik. És a nyers sortól a jelentésbeli számig vezető teljes út feltérképezéséhez, akár specializált szoftver nélkül is, létezik hogyan hoz létre lineage-t eszköz nélkül, ha a forrás egy táblázat. Mindkettő kapcsolódik a szélesebb kérdéshez, hogy mit jelent pontosan a source-to-report mapping, amelyben az aggregáció egyike a dokumentált lépéseknek.
Egy aggregációs szabálynak, éppúgy mint egy adatpontnak, szüksége van valakire, aki felelős a mögötte álló választásért. Nem az, aki éppen megírta a formulát, hanem az, aki el tudja magyarázni, miért ezt a kiválasztást és ezt a számítási módot választották, és aki jóváhagy egy módosítást, mielőtt azt bevezetik. Ez a kérdés összefügg azzal, hogy ki a tulajdonosa egy adatpont definíciójának: a definíció határozza meg, mit mérnek, az aggregációs szabály határozza meg, hogyan vonják össze a méréseket egy jelentésbeli számmá. Mindkettő egy néven nevezhető személyhez tartozik, nem egy kézről kézre járó táblázathoz.
Az aggregációs szabályok rögzítése nem egyszeri gyakorlat. Ez egy kérdés, amely mindig visszatér, amint a szervezet megváltozik: egy új telephely, egy új egység, egy fúzió. Ezért nem elég ezúttal dokumentálni; kell lennie egy folyamatnak, amely a rögzítést minden változásnál megismétli. Ki felügyeli ezt a folyamatot, és mikor kerül felülvizsgálatra egy aggregációs szabály, ez egy kérdés, amely kapcsolódik ahhoz, hogy ki a tulajdonosa az alatta lévő folyamatnak, függetlenül attól, ki szolgáltatja az egyedi számokat.
Ez az oldal leírja, mi szükséges az aggregáció átláthatóvá tételéhez. A Data Readiness Scan az az eszköz, amely segít ezt rögzíteni az Ön adatpontjai számára: a nyilvántartást, a forrástól a jelentésig tartó lineage-t pontonként, és a tulajdonjogi szabályokat. Ez az eszköz jelenleg épül. Aki már most szeretné ezzel elkezdeni, feliratkozhat a várólistára.
Amint az aggregációs szabályok rögzítve vannak, egy tulajdonossal és egy okkal, egy másfajta munka keletkezik: ugyanazoknak a lépéseknek a kivitelezése és ellenőrzése, évről évre. Sok ilyen kivitelező munka, a sorok kiválasztásától a számok egy fix szabály szerinti összeadásáig, olyan feladat, amelynél az FTE TO AI munkaszkennerével kiszámítható, mekkora rész vehető át AI-val, feladatonként, azon alapulva, mi pontosan a munka tartalma.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.