Individuelle Software-Entwicklung vs. Tooling

Die meisten Manager sind mit der traditionellen „Make or Buy“-Entscheidung vertraut.
Bei digitalen Projekten ist es nicht so einfach.

Wann immer du ein neues digitales Projekt startest, egal ob es sich um eine einfache Website oder eine komplexe Unternehmensanwendung handelt, stehst du vor der folgenden großen Frage:
Sollten wir bestehende Systeme kaufen und anpassen oder es von Grund auf neu bauen?

Stelle dir diese Frage als diejenige vor, die du unmittelbar nach „Make or Buy“ stellen solltest.
Beachte, dass du, egal ob du es selbst machst oder es durch die Bezahlung eines externen Dienstleisters kaufst, entscheiden musst, ob „von Grund auf neu oder bestehende Dinge konfigurieren“.

Was zu erwarten ist

Dieser Artikel beleuchtet die Schwierigkeiten dieser Frage, hebt ihre Bedeutung und Auswirkungen hervor und bietet dir einige Entscheidungshilfen.

Er richtet sich hauptsächlich an Geschäftsmanager, die Entscheidungen in digitalen Angelegenheiten treffen müssen, ohne selbst IT-Architekten zu sein.

Die Schwierigkeiten

Mehrere Ebenen

Um ehrlich zu sein, ist dies keine echte Schwarz-Weiß-Entscheidung.
Diese Frage tritt auf mehreren Ebenen auf und selbst wenn es klug ist, sich auf einer Ebene für „von Grund auf neu“ zu entscheiden, kann „bestehende Dinge konfigurieren“ auf einer anderen Ebene nützlich sein.

Um die wichtigsten Ebenen zu nennen:

1. Infrastruktur.
   Es beginnt oft mit der Frage, wo eine Anwendung gehostet werden soll. Du könntest dich um alle Infrastrukturdetails kümmern (von Grund auf) oder Serviceangebote nutzen, um den Aufwand hier zu minimieren. Siehe den Artikel “PaaS vs. IaaS vs. running your own Server Network — a Management Perspective” für weitere Details.
2. Anwendung.
   Du könntest eine bestehende Customer Relationship Management (CRM)-Software wie Salesforce verwenden oder dein eigenes CRM entwickeln. Hier ist die Wahl normalerweise ziemlich klar. Aber wie sieht es mit der Verwendung von WordPress im Vergleich zur Einrichtung einer eigenen Content Management System (CMS)-Lösung aus? Selbst für komplexere Web- und native Apps gibt es visuelle Editoren wie appgyver oder unqork.
3. Templates.
   Also, du hast dich für WordPress als dein CMS entschieden. Aber das ist im Grunde nur dein Backend. Solltest du ein bestehendes Frontend-Template von einem Marktplatz verwenden? Es ist oft einfach mit vielen Optionen, verlangsamt aber gleichzeitig deine Seite. Die Entwicklung eines eigenen Templates führt zu besserer Leistung und noch besserer Anpassung, kostet aber Zeit und Geld.
4. Frameworks / Libraries.
   Du hast dich vielleicht entschieden, deine Website von Grund auf neu zu entwickeln. Aber selbst dort könntest du entscheiden, mit einem starken Framework (z.B. Angular) oder einer Library (z.B. React) zu arbeiten. Dies hilft oft, kann aber in einigen Fällen auch ein großer Overhead sein.
5. Code Snippets und Packages.
   Auf der untersten Ebene, dem Code. Selbst beim Schreiben des Codes von Grund auf haben Entwickler die Möglichkeit, Code-Snippets von anderen zu verwenden oder externe Packages für spezifische Funktionen zu integrieren. Es spart ihnen Zeit, aber viele dieser Dinge sind veraltet, was deine Anwendung später zum Absturz bringen oder Hintertüren für Hacker öffnen kann.
6. Alle Teile berücksichtigen.
   Und natürlich kannst du unterschiedliche Entscheidungen für verschiedene Teile deiner Anwendung treffen. Das Kontaktformular kann anders funktionieren als deine Support-Seite oder deine CRM-Middleware. Selbst wenn es nur um eine Anwendung zu gehen scheint, sind oft viele verschiedene Systeme beteiligt.

