Selbst entwickeln oder kaufen?

Make or Buy? Welche Bewertungskriterien auf Unternehmensebene relevant sind

Hermann Schlamann, Tobias Fleischmann
©Shutterstock/irin-k

Selbst entwickeln oder kaufen? Die Entscheidung für die eine oder andere Art hat spezifische Auswirkungen, die in diesem Artikel zum einen hinsichtlich der strategischen Ausrichtung und zum anderen in Hinblick auf eine konkrete Projektsituation betrachtet werden. Aus beiden Betrachtungsweisen ergeben sich Entscheidungskriterien, die zu einer Gesamtentscheidung aggregiert werden können.

Im täglichen Leben suchen wir oft nach einer Problemlösung, indem wir uns die Fragen „Gibt es das schon irgendwo?“ und „Können wir es kaufen?“ stellen. Die Motivation zu diesen Fragen ist vielschichtig: Vielleicht haben wir nicht das richtige Werkzeug, um die Problemlösung zu erstellen. Möglicherweise hapert es auch an den notwendigen Fähigkeiten. Wir haben nicht die notwendige Zeit zur Erstellung der Problemlösung oder es wird bereits eine Kauflösung zu einem sehr günstigen Preis angeboten.

Motivationen

Bei vielen Projekten in der IT ist das heute noch ganz anders. Wir wollen alles selbst machen oder wir glauben, es selbst machen zu müssen. In manchen Fällen mag es richtig sein, Lösungen selbst zu fertigen, aber viele Problemlösungen gibt es bereits von der Stange zu kaufen. Als Projektverantwortlicher müssen wir herausfinden, an welcher Stelle einer Problemlösung etwas selbst gefertigt werden muss oder kann und wo einer eingekauften Lösung der Vorzug zu geben ist. Das Rad sollte nicht in jedem Projekt neu erfunden werden.

Im strategischen Teil betrachten wir, was für Bewertungskriterien für die „Make or Buy“-(MoB-)Entscheidung auf Unternehmensebene relevant sind. Üblicherweise sind solche Entscheidungen langfristig orientiert und haben meistens einen unternehmensweiten Geltungsbereich. Es gibt aber auch die operative Betrachtungsweise, die die MoB-Entscheidungen aus Projektsicht augenblicksorientiert untersucht.

Die Kriterien für die Entscheidung sind vielfältig. Einerseits müssen wir uns aus strategischer Sicht überlegen, was Selbstmachen oder Einkauf für das Unternehmen bedeutet. Andererseits hat die Eigenerstellung oder der Zukauf von Problemlösungen aus operativer Sicht im konkreten Projekt enorme Auswirkungen z. B. auf das Zeit- und Finanzbudget.

Aufmacherbild: money background von Shutterstock / Urheberrecht: irin-k

[ header = Seite 2: MoB-Konzept aus strategischer Sicht ]

MoB-Konzept aus strategischer Sicht

Jedes Produktionsunternehmen lebt vom Mehrwert seiner Produkte, die durch Prozesse der Wertschöpfungskette des Unternehmens erzielt werden. Einige dieser Prozesse sind Kernkompetenz des Unternehmens und stellen den hauptsächlichen Zweck der Unternehmung dar. Mit anderen Worten, dies kann das Unternehmen am besten.

