Software als Maßanzug. Prototypische Organisationsmuster 1/6
Veröffentlicht am: Wednesday, May 06, 2026 von David Symhoven & Jens Aßmann
Software als Maßanzug
Ein organisationales Muster in der Softwareentwicklung
Jedes Softwareunternehmen kennt diese Situation: Der Kunde will einen Maßanzug und nichts von der Stange, der Vertrieb verspricht den Maßanzug. Die Entwicklung zahlt später die Rechnung. Was wie ein Kommunikationsproblem zwischen zwei Bereichen aussieht, ist keines. Es ist ein organisationales Muster, das typisch für die Softwareentwicklung ist.
Die Grundspannung: Softwareentwicklung als Spagat zwischen Individualisierung und Skalierbarkeit
Jede Organisation, die Software herstellt und verkauft, lebt in der Spannung zwischen dem Kundenwunsch nach Individualisierung und dem eigenen Wunsch nach Standardisierung. Wie eine Organisation mit dieser Grundspannung umgeht, ist ihr organisationales Muster.
Die Metallbau Westerburg GmbH aus dem Sauerland sucht ein neues ERP-System. Die Anforderungsliste ist lang: Firmenspezifische Begriffe sollen übernommen werden, in das Interface sollen die Unternehmensfarben integriert werden, bestimmte Sonderfälle des eigenen Geschäftsmodells müssen in der Logik des ERP verankert werden. Der Einkäufer des Mittelständlers formuliert es so: „Wir wollen keinen Anzug von der Stange, sondern einen Maßanzug, der zu unseren Abläufen passt. Wir haben da einige Besonderheiten.”
Auf der anderen Seite des Tisches sitzt der Vertriebsleiter des Softwareanbieters Planex ERP AG aus Niedersachsen. Er nickt, lächelt und denkt sich: „Maßanzug. Natürlich. Und zwar zum Preis eines Anzugs von der Stange.” Was er sagt, ist etwas anderes: „Unser ERP ist extrem flexibel, wir können alles auf Ihre Wünsche und Gegebenheiten anpassen.”
Kein Unternehmen funktioniert exakt wie ein anderes. Prozesse, Begriffe, Ausnahmeregeln – sie sind Ausdruck gewachsener Logiken, die man nicht einfach in den Standard pressen kann. Auf der Kundenseite steht daher häufig der Wunsch nach Individualisierung der Software.
Ein Softwareunternehmen entwickelt Produkte, um den Umsatz vom Zeiteinsatz entkoppeln zu können. Diese Skalierbarkeit der Software ist nur möglich, wenn Produkte standardisiert sind. Wer jeden Kunden individuell bedient, ist im Grunde Dienstleister und kein Produzent. Dienstleistung verkauft Zeit gegen Geld, Produzenten haben die Möglichkeit, skalierbare Produkte zu bauen und zu verkaufen. Die Grundspannung zwischen Individualisierung und Standardisierung auf den zwei Seiten des Tisches stellt die Basis für das organisationale Muster dar.
Die Musterbildung: Ab wann es schädlich wird, Kundenwünsche zu erfüllen
Der Vertriebsleiter erledigt seinen Job, das Unternehmen aus dem Sauerland bekommt ein neues ERP-System. Die ersten Wünsche der Individualisierung lassen sich leicht umsetzen. Die firmenspezifischen Begriffe sind integriert, die Bedienoberfläche erscheint in den Unternehmensfarben, das Logo ist sichtbar. Diese Anpassungen auf Ebene der Customisation sind schnell gemacht und hinterlassen Eindruck beim Kunden.
Schwieriger wird es auf den Ebenen, auf denen die gewünschten Kundenanpassungen in die Grundlogik und die Architektur der Software eingreifen. Die Metallverarbeiter wünschen sich die tiefe Verdrahtung von Sonderlocken gemäß ihrer Geschäftsabläufe ins ERP. Die Zusage dieser Sonderlocken für den Kunden beschert dem Vertriebler seinen individuellen Bonus. Gleichzeitig werden sie zum Albtraum des Entwicklers des Softwareanbieters. Der Entwickler der Planex ERP AG, der die Anforderungsliste der Metallbau Westerburg GmbH zum ersten Mal sieht, sagt in der internen Abstimmung mit dem Vertriebsleiter wenig. Aber er hat einen klaren Gedanken: „Das können wir so machen, aber das werden wir bei jedem Release bereuen.” Die individuelle Anpassungsprogrammierung für den Kunden hat zur Folge, dass bei jedem Release die Sonderlocke des ERP für diesen Kunden individuell geprüft und ggf. angepasst werden muss. Der Kunde wurde mit der Integration der Sonderlocke zwar gewonnen, aber der Softwarehersteller hat sich eine dauerhafte Pfadabhängigkeit eingehandelt. Die Software wurde als Maßanzug verkauft.
Diese Unterscheidung entscheidet über Skalierbarkeit
Solange Anpassungen für Kunden auf der Ebene der beschriebenen Customisation verbleiben, sind sie prinzipiell unschädlich für das Ziel eines skalierbaren Softwareprodukts. Beim nächsten Release neuer Fehlerbehebungen können mit einmaligem Aufwand Verbesserungen für alle ERP-Kunden ausgespielt werden. In diesem Fall hat die gewünschte Anpassungsprogrammierung aber ein Level erreicht, das von nun an bei jedem Release eine individuelle Prüfung erforderlich macht. Welche Auswirkungen hat dieses Release in Bezug auf die Sonderlocken des Kunden? Die lediglich einmal bestellten Sonderlocken führen zu einem individuellen Friseureinsatz bei jedem Release. Wartungsumsätze in der Anpassungsprogrammierung skalieren nicht. Sie folgen der Logik Zeit gegen Geld. Wartungsumsätze im Standard skalieren. Sie entkoppeln den Einsatz von Zeit und Geld. Aus der guten Intention der Befriedigung eines Kundenwunsches ist ein langfristiger Schaden für das Ziel der Skalierbarkeit der Software geworden.
Customisation verändert lediglich, wie die Software aussieht, und schadet dem Ziel der Skalierbarkeit nicht.
Anpassungsprogrammierung verändert, wie Software denkt. Wird einem Kunden Anpassungsprogrammierung zugesagt, wird die Skalierbarkeit geopfert.
Wenn der hier beschriebene Vorgang nicht nur einmal, sondern wie eine Betriebseinstellung regelmäßig und wie auf Autopilot stattfindet, hat sich ein organisationales Muster etabliert. Der Softwareanbieter handelt sich eine breite Kundenbasis mit Sonderlocken ein, die bei jedem Releasewechsel individuell geprüft und ggf. angepasst werden müssen. In der Folge kann man beobachten, dass ein Softwareproduzent, der damit angetreten war, skalierbare Produkte zu entwickeln, zum Dienstleister geworden ist.
Die Spannung ist weder technisch, noch vertrieblich
Viele Softwareunternehmen behandeln die Spannung, die diesem Muster zugrunde liegt, als technisches oder vertriebliches Problem.
- Wenn das ERP zu viel für einzelne Kunden angepasst wird, braucht es effizientere Entwicklungsprozesse.
- Wenn das Skalierungspotenzial des ERP nicht genug genutzt wird, braucht es schärfere Vertriebsleitlinien.
Softwareunternehmen stehen dauerhaft in der Spannung zwischen Individualisierung und Skalierbarkeit. Aus dieser Spannung wählen viele Organisationen – meist unbewusst – die Individualisierung. Das Ergebnis ist Anpassungsprogrammierung: immer öfter, immer tiefer, immer teurer. Solange das nicht als organisationales Muster erkannt wird, das schädlich in Bezug auf die Skalierbarkeit wirkt, bleibt jeder Lösungsversuch auf der Symptomebene stecken. Die Ursache bleibt unangetastet. Diese Grundspannung ist zudem kein Problem, das sich grundsätzlich lösen, also ein für allemal auflösen lässt. Sie kann nur gemanagt werden, es braucht einen dauerhaften Umgang mit ihr.
Die bewusste Gestaltung der Grundspannung
Zwei Jahre später, beim dritten großen Release, sitzt derselbe Vertriebsleiter in einem internen Abstimmungsgespräch. Der Entwickler erklärt ihm, warum das Update für die Metallbau Westerburg GmbH drei Wochen länger dauern wird, als das zentral für andere Kunden ausgespielte Release. Der Vertriebsleiter hört zu und reflektiert schließlich: „Ich glaube, ich habe damals nicht zu Ende gedacht, was die Zusage der Sonderlocken alles für uns nach sich ziehen wird.” Der Entwickler nickt. Beide wissen, dass das nächste Projekt nach dem gleichen Muster bereits angelaufen ist. Es wurde wieder ein Maßanzug verkauft.
Softwareunternehmen, die skalieren wollen und Software dennoch als Maßanzug verkaufen, treffen Entscheidungen, die sie zum Dienstleister machen. Unternehmen, die ihr organisationales Muster erkennen, können damit beginnen, die Spannung bewusst zu gestalten. Sie können sich zum Beispiel die folgenden Fragen stellen:
- Welche Kunden haben wir uns mit der Zusage von Sonderlocken erkauft und was kostet uns das bei jedem Release?
- Wissen Vertrieb und Entwicklung bei uns, wo die Grenze zwischen Customisation und Anpassungsprogrammierung liegt – und ist das eine gemeinsame organisationale Grenze?
- Haben wir jemals bewusst entschieden, ob und zu welchem Anteil wir Dienstleister sein wollen oder ist das einfach passiert?
Die beschriebene Spannung gibt es in jedem Softwareunternehmen. In den meisten wird sie weder wahrgenommen noch thematisiert. Wirken tut sie trotzdem.
Organisationen, die ihre eigenen Muster nicht kennen, werden trotzdem maßgeblich von ihnen beeinflusst. Diese Artikelserie beschreibt solche Organisationsmuster – nicht um sie zu verurteilen, sondern um sie sichtbar zu machen. Wer seine Organisation beim Lesen wiedererkannt hat, hat bereits begonnen, das Muster zu beobachten. Diese Sichtbarkeit ist die Voraussetzung für bewusstes Handeln.
Jens Aßmann auf LinkedIn folgen
Mehr zu dem Thema auch in meinem Podcast oder in meinem Buch Die Illusion der Kontrolle