Standard, Individual, Framework
Drei Wege zu derselben Anwendung — und was sie nach der Einführung kosten
Eine Standardplattform bildet ab, was alle Unternehmen gemeinsam haben — und nicht alles davon brauchen Sie.
Was Ihr Unternehmen von anderen unterscheidet, sind die individuellen Daten und Prozesse, mit denen Sie Ihr Geld verdienen. Genau dieser Teil fehlt.
Der Standard deckt das Gemeinsame, nicht das Unterscheidende
Große Standardplattformen sind für die Summe aller Anforderungen gebaut, die ihre Hersteller je gesehen haben. Kein einzelnes Unternehmen hat diese Summe: In den Einführungsprojekten, die wir gesehen haben, nutzt ein Unternehmen von 100 % Standardfunktionen etwa ein Fünftel. Der Rest ist vorhanden, ist mitbezahlt, ist mitzukonfigurieren, mitzuschulen und mitzuwarten.
Umgekehrt fehlt regelmäßig das, worauf es ankommt. Die Daten und Prozesse, mit denen ein Unternehmen sich von seinen Wettbewerbern unterscheidet, sind im Standard nicht vorgesehen — sie sind ja das Besondere. Also wird angepasst. Das Customizing schließt die Lücke zwischen dem, was der Standard kann, und dem, was das Unternehmen tut. Am Ende steht eine Lösung, die die Anforderungen deckt, und ein Verhältnis, das sich verschoben hat. Die Passung ist erkauft, nicht geliefert.
Die Rechnung, die in Lizenzvergleichen fehlt
Vier Zahlen, die den Unterschied zwischen den drei Wegen greifbar machen.
20 %
der Standardfunktionen werden in einem typischen Einführungsprojekt tatsächlich genutzt
vor dem Customizing
30 / 70
Verhältnis von genutzter zu ungenutzter Funktionalität nach dem Customizing
die Passung ist erkauft, nicht geliefert
100 %
Passung erreicht eine individuell entwickelte Anwendung von Anfang an
ohne Prozessverbiegung, ohne Ballast
1 ×
statt n-mal: Querschnittsdienste werden auf einem Framework einmal gebaut und gepflegt
gilt für jede darauf gebaute Lösung
Drei Wege, dieselbe Anforderung
Standardsoftware
Die Anwendung existiert, bevor Ihre Anforderung existiert. Sie kaufen Reifegrad und Geschwindigkeit in den ersten Monaten und bezahlen dafür in der Passung. Was nicht passt, wird konfiguriert; was sich nicht konfigurieren lässt, wird erweitert; was sich nicht erweitern lässt, wird zum Prozess, der sich der Software beugt.
Das stärkste Argument des Herstellers ist echt: Er pflegt und aktualisiert das Produkt, funktional wie sicherheitsseitig, ohne dass Sie etwas tun. Es gilt allerdings nur für den Standardanteil. Für Ihre Erweiterungen gilt es nicht — die pflegen Sie oder Ihr Implementierungspartner, und sie sind es, die bei jedem größeren Release erneut zu prüfen sind.
Individualsoftware ohne Framework
Die Anwendung entsteht entlang Ihrer Prozesse. Am Ende steht eine Lösung, die zu 100 % das tut, was das Unternehmen tut — kein Ballast, keine Umwege, keine Prozessverbiegung.
Der Einwand der Standardhersteller ist an dieser Stelle ebenfalls echt: Was individuell gebaut ist, wird individuell gewartet. Benutzerverwaltung, Rechtekonzept, Verschlüsselung, Mailversand, Dateiverarbeitung, Protokollierung — jede dieser Querschnittsfunktionen ist in einem freihändig gebauten Projekt eigener Code. Eigener Code heißt: eigene Schwachstellen, eigene Updates, eigene Nachweise. Und das je Instanz.
Individualsoftware auf einem Service-Framework
Der dritte Weg trennt zwei Dinge, die in den ersten beiden vermischt bleiben: was in jeder Anwendung gleich ist, und was in Ihrer Anwendung eigen ist.
Die Querschnittsdienste — Identitäts- und Rechteverwaltung, Schlüssel- und Geheimnisverwaltung, E-Mail, Dokumentenerzeugung, Datentransformation — sind Teil des SOLUTIONS Frameworks. Sie werden einmal entwickelt, einmal gehärtet, einmal getestet und in jeder Lieferung mitgeführt.
Der fachliche Teil wird modelliert statt programmiert: im Designer, im Gespräch mit Claudette, und aus dem Modell erzeugt ein regelbasierter Generator die Anwendung. Die Querschnittsdienste werden anschließend deklarativ konfiguriert und über Microservices angebunden. Was der Kunde erhält, ist keine Mischung aus Standard und Individual — es ist eine individuelle Anwendung, deren technischer Unterbau nicht jedes Mal neu erfunden wurde.
Die drei Wege nebeneinander
Standard
Standardsoftware
- Passung über Customizing erkauft
- etwa 30 % genutzte Funktionalität nach der Einführung
- Kern wird vom Hersteller gepflegt
- Erweiterungen pflegen Sie oder Ihr Partner
- Prozessanpassung häufig nötig
- Releasewechsel berühren auch das Ungenutzte
Individual
Ohne Framework
- vollständige Passung zu Ihren Prozessen
- 100 % der Funktionalität wird genutzt
- Querschnittsdienste sind eigener Code
- Sicherheitsupdates je Projekt einzeln
- Nachweise je Projekt einzeln
- keine Prozessanpassung nötig
Individual + Services
Auf dem SOLUTIONS Framework
- vollständige Passung zu Ihren Prozessen
- 100 % der Funktionalität wird genutzt
- Querschnittsdienste sind Teil des Frameworks
- ihre Sicherheitsupdates wirken für alle Installationen
- einzeln zu betrachten bleibt der fachliche Teil
- keine Prozessanpassung nötig
Wo diese Rechnung Grenzen hat
Zwei Punkte gehören dazu, sonst ist es Werbung und keine Argumentation.
Gleichzeitigkeit
Ein gemeinsamer Unterbau bedeutet auch: Eine Schwachstelle darin betrifft alle Installationen zur selben Zeit. Der Vorteil, einmal zu bauen, hat als Kehrseite, dass im Ernstfall gleichzeitig informiert und gleichzeitig ausgeliefert werden muss. Das ist eine Frage der Betriebsorganisation des Anbieters — und danach zu fragen ist berechtigt.
Abhängigkeit
Ein Framework, das man weder einsehen noch weiterbetreiben kann, tauscht einen Anbieterbindungseffekt gegen einen anderen. Die Gegenfrage an jeden Framework-Anbieter lautet deshalb: Was bekommt der Auftraggeber in die Hand — nur die laufende Anwendung oder auch den Quellcode und das Recht, ihn weiterzuentwickeln? Die Prüffragen dazu gelten für jeden Anbieter, uns eingeschlossen.
Was sich ab 2027 daran ändert
Bislang war der Framework-Ansatz eine Wirtschaftlichkeitsfrage. Ab dem 11. Dezember 2027 wird er zusätzlich eine Nachweisfrage: Der Cyber Resilience Act verlangt dann für jedes ausgelieferte Softwareprodukt eine Risikobewertung, eine technische Dokumentation, eine Stückliste der eingesetzten Komponenten, ein benanntes Ende des Unterstützungszeitraums und eine Konformitätserklärung — auch dann, wenn die Software für einen einzigen Auftraggeber entstanden ist.
Wer jedes Projekt freihändig baut, führt diesen Nachweis je Projekt. Wer auf einem gemeinsamen Unterbau baut, führt ihn einmal für den Unterbau und projektspezifisch nur noch für den fachlichen Teil. Was ab 2027 gilt und was davon schon 2026 greift, steht im eigenen Beitrag.
Eine Stunde per Videokonferenz, kostenlos.
Weiterlesen
Häufige Fragen
Wann ist Standardsoftware die richtige Wahl?
Immer dann, wenn der Prozess selbst austauschbar ist. Buchhaltung, Lohnabrechnung oder Zeiterfassung folgen weitgehend denselben Regeln, und diese Regeln sind im Standard besser abgebildet, als ein einzelnes Unternehmen sie nachbauen würde. Kritisch wird es bei den Prozessen, mit denen sich ein Unternehmen von anderen unterscheidet. Dort erzeugt der Standard Customizing, und Customizing ist der Teil, der bei jedem Herstellerrelease erneut zu prüfen ist.
Wer wartet eine individuell entwickelte Anwendung?
Das hängt davon ab, worauf sie gebaut ist. Ohne gemeinsamen Unterbau ist jede Querschnittsfunktion eigener Code und damit einzeln zu pflegen: Anmeldung, Rechtekonzept, Verschlüsselung, Mailversand, Protokollierung. Auf einem Service-Framework sind genau diese Dienste Teil des Frameworks und werden für alle Installationen gemeinsam gepflegt. Einzeln zu betrachten bleibt der fachliche Teil und die Aktualisierung der dort verwendeten Bibliotheken.
Was passiert, wenn wir den Anbieter wechseln wollen?
Das ist die Frage, die vor der Entscheidung gestellt werden sollte, nicht danach. Ein Framework, das man weder einsehen noch weiterbetreiben kann, tauscht eine Anbieterbindung gegen eine andere. Entscheidend ist, was der Auftraggeber in die Hand bekommt: nur die laufende Anwendung oder auch den Quellcode und das Recht, ihn weiterzuentwickeln.
Sprechen Sie mit uns.