Fintech für die Versicherungs Industrie - oder wie Digital Insurance aussehen kann

Liebe Leser,


Gerade habe ich diesen Blog gesehen.


http://banknxt.com/48332/fintech-1000-shows-not-so-many-insurance-tech-startups-yet/


Wir alle kennen ja schon die Fintechs für die Bankenindustrie. Für die Versicherungsindustrie hat sich bisher kaum etwas getan - bis jetzt.


Nun werden Insurance Techs nicht gleich die ganze Branche massiv verändern und alles neu machen. Aber man kann sich sehr wohl überschaubares und schnelles Geschäft, wie die KFZ Versicherung oder auch die Krankenversicherung hernehmen und einen neuen Ansatz fahren. Lebensversicherungen spielen aktuell kaum eine Rolle und vor allem haben diese eine Laufzeit von 30 Jahren oder mehr. Welche Insurance Tech wird sich diese Schuh anziehen? Wohl keine...


ABER ein Punkt kommt bei der Diskussion zur Digitalisierung immer wieder hoch, wenn ich mit Kollegen darüber rede - man muss Branchenübergreifend denken! Nur in einem Branchen Silo (Versicherung) denken, bringt einen hier nicht weiter. Was meine ich damit? Wir alle kennen wahrscheinlich Begriffe, wie Connected Car oder auch Connected Patient und Smart Home, oder nicht?


Es ist nun kein Geheimnis mehr, dass man KFZ Versicherungen individuell nach der Fahrweise abschließen kann. Hier und da gibt es jetzt schon Versicherer, die Boxen in Autos einbauen und damit individuelle KFZ Versicherungen abhängig von der Fahrweise anbieten. Die Frage ist für mich: Muss ich wirklich eine Extra Box in das Auto einbauen, wenn ich ein Connected Car habe? Wahrscheinlich eher nicht. Da ist es doch besser, wenn ich als Versicherer direkt auf die Daten des Autoherstellers zugreifen kann und die Daten aus dem Connected Car auswerte und nutze.


Viel spannender wird dann noch die Frage, was passiert, wenn autonomes Fahren und Google Car kommen. Kaufen wir dann wirklich noch Autos, wenn die Autos autonom fahren und man Mobility Services via Google & Co buchen können? Autos werden dann auch weiterhin gekauft, wenn auch etwas weniger in den Ballungsgebieten - siehe meinen Blog Local Motors Company. Aber wer versichert dann die selbst fahrenden Autos - der Mobility Service Provider, der Nutzer für die 1 Stunde, die er das Auto braucht...?? Wir wissen es nicht genau. Aber etwas wird sich ändern und die Versicherer müssen sich darauf einstellen!


Einen ähnlichen Ansatz kann man bei Connected Patient anwenden. Wobei hier die Frage sofort hochkommt, ob man kritische Patientendaten bekommen, auswerten und nutzen darf. Auf alle Fälle kann man zumindest in der Schadenabwicklung unterschiedliche Beteiligte in den Prozess automatisiert einbinden. Diesen Use Case werde ich aber noch einmal gesondert beleuchten.


Schauen wir noch kurz in Richtung Immobilienbranche. Hier kommt das nächste Buzzword namens "Smart Home" auf uns zu - oder besser gesagt, es ist schon da. Wenn ich Smart Home in der Gesamtheit zu Hause installiert habe und überall Daten erfassen kann, wem kann man diese zur Verfügung stellen und wohin hat man Verbindungen?


Stellen wir uns einmal folgendes Szenario vor: Herr Müller ist mit dem Auto unterwegs und zu Hause stellt das Haus fest, dass die Küche brennt - warum auch immer. Der erste Unterschied ist hier schon: das Haus stellt es fest - wenn der Leser richtig aufgepasst hat! Wenn das Haus mit Smart Home schon feststellt, dass es brennt, kann es auch gleich eine Meldung an die Feuerwehr, Polizei, Krankenwagen, Hausbesitzer und auch an die Versicherung absenden. Letzteres wäre dann im Sinne von "Achtung, hier passiert gerade ein Schaden!" Für die nähere Schadens- und Ursachenbeurteilung können dann auch Daten vom Smart Home System genutzt werden.


