REA.06: Was ist eigentlich ein Produkt oder Service?

Relevante Assets eines Produkt-orientierten Unternehmens

Mit den früheren Blog Beiträgen habe ich wesentliche Vorbedingungen diskutiert, um mittels pfiffiger Komponenten Architektur eine Systemlandschaft aufzubauen, die von einer Organisation beständig weiterentwickelt wird. Dabei beinhaltet «Weiterentwickeln» nicht nur das beständige Weiterentwickeln einer einzelnen Komponente, sondern auch das Wegwerfen und Neuimplementieren einer Komponente.

Nun ist die Frage: wie bauen wir eine Organisation auf, die Weiterentwickeln oder auch das Wegwerfen und Neuimplementieren einer Komponente per Design ermöglicht? Welche Design Prinzipien sind anzuwenden?

Dazu ist es sinnvoll zwei orthogonale Assets eines Unternehmens anzusehen. Diese sind in der Enterprise Architecture des Unternehmens zu finden. Diese Assets sind immer da. Unabhängig davon, ob die Assets dem Unternehmen gleichgültig sind oder ob sie transparent und aktiv bewirtschaftet sind. Diese Assets existieren. Es sind zum einen die Produkte & Services, welche den internen oder externen Benutzern angeboten werden, zum anderen die Geschäftsfähigkeiten (Business Capabilities), welche die Produkt und Services anbieten – und die ein Unternehmen für deren Entwicklung und Betrieb besitzen muss. Dieser Blog ist dem Begriff «Produkt» gewidmet

Produkte und Services als Assets des Unternehmens

Vor 30 Jahren, als Digitalisierung noch nicht integraler Bestandteil von Produkten und Services war, war der Begriff Produkt vor allem Sales orientiert. Ein Produkt wurde – stark pauschalisiert beschrieben – in einem Projekt gebaut, dann dem Verkauf angedient, um es möglichst teuer zu verkaufen und der Fertifunf angedient, um es zu bauen und dem physischen oder telefonischen Kundendienst, um unglücklichen Kunden wieder ein Lächeln in das Gesicht zu zaubern.

Mit der immer stärker werdenden Digitalisierung, dem immer höheren Druck der Kundenorientierung und dadurch notwendigen Differenzierung am Markt erweitert sich der Produkt Begriff um die Services rund um das (Kern-)Produkt. Das «neue Produkt» ist das Kernprodukt mit seinen kundenorientierten Services rund um das Kernprodukt. Mittlerweile sind es vielfach die Services rund um das Kernprodukt, welche den Gewinn des Unternehmens erwirtschaften mit dem Kernprodukt als Träger. Die Servicequalität zusammen mit dem Preis für die Services erlauben die Differenzierung gegenüber der Konkurrenz.

Beispiele sind Services rund um das Erlebnis Auto. Das Auto transportiert Fahrgäste von A nach B. Services sind heutzutage die Gestaltung des digitalen Entertainments im Auto, die Verbindung zu Wartungsdiensten in Werkstätten, die Kompatibilität zu Ladestationen, Navigation und weitere. Bei Versicherungen ist es das Einreichen eines Schadens per Mobile Phone direkt vom Ort des Schadens aus, der Download des Steuerdokumentes für die Steuererklärung im der myPortal App. TWINT ist ein Beispiel für vielfache Services rund um das Kernprodukt Payment. Es lassen sich beliebig viele Beispiele aufführen.

Die spannende Frage: Was ist denn nun ein Produkt oder Service?!

Diese Frage kann hier nicht beantwortet werden. Diese Frage kann nur Kontext spezifisch im Unternehmen beantwortet werden. Die Granularität und der Charakter eines Produktes oder Service hängt von den Fähigkeiten ab (siehe nachfolgende Diskussion), die ein Produkt oder Service anbietet, von den Kunden, welche das Produkt oder den Service nutzen und vom Ökosystem mit seinen Rahmenbedingungen wie es etwa Regulatorien oder Compliance Regeln darstellen.

Ein paar Grundcharakteristiken halte ich hier fest zu allgemeinen Eigenschaften eines Produktes oder Service. Der Einfachheit verwende ich im Weiteren nur noch den Begriff Produkt für «Produkte und Services».

Ein Produkt kann Teil eines Produktes sein

Ein Produkt kann eigenständig einem Nutzer zur Verfügung gestellt werden, das identische Produkt kann gleichzeitig Teil eines anderen Produktes sein. Ein Beispiel kennen wir alle: Die Tintenpatrone im Tintenstrahldrucker. Die Tintenpatrone ist Teil des verkauften Druckers, eine Tintenpatrone ist gleichzeitig ein eigenständiges Produkt (und die eigentliche Cash-Cow der Druckerhersteller). Weniger bekannt ist das bei Versicherungen. Ein versichertes Risiko, zum Beispiel Haftpflichtversicherung kann eigenständig verkauft werden, sie kann auch Teil einer Unternehmensversicherung sein, die mehrere Risiken abdeckt. Viele Versicherungen haben das (leider) noch nicht begriffen und bauen zwei Produkte, ein Standalone Produkt und ein undefiniertes Zwischending in einer Unternehmensversicherung. Zusätzlich könnte zum Beispiel eine Versicherung als «Produkt» (Service) eine Risikoanalyse als Beratungsleistung für Unternehmen anbieten. Die Beratung ist nicht das Kernprodukt einer Versicherung, konzeptionell jedoch ein eigenständiges Produkt und ein (eventuell optionales) Teil eines Produktes, das sich Unternehmensversicherung nennen könnte.

Es existieren rein interne Produkte

