CIO 016 - „Historisch gewachsene Systeme“ sind wie rostige Autos... - id cubic

Ich wünsche Ihnen ein frohes neues Jahr 2017, viel Gesundheit, Zufriedenheit und Erfolg für das neue Jahr und alles Gute.

„Historisch gewachsene Systeme“ sind wie rostige Autos, beide gehören ins Museum, aber nicht mehr in ein Unternehmen oder den Straßenverkehr. In Folge 16 geht es um die Ablösung von „historisch gewachsenen Systemen“. Warum ist es so schwer, aber dennoch oft strategisch notwendig die alten „Schätzchen“ abzuschalten? Das erfahren Sie in dieser Folge und es geht auch darum mit welchen Schritten bzw. Argumenten Sie Widerständen auf diesem Weg begegnen können.

Podcast: Play in new window | Download (Duration: 20:58 — 17.7MB)

CIO Podcast jetzt bewerten

Folgende Aspekte werden in der Podcast-Folge besprochen:

Sie haben „histroisch gewachsene Systeme“ und nun? [00:00:30]
Was hat es mit „Never change a running System“ auf sich? [00:03:00]
Der innovative Weg in die Zukunft geht nur mit moderner IT-Architektur [00:07:00]
5 Gründe warum es trotz strategischer Notwendigkeit so schwer ist alte Systeme abzulösen [00:09:00]
Erfolgreich Systeme einführen und alte Systeme abschalten in 8 Schritten [00:11:30]

Ich freue mich auf die nächsten Folgen im Jahre 2017. Dazu habe ich eine kurze Bitte an Sie als Hörerin beziehungsweise an Sie als Hörer dieses Podcast. Damit Ihre Themen und Fragestellungen auch in diesem Podcast immer besprochen werden können, möchte ich Sie bitten an einer kleinen Umfrage teilzunehmen und mir Ihre wichtigsten zwei Fragen beziehungsweise Ihre wichtigsten zwei Herausforderungen für dieses Jahr mitzuteilen. Das können Sie ganz bequem über ein anonymes Formular machen unter www.cio-podcast.de/umfrage.

So bekomme ich dann Ihre Themenwünsche und kann das dann auch einfließen lassen und eben diesen Podcast noch ein Stückchen näher an Ihre Bedürfnisse anpassen. Dafür bedanke ich mich schon jetzt ganz herzlich für Ihr Mitmachen und Ihre Teilnahme daran.

Diskutieren Sie mit, ich freue mich über Ihr Feedback.

Sie haben „histroisch gewachsene Systeme“ und nun?

Warum halten sich histroisch gewachsene Systeme so lange in Unternehmen?

Kennen Sie die Aussage „Dieses System ist historisch gewachsen, das ist halt so und das bleibt auch so“? Ich kann Ihnen gar nicht sagen, wie oft ich diese Aussage schon in Unternehmen gehört habe. Man könnte sagen, es ist auch die Nummer Eins Ausrede für alle IT-Probleme, wenn man an seiner Anwendungsarchitektur nichts verändern möchte.

Diese Haltung ist meiner Erfahrung nach besonders häufig anzutreffen im mittleren IT-Management. Ich habe mir oft die Frage gestellt: Warum ist das so? Und ich bin auf folgende Punkte gekommen. Wenn also der CIO, also Sie, die jetzt zuhören, etwas verändern möchte, dann gibt er das an das mittlere Management weiter und die wissen aber häufig, dass diese Software, die da vielleicht gerade abgelöst werden soll oder diese Veränderungen in der Architektur, die ansteht, ja, dass das bei den Mitarbeitern vielleicht nicht so gut ankommt, weil die dann selber an dieser Software hängen und vielleicht auch manchmal ein bisschen veränderungsresistent sind. #00:01:53-3#

Der Weg des vermeintlich geringsten Wiederstands

Daher gehen sie den vermeintlich einfachen Weg des geringsten Widerstandes und versuchen erst einmal – in Anführungsstrichen – Ausreden zu finden, warum man das Ganze denn jetzt nicht machen muss und warum das alte System doch eigentlich ganz gut ist und auch immer schön funktioniert hat. Das ist so super. Da braucht man doch jetzt nichts ändern.