Für die weitere Gebäudeversicherung können diese Daten ebenfalls genutzt werden, um dann eine individuelle Versicherung anbieten zu können, aber auch um zusätzliche Leistungen (Value Added Services) anbieten zu können, Bsp: Beratung, Vorschlag für Smart Home Konzepte, und vieles mehr. In diesem Punkt geht es vor allem darum, ein Stück heraus aus der Versicherungsecke zu kommen und neue branchenübergreifende digitale Geschäftsmodelle zu entwickeln. Damit meine ich im Speziellem die sogenannte "Customer Experience" für die Kunden von Versicherungen. Dies geht aber nur dann entsprechend gut, wenn ich als Versicherer eine aaS Strategie fahre und modulare Services / Micro Services etabliere. So kann sich dann der Versicherte individuell seine Versicherung zusammenstellen und seine Daten mit einfließen lassen.


Weitere Anregungen sind gerne willkommen....


Viele Grüße
Danny

Managing the Complexity of Digital Transformations – Or How to Manage and Govern a Multi-Speed IT Environment

by Marc Lankhorst (Bizzdesign) and Danny Weinberger (R+V Allgemeine Versicherung AG)

In the previous blog we wrote about the impact of multi-speed IT on the IT organization and enterprise architecture. Let us now talk about the different options for managing a multi-speed IT approach.

The management and governance of the agile fast track architecture and the stable and robust baseline architecture we discussed previously can be done by various options, which are shown in Figure 1. You might assume that we just talk about a simple two-speed IT approach as mentioned elsewhere, but it is not as easy as it looks.

Figure 1

Why Bi-Modal IT Won’t Work

Many organizations tend to establish a Digital Office function that includes governance for new digital initiatives supported by a dedicated team. That sounds a bit like the bi-modal approach as advocated by Gartner, shown in the picture below. As every approach, this has pros and cons. Separate teams working on separate issues sound like a good idea as each team can concentrate on their specific tasks bringing this forward to the target.

However, it also results in disconnecting the two teams. When establishing two different teams working on two different tasks, the communication between them will suffer, independently from the quality of the communication strategy. Furthermore, the team of the stable baseline might feel disadvantaged in their reputation (being perceived as ‘slow’ and ‘old-fashioned’ compared with digital initiatives), access to resources and budget, and power and influence in the organization. This circumstance often leads to major conflicts between the two teams and the quality of the work may suffer dramatically. 

Furthermore, the bi-modal approach, unfortunately, does not seem to offer a sustainable, long-term solution. It is even found to be incapable of putting forward a potential solution to the simplified agility-stability problem. Moreover, organizations that actually implemented a bi-modal approach had to face harsh consequences, like the formation of artificial silos for products, processes and people, and institutionalizing stagnation by deterring innovation in traditional platforms with the excuse that “if it isn’t broken, don’t fix it”.

Next to this, there is also a major architectural and technological challenge: the stable baseline systems need to be connected to the rapidly changing innovative systems of the new digital business domain, since they often contain core business data. Such systems of record are indispensable but difficult to integrate. Putting this integration and transformation burden on the digital business team may slow them down to an unacceptable pace, whereas the baseline team is already quite busy enough keeping the lights on, and dealing with new rules and regulations. Hence, it appears we need something in between, to bridge both the cultural and the technical differences between a stable baseline world and a rapidly moving digital business world.

Is Tri-Modal the Solution?

A tri-modal approach, as shown in Figure 2, offers a more sophisticated and flexible method than a simple two-speed scenario. This approach considers three different teams: the Pioneers, the Settlers, and the Town Planners. The Pioneers develop the target digital organization enabling innovation and co-creation, using agile techniques and methods. At the other side of the spectrum, the Town Planners represent the baseline , providing stable and robust services to the Pioneers and Settlers. Simultaneously, they manage external service providers via a service integration and management function and add value to the other teams. The Settlers are positioned in the middle and deal with transitions or rather transition architectures, helping the organization industrialize and personalize the target services, systems, and applications to fit with the baseline architecture, and to gradually transform that baseline architecture to accommodate the new digital business needs. They also ensure a better management of workflow and communication as it proceeds from one level to the next. 

Figure 2

Towards a Cellular Structure