Bei einem internen Produkt sind die Nutzer die Mitarbeitenden in der gleichen Organisation, welche das Produkt baut. Das entspricht der Eigenfertigung. Ein gutes Beispiel ist im Automobilbau eine Typenplattform, die es erlaubt mehrere unterschiedliche Modelle mit vollkommen unterschiedlichem Aufbau auf der identischen Plattform aufzubauen. So basierten zum Beispiel von VW Golf IV, Bora, New Beetle, Skoda Oktavia, Seat Leon, Audi A3 und Audi TT auf der identischen Plattform. Daher kommt auch der Plattform Gedanke, der nun immer stärker in Unternehmen fliesst, die digitale Produkte bauen. Dabei ist eine Plattform nicht die Basis-Infrastruktur wie Cloud oder Netzwerk, sondern ein Produkt – oder ein Set an Produkten – welches den Nutzern fachliche Fähigkeiten (siehe nachfolgende Diskussion) zur Verfügung stellt. Bei einem Zahlungsprovider könnte ein Produkt zum Beispiel die fachliche Aufgabe haben eine Zahlungstransaktion abzuwickeln, bei einer Versicherung einen Schaden auszubezahlen. Mit der Fähigkeit eine Zahlungstransaktion auszuführen kann eine Überweisung durchgeführt werden, oder die Zahlungen im Rahmen einer Einzugsermächtigung ausgeführt werden. Die Fähigkeit einen Schaden auszubezahlen kann für jede Sachversicherung durchgeführt werden, also für Haftpflicht-, Hausrat- oder Rechtsschutzversicherung.

Der Sinn Produkte und Services zu definieren

Aus den Betrachtungen zu Produkten (und Services) sehen wir, dass ein Produkt aus Produkten besteht. Auch eine Plattform ist ein Produkt, das aus Produkten besteht bzw. bestehen kann. Wichtig ist zu erkennen welche Charakteristiken relevant sind, um ein Artefakt mit dem Begriff Produkt zu bezeichnen. Ich sehe die folgenden Charakteristiken als minimal relevant an

• Ein Produkt wird verwendet «as is». Das bedeutet der Benutzer muss, ja darf nicht wissen, wie das Produkt innen aufgebaut ist, um es zu benutzen. Alleine seine Fähigkeiten und die Art, wie das Produkt seine Fähigkeiten anbietet (die Schnittstelle zum Nutzer) ist relevant. Der passende Ausdruck dafür ist: das Produkt wird als Blackbox verwendet.
• Ein Produkt besitzt klar definierte und dem Nutzer bekannte Fähigkeiten. Eine Fähigkeit besitzt insbesondere einen fachlichen Bezug, der im Ökosystem der Anwendung des Produktes dem Nutzer einen Mehrwert liefert.
• Ein Produkt besitzt einen eigenen Lebenszyklus, der unabhängig ist von anderen Produkten. In dem Lebenszyklus bietet das Produkt seine Fähigkeiten über die Schnittstellen an. Dabei sind eine klare Versionsverwaltung und Transparenz zwingend, die eindeutig definieren, welche Fähigkeiten über eine Version der Schnittstellen dem Nutzer angeboten werden.

Das entspricht doch identisch dem Begriff der Modularisierung – könnte man nun argumentieren. Allerdings ist ein wesentlicher Unterschied zur Modularisierung vorhanden. In der Modularisierung werden häufig zwei Charakteristiken verletzt: das Blackbox Prinzip und der eigene unabhängige Lebenszyklus.

Wenn wir diese Charakteristiken in eine moderne Cloud Weltanschauung übertragen, so bedeutet dies

• Ein Produkt besitzt sein eigenes Repository – oder mehrere Repositories, die zusammen in einer Pipeline zu einem Artefakt zusammengeführt werden.
• Ein Produkt besitzt ein klar definiertes öffentliches API und kommuniziert über klar definierte und versiononierte Schnittstellen mit der Umgebung. Eine Schnittstelle kann auch eine Benutzerschnittstelle, also ein GUI sein.
• Ein Produkt bietet klar definierte fachliche Fähigkeiten (Business Capabilities) an.
• Die Schnittstellen des Produkts unterliegen einer Versions- und Konfigurationsverwaltung, welche die Entwicklung und Nutzung der Fähigkeiten des Produkts über die Zeit für den Nutzer transparent darstellt.

In der digitalen Welt wird dazu der oft Begriff Komponente verwendet. In meiner Wahrnehmung ist jedoch auch der Begriff der Komponente ebenso unscharf wie der Begriff des Moduls. Die oben genannten Charakteristiken Blackbox, fachliche Fähigkeiten und eigener Lebenszyklus werden nicht konsequent eingefordert und sind in vielen Systemlandschaften verletzt. Diese Verletzung kann mittel- und langfristig zu einem Versions-Nightmare führen mit unvorhersagbaren Fehlerzuständen bei einem Update einer „Komponente“.

Der nächste Blog (publishing 8. Nov 2024) beschäftigt sich mit dem Zusammenhang zwischen Produkten und Geschäftsfähigkeiten oder (Neudeutsch) Business Capabilities.

• Blog 1: Ein Essay über resiliente Enterprise Architecture
• Blog 2: Architektonische Irrungen
• Blog 3: Das Spiel mit der Komplexität
• Blog 4: Komplexität verteilen – Die Grössen einer Komponente
• Blog 5: Die Komplexität des Schnittstellen Netzwerkes

P.S.: Alle Bilder sind frei lizenzierbaren Quellen entnommen – oder meine eigenen. Daher können alle Bilder aus dieser Blogserie entsprechend Attribution weiter verwendet werden.

Resilince in Enterprise Architecture © 2024 by Rainer Grau is licensed under CC BY-SA 4.0