Meiner Meinung nach funktioniert das aber leider nur solange bis das System endgültig ausgedient hat. Denn dann werden die Probleme umso größer, wenn Sie nicht vorgesorgt haben. Also, wenn Sie dieses System, was historisch gewachsen ist, einfach weiterbetreiben und hier und da nochmal Anpassungen vornehmen und vielleicht das eine oder andere in Anführungszeichen flicken, aber eigentlich nie den Kern der Probleme beheben. So ist es eben, wenn Sie Veränderungen anstoßen wollen, dann finden Sie immer Wege diese auch umzusetzen.

Also nehmen Sie den Versuch ruhig an und sagen: Ich möchte etwas verändern, ich möchte versuchen auch neue Systeme und neue Architekturen einzuführen. Wahrscheinlich könnten Ihnen, wenn Sie das angehen, zwei verschiedene Arten von Sprüchen begegnen. #00:02:58-7#

Was hat es mit „Never change a running System“ auf sich?

Stillstand gleich Rückschritt

Zum einen „Never change a running system“. Den kennen wir glaube ich alle. Und das andere ist, was häufig auch anzutreffen ist in solchen Prozessen: Na ja das System kann man ja gar nicht so leicht ändern, das neue System kann ja gar nicht alles, was wir in dem alten System haben. Das hören Sie dann häufig entweder von den Nutzern oder auch aus der IT-Reihe von den eigenen Mitarbeitern. Das ist sehr unterschiedlich.

Und lassen Sie uns doch mal diesen zwei Aussagen auf den Grund gehen und mal schauen warum das so ist. Die Aussage Nummer Eins „Never change a running system“, ich glaube, das kennen sie alle. Das ist, wenn man nichts verändern möchte halt eine einfache Aussage. Das System läuft doch. Ist alles gut. Besser nicht anfassen.

Warum ist diese Haltung in der IT-Organisation so brisant aus meiner Sicht? Ganz einfach, wenn sie versuchen etwas zu verändern und das vielleicht zu Schwierigkeiten kommt, es am Anfang nicht so läuft, dann sagt Ihnen jeder: Sehen Sie, habe ich Ihnen doch gesagt, nicht anfassen, das macht mehr Probleme als es nützt. #00:03:54-6#

Wenn Sie es aber schaffen und über diese ganzen Schwierigkeiten, die vielleicht damit zusammenhängen, auch überwinden, was Sie ja sollen und dafür treten Sie auch an, wenn Sie das erfolgreich durchlaufen, dann werden Sie wieder Widerstände treffen, weil dann gibt es immer Personen, die an dem Alten festhalten und das alte System einfach verteidigen und Ihnen dann die ein oder anderen Steinchen in den Weg rollen werden.

Gehen Sie konsequent den Weg der Veränderung

Was ist jetzt die Konsequenz? Ich schließe mal da raus, egal welchen Weg sie gehen, der wird nie einfach sein. Und Veränderungen durchzusetzen ist immer schwierig und ist immer mit viel Aufwand verbunden und mit vielen Gesprächen. Doch trotzdem sollten Sie aus meiner Sicht den Weg gehen und etwas verbessern und dafür antreten.

Denn nur, wenn sie den Status Quo nicht einfach hinnehmen und nur bewahren, dann werden Sie auch Fortschritte machen, dann werden Sie auch innovativ sein und besser sein als Ihre Mitbewerber. Weil das ist genau der Punkt. Wenn Sie alles so bewahren und einfach so lassen, wie es heute ist, dann haben Sie im Prinzip einen Stillstand, weil Sie bewahren nur das, was Sie heute schon haben. Und der Wettbewerb schläft nicht. Die anderen entwickeln sich weiter. Und somit ist eigentlich Stillstand auch in der IT oder vor allen Dingen gerade in der IT ein Rückschritt. #00:05:03-3#

Also nur das zu bewahren, was Sie heute haben, das wird Ihnen in Zukunft glaube ich nicht viel bringen. Deswegen nehmen Sie diese Mühen auf sich und versuchen auch da etwas zu verändern.