Evolving the tri-modal approach results in a cellular structure (Figure 3), where each team (or rather a team member of one such team) supports the teams above, fulfilling their objectives and thus being involved in the daily business of this team. Different teams are responsible for different parts of the IT, some focused on stable baseline functionality, some on advanced digital capabilities, and some in between. Applying DevOps practices implies that each team is fully responsible for building and running their part of the IT. Communication between teams happens on a daily basis at the ‘shop floor’, and necessary decisions across teams can be made quickly and efficiently. Furthermore, relevant stakeholders from business and IT can smoothly be integrated into the team work, contributing their views and providing strategic and tactical guidance when needed. Enterprise architects are one such group of stakeholders, tasked to ensure that the teams’ efforts and results are aligned with the organization’s digital strategy and medium- to long-term goals.

Figure 3

Managing the Complexity of Digital Transformations – Or How Multi-Speed IT Affects the IT Organization and Enterprise Architecture

by Mark Lankhorst & Danny Weinberger

Looking back to many discussions about Digital Strategy with different organizations, most of them have the challenge of going through a balancing act day by day. Firstly, a Digital Oriented Organization needs to accept that the roles and responsibilities of Business and IT will merge with each other, whilst both parties need to enable business and IT innovations towards digital business needs. Simultaneously, they need to set up an agile approach across the whole organization for developing and managing innovative digital business models, dealing with new business moments, and realizing the associated technology and services. Finally, cost control for IT and its services also remains high on the agenda of the organization.

Such changes are especially difficult in organizations with a large legacy base, both in terms of IT and in terms of organizational processes and culture. In finance, for example, we see that banks and insurers are under attack from nimble fintech companies and struggle to respond in a timely way. They are weighed down by complicated IT landscapes, a risk-averse culture and ever increasing regulatory compliance demands. In architecture terms, they have an outdated baseline architecture in place and need to develop a new target architecture to enable innovative and digital business models, best realized by an agile approach.

But at the same time, they cannot simply replace the old systems that run their core business processes, or radically change the way these systems and the associated business processes are maintained. The operational risks, compliance demands and the culture of the development organization preclude such a radical approach. This is where the so-called two-speed IT approach comes into play; the IT and Enterprise Architecture teams needs to manage the complexity of both worlds, the stable, risk-averse legacy environment and the innovative and agile digital business.

From Traditional Baseline to Digital Target                 

The stable and robust baseline architecture is reflected at the right side of the picture below. This is fully managed by proper portfolio, architecture, and release management based on defined and established methods, standards and frameworks. This architecture is normally quite stable and underpinned by robust internal and external services, which seldom change during the year. The focus is on reducing cost and risk, keeping the lights on for the business, and not on developing innovative business and IT solutions.

In the context of Enterprise Architecture, the target architecture represents the envisioned future state of the organization, which partly replaces and transforms the baseline architecture. Nowadays, the development of a target architecture mostly is a medium-term transformation project taking 1 or 2 years to implement a full complex architecture landscape and solutions across various business and/or IT domains. But is this really sustainable in the near future? The speed of change of the environment and the competitive pressure from innovative new players demands a much faster response. In our view, this approach will change dramatically, or rather this is already changing in many organizations.

Even in the near future, we will talk about developing and integration micro-services into the existing architecture landscape, and we will be faced with managing these services and their related service providers, creating and entirely new role for architects.

So, let us assume an insurance company plans to develop a community platform to enable co-creation for designing and developing new insurance products? Simultaneously, they want to improve the customer experience by proper omni-channel management. From the current perspective this seems to be a medium-term transformation project as we have seen all the time. To be fair, they are even taking too much time for getting the low-hanging fruit.

Adding Agile to the Mix

But what happens if you break it down into smaller bunches of services, or rather micro-services, to be developed by different providers and other players using an agile approach? Using methods and concepts like minimal viable products, agile development and DevOps, each of these smaller services can rapidly be developed and deployed to prototypes ending up in working products within 2-4 weeks. Doing so, it is crucial to understand that this approach entails fast and agile experiments which may also fail. Consequently, a culture of accepting failures, learning from them and doing it right afterwards is essential for long-term success. You can also think about so-called AB-testing, trying out different variants of services with customers for identifying which variant works better in practice. No one has the right answers right from the beginning, so you just have to test what fits better to customers. Naturally, this approach implies a fast and agile development process with frequent releases of new services, coordinated by concepts like the Agile Release Train from the Scaled Agile Framework. These agile release trains, combined with the infrequent releases of the stable baseline architecture are jointly considered as part of the Enterprise Portfolio Management function we have written about last year.

