Drei Auswertungen für die Risikofrüherkennung am Bau entwickeln

Die Aufgabe

Wenn die Betriebsabrechnung eine Risikobaustelle meldet, ist die Datengrundlage vier bis acht Wochen alt. Für eine Gegenmaßnahme ist das zu spät.

Kunde: Bauunternehmen
Branche: Bauwirtschaft
Dauer: zwei Phasen mit einem Ausstiegspunkt dazwischen, gut ein Jahr

Anwendungsfälle aus dem Risikocontrolling gemeinsam bewertet und auf drei priorisiert

Prototypen umgesetzt — Geräteauslastung aus Telematikdaten, Nachträge in Schlussrechnungen, vertragsrelevante Sachverhalte im Schriftverkehr

Quellsysteme angebunden, ausgewählt aus einer Landschaft von rund siebzehn

Kurz zum Kunden

Bauunternehmen, das die gesamte Wertschöpfungskette des Bauens abdeckt, von der Planung über die Errichtung bis zur Bewirtschaftung. Die Bandbreite reicht vom Wohnungsbau über Erschließungsmaßnahmen bis zur innerstädtischen Kanalsanierung. Kennzeichnend für die Branche ist die Projektfertigung: Jede Baustelle ist ein Einzelvorhaben mit eigener Kalkulation und eigener Kostenstelle, und eine defizitäre Maßnahme kann die Marge mehrerer erfolgreicher aufzehren. Deshalb ist die Frage, wie früh ein Betrieb von einer Schieflage erfährt, hier keine Controllingfrage, sondern eine Ergebnisfrage.

Unsere Lösung

Die Zahl, an der ein Bauunternehmen ein Risiko erkennt, ist ein Nachbericht. Das Frühwarnsignal liegt in den Systemen, die niemand dafür ansieht.

Die Aufgabe

Das Projektcontrolling erkannte Risikobaustellen an drei Schwellen. Ergebnis unter null, mehr als fünfzigtausend Euro unberechnete Leistung bei einer unfertigen Baustelle, mehr als fünfzigtausend Euro unbezahlte Leistung bei einer fertigen. Ermittelt wird das über einen Tabellenexport aus dem Finanzsystem, von Hand gefiltert und für die Berichterstattung formatiert. Der wunde Punkt steht im eigenen Konzept des Auftraggebers wörtlich: Wenn die Betriebsabrechnung von einer Risikomaßnahme spricht, ist die Datengrundlage bereits vier bis acht Wochen alt. Auf einer Baustelle sind vier bis acht Wochen der Unterschied zwischen einer Gegenmaßnahme und einer Schadensmeldung. Alles, was früher warnen könnte — Auslastung der Geräte, Nachtragslage, vertragsrelevanter Schriftverkehr, Abweichungen in der Kalkulation — liegt in anderen Systemen und wird für die Risikobeurteilung nicht ausgewertet. Die Aufgabe ist, zu klären, ob sich aus diesen Daten ein Frühwarnsignal gewinnen lässt, und es an drei Anwendungsfällen zu beweisen.

Unser Ansatz

Das Frühwarnsignal liegt nicht im Finanzsystem. Die Zahl, an der ein Bauunternehmen eine Risikobaustelle erkennt, entsteht in der Betriebsabrechnung — und die ist, wenn sie vorliegt, ein Nachbericht. Was früher spricht, liegt in den Systemen, die niemand für das Risikocontrolling ansieht: Telematik der Geräte, Nachtragsstände in der Baustellensteuerung, Rechnungs- und Zahlungsdaten, projektbezogener Schriftverkehr. Der Ansatz war deshalb nicht, die vorhandene Auswertung zu verbessern, sondern die Datenquellen zu wechseln.

Zwanzig Anwendungsfälle, drei umgesetzt — und die Auswahl war der eigentliche Arbeitsschritt. Der Auftraggeber hatte die möglichen Anwendungsfälle selbst zusammengetragen, von der Geräteauslastung über Skontofristen und Massenverhältnisse in der Kalkulation bis zur Auswertung von Submissionsergebnissen. Wir haben sie gemeinsam bewertet und auf drei priorisiert. Der Maßstab war nicht, welcher Fall am interessantesten klingt, sondern für welchen die Daten in ausreichender Qualität vorliegen und welcher ein Signal liefert, das früh genug kommt, um noch etwas zu ändern. Siebzehn von zwanzig hätten gute Vorträge ergeben. Drei ließen sich beweisen.

