Make-or-Buy bei Unternehmenssoftware: Kaufen oder entwickeln lassen

Eine Standardsoftware deckt achtzig Prozent einer Funktionsliste ab, zwingt den wichtigsten Auftragsprozess aber in manuelle Umwege. Eine Eigenentwicklung bildet den Ablauf passend ab, benötigt dafür Konzeption, Betrieb und Weiterentwicklung. Make-or-Buy bei Unternehmenssoftware ist deshalb keine Entscheidung zwischen billig und teuer, sondern zwischen unterschiedlichen Kosten, Abhängigkeiten und Gestaltungsmöglichkeiten.

In vielen Projekten ist eine Mischform wirtschaftlich: Standardsoftware übernimmt etablierte Funktionen, Schnittstellen verbinden die Daten und eine individuelle Anwendung bildet den geschäftsspezifischen Teil ab. Die Bewertung muss diesen dritten Weg ausdrücklich zulassen.

SW Business Solutions prüft vorhandene Systeme und reale Prozessfälle, bevor eine Entwicklungsleistung empfohlen wird. Ziel ist eine tragfähige Architektur, nicht möglichst viel individuelle Software.

Die Entscheidung bleibt damit technisch und wirtschaftlich überprüfbar, statt von einer frühen Produktvorliebe abzuhängen.

Die Kriterien gelten für den gesamten vorgesehenen Nutzungszeitraum.

Make-or-Buy bei Unternehmenssoftware beginnt mit dem Zielprozess

Eine Funktionsliste beschreibt einzelne Möglichkeiten, aber nicht deren Zusammenspiel. Für die Entscheidung wird ein vollständiger Vorgang mit Rollen, Daten, Freigaben, Ausnahmen und Fehlerwegen formuliert.

Anbieter und Entwicklungskonzepte bearbeiten dieselben anonymisierten Testfälle. Dadurch wird sichtbar, ob Standardsoftware nur den Normalfall zeigt oder den tatsächlichen Prozess trägt.

Der Umfang wird begrenzt. Eine Entscheidung für CRM muss nicht gleichzeitig Buchhaltung, DMS und Kundenportal lösen.

Standardsoftware nutzt vorhandene Produktreife

Etablierte Produkte bieten erprobte Funktionen, Updates, Dokumentation und einen bestehenden Betrieb. Bei Standardprozessen kann das Zeit und Entwicklungsrisiko reduzieren.

Der Nutzen hängt von Konfigurierbarkeit und Prozesspassung ab. Viele Zusatzmodule, Workarounds und doppelte Pflege können den Einstiegsvorteil aufzehren.

Hersteller-Roadmap und Support gelten für viele Kunden. Ein einzelnes Unternehmen kontrolliert Prioritäten und Zeitpunkte nur begrenzt.

Individualsoftware bildet besondere Geschäftslogik ab

Eine eigene Anwendung kann Rollen, Regeln und Bedienung gezielt auf das Unternehmen ausrichten. Sie eignet sich für Prozesse, die Umsatz, Kapazität oder Kundenerlebnis wesentlich unterscheiden.

Das Unternehmen trägt dafür Konzeption, Entwicklung, Qualität, Betrieb und Weiterentwicklung. Diese Aufgaben können extern erbracht werden, müssen aber verantwortlich organisiert sein.

Der bestehende Beitrag erläutert ausführlich, wann sich individuelle Softwareentwicklung lohnt.

Die Mischform trennt Standard und Differenzierung

Buchhaltung, Identität, Zahlung oder Dokumentenablage müssen selten vollständig neu entwickelt werden. Standardkomponenten können diese Aufgaben übernehmen.

Eine individuelle Oberfläche oder Integrationsschicht verbindet sie mit dem besonderen Kunden-, Auftrags- oder Serviceprozess. Dadurch bleibt Fachlogik kontrollierbar, ohne jede technische Grundlage selbst zu bauen.

Die Systemgrenzen werden bewusst definiert. Ein unklarer Mix kann sonst mehr Schnittstellen und Verantwortungslücken erzeugen.

Strategische Bedeutung beeinflusst die Entscheidung