Meistens braucht es für die Fertigstellung eines Endprodukts noch weitere Prozesse, die für ein Unternehmen zwar wichtig, aber nicht überlebenswichtig sind. Zum Beispiel gehört zu jedem Unternehmen eine Buchhaltung, in der die getätigten Geschäfte festgehalten werden. Angebote zur Automatisierung buchhalterischer Tätigkeiten gibt es in vielfältiger Weise. Wir können also Tätigkeiten, die keine Kernkompetenz des Unternehmens darstellen, mit „Standardlösungen“ umsetzen. Sei es durch eingekaufte Lösungen im eigenen Haus oder durch Auslagerung der Tätigkeiten an ein Unternehmen, das diese Tätigkeiten als Kernkompetenz anbietet. Ein solches Vorgehen bietet mehrere Vorteile, z. B.:

  • Einsatz von Standardlösungen. Die Lösungen basieren auf anerkanntem gemeinsamem Verständnis und werden von vielen Benutzern verwendet. Die Kosten für Wartung und Weiterentwicklung verteilen sich dadurch auf viele Schultern. Insgesamt ist der Einsatz einer solchen Lösung preiswerter als eine Eigenentwicklung. à Geringere Kosten
  • Einsatz und Integration einer fertigen Lösung erfolgen meistens in kürzerer Zeit als die Eigenentwicklung. Die Gesamtlösung ist dadurch früher einsatzbereit. à Kürzere Time to Market

Durch den Einsatz von fertigen Lösungen kann u. U. Kapazität freigesetzt werden, die sinnvollerweise für die Entwicklung von solchen Lösungen verwendet wird, die der Kernkompetenz des Unternehmens entsprechen. Aus strategischer Sicht gesehen, sollte sich das Unternehmen mehr auf seine Kernkompetenz konzentrieren, um dadurch (wenn richtig durchgeführt) gegenüber dem Mitbewerber einen Wettbewerbsvorteil erlangen zu können.

Geoffrey Moore beschreibt in seinem Buch „Dealing with Darwin“ [1] den Innovationszyklus dadurch, dass er einerseits zwischen Kernkompetenz- und Kontextprozessen und andererseits zwischen unternehmenskritischen und nicht kritischen Prozessen unterscheidet. Damit lassen sich vier Quadranten für Prozesse aufzeigen (Abb. 1).

Abb. 1: Core-/Context-Prozesse

Je nachdem in welchem Quadranten Prozesse positioniert sind, lassen sich Innovationsstrategien zur besseren Positionierung des Unternehmens am Markt aufzeigen. Als generelle Strategie kann man festlegen, dass z. B. alle Prozesse, die nicht zum Kerngeschäft gehören, als Kontextprozesse (Commodity) zu betrachten sind und entweder zugekauft oder ausgelagert werden sollten. Die Charakteristika der einzelnen Prozesse in den Quadranten sind problembasiert, produktbasiert, kostenbasiert und servicebasiert. Abbildung 2 zeigt Innovationsprozesse.

Abb. 2: Innovationsprozesse

Aus dieser Charakterisierung ergeben sich entsprechend für die einzelnen Quadranten Änderungsstrategien:

  • Neue Prozesse bezüglich der Kernkompetenz des Unternehmens werden experimentell problembasiert erforscht. Wenn solche Prozesse mal schief gehen, ist das nicht weiter schlimm, denn das Risiko ist minimal (es war eben ein Experiment, Innovation).
  • War ein solcher experimenteller Prozess erfolgreich, entsteht daraus ein professionelles Produkt, das als Kernkompetenz eine tragende Säule des Unternehmens bilden kann und anhand dessen sich das Unternehmen vom Mitbewerber unterscheidet (Differenzierung).
  • Je mehr die Differenzierung am Markt für das Produkt oder die Lösung schwindet, umso mehr ist durch Standardisierung des Produkts ein Kostenvorteil zu erzielen (Commodity).
  • Weitere Kostensenkungen lassen sich erzielen, wenn das Produkt oder die Lösung als externer Service ausgelagert werden kann (Outsource).

Bleibt am Ende noch die Frage zu beantworten, mit welchen Bewertungskriterien die Prozesse beurteilt werden. Es fällt schwer, eine allgemeingültige Skala für die Bewertungskriterien zu finden, weil die Sichtweisen auf die Prozesse je nach Adressat unterschiedlich sein können. Den besten Erfolg verspricht eine klassische Dreiteilung: „Eindeutig ja (Wertschöpfend)“, „Eindeutig nein (Commodity)“ und „Weder noch (Weiß nicht)“.

