Das Tool passt nicht. Also passen wir uns an.

Es fängt meistens mit einer guten Nachricht an.

Der Anbieter hat nachgelegt. Das Kalkulationssystem, das seit Jahren für Ausschreibungen und Angebote im Einsatz ist, bekommt ein KI-Modul. Automatische Vorschläge auf Basis vergangener Projekte, intelligente Preisfindung, schnellere Angebotserstellung. Das klingt nach dem nächsten logischen Schritt. Kein Systemwechsel, kein Aufwand — einfach das Bestehende erweitern.

Tatsächlich: Die großen Bausoftware-Anbieter rüsten gerade alle in diese Richtung auf. NEVARIS bewirbt KI-gestützte Angebotserstellung mit Vorschlägen auf Basis historischer Projekte. RIB Software hat Ende 2025 eine Partnerschaft mit Microsoft geschlossen — ausdrücklich mit dem Ziel, mehr KI in iTWO zu integrieren. Die Botschaft ist bei allen Anbietern dieselbe: KI ist jetzt dabei. Steigen Sie auf.

Das ist keine schlechte Nachricht. Diese Anbieter bauen solide Produkte — für die Breite des Marktes. Und genau das ist der Punkt.

Denn bevor man aufsteigt, lohnt sich eine Frage: Für wen ist diese KI eigentlich gebaut?

Ein Tiefbauer, ein Angebot, ein Problem

Nehmen wir ein Beispiel, das so oder ähnlich in der Branche regelmäßig vorkommt. Ein mittelständisches Unternehmen im Tiefbau und Infrastrukturbau — rund 70 Mitarbeiter, spezialisiert auf kommunale Aufträge, Kanal- und Leitungsbau. Das Angebotswesen ist der Engpass: erfahrene Kalkulatoren mit knappem Zeitbudget, komplexe Leistungsverzeichnisse, Preisspiegel aus vergangenen Projekten, die in verschiedenen Systemen liegen. Die Idee: das bestehende Kalkulationssystem um ein KI-Modul erweitern, das genau hier hilft.

Die Demo war überzeugend. Die ersten Wochen auch.

Dann kam die Realität.

Das KI-Modul arbeitete mit Projektdaten aus dem eigenen System — aber dieser Betrieb hatte seine historischen Kalkulationen über Jahre in einer Kombination aus dem Hauptsystem und Excel gepflegt. Der eigentliche Erfahrungsschatz lag nicht sauber strukturiert in einer Datenbank, sondern verteilt in Dateien, Ordnern, in den Köpfen der Kalkulatoren. Das Modul konnte damit nichts anfangen. Es machte Vorschläge — aber aus einem Datenpool, der nur einen Bruchteil der tatsächlichen Projekthistorie abbildete.

Der Anbieter bot Anpassungen an. Datenmigration, Konfiguration, Schulung. Alles möglich. Alles gegen Aufpreis.

Und damit begann die eigentliche Rechnung.

Was Anbieterabhängigkeit wirklich kostet

Wer ein Standardmodul einführt, zahlt zunächst — scheinbar — wenig. Die Lizenz ist sofort verfügbar, das System läuft, eine erste Demo zeigt Ergebnisse. Das ist der Moment, in dem der Vergleich mit einer maßgeschneiderten Lösung ungerecht wirkt: Die individuelle Entwicklung kostet in der Anfangsphase mehr, das Standardmodul scheinbar kaum etwas.

Doch diese Rechnung hat zwei Seiten — und die zweite Seite wird selten zu Ende gedacht.

Lizenzkosten akkumulieren sich. Bausoftware-Lizenzen sind nicht günstig, und sie steigen. Was im ersten Jahr wie ein überschaubarer Posten wirkt, wächst mit jedem Nutzer, mit jedem Zusatzmodul, mit jeder Preisanpassung. Nach drei bis fünf Jahren ist aus dem scheinbar kleinen Einstieg eine substanzielle Dauerverpflichtung geworden — ohne dass der Betrieb Eigentümer irgendeines Teils davon wäre.

Anpassungskosten kommen obendrauf. Kein Standardmodul passt auf Anhieb. Datenmigration, Konfiguration, Integration in bestehende Systeme — all das kostet Tagessätze und Projektzeit. Und weil diese Kosten nicht im Lizenzpreis stehen, werden sie oft unterschätzt oder erst im Lauf der Einführung sichtbar.

Prozesse folgen der Software. Das ist die stillste und teuerste Form der Abhängigkeit. Wenn ein Team über Monate lernt, wie das Tool Informationen erwartet, verändert es unbewusst, wie es arbeitet. Kalkulatoren passen ihre Vorgehensweise an die Systemlogik an — nicht umgekehrt. Das Werkzeug formt das Handwerk. Und wenn das Tool irgendwann nicht mehr passt oder zu teuer wird, stellt man fest: Man muss nicht nur das System tauschen. Man muss die eigenen Prozesse neu denken.

Datensouveränität ist keine Selbstverständlichkeit. Ausschreibungsunterlagen, Kalkulationen, Projektdaten, Preisspiegel — das sind sensible Geschäftsinformationen. Bei vielen cloudbasierten Angeboten liegt die Frage, wo diese Daten tatsächlich liegen und unter welchen Bedingungen sie verarbeitet werden, im Graubereich. DSGVO-konform auf dem Papier ist nicht dasselbe wie datensouverän in der Praxis.

