Един завод измерва тегло на отпадъците на кантара. Друг завод го оценява въз основа на обема на контейнерите. Двата подават число за един и същ ред в отчета. Никой не е излъгал, никой не е направил грешка. Просто никога не е било документирано какво точно означава определението на тази точка от данни, така че всяко поделение е избрало най-логичното тълкуване, което е имало на разположение.
Това не е изключение. Това е нормалното състояние на организация, в която една и съща метрика се подава от различни екипи, с различни изходни системи и различна история. Въпросът не е как да премахнете тази разлика преди да възникне. Въпросът е какво правите с нея, когато я забележите.
Стъпката, която обикновено се пропуска, е самото определение да бъде записано някъде. Не в главата на контролера, който го прави така от години, а в регистър: тази точка от данни означава това, измерва се така и включва или не включва тези единици. Какво представлява валидна стойност в тези рамки и кой забелязва, ако подадена стойност излиза извън тях, е описано на страницата за какво е валидна стойност и кой забелязва, ако стойност излиза извън нея. Без това документиране всяко сумиране между поделения е сумиране на неща, които не са съвсем еднакви, опаковани в едно число, което изглежда сякаш е еднозначно.
Това документиране е точно работата на Data Readiness Scan: не пренаписване на отчета, а изграждане на регистър от точки от данни, в който за всяка точка от данни е записано какво представлява, откъде идва и кой отговаря за нея. Този регистър е мястото, където разликата между поделенията става видима, вместо да стане видима едва след като числото вече е сумирано.
Веднъж като видите, че поделение А и поделение Б разбират по различен начин една и съща точка от данни, има грубо три пътя.
Първият е хармонизиране: наложете едно определение за цялата организация, с всички системни промени, които това изисква. Това често е правилният път в дългосрочен план, но не е нещо, което се решава от днес за утре.
Вторият е документиране и коригиране: оставете отклонението там, където е, но запишете колко голямо е то и с фиксирано преизчисление се погрижете общата сума да е коректна. Това работи, когато разликата е стабилна и известна — например когато едно поделение системно използва друг метод на измерване, който може да се преизчисли.
Третият е сигнализиране: не коригиране, а поставяне на флаг, когато подаването се отклонява от модела, който сте свикнали да виждате от това поделение. Как се настройва такова сигнално отклонение и кой получава известие за него, е разработено на страницата за как настройвате сигнално отклонение и кой забелязва, когато се случи. Този път не е там за да реши проблема, а за да предотврати да остане незабелязан, докато работите към структурно решение.
Кой път е подходящ, зависи от колко поделения се отклоняват, колко стабилно е това отклонение и колко време има преди числото да влезе в отчетен период. Това е преценка, която се различава по организация и този регистър не я прави за вас — но прави видимо, че тя трябва да бъде направена.
Разликата в определенията е една от най-тихите грешки, защото всяко поделение е право поотделно. Поделението, което оценява по обем на контейнерите, не прави нищо погрешно в рамките на собствения си процес. Проблемът възниква едва на нивото, където числата се съединяват, и точно там често никой не е определен да проверява дали основните определения дори са съпоставими.
Затова собствеността по точка от данни е точно толкова важна, колкото самото определение. Какви проверки принадлежат на точка от данни и кой забелязва, когато една от тези проверки бъде пропусната, е описано на страницата за какви проверки принадлежат на точка от данни и кой забелязва, ако липсва такава. Без определен собственик въпросът „но кой всъщност вижда това" остава без отговор, дори когато определението стои на хартия.
Съблазнително е да искате да решите този проблем с система, която автоматично нормализира подадени данни. Но инструмент, поставен над съвкупност от недефинирани точки от данни, не нормализира нищо — той просто опакова същите различия в по-подреден интерфейс. Редът, който издържа, е първо да документирате определението и собствеността, и само след това да гледате какъв инструмент подхожда. Защо този ред не е случаен, е разработено на страницата за първо да купите инструмент или първо да изградите процеса.
Веднъж като бъде фиксирано за всяка точка от данни какво е определението, кой е собственик и какви отклонения се сигнализират, възниква друг вид въпрос: кой ще извършва работата, свързана с тези проверки — преизчисляването, обратната връзка с поделението, което се отклонява, поддържането на самия регистър. Част от тази работа е достатъчно повторяема за да бъде прехвърлена на автоматична стъпка, друга част изисква преценка, която остава при човек. Работният скенер на FTE TO AI изчислява за всяка задача каква част от нея може да бъде поета от AI, въз основа на същия вид конкретност като този регистър: не въпросът дали автоматизация е възможна, а каква част от коя задача се обхваща от нея.
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.