Figure 1. Two-speed IT and Enterprise Portfolio

So, the enterprise architecture team has to manage and govern both worlds towards a common digital architecture vision and strategy. But the crucial question here is, how to manage and govern this digital world. Quite often you hear about approaches like bi-modal or tri-modal IT. But do these really help you deal with the complexity of digital transformation? We will address this in our next blog.

Liebe Leser,

gerade habe ich diesen Beitrag entdeckt.

http://www.welt.de/wirtschaft/article151797625/Fruchtgummis-gibt-es-jetzt-auch-aus-dem-3-D-Drucker.html

Es kommt doch - die Lebensmittel aus dem 3D Drucker! Ich bin gespannt, was noch alles möglich ist, wenn wir 10 Jahre weiter sind. Die Digitale Revolution nimmt langsam aber stetig ihren Lauf und wird die Gesellschaft gravierend verändern!

Was meint die Community dazu?

Schöne Grüße
Danny

Blog: Enterprise Architecture und Agile Development: Gegensätze ziehen sich an?

Marc Lankhorst (BiZZdesign), Danny Weinberger (CSC)

Warum Agilität wichtig ist

Agilität ist zu einer wichtigen Fähigkeit der Unternehmen geworden. Das Tempo, bei dem die Kunden sich verändern, bei dem neue Gesetze und Verordnungen ihre Dienstleistungen und Prozesse beeinflussen und die Schnelligkeit, mit der Wettbewerber, wie Google und Apple, sie herausfordern, führt allzu oft zu einem enormen Druck auf das Unternehmen. Dabei kann sich der Druck in unterschiedlicher Art und Weise bemerkbar machen, wie zum Beispiel Druck sich schnell zu verändert, oder neue Technologien einzuführen, Wachstum zu generieren oder Kosten zu reduzieren. In Folge dessen ist die Agilität schlichtweg notwendig, um überhaupt mit ständigen Innovationen schnell auf dem Markt agieren zu können. Beides, Innovation und Flexibilität, sind für eine nachhaltige Positionierung am Markt notwendig.

Agile Development ist zur Norm für die Softwareentwicklung geworden. Aber wahre Agilität des Geschäfts und des Unternehmens benötigt mehr als die Schaffung von Scrum-Teams. Mehr noch, fokussiert man sich nur auf die Agilität in kleinem Rahmen, die durch Agile Software Development erreicht wird. Allerdings sieht man dann den Wald vor lauter Bäumen nicht mehr. Die Frage, die sich hier stellt ist,  warum will man als Unternehmen agil sein und was ist dafür notwendig?

Agilität in großem Maß organisieren

Ein Unternehmen ist mehr als nur eine Ansammlung lokaler Entwicklungen kleiner Teams. Die Puzzlestücke, an denen diese Teams arbeiten, müssen irgendwie zusammenpassen. Und hoffentlich ist da eine Vision für die Zukunft, eine Geschäfts- und IT-Strategie, eine Reihe von Zielen, die die Organisation anstrebt. Das ist, wo Enterprise Architecture auf den Plan gerufen wird.

Klassische Enterprise Architecture hat eher einen Top-Down-Charakter, bei dem man umfassende Pläne entwickelt, bevor man diese implementiert. Die Agile-Bewegung, mit dem Fokus auf Anpassung an Veränderung und Widerstand gegen ‘Big Design Up-Front’ (BDUF), ist eigentlich das Gegenteil.

Beide Ansätze haben ihre also Vor- und Nachteile. Klassische Enterprise Architecture Management kann zu einer langsamen und bürokratischen Organisation führen, die es nicht versteht mit der Zeit zu gehen. Eine losgelöste Reihe von unterschiedlichen Scrum-Teams ohne integrativen, überliegenden Ansatz zu haben, kann zu einer unschlüssigen Architekturlandschaft voller agile-Silos führen. Dennoch können wir die Unternehmen in die Lage versetzen,  sich als ganze Einheit zu bewegen, wenn wir auf die Stärken beider Ansätze bauen, ohne ein zentral bestimmendes Management zu haben, das Innovationen und Entwicklungen gleich im Keim erstickt.

Beispiel: das Scaled Agile Framework