Stellen Sie alle Funktionalitäten auf den Prüfstand

Schauen wir uns mal die zweite Aussage an, die man auch wie gesagt häufig antrifft. „Das neue System kann ja gar nicht alles, was wir in dem alten System haben.“ Genau, das kann sogar auch aus gutem Grunde so sein und ich glaube, das sollten sie auch als CIO oder als IT-Manager dann auch mit gutem Grunde so vertreten, weil Sie haben über Jahre diese Software, die sie bisher im Einsatz haben angepasst und hier und da immer mal wieder was dran gebaut.

Und wenn Sie jetzt zum Beispiel vor der Entscheidung stehen, dass Standardsoftware einzuführen oder eine Cloud Software zu nutzen, dann bringt diese vielleicht andere Funktionalitäten mit als Sie bisher hatten oder vielleicht bringt sie auch nur einen Teil der Funktionalität mit, die sie bisher hatten. Und alles Weitere müssten Sie gegebenenfalls wieder neu konfigurieren. Es kann aber auch weitere gute Gründe geben, warum Sie diese alten Funktionalitäten, die Sie in der alten Software haben, gar nicht mehr brauchen heute. #00:06:04-5#

Weil Sie vielleicht den Geschäftsprozess vorher schon angepasst haben oder, weil sie in der Digitalisierung noch mehr automatisieren wollen und bestimmte Schleifen, die in der alten Lösung drin sind, die brauchen Sie einfach heute dadurch gar nicht mehr. Und deswegen denke ich kann man auch gut vertreten, warum Sie eben zu diesem Punkt auch wieder andere Argumente liefern können, warum das Ganze doch ganz gut ist.

Konzipieren Sie erst die Prozesse und führen dann die Software ein

Bitte denken Sie nur da dran, erst auch die Prozesse anzupassen und dann die Software einzuführen. Andersrum ist es erfahrungsgemäß deutlich schwieriger. Und darauf komme ich aber gleich nochmal zurück, wenn es um die Einführung dieser Themen geht. Sie haben natürlich in dem System vielleicht nicht alle Funktionalitäten. Aber dafür haben Sie zum Beispiel bei Standardsoftware die Möglichkeit, wenn Sie einen Release Wechsel haben, diese recht standardisierte Software auch relativ schnell upzudaten. Wenn Sie hingegen ganz viele Eigenanpassungen, Modifikationen haben, dann ist zum Beispiel so ein Release Wechsel oder irgendwelche rechtlichen Rahmenparameter neu einzubauen deutlich aufwendiger als andersherum. #00:07:02-1#

Der innovative Weg in die Zukunft geht nur mit moderner IT-Architektur

Konsequente strategische Ausrichtung an innovativen Themen erfordert eine Transformation der IT-Architekturen

Also warum sollten Sie jetzt bei all diesen Widerständen, die möglicherweise auf Sie zukommen könnten, den Mut haben ein neues System oder eine neue IT-Architektur einzuführen und vor allen Dingen auch, das ist aus meiner Sicht auch ein super wichtiger Schritt, dann auch das nicht mehr verwendete alte historisch gewachsene System abzuschalten. Also wirklich irgendwann auszumachen? Warum sollten Sie das machen?

Aus meiner Sicht, wenn Sie strategisch denken und in Richtung der innovativen IT-Organisation unterwegs sind und sich auf diesen Weg begeben möchten, dann benötigen Sie Innovationen, neue Designs ihrer Software, also neue Architekturen auch an vielen Stellen und die Transformation Ihrer Organisation. Und das ist eigentlich, ist so eine stetige Weiterentwicklung und Sie benötigen in der digitalisierten Welt eine moderne IT-Architektur und Anwendungssysteme mit offenen Schnittstellen, digitalisierte Prozesse ohne Medienbrüche und eine gewisse Flexibilität sollte diese Software auch bieten, um sie an Neuerungen anzupassen und schnell auf Marktbedürfnisse reagieren zu können. #00:08:05-2#

Die Flexibilität ist bei älteren IT-Architekturen häufig nicht hoch genug

