O fabrică cântărește greutatea deșeurilor pe cântarul-pod. O altă fabrică o estimează pe baza volumului containerului. Ambele livrează o cifră pentru aceeași linie din raport. Nimeni nu a mințit, nimeni nu a făcut o greșeală. Doar că nu s-a consemnat niciodată care este exact definiția acelui punct de date, așa că fiecare unitate a ales interpretarea cea mai logică pe care a avut-o la îndemână.
Aceasta nu este o excepție. Este starea normală a unei organizații în care aceeași metrică este furnizată de echipe diferite, cu sisteme sursă diferite și istorii diferite. Întrebarea nu este cum eliminați această diferență înainte ca ea să apară. Întrebarea este ce faceți cu ea în momentul în care o observați.
Pasul care de obicei este omis este ca definiția în sine să existe undeva. Nu în capul controlorului care o face așa de ani de zile, ci într-un registru: acest punct de date înseamnă asta, se măsoară așa, și include sau nu aceste unități. Ce reprezintă o valoare validă în acest cadru și cine observă atunci când o livrare se situează în afara acestuia sunt descrise pe pagina despre ce este o valoare validă și cine observă când o valoare se situează în afara acesteia. Fără această consemnare, fiecare adunare între unități este o adunare de lucruri care nu sunt chiar identice, ambalate într-o singură cifră care pare, la prima vedere, univocă.
Această consemnare este exact munca Data Readiness Scan: nu rescrierea raportului, ci construirea registrului de puncte de date în care, pentru fiecare punct de date, se indică ce este, de unde provine și cine își asumă responsabilitatea pentru el. Acest registru este locul în care diferența dintre unități devine vizibilă, în loc să devină vizibilă abia după ce cifra a fost deja adunată.
Odată ce observați că unitatea A și unitatea B înțeleg altceva prin același punct de date, există în mare trei căi.
Prima este armonizarea: impunerea unei singure definiții pentru întreaga organizație, cu toate adaptările de sistem care decurg din asta. Aceasta este de obicei calea corectă pe termen lung, dar nu este ceva ce se poate finaliza de la o zi la alta.
A doua este documentarea și corectarea: lăsarea abaterii acolo unde se află, dar consemnarea mărimii ei și asigurarea, printr-o conversie fixă, că totalul este totuși corect. Aceasta funcționează atunci când diferența este stabilă și cunoscută — de exemplu atunci când o unitate folosește structural o altă metodă de măsurare care poate fi urmărită și reconstituită.
A treia este semnalizarea: nu corectarea, ci ridicarea unui semnal de îndată ce o livrare se abate de la modelul la care sunteți obișnuiți din partea acelei unități. Cum configurați o astfel de abatere semnalizată și cine primește o notificare despre ea sunt detaliate pe pagina despre cum configurați o abatere semnalizată și cine observă când se produce. Această cale nu servește la rezolvarea problemei, ci la a preveni ca aceasta să rămână neobservată în timp ce lucrați către o soluție structurală.
Care cale este potrivită depinde de câte unități se abat, cât de stabilă este acea abatere și câtă vreme mai este până când cifra intră într-o perioadă de raportare. Aceasta este o evaluare care diferă de la o organizație la alta și pe care acest registru nu o face în locul dvs. — dar face vizibil faptul că evaluarea trebuie făcută.
Diferența de definiție este una dintre cele mai tăcute erori care există, pentru că fiecare unitate, luată separat, are dreptate. Unitatea care estimează pe baza volumului containerului nu face nimic greșit în cadrul propriului proces. Problema apare abia la nivelul la care cifrele se adună, și tocmai acolo, de multe ori, nimeni nu este desemnat să verifice dacă definițiile de bază sunt măcar comparabile.
Acesta este motivul pentru care proprietatea asupra fiecărui punct de date este la fel de importantă ca definiția în sine. Ce verificări sunt asociate unui punct de date și cine observă atunci când una dintre aceste verificări este omisă sunt descrise pe pagina despre ce verificări sunt asociate unui punct de date și cine observă când una lipsește. Fără un proprietar desemnat, întrebarea „dar cine observă de fapt asta” rămâne fără răspuns, chiar dacă definiția este consemnată pe hârtie.
Este tentant să vrei să rezolvi această problemă cu un sistem care normalizează automat livrările. Dar un instrument plasat peste o colecție de puncte de date nedefinite nu normalizează nimic — ambalează aceleași diferențe într-o interfață mai îngrijită. Ordinea care rezistă este întâi consemnarea definiției și a proprietății, și abia apoi analizarea sistemului care se potrivește cu asta. De ce această ordine nu este întâmplătoare este detaliat pe pagina despre întâi cumpărați un instrument sau întâi organizați procesul.
Odată ce pentru fiecare punct de date este stabilit care este definiția, cine este proprietarul și care abateri sunt semnalizate, apare un alt tip de întrebare: cine va efectua, de acum înainte, munca aferentă acestor verificări — recalcularea, interogarea unității care se abate, ținerea la zi a registrului însuși. O parte din această muncă este suficient de repetabilă pentru a fi transferată unui pas automatizat, o altă parte necesită o evaluare care rămâne la un om. Scanul de muncă al FTE TO AI calculează, pe sarcină, ce parte din aceasta poate fi preluată de AI, pe baza aceluiași tip de concretețe ca acest registru: nu întrebarea dacă automatizarea este posibilă, ci ce parte din ce sarcină se încadrează în ea.
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.