Selbst entwickeln oder kaufen? Software für Modeunternehmen auswählen
Individualsoftware verspricht perfekte Passung, Standardsoftware Tempo und weniger Risiko. Ein praktischer Rahmen, um zu entscheiden, welcher Weg zu welchem Bereich eines Modeunternehmens passt.
DAS WICHTIGSTE Zusammenfassung der Redaktion
- Kaufen Sie Software für Prozesse, die in der Branche üblich sind, und erwägen Sie eine Eigenentwicklung nur dort, wo ein Prozess die Marke wirklich differenziert.
- Die wahren Kosten von Individualsoftware werden von langfristiger Wartung, Sicherheit und personeller Kontinuität bestimmt, nicht von der Erstentwicklung.
- Standardsoftware verlangt von der Organisation, einige Prozesse anzupassen, was oft eher ein Vorteil als ein Kompromiss ist.
- Ein hybrides Modell, bei dem Kernsysteme gekauft und schlanke individuelle Schichten über APIs gebaut werden, ist bei mittelgrossen Marken das häufigste Ergebnis.
- Die Entscheidung sollte überprüft werden, wenn sich Markt und Marke verändern, denn was vor einigen Jahren einzigartig war, ist heute womöglich Standard.
Der Vertriebsleiter einer Modemarke wünscht sich einen besseren Weg, über den Einkäufer Re-Orders platzieren können. Der interne Entwickler sagt, das liesse sich in einigen Monaten bauen. Ein Anbieter offeriert eine fertige Lösung. Beide Optionen wirken plausibel, und die Entscheidung wird das Unternehmen über Jahre prägen. Selbst entwickeln oder kaufen ist eine der folgenreichsten Technologieentscheidungen von Führungskräften, und sie ist selten so einfach wie der Vergleich zweier Offerten.
Worüber wird eigentlich entschieden?
Selbst entwickeln oder kaufen ist ein Kürzel für eine ganze Bandbreite an Optionen. Am einen Ende schreibt die Marke eigene Software und besitzt sie. Am anderen abonniert sie ein Standardprodukt und nutzt es so, wie es geliefert wird. Dazwischen liegen konfigurierbare Plattformen, individuelle Erweiterungen von Standardsystemen und Low-Code-Werkzeuge. Die eigentliche Frage lautet, wie viel einer bestimmten Fähigkeit die Marke selbst besitzen und pflegen will.
| Option | Passung zum Prozess | Zeit bis zum Nutzen | Langfristiger Aufwand | Hauptrisiko |
|---|---|---|---|---|
| Standard kaufen | Gut für übliche Prozesse | Schnell | Gering, der Anbieter pflegt | Gewisse Prozessanpassung nötig |
| Kaufen und konfigurieren | Hoch innerhalb der Grenzen des Produkts | Mittel | Moderat | Überkonfiguration, komplexe Upgrades |
| Kern kaufen, Schichten bauen | Hoch, wo es darauf ankommt | Mittel | Moderat bis hoch | Erfordert Integrationsdisziplin |
| Vollständig selbst entwickeln | Exakt | Langsam | Hoch, die Marke pflegt alles | Abhängigkeit von wenigen Personen, steigende Kosten |
Wann ist Kaufen sinnvoller?
Für die meisten Prozesse eines Modeunternehmens ist Kaufen die sicherere Standardwahl. Auftragsverwaltung, Fakturierung, Lagerbetrieb, Workflows der Produktentwicklung und Wholesale-Ordering sind über Marken hinweg weitgehend ähnlich. Anbieter mit vielen Kunden können Entwicklungskosten verteilen, mit Standards wie EDI oder Steuerregeln Schritt halten und Funktionen ergänzen, die auf Erfahrungen aus der ganzen Branche beruhen. Kaufen ist meist richtig, wenn:
- der Prozess unter Modemarken üblich ist und keinen Wettbewerbsvorteil begründet.
- der Marke ein stabiles internes Entwicklungsteam fehlt oder sie keines aufbauen will.
- Tempo zählt, etwa weil ein neuer Kanal zur nächsten Orderphase bereit sein muss.
- Compliance, Sicherheit oder Branchenstandards betroffen sind und aktuell gehalten werden müssen.
- bereits mehrere ausgereifte Produkte existieren, die von vergleichbaren Marken genutzt werden.
Wann lässt sich eine Eigenentwicklung rechtfertigen?
Eine Eigenentwicklung ist sinnvoll, wo eine Fähigkeit wirklich unverwechselbar und zentral dafür ist, wie die Marke gewinnt. Das kann ein einzigartiges Kundenerlebnis sein, eine eigene Planungsmethode oder ein ungewöhnliches Geschäftsmodell, das Standardwerkzeuge nicht abbilden können. Selbst dann bedeutet es selten, alles selbst zu bauen. Typischerweise kauft die Marke die führenden Kernsysteme und baut darauf über APIs eine schlanke, differenzierende Schicht.
Welche versteckten Kosten werden oft übersehen?
- Abhängigkeit von Schlüsselpersonen: Individualsoftware hängt oft an einem oder zwei Entwicklern. Gehen sie, geht das Wissen mit.
- Laufende Veränderung: Partnerformate, Betriebssysteme, Browser und Vorschriften ändern sich, und jede Änderung erfordert Entwicklungsarbeit.
- Opportunitätskosten: Interne Teams, die ein individuelles Werkzeug pflegen, arbeiten nicht an anderen Prioritäten.
- Überanpassung gekaufter Software: Stark veränderte Standardsysteme vereinen die Nachteile beider Wege, denn Upgrades werden so schwierig wie die Pflege von Individualcode.
- Change Management: Welcher Weg auch gewählt wird, Schulungs- und Einführungskosten sind real und werden oft unterschätzt.
Wie sollten Führungskräfte entscheiden?
Ein strukturiertes Vorgehen verhindert Entscheidungen aus Begeisterung oder Gewohnheit. Beschreiben Sie zuerst das geschäftliche Ergebnis statt der Lösung, etwa eine schnellere Re-Order-Abwicklung oder weniger Orderfehler. Beurteilen Sie dann, wie differenzierend die Fähigkeit ist, wie ausgereift der Anbietermarkt ist und ob die Organisation eine Individualentwicklung über die Zeit tragen kann.
Es lohnt sich auch, die Annahme zu hinterfragen, dass der Prozess genau so bleiben muss, wie er ist. Standardsoftware verkörpert Praktiken, die sich in vielen Unternehmen bewährt haben. Sich an sie anzupassen, kann Abläufe vereinfachen und die Einarbeitung neuer Mitarbeitender erleichtern. Anpassungen sollten den Fällen vorbehalten sein, in denen der Unterschied für Kunden oder Einkäufer wertvoll ist und nicht bloss internen Teams vertraut.
Eine nützliche Disziplin ist es, vor jeder Entscheidung aufzuschreiben, was wahr sein müsste, damit jede Option Erfolg hat: die Teamgrösse, die für die Pflege einer Eigenentwicklung nötig ist, die Prozessänderungen, die ein Standardprodukt erfordern würde, das Budget über mehrere Jahre. Diese Bedingungen nebeneinander zu sehen, macht die Wahl oft klarer als jeder Funktionsvergleich.
Überprüfen Sie die Entscheidung schliesslich regelmässig. Fähigkeiten, die einst eine Individualentwicklung erforderten, etwa mobile Order-Apps oder digitale Showrooms, sind heute Standardangebote. Eine Marke, die vor Jahren ein Werkzeug gebaut hat, bezahlt womöglich heute für die Pflege von etwas, das der Markt zuverlässiger bereitstellt. Gute Technologieführung bedeutet, nicht nur zu wissen, wann man baut, sondern auch, wann man damit aufhört.
Häufige Fragen
Ist Low-Code ein Mittelweg zwischen Entwickeln und Kaufen?
Das kann es sein, für interne Workflows und einfache Werkzeuge. Auch mit Low-Code entsteht Software, die die Marke pflegen muss, und sie kann schwer beherrschbar werden, wenn viele unverbundene Apps ohne Governance wuchern.
Wie vermeiden wir beim Kauf einen Vendor-Lock-in?
Prüfen Sie vor der Unterschrift die Exportmöglichkeiten für Daten, verfügbare APIs und die Vertragsbedingungen zum Dateneigentum. Wer Stammdaten in Systemen hält, die die Marke kontrolliert, und dokumentierte Integrationen nutzt, verringert die Abhängigkeit von einem einzelnen Produkt.
Wer sollte an einer Entscheidung zwischen Entwickeln und Kaufen beteiligt sein?
Die fachlichen Prozessverantwortlichen, die IT- oder Digitalleitung und die Finanzabteilung sollten alle beteiligt sein. Die Fachseite definiert das Ergebnis und wie differenzierend es ist, die IT beurteilt Machbarkeit und Wartung, und die Finanzabteilung vergleicht die Gesamtkosten über mehrere Jahre.
Eine Ausgabe an jedem Werktag. In fünf Minuten gelesen. Kostenlos für Branchenprofis.