Häufig ist das mit dem historisch gewachsenen System eben genau an der Stelle nicht der Fall. Die können Sie nicht mal eben flexibel anpassen, weil die so sehr verwoben sind in ihrer ganzen Architektur, dass Sie, wenn Sie an einem Schräubchen drehen, immer gleich an ganz vielen Schräubchen drehen. Und meine Vorstellung ist es, dass es sich lohnt genau dieses Gebilde etwas flexibler zu gestalten und zu ermöglichen, dass Sie an einem Schräubchen auch drehen können ohne, dass Sie gleich alle anderen Schräubchen drehen müssen, weil sie eine IT-Architektur haben, die eine gewisse Offenheit und eine gewisse Flexibilität und Modularisierung untereinander mitbringt.

Das heißt, Sie haben gewisse Module, die erst einmal für sich stehen, die aber trotzdem so offen programmiert und konfiguriert sind, dass sie mit den anderen zusammenarbeiten. Ich glaube, das ist ganz wichtig, dass man auf so etwas hingearbeitet und da eben halt auch in Kauf nimmt vielleicht den einen oder anderen Widerstand überwinden zu müssen. #00:09:02-9#

5 Gründe warum es trotz strategischer Notwendigkeit so schwer ist alte Systeme abzulösen

Noch mal ganz kurz zusammengefasst. Das sind aus meiner Sicht fünf Gründe, warum es trotz der strategischen Notwendigkeit, die ich gerade erläutert habe, sehr, sehr schwer ist oft alte Systeme abzuschalten.

1. Das System funktioniert und erfüllt den heutigen Zweck

Im Prinzip funktionieren sie und sie erfüllen den heutigen Zweck. Was nicht heißt, dass sie auch den zukünftigen Zweck erfüllen oder diese zukünftigen Entwicklungen mitgehen können.

2. „Fürstentümer“ in der IT-Organisation

Das schon Angesprochene, die Haltung des mittleren Managements, des Punkt 2 also das sogenannte „Fürstentum“, das haben Sie bestimmt auch schon häufiger kennengelernt. Dann gibt es dann doch irgendwie kleine Inseln, wo bestimmte Leute dann einfach die Hoheit drüber haben und eben mit ihren Vorstellungen versuchen diese alten Systeme auch zu bewahren. Was auch nachvollziehbar ist, alles menschlich, aber eben an der Stelle fürs Unternehmen häufig nicht unbedingt hilfreich.

3. Nutzergewohnheiten verändern

Der Punkt 3 sind die Nutzergewohnheiten. Wenn Sie jetzt Prozessanpassungen machen, natürlich müssen sich die Nutzer umstellen. Das ist auch immer wieder ein langwieriger Prozess. #00:10:01-6#

4. Widerstand aus den eigenen Reihen in der IT

Genau wie Punkt 4 ist die Umgewöhnung aller Beteiligten aus der IT Organisation. Also Ihr eigenes Team, auch da müssen Sie erst einmal dafür werben und quasi auch die neue Software erst einmal beliebt machen und irgendwie den Nutzen aufzeigen, warum das denn alles sinnvoll ist, was Sie da vorhaben.

5. Andere Funktionalitäten der neuen Software

Und der 5. und letzte Punkt ist was ich schon angesprochen hatte, häufig eben andere Funktionalitäten als die bisherige Software. Nehmen Sie zum Beispiel mal das Thema Cloud. Sie wollen eine Anwendung, die Sie bisher haben, in die Cloud verlagern. Dann finden Sie ganz, ganz viele Gründe, die Mitarbeiter und vielleicht auch Ihre Kollegen im Management, warum das alles nicht geht.

Aber vielleicht sollte man auch mal andersrum den Ansatz wagen und überlegen, was Ihnen das bringt und wie man das hinbekommen kann, dass es eben funktioniert. Ich mein klar, haben Sie vielleicht die einen oder anderen Themen der Sicherheit, die werden da immer angesprochen. Wenn man das in die Cloud packt, dann ist das nicht sicher. Andersrum müssen Sie mal fragen, wie viele Mitarbeiter haben Sie denn, die sich um die IT-Security kümmern? #00:11:02-8#

