Digitalisierung und der kulturelle Wandel – Geht das eine ohne das andere?



Wir sehen es immer öfter. Es gibt bereits viele Organisationen und Unternehmen, die sich mit Digitalisierung bereits seit längerer Zeit befassen und andere fangen eventuell jetzt damit an.



Oft betrachtet man in diesem Zusammenhang zum größten Teil technische Komponenten, wie digitale Plattformen, digitale Services, Cloud, oder Mobile Apps- um nur einige zu nennen. Sprich man ist sofort in der technischen Diskussion und entwickelt technische Lösungskonzepte und Plattformen für eine digitale Organisation. Gerade Mobile Apps sind meist sehr beliebt bei vielen Unternehmen, wo man dann hektisch "agil" Apps wie am Fließband produziert. Schließlich möchte man über die neuen Kanäle den Kunden erreichen und die Innovationen nach außen tragen. Ob dann immer eine Mobile Strategy, geschweige denn eine Digitale Strategie oder gar Kultur existiert, ist nicht immer gesagt.



Der technische Aspekt ist mit Sicherheit ein wichtiges Element bei der Digitalisierung. Schließlich macht sie das Ganze ja erst möglich. Nachdem man die digitale Technik stehen hat, merkt man allerdings sehr oft, dass die Organisation lernen muss, damit umzugehen. Das bedeutet oft auch einen kompletten Wandel der bisher „beliebten“ Arbeitsweisen, Strukturen und liebgewonnenen Gewohnheiten.



Redet man beispielsweise über Fast Track IT und agiler Entwicklung bezieht sich das nicht nur zwangsweise auf den IT Bereich alleine. Nein, auch der Fachbereich stellt mit völliger Verwunderung fest, dass auch er sich verändern muss, wenn er agil und schnell Produkte an den Endkunden anbieten möchte. Schon befindet man sich nicht mehr nur im sogenannten 2-Speed IT, sondern schon eher bei Multi-Speed Organisation. Das hat sehr schnell Auswirkungen auf die Fachprozesse, Arbeitsweisen, Rollen & Verantwortlichkeiten auch in Verbindung mit dem IT Bereich – wie arbeitet man hier in agilen Teams zusammen, etc. Kommt dann noch ein liebgewonnener Anspruch hinzu, immer 120 % Lösungen haben zu wollen – selbst bei Fast Track IT Ansätzen – ist der Cultural Crash schon vorprogrammiert. Spätestens jetzt merkt man, dass man einen kulturellen Wandel braucht – nur wie?



Das ist dann oft der Zeitpunkt, wo jemand aus der Organisation den Pokal gewonnen hat, sich um Kultur und den Wandel zu „kümmern“. Das ist jedoch schwerer als gedacht. Wie wir einen kulturellen Wandel einleiten und umsetzen können, können wir vielleicht noch sagen. Da helfen einen Modelle wie die Kotter’s 8 Phases of Change.



Die Frage nach dem WOHIN sollen wir uns denn hin entwickeln bzw. WAS ist denn jetzt die neue digitale Ziel-Kultur, wird oft nicht beantwortet. Dummerweise ist das genau der wichtige Startpunkt für solch einen Kulturwandel. Hat man es dann noch versäumt, eine digitale Vision und digitale Strategie am Anfang der digitalen Initiative zu beschreiben und vor allem zu kommunizieren, hat man es jetzt umso schwerer. Aber Hauptsache wir haben die technische digitale Lösung stehen!



Die digitale Vision und die Definition der Digitalen Strategie einer Organisation sind extrem wichtig in diesem Kontext. Schließlich geht es hier vor allem darum, den Sense of Urgency (nach Kotter's 8 Phases of Change) zu beschreiben, zu kommunizieren und neue Werte, Normen, Zeichen, Symbole und Rituale für die neue digitale Ziel-Kultur zu kommunizieren - am besten vom Top Management aus. Hier fängt schließlich das Ganze an und nur so kann man sich überhaupt zu etwas Neuem hin entwickeln.



Das ist allerdings leichter gesagt, als getan – das muss man zugeben. Oft ist die Einsicht auf unterschiedlichen Management Ebenen nicht wirklich vorhanden, dass man sich überhaupt ändern muss.



Ist zusätzlich der wirtschaftliche Druck nicht vorhanden, da man ja „gute Zahlen“ schreibt (noch!), haben alle Beteiligten ihr eigenes Bild und Definition von Digitalisierung im Kopf und kommen die Mitarbeiter aus alten traditionellen Denkweisen nicht heraus, kann das eher eine Mission Impossible werden und der Sense of Urgency fehlt völlig! Dies beschreibt auch Herr Sattelberger in diesem Beitrag sehr gut.



https://spielraum.xing.com/2016/07/interview-thomas-sattelberger/?pid=b7237_cnwsl&xing_share=News



Um noch einmal auf die Eingangsfrage zurück zu kommen.



Bei der Digitalisierung geht es eben nicht nur darum, neue technische Konzepte und Lösungen zu entwickeln und den Rest so zu belassen – quasi alter Wein in neuen Schläuchen mit Digitalisierung „Light“.



Es geht vor allem darum, an den Grundwerten der bisherigen Modelle zu rütteln, alte Denkweisen und Strukturen abzuschütteln, neue digitale Geschäftsmodelle / Produkt & Service Strategien zu entwickeln und letztendlich völlig neue Werte und Normen für die digitale Organisation mit der strikten Orientierung am Kunden bzw. an der Community zu definieren – im Grunde also eine digitale Neuerfindung.

 

Um es also kurz zu definieren: Die digitale Strategie beschreibt eben einen gesellschaftlichen, kulturellen und wirtschaftlichen Wandel (Digitale Revolution) mit der allgegenwärtigen Gestaltung, Nutzung und Herstellung von Informationen, Daten, Produkten und Dienstleistungen in der Gemeinschaft (Community).

 

Was denkt die Community darüber…J?

 

Viele Grüße

Danny

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