Egy jelentési kötelezettség felbukkan, és az első reakció egy eszköz keresése. Egy dashboard, egy platform, egy modul a meglévő szoftverhez. Ez haladásnak érződik: megjelenik valami új, pénzt költenek rá, van egy leverancier, akivel lehet egyeztetni.
A kérdés, amit átugranak, az, hogy honnan szerzi az eszköz a számait. Egy eszköz számol, vizualizál és jelent, de nem talál ki semmit. Az adat, ami belemegy, ugyanazokból a spreadsheetekből, ugyanazokból az e-mailekből a facility managernek, ugyanazokból a becslésekből származik, amik már korábban is léteztek. Csak az adat most egy olyan felület mögé kerül, amely áttekinthetőnek néz ki.
Egy eszköz kiválasztása mielőtt tudná, milyen adata van, ki felel érte és mennyire megbízható, azt jelenti, hogy az eszközt feltételezés alapján választja ki. A leverancier megkérdezi, milyen funkcionalitásra van szükség, és Ön arra válaszol, amit gondol, hogy megvan — nem arra alapozva, hogy valójában milyen adatpontok, források és tulajdonosok léteznek. Melyek a funkcionális követelmények, amelyek a saját folyamatából adódnak egy olyan kérdés, amelyre csak akkor lehet válaszolni, ha a folyamat már megvan; ez az alap nélkül az eszközt egy olyan követelménylista alapján választják ki, amelyet valaki más állított össze, vagy amely utólag kiderül, hogy pont azt hiányolja, amire szükség volt.
A fordított sorrend — először az adatpont-nyilvántartást, a lineage-t és a tulajdonjogot rendezni, majd csak azután eszközt választani — az elején több időt vesz igénybe. Nincs dashboard, amire rá lehetne mutatni, nincs olyan előrehaladás, amit egy megbeszélésen bemutatni lehetne. De az utána egy eszközhöz feltett kérdések olyan kérdések, amelyek azon alapulnak, amit valóban történik a vállalatban, nem egy olyan listán, amelyet egy demóból vettek át.
Az eszköz-elsőbb sorrend költségeit nem lehet egy tételbe belefoglalni, de felismerhetők.
Ott van az eszköz maga, amelyről egy év után kiderül, hogy nem azt tudja, amire szükség volt — egy kapcsolat egy forrásrendszerrel, amely nincs, egy jelentési struktúra, amely nem illik ahhoz, ahogy az organizáció működik, egy modul, amely olyasmit tesz, amire senkinek nem volt szüksége. Ott van azoknak az embereknek az ideje, akiknek az eszközt fel kellett tölteniük: ha az adatpont-nyilvántartás nem létezett, az eszköz ugyanazokkal a különálló Excel-exportokkal lett feltöltve, mint korábban, csak most egy olyan rendszeren belül, amely azt sugallja, hogy ellenőrzött.
És ott van a látszatbiztonság, amely a legdrágább. Egy eszköz egy meggyőző dashboarddal azt az érzést adja, hogy az adat rendben van. Ez az érzés kitart egészen egy assurance-folyamatig, egy auditorig vagy a felügyelőbizottság kérdéséig egy szám eredetéről. Akkor kiderül, hogy senki nem tudja megmondani, ki szolgáltatta a forrást, milyen feltételezés van beépítve, vagy hogy az idei szám ugyanúgy lett-e kiszámítva, mint a tavalyi. Az eszköz ezt nem tudta, mert az eszköz soha nem tette fel ezt a kérdést — feltételezte azt, amit beírtak.
És ott van a lecserélés. Egy eszközt, amelyet a mögötte lévő folyamat áttekintése nélkül választottak, egy idő után egy másik eszközre cserélik, azzal a reménnyel, hogy az jobban teljesít. A probléma áthelyezkedik, de nem tűnik el: először eszközt vásárolni vagy előbb a folyamatot berendezni pontosan az a döntés, amely minden csere alkalmával újra felmerül, és amely a folyamati oldalra adott válasz hiányában újra ugyanúgy rosszul sül el.
Az, hogy mennyire súlyosan nyomja a rossz sorrend, attól függ, hol keletkezik az adat. Egy építőipari vállalatnál a fenntarthatósági adat nagy része alvállalkozóknál, az építkezésen és olyan projektadminisztrációkban van, amelyek nem jelentés céljára készültek — honnan származik a fenntarthatósági adat az építőiparban meghatározza, milyen kapcsolatokra van valójában szükség egy eszköznek. Az installációs ágazatban az adat szolgáltatási jegyeken, materiálregisztrációkon és karbantartási szerződéseken szétszórtan található, és hol van a fenntarthatósági adat az installációs ágazatban megmutatja, hogy egy generikus eszköz, amelyet egy irodai organizáció számára építettek, itt gyorsan elégtelennek bizonyul. Egy eszköz, amely nem ismeri ezeket a különbségeket, nem is tudja megoldani azokat — bármilyen jó is a felület. Aki mégis inkább előbb eszközt választana, jól teszi, ha elolvassa hogyan válasszon eszközt utólagos megbánás nélkül, bár a lényeg ugyanaz marad: egy eszköz nem old meg egy folyamatot, amely nem létezik.
A megmaradó sorrend nem bonyolult, de kevésbé vonzó felkínálni: először rögzíteni, milyen adatpontok léteznek, honnan származnak, ki felel értük és milyen minőségi szabályok tartoznak hozzájuk. Ez az a munka, amelyre a CSRDready.net Data Readiness Scanját létrehozták — egy adatpont-nyilvántartás, source-to-report lineage adatpontonként, tulajdonjog és minőségi szabályok, anélkül, hogy már eszköz vagy jelentésforma tartozna hozzá. Az eszköz épülőben van; aki most már ezzel szeretne dolgozni, feliratkozhat a várólistára.
Ha az adatpont-nyilvántartás egyszer megvan, akkor még marad egy kérdés, amelyet nem egy szoftver-leverenciernek kell feltenni: mennyi ebből a munkából — az ugyanazon adatpontok gyűjtése, ellenőrzése és megismétlése — maradjon emberi munka, és mekkora rész vehető át. Ezért készült a FTE TO AI munkaszkennere: az minden feladatnál kiszámítja, hogy a munka mekkora része vehető át AI által, a feladatok alapján, ahogyan azokat valójában végzik az Ön organizációjában.
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.