Unterstützt Software nur eine allgemeine Verwaltungsaufgabe, spricht viel für Standard. Prägt der digitale Prozess das Leistungsangebot oder den Wettbewerbsvorteil, kann mehr Kontrolle wirtschaftlich wichtig sein.

Strategisch bedeutet nicht automatisch selbst entwickeln. Ein starkes Standardprodukt kann den Markt schneller erschließen. Entscheidend ist, welche Fähigkeit das Unternehmen kontrollieren und verändern können muss.

Diese Einschätzung wird durch Geschäftsführung und Prozesseigentümer getroffen, nicht allein durch IT.

Time-to-Value wird bis zum stabilen Betrieb gerechnet

Standardsoftware ist häufig schnell lizenziert, aber Einführung, Daten und Integration benötigen weiterhin Zeit. Eine Eigenentwicklung kann mit einem engen vollständigen Prozess starten und danach ausgebaut werden.

Verglichen wird der Zeitpunkt, an dem Nutzer den Prozess zuverlässig im Betrieb ausführen. Eine Demo oder erste Maske ist kein wirtschaftlicher Nutzen.

Interne Entscheidungen und Testkapazität beeinflussen beide Wege. Unklare Anforderungen verzögern Kauf und Entwicklung gleichermaßen.

Total Cost of Ownership schafft eine gemeinsame Basis

Beim Kauf zählen Lizenz, Implementierung, Module, Integration, Migration, Schulung, Administration und Anbieterwechsel. Bei Entwicklung zählen Konzeption, Bau, Hosting, Wartung, Support und Weiterentwicklung.

Beide Wege werden über denselben Zeitraum und Funktionsumfang betrachtet. Die Kosten der Digitalisierung im Unternehmen zeigen die dafür relevanten Preisfaktoren.

Ein niedriger Startpreis darf nicht gegen eine vollständige mehrjährige Lösung verglichen werden.

Prozessanpassung kann wirtschaftlicher als Softwareanpassung sein

Nicht jede Besonderheit besitzt geschäftlichen Wert. Historische Freigaben, lokale Vorlagen oder persönliche Feldreihenfolgen können vereinheitlicht werden.

Wenn Standardisierung Fehler und Betrieb reduziert, ist Prozessanpassung sinnvoll. Zwingt sie dagegen den entscheidenden Leistungsablauf in unpassende Regeln, entstehen dauerhafte Kosten.

Jede Abweichung wird nach Nutzen, Häufigkeit und Folge bewertet, nicht nach Lautstärke des Wunsches.

Konfiguration hat Grenzen und Folgekosten

No-Code-Regeln, benutzerdefinierte Felder und Plugins können Standardsoftware weit anpassen. Zu viele Erweiterungen erschweren Updates, Tests und Support.

Herstellergrenzen werden früh geprüft. Eine scheinbar mögliche Konfiguration kann nur im höchsten Tarif oder ohne ausreichende Rechte verfügbar sein.

Dokumentation und Eigentümer der Konfiguration gehören zum Betrieb.

Integrationsfähigkeit entscheidet über den Gesamtprozess

Eine gute Einzellösung kann unwirtschaftlich sein, wenn Daten manuell in andere Systeme gelangen. APIs, Webhooks, Export, Identitäten und Fehlerbehandlung werden praktisch getestet.

Bei Eigenentwicklung können Schnittstellen gezielt gebaut werden, bleiben aber von Fähigkeiten der Fremdsysteme abhängig. Direkter Datenbankzugriff ist selten ein nachhaltiger Ersatz.

Integration wird als eigenes Arbeitspaket und laufende Verantwortung kalkuliert.

Datenzugang und Exit begrenzen Abhängigkeit

Das Unternehmen prüft, ob Kunden, Aufträge, Dokumente, Aktivitäten und Beziehungen vollständig exportierbar sind. Eine CSV mit Kontakten genügt nicht für jeden Wechsel.

Bei Individualsoftware werden Datenmodell, Quellcodezugang, Dokumentation und Nutzungsrechte vertraglich geklärt. Auch hier kann Abhängigkeit vom Entwicklungspartner entstehen.

Ein Exit-Plan macht beide Wege kontrollierbarer, ohne einen frühen Wechsel zu unterstellen.

Sicherheits- und Compliance-Anforderungen werden gleich geprüft

