Die gängige Reihenfolge ist: ein Tool auswählen, das Tool einrichten, und dann hoffen, dass sich der Prozess dem schon anpassen wird. Das funktioniert in der Praxis nicht, weil ein Tool keinen Prozess mitbringt. Ein Tool bringt Felder mit, Verknüpfungen, Dashboards — aber nicht die Frage, wer in Ihrer Organisation für den Energieverbrauch von Gebäude drei verantwortlich ist, oder ob der Facility Manager, der diese Zahl liefert, weiß, dass sie in der Scope-2-Berichterstattung landet.
Die richtige Reihenfolge ist umgekehrt: erst den Prozess beschreiben, dann erst ein Tool wählen auf Basis dessen, was dieser Prozess benötigt. Das klingt nach einem Umweg, ist aber der kürzeste Weg, weil jede funktionale Anforderung, die Sie an ein Tool stellen, irgendwo aus Ihrer eigenen Datenorganisation kommen muss. Ohne diesen Ausgangspunkt wählen Sie nach Funktionen aus, die ein Anbieter wichtig findet, nicht nach Funktionen, die Ihren Engpass lösen.
Die Kosten der falschen Reihenfolge sind nicht sofort sichtbar, denn ein Tool, das nicht passt, funktioniert zunächst prima — für den Teil des Prozesses, der zufällig mit dem übereinstimmt, was das Tool erwartet. Der Rest wird händisch herumgebaut: eine Excel-Anlage hier, ein E-Mail-Austausch dort, ein Mitarbeiter, der genau weiß, welcher Schritt gerade außerhalb des Systems liegt. Das funktioniert, bis dieser Mitarbeiter geht oder der Datenumfang wächst.
Was es kostet, hängt davon ab, wie viele Datenpunkte außerhalb des Tools laufen und wie oft diese pro Berichtszyklus erneut händisch erfasst werden müssen. Bei einer kleinen Anzahl von Punkten ist das ein akzeptabler Umweg. Bei einer wachsenden Anzahl — mehr Standorte, mehr Scope-3-Kategorien, mehr Gesetzgebung, die hinzukommt — wird der Umweg zur Hauptroute, und Sie zahlen dauerhaft für die Diskrepanz zwischen Tool und Prozess. Das ist eine andere Art zu sagen, was auch auf dieser Seite steht: ein Tool über einem unorganisierten Prozess produziert ordentlichere Berichte über dieselben unzuverlässigen Zahlen.
Eine funktionale Anforderung ist erst eine Anforderung, wenn sie aus etwas hervorgeht. „Das Tool muss Lineage anzeigen können“ ist keine Anforderung, bis Sie wissen, dass Ihr Controller dreimal im Jahr händisch herausfinden muss, woher eine Zahl kommt. „Das Tool muss Eigenverantwortung festhalten können“ ist keine Anforderung, bis Sie gesehen haben, dass ein Datenpunkt ohne Eigentümer bei niemandes Aufgabenliste steht.
Genau deshalb müssen das Datenpunktregister, die Source-to-Report-Lineage pro Datenpunkt und die Eigentümerzuweisung zuerst existieren, unabhängig davon, welches Tool Sie letztlich wählen. Sobald diese drei Dinge schriftlich vorliegen — welcher Datenpunkt, woher er kommt, wer dafür verantwortlich zeichnet — haben Sie eine Liste von Anforderungen, die nicht von einem Anbieter kommt, sondern von Ihrer eigenen Organisation. Diese Liste nutzen Sie, um Tools zu vergleichen, nicht um blindlings eines auszuwählen. Wie Sie diesen Vergleich ohne Reue angehen, steht beschrieben auf dieser Seite über Toolauswahl.
Der Ort, an dem die Daten liegen, unterscheidet sich stark je Branche, und das bestimmt auch, welche funktionalen Anforderungen relevant sind. In einem Bauunternehmen liegt ein großer Teil der Nachhaltigkeitsdaten bei Subunternehmern und auf der Baustelle selbst, wie beschrieben auf dieser Seite über Datenquellen im Bau; dort ist eine Anforderung rund um mehrere externe Quellen pro Projekt wahrscheinlich wichtiger als in anderen Branchen. In der Installationsbranche liegen die Daten häufiger verteilt über Servicescheine und Materialerfassungen auf Projektebene, wie auf dieser Seite über die Installationsbranche zu lesen ist; dort zählt vor allem, ob ein Tool einzelne Eingabepunkte zusammenführen kann, ohne dass jemand das händisch macht.
Die allgemeine Frage — erst den Prozess einrichten oder erst ein Tool kaufen — wird auf dieser Seite weiter ausgearbeitet, und die Kernfrage dieser Seite, welche Anforderungen genau aus Ihrem eigenen Prozess hervorgehen, ist zusammengefasst auf dieser Seite. Beide Seiten gehen vom selben Punkt aus: Die Reihenfolge bestimmt, ob eine Anforderung eine Anforderung ist, oder ein Ratespiel.
Der Data Readiness Scan erfasst das Datenpunktregister, die Lineage und die Eigentümerzuweisung, bevor über ein Tool gesprochen wird. Das ist kein Berichtstool und keine Fragebogen-Lösung — es ist der Schritt, der bestimmt, was ein Tool für Ihre Organisation eigentlich können muss. Ohne diesen Schritt kaufen Sie Funktionen; mit diesem Schritt kaufen Sie eine Lösung für ein Problem, das Sie benennen können.
Der Scan befindet sich im Aufbau. Wer seinen Prozess auf diese Weise kartieren lassen möchte, bevor eine Toolentscheidung getroffen wird, kann sich für die Warteliste anmelden und wird informiert, sobald der Scan verfügbar ist.
Sobald das Datenpunktregister steht und klar ist, welcher Datenpunkt von welcher Quelle kommt und wer dafür verantwortlich ist, entsteht eine zweite, natürliche Frage: welcher Teil der Arbeit darum herum — das Sammeln, Kontrollieren und Übertragen von Zahlen — noch Handarbeit ist, und welcher Teil ein System übernehmen kann, ohne dass die Zuverlässigkeit sinkt. Diese Frage beantwortet der Werkscan von FTE TO AI, der pro Aufgabe berechnet, welcher Anteil der Arbeit von KI übernommen werden kann. Das ist ein anderer Scan als der Data Readiness Scan, und eine logische Fortsetzung davon: erst wissen, was die Daten sind und woher sie kommen, dann erst betrachten, welcher Teil der Handarbeit darum herum überflüssig werden kann.
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.