C Referenz Produkte
C.1 Produkte
C.1.10 Systemanalyse
C.1.10.6 Make-or-Buy-Entscheidung
In einer Make-or-Buy-Entscheidung wird der Weg hin zur Entscheidung, ob eine Externe Einheit, ein Externes HW-Modul oder ein Externes SW-Modul als Fertigprodukt zugekauft, selbst entwickelt oder als Unterauftrag vergeben wird, dokumentiert. Abhängig von den strategischen Vorgaben kann eine vorrangige Untersuchung durchzuführen sein, ob die Wiederverwendung einer Komponente aus Eigenentwicklung oder die Verwendung einer Open-Source-Komponente möglich ist.
Strategische und wirtschaftliche Aspekte werden untersucht. Eventuell wird eine Evaluierung potentieller Fertigprodukte durchgeführt. Die Ergebnisse der Analysen und der Evaluierung stützen die endgültige Entscheidung. Das Ergebnis der Entscheidung wird in der Systemarchitektur oder Unterstützungs-Systemarchitektur dokumentiert.
Verantwortlich |
Mitwirkend |
Vergabestelle, Projekteigner, SW-Architekt, Systemarchitekt, Systemintegrator |
Hilfsmittel |
Make-or-Buy-Entscheidung durchführen (Aktivität), Make-or-Buy-Entscheidung(.odt|.doc) |
Erzeugt durch |
SW-Architektur (Dekomposition der SW-Einheit), Systemarchitektur (Dekomposition des Systems), Unterstützungs-Systemarchitektur (Dekomposition des Unterstützungssystems) |
C.1.10.6.1 Strategische Analyse
Der Auftragnehmer hat im Rahmen der strategischen Ausrichtung seiner Organisation zu untersuchen, ob die möglichen Vorteile des Einsatzes von Fertigprodukten, der Wiederverwendung von Komponenten aus eigener Entwicklung, der Verwendung von Open Source-Komponenten oder einer Auftragsvergabe für sein Projekt genutzt werden können. Dabei hat er insbesondere abzuwägen, ob die Verfügbarkeit und die Reife der vorgefertigten Komponenten für die von ihm benötigten Funktionalitäten ausreichend und geeignet sind.
Für alle Arten der Beschaffung ist zu prüfen, ob eine spürbare Kostenersparnis gegenüber einer Eigenentwicklung sowohl in der Beschaffungs- als auch in der Nutzungs- und Wartungsphase erkennbar und eine signifikante Verkürzung der Lieferzeiten zwischen Anforderungsfestlegung und Implementierung zu erwarten ist.
Bei Open Source-Komponenten ist außerdem zu beachten, dass die verschiedenen Open Source-Communities Regeln für die Benutzung der Open Source-Komponenten haben.
Die strategische Analyse hat dabei gegebenenfalls unternehmensweite Vorgaben zu beachten. Relevante Vorgaben können beispielsweise sein:
- Es dürfen keine Aufträge vergeben werden, bei denen Kernkompetenzen preisgegeben werden müssen.
- Der Einsatz von konkreten Fertigprodukten ist vorgeschrieben. Eigenentwicklungen müssen besonders begründet werden. Gründe können höhere wirtschaftliche oder technische Risiken beim Einsatz von Fertigprodukten sein.
- Der Einsatz von Fertigprodukten ist freigestellt. Es ist die wirtschaftlichste Lösung anzustreben.
- Es müssen eigene Komponenten wiederverwendet werden, z.B. im Zusammenhang mit Produktlinienengineering.
C.1.10.6.2 Wirtschaftliche Analyse
Die Wirtschaftlichkeit der Verwendung von Produkten vom Typ Externe Einheit, Externes HW-Modul oder Externes SW-Modul ist möglichst durch eine Kosten-Nutzen-Analyse in quantitativer Form (Geldeinheiten) nachzuweisen. Dies ist unabhängig davon, ob es sich um die Verwendung eines vorgefertigten Produkte oder um das Ergebnis eines Entwicklungsauftrags handelt. Bei einem Nutzenüberhang über die Kosten ist die Verwendung eines Externen Systemelements eindeutig als wirtschaftlich einzustufen. Eventuell kann auch durch Reduzierung der Anforderungen an ein externes Systemelement eine zusätzliche Kosteneinsparung erreicht werden (z.B. können bei 20% der Kosten 80% der Anforderungen erfüllt sein).
Der messbare Nutzen eines vorgefertigten Produktes kann beispielsweise in seiner sofortigen Verfügbarkeit liegen. Zusätzlich ist ein geringerer Aufwand für Prüfung und Integration zu erwarten, da die Produkte in der Regel am Markt oder bereits im eigenen Haus erprobt wurden.
Wie die Kostenvorteile sind jedoch auch die Kostennachteile zu berücksichtigen. Beispielsweise können Kostenvorteile vollständig aufgezehrt werden, wenn bei Fertigprodukten oder Open Source-Komponenten aufwändige Anpassungen notwendig werden oder Implementierungsfehler, Schnittstelleninkompatibilität oder Plattforminkompatibilität zu bereinigen sind.
Sollte der Nutzen sich nicht in Geldeinheiten ausdrücken lassen, so können qualitative Nutzenaspekte hinzugezogen werden (dazu kann im öffentlichen Bereich die IT-WiBe verwendet werden). Qualitativer Nutzen entsteht beispielsweise beim Einsatz von Standardkomponenten durch eine höhere Flexibilität und leichtere Erweiterbarkeit. Bei Produkten, die bereits im Markt oder im Haus erprobt wurden, kann von einer geringeren Ausfallwahrscheinlichkeit und damit einer höheren Verfügbarkeit des neuen Produktes ausgegangen werden.
Kommt der Einsatz von Fertigprodukten, einer Open Source-Komponente oder einer wiederverwendbaren Komponente nicht in Frage, muss zwischen der Fremd- oder Eigenentwicklung entschieden werden. Dabei spielen Aspekte wie ‚Time to Market’, eigene Ressourcenverfügbarkeit und der Kostenfaktor eine Rolle.
C.1.10.6.3 Evaluierung der Fertigprodukte
Das Thema Evaluierung der Fertigprodukte dokumentiert die Evaluierung möglicher Fertigproduktkandidaten für eine Externe Einheit, ein Externes HW-Modul oder ein Externes SW-Modul. Damit wird die Grundlage zur Entscheidung für oder gegen ein Fertigprodukt im Allgemeinen oder auch für oder gegen ein bestimmtes Fertigprodukt gelegt. Kommen aus strategischen Überlegungen auch Open Source-Komponenten in Frage, werden diese ebenfalls betrachtet.
Anhand der Schnittstellen und nicht-funktionalen Anforderungen der Externe-Einheit-Spezifikation, der Externes-HW-Modul-Spezifikation oder der Externes-SW-Modul-Spezifikation wird eine Kriterienliste aufgestellt. Sie dient dazu, die Eignung der Fertigproduktkandidaten zu überprüfen. Entscheidungen fallen oft aufgrund der Nichterfüllung von K.o.-Kriterien in Randbereichen, die anfangs nicht immer gegenwärtig sind. Aus diesem Grund ist eine Bewertung der Erfüllungsgrade der konkreten und gewichteten Anforderungen, das heißt eine klassische Nutzwertanalyse mit K.o.-Kriterien erforderlich. Eine Bewertung von Fertigprodukten z.B. anhand starrer Funktionskataloge ist sinnlos und führt zu falschen Ergebnissen. Die einzelnen Fertigprodukte werden anhand der Kriterienliste bewertet.
Zu beachten ist, dass Fertigprodukte oft nicht die besonderen (z.B. militärischen) Anforderungen, die aus Umwelteinflüssen und speziellen Einsatzbedingungen herrühren, erfüllen. Daher werden Anpassungen (Härtung beziehungsweise Wrapping-Technologien) der Fertigprodukte an die vorgegebenen Einsatzbedingungen notwendig, das heißt bei der Verwendung von Fertigprodukten muss der Aufwand für eventuell neu zu entwickelnde Anpassungs-SW beziehungsweise -HW hinsichtlich Kosten und Integrationsrisiko betrachtet werden. Ergebnis der Evaluierung ist eine Liste mit priorisierten Fertigproduktkandidaten.
C.1.10.6.4 Bewertung und Ergebnis
Wurden die verschiedenen Analysen und gegebenenfalls eine Fertigproduktevaluierung durchgeführt, ist anhand der Ergebnisse die Entscheidung zur Eigenentwicklung, zum Kauf, zur Wiederverwendung oder zur Fremdvergabe zu treffen.
In die Entscheidung fließen zusätzliche Bewertungskriterien für mögliche Fertigproduktlieferanten bzw. Unterauftragnehmer mit ein, wie beispielsweise Bonitätskriterien, Leistungskriterien und vertragliche Kriterien. Ebenso relevant für eine Make-or-Buy-entscheidung sind Kriterien wie Marktstellung eines Unternehmens, Erfahrungen auf dem Fachgebiet, Beteiligungen an Standardisierungen, Vertragspolitik, Preispolitik und verfügbare Wartungs-, Support- und Schulungsangebote.
Wurde eine Evaluierung von Fertigprodukten durchgeführt, ist die priorisierte Kandidatenliste ebenfalls als Entscheidungsgrundlage hinzuzuziehen. Des Weiteren sind mögliche Risiken zu bewerten, wie beispielsweise Integrationsrisiken, Beherrschbarkeit neuer Technologien oder Anpassungsfähigkeit und Modularität des Fertigprodukts.
Anhand der oben genannten Kriterien und untersuchten Risiken wird eine Rangfolge der Alternativen aufgestellt, die Entscheidung durchgeführt und das Ergebnis dokumentiert.
Sofern das betrachtete Systemelement im Rahmen einer Fremdvergabe erstellt werden soll, muss dokumentiert werden, wie sich der dazugehörige Vergabeprozess gestaltet.
Erzeugt |
Aufforderung zur Abgabe eines Angebots (Unterauftrag): Dokumentation des Vergabeverfahrens (Unterauftrag): Erteilung des Auftrags (Unterauftrag): Veröffentlichung der Ausschreibung (Unterauftrag): Ausschreibungskonzept, Bewertungsmatrix, Vergabeunterlagen (Ausschreibung) Zuschlagserteilung auf ein Angebot (Unterauftrag): |