Eine illustrative Rechnung

Bausoftware-Anbieter veröffentlichen selten Listenpreise — Konditionen werden individuell verhandelt. Aber die Größenordnungen sind bekannt, und sie helfen, die Rechnung zu verstehen.

Ein Tiefbauunternehmen mit drei Kalkulatoren, die ein KI-gestütztes Angebotsmodul nutzen sollen: Bei marktüblichen Lizenzen für professionelle Bausoftware in diesem Segment sind schnell 300 bis 600 Euro pro Nutzer und Monat erreicht — das ergibt 10.000 bis 20.000 Euro pro Jahr, allein für die Lizenz. Dazu kommen Einführungskosten: Datenmigration, Konfiguration, Schulung. Erfahrungsgemäß entsprechen diese im ersten Jahr noch einmal dem ein- bis zweifachen der Jahreslizenz. Und weil kein Modul auf Anhieb passt, folgen Anpassungskosten — jede Änderung, jede Sonderfunktion, jede Integration kostet Tagessätze.

Nach drei Jahren summiert sich das — konservativ gerechnet — auf 60.000 bis 100.000 Euro. Für ein System, das dem Betrieb nicht gehört, dessen Daten auf fremder Infrastruktur liegen, und das beim nächsten Versionssprung des Anbieters erneut Anpassungskosten auslösen kann.

Eine maßgeschneiderte Lösung auf Open-Source-Basis kostet in der Entwicklung mehr als die Lizenzgebühr des ersten Jahres. Aber sie kostet einmalig — zuzüglich transparenter, planbarer Infrastrukturkosten. Keine Lizenz pro Nutzer. Kein Aufpreis für das nächste Feature. Kein Abhängigkeitsverhältnis, das sich mit jedem Monat vertieft. Wer diese Rechnung über drei Jahre aufmacht, kommt meistens zu einem anderen Ergebnis als erwartet.

Die andere Ausgangsfrage

Was wäre passiert, wenn unser Tiefbauer nicht gefragt hätte: „Welches Modul gibt es für unser Angebotswesen?" — sondern: „Was ist unser Angebotsprozess, und was brauchen wir dafür wirklich?"

Wahrscheinlich wäre herausgekommen: Die eigentliche Stärke liegt in der Projekthistorie — aber die liegt nicht sauber in einem System, sondern verteilt. Der erste Schritt wäre also nicht KI, sondern Datenbasis: Welche Projekte haben wir gemacht, mit welchen Kennwerten, welchen Materialpreisen, welchen Subunternehmern? Erst wenn diese Grundlage strukturiert ist, kann KI darauf aufbauen — und dann kann sie wirklich helfen.

Das ist übrigens dieselbe Logik, die wir in einem früheren Beitrag beschrieben haben: Manchmal ist der erste Schritt kein KI-Tool, sondern die Vorbereitung dafür. Wer hier zu schnell zum Standardmodul greift, überspringt die eigentliche Hausaufgabe.

Und wer diese Hausaufgabe gemacht hat, braucht kein Standardmodul mehr. Er braucht eine Lösung, die auf seine Daten, seine Projekttypen, seinen Angebotsprozess zugeschnitten ist. Gebaut auf Open-Source-Komponenten, gehostet auf europäischer Infrastruktur, vollständig im Eigentum des Betriebs. Keine Lizenz für Funktionen, die ein anderer Betriebstyp braucht. Kein proprietäres Format, das den Ausstieg erschwert. Kein monatlicher Aufpreis für das nächste Feature.

Was „maßgeschneidert" wirklich bedeutet

Maßgeschneidert klingt nach groß und aufwendig. Das Gegenteil ist der richtige Ansatz.

Es geht nicht darum, das komplexeste System zu bauen. Es geht darum, genau den einen Prozess gut zu lösen, der heute der Engpass ist — mit Open-Source-Komponenten, auf europäischer Infrastruktur, vollständig im Eigentum des Betriebs. Keine Features, die niemand braucht. Keine Lizenz, wenn ein weiterer Nutzer hinzukommt. Kein proprietäres Format, das den Ausstieg erschwert.

Ein schlankes System, das einen Prozess wirklich löst, ist mächtiger als ein umfassendes System, das zehn Prozesse mittelmäßig abdeckt. Und es bleibt kontrollierbar — weil der Betrieb entscheidet, was das System tut. Nicht der Anbieter.

Wo fangen Sie an?

Anbieterabhängigkeit entsteht nicht über Nacht. Und sie lässt sich nicht über Nacht auflösen.

Aber der erste Schritt ist kleiner als gedacht: Einen Prozess herausgreifen, der heute durch ein Tool mehr eingeschränkt als unterstützt wird. Und die Frage stellen — ehrlich, ohne Rücksicht auf bereits getätigte Investitionen: Wie würden wir das lösen, wenn wir frei entscheiden könnten?

Diese Frage ist unbequemer als sie klingt. Aber sie ist der Anfang von etwas Besserem.

PRAIN berät mittelständische Unternehmen in Bau und Fertigung beim Aufbau maßgeschneiderter KI-Lösungen — Open Source, ohne Vendor Lock-in, mit vollem Datenzugriff für den Kunden. Interesse an einem Erstgespräch? Melden Sie sich.