Ein großer Anbieter ist nicht automatisch passend, eine Eigenentwicklung nicht automatisch unsicher. Rollen, Protokolle, Sicherung, Schwachstellenmanagement und Betrieb werden am konkreten Risiko bewertet.

Standardprodukte liefern Zertifikate und Vertragsunterlagen, deren Geltungsbereich geprüft wird. Eigenentwicklungen benötigen sichere Entwicklungs- und Betriebsprozesse.

Rechtliche Entscheidungen bleiben bei zuständigen Verantwortlichen. Technik setzt die Anforderungen nachvollziehbar um.

Interne Kompetenz bestimmt die tragfähige Kontrolle

Ein Unternehmen muss nicht selbst programmieren, braucht aber fachliche Eigentümer, Anbietersteuerung und Entscheidungsfähigkeit. Niemand darf der einzige Kenner von Daten, Konfiguration oder Freigaben sein.

Standardsoftware benötigt Administration und Releasebewertung. Individualsoftware benötigt Produkt- oder Prozessverantwortung und technischen Betrieb, intern oder vertraglich abgesichert.

Fehlt diese Kapazität, wird ein engerer Umfang oder stärker betreuter Betrieb gewählt.

Skalierung wird anhand realer Treiber bewertet

Nutzer, Standorte, Transaktionen, Datenvolumen und Varianten beeinflussen Kosten. Standardprodukte skalieren technisch oft gut, können aber Lizenzkosten stark erhöhen.

Individualsoftware verursacht Infrastruktur- und Betriebsaufwand. Ihre Grenzkosten können bei hohem Volumen günstiger sein, sofern Architektur und Support passen.

Mehrere Szenarien verhindern, dass ein Pilotpreis ungeprüft auf Wachstum übertragen wird.

Roadmap-Kontrolle hat einen wirtschaftlichen Wert

Bei Standardsoftware bestimmt der Hersteller, wann Funktionen verändert oder eingestellt werden. Das Unternehmen profitiert von allgemeiner Weiterentwicklung, trägt aber Anpassungsrisiko.

Bei Individualsoftware priorisiert das Unternehmen selbst, muss Verbesserungen jedoch finanzieren. Fehlende Produktverantwortung kann die Lösung stagnieren lassen.

Die Entscheidung bewertet, welche Änderungen geschäftskritisch und wie planbar sie sind.

Anbieter- und Entwicklungsrisiko werden symmetrisch betrachtet

Ein SaaS-Anbieter kann Preise ändern, verkauft werden oder Funktionen einstellen. Ein Entwicklungspartner kann Kapazität verlieren, Wissen schlecht dokumentieren oder schwer ersetzbar werden.

Vertrag, Datenexport, Dokumentation, Codequalität, mehrere Ansprechpartner und Betriebsübergabe reduzieren Abhängigkeit. Kein Weg ist ohne Lieferantenrisiko.

Risiken werden mit Eintrittszeichen und Reaktion dokumentiert, nicht pauschal bewertet.

Änderungshäufigkeit beeinflusst die wirtschaftliche Kontrolle

Ein stabiler Standardprozess profitiert von einer fertigen Software. Ändern sich Angebot, Preislogik oder Partnerintegration häufig, kann die Abhängigkeit von Herstellerzyklen den Betrieb bremsen.

Bei Individualsoftware lassen sich Prioritäten selbst setzen, jede Änderung verursacht jedoch Analyse, Entwicklung und Test. Ein klarer Product Owner verhindert, dass spontane Wünsche die Lösung dauerhaft verteuern.

Die Bewertung betrachtet erwartete Änderungen der nächsten Jahre und nicht nur den heutigen Funktionsstand.

Verfügbarkeit und Support werden am Geschäftsrisiko ausgerichtet

Ein internes Archiv und ein öffentliches Buchungsportal benötigen unterschiedliche Reaktionszeiten. Standardanbieter bieten feste Servicepakete; bei Individualsoftware wird der Betrieb passend vereinbart.

Entscheidend sind Erreichbarkeit, Wiederherstellung, Statuskommunikation und Zuständigkeit über mehrere Anbieter. Eine günstige Lizenz ohne geeigneten Support kann im Ausfall hohe Kosten verursachen.