Erst die Daten bewerten, dann Modelle entwickeln. Die Vorstudie hatte ein ausdrücklich begrenztes Ziel: ein Datenframework über die vier risikorelevanten Quellsysteme, eine Prüfung jeder Quelle auf Datenqualität und Eignung, eine Visualisierung der Bestände und daraus ein Vorschlag geeigneter Verfahren. Das Training von Modellen war in dieser Phase ausgeschlossen, und das stand so im Angebot. Der Grund ist Erfahrung: Der teuerste Fehler in KI-Projekten ist ein Modell, das auf Daten trainiert wird, deren Qualität niemand geprüft hat. Man merkt es erst, wenn das Ergebnis plausibel aussieht und trotzdem falsch ist.

Vier Systeme statt siebzehn. Die Landschaft des Auftraggebers umfasste rund siebzehn Systeme über technische und kaufmännische Seite hinweg — von Statik, Vermessung und Zeitplanung bis zu Finanzbuchhaltung, Dokumentenverwaltung und vier verschiedenen Telematiklösungen für Fahrzeuge und Geräte. Der Reflex wäre, alles anzubinden. Wir haben die vier Systeme angebunden, in denen die Daten für die drei Anwendungsfälle liegen, und die Datenbereitstellung als einmaligen Abzug vereinbart, ohne Eingriff in Produktivsysteme. Eine Integrationsarchitektur hätte das Projekt verdoppelt, bevor bewiesen war, dass sich der Aufwand lohnt.

Zwei Ausstiegspunkte, vertraglich verankert. Zwischen Vorstudie, Prototypen und Produktivsetzung stand jeweils ein Evaluation Point, an dem über die Fortführung entschieden wurde. Die dritte Phase — die Integration in einen Gesamtprozess — war ausdrücklich nicht Gegenstand des Angebots. Das ist keine Zurückhaltung, sondern die Bedingung dafür, dass ein Unternehmen ein KI-Vorhaben überhaupt beginnen kann: Es muss vorher wissen, wo es wieder aussteigen darf.

Ein Modell, das nicht in Betrieb geht, hat nichts bewiesen — deshalb als Dienst entwickelt. Die Ergebnisse liefen nicht in Notebooks, sondern hinter einer definierten Schnittstelle, dazu ein Dashboard mit Ampeldarstellung, wie es der Auftraggeber im Zielbild beschrieben hatte. Damit war nach der Erprobung die Frage nach der Produktivsetzung eine Entscheidung und keine Entwicklungsaufgabe von vorn.

Das Ergebnis

Aus dem Katalog von zwanzig möglichen Anwendungsfällen sind gemeinsam mit dem Auftraggeber drei ausgewählt und umgesetzt worden.

Erstens die Auslastung der Baustellengeräte aus Telematikdaten über das Verhältnis von Last- zu Leerlaufstunden. Zweitens die Prüfung von Schlussrechnungen auf Nachträge, die dem Bauherrn nicht vorlagen, samt Vergleich von Teilleistungen gegen die eigene Projekthistorie. Drittens die Auswertung des projektbezogenen Schriftverkehrs auf vertragsrelevante Sachverhalte nach VOB — Behinderung, Verzug, Fristsetzung, Mangelanzeige.

Davor die Vorstudie: Aufnahme der Ist-Prozesse in zwei Workshops, ein Gesamtkonzept für die Frühwarnung mit Ampeldarstellung, Soll-Prozesse für die drei Anwendungsfälle und eine Roadmap für die übrigen. Dazu ein Datenframework über die vier risikorelevanten Quellsysteme, eine Bewertung jeder Quelle nach Datenqualität und Eignung für KI-Verfahren, und die Vorauswahl der Algorithmen und des Technologie-Stacks. In der zweiten Phase je Anwendungsfall Datenaufbereitung, Datenstrecken, Basismodelle, Optimierung und Validierung, zusammengeführt in einem Dashboard mit Ampelfunktion. Die Modelle sind als Dienst hinter einer definierten Schnittstelle entwickelt worden.