Bezogen auf die Trennung der Prozesse in Kernkompetenz und Kontext erhält damit jeder Prozess ein entsprechendes Klassifizierungsmerkmal. Für die Klassifizierungsmerkmale kann eine strategische, generelle Regel im Unternehmen gelten und zur Anwendung kommen:

  • Wertschöpfend: Prozesse müssen im eigenen Haus ablaufen, höchst stabil und performant sein. Produkte zur Abwicklung der Prozesse werden selbst gefertigt, denn hier steckt das Unternehmens-Know-how. Änderungen sind restriktiv zu handhaben, die Verfügbarkeit ist hoch.
  • Commodity: Prozesse sind unter Kostengesichtspunkten zu optimieren. Produkte werden eingekauft. Stabilität und Verfügbarkeit werden nicht überbewertet. Wo immer es geht, wird dem Standard Vorrang gegenüber der Individuallösung gegeben.
  • Weiß nicht: Hier sollte in jedem Einzelfall näher untersucht werden, ob spezielles Unternehmens-Know-how für den Prozess oder das Produkt notwendig ist. Sollte dies der Fall sein, dann ist der Prozess in Richtung „wertschöpfend“ weiterzuentwickeln. Im gegenteiligen Fall sollte die Strategie sein, den Prozess durch einen Standard abzubilden bzw. ein Standardprodukt für den Prozess einzukaufen.

Diese Überlegungen zu „Make or Buy?“ sind auf die lange Sicht, d. h. auf einen strategischen Zeitraum (z. B. von drei bis fünf Jahren) ausgerichtet. Neben den strategischen gibt es für die MoB-Entscheidung auch operative Aspekte.

[ header = Seite 3: MoB-Konzept aus operativer Sicht ]

MoB-Konzept aus operativer Sicht

Nachdem wir uns nun angesehen haben, wo die Schwerpunkte eines MoB-Konzepts aus Businesssicht betrachtet liegen, wenden wir uns nun den Gesichtspunkten zu, die sich ergeben, wenn man die Fragestellung nach dem Kaufen oder Selbstmachen aus einer konkreten Projektsituation heraus betrachtet.

In einem Entwicklungsprojekt geht es um die Herstellung eines Produkts – dabei kann es sich je nach Komplexität des Produkts um ein komplettes System (bestehend aus Hardware, Software und nicht funktionalen Elementen) handeln, das aus verschiedenen Teilen besteht (nachfolgend einfach Building Blocks genannt), oder um eine einfache Softwarekomponente. Wir wollen aber bei dem komplexeren Fall eines Systems für die weiteren Betrachtungen bleiben. Die einzelnen Building Blocks eines komplexen Produkts werden in einer Produktstruktur sichtbar, wo das Gesamtprodukt in seine Komponenten zerlegt wird. Die Building Blocks bilden die Vertikalen des MoB Grids (Schritt 1 in Abb. 3).

Für eine MoB-Entscheidung ist aber neben der Komponentensicht auch die Wertschöpfungskette zu betrachten. Dazu zählen alle Aktivitäten, die zur Herstellung des Produkts erforderlich sind. Die typischen Aktivitäten in einem Entwicklungsprozess sind: Prototyping, Spezifikation, Design, Produktion und Übergang in den Betrieb. Trägt man nun die Aktivitäten in der Wertschöpfungskette als Horizontalen entlang der Building Blocks auf (Schritt 1 in Abb. 3), so ergibt sich für die weitere MoB-Analyse ein praktisches Gitter.

Es fehlen nun noch die Kriterien (Schritt 2 und 3 in Abb. 3), um auf Basis dieses MoB Grids strukturiert zu einer qualitativ hochwertigen MoB-Entscheidung zu gelangen (Schritt 4 in Abb. 3).

Abb. 3: MoB-Prozess

