Case Study: Make or Buy – Der erste Blick kann trügen!

Make or Buy – Das sollte bei einer Entscheidung für ein IT System berücksichtigt werden

Auf die Frage ob ein System per Eigenentwicklung oder als Standardsoftware, kurz Make or Buy, bereitgestellt werden sollte, gibt es aus ökonomischer Sicht keine einfache Antwort. Die pauschale Aussage, Standardsoftware ist die wirtschaftlichere Lösung ist genauso falsch, wie umgekehrt, dass die Eigenentwicklung den Königsweg darstellt. Um sich einer transparenten Bewertung zu nähern hat sich gezeigt, dass eine partikuläre Kostenbetrachtung nicht ausreicht. Denn der Vergleich von Entwicklungskosten und Lizenzkosten bzw. Customizing Kosten schafft ein trügerisches Bild. Genauso wenig genügt der Vergleich von Wartungskosten, da diese im schlechtesten Fall von der Marketingabteilung des Produktherstellers bestimmt werden. Aber auch wenn sich für die Eigenentwicklung entschieden wurde, kann sie schnell zum Kostentreiber werden.

Unsere Erfahrung zeigt, dass erst der Vergleich der Life-Cycle Kosten einen transparenten Kostenvergleich von Make (Eigenentwicklung) und Buy (Kauflösung) Lösungen ermöglicht.

Das nachfolgende Fallbeispiel geht der Frage nach, welche Lösung günstiger ist und zeigt darüber hinaus Entscheidungsoptionen auf.  

Ihre Ziele sind wichtig – was soll das IT System können? 

Für die Durchführung einer Make or Buy Entscheidung sind Ihre Ziele wesentlich. Was ist Ihnen wichtig? Time to Market? Die kostengünstigste Lösung? Wie nah verhält sie sich am Standard? Diese und weitere Ziele werden einem Kick-Off ermittelt. Anschließend erfolgt die Datenanalyse.

Aufbauend auf Ihren Zielen werden die Bausteine der Analyse zusammengesetzt. Für die Eigenentwicklungs-Lösung (Make) wird zunächst der Funktionsumfang untersucht, um dann Produktivität für Change und Run zu bestimmen. Darauf aufbauend können die Aufwände für Entwicklung und Wartung ermittelt werden. 

Für die Standard-Lösung (Buy) hingegen wird ein erweitertes Verfahren ausgewählt. Zunächst werden die Komponenten, aus denen sich die Kosten zusammensetzen, identifiziert. Dazu gehören: 

1. Lizenzkosten: Die Ermittlung der Lizenzkosten ist kein standardisiertes Verfahren, sondern wird von den Produktherstellern sehr individuell gestaltet. Dieses Beispiel geht von einem mengenbasierten Ansatz aus, der jährlich zu entrichten ist. 

2. Wartungskosten: Auch die Wartungskosten folgen sehr individuellen Konzepten der Produkthersteller. Das vorliegende Beispiel geht von einem marktüblichen Anteil aus, der aus den Lizenzkosten prozentual abzuleiten ist. 

3. Individuelle Anpassungen: Die individuellen Anpassungen berücksichtigen Ihre Wünsche, in denen sich der Ablauf bzw. die Funktionalität vom bereitgestellten Standard unterscheidet. Der Grad der Individualisierung differiert. Ein hoher Individualisierungsgrad ist in vielen Fällen Praxis. 

4. Schnittstellen: Um die Standardsoftware in die Systemlandschaft zu integrieren, sind vielfach Schnittstellenanpassungen erforderlich. Dies geschieht Initial und muss bei Releasewechsel wiederholt werden. 

5. Releasewechsel (Migration): Auch der Releasewechsel ist eine Eigenheit der Standardsoftware. Aufgrund der Produktpolitik des Herstellers sind temporär solche Releasewechsel erforderlich. Sie umfassen Tätigkeiten wie Datenmigration, Anpassung der Schnittstellen und Implementierung der individuellen Anpassungen, die bereits in vorhergehenden Releases bereitgestellt wurden. 

Make or Buy – Beispiel aus der Praxis: 

In einem Beispiel aus unserer Praxis wird das oben beschriebene Vorgehen nun illustriert. In diesem Fall sind folgende Anforderungen an die IT Anwendung im Vorfeld bereits bekannt:  

• Der identifizierte Funktionsumfang der Anwendung beträgt 2500 Function Points  
• Die Entwicklungszeit (Change) bzw. das Customizing beträgt 1 Jahr 
• Die geplante Betriebszeit ist mit 10 Jahren geplant 

Im Anschluss werden die Aufwände sowohl für eine Eigenentwicklung (Make) und auch eine Standardsoftware (Buy) ermittelt.

Fall a: Eigenentwicklung (Make)

Im ersten Schritt werden die Entwicklungskosten (Change) für die Eigenentwicklung (Make) ermittelt. Nach Analyse der organisatorischen Randbedingungen wird von folgenden Produktivitätskennzahlen ausgegangen: 

