Die kostenoptimierte Symbiose. Standard, Low-Code und KI sinnvoll kombiniert.
Teil 4: Die kostenoptimierte Symbiose. Standard, Low-Code und KI sinnvoll kombiniert.
Teil 3 endete mit einer Frage: Wie kombiniert man Standard, Low-Code und KI-Eigenbau, ohne in fünf Jahren wieder im Zoo zu landen? Genau darum geht es jetzt. Um das Symbiose-Modell, eine ehrliche TCO-Rechnung über fünf Jahre und die Frage, wer eigentlich entscheidet, was wir kaufen, bauen oder klicken.
Die letzten beiden Teile haben das Bild geöffnet. Erst die Diagnose, warum der Applikations-Zoo unter den Annahmen der 2000er entstand. Dann die Greenfield-Architektur, die wir heute empfehlen würden: fünf Schichten, vier bis sechs Kernplattformen. Und im letzten Teil die ehrliche Make-or-Buy-Rechnung im KI-Zeitalter.
Was noch fehlt, ist die Zusammenführung. Wenn Standard, Low-Code und KI-Eigenbau alle ihren Platz haben, wie sieht das in der Praxis konkret aus? Welche Architektur, welche Kosten über fünf Jahre, welche Verantwortlichkeiten? Dieser Teil ist die Antwort.
Das Symbiose-Modell: vier Bausteine, keine Reinheits-Lehre
Die Zukunft der Tool-Landschaft im Mittelstand ist weder „alles aus einer Hand“ noch „alles selbst gebaut“. Sie ist eine bewusste Symbiose aus vier Bausteinen, die sich gegenseitig stützen und nicht ersetzen.
1. Standard-Kern als Rückgrat
ERP, CRM, je nach Geschäftsmodell PLM und MES, dazu eine Daten- und BI-Plattform. In Summe vier bis sechs Plattformen, die Sie kaufen, nicht bauen sollten. Sie sind millionenfach erprobt, kommen mit Update-Pfad und decken die Standardprozesse ab, die in jedem Industrieunternehmen ähnlich aussehen: Beschaffung, Bestand, Faktura, Kunde. Wer hier eigenständig baut, baut sich Schulden an, deren Zinsen normalerweise der Anbieter zahlt.
2. Low-Code-Ergänzung für die Lücken
Zwischen den Standardplattformen entsteht immer eine Lücke: ergänzende Workflows, Dashboards, kleine Genehmigungsprozesse, fachspezifische Datenerfassungen. Genau hier ist Low-Code stark: schnell, vom Fachbereich nutzbar, mit niedriger Hürde. Wichtig ist die Begleitung durch klare IT-Guardrails. Ohne sie wird aus Low-Code in 18 Monaten Schatten-IT mit eigener Wartungs-Schuld.
3. KI-gestützte Spezial-Apps für die Differenzierung
Dort, wo Sie sich am Markt unterscheiden (der Spezial-Konfigurator, die einzigartige Preislogik, die Branchen-Workflow-Variante, die kein Standard abbildet), lohnt sich Eigenbau heute schneller als noch vor Kurzem. KI-gestützte Entwicklung verschiebt die Bauschwelle nach unten. Aber nur in der bewussten Erweiterungs-Schicht, nicht als Schatten-IT, und nur, wenn die Betriebsfähigkeit geklärt ist. Sonst entstehen genau die vier Schulden aus Teil 3.
4. KI als Daten- und Intelligenz-Layer
Der vierte Baustein ist keine zusätzliche App. Er ist eine Schicht, die alle anderen veredelt: Klassifikation, Anomalie-Erkennung, semantische Suche, Forecasts. Diese Funktionen leben nicht im ERP oder CRM, sondern auf einer eigenen Daten- und Intelligenz-Schicht, die sich quer über alle Systeme zieht. Wer diese Schicht früh denkt, entkoppelt KI-Funktionen von einzelnen Plattformen und kann sie auch dann erneuern, wenn das ERP wechselt.
Vier Bausteine, klare Verantwortung pro Baustein. Das ist nicht weniger als der alte Best-of-Breed-Zoo, nur disziplinierter. Jeder Baustein hat einen Platz, eine Aufgabe und eine Grenze.
→ Eine kluge Symbiose schlägt jede Reinheits-Lehre.
Das Symbiose-Modell – vier Bausteine: Grundprinzip
Der Standard-Kern bildet die Basis der Architektur. Darauf aufbauend erweitern Low-Code-Lösungen und KI-Spezial-Apps das System gezielt. Der KI-Daten- und Intelligenz-Layer verbindet schließlich alle Bausteine und macht Informationen und Funktionen über Systemgrenzen hinweg nutzbar.
1. Standard-Kern: Stabiles digitales Rückgrat mit langfristigem Update-Pfad
Der Standard-Kern bildet das stabile digitale Fundament des Unternehmens. Er ist typischerweise aufgebaut aus zentralen Systemen wie ERP, CRM, PLM, MES und BI und sorgt für eine langfristig wartbare, skalierbare und integrierte IT-Landschaft.
2. Low-Code-Ergänzungen: Erweiterung bestehender Systeme durch zusätzliche Workflows und Anwendungen
Low-Code-Lösungen erweitern die bestehenden Kernsysteme gezielt um zusätzliche Prozesse und Anwendungen. Sie werden fachbereichsnah umgesetzt und unter IT-Governance betrieben, sodass Fachabteilungen flexibel arbeiten können, ohne die Systemstabilität zu gefährden.
3. KI-gestützte Spezial-Apps: Individuell entwickelte Lösungen für spezifische Anforderungen
KI-gestützte Spezialanwendungen werden dort eingesetzt, wo Standardlösungen nicht ausreichen. Sie sind individuell entwickelt, eng auf konkrete Anforderungen zugeschnitten und schaffen gezielt dort Mehrwert, wo Differenzierung und Wettbewerbsvorteile entstehen.
4. KI als Daten- und Intelligenz-Layer: Verbindende Schicht über allen Systemen
Der KI-Layer ist kein zusätzliches Tool, sondern eine übergreifende Intelligenz- und Datenebene. Er verbindet alle Systeme miteinander und ermöglicht die systemübergreifende Nutzung von Informationen sowie den Einsatz von KI-Funktionen über Systemgrenzen hinweg.
Wo das Geld wirklich versickert: vier Lizenzkostenfallen
Bevor wir die echte Kostenrechnung aufmachen, ein Zwischenstopp bei dem Posten, der in CFO-Gesprächen am lautesten ist: den Lizenzkosten. Vier Fallen sehen wir immer wieder. Sie sind selten der größte Schaden, aber der sichtbarste.
1. Modul-Aktivierung ohne Bedarfsanalyse
ERP- und CRM-Anbieter machen es leicht, Module per Mausklick freizuschalten. Schwerer ist es, dieselben Module wieder abzuschalten, wenn niemand sie nutzt. Wir sehen regelmäßig Lizenzlandschaften mit aktiven Modulen, deren Eigentümer niemand mehr benennen kann. Die Kosten laufen trotzdem weiter.
2. Wachstumsklauseln ohne Obergrenze
Lizenzverträge skalieren mit Nutzerzahlen, Datenvolumen oder Transaktionen. Das ist fair, solange es eine Obergrenze gibt. Verträge ohne Cap werden zur dauerhaften Wachstumsbremse: Jeder zusätzliche Erfolg im Geschäft trifft direkt das IT-Budget. Verhandeln Sie das Cap bei der Erstunterschrift, nicht erst beim nächsten Schub.
3. All-in-Pakete mit Leerlauf
All-in-Suiten versprechen, alles abzudecken. In der Praxis nutzen die meisten Unternehmen weniger als 70 Prozent dessen, wofür sie zahlen. Das ist nicht zwingend ein Fehler (manchmal kauft man bewusst Spielraum), aber es muss eine bewusste Entscheidung sein, kein Versehen. Eine jährliche Nutzungs-Inventur deckt diese Lücke schnell auf.
4. Vollzeit-Lizenzen für Gelegenheitsnutzer
Der lautlose Klassiker. Mitarbeiter, die nur einmal pro Woche eine Auswertung einsehen, bekommen Vollnutzer-Lizenzen, weil Read-Only- oder Casual-User-Tarife im Anbietergespräch nie thematisiert wurden. Über fünf Jahre summiert sich das zu sechsstelligen Beträgen, ohne dass jemand davon profitiert.
→ Lizenzkosten sind das Symptom. Architektur-Schulden sind die Krankheit.
Vier wiederkehrende Lizenzkostenfalle, die wir immer wieder sehen – sichtbar im Budget, korrigierbar mit ein paar wenigen Vertrags- und Inventur-Disziplinen:
1. Modul-Aktivierung ohne Bedarf
Bezahlt für Funktionen, die niemand nutzt – und niemand abschalten will.
2. Wachstumsklauseln ohne Cap
Skalieren ist gut. Automatisch skalierende Lizenzkosten ohne Obergrenze sind es nicht.
3. All-in-Pakete mit Leerlauf
30 % ungenutzte Funktionalität ist eine optimistische Schätzung.
4. Vollzeit für Gelegenheit
Vollnutzer-Lizenzen für alle, die nur einmal pro Woche ins System schauen.
Was kostet das wirklich? Eine ehrliche TCO-Rechnung über fünf Jahre.
Wer Tool-Entscheidungen am Lizenzpreis festmacht, hat den größten Teil der Rechnung noch nicht gesehen. Die Realität sind sechs bis sieben Kostenposten, die sich über fünf bis sieben Jahre summieren. Was Sie an Lizenz oder SaaS-Gebühr zahlen, ist nur einer davon.
Die Posten, die Sie tatsächlich einplanen sollten: Lizenz oder SaaS-Gebühr über die geplante Laufzeit. Implementierung und Einführung. Anpassung und Customizing. Schnittstellen zu den Nachbarsystemen. Wartung und Betrieb über die ganze Laufzeit. Schulung und Change. Und schließlich, oft der unsichtbare Posten, eine ehrliche Risiko- und Wartungs-Reserve. Wer einen dieser Posten unterschätzt, unterschätzt die Entscheidung.
Illustrative Beispielrechnung für einen Spezial-Konfigurator
Ein konkretes Beispiel, rein illustrativ, mit fiktiven, aber plausiblen Zahlen. Der Use Case: ein Spezial-Konfigurator für rund ~30 Nutzer in der Fertigung, abgewogen über drei Optionen, nämlich ein Standard-Modul vom ERP-Anbieter, eine Low-Code-Plattform oder einen KI-gestützten Eigenbau.
Bei einem reinen Standardprozess (z. B. Buchhaltung) kippt das Bild deutlich Richtung Standard.
| Kostenposten (5 Jahre) | Standard kaufen | Low-Code-Plattform | KI-gestützter Eigenbau |
|---|---|---|---|
| Lizenz / SaaS | € 120.000 | € 60.000 | € 0 |
| Implementierung / Einführung | € 60.000 | € 30.000 | € 45.000 |
| Anpassung & Customizing | € 40.000 | € 20.000 | € 30.000 |
| Schnittstellen | € 15.000 | € 30.000 | € 40.000 |
| Wartung & Betrieb | € 50.000 | € 35.000 | € 90.000 |
| Schulung & Change | € 15.000 | € 15.000 | € 8.000 |
| Risiko- / Wartungs-Reserve | € 10.000 | € 20.000 | € 40.000 |
| Summe (indikativ, 5 Jahre) | € 310.000 | € 210.000 | € 253.000 |
Was Sie hier sehen, ist kein universelles Ergebnis. Für genau diesen Use Case ist Low-Code die schlankste Lösung, KI-gestützter Eigenbau die zweitgünstigste und Standard das teuerste Verfahren. Hätten wir denselben Vergleich für einen Standardprozess gerechnet, läge Standard mit Abstand vorne und Eigenbau wäre Wahnsinn. Der Punkt ist nicht, dass eine Option immer gewinnt. Er ist, dass die Frage seriös nur fallweise zu beantworten ist, und nur dann ehrlich, wenn alle Posten auf dem Tisch liegen, nicht nur der Lizenzpreis.
Wichtig ist auch der Posten ganz unten: die Risiko- und Wartungs-Reserve. Wir setzen sie für KI-gestützten Eigenbau am höchsten an, genau wegen der vier Schulden aus Teil 3. Wer diesen Posten ehrlich einrechnet, sieht erst, was Eigenbau wirklich kostet. Wer ihn weglässt, schaut sich nur die schöne Seite der Rechnung an.
Wer entscheidet, was wir kaufen, bauen oder klicken?
Bauen, Kaufen und Klicken sind nicht nur Architektur-Fragen, sie sind Entscheidungsfragen. Und genau dort scheitern in unserer Erfahrung die meisten Symbiosen: nicht an der Technik, sondern an der Frage, wer wofür zuständig ist.
Unser Modell hat in der einfachsten Form vier Rollen. Erstens den Plattform-Owner für jeden Baustein des Standard-Kerns. Er entscheidet über die Plattform-Roadmap, hält die Daten konsistent und vertritt das System gegenüber dem Geschäft. Zweitens die fachliche Domänen-Verantwortung: wem gehört der Prozess (Vertrieb, Produktion, Service), unabhängig davon, welches System ihn abbildet. Drittens einen Low-Code-Guard: eine kleine IT-Einheit, die Low-Code-Anwendungen aus dem Fachbereich begleitet, ohne sie zu blockieren. Und viertens den Daten-Owner für die KI-Schicht: wer entscheidet, welche Daten wie verwendet werden dürfen, und wer für ihre Qualität haftet.
Schatten-IT verhindert dieses Modell nicht, aber es kanalisiert sie. Die meisten Schatten-IT-Projekte entstehen nicht aus Trotz, sondern aus Geschwindigkeit: der Fachbereich braucht etwas, und der formale Weg ist zu langsam. Ein Low-Code-Guard mit klaren Spielregeln macht den schnellen Weg auch zum legitimen Weg und nimmt der Schatten-IT die Daseinsberechtigung.
Der Quick-Check: fünf Fragen pro Use Case
Wenn Sie einen konkreten Use Case auf Ihrem Tisch haben (eine neue Anforderung aus dem Fachbereich, ein Verbesserungsvorschlag aus der IT, eine externe Empfehlung), dann sind es fünf Fragen, die zwischen einer Architektur-Entscheidung und einem Schnellschuss stehen.
• Erstens: Welche Schicht ist das eigentlich, Kern, Erweiterung, Spezial-App oder Daten-Layer?
• Zweitens: Wer ist der Plattform-Owner und wer der fachliche Eigentümer dieses Prozesses?
• Drittens: Welche Schnittstellen werden benötigt, und wer hält sie?
• Viertens: Welche TCO-Posten fallen über fünf Jahre tatsächlich an, inklusive Risiko-Reserve?
• Fünftens: Wer betreibt, pflegt und verantwortet das Ergebnis in fünf Jahren?
Wenn Sie auf alle fünf Fragen eine ehrliche Antwort haben, dann haben Sie keine Tool-Entscheidung mehr. Sie haben eine Architektur-Entscheidung. Genau das ist der Unterschied zwischen einer Symbiose und dem nächsten Zoo.
Was als Nächstes kommt
Die Symbiose ist die Zielarchitektur. Was sie nicht ist: ein Migrationspfad. Kein Mittelständler kommt morgen mit einer leeren Tool-Landschaft ins Büro. Der Schritt von der gewachsenen Zoo-Realität in die Symbiose, mit laufendem Betrieb, ohne Big Bang, ohne dass das Tagesgeschäft leidet, ist ein eigenes Thema. Es ist Teil 5 dieser Serie.
Bis dahin eine Frage zum Mitnehmen für Ihre nächste Investitionsentscheidung: Wissen Sie eigentlich, was Ihre größte Plattform Sie über die nächsten fünf Jahre wirklich kostet, inklusive Anpassung, Schnittstellen, Wartung und Reserve? Oder ist Ihnen nur der Lizenzpreis bekannt? Wenn nur Letzteres, dann arbeiten Sie an der gleichen halben Rechnung wie die meisten.