„Wir entwickeln das lieber selbst.“ Dieser Satz leitet seit 25 Jahren viele Gespräche über Softwareprojekte ein. Der Wunsch dahinter ist nachvollziehbar: volle Kontrolle über die eigene Software, kurze Wege, kein externer Dienstleister, der den Geschäftskontext erst verstehen muss.
Häufig scheitert die Umsetzung dieses Wunsches aber an Voraussetzungen, die unterschätzt werden.
Das typische Szenario
Ein Unternehmen hat einen Entwickler, vielleicht zwei. Die kümmern sich um die Website, das ERP-Customizing, ein paar Schnittstellen. Nebenbei betreuen sie Teile der internen IT. Das funktioniert, solange die Aufgaben überschaubar bleiben.
Dann kommt ein neues Projekt dazu: Eine Fachanwendung, die einen echten Geschäftsprozess abbilden soll. Plötzlich verändert sich die Situation grundlegend.
Der Entwickler arbeitet allein. Niemand prüft seine Arbeit, niemand hinterfragt Architekturentscheidungen. Nicht aus mangelndem Willen, sondern weil schlicht kein zweiter Fachmensch da ist, der das leisten könnte.
Die Fachabteilung wartet Wochen auf Änderungen, weil der Entwickler parallel drei andere Baustellen betreut. Nach 18 Monaten ist er überlastet und kündigt. Zurück bleibt Software, die niemand im Unternehmen versteht, warten oder weiterentwickeln kann.
Das ist keine Kritik an dem Entwickler. Er macht unter den gegebenen Umständen einen guten Job. Aber ein Entwickler allein ist kein Softwareteam. Genauso wie ein Chirurg allein kein OP-Team ist.
Zwei Bedeutungen von „Wir machen das selbst“
Hinter dem Satz „Wir entwickeln das selbst“ verbergen sich tatsächlich zwei sehr unterschiedliche Ansätze.
Ein professionelles internes Team aufbauen: Das bedeutet: Mehrere Entwickler mit komplementären Fähigkeiten. Etablierte Prozesse für Qualitätssicherung, Tests und Deployment. Vertretungsregelungen. Kontinuierliche Weiterbildung. Das ist der richtige Weg, aber er erfordert eine erhebliche Investition. Für ein funktionsfähiges internes Softwareteam sind mindestens drei bis fünf Entwickler nötig, plus die Kapazität, diese Stellen dauerhaft zu besetzen und zu halten. In Zeiten des IT-Fachkräftemangels ist das für viele mittelständische Unternehmen eine echte Herausforderung.
Einen einzelnen Entwickler neben seinem Tagesgeschäft etwas bauen lassen: Das ist der deutlich häufigere Fall. Die Anfangsinvestition ist gering, die versteckten Kosten zeigen sich erst später: Abhängigkeit von einer einzelnen Person, fehlende Qualitätssicherung, langsame Umsetzung, und im schlimmsten Fall eine Software, die nach dem Weggang des Entwicklers nicht mehr wartbar ist.
Warum Einzelentwickler-Projekte scheitern
Das Problem ist nicht mangelnde Kompetenz des Entwicklers, sondern strukturell.
Kein Sparring: Gute Software entsteht im Austausch. Architekturentscheidungen, die ungeprüft getroffen werden, haben eine hohe Fehlerquote. In einem Team werden Annahmen hinterfragt, Alternativen diskutiert und blinde Flecken aufgedeckt. Ein Einzelner hat diese Korrektivfunktion nicht.
Keine Vertretung: Wenn der Entwickler krank wird, im Urlaub ist oder das Unternehmen verlässt, steht die Entwicklung still. Bei geschäftskritischer Software ist das ein reales Risiko, das viele Unternehmen erst ernst nehmen, wenn es eingetreten ist.
Geteilte Aufmerksamkeit: In den meisten Fällen ist Softwareentwicklung nicht die einzige Aufgabe. Der Entwickler betreut parallel die IT-Infrastruktur, beantwortet Support-Anfragen und pflegt bestehende Systeme. Die Fachanwendung konkurriert mit dem Tagesgeschäft um seine Zeit. Das führt zu verzögerten Lieferungen und Frustration auf beiden Seiten.
Keine etablierten Prozesse: Qualitätssicherung, automatisierte Tests, strukturiertes Deployment: All das entsteht in einem Team aus Notwendigkeit. Ein Einzelner überspringt diese Schritte, weil der Aufwand unverhältnismäßig erscheint. Das funktioniert kurzfristig, rächt sich aber langfristig in Form von Fehlern, Instabilität und steigender Wartungskomplexität.
Die Alternative: Eigene Software, externes Team
Die Entscheidung steht nicht zwischen „alles intern“ und „alles abgeben“. Es gibt einen Mittelweg, der die Vorteile beider Ansätze kombiniert.
Das Unternehmen behält die volle Kontrolle über die Software. Es entscheidet, was gebaut wird, wie die Anforderungen aussehen und wann geliefert wird. Die Software gehört dem Unternehmen, nicht dem Dienstleister.
Die Entwicklung übernimmt ein externes Team, das genau das jeden Tag macht: professionelle Softwareentwicklung mit etablierten Prozessen, Qualitätssicherung und Vertretungsregelungen. Wenn jemand im Team ausfällt, steht nicht alles still.
Kontrolle bedeutet nicht, dass alles intern stattfinden muss. Kontrolle bedeutet, dass das Unternehmen entscheidet, was gebaut wird, und das Ergebnis besitzt. Wie die Umsetzung organisiert ist, ob intern, extern oder als Mix, ist eine operative Frage, keine strategische.
Checkliste Individualsoftware
Wann „selbst entwickeln“ trotzdem richtig ist
Es gibt Situationen, in denen ein internes Entwicklerteam die bessere Wahl ist:
Wenn Software das Kernprodukt des Unternehmens ist, nicht nur ein unterstützendes Werkzeug. Wenn das Unternehmen groß genug ist, um ein vollständiges Team dauerhaft auszulasten und zu halten. Wenn die Entwicklungsgeschwindigkeit so hoch sein muss, dass die Abstimmung mit einem externen Team zum Engpass würde.
Für die meisten mittelständischen Unternehmen, die Software zur Unterstützung ihrer Geschäftsprozesse brauchen, ist das nicht der Fall. Dort ist ein externer Partner mit einem eingespielten Team oft die wirtschaftlichere und risikoärmere Lösung.
Fazit
„Wir entwickeln das lieber selbst“ ist ein verständlicher Impuls. Aber zwischen dem Wunsch nach Kontrolle und der Realität professioneller Softwareentwicklung liegt eine Lücke, die sich nicht mit einem einzelnen Entwickler schließen lässt. Die ehrliche Frage lautet nicht „intern oder extern?“, sondern „haben wir die Struktur, um Software professionell zu entwickeln?“ Wenn die Antwort nein ist, ist ein erfahrenes externes Team die bessere Investition als ein überarbeiteter Einzelkämpfer.
Die Entscheidung zwischen Standard- und Individualsoftware hat erhebliche finanzielle Auswirkungen, in beide Richtungen. Individualsoftware für einen Standardprozess ist Overengineering. Standardsoftware für einen differenzierenden Prozess ist ein Kompromiss, der sich über Jahre als teurer erweisen kann als die vermeintlich günstigere Lösung. Beide Fehler kommen in der Praxis regelmäßig vor.
Wann Standardsoftware passt
Standardsoftware ist die richtige Wahl, wenn mehrere der folgenden Bedingungen zutreffen:
Der Prozess entspricht dem Branchenstandard: Buchhaltung, HR-Verwaltung, CRM-Basics: Wenn der eigene Prozess keine wesentlichen Abweichungen vom Standard aufweist, gibt es keinen Grund, eine Individuallösung zu entwickeln. Der Standardanbieter hat das Problem bereits für hunderte Kunden gelöst und optimiert.
Schnelle Verfügbarkeit ist entscheidend: Standardsoftware ist sofort einsetzbar. Keine monatelange Entwicklungsphase, keine Anforderungsanalyse, kein iterativer Entwicklungsprozess. Wenn Time-to-Market wichtiger ist als Passgenauigkeit, ist das ein gewichtiges Argument.
Die Weiterentwicklung durch den Anbieter hat Wert: Standardanbieter investieren kontinuierlich in neue Features, Sicherheitsupdates und regulatorische Anpassungen. Der Kunde profitiert davon, ohne eigenen Entwicklungsaufwand. Das ist ein realer Vorteil, besonders in regulatorisch anspruchsvollen Bereichen.
Die Abhängigkeit wird bewusst in Kauf genommen: Standardsoftware bedeutet Abhängigkeit von der Roadmap, den Preisen und den strategischen Entscheidungen des Herstellers. Solange diese Abhängigkeit beherrschbar ist und der Nutzen überwiegt, ist das eine rationale Entscheidung.
Wann Individualsoftware passt
Individualsoftware ist die richtige Wahl, wenn mindestens eine der folgenden Bedingungen zutrifft:
Die Standardlösung bildet nur einen Bruchteil der Anforderungen ab: Wenn 80% der bezahlten Funktionen nicht genutzt werden und die benötigten 20% nicht richtig funktionieren, stimmt die Kosten-Nutzen-Rechnung nicht mehr. Der Kunde zahlt für ein Produkt, das ihm nur teilweise dient, und investiert zusätzlich in Workarounds für die fehlenden Funktionen.
Der Prozess ist ein Wettbewerbsvorteil: Wenn das Geschäftsmodell darauf basiert, etwas anders oder besser zu machen als die Konkurrenz, darf die Software das nicht nivellieren. Standardsoftware ist per Definition für den Durchschnitt gebaut. Wer sich differenzieren will, braucht eine Lösung, die diese Differenzierung technisch unterstützt.
Volle Kontrolle über Daten und Infrastruktur ist notwendig: Wo werden die Daten gehostet? Wer hat Zugriff? Welche Sicherheitsstandards gelten? Bei Standardsoftware, insbesondere SaaS-Lösungen, entscheidet der Anbieter über diese Fragen. Für Unternehmen mit hohen Anforderungen an Datensouveränität kann das ein Ausschlusskriterium sein.
Die Standardlösung erzwingt Prozessanpassungen: Wenn die eigenen Abläufe an die Software angepasst werden müssen statt umgekehrt, entstehen Workarounds, manuelle Nacharbeiten und Frustration im Team. Schleichend, über Monate und Jahre, entwickeln Abteilungen eigene Tricks, um die Software zu umgehen. Das kostet nicht nur Produktivität, es verhindert auch echte Prozessverbesserung: Wer ständig damit beschäftigt ist, die Software zu umgehen, hat keine Kapazität für Innovation.
Ein strukturierter Entscheidungsrahmen
Statt die Entscheidung von Vorurteilen leiten zu lassen („Standard ist günstiger“ oder „Individual ist besser“), hilft ein strukturierter Bewertungsrahmen.
Prozess-Fit prüfen: Wie viel Prozent der Anforderungen deckt die Standardlösung tatsächlich ab? Ein ehrlicher Abgleich, nicht die Prospekt-Version des Anbieters, sondern ein Test mit den eigenen Prozessen. Unter 60% Abdeckung wird es schwer, die Lücken wirtschaftlich zu schließen.
Total Cost of Ownership über 5 bis 7 Jahre rechnen: Nicht nur Anschaffungs- oder Entwicklungskosten, sondern die Gesamtkosten: Lizenzen, Wartung, Schulungen, Anpassungen, Workarounds, Opportunitätskosten. Dieser Vergleich ergibt häufig ein anderes Bild als der reine Anfangspreis.
Abhängigkeiten bewerten: Was geschieht, wenn der Standardanbieter den Preis verdoppelt? Die Lösung abkündigt? Die Daten in eine andere Cloud migriert? Wie hoch ist der Migrationsaufwand, wenn gewechselt werden muss? Diese Szenarien sind nicht hypothetisch, sie treten regelmäßig ein.
Die strategische Bedeutung des Prozesses einschätzen: Ist der Prozess ein Differenzierungsmerkmal? Wenn ja, sollte die Software diesen Prozess stärken. Ist er Standard? Dann reicht Standard.
Vermeide die Vorurteilsfalle: Weder „Individual ist zu teuer“ noch „Standard passt nie“ ist eine fundierte Aussage. Beide Optionen haben ihre Berechtigung. Die Entscheidung sollte auf der konkreten Analyse basieren, nicht auf der generellen Überzeugung.
Checkliste Individualsoftware
Die Kosten der falschen Entscheidung
Beide Fehler kosten. Individualsoftware für einen Standardprozess ist eine Investition in Flexibilität, die nicht gebraucht wird. Der Entwicklungsaufwand, die laufende Wartung und die Weiterentwicklung stehen einem Nutzen gegenüber, der mit einer deutlich günstigeren Standardlösung genauso hätte erreicht werden können.
Standardsoftware für einen differenzierenden Prozess ist ein anderer Fehler. Die Lizenzkosten erscheinen niedrig, aber die Folgekosten durch Workarounds, Ineffizienz, Frustration und verpasste Geschäftschancen summieren sich über Jahre. Und sie sind schwerer zu beziffern, weil sie nicht als einzelner Posten in der Buchhaltung auftauchen.
Die Entscheidung verdient mehr als eine oberflächliche Diskussion im Meeting. Sie verdient eine sorgfältige Analyse, belastbare Zahlen und die Bereitschaft, gegen die erste Intuition zu entscheiden, wenn die Analyse es nahelegt.
Fazit
Die Frage „Standard oder Individual?“ hat keine pauschale Antwort. Aber sie hat einen klaren Entscheidungsprozess. Prozesse analysieren, Kosten über die Laufzeit rechnen, Abhängigkeiten bewerten, strategische Bedeutung einschätzen. Wenn diese Schritte sorgfältig durchlaufen werden, fällt die Entscheidung in den meisten Fällen eindeutiger aus als erwartet.
„Individualsoftware ist uns viel zu teuer.“ Dieser Satz fällt in fast jedem Erstgespräch. Die Annahme dahinter: Standardsoftware ist günstiger, weil die Entwicklungskosten auf viele Kunden verteilt werden. Individualsoftware ist ein Luxus, den sich nur Großkonzerne leisten können.
Diese Annahme lässt sich mit konkreten Zahlen widerlegen. Nicht in jedem Fall, aber in deutlich mehr Fällen, als die meisten erwarten.
Individualsoftware Kosten im konkreten Vergleich
Ein Kunde suchte eine neue Lösung für die Verwaltung von 50.000 Anleger-Anteilen. Die alte Software, eine Standardlösung, wurde abgekündigt. Der naheliegende Ansatz: wieder Standardsoftware.
Nach Recherche und Angebotseinholung ergab sich ein Lizenzpreis von 66.000 Euro pro Jahr für die am besten passende Standardlösung. Genutzt hätte der Kunde davon etwa 20% der Funktionen. Die restlichen 80% hätte er mitbezahlt, ohne sie jemals einzusetzen.
Das war der Anlass, die Kosten für eine Individuallösung ehrlich dagegen zu rechnen:
Standardsoftware über 7 Jahre: Lizenz 66.000 Euro pro Jahr, ergibt 462.000 Euro. Dazu jährliche Preisanpassungen durch den Anbieter, auf die der Kunde keinen Einfluss hat. Plus Kosten für Schulungen und Workarounds in den 80% der Funktionen, die nicht zum Prozess passen.
Individualsoftware über 7 Jahre: Entwicklung 150.000 Euro einmalig, Wartung ca. 15.000 Euro pro Jahr, ergibt 255.000 Euro. Der Kunde zahlt ausschließlich für die Funktionen, die er tatsächlich braucht. Die jährlichen Wartungskosten sind planbar und verhandelbar.
Unter dem Strich sind das 207.000 Euro weniger über 7 Jahre. Ab dem achten Jahr spart der Kunde jedes weitere Jahr 51.000 Euro, ohne Zusatzinvestition.
Die versteckten Kosten von Standardsoftware
Der Lizenzpreis ist der sichtbare Teil der Kosten. Die weniger sichtbaren Kosten werden bei der Entscheidung häufig nicht berücksichtigt:
Lizenzkosten skalieren mit der Unternehmensgröße: Mehr Mitarbeiter, mehr Nutzer, mehr verwaltete Objekte bedeuten bei den meisten Standardanbietern höhere Lizenzgebühren. Bei Individualsoftware bleibt die Wartungspauschale konstant, unabhängig davon, wie viele Nutzer das System verwenden. Für wachsende Unternehmen kann dieser Unterschied über die Jahre erheblich werden.
Anpassungen sind teuer oder unmöglich: Wenn der eigene Prozess nicht exakt zum Standard passt, gibt es zwei Wege: Den Prozess an die Software anpassen, was Workarounds und Produktivitätsverluste bedeutet. Oder teure Customizings beauftragen, deren Kompatibilität bei jedem Update des Standardprodukts neu geprüft werden muss. Beides verursacht Folgekosten, die in der ursprünglichen Kalkulation nicht auftauchen.
Abkündigung durch den Anbieter: Standardlösungen können jederzeit eingestellt werden, wie im Fall unseres Kunden geschehen. Dann muss erneut investiert werden: in Evaluation, Migration und Einarbeitung. Bei Individualsoftware liegt die Entscheidung über Lebensdauer und Weiterentwicklung beim Kunden selbst.
Jährliche Preiserhöhungen: Der Kunde hat keinen Einfluss auf die Preispolitik des Anbieters. Preiserhöhungen von 5 bis 10% pro Jahr sind keine Seltenheit und können über die Laufzeit den Kostenvergleich deutlich verschieben.
Die richtige Analogie: Haus statt Auto
Ein häufiger Einwand: „Individualsoftware wird am Ende immer teurer als geplant.“ Das kann vorkommen. Aber der Vergleich, der oft gezogen wird, hinkt: Individualsoftware wird mit einem Serienprodukt verglichen, etwa einem Auto. Ein Auto ist ein Serienprodukt mit vorhersagbaren Kosten.
Die passendere Analogie ist der Hausbau. Ein Haus vom Architekten ist ein Unikat. Niemand erwartet, dass am Ende wirklich alles exakt so läuft wie zu Beginn geplant. Wünsche ändern sich im Prozess, technische Gegebenheiten erfordern Anpassungen, gesetzliche Rahmenbedingungen ändern sich. Das ist kein Zeichen für schlechte Planung, sondern die Natur eines komplexen, maßgeschneiderten Projekts.
Der entscheidende Unterschied: Am Ende steht etwas, das genau zu den eigenen Anforderungen passt. Kein Standardgrundriss, in den man sich hineinleben muss. Sondern ein Gebäude, das für den konkreten Bedarf geplant und gebaut wurde.
Fünf Aspekte jenseits der Kostenfrage
Individualsoftware ist nicht nur eine Kostenfrage. Es gibt Aspekte, die in der reinen Kostenbetrachtung untergehen:
Budgetkontrolle: Der Auftraggeber steuert den Umfang selbst. Funktionen können priorisiert, verschoben oder gestrichen werden. Bei Standardsoftware bestimmt der Anbieter, welche Funktionen im Paket enthalten sind und welche nicht.
Wettbewerbsvorteil: Wenn ein Prozess der eigene Differenzierungsfaktor ist, sollte die Software diesen Prozess optimal unterstützen. Standardsoftware ist per Definition für den Durchschnitt gebaut. Wer sich vom Wettbewerb unterscheiden will, braucht eine Lösung, die diese Unterscheidung technisch abbildet.
Unabhängigkeit: Keine Abhängigkeit von Release-Zyklen, Preiserhöhungen oder strategischen Entscheidungen eines Drittanbieters. Die Hoheit über Daten, Infrastruktur und Weiterentwicklung liegt beim Kunden.
Flexibilität: Änderungen am Prozess erfordern Änderungen an der Software, nicht umgekehrt. Das klingt selbstverständlich, ist aber bei Standardsoftware oft nicht gegeben: Dort muss sich der Prozess an die Software anpassen.
Bilanzierung als Vermögenswert: Individuelle Software ist ein Vermögenswert in der Buchhaltung, kein laufender Kostenfaktor. Sie ist eine Investition, die Wert schafft und abgeschrieben werden kann. Dieser Aspekt wird bei der Entscheidungsfindung häufig übersehen.
Checkliste Individualsoftware
Wann Standardsoftware trotzdem sinnvoll ist
Um ein vollständiges Bild zu geben: Individualsoftware ist nicht in jedem Fall die bessere Wahl.
Standardsoftware ist sinnvoll, wenn der eigene Prozess dem Branchenstandard entspricht und kein Differenzierungsmerkmal darstellt. Wenn eine schnelle Verfügbarkeit wichtiger ist als Passgenauigkeit. Wenn das Unternehmen von der kontinuierlichen Weiterentwicklung durch den Anbieter profitiert. Und wenn die Abhängigkeit vom Anbieter bewusst in Kauf genommen wird.
Die Grenze verläuft dort, wo der eigene Prozess zum Wettbewerbsvorteil wird. Wenn das Geschäftsmodell darauf basiert, etwas anders oder besser zu machen als die Konkurrenz, sollte die Software das unterstützen, nicht nivellieren.
Fazit
Die Entscheidung zwischen Standard- und Individualsoftware ist keine reine Kostenfrage. Sie ist eine strategische Frage: Soll der Prozess sich an die Software anpassen, oder soll die Software den Prozess abbilden? Wer nur den Anfangspreis vergleicht, übersieht die langfristigen Kosten. In vielen Fällen, insbesondere wenn die Standardlösung nur teilweise passt, ist Individualsoftware nicht nur die passendere, sondern auch die wirtschaftlichere Lösung.
Sie sehen gerade einen Platzhalterinhalt von Facebook. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von Instagram. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Sie sehen gerade einen Platzhalterinhalt von X. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