• Die Produktivität für die Entwicklungsgeschwindigkeit PK1 [FP/PM] beträgt 11,88 FP/PM 
• Die Produktivität für die Entwicklungsdauer und –aufwand PK2 [EUR/FP] beträgt 2.825 EUR/FP 

Daraus resultieren folgende Entwicklungsaufwände (Change) für das Projekt: 

• Kosten (Change): 7.062.500 EUR (1) 
• Entwicklungszeit: 210,4 PM 
• Ressourcen (FTE): 17,5 

Anschließend werden die Aufwände für die Wartung (Run) erhoben. Dazu konnte für die Produktivität PK2 (Run) auf organisationsspezifische Werte zurückgegriffen werden (alternativ stellt die BAMAC GROUP die Daten über ihre Datenbank zur Verfügung). Infolgedessen ergeben sich die Kosten für die Wartung pro Jahr wie folgt (siehe Tabelle 1): 

Aus der Summe für Change (1) und Run (2) ergeben sich die Life-Cycle-Kosten für die Eigenentwicklung (Make) in Höhe von 44.704.049 EUR.  
Es folgt nun die Beispielrechnung für die Möglichkeit der Eigenentwicklung (Buy).

Fall b: Standardsoftware (Buy)

Zur Ermittlung der Life-Cycle Kosten für die Buy-Lösung werden die fünf oben aufgeführten Schritte verwandt. Dabei wird von folgenden Randbedingungen ausgegangen:  

1. Lizenzkosten: Die Kosten pro Lizenz und Jahr betragen 4.750 EUR bei 500 Usern. 

2. Wartungskosten: Die Wartungskosten ermitteln sich aus den jährlichen Lizenzkosten und machen 22% der Lizenzkosten aus.  

3. Individuelle Anpassungen: In unserem Beispiel gehen wir davon aus, dass 30% der Funktionalitäten individualisiert werden. Hier sind herkömmliche Programmierarbeiten erforderlich deren Auswirkungen ähnlich wie in einer Eigenentwicklung sind. 

4. Schnittstellenanpassungen: Wir gehen von 10 anzupassenden Schnittstellen aus, die für die Integration in die Systemlandschaft unseres Kunden erforderlich ist.  

5. Releasewechsel: Aufgrund eines Releasewechsels seitens des Herstellers plant der Kunde einen Releasewechsel während der Betriebsdauer mit ein. Der Releasewechsel umfasst eine Datenmigration, Schnittstellenanpassungen und die Migration der individuellen Anpassungen, die in diesem Fall erneut bereitgestellt werden müssen.  

Zum besseren Verständnis werden im Folgenden die einzelnen Schritte bis zur Ermittlung der Gesamtkosten aufgezeigt. 

Schritt 1: Lizenzkosten 

Das vorliegende Lizenzmodell sieht eine Kostenpauschale pro User und Jahr vor. Die Kosten pro User/pro Jahr betragen 4.750 EUR. Die Anzahl der User beträgt 500.  
Daraus ergeben sich pro Jahr Lizenzkosten in Höhe von 2.375.000 EUR. Für das Jahr der Entwicklung konnte mit dem Hersteller vereinbart werden, dass keine Lizenzkosten anfallen.  
Für die Betriebszeit fallen somit Betriebskosten in Höhe von 23.750.000 EUR (3) an. 

Schritt 2: Wartungskosten 

Die Wartungskosten werden mit 22% der Lizenzkosten veranschlagt. Insgesamt umfasst die Wartung sowohl Beratung und Support für den Anwendungsbetrieb, als auch Analysen, die Geschäftsprozesse zu verbessern.
Die Kosten pro Jahr betragen daher 522.500 EUR. Für die 10 Jahre Betriebsdauer ergibt sich somit ein Gesamtaufwand in Höhe von 5.225.000 EUR (4). 

Schritt 3: Individuelle Anpassungen 

Da der Kunde nur in Teilen mit den Standardvorgaben einverstanden ist, sollen 30% der Funktionalität nach seinen Wünschen anpassen. Somit sind 750 FPs der Funktionen betroffen. Für die Aufwandsermittlung wird klassisch nach Entwicklung und Wartung vorgegangen. 

Es wird von folgenden kundenspezifischen Produktivitätsfaktoren ausgegangen: 

• Die Entwicklungsgeschwindigkeit PK1 [FP/PM] beträgt 13,5 FP/PM 
• Die Entwicklungskosten bzw.  der Entwicklungsaufwand für PK2 [EUR/FP] beträgt 3.725 EUR/FP 

So ergeben sich Entwicklungskosten (Change) in Höhe von 2.793.750 EUR (5). 
Die Entwicklungszeit beträgt 55,6 PM. Die Anzahl der erforderlichen Ressourcen beträgt 4,6 FTE. 

Die Wartungskosten (Run) beruhen auf den Baseline-Daten der Organisation für PK2 (vgl. Tabelle 2). Daraus resultieren die Kosten für Wartung in Höhe von 20.513.740 EUR (6).  