Moderne Entwicklungen, wie das Scaled Agile Framework (SAFe) und Disciplined Agile Delivery (DAD), bewegen sich in diese richtige Richtung. Nehmen wir beispielsweise SAFe, dargestellt in vereinfachter Form in der untenstehenden Abbildung.

Figure 1. Scaled Agile Framework (simplified)

SAFe nutzt einen iterativen Ansatz über mehrere Ebenen, bei dem wir die typischen agile-Teams in der untersten Ebene finden können. Sie liefern Ergebnisse in einer agile-typischen Frequenz von 2 bis 3 Wochen. In der mittleren Ebene werden die Ergebnisse dieser Teams integriert und mittels von Solution Architecture Konzepten wie Architecture Runway und Agile Release Train veröffentlicht, was sicherstellt, dass diese zusammenpassen. Diese Ebene wiederholt sich mit einer Geschwindigkeit, die sich aus einer Mehrzahl der Team-Ebene ergibt und so potentiell lieferbare Produkte alle 2 bis 3 Monate erarbeitet. Auf der obersten Ebene sind die großen, langzeitlichen Entwicklungen angesiedelt. Genau dort findet  Enterprise Architecture Management statt. Die Unternehmensstrategie mündet ebenfalls in dieser Ebene und stellt den Rahmen für alle groß angelegte Architekturentscheidungen mit hohem Einfluss, Festlegung von Prioritäten und schließlich die Zuweisung der notwendigen Mittel.

Auf dieser obersten Ebene befinden sich die etablierten Enterprise Architecture Methoden, wie TOGAF. TOGAF hat ebenfalls eine sich wiederholende Struktur, die sich im bekannten „Architekturentwicklungs“ Diagramm des Architecture Development Method (ADM) wiederspiegelt. Dieses in einem agilen Kontext anzuwenden, erfordert jedoch einige Anpassungen. Insbesondere muss die Enterprise Architecture dafür offener nach außen und konsequent Geschäftsorientiert, Endkunden- und Ergebnisfokussiert werden. Ein Geschäftsergebnis kann ein Endkundenprodukt sein, welches durch Services, Fähigkeiten (Capabilities), Ergebnisse und Artefakte, aber auch Unternehmenstransformation die neue Strategien implementiert, beschrieben wird.

Betrachten wir TOGAF weiter, dann benötigt TOGAF‘s Implementation Governance (Phase G im ADM), die an Implementationsprojekte und – Programme koppelt ist, eine Überarbeitung. Besonders, dass agile Methoden sich stark auf Rückkopplungen  verlassen, während TOGAF‘s Governance von Natur aus mehr auf die Zukunft ausgerichtet ist. TOGAF‘s Architecture Change Management (Phase H) ist eine typische Anlaufstelle für diese Art von  Feedbacks. Wir werden dies in einem zukünftigen Blog näher ansprechen.

Figure 2. Agile EA with TOGAF 9.1

Ferner sind SAFe, DAD, TOGAF und verwandte Methoden weiterhin sehr IT-zentriert. Entsprechend dem SAFe, ist die Rolle des Enterprise Architect „[...] ganzheitliche Technologieimplementation an[zu]treiben [...]“. Aber wahre Enterprise Architects sind nicht alleine auf die Technologie fokussiert. Vielmehr ist die Geschäftsarchitektur ein immer wichtiger werdender Teil der Arbeit, wie zum Beispiel: Abbildung der Strategie, Fähigkeiten-basierte Planung, Mehrwert Ermittlung, Geschäftsprozessmanagement, Lean Six Sigma und andere geschäftsbezogene Disziplinen fehlen noch im Gesamtbild. Ein wirklich agiles Unternehmen braucht mehr als eine agile IT alleine. Wir wollen diese Problematik der Unternehmensagilität in zukünftigen Blogs weiter vertiefen.

Verfolgen Sie uns weiter für agilere Enterprise Architecture, und lassen Sie uns in der Zwischenzeit Ihre Gedanken zu dieser Thematik wissen. 

Zentrales Datenmanagement für alle

Hallo,

Gerade habe ich diesen Artikel in der Zeit gelesen.

http://www.zeit.de/politik/deutschland/2015-04/fdp-digitalisierung-datenschutz-nicola-beer