Ganzheitlicher Ansatz

Angesichts der vielen Ebenen wird es noch verwirrender, wenn du die relevanten Aspekte dieser Entscheidung berücksichtigst.

Beispiele:

1. Eine Technologie könnte besser passen, aber wenn du keinen Zugang zu entsprechend qualifizierten Personen hast, könnte eine andere Lösung sogar besser sein.
2. Die Konfiguration bestehender Tools könnte die Dinge zunächst schneller und kostengünstiger machen, aber wenn du später spezifischer werden musst, könnte es noch teurer werden. Was für ein Startup noch funktioniert, könnte für CAPEX-getriebene Unternehmen ein echtes Problem sein.
3. Du möchtest vielleicht mit deiner von Grund auf neu entwickelten Lösung XYZ gehen, aber das bedeutet, dass das System deines Lieferanten keinen vorkonfigurierten Connector zu deiner Lösung hat. Also müsstest du zusätzlich eine Art Middleware entwickeln.

Um all diese und noch mehr Probleme gleichzeitig berücksichtigen und diskutieren zu können, benötigst du erfahrene, technisch versierte Geschäftsmanager. Dies ist oft der eigentliche limitierende Faktor.

Flexibel bleiben

Ja, das ist nicht einfach. Das ist der Grund, warum es oft notwendig werden könnte, den Ansatz unterwegs zu ändern.
Um dies tun zu können, musst du von Anfang an entsprechende Flexibilität implementieren. Dies beginnt damit, den Leuten von diesem potenziellen Wechsel zu erzählen.

Die Auswirkungen

Wenn du denkst, dass dies von geringerer Bedeutung ist oder nur von Entwicklern diskutiert werden sollte: STOP!

Natürlich sollten einige Details auf operativer Ebene geschehen, aber als Manager musst du die Richtung vorgeben und leiten.

Diese Entscheidungen sind stark mit Ausgaben verbunden.
Selbst wenn ein Entwickler entscheidet, einen Teil selbst zu bauen, anstatt ein etabliertes bestehendes Package zu verwenden, kostet es dich nicht nur viel Geld, sondern blockiert auch diese Ressource.

Natürlich führt dies auch zu einem wichtigen Timing- und Fahrplan-Problem.
Oft geht es nicht nur um die Zeit, die benötigt wird, um die anfängliche Anwendung zu erstellen, sondern auch um Wartung und Weiterentwicklung. Einfach „von Grund auf neu“ zu gehen, kann dich Jahre kosten!

Zu guter Letzt geht es um langfristige Strategie und ROI!
Du könntest jetzt Zeit und Geld sparen, aber es könnte dir in 2 Jahren leicht auf die Füße fallen. Oder du sparst Geld, bist aber nicht in der Lage, diese Killer-Features zu entwickeln, die deine Kunden wirklich brauchen. Dies kann schnell zu einem scheiternden Produkt führen und dann ist selbst ein kleiner Preis zu hoch.

Entscheidungshilfen

Aber wie entscheidet man, welchen Weg man gehen soll?

Leider gibt es keine einfache Matrix, die dir in jeder Situation helfen könnte.
Die folgenden Themen und Fragen helfen dir, die Menschen um dich herum herauszufordern, um so nah wie möglich an das ideale Setup heranzukommen.

Allgemeine Überlegungen

• Budget: Mit bestehenden Dingen zu arbeiten ist normalerweise günstiger als von Grund auf neu zu beginnen.
• Kontrolle: Von Grund auf neu zu beginnen bedeutet 100% Kontrolle. Beachte unterschiedliche Kontrollniveaus pro bestehendem Tool, wenn du dich für eines davon entscheiden musst.
• Geschwindigkeit: Von Grund auf neu zu beginnen dauert viel Zeit und zukünftige Updates könnten noch länger dauern, abhängig von deinen internen Ressourcen. Die Konfiguration ist auch nicht über Nacht erledigt, aber normalerweise schneller.
• Individualität: Etwas von Grund auf neu zu bauen ermöglicht es dir, ein echtes Produkt-USP zu schaffen. Faustregel: Je günstiger und einfacher deine Lösung, desto kleiner dein Marktvorteil. Wenn du nur etwas testen möchtest oder dein USP mehr auf der geschäftlichen Seite liegt (z.B. niedrigere Preise), gehe mit bestehenden Tools!
• Passung mit bestehendem Skillset: Die Nutzung bestehender Dinge ist normalerweise kein Problem für technisch versierte Personen. Wenn du dich für einen spezifischen Tech-Stack von Grund auf entscheidest, könnte dies neue Einstellungen erfordern, wenn du die Fähigkeiten nicht an Bord hast.