Also ich meine, kann da nicht der Cloud-Anbieter, der irgendwie vielleicht hunderte Leute mit dem Thema beschäftigt und irgendwie alles mit Firewalls abgeriegelt hat, kann er nicht die Sicherheit vielleicht sogar viel besser gewährleisten? Das ist einfach nur mal eine Frage, wo man mal drüber nachdenken kann und eben dieses Thema auch mal beleuchten kann und versuchen kann auch mal Wege da rauszufinden und nicht immer nur die Gründe zu suchen, warum das alles eben nicht geht. Ich glaub so kommen Sie auf jeden Fall viel, viel weiter und vielleicht auch viel, viel schneller weiter. Deswegen kommen wir zum nächsten Thema.

Wie gestalten Sie denn jetzt so eine Systemveränderung und Ablösung eines alten Systems?

Erfolgreich Systeme einführen und alte Systeme abschalten in 8 Schritten

Die 8 Schritte der Systemablösung im Überblick

Da würde ich Ihnen die folgenden 8 Schritte ans Herz legen:

Zum einen erstmal die Zielsetzung zu klären,
die bestehenden Geschäftsprozesse zu analysieren ist der Punkt 2,
der Punkt 3 ist die Soll-Konzeption für zukünftige Geschäftsprozesse.
Punkt 4, die Funktionalitäten für zukünftige Software aussuchen und erörtern.
Punkt 5, alle Beteiligten frühzeitig mit einbinden.
Punkt 6 ist dann die neue Software auswählen, sich überlegen. Brauche ich On-Premises Lösung? Kann ich eine Cloud-Lösung nehmen? Möchte ich eine Standardsoftware nehmen? Möchte ich selber entwickeln? Und so weiter und so fort. Alles, was damit zu tun hat, was für Lösungen gibt’s auf dem Markt? Markt Screenings, alles was damit zu tun hat.
Punkt 7, dann die Software tatsächlich einzuführen, komme ich gleich nochmal drauf mit all den Punkten.
Und dann ist der Punkt 8 auch echt extrem wichtig. Die alte Software nach einer festgelegten Übergangsphase auch wirklich abzuschalten.

Ich gehe auf diese 8 Punkte nochmal genauer ein.

Schritt 1: Die Zielsetzung klären

Die Zielsetzung klären, Punkt 1. Welchen Nutzen erwarten Sie, wenn Sie jetzt das System ablösen? Warum machen Sie das Ganze? Was ist Ihr Ziel dahinter? Und was ist der Nutzen, den sie damit verfolgen? Also was wird besser? Welche Geschäftsprozesse verbessern Sie und vielleicht an welcher Stelle machen Sie auch einen Schritt in Richtung Automatisierung und Digitalisierung gewisser Punkte. #00:12:59-3#

Schritt 2: Bestehende Geschäftsprozesse analysieren

Punkt 2, analysieren Sie bestehende Geschäftsprozesse, die durch die neue Software auch unterstützt werden sollen. Schauen Sie, wo es heute Medienbrüche? Wo machen Sie gewisse Tätigkeiten manuell? Wo haben Sie die Chance zu automatisieren oder eben noch mehr in dem Prozess zu digitalisieren?

Schritt 3: Soll-Konzeption der Geschäftsprozesse

Erstellen Sie in Punkt 3 die Soll-Konzeption für die zukünftigen Geschäftsprozesse. Also überlegen Sie sich. Wie soll denn der zukünftige Geschäftsprozess oder diese zukünftigen Geschäftsprozesse, die mit der Software unterstützt werden, aussehen? Und welche Prozessschritte sind vielleicht noch einmal Kontrollschritte, wo nochmal eine manuelle Prüfung eingebaut werden soll oder wo kann eigentlich das System vollautomatisch handeln? Und Sie brauchen eben nichts mehr dabei zu tun. All das sollten Sie überlegen.

Schritt 4: Funktionalitäten und Umfang der neuen Software und IT-Architektur

Dann im Punkt 4 überlegen Sie, welche Funktionalitäten sind für die zukünftige Software wichtig? Was brauchen Sie in Zukunft an Software, damit Sie auch strategisch richtig aufgestellt sind, damit es in Ihrer Anwendungsarchitektur passt? #00:14:05-0#