Typischerweise wird eine MoB-Entscheidung von einem Projekt aus den konkreten Zwängen des Tagesgeschäfts heraus getroffen. Die typischen Kriterien hierbei sind meist ein limitiertes Budget, ein enger Zeitplan oder konkrete Projektvorgaben bezüglich zu verwendender Konzepte oder sogar vorgegebener Komponenten. Was hierbei oft zu kurz kommt, sind die strategischen Gesichtspunkte, daher sind wir in diesem Artikel darauf explizit im vorherigen Abschnitt eingegangen. Eine unstrukturierte Liste von operativen Kriterien könnte also ungefähr so oder ähnlich aussehen: Kosten, Zeit, Effizienz, Erfahrung, Fähigkeiten, Synergie, Wiederverwendung, Werkzeuge, Zulieferer, Qualität etc.

Kommen wir nun nochmal kurz auf den MoB-Prozess zurück: Es gibt also eine ganze Menge von Kriterien, gegen die jede Aktivität im MoB Grid zu bewerten ist. In der Kompetenzanalyse (Schritt 2 in Abb. 3) steht die Bewertung der eigenen Fähigkeiten (Know-how, Erfahrung, Ressourcen bzw. Werkzeuge) im Vordergrund. Diese sind gegen strategische Überlegungen aus dem Business abzuwägen (zukünftige Märkte, Alleinstellung im Wettbewerb, Kundenorientierung etc.) – siehe Innovationsstrategien (Core-/Context-Prozesse) im vorigen Abschnitt. In der Transferanalyse (Schritt 3 in Abb. 3) steht die programmatische Betrachtung im Vordergrund: Abwägung finanzieller Aspekte (wieder getrieben vom Business) gegenüber den Risiken beim Auslagern von Aktivitäten.

[ header = Seite 4: Entscheidung ]

Entscheidung

Sind alle Kriterien, sowohl strategische aus dem Business als auch operative aus dem Tagesgeschäft eines Projekts, in die Bewertung eingeflossen, gilt es, aus diesem detaillierten Gitter eine Entscheidung zu aggregieren (Schritt 4 in Abb. 3).

Zunächst bietet sich eine Synthese über die Wertschöpfungskette an, also eine MoB-Strategie für jeden Building Block abzuleiten (Resultat unter jeder Vertikalen in Schritt 4 von Abb. 3). Je differenzierter die Betrachtung der Prozessschritte, je feinmaschiger also das MoB Grid, je schwieriger fällt die Aggregation – eine generelle Regel, wie die Anwendung einer Triage (wertschöpfend, Commodity, weiß nicht) bei der Bewertung der Unternehmensprozesse, kann bei der Bewertung aus Produktentwicklungssicht nicht gegeben werden. Bei einer Wertschöpfungskette, die beispielsweise Spezifikations-, Design- und Produktionsaktivitäten kennt, sind folgende Kaufstrategien möglich:

  • kaufe Handelsware (COTS)
  • kaufe wie spezifiziert
  • kaufe wie entworfen

Werden weitere Aktivitäten im MoB Grid berücksichtig, fällt eine Differenzierung noch feingranularer aus – die Kooperation mit einem Partner in einer frühen Prototyping-Phase kann beispielsweise die notwendige Innovation in einem für das Unternehmen noch unbekanntem Geschäftsfeld schaffen.

Die MoB-Strategie, die nun auf Basis einzelner Building Blocks vorliegt, lässt sich schließlich noch weiter aggregieren, indem generische Komponenten betrachtet werden. Durch das Clustern von einzelnen Building Blocks können MoB-Entscheidungen projektübergreifend getroffen werden, beispielsweise für ganze Produkte oder Produktfamilien (MoB-Strategie in Abb. 4).Abb. 4: MoB-Strategie für ein Remote-Power-Supply-System

[ header = Seite 5: Konsequenzen für die Architektur ]

Konsequenzen für die Architektur

Was bedeuten nun die vorherigen Überlegungen für die Architektur eines Unternehmens? Es scheint aus strategischer Sichtweise notwendig zu sein, dass sich die Verantwortlichen ein präzises Bild darüber machen sollten, in welchem Business das Unternehmen seinen Mehrwert generieren will/soll. Dazu ist einerseits das vorhandene Know-how im Unternehmen zu berücksichtigen, andererseits braucht es aber auch die Fähigkeiten der Mitarbeiter, dieses Know-how entsprechend umzusetzen.