Fragen an deinen Projektmanager

• Bietet dir dein Projektmanager (make) oder der Dienstleister (buy) diese verschiedenen Wege pro Ebene an und weist auf Risiken, Chancen, Vor- und Nachteile hin?
  Nein? Das sollte alle Alarmglocken läuten lassen und du solltest unbedingt darüber nachdenken, einen anderen Projektleiter zu finden!
• Frage immer nach Alternativen! Lass dir von den Leuten Vor- und Nachteile aufzeigen, aber lass sie auch einen Grad der Vertrautheit hinzufügen. Wenn Python eine gute Wahl als Programmiersprache wäre, aber deine Leute es nicht kennen, solltest du es nicht in Betracht ziehen.
  Für große, wichtige Projekte ist es oft gut, einen unabhängigen Berater zu engagieren — nur für diesen Check-up. Profi-Tipp: Wenn er kein Folgeprojekt sieht, hast du bessere Chancen, mehr Wahrheit zu sehen.
  Beachte auch Wissenslücken: Wenn ein Berater mehrere Best-Practice-Ansätze aufzeigt, die niemand in deinem Team handhaben könnte, solltest du vielleicht eher „buy“ als „make“ in Betracht ziehen.
• Führe eine Systemabhängigkeitsbewertung durch. Oft sind Projekte auf ein Tool oder System fokussiert, ohne die komplexere Umgebung darum herum zu berücksichtigen. Hast du Lieferanten, die ihre Systeme mit deinen verbinden sollten? Oder arbeitest du mit anderen externen Systemen? Planst du, bald ein anderes System zu migrieren, das die Pläne dieses Projekts stören könnte? Lass deinen Projektmanager die komplette Landschaft zeichnen und potenzielle Probleme aufzeigen!
  Manchmal kann es besser sein, bestehende Tools zu verwenden, weil sie bereits verbunden sind, manchmal musst du von Grund auf neu bauen, weil bestehende Tools keine ordentlichen Verbindungsoptionen bieten.
• Die kleinen Details (z.B. Code-Snippets) werden dir normalerweise nicht von Anfang an aufgezeigt. Frage proaktiv danach. Normalerweise ist es eine gute Idee, hier die Arbeit anderer Leute zu nutzen. Aber achte darauf, alle Abhängigkeiten nicht nur im Code-Repository aufzulisten, sondern auch irgendwo, wo Geschäftsleute Zugang haben. Lass die Entwickler auch die Risiken dieser Abhängigkeiten und wie aktiv sie gepflegt werden, aufzeigen. Ein hochriskanter Code, der zuletzt vor 5 Jahren aktualisiert wurde? Kritisch!
• Kosten, Budget, Zeit, Wartbarkeit, langfristige Nachteile, Abhängigkeiten, Zuverlässigkeit, Leistung, Sicherheit.
  Wiederhole diese Worte immer wieder. Das sollte dich im Fahrersitz halten.

Fazit

Egal, wie du dich am Ende entscheidest, setze diese Frage auf „Priorität A+“ und stelle entsprechende Ressourcen dafür bereit!

Zu schnell an diesem Punkt voranzugehen oder nicht alle Details zu berücksichtigen, kann dein ganzes Projekt scheitern lassen — normalerweise nicht sofort, aber 12 Monate später.
Ich habe das mehrmals mit eigenen Augen gesehen.

Denke daran:

„Make or Buy“ + „From Scratch or Configuration“.