In der jetzigen Phase der Digitalisierung ist das zugegebenermaßen ein realistisches Szenario für die nahe Zukunft. Aus architektonischer Sicht betrachtet, ist diese Idee durchaus umsetzbar, bedarf allerdings konsequent angewandter Regeln im Datenmanagement und in der Datenverantwortung (Data Ownership).

Noch viel wichtiger dabei spielen allerdings allgemein gültige Standards für die Datenarchitektur und für die Schnittstellen. Ansätze in der Open Group sind hier zu erwähnen, wie UDEF (Universal Data Element Framework).

Auch politisch kann das Auswirkungen haben. Viele kennen wahrscheinlich die Diskussion zum bedingungslosen Grundeinkommen. Bisher sind die unterschiedlichen Ansätze mehr oder weniger Ideen ohne wirkliche finanzielle Grundlage. Mal angenommen wir hätten solch ein zentrales Datenmanagement, wo jeder Bürger Hoheit über seine Daten hat. Wer die Kundendaten dann haben möchte, kann u.U. auch dafür bezahlen. Nebeneinkünfte für Bürger sind mit diesem Ansatz auf alle Fälle realisierbar. 

Schönes WE
Danny

Die Digitale Community entwickelt ihre Autos selbst. Ändert sich die Architekturwelt dabei?

Die digitale Community entwickelt und baut ihre Autos in Zukunft weitestgehend selbst. Wie beeinflusst das die Automobilunternehmen und das Architektur Team?

Aktuell gibt es einige Diskussionen mit Kunden rund um digitale Strategien, den Einfluss auf Geschäftsstrategien und Modellen und die Rolle von Enterprise Architecture dabei. Im Rahmen dieser Diskussionen sehe ich es jedoch immer wieder, dass Dinge, wie Mobile Strategy, Apps und digitale Plattformen in den Vordergrund gestellt werden. Ja, das sind alles wichtige Themen, die man auch angehen und umsetzen muss. Wie sieht allerdings eine digitale Geschäfts- und IT Strategie aus und welchen fachlichen Mehrwert liefert die IT und das Architektur Team am Ende des Tages?

In den letzten Tagen bin ich auf dieses Unternehmen gestoßen, Local Motors Company. https://localmotors.com/. In diesem Unternehmen designed und entwickelt eine globale Community die Autos, die sie aktuell haben will oder sich demnächst wünscht. Danach kann man in eine Local Factory gehen und sich das Auto mit einem 3D Drucker drucken lassen. Ein Minderaufwand an Montage komplettiert das Ganze dann noch. Das Unternehmen selbst stellt „nur“ den Rahmen zur Verfügung, stellt strategische Partnerschaften sicher und initiiert Projekte und Design Wettbewerbe für die Community. Sieht so ein Automobilkonzern der Zukunft aus?

Mit Sicherheit ist Local Motors im Moment kein Konkurrent für VW, Mercedes, BMW & Co, hätte allerdings durchaus das Potential dazu. Der Einfluss dieses Konzeptes auf die traditionelle Automobilindustrie ist jedoch enorm. Was glauben die Leser dieses Blogs? Haben wir bei dem Konzept von Local Motors lange Supply Chains mit komplexen Abhängigkeiten und Risiken? Wahrscheinlich nein. Benötigen wir dazu grosse Car Factories, die mehr oder weniger zentral Autos produzieren? Auch hier wahrscheinlich ein grosses Nein. Nebenbei erwähnt: Dezentralisierung scheint nicht nur hier im Gange zu sein. Auch in der Energieversorgung geht schon seit vielen Jahren der Trend hin zur dezentralen Energieversorgung mit intelligenten Smart Home Konzepten.

Wenn ich mich mit Vertretern der traditionellen Automobilindustrie unterhalte, kommen oft Themen zur Sprache, wie Application Modernization, digitale Zielarchitekturen und Fähigkeiten, Cost Transparency / Reduction & Connected Car, etc – um nur Einige zu nennen. Gleichzeitig versuchen die Unternehmen direkt den Kunden anzusprechen, was die Händler stärker ins Hintertreffen geraten lässt. Den Unmut der Händler kann man sich vorstellen und manchmal schon jetzt erkennen.

Jetzt stellen wir uns einmal vor, ein traditionelles Automobilunternehmen geht einen ähnlichen Weg, wie Local Motors. Was würde dies ungefähr bedeuten?