Notfall- und Ersatzwege werden praktisch geprüft. Marketingbegriffe zur Hochverfügbarkeit ersetzen keine konkrete Leistungsbeschreibung.

Eigentum an Anpassungen muss eindeutig bleiben

Plugins, Skripte und Konfigurationen rund um Standardsoftware können vom Implementierungspartner stammen. Vertrag und Dokumentation klären, wer sie warten, exportieren oder zu einem anderen Partner übertragen darf.

Bei Eigenentwicklung werden Quellcode, Nutzungsrechte, Drittanbieterbibliotheken und Zugang zu Build sowie Betrieb geklärt. Besitz des Codes allein garantiert noch keine Wartbarkeit.

Das Unternehmen benötigt ausreichend Dokumentation und kontrollierte Konten, damit ein Anbieterwechsel technisch möglich bleibt.

Open Source ist eine Beschaffungsform mit Betriebsverantwortung

Open-Source-Komponenten können Lizenzflexibilität und Quellcodezugang bieten. Einrichtung, Updates, Sicherheit, Hosting und Support bleiben jedoch kostenpflichtige Aufgaben.

Community, Lizenzbedingungen und langfristige Pflege werden geprüft. Ein öffentliches Repository ist kein Beleg, dass eine geschäftskritische Funktion dauerhaft betreut wird.

Managed Open Source kann Standardprodukt und offene Basis kombinieren. Die wirtschaftliche Bewertung folgt denselben TCO-Kriterien.

Beschaffungsverträge werden mit der Architektur gelesen

Nutzergrenzen, API-Aufrufe, Speicher, Datenregion, Unterauftragnehmer, Kündigung und Export beeinflussen die technische Lösung. Einkauf, IT und Fachbereich prüfen daher gemeinsam.

Ein günstiger Vertrag kann notwendige Integrationen ausschließen. Ein umfassendes Enterprise-Paket kann Funktionen enthalten, die kein priorisierter Prozess benötigt.

Vertragsoptionen werden auf reale Volumenszenarien gerechnet. Rabatte im ersten Jahr dürfen den langfristigen Vergleich nicht verzerren.

Migration und Übergang beeinflussen beide Wege

Auch beim Kauf müssen Daten bereinigt, Rollen eingerichtet, Nutzer geschult und alte Systeme beendet werden. Bei Entwicklung kommen möglicherweise stufenweise Funktionsübergänge hinzu.

Der Cutover-Plan zeigt letzten Alt- und ersten Neuvorgang. Befristeter Parallelbetrieb besitzt Zweck und Enddatum. Diese Einführungskosten gehören in Make-or-Buy.

Eine Lösung mit besserer Migration und sicherem Rückfall kann wirtschaftlicher sein als eine funktional stärkere Option mit hohem Umstellungsrisiko.

Personalsuche ist kein Ersatz für Produktverantwortung

Ein internes Entwicklungsteam kann strategische Kontrolle erhöhen, benötigt aber Rekrutierung, Führung, Vertretung und passende technische Breite. Eine einzelne Entwicklerstelle trägt selten Architektur, Frontend, Backend, Betrieb und Support dauerhaft allein.

Externe Entwicklung kann Kapazität und Spezialwissen bereitstellen. Interne Prozesseigentümer und Anbietersteuerung bleiben dennoch notwendig.

Make-or-Buy für Software und Make-or-Buy für Entwicklungskapazität sind zwei getrennte Entscheidungen, die gemeinsam geplant werden.

Referenzen werden nach vergleichbarer Schwierigkeit geprüft

Eine große Kundenliste belegt nicht automatisch Erfahrung mit der relevanten Integration, Offline-Nutzung oder fachlichen Logik. Referenzfälle werden nach Prozess, Systemlandschaft und Betriebsverantwortung eingeordnet.

Bei Standardsoftware helfen bestehende Kundenberichte, ersetzen aber keinen Test der eigenen Fälle. Bei Individualentwicklung zeigen Code- und Vorgehensqualität mehr als eine optisch ähnliche Oberfläche.

Offene Grenzen sind ein positives Signal, wenn der Anbieter einen belastbaren Prüfweg anbietet.

