Harsh Joshi
Co-founder & Technical Director
Vergleichen Sie die Eigenentwicklung, den Kauf und das Outsourcing von Unternehmenssoftware anhand eines praktischen Entscheidungsrahmens, der Kosten, Kontrolle, Zeitplan und langfristige Risiken berücksichtigt.
Ein CTO, der auf ein defektes internes Tool starrt, hat drei Möglichkeiten: die Roadmap auf Eis zu legen und das hauseigene Team einen Ersatz entwickeln zu lassen, ein kommerzielles Produkt zu kaufen und das Geschäft daran anzupassen oder ein externes Entwicklerteam hinzuzuziehen, um eine passende Lösung zu entwickeln. Jeder Weg löst das gleiche Problem auf unterschiedliche Weise, und jeder hat achtzehn Monate später andere Konsequenzen zur Folge.
„Selbst entwickeln“, „kaufen“ und „auslagern“ sind die drei praktischen Wege zum Erwerb von Unternehmenssoftware, und bei der Entscheidung geht es nicht wirklich darum, welche Option heute am günstigsten ist. Es geht vielmehr darum, welche Option am besten zu den Anforderungen passt: Wie spezialisiert muss die Software sein, wie schnell benötigt das Unternehmen sie und inwieweit möchte das Unternehmen tatsächlich die Verantwortung für die weitere technische Entwicklung selbst tragen? Dieser Leitfaden erläutert, was die einzelnen Wege beinhalten, zeigt eine praktische Methode auf, um sie anhand Ihrer spezifischen Situation zu bewerten, und geht auf Fragen zu den Gesamtbetriebskosten ein, die oft übersehen werden, wenn eine Entscheidung schnell getroffen werden muss. Für Teams, die sich letztendlich für Outsourcing entscheiden, decken die digitalen Engineering-Dienstleistungen von Monarch Innovation genau an diesem Entscheidungspunkt maßgeschneiderte Software-, Cloud- und Daten-Engineering-Aufgaben ab.
Kaufen Sie Software, wenn der Bedarf standardisiert ist, entwickeln Sie sie selbst, wenn die Software strategisch wichtig ist und Ihr Team über die entsprechenden Kapazitäten verfügt, und lagern Sie die Entwicklung aus, wenn Sie maßgeschneiderte Software benötigen, Ihnen jedoch die internen Kapazitäten oder das erforderliche Fachwissen fehlen, um diese innerhalb des vorgegebenen Zeitrahmens bereitzustellen.
Selbst entwickeln, kaufen oder auslagern: Die kurze Antwort
| Option | Optimale Passform | Hauptvorteil | Wichtigster Kompromiss |
|---|---|---|---|
| Erstellen | Strategische, differenzierte Software mit internem Fachwissen und Kapazitäten | Maximale Kontrolle und Eigenverantwortung | Stärkeres Engagement der internen Entwicklungsabteilung |
| Kaufen | Standardisierte oder allgemeine Geschäftsfunktionen | Schnellere Implementierung und vom Anbieter verwaltete Wartung | Geringere Flexibilität und mögliche Anbieterabhängigkeit |
| Auslagern | Bedarf an maßgeschneiderter Software bei begrenzten internen Kapazitäten oder fehlenden Fachkenntnissen | Maßgeschneiderte Entwicklung ohne sofortige Einstellung | Abhängigkeit von der Qualität der Partner und vom Wissenstransfer |
Was „Build, Buy und Outsource“ eigentlich bedeuten
Bei der Eigenentwicklung entwirft, entwickelt und wartet Ihr eigenes Entwicklerteam die Software unter Einsatz interner Mitarbeiter und Infrastruktur. Beim Kauf erwerben Sie eine Lizenz für ein kommerzielles Produkt oder ein SaaS-Produkt und passen Ihre Prozesse an dessen Funktionen an. Outsourcing bedeutet, ein externes Entwicklerteam zu beauftragen – entweder für ein bestimmtes Projekt oder als festes, dauerhaftes Team –, um maßgeschneiderte Software zu entwickeln, für deren Erstellung Ihre internen Mitarbeiter weder die Zeit noch die erforderlichen Fachkenntnisse haben.
Es handelt sich hierbei nicht um dieselbe Entscheidung, die auf drei verschiedene Arten formuliert wurde. Bei der Eigenentwicklung behält man die volle Kontrolle, muss jedoch mit einem dauerhaften technischen Mehraufwand rechnen. Durch den Kauf kommt man schnell zum Einsatz, ist jedoch an die Produkt-Roadmap eines anderen Anbieters gebunden. Beim Outsourcing erhält man maßgeschneiderte Software, ohne die Mitarbeiterzahl zu erhöhen – allerdings hängt der Erfolg vollständig von der Wahl des richtigen Partners ab. Monarch Innovation arbeitet mit technischen Führungskräften in allen drei Szenarien zusammen und wird meist dann aktiv, wenn ein Team zu dem Schluss gekommen ist, dass eine maßgeschneiderte Entwicklung die richtige Entscheidung ist, aber nicht über die internen Kapazitäten verfügt, diese umzusetzen.
Warum diese Entscheidung mehr verdient als nur einen Kostenvergleich
Die meisten Vergleiche zwischen „Selbstentwicklung“ und „Kauf“ beschränken sich auf die Lizenzkosten im Vergleich zu den Gehältern der Entwickler. Dieser Vergleich geht jedoch an der eigentlichen Frage vorbei, nämlich ob die Software einen Wettbewerbsvorteil darstellt oder lediglich eine Standardfunktion ist, die auch hundert andere Unternehmen benötigen.
Ein Terminplanungs-Tool, ein Spesenabrechnungssystem oder ein Standard-CRM lohnt sich selten, von Grund auf neu zu entwickeln, da Anbieter dieses Problem bereits in einem Umfang gelöst haben, den kein einzelnes Unternehmen erreichen kann. Anders verhält es sich mit einer Preisberechnungs-Engine, die an ein firmeneigenes Geschäftsmodell gekoppelt ist, einem Fertigungssteuerungssystem, das auf einen bestimmten Produktionsprozess zugeschnitten ist, oder einer internen Plattform, die direkt Einfluss darauf nimmt, wie Kunden das Produkt erleben. Wenn die Software bestimmt, wie das Unternehmen tatsächlich arbeitet oder im Wettbewerb steht, bedeutet der Kauf eines generischen Produkts, das Unternehmen so umzugestalten, dass es den Annahmen eines anderen entspricht.
Diese Unterscheidung – ob es sich bei dem System um ein Alleinstellungsmerkmal oder um ein Massenprodukt handelt – ist der erste Filter, der die Auswahl eingrenzen sollte, noch bevor die Kosten überhaupt zur Sprache kommen.
Option 1: Eigenentwicklung
Durch die Eigenentwicklung hat ein Unternehmen die volle Kontrolle über die Roadmap, die Architektur und die Art und Weise, wie sich die Software parallel zum Geschäftsverlauf weiterentwickelt. Es gibt keinen Lieferantenvertrag, der zwischen einer neuen Anforderung und einer ausgelieferten Funktion steht, und das Team, das das System entwickelt, versteht es zudem so gut, dass es später erweitert werden kann.
Der Kompromiss besteht aus Kapazität und Zeit. Interne Entwicklungen konkurrieren um dieselben Entwicklungsstunden wie alle anderen Roadmap-Punkte, und die Einstellung von Fachkräften für ein einzelnes Projekt – sei es für eine bestimmte Cloud-Plattform, einen Bereich des Data Engineering oder einen stark von Compliance-Anforderungen geprägten Bereich – dauert Monate, über die eine schnell voranschreitende Initiative oft nicht verfügt. Die hauseigene Entwicklung trägt zudem die volle Last der langfristigen Wartung: Sicherheitspatches, Infrastruktur-Upgrades und die späteren Kosten für Software, die die Entwickler, die sie geschrieben haben, überdauert.
Eine Eigenentwicklung ist in der Regel dann am sinnvollsten, wenn die Software ein zentraler Bestandteil des Produkts selbst ist, wenn das Team bereits über das erforderliche Fachwissen verfügt und wenn das Unternehmen bereit ist, dieses System über Jahre hinweg zu betreiben und es nicht nur einmal auf den Markt zu bringen.
Option 2: Kauf einer Standard- oder SaaS-Lösung
Durch den Kauf lässt sich am schnellsten ein funktionsfähiges System einrichten, oft innerhalb von Tagen oder Wochen statt Monaten. Wartung, Sicherheitspatches und Infrastruktur werden an den Anbieter ausgelagert, und es steht ein Support-Team zur Verfügung, das die meisten der üblichen Probleme, auf die man bei einer Neuaufbauphase stoßen würde, bereits gelöst hat.
Der Kompromiss zeigt sich erst im Laufe der Zeit und nicht gleich am ersten Tag. Kommerzielle Software ist für einen breiten Markt konzipiert und passt daher selten genau zu einem bestimmten Arbeitsablauf; die Lücke wird durch manuelle Umgehungslösungen oder teure Anpassungen geschlossen. Die Lizenzkosten steigen mit der Nutzung in einem Maße, das letztendlich die Kosten einer maßgeschneiderten Lösung übersteigen kann. Eine Anbieterabhängigkeit entsteht in dem Moment, in dem die Daten, Integrationen und internen Prozesse eines Unternehmens auf ein Produkt ausgerichtet sind, über das es keine Kontrolle hat, und ein späterer Anbieterwechsel kann zu einem größeren Projekt werden als die ursprüngliche Implementierung.
Der Kauf ist in der Regel dann am sinnvollsten, wenn es sich um klar definierte Standardfunktionen handelt, für die ein ausgereifter Anbietermarkt besteht und bei denen die Differenzierung des Unternehmens ganz woanders liegt.
Option 3: Auslagerung der kundenspezifischen Entwicklung
Outsourcing liegt zwischen den beiden anderen Optionen. Es liefert maßgeschneiderte Software, die speziell für das Unternehmen entwickelt wird, ohne dass dieses dafür ein komplettes internes Team einstellen, schulen und binden muss. Ein externer Entwicklungspartner bringt vorhandenes Fachwissen im entsprechenden Technologie-Stack mit, übernimmt den Aufwand für die Personalbeschaffung und -verwaltung und kann in der Regel schneller starten, als es ein interner Rekrutierungsprozess zulassen würde.
Outsourcing ist keine Einheitslösung. Ein projektbasiertes Engagement eignet sich für ein klar umrissenes Ergebnis mit definiertem Beginn und Ende, wie beispielsweise die Ablösung eines Altsystems oder die Entwicklung einer bestimmten Integration. Ein fest zugeordnetes Entwicklerteam, das dauerhaft beschäftigt wird, fungiert eher als Erweiterung des internen Teams und eignet sich für Unternehmen mit einem kontinuierlichen Bedarf an maßgeschneiderten Entwicklungsarbeiten. Bei der Personalaufstockung werden einzelne Entwickler in ein bestehendes internes Team integriert. Dies funktioniert am besten, wenn das Unternehmen bereits über eine starke technische Führung verfügt und lediglich zusätzliche Mitarbeiter mit einer bestimmten Fachkompetenz benötigt. Der frühere Leitfaden von Monarch Innovation zur Auswahl zwischen diesen Kooperationsmodellen geht näher darauf ein, wie das Modell an die Arbeitsauslastung angepasst werden kann.
Der Nachteil des Outsourcings besteht darin, dass die Ergebnisse stark von der Partnerauswahl abhängen. Ein schwacher Partner kann das gleiche Bindungsrisiko mit sich bringen wie ein schlechter SaaS-Kauf – nur mit weniger Dokumentation und einer Codebasis, die nur er selbst versteht. Ein starker Partner hingegen kann ein Maß an Kontrolle bieten, das dem einer internen Entwicklung nahekommt, und das bei deutlich geringerem Aufwand bei der Personalbeschaffung. Der Leitfaden zu den Kosten des Outsourcings im Bereich Produktentwicklung behandelt eine ähnliche Kostenabschätzung für Hardware- und Produktentwicklungsarbeiten, und viele der gleichen Fragen zum Preismodell (Zeit- und Materialaufwand, Festpreis, dediziertes Team) gelten auch für Software-Projekte.
Entscheidungsrahmen für „Selbst entwickeln“, „Kaufen“ oder „Auslagern“
Sobald die Frage „Standardprodukt oder Alleinstellungsmerkmal?“ geklärt ist, übernehmen diese Faktoren den Großteil der verbleibenden Arbeit bei der Wahl des Weges.
| Faktor | Geschenke zusammenstellen | Geschenke kaufen | Geschenke auslagern |
|---|---|---|---|
| Strategische Differenzierung | Hoch, entscheidend für den Wettbewerbsvorteil | Geringe, standardmäßige Funktion | Hoch, aber die interne Kapazität ist begrenzt |
| Zeit für den Start | Flexibel, monatsweise möglich | Benötigt in Tagen oder Wochen | In wenigen Wochen benötigt – schneller, als es die Einstellungsprozesse zulassen |
| Interne Fachkompetenz | Bereits im Personalbestand vorhanden | Nicht erforderlich | Extern verfügbar, nicht intern |
| Interesse an langfristigem Besitz | Das ist großartig, das Team wird noch jahrelang davon profitieren | Gering, Wartung obliegt dem Anbieter | Mittel, hängt vom gewählten Engagement-Modell ab |
| Komplexität der Integration | Umfassende Kontrolle über APIs und interne Systeme | Funktioniert am besten, wenn die Integrationen standardisiert sind | Nützlich, wenn benutzerdefinierte Integrationen oder eine Datenmigration erforderlich sind |
| Erwartete Lebensdauer | Langfristige strategische Plattform | Kurzfristige oder ersetzbare Funktion | Langfristig angelegtes, maßgeschneidertes System mit externer Lieferunterstützung |
Keine einzelne Zeile entscheidet allein über das Ergebnis. Ein System, das beispielsweise hochgradig differenziert ist, aber in drei Wochen benötigt wird, spricht in der Regel eher für Outsourcing als für eine Eigenentwicklung, die nicht schnell genug umgesetzt werden kann, oder für ein kommerzielles Produkt, das nicht ausreichend angepasst werden lässt.
Ein einfacher Entscheidungsbaum für „Selbstentwicklung“, „Kauf“ und „Auslagerung“
- Handelt es sich bei der Software um eine standardisierte oder eine Standardfunktion?
- Ja: Beginnen Sie damit, etablierte kommerzielle oder SaaS-Produkte zu prüfen.
- Nein: Ist die Software für das Unternehmen von strategischer Bedeutung?
- Ja: Verfügen Sie über das interne Fachwissen und die technischen Kapazitäten, um das System zu entwickeln und zu warten?
- Ja: Eine Eigenentwicklung könnte in die Roadmap passen.
- Nein: Es könnte sinnvoller sein, die kundenspezifische Entwicklung auszulagern.
- Nein: Prüfen Sie erneut, ob der Kauf eines bereits vorhandenen Produkts den geschäftlichen Anforderungen gerecht werden kann, ohne dass übermäßige Anpassungen erforderlich sind.
Gesamtbetriebskosten: Ein Blick über das erste Jahr hinaus
Der häufigste Fehler bei dieser Entscheidung besteht darin, eine interne Gehaltsschätzung, das Lizenzangebot eines Anbieters und den Stundensatz eines Outsourcing-Partners so zu vergleichen, als handele es sich um die gleiche Art von Zahlen. Das ist jedoch nicht der Fall, und ein fairer Vergleich muss einen Zeitraum von drei bis fünf Jahren umfassen und darf sich nicht nur auf die erste Rechnung beschränken.
Eine Eigenentwicklung verursacht laufende Kosten für Gehälter und Sozialleistungen, unabhängig davon, ob die Roadmap für dieses Team in jedem Quartal aktive Aufgaben vorsieht, sowie Kosten für Infrastruktur, Sicherheit und eine eventuelle Neuprogrammierung, die mit jedem System einhergehen, das alt genug ist, um als Legacy-System zu gelten. Eine gekaufte Lösung verursacht wiederkehrende Lizenzgebühren, die in der Regel mit der Nutzung oder der Anzahl der Benutzer skalieren, sowie Kosten für interne Workarounds für alles, was das Produkt nicht von Haus aus leistet, und echte, oft unterschätzte Kosten für eine spätere Abwanderung von diesem System. Eine ausgelagerte Entwicklung verursacht die Kosten für das Dienstleistungsverhältnis selbst sowie den internen Aufwand, der zur Pflege der Geschäftsbeziehung und schließlich zur Wartung oder Erweiterung des gelieferten Systems erforderlich ist. Aus diesem Grund müssen Klarheit hinsichtlich der Dokumentation und der Übergabe von Anfang an im Vertrag festgehalten werden.
Keiner dieser Wege ist von vornherein kostengünstiger. Der richtige Vergleich berücksichtigt, was das System im dritten Jahr leisten muss, und nicht nur, was die Einrichtung im ersten Monat kostet.
Wann welcher Weg sinnvoll ist
Anhand einiger realistischer Szenarien lässt sich das Muster leichter anwenden als das Framework allein:
- Ein handelsübliches CRM- oder Spesenmanagement-Tool. Kaufen. Der Markt ist ausgereift, die Funktion stellt kein Alleinstellungsmerkmal dar, und eine interne Entwicklung würde bedeuten, ein Problem neu zu lösen, das Anbieter bereits gut gelöst haben.
- Eine Preis- oder Angebotsberechnungs-Engine, die an ein firmeneigenes Geschäftsmodell gekoppelt ist. Je nach interner Kapazität sollte diese entweder selbst entwickelt oder ausgelagert werden. Genau diese Art von System ist entscheidend für den Wettbewerbsvorteil, sodass ein Standardprodukt ohne erhebliche Abstriche nicht geeignet ist.
- Ein veraltetes Fertigungssteuerungssystem, das innerhalb einer knappen Frist ersetzt werden muss. Auslagern. Das System ist so spezifisch, dass eine maßgeschneiderte Entwicklung erforderlich ist, doch es ist selten realistisch, ein internes Team so schnell einzustellen und einzuarbeiten, dass die Frist eingehalten werden kann.
- Eine interne Plattform, für die Ihr Produktteam in den nächsten zehn Jahren verantwortlich sein und die es weiterentwickeln wird. Beginnen Sie mit der Entwicklung, sobald das Team über das erforderliche Fachwissen verfügt, denn langfristige Verantwortung und ein tiefgreifendes Verständnis der internen Zusammenhänge sind hier wichtiger als eine schnelle Markteinführung.
Häufige Fehler bei der Entscheidung zwischen „Selbstentwicklung“, „Zukauf“ und „Auslagerung“
Es gibt eine Handvoll Muster, die immer wieder auftreten, wenn diese Entscheidung falsch ausfällt. Am häufigsten wird sie als einmalige Entscheidung betrachtet: Die geschäftlichen Anforderungen ändern sich, und ein System, das vor zwei Jahren als Standardlösung angeschafft wurde, kann zu einem strategischen Engpass werden, sobald sich das Unternehmen durch dieses System von der Konkurrenz abhebt. Ein weiterer Fehler ist der Vergleich ausschließlich der Kosten im ersten Jahr, da sich Lizenzgebühren, Gehälter und Outsourcing-Sätze über einen Zeitraum von drei bis fünf Jahren unterschiedlich entwickeln. Auch die Unterschätzung des Integrations- und Migrationsaufwands verursacht erheblichen Schaden, insbesondere bei gekaufter Software, die vom ersten Tag an mit fünf anderen internen Systemen verbunden werden muss. Die Auswahl eines Outsourcing-Partners allein anhand des Preises, ohne die Dokumentationspraktiken, den Kommunikationsrhythmus oder die Frage zu prüfen, was mit dem Code nach Beendigung des Auftrags geschieht, führt in der Regel genau zu dem Lock-in-Problem, das durch das Outsourcing eigentlich vermieden werden sollte. Schließlich ist das Überspringen einer gründlichen Bewertung der internen Kapazitäten – in der Annahme, ein bereits ausgelastetes Team könne ein Entwicklungsprojekt zusätzlich zu seiner bestehenden Roadmap bewältigen – ein häufiger Grund dafür, dass interne Projekte still und leise ein Jahr lang ins Stocken geraten.
Bewertung eines Outsourcing-Partners, bevor Sie sich festlegen
Wenn Outsourcing der richtige Weg ist, ist die Wahl des Partners genauso wichtig wie die Entscheidung selbst. Einige Fragen sollten unbedingt geklärt werden, bevor ein Vertrag unterzeichnet wird: Welche Ingenieure werden konkret an dem Projekt arbeiten, und bleiben sie während der gesamten Projektlaufzeit zugewiesen? Welche Dokumentation, welcher Quellcode und welche Architekturentscheidungen werden bei Projektabschluss übergeben, und in welchem Format? Wie geht der Partner mit einer Anforderungsänderung während des Projekts um, und wie wirkt sich das auf Kosten und Zeitplan aus? Was geschieht mit dem Unternehmenswissen, wenn das Projekt endet oder wichtige Mitarbeiter wechseln? Ein Partner, der diese Fragen konkret beantwortet, anstatt nur allgemeine Zusicherungen zu geben, ist in der Regel die sicherere Wahl, und dieselbe Bewertungslogik gilt unabhängig davon, ob es sich um ein projektbasiertes Engagement, ein festes Team oder eine Personalaufstockung handelt.
Einen Weg wählen, der zu Ihrem Plan passt
„Selbst entwickeln“, „kaufen“ und „auslagern“ sind keine konkurrierenden Ansätze. Es handelt sich um drei Instrumente, die für unterschiedliche Situationen geeignet sind, und die richtige Lösung für ein System in Ihrer Roadmap kann für das nächste System die falsche Lösung sein. Bevor man sich festlegt, sollte man sich folgende Fragen stellen: Wie differenziert ist das System tatsächlich, wie viel interne Kapazität steht für den Betrieb zur Verfügung und wie sehen die Gesamtkosten in drei Jahren aus – und nicht nur auf der ersten Rechnung?
Monarch Innovation arbeitet mit führenden Ingenieuren aus den Bereichen maßgeschneiderte Software, Cloud und Data Engineering zusammen und wird oft genau an diesem Entscheidungspunkt hinzugezogen, wenn ein System maßgeschneidert entwickelt werden muss, das interne Team jedoch kein weiteres langwieriges Projekt übernehmen kann. Wenn Sie abwägen, ob Sie ein bevorstehendes System selbst entwickeln, kaufen oder ein externes Entwicklerteam hinzuziehen sollen, wenden Sie sich an Monarch Innovation, um die spezifischen Vor- und Nachteile für Ihre Roadmap zu besprechen.
Besprechen Sie Ihre Strategie zur Softwareentwicklung
Sie überlegen, ob Sie die Lösung selbst entwickeln, ein kommerzielles Produkt kaufen oder ein externes Entwicklerteam beauftragen sollen? Wenden Sie sich an Monarch Innovation, um gemeinsam mit unserem Entwicklerteam die Anforderungen an Ihr System, den Zeitplan und die langfristigen Betriebsanforderungen zu besprechen.
Häufig gestellte Fragen zum Thema „Selbst entwickeln, kaufen oder auslagern“
Was ist der Unterschied zwischen der Eigenentwicklung, dem Kauf und der Auslagerung der Softwareentwicklung?
„Build“ bedeutet, dass Ihr internes Team die Software entwirft, entwickelt und wartet. „Buy“ bedeutet, dass Sie eine Lizenz für ein kommerzielles Produkt oder ein SaaS-Produkt erwerben und Ihre Geschäftsprozesse daran anpassen. „Outsource“ bedeutet, dass ein externer Technikpartner maßgeschneiderte Software für Ihr Unternehmen entwickelt, in der Regel im Rahmen eines Projektvertrags, mit einem dedizierten Team oder durch Personalverstärkung.
Ist es besser, maßgeschneiderte Software entwickeln zu lassen oder SaaS zu kaufen?
Das hängt davon ab, ob der Bedarf standardisiert oder strategisch differenziert ist, in welchem Umfang Anpassungen und Integrationen erforderlich sind, wie schnell das System benötigt wird und ob Ihr internes Team über die Kapazitäten und das Fachwissen verfügt, um die Software über ihre gesamte Lebensdauer hinweg zu betreuen – und nicht nur bei der Einführung.
Wie entscheide ich mich bei Unternehmenssoftware zwischen „selbst entwickeln“, „kaufen“ oder „auslagern“?
Fragen Sie sich zunächst, ob das System ein Wettbewerbsvorteil oder eine Standardfunktion ist. Bei Standardanforderungen ist der Kauf in der Regel die bessere Wahl. Bei differenzierten Systemen empfiehlt sich die Eigenentwicklung oder das Outsourcing, und die Entscheidung zwischen diesen beiden Optionen hängt oft davon ab, ob Ihr internes Team über die Kapazitäten und die erforderlichen Fachkenntnisse verfügt, um das System rechtzeitig zu entwickeln.
Ist das Outsourcing der Softwareentwicklung kostengünstiger als die Eigenentwicklung?
Nicht immer, und ein Vergleich der Stundensätze allein mit den Gehältern ist irreführend. Durch Outsourcing lassen sich die Fixkosten für die Einstellung neuer Vollzeitmitarbeiter sowie der monatelange Einstellungsprozess vermeiden, doch die Gesamtkosten hängen nach wie vor vom Projektumfang, der Anzahl der Iterationen und davon ab, wie das Projekt im Laufe der Zeit gesteuert wird.
Was ist das größte Risiko, wenn man kommerzielle Software kauft, anstatt sie selbst zu entwickeln?
Das größte Risiko ist die Anbieterabhängigkeit. Sobald interne Prozesse, Daten und Integrationen auf ein gekauftes Produkt ausgerichtet sind, kann der Wechsel zu einem anderen Anbieter oder die spätere Entwicklung einer Ersatzlösung zu einem größeren und kostspieligeren Projekt werden, als es die ursprüngliche Implementierung jemals war.
Wann ist Outsourcing sinnvoller als eine Eigenentwicklung?
Outsourcing eignet sich in der Regel am besten, wenn die Software maßgeschneidert entwickelt werden muss, dem internen Team jedoch die erforderlichen Fachkenntnisse oder die Kapazitäten fehlen, um sie innerhalb des vorgegebenen Zeitrahmens fertigzustellen, da ein Partner in der Regel schneller mit der Arbeit beginnen kann, als es ein vollständiger Einstellungszyklus zulässt.
Was sollte ich fragen, bevor ich mich für einen Software-Outsourcing-Partner entscheide?
Fragen Sie, welche konkreten Ingenieure an dem Projekt arbeiten werden, welche Dokumentation und welchen Quellcode Sie nach Abschluss des Projekts erhalten, wie mit Änderungen der Anforderungen während des Projekts umgegangen wird und was mit dem institutionellen Wissen geschieht, wenn das Projekt endet. Konkrete Antworten sind aussagekräftiger als allgemeine Zusicherungen.
Sind die Gesamtbetriebskosten wichtiger als der Anschaffungspreis?
Ja, in den meisten Fällen. Eigenentwicklung, Kauf und Outsourcing weisen über einen Zeitraum von drei bis fünf Jahren jeweils unterschiedliche Kostenmuster auf, einschließlich Wartungs-, Lizenzerweiterungs- und Migrationskosten, und wenn man nur die erste Rechnung vergleicht, führt dies häufig zu einer Entscheidung, die sich bereits nach ein oder zwei Jahren als falsch herausstellt.
Kann sich die Entscheidung zwischen „Selber entwickeln“, „Kaufen“ und „Auslagern“ im Laufe der Zeit ändern?
Das kann passieren und ist oft der Fall. Ein System, das als Standardlösung angeschafft wurde, kann zu einem strategischen Engpass werden, sobald sich ein Unternehmen dadurch von der Konkurrenz abhebt. Deshalb lohnt es sich, diese Entscheidung im Zuge von geschäftlichen Veränderungen regelmäßig zu überdenken, anstatt sie als endgültig zu betrachten.