Die kreativen Designer des Unternehmens könnten stärker in die Moderatoren- und Governancerolle hineingehen und Designs vorschlagen und begleiten oder auch Wettbewerbe für die Community initiieren. Sie werden mit Sicherheit eine aktive Rolle spielen. Allerdings werden grosse Teile von der Community getragen und entschieden. Im Grunde ist dies die ideale Plattform, um mit den Endkunden direkt in Kontakt zu treten und Rückmeldungen direkt und zeitnah zu erhalten.

Der Entwicklungsprozess von neuen Modellen bis hin zur Markreife, der bisher Jahre dauert und eine Vielzahl an Designern und Ingenieuren benötigt, kann unter diesem Ansatz in wenigen Wochen oder maximal Monaten von Statten gehen. Auch die Ingenieure können weiterhin eine aktive Rolle in diesem Zusammenhang spielen. Jedoch werden Sie stärker standardisierte Elemente aus ihrem Baukasten zur Verfügung stellen, die die Community dann nach Bedarf verwendet und kombiniert, um ihr individuelles Auto zu drucken. Sie müssen aber auch zulassen, dass völlig fremde Elemente für dieses Auto ebenfalls funktionieren. In Folge dessen, gehen sie auch in eine stärke Moderatoren-, Standardisierungs- und Governance Rolle hinein.

Das Community Mitglied kauft dann später kein Auto beim Händler, was vorher in einer Car Factory produziert wurde. Das Mitglied kann entweder sein Auto, eines der Projektautos oder die des Automobilunternehmens vor Ort in einer Local Factory „drucken und montieren“ lassen, und das für ein überschaubaren Preis. Lange Liefer- und Produktionsketten existieren in diesem Szenario kaum bis gar nicht. Der bisherige Autohändler kann dabei in die Rolle der Local Factory hineingehen und somit den Kontakt zum Kunden intensivieren und sein Geschäftsmodell erweitern. Es ist auch durchaus möglich, dass sich eine lokale Community rund um diese Local Factory bilden kann, die wiederum unabhängig Modelle und Konzepte entwickelt und umsetzt.

Im Aftersales Bereich kann für eine Reparatur notwendige Ersatzteile einfach vor Ort gedruckt und montiert werden. Eine lange und kostenintensive Produktion, Lagerhaltung von Ersatzteilen in Zentrallagern und Anfahrtswege- bzw. Zeiten fallen auch hier weg. Selbst für Oldtimer könnten dann noch Ersatzteile gedruckt werden, die man im Moment nicht erhalten kann. Die positive Kundenerfahrung kann man hier schon erahnen. Dabei kommt in mir gleich eine weitere Frage hoch. Gibt es in Zukunft überhaupt noch Oldtimer? Müssen dann überhaupt noch komplett neue Autos nach ein paar Jahren gekauft werden und spielt das Alter eines Autos dann noch eine Rolle? Im Grunde kann man doch dann Ersatzteile drucken und sein Auto permanent runderneuern oder abändern, je nach Bedarf und Wunsch. Wie sähen dann wohl ein Car Lifecycle Management, geschweige denn Garantie, Kulanz und der Preis eines Autos oder eines Ersatzteiles aus?

Ich könnte jetzt noch weitere Punkte beschreiben. Aber bleiben wir einmal kurz hier stehen und fragen uns Folgendes. Wenn wir schon solche gravierenden Änderungen im fachlichem Umfeld haben, was bedeutet dies dann erst aus architektonischer Sicht und für das Architektur Team?

Eines dürfte schon jetzt klar sein, komplexe Produktentwicklungs-, Produktions- und Lieferketten und Prozesse mit Abhängigkeiten existieren hier kaum noch, oder auch gar nicht. Folglich müssen auch keine komplizierten Unternehmens- und IT Architekturen für diese Bereiche entwickelt und dokumentiert werden. Wenn überhaupt noch, dann ganz rudimentär und auf eine Community zugeschnitten. Den Effekt auf die Kostenstruktur für das Unternehmen und die IT erwähne ich hier noch nicht einmal.

Da ich schon von einer Community sprach, was bedeuten dann eigentlich die Begriffe „Unternehmensarchitektur“, „Kunde“ und „Produkt“ (im Moment ein Auto) für das Architektur Team und für das Unternehmen?

