Zum Inhalt

Kapitel 5: Variantenvergleich (Make vs Buy)

Lernziele

Nach diesem Kapitel können Sie: * Die Entscheidung zwischen Make (Eigenentwicklung) und Buy (Standardsoftware) systematisch treffen * Variantenvergleichsmethoden anwenden und bewerten * Entscheidungsmatrizen für IT-Projekte erstellen * Risiken bei Make- und Buy-Optionen identifizieren und bewerten

1. Grundlagen der Make-vs-Buy-Entscheidung

Die Make-vs-Buy-Entscheidung ist eine der zentralen strategischen Fragen in der IT. Sie betrifft nicht nur die Softwarebeschaffung, sondern auch Infrastruktur, Services und Personal. Eine fundierte Entscheidung spart Kosten, beschleunigt Time-to-Market und reduziert Risiken.

Kernfragestellung

Aspekt Make (Eigenentwicklung) Buy (Standardsoftware)
Anpassung Exakt auf Anforderungen zugeschnitten Kompromisse bei Spezialisierung
Kosten Hohe Initialkosten, niedrige laufende Kosten Geringere Initialkosten, höhere laufende Kosten
Zeit Längere Entwicklungszeit Schnelle Verfügbarkeit
Risiko Technisches Risiko beim Entwickeln Abhängigkeit vom Anbieter
Know-how Aufbau internen Wissens Nutzung externer Expertise

2. Entscheidungsmatrix

Eine strukturierte Entscheidungsmatrix hilft, objektiv zwischen Varianten zu wählen. Bewerten Sie jede Option anhand gewichteter Kriterien.

Beispiel: CRM-System-Entscheidung

graph LR
    A[Anforderungsanalyse] --> B[Kriterien definieren]
    B --> C[Gewichtung vergeben]
    C --> D[Varianten bewerten]
    D --> E[Score berechnen]
    E --> F[Entscheidung treffen]

    style A fill:#e3f2fd
    style B fill:#e3f2fd
    style C fill:#bbdefb
    style D fill:#bbdefb
    style E fill:#90caf9
    style F fill:#64b5f6

Kriterienkatalog

  1. Funktionale Anforderungen (30%)
  2. Anpassbarkeit an Geschäftsprozesse
  3. Integration in bestehende Systeme

  4. Zukunftssicherheit und Skalierbarkeit

  5. Wirtschaftliche Faktoren (25%)

  6. Total Cost of Ownership (TCO)
  7. ROI und Amortisationsdauer

  8. Lizenz- vs. Entwicklungskosten

  9. Technische Aspekte (20%)

  10. Architektur und Technologiestack
  11. Sicherheitsstandards

  12. Performance und Verfügbarkeit

  13. Organisatorische Faktoren (15%)

  14. Schulungsaufwand
  15. Change-Management

  16. Internes Know-how-Aufbau

  17. Risiken (10%)

  18. Abhängigkeiten und Vendor Lock-in
  19. Compliance-Risiken
  20. Projekt- und Umsetzungsrisiken

Scoring-Matrix (Beispiel)

Kriterium Gewichtung Eigenentwicklung Standardlösung A Standardlösung B
Funktionalität 30% 9 (270) 7 (210) 8 (240)
TCO (5 Jahre) 25% 6 (150) 7 (175) 8 (200)
Technologie 20% 8 (160) 6 (120) 7 (140)
Organisation 15% 5 (75) 8 (120) 9 (135)
Risiko 10% 5 (50) 7 (70) 8 (80)
Gesamtscore 100% 705 695 795

Bewertungsskala

  • 9-10: Exzellent, erfüllt Anforderung vollständig
  • 7-8: Gut, kleine Abstriche akzeptabel
  • 5-6: Mittel, Kompromisse notwendig
  • 3-4: Ungenügend, erhebliche Mängel
  • 1-2: Unzureichend, erfüllt Anforderungen nicht

3. Make-Option: Eigenentwicklung

Eigenentwicklung ist sinnvoll, wenn: - Einzigartige Wettbewerbsvorteile durch Software geschaffen werden sollen - Hohe Anpassungsanforderungen bestehen - Internes Know-how aufgebaut werden soll - Langfristige Unabhängigkeit gewünscht ist