Schritt 4: Schnittstellenanpassungen 

Wie bereits aufgeführt, ist von einer Anpassung von 10 Schnittstellen ausgegangen worden. Die ermittelten Function Points betragen 150 FPs. Die zugehörigen Entwicklungs- und Wartungsaufwände lauten: 

• Die Produktivität beträgt wie oben für die Entwicklungsgeschwindigkeit 13,5 FP/PM 
• Die Produktivität für die Entwicklungskosten beträgt 3.725 EUR/FP 

Daraus resultieren die Entwicklungskosten in Höhe von 558.750 EUR (7). 
Die Entwicklungszeit beträgt 11,1 PM und die erforderlichen Ressourcen 0,9 FTEs. 

Zusätzlich wurden, unter Berücksichtigung der Produktivität PK2 (vgl. Tabelle 3), Wartungsaufwände in Höhe von 4.102.748 EUR (8) ermittelt. Dabei wird die gleiche Produktivität angenommen, wie bei den individuellen Anpassungen.  

Schritt 5: Releasewechsel 

Schlussendlich ist davon ausgegangen worden, dass während der Betriebszeit ein Releasewechsel zu bewältigen sein wird. Dabei werden keine neuen Funktionen eingeführt, sondern es gilt die zuvor bereitgestellten Funktionen weiterhin zur Verfügung zu stellen. Für die Migration sind folgende Aktivitäten zu berücksichtigen: 

• Datenmigration 
• Schnittstellenanpassungen und 
• Individuelle Anpassungen 

Der gemessene Funktionsumfang beträgt 930 FPs.  

Auch hier erfolgt die Vorgehensweise wie bei der Eigenentwicklung. Zunächst werden die Entwicklungsaufwände (Change) erhoben. Bei den Wartungskosten werden die bereits oben aufgeführten Kosten übernommen, da die Analyse keine nennenswerten Abweichungen gezeigt haben. 

Es wird von folgender Produktivität ausgegangen: 

• Entwicklungsgeschwindigkeit 13,5 FP/PM 
• Entwicklungskosten 3.725 EUR/FP 

Die resultierenden Entwicklungskosten für den Releasewechsel betragen 3.464.250 EUR (8). 
Die Entwicklungszeit beträgt 68,9 PM und die erforderlichen Ressourcen 5,7 FTE. Die Wartungskosten entfallen, da wir sie bereits oben berücksichtigt haben. 

Zusammenfassung Make or Buy

Zusammengefasst lässt sich feststellen, dass die Kosten für Eigenentwicklung im Life-Cycle ca. 44,7 Mio. EUR betragen.
Die für die Einführung der Standardsoftware beträgt dagegen 60,4 Mio. EUR.
Somit liegen die Life-Cycle Kosten der Standardsoftware mit 35% deutlich über denen der Eigenentwicklung. Zur Kostenreduzierung der Standardlösung könnte man weniger individuelle Anpassungen zulassen bzw. auf die Migration verzichten. In der Praxis zeigt sich regelmäßig, dass der Anteil der individuellen Anpassungen vielfach deutlich höhere Werte als 30% erreicht (Banken und Versicherungen z.B. 50%). Dadurch würde die Standardlösung (Buy) gegenüber der Eigenentwicklung (Make) noch schlechter abschneiden, als unten aufgeführt.  

Als Pro-Argumente für die Standardlösung können die kürzere Einführungsdauer und die erforderlichen Ressourcen aufgeführt werden. Die Einführungsdauer ist bei der Standardsoftware erheblich schneller und bedarf weniger Ressourcen. Darüber hinaus ist zu prüfen, ob der kalkulierte Releasewechsel tatsächlich erforderlich ist. Ein Verzicht darauf würde Kosten sparen.

Make or Buy – Ihre Entscheidung

Die Entscheidung, welche Lösung die Richtige für das Unternehmen ist, hängt von Ihren Zielen ab (z.B. Entwicklungszeit vs. Kosten).
Fassen wir alle Ergebnisse des Fallbeispiels zusammen, lassen sich diese wesentlichen Hebel zur Effizienzsteigerung und der Freisetzung von Ressourcen für den Change-Bereich in Ihrem IT Produktportfolio besonders wirkungsvoll ermitteln:  

1. Bauen Sie nicht mehr verwendete Funktionalitäten zurück.  

2. Lösen Sie Altsysteme ab.

3. Standardisieren Sie Prozesse und Funktionen – Verzichten Sie auf Arabesken. 

4. Konsolidieren Sie Daten und Funktionen. 

5. Make or Buy: Treffen Sie Ihre Entscheidung nach Produktivitätskriterien. 

6. Make or Buy: Life-Cycle Kosten vergleichen.

Ein weiteres Fallbeispiel aus der Praxis, in dem wir Ihnen darlegen, wie sie verhindern, dass die Wartungskosten Sie auffressen, finden Sie hier.