Das Architektur Management wird sich unter diesem Gesichtspunkt wohl kaum noch auf das traditionelle Unternehmen und dessen Architektur alleine beziehen. Die Community, sprich Kunde, Partner, Lieferanten oder auch Konkurrenten sind Teil der gesamten Architekturbetrachtung und wirken aktiv an der Entwicklung der Architektur mit. Damit muss das Architektur Team auch erst einmal umgehen lernen und akzeptieren, Aufgaben auszulagern oder sogar einen Service Katalog anzubieten – die Frage ist dann an wen.

Wer ist dann eigentlich der „Kunde“ für das Architektur Team? In diesem Szenario steht das Architektur Team plötzlich vor der Tür der Endkunden, ist Teil der neuen Business Value Chain, bietet Services an, wirkt bei der Entwicklung von Business Modellen aktiv mit und verändert auch gemeinsam mit der Community die notwendige Architektur.

Die Herausforderungen an die Architektur Organisation, das Team, deren Fähigkeiten und Wissen werden entsprechend anders gelagert sein. Es geht viel stärker darum, sich Business Knowhow anzueignen, den Business Value ihrer Architektur und ihres Handelns in den Vordergrund zu stellen und dafür zu sorgen, die gesamte Architektur zu steuern und Standards zu definieren, die Community weit Gültigkeit haben, und die Community ein Stück weit zu begleiten. Langwieriges Modellieren und Dokumentieren von komplexen Architekturen, eine „Massenproduktion“ von Artefakten (oder auch Datengräbern) spielen für das Architektur Team kaum noch eine Rolle – das übernimmt teilweise auch die Community. Das Architektur Team muss dann „nur“ dafür sorgen, den Gesamtüberblick zu behalten, entsprechend zu steuern, und in der Lage zu sein, Analysen kundengerecht bereit zu stellen.

Die Frage nach dem „Produkt“ stellt sich jetzt allerdings auch noch. Wenn wir unter Umständen keine Autos mehr kaufen müssen, weil wir sie permanent erneuern und ändern können, was ist dann noch ein Produkt für das Unternehmen und das Architektur Team? Ist das noch ein Auto im traditionellen Sinne, oder reden wir hier zusätzlich auch von Intellectual Property? Wenn ja, wer ist Eigentümer vom Intellectual Property und deren Daten und was ist ein Preis dafür, wenn ich teilweise an der Entwicklung mitwirke?

Das Architektur Team ist also angehalten, ein umfassendes Datenmodell zu definieren und muss ebenfalls in der Lage sein die Daten und Informationen der gesamten Community zu verwalten, zu schützen, bereitzustellen und zu integrieren und der Community – je nach Bedarf – jederzeit und überall zu Verfügung zu stellen. Das Ganze muss dann natürlich noch funktionieren, wenn Millionen von Community Mitgliedern unterschiedlichste Tools und Standards verwenden, um sich am gesamten Prozess zu beteiligen.

Daten und Informationen werden also noch stärker ein „hohes Gut“ für das Unternehmen sein, als jetzt schon. Wer hier in der Hauptrolle ist, eine Plattform und ein intelligentes Architektur Management, Standards bereitstellt und gleichzeitig Business Value Chains mitgestaltet, dem wird eine tragende Rolle im Unternehmen zu Teil – Architektur Team.

Dies ist mit Sicherheit nur ein kleines Szenario und ich habe auch nicht den Anspruch der Perfektion oder Vollständigkeit. Aber jeder kennt doch den Begriff, der oft im Zusammenhang mit Enterprise Architecture genannt wird: Business and IT Alignment. In diesem Szenario kann man den Begriff ersatzlos streichen und dafür folgendes sagen: IT is part of the business. Das passt doch viel besser unter diesem Umständen.

Eines noch kurz zum Schluss. Ich habe mich in diesem Szenario auf die Automobilindustrie fokussiert. Unter dem folgendem Link finden Sie ein weiteres Beispiel, allerdings aus der Bauindustrie. http://www.yhbm.com/index.php?siteid=3

Wie sieht wohl ein Szenario aus, wenn man in naher Zukunft, wie jetzt schon in China, ein Haus einfach einmal drucken kann und binnen Tagen aufbaut? Wir können gerne darüber diskutieren.

You are in the driver seat, Architecture Team!