Ausschlusskriterien verhindern rechnerisch schöne Fehlentscheidungen

Fehlender notwendiger Datenexport, unzulässige Verarbeitung, nicht erfüllbare Verfügbarkeit oder eine unüberbrückbare Prozesslücke können eine Option ausschließen. Eine hohe Punktzahl in weniger wichtigen Kriterien kompensiert das nicht.

Ausschlusskriterien werden vor Bewertung festgelegt und belegt. Persönliche Produktvorlieben dürfen nicht nachträglich als zwingende Regel erscheinen.

Erst die verbleibenden Optionen werden über Gewichtung, Kosten und Risiko verglichen.

Ein Pilot prüft die kritische Differenz

Nicht jede Funktion muss vor der Entscheidung gebaut werden. Ein technischer Spike kann API, Datenexport oder schwierige Geschäftsregel prüfen. Ein produktiver Pilot testet den vollständigen Prozess begrenzt.

Standardanbieter erhalten dieselben Testfälle. Eine Eigenentwicklungsoption zeigt nur die Teile, deren Machbarkeit oder Bedienung unsicher ist.

Nach dem Pilot werden Kosten, Zeit und Prozesspassung aktualisiert.

Eine Entscheidungsmatrix macht Gewichtung sichtbar

Kriterien können Prozesspassung, Zeit, Gesamtkosten, Integration, Datenkontrolle, Sicherheit, Skalierung, Roadmap und Betrieb sein. Jedes Kriterium erhält eine begründete Gewichtung.

Bewertungen brauchen Belege aus Demo, Vertrag, Test oder technischer Prüfung. Ein Markenname ersetzt keinen Nachweis.

Die Matrix unterstützt die Entscheidung, trifft sie aber nicht automatisch. Kritische Ausschlusskriterien bleiben separat.

Beispiel CRM spricht meist für Standard plus Integration

Kontakt-, Aktivitäts- und Vertriebsgrundfunktionen sind breit verfügbar. Ein geeignetes Standard-CRM kann wirtschaftlicher sein als vollständige Neuentwicklung.

Besondere Angebotslogik, Kundenportal oder Auftragsübergabe können individuell ergänzt werden. Entscheidend ist, welches System für welche Daten führt.

Eine Eigenentwicklung des gesamten CRM benötigt einen sehr spezifischen strategischen Grund.

Beispiel Monteur-App kann eine individuelle Ergänzung rechtfertigen

Wenn Außendienstprozesse spezielle Leistungen, Offlinebetrieb, Fotos, Unterschrift und ERP-Übergabe verbinden, passen Standard-Field-Service-Produkte möglicherweise nur teilweise.

Zuerst werden vorhandene Module geprüft. Eine individuelle App kann anschließend gezielt den mobilen Ablauf abbilden, während ERP und Dokumentenablage bestehen bleiben.

Geräte, Support und Offline-Synchronisation gehören in die Wirtschaftlichkeitsrechnung.

Beispiel Buchhaltung bleibt meist Standarddomäne

Rechnungswesen unterliegt etablierten fachlichen und rechtlichen Anforderungen. Bewährte Standardsoftware ist häufig die tragfähige Basis.

Individuell entwickelt werden eher Eingang, Freigabe, Leistungsdaten oder Schnittstelle. Gebuchte Belege und verantwortliche Buchhaltungslogik bleiben im geeigneten Fachsystem.

Diese Trennung reduziert Eigenentwicklungsrisiko und erhält Prozesspassung.

SW Business Solutions empfiehlt keine Eigenentwicklung als Selbstzweck

SW Business Solutions analysiert Prozess, vorhandene Produkte, Integrationen und Gesamtkosten. Geeignete Standardsoftware wird weiter genutzt oder neu eingeführt.

Wo eine geschäftsrelevante Lücke bleibt, entwickelt SW Business Solutions individuelle Anwendungen und Schnittstellen. Architektur, Daten, Betrieb und Exit werden gemeinsam geplant.

In einem Make-or-Buy-Gespräch zur Unternehmenssoftware lassen sich Testfälle und Entscheidungskriterien abgrenzen. Das Ergebnis kann Kauf, Konfiguration, Integration, individuelle Entwicklung oder eine bewusst gestufte Mischform sein.