csrdready Auf die Warteliste setzen

Kennisbank

Welche Kontrolle gehört zu diesem Datenpunkt, und wer sieht es, wenn der Wert abweicht

Ein Datenpunkt ohne Kontrolle ist eine Zahl, der niemand widerspricht. Sie steht im Bericht, sie kommt aus einem System oder einer Tabelle, und sie wird akzeptiert, weil es keinen Anlass gibt, sie zu hinterfragen. Erst wenn eine externe Partei eine Frage stellt, oder wenn eine Zahl plötzlich um den Faktor zehn gegenüber dem Vorjahr abweicht, fällt auf, dass sich nie jemand damit befasst hat. Dann ist es zu spät, um noch zu rekonstruieren, wo es schiefging.

Die Frage, die dies verhindert, ist einfach zu stellen und schwer zu beantworten ohne Struktur: welche Kontrolle gehört zu diesem Datenpunkt, und wer merkt es, wenn es schiefgeht. Das sind zwei Fragen, und beide sollten beantwortet sein, bevor eine Zahl in einen Bericht eingeht.

Was ein gültiger Wert ist, und was nicht

Jeder Datenpunkt hat Grenzen. Ein Energieverbrauch kann nicht negativ sein. Eine Anzahl an fte ist keine Dezimalzahl. Ein Prozentsatz kommt nicht über hundert. Das erscheint selbstverständlich, aber in der Praxis sind solche Grenzen nirgendwo festgelegt — sie stecken im Kopf derjenigen Person, die die Daten schon jahrelang verarbeitet, und verschwinden, sobald diese Person die Funktion wechselt.

Einen gültigen Wert festzulegen bedeutet nicht nur, eine Unter- und eine Obergrenze zu notieren. Es bedeutet auch festzulegen, in welcher Einheit ein Datenpunkt geliefert wird, welche Datumsformate zulässig sind, und ob ein leeres Feld ein gültiges Ergebnis ist oder ein Zeichen dafür, dass etwas fehlt. Ohne diese Abstimmung wird jede Ausnahme erneut beurteilt, von wem gerade zufällig hinschaut. Was dabei genau als gültig zählt, und wann ein Grenzwert eher eine Annahme als eine Regel ist, ist ausgeführt auf der Seite über einen gültigen Wert.

Der Unterschied zwischen einem Fehler und einem Signal

Nicht jede Abweichung ist ein Fehler. Ein Datenpunkt kann vollständig innerhalb der gültigen Grenzen liegen und trotzdem ein Signal sein — ein Verbrauch, der plötzlich sinkt, eine Anzahl, die dreimal so hoch ist wie im vorigen Quartal, ein Lieferant, der zum ersten Mal seit zwei Jahren keine Daten liefert. Das sind keine ungültigen Werte. Es sind Werte, die einen Blick von jemandem erfordern, der den Kontext kennt.

Eine Signalregel ist also etwas anderes als eine Validierungsregel. Validierung bestimmt, ob ein Wert existieren kann. Ein Signal bestimmt, ob ein Wert, auch wenn er gültig ist, trotzdem ein Anlass ist, hinzuschauen. Wie diese Schwelle eingestellt wird — fester Prozentsatz der Abweichung, Vergleich mit einer historischen Reihe, oder eine Kombination — hängt vom Datenpunkt und davon ab, wie stabil die zugrunde liegende Aktivität normalerweise ist. Der Aufbau einer solchen Regel, einschließlich der Abwägung zwischen zu vielen und zu wenigen Signalen, ist beschrieben auf der Seite über das Einstellen einer Signalabweichung.

Wer es bemerkt, ist keine technische Frage

Eine Regel, die niemand sieht, ist keine Regel. Wenn eine Validierungs- oder Signalprüfung irgendwo in einem System auslöst, muss feststehen, wer die Meldung erhält und was diese Person damit tut. Ist es die Person, die die Daten eingibt, der Eigentümer des Datenpunkts, oder jemand, der das Ganze überblickt, bevor der Bericht zusammengestellt wird? Ohne einen festgelegten Empfänger verschwindet ein Signal in einem Protokoll, das niemand einsieht.

Das berührt Eigentümerschaft, und Eigentümerschaft berührt ein Problem, das in vielen Organisationen ungelöst bleibt: verschiedene Einheiten verwenden unterschiedliche Definitionen für das, was auf dem Papier derselbe Datenpunkt ist. Der eine Standort zählt fte inklusive Fremdpersonal, der andere nicht. Wenn ein Signal auslöst, dass ein Wert abweicht, ist die erste Frage oft nicht, ob der Wert stimmt, sondern ob alle von derselben Definition ausgehen. Wie Sie damit umgehen, steht auf der Seite über unterschiedliche Definitionen zwischen Einheiten.

Warum dies nicht mit einem Tool beginnt

Es ist verlockend, diese Kontrollen in einem Softwarepaket zu suchen: etwas, das automatisch warnt, validiert und berichtet. Aber ein Tool, das Kontrollen auf Daten ausführt, für die niemand festgelegt hat, was ein gültiger Wert ist, führt keine Kontrolle aus — es liefert nur ein ordentlich aussehendes Ergebnis über einen Prozess, der noch immer nicht durchdacht ist. Die Regeln müssen zuerst vorhanden sein, unabhängig davon, welches System sie letztlich anwendet. Diese Reihenfolge, und warum sie umzudrehen meist zu Enttäuschung führt, ist erläutert auf der Seite über zuerst ein Tool kaufen oder zuerst den Prozess einrichten.

Was dies bereits liefert, bevor etwas gebaut wird

Wenn für jeden Datenpunkt festliegt, was ein gültiger Wert ist, wann ein Signal auslöst, und wer dieses Signal erhält, entsteht ein Register, das nicht nur dokumentiert, sondern auch als Anforderungspaket brauchbar ist. Dieses Register ist genau das, was benötigt wird, um zu bestimmen, was ein System — intern gebaut oder eingekauft — später können muss. Ohne dieses Anforderungspaket wird jede Anschaffung zum Glücksspiel. Wie Sie das in funktionale Anforderungen übersetzen, die aus Ihrem eigenen Prozess stammen, statt von einem Anbieter, steht auf der Seite über funktionale Anforderungen aus Ihrem eigenen Prozess.

Kontrollen auf Datenpunkten legen auch offen, wie viel der Arbeit darum herum Wiederholung ist: denselben Vergleich anstellen, dieselbe Meldung weiterleiten, dieselbe Ausnahme erneut beurteilen. Welcher Teil dieser Wiederholung sich dafür eignet, von KI übernommen zu werden, und welcher Teil gerade eine Beurteilung erfordert, die sich nicht automatisieren lässt, ist eine Frage, die sich pro Aufgabe beantworten lässt. Der Werkscan von FTE TO AI rechnet das pro Aufgabe durch.

Marvinde assistent van de Data Readiness Scan

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.