Ein Anbieter fragt früher oder später: Was muss das System können? Die Antwort liegt nicht beim Anbieter und nicht bei einer Liste von Funktionalitäten, die andere Unternehmen ebenfalls angekreuzt haben. Die Antwort liegt in Ihrem eigenen Prozess: welche Datenpunkte Sie erfassen, wer sie liefert, woher sie kommen, und was schiefgeht, wenn niemand hinschaut.
Der gängige Weg ist: ein Tool auswählen, das Tool einrichten, und dann erst entdecken, welche Daten woher kommen müssen. Diese Reihenfolge wirkt kontraproduktiv, weil ein Tool keine Meinung zu Ihrem Prozess hat. Es verlangt Eingaben, und diese Eingaben müssen aus etwas stammen. Wenn dieses Etwas — das Datenpunktregister, die Eigenverantwortlichkeit, die Quellen — noch nicht existiert, wird die Einrichtung des Tools zu einer Suche, die niemand geplant hatte.
Die andere Reihenfolge beginnt beim Prozess. Zunächst wird ermittelt, welche Datenpunkte benötigt werden, wer sie liefert, aus welchem System oder welcher Tabelle sie stammen, und welche Qualitätsregeln dazugehören. Erst danach wird klar, welche Anforderungen ein Tool eigentlich erfüllen muss. Nicht abstrakte Anforderungen wie „benutzerfreundlich“ oder „skalierbar“, sondern konkrete Anforderungen wie: muss mit diesem spezifischen Quellsystem verbunden werden können, muss drei Eigentümer innerhalb eines einzigen Datenpunkts unterscheiden können, muss eine Abweichung melden, wenn eine Zahl außerhalb einer vorab festgelegten Marge liegt.
Die Reihenfolge ist keine methodische Vorliebe; sie folgt daraus, was dem Tool funktional logisch vorausgeht. Ein Tool kann erst Anforderungen erhalten, wenn es etwas gibt, aus dem sich Anforderungen ableiten lassen. Dieses Etwas ist der Prozess: der Datenfluss von der Quelle zum Bericht, mit allen manuellen Schritten, Übergaben und Annahmen, die dazugehören. Ohne diesen Überblick stellt eine Organisation Anforderungen auf Basis dessen, was ein Tool kann, statt auf Basis dessen, was der Prozess braucht. Das klingt nach einem subtilen Unterschied, entscheidet aber darüber, ob das Tool später an der Realität andockt oder neben ihr steht.
Das schließt an die Frage an, wie Sie ein Tool auswählen, ohne es hinterher zu bereuen: Bedauern entsteht oft nicht durch ein schlechtes Tool, sondern durch ein Tool, das Anforderungen erraten musste, weil niemand sie aufgeschrieben hatte.
Wenn das Tool zuerst kommt und der Prozess erst später, entstehen zwei Arten von Kosten. Die erste ist eine direkte Neueinrichtung: Funktionalität, die nicht passt, Verbindungen, die nachträglich gebaut werden müssen, Felder, die leer bleiben, weil niemand weiß, wer sie ausfüllen soll. Die zweite Kostenart ist weniger sichtbar, aber schwerer: Das Tool liefert Berichte, die ordentlicher aussehen, während die zugrunde liegenden Zahlen weiterhin nicht auf eine Quelle oder einen Eigentümer zurückzuführen sind. Dieses Risiko wird ausführlicher beschrieben auf der Seite über was es kostet, ein Tool über einen unorganisierten Prozess zu setzen: Das Tool verdeckt das Problem, statt es zu lösen.
Welche Reihenfolge günstiger ausfällt, hängt davon ab, wie viele Datenpunkte, Systeme und Eigentümer bereits vorhanden sind und wie viele davon noch nicht erfasst sind. Bei einem kleinen Prozess mit wenigen Quellen ist der Schaden der umgekehrten Reihenfolge begrenzt. Bei einem Prozess, der über mehrere Abteilungen, Systeme und Tabellen verteilt ist, wächst dieser Schaden mit jedem Datenpunkt, der nicht geklärt wurde, bevor das Tool danach fragt. Diese Abwägung wird ausführlich dargestellt auf der Seite zuerst ein Tool kaufen oder zuerst den Prozess einrichten: was dieser Unterschied kostet.
Bevor ein Tool Anforderungen erhalten kann, muss ein Überblick bestehen, welche Datenpunkte für die Berichterstattung benötigt werden, woher jeder Datenpunkt stammt, wer für die Richtigkeit verantwortlich ist, und welche Regel bestimmt, ob ein Wert plausibel ist. Dieser Überblick ist kein technisches Dokument und kein Tool selbst; er ist ein Register, das die Grundlage für jeden weiteren Schritt bildet, ob dieser weitere Schritt nun ein Tool ist, ein manueller Prozess, oder eine Kombination aus beidem.
Die Frage, welche funktionalen Anforderungen sich daraus ergeben, ist also eigentlich die Frage: Was steht in diesem Register, und was fehlt noch? Solange diese Frage nicht beantwortet ist, bleibt jede Anforderung an ein Tool eine Vermutung. Dieser Zusammenhang zwischen Anforderungen und dem zugrunde liegenden Prozess wird weiter ausgeführt auf der Seite über welche funktionalen Anforderungen aus Ihrem eigenen Prozess folgen und was eine falsche Reihenfolge dabei kostet.
Sobald das Datenpunktregister und die Eigenverantwortlichkeit einmal geregelt sind, verschiebt sich die Frage davon, was ein Tool können muss, zu dem, was mit den Menschen geschieht, die diese Arbeit derzeit ausführen: das Erfassen, Kontrollieren und Übertragen von Zahlen aus Tabellen und Systemen. Ein Teil dieser Aufgaben ist repetitiv und folgt festen Regeln, und genau das ist die Art von Arbeit, von der sich ein Teil durch KI übernehmen lässt. Der [Arbeitsscan von FTE TO AI](https://ftetoai.nl) berechnet pro Aufgabe, welcher Anteil davon automatisiert werden kann, sodass deutlich wird, wo Menschen weiterhin gebraucht werden und wo die Arbeit an ein System übergeben werden kann, das nach festen Regeln kontrolliert und liefert.
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.