Wie sind nun die Auswirkungen auf die Businessarchitektur? Die Mechanismen, mit denen das Business zunächst implementierungsneutral dokumentiert und spezifiziert wird, sollten entsprechende Verfahren bieten, um eine Kennzeichnung der Prozesse gemäß den zuvor genannten Kategorien vorzunehmen (wertschöpfend, Commodity, weiß nicht). Es kann davon ausgegangen werden, dass bestimmte Fähigkeiten (Capabilities) zum Kerngeschäft des Unternehmens gehören. In einer ersten Inventur kann eine Landkarte (Capability Map) von bestehenden Prozessen erstellt werden. Jede Prozessänderung verändert dann auch diese Landkarte.

Die Erfahrung aus verschiedenen Projekten zeigt eine Häufung von Prozessen aus der „weiß nicht“-Kategorie. Ist die strategische Ausrichtung vorgegeben, kann bei dieser Kategorisierung auch entschieden werden, in welche Richtung der Prozess weiterentwickelt werden soll. Das gibt die notwendige Flexibilität nach Bedarf und Budget, die Weiterentwicklung von Prozessen und Produkten voranzutreiben.

Was sind nun die Auswirkungen auf die Softwarearchitektur? Aufgrund der Building Blocks ist die notwendige Modularität gegeben, Anpassungen so vorzunehmen, dass nicht ein System als Ganzes zu ändern ist, sondern einzelne, abgegrenzte Teile. Wird die Umsetzung durch eine serviceorientierte Architektur (SOA) geplant, können Building Blocks unmittelbar in Services abgebildet werden. Dies ermöglicht auch die notwendige Flexibilität für das MoB-Konzept, falls sich durch Änderungen in der Unternehmensstrategie die Capability Map verändert. Um die Trennung zwischen core und context in der Softwarearchitektur umzusetzen, bietet es sich z. B. an, zwischen IT-Infrastrukturservices und fachlichen Services zu differenzieren. Detailliertere Unterteilungen erfolgen durch die Definition von z. B. fachlichen Domänen, in denen eng zusammenhängende Services gruppiert werden (Kohäsion). Genauere Handlungsanweisungen für die Umsetzung der einmal festgelegten Strategie erfolgen durch die Definition von Policies, die zu beachten sind. Policies sind die Vorgaben, die mithilfe der Governance durch verschiedene (Test-)Verfahren überprüft werden.

Weitere Überlegungen zur Detaillierung der Policies und zur Umsetzung und der Überprüfung würde den Rahmen dieses Beitrags überschreiten. Es wird u. U. als separates Thema einen der nächsten Beiträge bilden.

Geschrieben von
Hermann Schlamann
Hermann Schlamann
Hermann Schlamann ist unabhängiger Berater, erfahrener IT-Architekt, Trainer und Coach und seit vielen Jahren mit dem Thema ITUnternehmensarchitekturund Serviceorientierung befasst. Er hat lange Jahre bei Schweizer Großbanken die Einführung von SOA maßgeblich mitgestaltet. Hermann ist regelmäßigerReferent auf nationalen und internationalen Fachtagungen und Verfasser von Fachbeiträgen. Er ist Autor eines Buchs über Serviceorientierung und gibt Trainings für IT-Unternehmensarchitektur und SOA.
Tobias Fleischmann
Tobias Fleischmann
Tobias Fleischmann ist System Ingenieur bei Cassidian, einer EADS-Tochtergesellschaft. Er beschäftigt sich schwerpunktmäßig mit der Entwicklung von Aufklärungssystemenund deren Vernetzung zu komplexen Sicherheitslösungen. Sein Fokus liegt im Bereich Systemarchitektur und Prozess. Er berichtet von seinenErfahrungen aus einem Projekt, in dem er als Enterprise-Architekt und stellvertretender Chief SW Engineer agiert.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: