Каква проверка съответства на тази точка от данни, и кой вижда, когато стойността се отклонява

Точка от данни без проверка е число, което никой не поставя под въпрос. То стои в отчета, идва от система или таблица, и се приема, защото няма повод да бъде поставено под въпрос. Едва когато външна страна зададе въпрос, или когато число внезапно се промени с фактор десет спрямо предходната година, се забелязва, че никой никога не го е погледнал. Тогава е късно да се възстанови къде е сгрешено.

Въпросът, който предотвратява това, е лесен за задаване и труден за отговор без структура: каква проверка съответства на тази точка от данни, и кой забелязва, когато нещо се обърка. Това са два въпроса, и на двата трябва да има отговор, преди число да влезе в отчет.

Какво е валидна стойност, и какво не е

Всяка точка от данни има граници. Енергийно потребление не може да бъде отрицателно. Броят на служителите (fte) не е дробно число. Процент не надвишава сто. Това изглежда очевидно, но на практика такива граници никъде не са записани — те се пазят в главата на човека, който от години обработва данните, и изчезват веднага щом този човек смени длъжността си.

Запис на валидна стойност означава не само отбелязване на долна и горна граница. Означава също така да се определи в каква единица се предоставя точка от данни, какви формати на дата са допустими, и дали празно поле е валиден резултат или знак, че нещо липсва. Без тази договорка всяко изключение се преценява отново, от когото се случи да го гледа в момента. Какво точно се брои за валидно, и кога граничната стойност е по-скоро предположение, отколкото правило, е разгледано на страницата за какво е валидна стойност.

Разликата между грешка и сигнал

Не всяко отклонение е грешка. Точка от данни може да бъде напълно в рамките на валидните граници и все пак да бъде сигнал — потребление, което внезапно спада, брой, който е три пъти по-висок от предходното тримесечие, доставчик, който за първи път от две години не предоставя данни. Това не са невалидни стойности. Това са стойности, които изискват поглед от някого, който познава контекста.

Правило за сигнал е следователно нещо различно от правило за валидиране. Валидирането определя дали стойност може да съществува. Сигналът определя дали стойност, макар и валидна, все пак е причина да се погледне. Как се задава този праг — фиксиран процент отклонение, сравнение с исторически ред, или комбинация — зависи от точката от данни и от това колко стабилна е обичайно съответната дейност. Изграждането на такова правило, включително компромисът между твърде много и твърде малко сигнали, е описано на страницата за задаване на отклонение за сигнал.

Кой го забелязва, не е технически въпрос

Правило, което никой не вижда, не е правило. Ако проверка за валидиране или сигнал се задейства някъде в система, трябва да е ясно кой получава известието и какво прави тази личност с него. Дали е лицето, което въвежда данните, собственикът на точката от данни, или някой, който има общ поглед, преди отчетът да бъде съставен? Без определен получател сигнал изчезва в дневник, който никой не преглежда.

Това засяга собствеността, а собствеността засяга проблем, който в много организации остава нерешен: различни звена използват различни определения за онова, което на хартия е една и съща точка от данни. Едно поделение брои fte, включително наети чрез агенция, друго не. Когато се задейства сигнал, че стойност се отклонява, първият въпрос често не е дали стойността е правилна, а дали всички имат едно и също определение. Как да се справите с това, е описано на страницата за различни определения между звената.

Защо това не започва с инструмент

Изкушаващо е да се търсят тези проверки в софтуерен пакет: нещо, което автоматично предупреждава, валидира и отчита. Но инструмент, който извършва проверки върху данни, за които никой не е определил какво е валидна стойност, не извършва проверка — той само дава резултат, който изглежда подреден, за процес, който все още не е обмислен. Правилата трябва да съществуват първо, независимо от каква система накрая ги прилага. Тази последователност, и защо обръщането й обикновено води до разочарование, е обяснена на страницата за първо купуване на инструмент или първо изграждане на процеса.

Какво дава това, преди да се построи каквото и да е

Ако за всяка точка от данни е определено какво е валидна стойност, кога се задейства сигнал, и кой получава този сигнал, се получава регистър, който не само документира, но и е използваем като пакет от изисквания. Този регистър е точно това, което е необходимо, за да се определи какво трябва да може система — изградена вътрешно или закупена — впоследствие. Без този пакет от изисквания всяка покупка се превръща в залагане. Как да преведете това във функционални изисквания, произлизащи от собствения ви процес, а не от доставчик, е описано на страницата за функционални изисквания от собствения ви процес.