Chancen

  • Exakte Anpassung: Software spiegelt Geschäftsprozesse perfekt wider
  • Wettbewerbsvorteil: Exklusive Funktionen differenzieren vom Markt
  • Wissensaufbau: Internes Verständnis für Prozesse und Technik
  • Flexibilität: Schnelle Anpassung an Änderungen möglich
  • Kein Vendor Lock-in: Unabhängigkeit von externen Anbietern

Risiken

Hauptrisiken bei Eigenentwicklung

  • Budgetüberschreitungen: Komplexe Projekte sind schwer kalkulierbar
  • Zeitverzögerungen: Fehlende Ressourcen oder technische Probleme
  • Qualitätsmängel: Insufficient Testing und fehlendes Fachwissen
  • Personalmangel: Schwierigkeiten bei der Rekrutierung qualifizierter Entwickler
  • Wartungsaufwand: Laufende Kosten für Maintenance und Updates

Praxisbeispiel: Custom Analytics-Plattform

Ein mittelständisches E-Commerce-Unternehmen entschied sich für die Eigenentwicklung einer Analytics-Plattform. Die Standardlösungen boten keine ausreichende Integration in das komplexe Produktkategorisierungssystem.

Ergebnis nach 18 Monaten: - Kostenaufwand: 350.000 € vs. 80.000 € für Standardlösung - Entwicklungsdauer: 6 Monate länger als geplant - Nutzen: 15% Umsatzsteigerung durch verbessertes Cross-Selling - ROI: Amortisation nach 2,5 Jahren - Know-how: Aufbau eines 4-köpfigen Data-Science-Teams

4. Buy-Option: Standardsoftware

Standardlösungen sind sinnvoll, wenn: - Standardisierte Prozesse abgebildet werden können - Schnelle Verfügbarkeit gefordert ist - Budgetbeschränkungen bestehen - Fokus auf Kerngeschäft, nicht auf IT

Chancen

  • Schnelle Implementierung: Go-Live oft innerhalb weniger Wochen
  • Geringere Kosten: Keine Entwicklungskosten, kalkulierbare Lizenzgebühren
  • Erfahrungswerte: Viele Referenzen und Best Practices
  • Kontinuierliche Updates: Vendor kümmert sich um Weiterentwicklung
  • Support: Professioneller technischer Support

Risiken

Hauptrisiken bei Standardsoftware

  • Fehlende Anpassung: Kompromisse bei Geschäftsprozessen
  • Vendor Lock-in: Abhängigkeit vom Anbieter
  • Hidden Costs: Zusatzkosten für Anpassungen, Integrationen und Training
  • Unflexibel: Änderungsanforderungen nicht sofort umsetzbar
  • Datenhoheit: Abhängigkeit von Cloud-Anbieter und Datenschutzregelungen

Praxisbeispiel: SAP S/4HANA Implementierung

ein Konzern im Maschinenbau entschied sich für die Standard-ERP-Lösung SAP S/4HANA anstelle der Eigenentwicklung.

Vorgehen: - Prozesse wurden an SAP-Standard angepasst, nicht umgekehrt - Branchenlösung für Maschinenbau gewählt - Integrationspartner mit Branchenkenntnis beauftragt

Ergebnisse: - Implementierungsdauer: 14 Monate - Gesamtkosten: 2,8 Mio. € (Lizenzen + Implementierung + Training) - Einsparungen: 30% reduzierte Prozesskosten - Compliance: Automatische Einhaltung branchenspezifischer Vorschriften

5. Hybride Ansätze

Oft ist die beste Lösung eine Kombination aus Make und Buy.

Architekturtypen

graph TB
    subgraph "Frontend"
        A[Standard CRM]
        B[Custom Dashboard]
    end

    subgraph "Backend"
        C[Standard ERP]
        D[Custom Middleware]
        E[Proprietärer Algorithmus]
    end

    subgraph "Infrastruktur"
        F[Cloud Provider]
        G[On-Premise Legacy]
    end

    A --> D
    B --> D
    D --> C
    D --> E
    C --> F
    E --> G

    style A fill:#c8e6c9
    style C fill:#c8e6c9
    style F fill:#c8e6c9
    style B fill:#fff9c4
    style D fill:#fff9c4
    style E fill:#ffe0b2
    style G fill:#ffe0b2