Überlegen Sie sich sogenannte Design-Prinzipien, die Ihre Software erfüllen muss. Das heißt: Gibt es bestimmte Programmiersprachen? Gibt es bestimmte Schnittstellenformate? Sind es bestimmte andere technische Sachen, die Sie mit abprüfen sollten bei der Software? Und wie gesagt die Funktionalitäten an sich, die können doch deutlich und signifikant von den heutigen abweichen und das ist gar nicht mal so schlimm, weil wie gesagt, Sie haben alles von der Software auf den zukünftigen Prozess ausgerichtet und nicht auf den heutigen. Weil nur so machen Sie auch einen Schritt nach vorne. Wenn Sie alles wie heute abbilden, na dann kommen Sie nicht weiter.

Schritt 5: Die Beteiligten frühzeitig einbinden

Und der nächste Schritt bei Punkt 5 ist, binden Sie frühzeitig alle Beteiligten mit ein. Die Beteiligten sind unter anderem natürlich auch ihre Nutzer. Also nehmen Sie Vertreter der Nutzer mit dazu, nehmen Sie vielleicht aus der Fachbereichsseite frühzeitig Leute mit dazu. Im besten Falle wird es auch von der Fachbereichsseite angefordert, dass sich da etwas tut. #00:15:02-2#

Und ansonsten schauen Sie, dass Sie direkt mit den Fachbereichen ins Gespräch kommen und die mitnehmen und nehmen sie gerade bei so Systemveränderungen auch immer ihre IT mit, also auch bis runter auf die Mitarbeiterebene. Machen Sie klar, warum dieser Wechsel und dieser Wandel notwendig ist und vor allen Dingen auch essentiell wichtig ist.

Ein ganz kurzes Beispiel hier mal zur Verdeutlichung. Weil ich habe immer festgestellt, Software ist immer so was, das können sich auch nicht immer alle vorstellen und gerade in den Fachbereichen, je nachdem wie versiert die Leute da mit der Software sind, ist das für sie einfach nicht greifbar und die sagen: Na ja, ich habe doch jetzt hier mit meiner Software alles wunderschön gehabt. Warum soll sich das denn jetzt ändern? Und die erkennen dann nicht den aus IT sich übergeordneten Nutzen, wenn Sie jetzt zum Beispiel offene Schnittstellen haben oder bestimmte andere Sachen haben. Das macht Ihnen aus der IT-Sicht das Leben leichter und senkt aus der Sicht auch Kosten. Aber eben für den Nutzer ist es vielleicht auch erstmal an der einen oder anderen Stelle umständlich. #00:15:56-5#

Beispiel:

Und da können Sie das ganz plakative und vielleicht ein bisschen zugespitzte Beispiel nehmen des Auto Kaufens. Wenn Sie jetzt zu einem Autohaus rausgehen und Sie möchten ein neues Auto kaufen. Nehmen wir mal an, Ihr Autos ist sehr, sehr alt. Sie haben da schon ein bisschen Rost dran und so weiter. Dann gehen Sie auch nicht zum Autohändler und sagen:

„Ich möchte ein neues Auto kaufen von dem und dem Fabrikat. Die und die Variante hätte ich gerne so und so die Farbe, die und die Ausstattung und so weiter. Und dann machen Sie noch ein bisschen Rost dran. Das war am alten Auto ja auch.“

Na das wird niemand sagen. Und warum ist das eben bei Software so? Bei Software haben wir immer wieder das Thema:

„Ja bauen Sie doch bitte die neue Software genauso wie die alte.“

Nee, das macht einfach keinen Sinn. Weil da werden Sie sich einfach nicht weiterentwickeln. Da haben Sie die ganze alte Technik und das macht einfach keinen Sinn. Von den Funktionalitäten her sollten Sie natürlich die Kernfunktionalitäten schon mit einbauen, also, dass die Geschäftsprozesse auch funktionieren. Aber ich glaube, da muss man den Leuten auch plakativ klarmachen. Den ganzen alten Ballast aus der alten Software das – in Anführungsstrichen – historisch Gewachsene, das wollen wir auch bewusst über Bord schmeißen. #00:16:59-6#

