COTS Lock-in im Mittelstand entsteht, wenn Standardsoftware nicht mehr nur Prozesse unterstützt, sondern deren Gestaltung zunehmend vorgibt. Anpassungen, proprietäre Datenmodelle, Zusatzmodule und eingeübte Workarounds erhöhen die Wechselkosten über Jahre. Branchenspezifische Systeme mit integriertem Company Brain können diese Abhängigkeit verringern, sofern Datenzugang, Schnittstellen und Verantwortlichkeiten von Beginn an mitgedacht werden.
Was bedeutet COTS im betrieblichen Alltag?
COTS steht für „Commercial Off-the-Shelf“. Gemeint sind marktverfügbare Software- oder Hardwareprodukte, die fertig entwickelt und einer breiten Kundengruppe zum Kauf, zur Miete oder zur Lizenzierung angeboten werden. Das National Institute of Standards and Technology, https://www.nist.gov/, beschreibt COTS entsprechend als kommerziell verfügbares, bereits fertiges Produkt.
Im Unternehmensalltag reicht das Spektrum von ERP-, CRM- und Dokumentenmanagementsystemen bis zu Projektsoftware, Ticketsystemen, Personalplattformen, Außendienstanwendungen und branchennahen SaaS-Lösungen. COTS ist weder grundsätzlich schlecht noch automatisch veraltet. Für Finanzbuchhaltung, Lohnabrechnung, E-Mail, Standard-CRM oder Collaboration wäre eine vollständige Eigenentwicklung in den meisten mittelständischen Unternehmen wirtschaftlich kaum vertretbar.
Der Vorteil liegt auf der Hand: Das Produkt ist verfügbar, erprobt, dokumentiert und wird vom Anbieter weiterentwickelt. Implementierungspartner, Schulungsangebote und standardisierte Betriebsmodelle sind häufig vorhanden. Das Unternehmen kann schneller starten, als wenn jede Funktion individuell geplant und programmiert werden müsste.
Problematisch wird es erst, wenn eine generische Anwendung in Bereiche vordringt, in denen branchenspezifische Abläufe, Erfahrungswissen und kundenspezifische Leistungserbringung den eigentlichen Wettbewerbsvorteil bilden. Dann beginnt die Organisation, ihre Arbeit an die Software anzupassen, obwohl die Software ursprünglich den Betrieb unterstützen sollte.
Den richtigen KI-Bedarf im Unternehmen erkennen
Die KI-Bedarfsermittlung zeigt, wo KI in Ihrem Unternehmen sinnvoll eingesetzt werden kann, welche Prozesse geeignet sind und welche nächsten Schritte realistisch umsetzbar sind.
Strukturiert analysiert · Praxisnah bewertet · Made in Germany
Warum wirkt generische Software anfangs besonders wirtschaftlich?
Standardsoftware verkauft ein attraktives Versprechen: Ein bereits vorhandenes Produkt deckt viele Anforderungen ab, reduziert Entwicklungsrisiken und verteilt seine Entwicklungskosten auf zahlreiche Kunden. Die Lizenzkosten erscheinen deshalb häufig niedriger als die Investition in ein individuelles System.
In der Auswahlphase werden vor allem sichtbare Funktionen verglichen. Kann die Software Angebote erstellen, Aufgaben verteilen, Dokumente speichern, Freigaben abbilden und Auswertungen erzeugen? Werden diese Fragen überwiegend bejaht, wirkt das Produkt passend. Die späteren Kosten entstehen jedoch weniger durch fehlende Einzelfunktionen als durch die Art, wie Daten, Rollen, Prozesse und Erweiterungen im Produktmodell organisiert sind.
Ein mittelständischer technischer Dienstleister kann beispielsweise feststellen, dass sein neues ERP zwar Aufträge, Artikel und Rechnungen abbildet, aber keine geeignete Struktur für wiederkehrende Fehlerbilder, Objektwissen, technische Erfahrungswerte oder mehrstufige Einsatzübergaben besitzt. Der Betrieb ergänzt Freitextfelder, Excel-Listen, SharePoint-Ordner, E-Mail-Vorlagen und zusätzliche Apps. Jede einzelne Ergänzung wirkt zunächst überschaubar. In ihrer Summe entsteht eine schwer steuerbare Nebenarchitektur.
Die eigentliche Rechnung besteht deshalb nicht nur aus Einführung, Lizenz und Wartung. Hinzu kommen Prozessanpassung, Datenbereinigung, Schnittstellen, Schulung, externe Beratung, manuelle Nacharbeit, Versionswechsel, Abhängigkeit von Spezialisten und die spätere Migration.
Wie entwickelt sich aus einer Softwareentscheidung ein Lock-in?
Lock-in entsteht nicht erst, wenn ein Anbieter den Datenexport verweigert. Meist wächst die Abhängigkeit schrittweise und auf mehreren Ebenen gleichzeitig.
Der kommerzielle Lock-in entsteht durch Vertragslaufzeiten, Paketpreise, Mindestabnahmen, gestaffelte Lizenzen, Kündigungsfristen und Rabatte, die nur bei langfristiger Bindung gelten. Ein Wechsel ist zwar theoretisch möglich, verursacht aber erhebliche Mehrkosten.
Technischer Lock-in entsteht durch proprietäre Datenmodelle, nicht dokumentierte Schnittstellen, herstellerspezifische Erweiterungen, Skriptsprachen, Workflow-Engines und Identitätsdienste. Je stärker zentrale Abläufe von solchen Komponenten abhängen, desto größer wird der Umbauaufwand.
Prozessualer Lock-in entsteht, wenn Mitarbeiter den betrieblichen Ablauf nicht mehr unabhängig von der Software beschreiben können. Formulare, Statuswerte und Genehmigungsschritte des Produkts werden zur inoffiziellen Prozessdefinition. Wird das System später ersetzt, fehlen häufig dokumentierte Sollprozesse.
Wissensbezogener Lock-in entsteht durch Schulungen, Zertifizierungen und jahrelange Erfahrung mit einer bestimmten Plattform. Interne Administratoren und externe Dienstleister kennen die Besonderheiten des Produkts, nicht zwangsläufig die zugrunde liegenden fachlichen Anforderungen. Ein Wechsel bedeutet dann nicht nur Datenmigration, sondern den teilweisen Neuaufbau von Kompetenz.
Die britische Government Digital Service, https://www.gov.uk/, bezeichnet Lock-in als Situation, in der der Wechsel zu einer anderen Technologie oder einem anderen Anbieter schwierig, zeitaufwendig und unverhältnismäßig teuer wird. Die Behörde unterscheidet dabei ausdrücklich zwischen kommerzieller und technischer Abhängigkeit.
Woran erkennen Unternehmen, dass der Lock-in bereits Prozesse verlangsamt?
Der Lock-in zeigt sich selten durch einen einzelnen spektakulären Ausfall. Typischer sind wiederkehrende Reibungsverluste, die im Tagesgeschäft als unvermeidbar hingenommen werden.
Ein Warnsignal ist die zunehmende Zahl manueller Übertragungen. Daten werden aus dem ERP exportiert, in Excel ergänzt, per E-Mail weitergegeben und später in ein zweites System übertragen. Ein weiteres Signal sind Arbeitsanweisungen, die vor allem beschreiben, wie Mitarbeiter Einschränkungen der Software umgehen sollen.
Auch lange Änderungszeiten sprechen für eine problematische Abhängigkeit. Eine fachlich kleine Anpassung benötigt mehrere Monate, weil sie ein Hersteller-Release, einen spezialisierten Implementierungspartner oder eine aufwendige Schnittstellenänderung voraussetzt. Der Betrieb richtet seine Verbesserungsvorhaben dann nicht mehr am Kundennutzen aus, sondern an den Möglichkeiten des Produktfahrplans.
Weitere Hinweise sind:
- dieselben Stammdaten werden in mehreren Systemen gepflegt,
- Auswertungen funktionieren nur mit zusätzlichen Datenexporten,
- neue Mitarbeiter müssen zahlreiche systembedingte Sonderwege lernen,
- wichtige Informationen stehen nur in Freitextfeldern oder Anhängen,
- Prozessänderungen scheitern an Lizenzmodulen oder Herstellergrenzen,
- niemand kann verlässlich beziffern, was ein vollständiger Anbieterwechsel erfordern würde.
Der entscheidende Punkt ist nicht, ob Workarounds vorhanden sind. Fast jedes produktive System besitzt Ausnahmen. Kritisch wird es, wenn die Ausnahmen zum normalen Betriebsmodell werden und niemand mehr zwischen fachlicher Notwendigkeit und historisch gewachsener Softwarelogik unterscheidet.
Wie verbreitet sind zentrale Standardplattformen inzwischen?
Standardisierte Geschäftsanwendungen bilden längst das Rückgrat vieler Unternehmen. Nach Angaben von Eurostat, https://ec.europa.eu/eurostat/, nutzten 2025 rund 41,08 Prozent der kleinen Unternehmen in der Europäischen Union ERP-Anwendungen. Über alle Unternehmensgrößen hinweg waren es 46,45 Prozent.
Parallel wächst die Nutzung externer Plattformdienste. Im Jahr 2025 bezogen 52,7 Prozent der Unternehmen in der Europäischen Union kostenpflichtige Cloud-Dienste. Die Verlagerung zu SaaS und Cloud-Plattformen macht moderne Funktionen schneller verfügbar, erhöht aber die Bedeutung von Datenportabilität, Vertragsgestaltung und Exit-Fähigkeit.
Für den Mittelstand folgt daraus nicht, dass Cloud oder ERP vermieden werden sollten. Die Zahlen zeigen vielmehr, wie stark betriebliche Abläufe inzwischen von fremdbetriebenen Anwendungen, Datenmodellen und Plattformdiensten geprägt sind. Je zentraler diese Systeme werden, desto wichtiger ist eine Architektur, die Abhängigkeiten bewusst begrenzt.
Warum wächst die Komplexität trotz weniger zentraler Systeme?
Viele Unternehmen beginnen mit dem Ziel, Anwendungen zu konsolidieren. In der Praxis führt die Einführung eines zentralen Systems jedoch häufig nicht zum Verschwinden aller Nebenlösungen. Das ERP übernimmt Auftrags- und Finanzdaten, während operative Teams zusätzliche Werkzeuge für Einsatzplanung, Checklisten, Dateiaustausch, Kundenkommunikation, technische Dokumentation und Reporting verwenden.
Der Grund liegt im unterschiedlichen Veränderungstempo. Kernsysteme müssen stabil, revisionsfähig und beherrschbar bleiben. Fachbereiche benötigen dagegen schnelle Anpassungen an neue Kundenanforderungen, regulatorische Vorgaben oder betriebliche Erfahrungen. Kann das Kernsystem diese Veränderung nicht aufnehmen, entstehen Ergänzungslösungen.
Wie weit solche Anwendungslandschaften wachsen können, zeigt der Connectivity Benchmark Report 2025 von MuleSoft, https://www.mulesoft.com/. Die dort befragten größeren Organisationen nutzten im Durchschnitt 897 Anwendungen. Zugleich berichteten nur 2 Prozent, mehr als die Hälfte ihrer Anwendungen integriert zu haben. Die Zahlen lassen sich nicht direkt auf einen deutschen Mittelständler übertragen, verdeutlichen aber den Zusammenhang zwischen Anwendungswachstum und Integrationsbedarf.
Komplexität entsteht damit nicht allein durch die Zahl der Produkte. Sie entsteht durch Übergaben zwischen ihnen: doppelte Stammdaten, unterschiedliche Benutzerrollen, uneinheitliche Begriffe, verzögerte Synchronisation, fehlende Ereignisse und schwer nachvollziehbare Verantwortlichkeiten.
Wie unterscheiden sich generische COTS-Lösungen und branchenspezifische Systeme?
| Kriterium | Generische COTS-Lösung | Branchenspezifisches System mit Company Brain |
|---|---|---|
| Ausgangspunkt | Allgemeine Funktionsbausteine für viele Branchen | Reale Arbeitsabläufe, Rollen und Objekte einer Branche |
| Prozessmodell | Vorgegebene Standardprozesse und konfigurierbare Masken | Fachliche Workflows mit branchentypischen Entscheidungen |
| Wissen | Dokumente, Hilfetexte und Freitextfelder | Verknüpftes Betriebs-, Projekt- und Erfahrungswissen |
| Anpassung | Customizing innerhalb des Herstellerrahmens | Erweiterbare Fachmodule und austauschbare Komponenten |
| Datenzugriff | Abhängig von Exporten, APIs und Lizenzstufe | Geplanter Zugriff über definierte Datenverträge und Schnittstellen |
| KI-Unterstützung | Allgemeiner Assistent innerhalb eines Produkts | Kontext aus Auftrag, Objekt, Rolle und freigegebenem Wissen |
| Wechselmöglichkeit | Migration häufig als späteres Sonderprojekt | Exit-Anforderungen werden bereits beim Aufbau berücksichtigt |
| Vorteil | Schnelle Einführung für standardisierte Anforderungen | Höhere Passung bei differenzierenden Betriebsprozessen |
| Risiko | Prozessanpassung an das Produkt | Höherer Gestaltungs- und Governance-Aufwand |
| Geeigneter Einsatz | Buchhaltung, Basis-CRM, Collaboration, Standardverwaltung | Service, Montage, Dokumentation, Prüfung und Fachentscheidungen |
Die Gegenüberstellung bedeutet nicht, dass branchenspezifische Software immer überlegen ist. Ein Betrieb benötigt meist eine Kombination. Standardisierbare Unterstützungsprozesse gehören in etablierte COTS-Produkte. Differenzierende Kernprozesse benötigen hingegen eine Architektur, die die Besonderheiten des Unternehmens nicht in zahllosen Ausnahmen versteckt.
Warum führt starkes Customizing häufig in eine Sackgasse?
Customizing wirkt zunächst wie der ideale Mittelweg. Das Unternehmen kauft ein Standardprodukt und passt es an die eigenen Abläufe an. Innerhalb bestimmter Grenzen ist das sinnvoll. Rollen, Formulare, Statusmodelle, Felder und einfache Workflows müssen konfigurierbar sein.
Die Grenze wird überschritten, wenn das Produktmodell dauerhaft gegen den Fachprozess arbeitet. Dann entstehen Erweiterungen, die tief in Herstellerlogik und Datenbankstruktur eingreifen. Versionswechsel benötigen Sondertests, neue Standardfunktionen kollidieren mit älteren Anpassungen und nur wenige Spezialisten verstehen die Gesamtarchitektur.
Ein typisches Muster ist die sogenannte Anpassungskaskade. Eine neue Anforderung erzeugt ein benutzerdefiniertes Feld. Das Feld wird in Berichte, Schnittstellen und Freigaben eingebaut. Später erhält es weitere Bedeutungen, die ursprünglich nicht vorgesehen waren. Nach einigen Jahren kann es nicht mehr entfernt werden, weil zahlreiche Prozesse indirekt davon abhängen.
Ähnlich problematisch sind Add-ons, die zentrale Lücken schließen, aber selbst proprietäre Daten oder Logik erzeugen. Der Betrieb ist dann nicht nur an den Hauptanbieter gebunden, sondern zusätzlich an Implementierungspartner und Erweiterungshersteller.
Die Alternative ist nicht zwangsläufig Eigenentwicklung. Oft ist eine sauber abgegrenzte Fachanwendung sinnvoller, die über dokumentierte Schnittstellen mit dem Kernsystem verbunden wird. Dadurch bleibt das ERP für standardisierte Transaktionen zuständig, während der Fachprozess dort abgebildet wird, wo er verändert werden kann.
Warum sind Workarounds teurer, als sie in der Kostenrechnung erscheinen?
Ein Workaround verursacht selten eine eigene Rechnungsposition. Seine Kosten verteilen sich auf Arbeitszeit, Rückfragen, Fehlerkorrektur, Schulung und Verzögerung. Deshalb bleiben sie in klassischen Softwarevergleichen häufig unberücksichtigt.
Nimmt ein Mitarbeiter täglich nur wenige Minuten für eine zusätzliche Übertragung auf, wirkt der Aufwand gering. Wird derselbe Schritt jedoch von mehreren Mitarbeitern über Jahre ausgeführt, entsteht ein erheblicher Produktivitätsverlust. Dazu kommt das Fehlerrisiko, wenn Daten mehrfach manuell erfasst oder aus verschiedenen Zwischenständen übernommen werden.
Workarounds erhöhen außerdem die Einarbeitungszeit. Neue Mitarbeiter müssen neben dem eigentlichen Fachprozess lernen, welche Felder anders verwendet werden, welche Excel-Datei maßgeblich ist und an welcher Stelle ein zusätzlicher Screenshot hochzuladen ist. Das betriebliche Wissen beschreibt dann nicht mehr nur die Leistungserbringung, sondern auch die Umgehung der Software.
Besonders teuer werden Workarounds bei Personalwechseln. Die inoffiziellen Verbindungen zwischen Anwendungen sind häufig unzureichend dokumentiert. Verlässt ein erfahrener Key User das Unternehmen, gehen nicht nur Bedienkenntnisse verloren, sondern auch das Wissen darüber, weshalb bestimmte Sonderwege überhaupt existieren.
Welche Rolle spielt der Daten-Lock-in?
Daten gehören formal oft dem Kunden, sind praktisch aber nicht ohne Weiteres nutzbar. Ein CSV-Export allein bedeutet noch keine Portabilität. Entscheidend ist, ob Beziehungen, Historien, Anhänge, Metadaten, Berechtigungen, Statuswerte und fachliche Bedeutungen vollständig erhalten bleiben.
Ein CRM kann beispielsweise Kontakte und Aktivitäten exportieren, aber keine konfigurierten Automatisierungen, Scoringmodelle oder vollständigen Kommunikationsbeziehungen. Ein DMS liefert Dokumente, ohne die zugehörigen Aktenstrukturen und Aufbewahrungsregeln ausreichend abzubilden. Ein ERP exportiert Stammdaten und Buchungen, während individuelle Workflows und Prüfregeln im Produkt verbleiben.
Der inzwischen anwendbare EU Data Act stärkt den Wechsel zwischen Datenverarbeitungsdiensten. Anbieter von Plattform- und Softwarediensten müssen unter anderem offene Schnittstellen bereitstellen und Daten mindestens in einem gängigen, maschinenlesbaren Format exportierbar machen. Die Europäische Kommission, https://commission.europa.eu/, stellt zugleich fest, dass hohe Ausstiegsgebühren, langwierige Verfahren und fehlende Interoperabilität bisher wesentliche Wechselhindernisse darstellen.
Diese Vorgaben verbessern die Rahmenbedingungen, lösen aber nicht automatisch jede Migration. Ein technisch exportierbarer Datensatz kann fachlich unbrauchbar bleiben, wenn das Unternehmen keine Dokumentation seiner Datenobjekte, Verantwortlichkeiten und Prozessbeziehungen besitzt.
Wie kann ein Company Brain den Lock-in verringern?
Ein Company Brain sollte nicht als zusätzliche Datenbank verstanden werden, in die sämtliche Unternehmensdaten kopiert werden. Richtig aufgebaut dient es als wissens- und kontextbezogene Schicht zwischen Mitarbeitern, Fachprozessen und vorhandenen Systemen.
Das Company Brain kann Informationen aus ERP, CRM, DMS, Ticketsystem, Projektplattform und branchenspezifischen Anwendungen zusammenführen, ohne deren jeweilige Transaktionsverantwortung zu übernehmen. Es kennt beispielsweise den Auftrag, das Objekt, die Kundenvereinbarung, frühere Störungen, freigegebene Arbeitsanweisungen und die Rolle des Mitarbeiters.
Dadurch muss eine Fachanwendung nicht jede Wissensfunktion selbst entwickeln. Ein mobiler Serviceprozess kann seine Auftragsdaten weiterhin aus dem ERP beziehen, während das Company Brain passende Erfahrungswerte, Dokumente und Handlungshinweise liefert. Nach Abschluss werden Messwerte, Berichte und Erkenntnisse in die jeweils verantwortlichen Systeme zurückgeschrieben.
Der entscheidende Architekturvorteil liegt in der Entkopplung. Nutzer greifen nicht mehr ausschließlich über die Oberfläche eines einzelnen Herstellers auf Wissen zu. Fachliche Begriffe, Rollen und Wissensobjekte können außerhalb des Produkts gepflegt und über definierte Schnittstellen mehreren Anwendungen bereitgestellt werden.
Ein Company Brain verhindert Lock-in jedoch nicht automatisch. Wird es selbst auf proprietären Datenstrukturen, nicht exportierbaren Vektorspeichern und undokumentierten Agentenlogiken aufgebaut, entsteht lediglich eine neue Abhängigkeit. Auch für diese Ebene sind Datenexport, Modellwechsel, Schnittstellen, Berechtigungskonzepte und nachvollziehbare Wissensquellen erforderlich.
Wie sieht ein praxisnaher Anwendungsfall aus?
Ein mittelständischer technischer Dienstleister verwendet ein Standard-ERP für Kunden, Angebote, Aufträge, Material und Rechnungen. Die operative Leistung ist jedoch komplexer als das Auftragsmodul. Monteure benötigen Objektbesonderheiten, frühere Fehlerbilder, Prüfabläufe, Fotodokumentation, Herstellerhinweise und Erfahrungen aus vergleichbaren Einsätzen.
Zunächst versucht der Betrieb, alle Anforderungen über zusätzliche ERP-Felder abzubilden. Die Masken werden umfangreicher, die Akzeptanz sinkt und wichtige Informationen landen weiterhin in Freitexten. Eine mobile Zusatzlösung verbessert die Bedienung, erzeugt aber einen weiteren isolierten Datenbestand.
Ein nachhaltigerer Aufbau belässt kaufmännische Transaktionen im ERP. Eine branchenspezifische Serviceanwendung führt den mobilen Arbeitsablauf. Das Company Brain verbindet Auftragskontext, Anlagendokumentation und freigegebenes Erfahrungswissen. Ein Integrationsdienst überträgt nur jene Daten, die für den jeweiligen Prozessschritt benötigt werden.
Wechselt das Unternehmen später das ERP, muss nicht der gesamte mobile Wissens- und Serviceprozess neu entwickelt werden. Die Schnittstelle zum neuen Auftrags- und Stammdatensystem wird ersetzt, während fachliche Abläufe und Wissensstrukturen weitgehend erhalten bleiben. Vollständig aufwandsfrei ist ein solcher Wechsel weiterhin nicht, aber der Änderungsumfang bleibt begrenzter.
Was läuft bei Ablösungsprojekten üblicherweise falsch?
Ein häufiger Fehler ist die Annahme, dass das neue System sämtliche historischen Besonderheiten des alten Systems exakt nachbilden müsse. Dadurch werden veraltete Prozesse, Sonderfelder und Workarounds in die neue Plattform übertragen. Das Unternehmen wechselt den Anbieter, behält aber die alte Komplexität.
Ebenso problematisch ist eine reine Datenmigration ohne fachliche Bereinigung. Dubletten, unvollständige Stammdaten, ungepflegte Statuswerte und unverständliche Freitexte werden übernommen, obwohl ihr Nutzen längst fraglich ist.
Viele Projekte unterschätzen außerdem die in Schnittstellen enthaltene Geschäftslogik. Eine vermeintlich einfache Übertragung von Kunden- oder Auftragsdaten enthält häufig Filter, Prioritäten, Ausnahmen und manuelle Nachbearbeitung. Wird diese Logik erst während der Migration entdeckt, steigen Zeitbedarf und Risiko.
Ein weiteres Problem ist die Auswahl nach Funktionslisten. Anbieter können nahezu jede Anforderung in einer Präsentation bestätigen. Entscheidend ist jedoch, wie eine Funktion im realen Prozess arbeitet, welche Daten sie erzeugt, wie sie integriert wird und ob sie später ohne den Hersteller nutzbar bleibt.
Ablösungen scheitern auch an fehlender organisatorischer Verantwortung. IT, Einkauf und Fachbereich bewerten unterschiedliche Risiken. Ohne gemeinsames Ziel wird das Projekt entweder zu technisch, zu preisgetrieben oder zu stark auf kurzfristige Nutzerwünsche ausgerichtet.
Wann ist COTS weiterhin die richtige Entscheidung?
COTS bleibt sinnvoll, wenn ein Prozess weitgehend standardisiert ist, kein wesentlicher Wettbewerbsvorteil daraus entsteht und ein etablierter Markt mit mehreren vergleichbaren Anbietern besteht. Finanzbuchhaltung, Lohnabrechnung, Basiskommunikation, Terminverwaltung und allgemeine Zusammenarbeit sind typische Beispiele.
Auch für branchenspezifische Prozesse kann COTS geeignet sein, wenn das Produkt die Arbeitsrealität tatsächlich abbildet, seine Schnittstellen dokumentiert sind und Daten vollständig exportiert werden können. Branchensoftware ist nicht automatisch frei von Lock-in. Ein vertikales Produkt kann sogar eine besonders starke Abhängigkeit erzeugen, wenn nur wenige Alternativen bestehen.
Die richtige Frage lautet daher nicht „Standardsoftware oder Individualsoftware?“. Sinnvoller ist die Unterscheidung zwischen austauschbaren Standardfähigkeiten, differenzierenden Fachprozessen und unternehmenseigenem Wissen.
Standardfähigkeiten können eingekauft werden. Differenzierende Prozesse benötigen kontrollierbare Anpassungspunkte. Unternehmenswissen sollte in einer Form vorliegen, die nicht ausschließlich an die Oberfläche oder Datenstruktur eines einzelnen Produkts gebunden ist.
Welche Anforderungen sollten bereits in die Softwareauswahl einfließen?
Eine belastbare Auswahl betrachtet neben Funktion und Preis auch den späteren Betrieb und einen möglichen Ausstieg. Anbieter sollten zeigen, wie Daten vollständig exportiert, Schnittstellen dokumentiert, Berechtigungen übertragen und kundenindividuelle Konfigurationen gesichert werden.
Wichtig ist eine Übersicht über sämtliche Abhängigkeiten: Identitätsanbieter, Hosting, Erweiterungen, Drittanbieter-Apps, Berichtswerkzeuge, Datenbanken, Automatisierungen und Implementierungspartner. Eine offene API allein genügt nicht, wenn wesentliche Objekte oder Aktionen darüber nicht erreichbar sind.
Der Vertrag sollte regeln, in welchem Format Daten bereitgestellt werden, wie lange der Zugriff nach Vertragsende möglich bleibt, welche Unterstützung bei einer Migration angeboten wird und welche Kosten entstehen. Ebenso relevant sind Rechte an individuell entwickelten Erweiterungen, Dokumentationen und Konfigurationen.
In einem realistischen Auswahlverfahren erhalten Anbieter einen vollständigen Beispielprozess statt einer langen Funktionsliste. Dabei wird geprüft, wie Auftrag, Daten, Dokumente, Wissen und Rückmeldungen durch das System laufen. Ein zusätzlicher Exit-Test kann zeigen, ob sich der entstandene Datensatz mit vertretbarem Aufwand wieder herauslösen lässt.
Wie lässt sich der bestehende Lock-in messen?
Unternehmen können ihren Lock-in anhand mehrerer Dimensionen bewerten. Dazu gehören der Umfang proprietärer Anpassungen, die Zahl nicht dokumentierter Schnittstellen, die Verfügbarkeit vollständiger Datenexporte, die Abhängigkeit von einzelnen Dienstleistern und die Zeit, die für einen Wechsel realistischerweise benötigt würde.
Auch der Prozessanteil außerhalb der offiziellen Anwendung ist relevant. Je mehr Excel-Dateien, E-Mail-Regeln, Skripte und manuelle Übergaben erforderlich sind, desto höher ist meist die versteckte Komplexität.
Eine weitere Messgröße ist die Änderungsgeschwindigkeit. Wie lange dauert es von einer fachlichen Anforderung bis zur produktiven Umsetzung? Muss der Betrieb auf einen Hersteller-Release warten? Können kleinere Anpassungen intern vorgenommen werden? Welche Regressionstests sind bei jeder Änderung erforderlich?
Der wirtschaftliche Lock-in zeigt sich im Verhältnis zwischen laufendem Nutzen und Austrittskosten. Hohe Wechselkosten sind nicht automatisch falsch, wenn das Produkt einen entsprechend hohen und dauerhaften Nutzen liefert. Problematisch wird die Situation, wenn der Nutzen sinkt, die Abhängigkeit aber weiter wächst.
Wie kann eine schrittweise Entkopplung gelingen?
Eine vollständige Ablösung ist selten der beste erste Schritt. Häufig ist es sinnvoller, die bestehende Landschaft schrittweise zu entkoppeln.
Zunächst werden Datenobjekte und Systemverantwortlichkeiten festgelegt. Für Kundenstammdaten, Aufträge, Dokumente, Wissenseinträge und Auswertungen muss jeweils bekannt sein, welches System führend ist. Danach werden kritische Schnittstellen dokumentiert und möglichst über wiederverwendbare APIs oder Integrationsdienste geführt.
Im nächsten Schritt können besonders problematische Fachprozesse aus dem Kernsystem herausgelöst werden. Das betrifft beispielsweise mobile Dokumentation, technische Prüfungen, Wissenszugriff oder kundenspezifische Serviceabläufe. Die neue Fachanwendung erhält nur die erforderlichen Daten und gibt Ergebnisse strukturiert zurück.
Parallel sollte Unternehmenswissen aus proprietären Freitextfeldern und persönlichen Ablagen in eine kontrollierte Wissensstruktur überführt werden. Ein Company Brain kann dabei Suche, Kontext und Wiederverwendung ermöglichen, ohne das führende Transaktionssystem zu ersetzen.
Erst wenn Datenflüsse, Prozesse und Verantwortlichkeiten verstanden sind, lässt sich entscheiden, ob das alte Kernsystem bestehen bleiben, reduziert oder vollständig abgelöst werden sollte.
Welche Architektur verbindet COTS und branchenspezifische Lösungen sinnvoll?
Eine tragfähige Architektur besteht nicht aus einem einzigen allumfassenden Produkt. Sie verteilt Verantwortung bewusst.
Das ERP verwaltet kaufmännische Transaktionen und zentrale Stammdaten. Das CRM unterstützt Vertriebs- und Kundenprozesse. Das DMS oder ECM verwaltet freigegebene Dokumente und Aufbewahrungsregeln. Branchenspezifische Anwendungen bilden operative Abläufe ab. Das Company Brain verbindet Wissen und Kontext über diese Grenzen hinweg.
Eine Integrationsschicht übernimmt Datenaustausch, Ereignisse, Transformationen und technische Überwachung. Identitäts- und Berechtigungsdienste sorgen für einheitliche Zugriffe. Protokollierung und Governance machen nachvollziehbar, welches System welche Information bereitstellt oder verändert.
Dabei gilt nicht, dass jede Komponente jederzeit austauschbar sein muss. Eine vollständig anbieterneutrale Architektur kann unnötig teuer und funktional eingeschränkt werden. Ziel ist eine bewusste Abhängigkeit: Das Unternehmen kennt ihren Nutzen, ihren Umfang und die Folgen eines späteren Wechsels.
Welche nächsten Schritte sind für mittelständische Unternehmen sinnvoll?
Der erste Schritt ist keine neue Ausschreibung, sondern eine Bestandsaufnahme. Unternehmen sollten erfassen, welche Systeme ihre Kernprozesse prägen, welche Workarounds existieren, welche Daten nur schwer exportiert werden können und welche externen Spezialisten unverzichtbar geworden sind.
Anschließend werden Prozesse nach ihrer strategischen Bedeutung geordnet. Standardisierte Unterstützungsprozesse benötigen andere Architekturentscheidungen als kundennaher Service, technische Dokumentation oder branchenspezifische Leistungserbringung.
Für besonders wichtige Anwendungen sollte eine realistische Exit-Skizze entstehen. Sie beschreibt Datenumfang, Schnittstellen, Konfigurationen, notwendige Kompetenzen, Vertragsbedingungen und eine grobe Migrationsfolge. Ein solcher Plan bedeutet nicht, dass der Wechsel unmittelbar bevorsteht. Er verhindert, dass Abhängigkeit erst dann untersucht wird, wenn Zeitdruck entstanden ist.
Branchenspezifische Systeme und ein Company Brain können die Handlungsfähigkeit erhöhen, wenn sie als modulare Ergänzung einer bestehenden Landschaft aufgebaut werden. Der wirtschaftliche Vorteil liegt nicht darin, sämtliche Standardsoftware zu ersetzen. Er liegt darin, jene Prozesse und Wissensbestände wieder unter eigene Gestaltungshoheit zu bringen, die für Leistung, Qualität und Kundenbindung entscheidend sind.
Welche Quellen belegen die verwendeten Kennzahlen?
- Eurostat: E-business integration – ERP-Nutzung in Unternehmen 2025
https://ec.europa.eu/eurostat/statistics-explained/index.php?title=E-business_integration - Eurostat: 53% of EU enterprises used paid cloud services in 2025
https://ec.europa.eu/eurostat/web/products-eurostat-news/w/ddn-20260203-1 - MuleSoft: AI, Modernization, Integration, Automation, and APIs in 2025
https://blogs.mulesoft.com/news/connectivity-benchmark-report-2025/
Welche weiterführenden Quellen vertiefen das Thema?
Interessante Links
- National Institute of Standards and Technology: Definition von Commercial Off-the-Shelf
https://csrc.nist.gov/glossary/term/commercial_off_the_shelf - Government Digital Service: Technischen Lock-in in der Cloud steuern
https://www.gov.uk/guidance/managing-technical-lock-in-in-the-cloud - U.S. Government Accountability Office: Restriktive Softwarelizenzen und Cloud-Abhängigkeit
https://www.gao.gov/products/gao-25-107114
Wann spricht man bei Unternehmenssoftware von Vendor Lock-in?
Vendor Lock-in liegt vor, wenn ein Anbieterwechsel zwar theoretisch möglich ist, praktisch aber unverhältnismäßig viel Zeit, Geld oder organisatorischen Aufwand erfordert. Ursachen können proprietäre Datenformate, individuelle Anpassungen, fehlende Schnittstellen, Vertragsbindungen und spezialisiertes Produktwissen sein. Nicht jede Abhängigkeit ist problematisch, solange ihr Nutzen bekannt ist und der Ausstieg beherrschbar bleibt.
Ist COTS dasselbe wie SaaS?
Nein. COTS beschreibt ein fertig verfügbares Standardprodukt, während SaaS ein Bereitstellungsmodell bezeichnet. COTS kann lokal installiert, gehostet oder als SaaS angeboten werden. Umgekehrt kann auch eine stark spezialisierte Anwendung als SaaS betrieben werden. Für das Lock-in-Risiko sind Datenmodell, Vertragsbedingungen, Schnittstellen und technische Abhängigkeiten wichtiger als das reine Betriebsmodell.
Ist branchenspezifische Software automatisch besser als Standardsoftware?
Nein. Branchenspezifische Software besitzt häufig passendere Begriffe, Abläufe und Datenobjekte, kann aber ebenfalls hohe Abhängigkeiten erzeugen. Entscheidend sind Produktqualität, Integrationsfähigkeit, Datenexport, Anbieterstruktur und Weiterentwicklungsfähigkeit. Für standardisierte Unterstützungsprozesse bleibt etablierte Standardsoftware meist wirtschaftlicher. Fachsoftware ist besonders dort wertvoll, wo der Prozess den betrieblichen Wettbewerbsvorteil prägt.
Wie erkennt ein Unternehmen versteckte Wechselkosten?
Versteckte Wechselkosten liegen in Datenbereinigung, Schnittstellenumbau, Prozessneugestaltung, Schulung, Parallelbetrieb und dem Verlust eingeübter Produktkenntnisse. Unternehmen sollten zusätzlich untersuchen, welche Excel-Dateien, Skripte, Add-ons und manuellen Abläufe vom bestehenden System abhängen. Ein Testexport und eine dokumentierte Exit-Skizze liefern meist belastbarere Erkenntnisse als eine rein vertragliche Prüfung.
Verhindern offene Schnittstellen einen Vendor Lock-in?
Offene Schnittstellen reduzieren die Abhängigkeit, beseitigen sie aber nicht vollständig. Eine API kann nur ausgewählte Daten und Funktionen bereitstellen oder an bestimmte Lizenzpakete gebunden sein. Zusätzlich müssen Datenbedeutung, Beziehungen, Berechtigungen und Ereignisse dokumentiert sein. Entscheidend ist, ob ein anderes System den fachlichen Prozess mit den exportierten Informationen tatsächlich fortführen kann.
Wann lohnt sich eine individuelle Softwareentwicklung?
Eine individuelle Entwicklung lohnt sich vor allem bei differenzierenden Kernprozessen, die mit Standardprodukten dauerhaft nur über umfangreiche Sonderlösungen abgebildet werden können. Der erwartete Nutzen muss Entwicklungs-, Betriebs- und Wartungskosten übersteigen. Häufig ist keine vollständige Eigenentwicklung erforderlich. Eine abgegrenzte Fachanwendung auf standardisierten Plattformkomponenten bietet oft ein ausgewogeneres Verhältnis.
Kann ein Company Brain ein bestehendes ERP ersetzen?
Ein Company Brain ersetzt üblicherweise kein ERP. Das ERP bleibt für Stammdaten, Aufträge, Material, Buchungen und Rechnungen zuständig. Das Company Brain verbindet dagegen Wissen, Dokumente, Erfahrungswerte und Kontext aus mehreren Systemen. Es kann Mitarbeitern einen einheitlichen Zugang bieten und Fachanwendungen unterstützen, ohne die Transaktionsverantwortung des ERP zu übernehmen.
Wie lässt sich ein bestehender Lock-in schrittweise reduzieren?
Der Betrieb sollte zuerst führende Systeme, Datenobjekte und Schnittstellen dokumentieren. Danach können kritische Datenexporte getestet, proprietäre Erweiterungen bewertet und besonders belastende Fachprozesse entkoppelt werden. Eine Integrationsschicht und eigenständige Wissensstruktur reduzieren weitere Abhängigkeiten. Eine sofortige Komplettmigration ist selten notwendig und erhöht häufig das Projektrisiko unnötig.
Welche Vertragsklauseln sind bei COTS besonders wichtig?
Wesentlich sind Regelungen zu Datenexport, Dateiformaten, Zugriff nach Vertragsende, Migrationsunterstützung, Preisänderungen, Kündigungsfristen und Rechten an individuellen Erweiterungen. Auch Unterauftragnehmer, Hostingregionen und Schnittstellenlizenzen gehören in die Bewertung. Vertragsklauseln ersetzen jedoch keine technische Prüfung. Der zugesicherte Export sollte bereits während der Vertragslaufzeit praktisch getestet werden.
Muss ein Unternehmen jeden Lock-in vermeiden?
Nein. Jede produktive Software erzeugt einen gewissen Grad an Abhängigkeit. Der Versuch, sämtliche Bindungen zu vermeiden, kann Entwicklung verteuern und den Nutzen moderner Plattformdienste verringern. Entscheidend ist eine bewusste Abwägung: Welchen betrieblichen Wert liefert die Abhängigkeit, wie entwickelt sie sich und welche Möglichkeiten bestehen, wenn Anbieter, Preis oder Strategie nicht mehr passen?