Szenarien für hybride Ansätze

  1. Standard-Kern, Custom-Erweiterungen
  2. Standard-ERP mit individueller Rechenlogik

  3. CRM mit custom-Integration zu Fachapplikationen

  4. Best-of-Breed-Integration

  5. Verschiedene spezialisierte Tools integriert via Middleware

  6. Zentrales Datenmodell verbindet alle Systeme

  7. Phasenweise Migration

  8. Start mit Standardlösung
  9. Schrittweise Entwicklung custom-Module für Differenzierung

Empfehlung für hybride Ansätze

Definieren Sie klare Schnittstellen zwischen Standard- und Custom-Komponenten. Verwenden Sie standardisierte APIs und Microservices-Architektur, um Flexibilität zu gewährleisten und Vendor Lock-in zu minimieren.

6. Entscheidungsprozess

Der Entscheidungsprozess sollte strukturiert und dokumentiert erfolgen.

Prozessschritte

  1. Anforderungsanalyse
  2. Detaillierte Definition funktionaler und nicht-funktionaler Anforderungen

  3. Identifikation von Must-Have- und Nice-to-Have-Kriterien

  4. Marktanalyse (für Buy)

  5. Recherche relevanter Lösungen und Anbieter

  6. Einholung von Referenzen und Case Studies

  7. Machbarkeitsstudie (für Make)

  8. Technische Machbarkeit prüfen

  9. Ressourcenabschätzung (Personal, Budget, Zeit)

  10. Variantenbewertung

  11. Erstellung der Entscheidungsmatrix

  12. Stakeholder-Workshops zur Validierung

  13. Proof of Concept

  14. Testen vielversprechender Varianten

  15. Realistische Bewertung而非 nur Theorie

  16. Entscheidung

  17. Dokumentation der Entscheidung inkl. Begründung
  18. Genehmigung durch Management und Stakeholder

Praxisbeispiel: Entscheidungsprozess für Projektmanagement-Tool

Ein IT-Service-Unternehmen mit 200 Mitarbeitern stand vor der Entscheidung: Custom-Tool oder Standardlösung für Projektmanagement.

Prozess: 1. Anforderungsanalyse: 75 Must-Haves, 40 Nice-to-Haves identifiziert 2. Marktanalyse: Jira, Asana, Monday.com, Microsoft Project evaluiert 3. Machbarkeit: Eigenentwicklung ca. 6 Monate, 3 Entwickler 4. Variantenbewertung: Jira gewinnt mit 78% vs. Custom 65% 5. PoC: 4-wöchige Testphase mit 20 Pilotnutzern 6. Entscheidung: Jira mit Custom-Plugins für spezifische Workflows

Resultat: - Go-Live nach 3 Monaten (inkl. Migration) - Gesamtkosten: 60.000 € (Lizenzen 1. Jahr) + 40.000 € (Plugins) - Zufriedenheit: 85% der Nutzer zufrieden - ROI: Amortisation nach 14 Monaten

Zusammenfassung

Die Make-vs-Buy-Entscheidung ist komplex und erfordert eine systematische Herangehensweise. Eine strukturierte Bewertungsmatrix mit gewichteten Kriterien ist unverzichtbar.

Kernpunkte: - Strukturierter Prozess: Analyse → Bewertung → PoC → Entscheidung - Objektive Kriterien: Wirtschaftlichkeit, Funktionalität, Risiko, Organisation - Hybride Lösungen: Oft die beste Balance zwischen Flexibilität und Effizienz - Dokumentation: Entscheidungen müssen nachvollziehbar sein - Stakeholder-Einbindung: Alle betroffenen Parteien müssen involviert sein

Es gibt keine pauschale Antwort – die Entscheidung muss für jeden Einzelfall basierend auf Anforderungen, Ressourcen und strategischen Zielen getroffen werden.