Das wollen wir auch nicht mehr mitnehmen. Und ich glaube dann schaffen sie es auch da den Fortschritt zu erzielen und die Mitarbeiter mitzunehmen und einzubinden. Ich glaube, dass es eben an mancher Stelle notwendig ist, da auch mal ganz plakativ so ein Beispiel zu bringen und einfacher zu sagen, so vielleicht mal drüber nachdenken und dann eben die Sachen auch einführen.

Schritt 6: Auswahl der neuen Softwarelösung und IT-Architektur

Dann kommen wir zum 6. Punkt. Wenn Sie das eben haben und die Unterstützung auch von Ihren Mitarbeitern haben und von dem Fachbereich haben, dann kann es an die Auswahl der neuen Software gehen.

Dann können Sie sagen: Okay, welche Funktionalitäten können wir denn jetzt mitnehmen? Welche brauchen wir, sind essentiell? In den Gesprächen und Sie wissen dann auch, auch in den Fachbereichen, gewisse Sachen müssen einfach über Bord geworfen werden. Die wollen wir nicht mitnehmen. Aber eben bestimmte Kernfunktionalitäten brauchen wir einfach.

Schritt 7: Software wenn möglich iterativ einführen

Im Punkt 7 führen Sie dann die ausgewählte Software ein. Wenn möglich in iterativen Schritten, sodass der Nutzer auch wieder direkt eingebunden ist, auch im Test eingebunden ist und schon stufenweise auch Ergebnisse sieht. Ich glaube, das ist ganz, ganz wichtig. #00:17:57-8#

Weil dann werden Sie auch hinterher eine hohe Akzeptanz haben, weil die brauchen Sie ja auch. Denn wir wollen auch die alte Software abschalten.

Schritt 8: Alte Software nach Übergangsphase abschlaten

Das ist Schritt 8. Also die alte Software abschalten, nachdem Sie vielleicht eine notwendige Übergangsphase definiert haben. Kann da durchaus sein, dass Sie sagen: Ich kann das jetzt nicht von heute auf morgen abschalten. Ich lass das jetzt noch ein paar Monate laufen. Und dann haben wir Tag X und da wird das alte eben abgeschaltet.

Dann wird die Software archiviert nach allen Vorgaben, die Sie eben einhalten müssen. Vielleicht haben sie noch Aufbewahrungsfristen und so weiter. Oder Sie müssen die Software so archivieren, dass Sie sie auch auf anderen Rechnern und anderen Servern wiederherstellen können. Das ist auch alles gut, das sollten Sie dann auch alles tun. Aber eben ganz wichtig. Die Software ist dann nicht mehr erreichbar für die Nutzer, sondern es gibt nur noch die neue Software, die dann auch fertig getestet und eingeführt ist und eben auch voll verwendet werden kann. Und dann haben Sie es geschafft. Dann haben Sie die Ausgangsfrage, ein historisch gewachsenes System ablösen, wirklich auch vollendet und vollzogen. #00:18:58-1#

Und vielleicht haben Sie jetzt ein paar Anhaltspunkte bekommen, warum das oft so schwer ist. Ist, wie gesagt, meine persönliche Beobachtung und meine persönliche Meinung auch an vielen Stellen dazu. Es ist aber aus meiner Sicht eben auch strategisch sehr häufig notwendig genau all diese Widerstände in Kauf zu nehmen und trotzdem etwas Neues einzuführen und das auch durchzusetzen. Super. Das war es für die heutige Folge.

Ihr Feedback

Wir freuen uns über eine Bewertung des CIO Podcasts bei Apple Podcasts und den anderen Portalen!
Fünf Sterne stehen für „gefällt mir sehr gut“. Herzlichen Dank!

Wie gefällt Ihnen diese Folge des CIO Podcasts? Senden Sie Ihr Feedback, Anregungen und Wünsche einfach über das Kontaktformular direkt an die Redaktion des CIO Podcasts (nicht öffentlich):

[contact-form-7 id=“189″ title=“CIO Podcast“]

Weitere Podcast Folgen finden Sie hier.