Jaká kontrola patří k tomuto datovému bodu a kdo to zjistí, pokud se hodnota odchýlí

Datový bod bez kontroly je číslo, kterému nikdo neodporuje. Je uvedeno ve zprávě, pochází ze systému nebo z tabulky a je přijato, protože není důvod ho zpochybňovat. Až když externí strana vznese otázku, nebo když se číslo náhle liší desetinásobně oproti loňskému roku, vyjde najevo, že se na něj nikdy nikdo nedíval. Tehdy už je pozdě rekonstruovat, kde se stala chyba.

Otázka, která tomu předchází, je snadné položit a bez struktury obtížné zodpovědět: jaká kontrola patří k tomuto datovému bodu a kdo si všimne, když se něco pokazí. Jsou to dvě otázky, a obě by měly mít odpověď dříve, než se číslo dostane do zprávy.

Co je platná hodnota, a co není

Každý datový bod má hranice. Spotřeba energie nemůže být záporná. Počet fte není desetinné číslo. Procento nepřekročí sto. To se zdá samozřejmé, ale v praxi tyto hranice nikde nejsou zaznamenány — jsou v hlavě osoby, která data zpracovává už léta, a zmizí, jakmile tato osoba změní pozici.

Zaznamenat platnou hodnotu neznamená jen zapsat spodní a horní hranici. Znamená to také zaznamenat, v jaké jednotce se datový bod dodává, jaké formáty data jsou povolené, a zda je prázdné pole platným výsledkem nebo znamením, že něco chybí. Bez této dohody se každá výjimka posuzuje znovu, podle toho, kdo se na ni v tu chvíli náhodou dívá. Co přesně se počítá jako platné, a kdy je mezní hodnota spíše předpokladem než pravidlem, je rozebráno na stránce o tom, co je platná hodnota.

Rozdíl mezi chybou a signálem

Ne každá odchylka je chyba. Datový bod může zcela odpovídat platným hranicím a přesto být signálem — spotřeba, která náhle klesne, počet, který je třikrát vyšší než v minulém čtvrtletí, dodavatel, který poprvé za dva roky nedodá data. Nejsou to neplatné hodnoty. Jsou to hodnoty, které si zaslouží pohled někoho, kdo znám kontext.

Signální pravidlo je tedy něco jiného než validační pravidlo. Validace určuje, zda hodnota může existovat. Signál určuje, zda je hodnota, i když je platná, přesto důvodem k prověření. Jak se taková hranice nastavuje — pevné procento odchylky, srovnání s historickou řadou, nebo kombinace — závisí na datovém bodu a na tom, jak stabilní je za normálních okolností podkladová činnost. Nastavení takového pravidla, včetně zvážení mezi příliš mnoha a příliš málo signály, je popsáno na stránce o nastavení signální odchylky.

Kdo si toho všimne, není technická otázka

Pravidlo, které nikdo nevidí, není pravidlo. Pokud se někde v systému spustí validační nebo signální kontrola, musí být jasné, kdo obdrží upozornění a co s ním daná osoba udělá. Je to osoba, která data zadává, vlastník datového bodu, nebo někdo, kdo má přehled nad celkem před sestavením zprávy? Bez určeného příjemce signál zmizí v protokolu, který nikdo nekonzultuje.

Toto se dotýká vlastnictví, a vlastnictví se dotýká problému, který v mnoha organizacích zůstává nevyřešen: různé části organizace používají odlišné definice pro to, co je na papíře stejný datový bod. Jedna pobočka počítá fte včetně externích pracovníků, druhá ne. Když se spustí signál, že se hodnota odchyluje, první otázka často není, zda je hodnota správná, ale zda všichni mají na mysli stejnou definici. Jak s tím naložit, je popsáno na stránce o odlišných definicích mezi jednotlivými částmi organizace.

Proč to nezačíná nástrojem

Je lákavé hledat tyto kontroly v softwarovém balíku: něco, co automaticky upozorní, ověří a vykáže. Ale nástroj, který provádí kontroly na datech, u kterých nikdo nezaznamenal, co je platná hodnota, žádnou kontrolu neprovádí — dává jen na první pohled solidní výsledek o procesu, který ještě nebyl promyšlen. Pravidla musí existovat nejprve, bez ohledu na to, jaký systém je nakonec použije. Toto pořadí, a proč jeho obrácení obvykle vede ke zklamání, je vysvětleno na stránce o tom, zda nejprve koupit nástroj nebo nejprve zavést proces.

Co to přinese ještě před tím, než se něco postaví

Když je pro každý datový bod zaznamenáno, co je platná hodnota, kdy se spustí signál, a kdo tento signál obdrží, vznikne rejstřík, který nejen dokumentuje, ale je také použitelný jako soupis požadavků. Tento rejstřík je přesně to, co je potřeba k určení, co má systém — vytvořený vlastními silami nebo nakoupený — v budoucnu umět. Bez tohoto soupisu požadavků se každá koupě stává sázkou do loterie. Jak to převést na funkční požadavky, které vycházejí z vašeho vlastního procesu, a nikoli od dodavatele, je popsáno na stránce o funkčních požadavcích z vašeho vlastního procesu.