Eine Fabrik zählt das Abfallgewicht auf der Waagbrücke. Eine andere Fabrik schätzt es anhand des Containervolumens. Beide liefern eine Zahl für dieselbe Zeile im Bericht. Niemand hat gelogen, niemand hat einen Fehler gemacht. Es wurde nur nie festgelegt, was die Definition dieses Datenpunkts genau ist, und deshalb hat jeder Unternehmensteil die naheliegendste Auslegung gewählt, die dort verfügbar war.
Das ist keine Ausnahme. Es ist der normale Zustand einer Organisation, in der derselbe Metrik von verschiedenen Teams, mit unterschiedlichen Quellsystemen und unterschiedlicher Historie, angeliefert wird. Die Frage ist nicht, wie Sie diesen Unterschied wegbekommen, bevor er entsteht. Die Frage ist, was Sie damit tun, sobald Sie ihn sehen.
Der Schritt, der meistens übersprungen wird, ist, dass die Definition selbst irgendwo steht. Nicht im Kopf des Controllers, der es schon jahrelang so macht, sondern in einem Register: dieser Datenpunkt bedeutet dies, wird so gemessen, und diese Einheiten zählen mit oder nicht. Was innerhalb dessen ein gültiger Wert ist und wer es auffällt, wenn eine Anlieferung davon abweicht, steht beschrieben auf der Seite über was ein gültiger Wert ist und wer es merkt, wenn ein Wert davon abweicht. Ohne diese Festlegung ist jede Zusammenrechnung über Unternehmensteile hinweg eine Summe von Dingen, die eben nicht ganz dasselbe sind, verpackt in eine Zahl, die eben doch eindeutig wirkt.
Dieses Festlegen ist genau die Arbeit des Data Readiness Scan: nicht den Bericht neu schreiben, sondern das Datenpunktregister aufbauen, in dem für jeden Datenpunkt steht, was er ist, woher er kommt und wer dafür zeichnet. Dieses Register ist der Ort, an dem der Unterschied zwischen Unternehmensteilen sichtbar wird, statt erst sichtbar zu werden, nachdem die Zahl bereits zusammengezählt wurde.
Wenn Sie einmal sehen, dass Unternehmensteil A und Unternehmensteil B etwas anderes unter demselben Datenpunkt verstehen, gibt es grob drei Wege.
Der erste ist Harmonisierung: eine einzige Definition für die gesamte Organisation durchsetzen, mit allen dazugehörigen Systemanpassungen. Das ist auf lange Sicht oft der richtige Weg, aber nichts, was von heute auf morgen erledigt ist.
Der zweite ist Dokumentieren und Korrigieren: die Abweichung dort stehen lassen, wo sie ist, aber festhalten, wie groß sie ist, und mit einer festen Umrechnung sicherstellen, dass die Summe stimmt. Das funktioniert, wenn der Unterschied stabil und bekannt ist — etwa wenn ein Standort dauerhaft eine andere Messmethode verwendet, die sich zurückrechnen lässt.
Der dritte ist Signalisieren: nicht korrigieren, sondern eine Flagge setzen, sobald eine Anlieferung vom Muster abweicht, das Sie von diesem Unternehmensteil gewohnt sind. Wie Sie eine solche Signalabweichung einstellen und wer davon eine Meldung erhält, steht ausgearbeitet auf der Seite über wie Sie eine Signalabweichung einstellen und wer es merkt, wenn es passiert. Dieser Weg dient nicht dazu, das Problem zu lösen, sondern zu verhindern, dass es unentdeckt bleibt, während Sie auf eine strukturelle Lösung hinarbeiten.
Welcher Weg passend ist, hängt davon ab, wie viele Unternehmensteile abweichen, wie stabil diese Abweichung ist und wie viel Zeit bleibt, bevor die Zahl in eine Berichtsperiode eingeht. Das ist eine Abwägung, die je nach Organisation unterschiedlich ausfällt und die dieses Register nicht für Sie trifft — es macht aber sichtbar, dass die Abwägung getroffen werden muss.
Ein Definitionsunterschied ist einer der stillsten Fehler, die es gibt, weil jeder Unternehmensteil für sich genommen recht hat. Der Standort, der anhand des Containervolumens schätzt, macht innerhalb seines eigenen Prozesses nichts falsch. Das Problem entsteht erst auf der Ebene, auf der die Zahlen zusammenkommen, und genau dort ist oft niemand bestimmt, um zu prüfen, ob die zugrunde liegenden Definitionen überhaupt vergleichbar sind.
Das ist der Grund, weshalb Eigentümerschaft pro Datenpunkt genauso wichtig ist wie die Definition selbst. Welche Kontrollen zu einem Datenpunkt gehören und wer es merkt, wenn eine dieser Kontrollen übersprungen wird, steht beschrieben auf der Seite über welche Kontrollen zu einem Datenpunkt gehören und wer es merkt, wenn eine fehlt. Ohne einen bestimmten Eigentümer bleibt die Frage „aber wer sieht das eigentlich" unbeantwortet, auch wenn die Definition auf Papier steht.
Es ist verlockend, dieses Problem mit einem System lösen zu wollen, das Anlieferungen automatisch normalisiert. Aber ein Tool, das über eine Sammlung undefinierter Datenpunkte gesetzt wird, normalisiert nichts — es verpackt dieselben Unterschiede in eine ordentlichere Oberfläche. Die Reihenfolge, die Bestand hat, ist erst die Definition und die Eigentümerschaft festzulegen, und erst danach zu schauen, welches System dazu passt. Warum diese Reihenfolge nicht zufällig ist, steht ausgearbeitet auf der Seite über erst ein Tool kaufen oder erst den Prozess einrichten.
Sobald pro Datenpunkt feststeht, was die Definition ist, wer Eigentümer ist und welche Abweichungen signalisiert werden, entsteht eine andere Art von Frage: wer führt später die Arbeit aus, die zu diesen Kontrollen gehört — das Nachrechnen, das Nachfragen beim Unternehmensteil, der abweicht, das Pflegen des Registers selbst. Ein Teil dieser Arbeit ist wiederholbar genug, um an einen automatischen Schritt zu übergeben, ein Teil erfordert eine Beurteilung, die bei einem Menschen bleibt. Der Werkscan von FTE TO AI rechnet pro Aufgabe aus, welcher Teil davon von KI übernommen werden kann, auf Basis derselben Art von Konkretheit wie dieses Register: nicht die Frage, ob Automatisierung möglich ist, sondern welcher Teil welcher Aufgabe darunterfällt.
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.