A szokásos sorrend a következő: kiválasztanak egy eszközt, beállítják az eszközt, majd azt remélik, hogy a folyamat majd igazodik hozzá. Ez a gyakorlatban nem működik, mert egy eszköz nem hoz magával folyamatot. Egy eszköz mezőket hoz magával, integrációkat, irányítópultokat — de nem azt a kérdést, hogy ki felelős a szervezetében a hármas számú épület energiafogyasztásáért, vagy hogy a létesítménygazdálkodási vezető, aki ezt a számot szolgáltatja, tudja-e, hogy az a scope 2 jelentésben fog végezni.
A helyes sorrend fordított: először a folyamatot kell leírni, csak azután lehet eszközt választani annak alapján, amire a folyamatnak szüksége van. Ez kerülőútnak hangzik, de valójában a legrövidebb út, mert minden funkcionális elvárásnak, amelyet egy eszközzel szemben megfogalmaz, valahonnan a saját adatszervezetéből kell erednie. Ez a kiindulópont nélkül olyan funkciók alapján választ, amelyeket egy szolgáltató fontosnak tart, nem olyanok alapján, amelyek az Ön szűk keresztmetszetét oldják meg.
A rossz sorrend költségei nem azonnal láthatók, mert egy eszköz, amely nem illik a folyamathoz, kezdetben tökéletesen működik — a folyamat azon részére, amely véletlenül megfelel annak, amit az eszköz elvár. A többit manuálisan építik köré: itt egy Excel-melléklet, ott egy e-mail-váltás, egy munkatárs, aki pontosan tudja, melyik lépés esik éppen a rendszeren kívül. Ez működik, amíg az a munkatárs el nem megy, vagy az adatmennyiség nem növekszik.
Az, mennyibe kerül, attól függ, hány adatpont fut az eszközön kívül, és milyen gyakran kell azokat jelentési ciklusonként újra manuálisan összegyűjteni. Kis számú pont esetén ez elfogadható kerülőút. Növekvő számú pont esetén — több telephely, több scope 3 kategória, több csatlakozó jogszabály — a kerülőút lesz a fő útvonal, és Ön strukturálisan fizet az eszköz és a folyamat közötti eltérésért. Ez egy másik módja annak kifejezésére, amit ezen az oldalon is olvashat: egy eszköz egy rendezetlen folyamat felett rendezettebb kimutatásokat készít ugyanazokból a megbízhatatlan számokból.
Egy funkcionális elvárás csak akkor elvárás, ha valahonnan ered. „Az eszköznek tudnia kell megjeleníteni a lineage-t” nem elvárás, amíg nem tudja, hogy a controllere évente háromszor manuálisan kell kiderítse, honnan származik egy szám. „Az eszköznek tudnia kell rögzíteni a tulajdonjogot” nem elvárás, amíg nem látta, hogy egy tulajdonos nélküli adatpont senki teendőlistáján nem szerepel.
Ez pontosan az oka, hogy az adatpont-regiszternek, az egyes adatpontokra vonatkozó source-to-report lineage-nek, és a tulajdonjog-kiosztásnak előbb kell léteznie, függetlenül attól, melyik eszközt választja végül. Amint ez a három dolog papíron áll — melyik adatpont, honnan származik, ki felel érte — olyan elvárás-listával rendelkezik, amely nem egy szolgáltatótól, hanem a saját szervezetétől ered. Ezt a listát az eszközök összehasonlítására használja, nem arra, hogy vakon kiválasszon közülük egyet. Hogy hogyan végezze el ezt az összehasonlítást megbánás nélkül, azt ez az eszközválasztásról szóló oldal írja le.
Az, hogy hol találhatók az adatok, ágazatonként erősen különbözik, és ez határozza meg azt is, mely funkcionális elvárások relevánsak. Egy építőipari vállalatnál a fenntarthatósági adatok nagy része alvállalkozóknál és magán az építkezésen található, amint az ezen az építőipari adatforrásokról szóló oldalon le van írva; ott egy több külső forrásra vonatkozó elvárás projektenként valószínűleg fontosabb, mint más ágazatokban. Az installációs ágazatban az adatok gyakrabban oszlanak el szervizlapokon és projekt szintű anyagregisztrációkon, amint az ezen, az installációs ágazatról szóló oldalon olvasható; ott elsősorban az számít, hogy egy eszköz össze tudja-e vonni a szórt beviteli pontokat anélkül, hogy valakinek ezt manuálisan kellene elvégeznie.
Az általános kérdést — először a folyamatot rendezni be, vagy először eszközt vásárolni — ezen az oldalon fejtik ki tovább, és ennek az oldalnak a fő kérdése, hogy pontosan mely elvárások erednek a saját folyamatából, ezen az oldalon van összefoglalva. Mindkét oldal ugyanabból a pontból indul ki: a sorrend határozza meg, hogy egy elvárás valóban elvárás, vagy csak találgatás.
A Data Readiness Scan rögzíti az adatpont-regisztert, a lineage-t és a tulajdonjogot, még mielőtt szó lenne egy eszközről. Ez nem jelentéskészítő eszköz és nem kérdőív-megoldás — ez az a lépés, amely meghatározza, mit kell valójában tudnia egy eszköznek az Ön szervezete számára. E lépés nélkül funkciókat vásárol; e lépéssel megoldást vásárol egy olyan problémára, amelyet meg tud mutatni.
A szkenner fejlesztés alatt áll. Aki szeretné ily módon feltérképeztetni a folyamatát, mielőtt eszközválasztásra kerülne sor, feliratkozhat a várólistára, és értesítést kap, amint a szkenner elérhetővé válik.
Amint az adatpont-regiszter elkészült, és egyértelmű, mely adatpont mely forrásból származik és ki felelős érte, egy második, természetes kérdés merül fel: az ezt körülvevő munka mekkora része — az adatok összegyűjtése, ellenőrzése és átvezetése — még emberi munka, és mekkora rész vehető át egy rendszer által anélkül, hogy a megbízhatóság csökkenne. Erre a kérdésre válaszol a FTE TO AI munkaszkennere, amely feladatonként kiszámítja, mekkora rész vehető át az AI által. Ez egy másik szkenner, mint a Data Readiness Scan, és annak logikus folytatása: először tudni kell, mi az adat és honnan származik, csak azután érdemes megnézni, a körülötte lévő manuális munka mekkora része válhat feleslegessé.
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.