CIO 028 – IT-Strategie Umsetzung ohne weitere Insellösungen zu schaffen – Hörerfrage

IT-Strategie Umsetzung ohne Insellösung

IT-Strategie Umsetzung ohne Insellösung

In CIO Podcast Folge 28 geht es um die Umsetzung von IT-Strategien ohne dabei weitere Insellösungen zu schaffen oder diese in der Zwischenzeit entstehen zu lassen, bis die IT-Strategie vollständig umgesetzt ist.

Die heutige Folge beantwortet eine Hörerfrage:

„Wie kann man die IT-Strategie mit einem starken Vernetzungsgedankten der IT-Architektur umsetzen und gleichzeitig den Betrieb aufrecht halten ohne den Aufbau von Insellösungen weiter zu fördern?“

Folgende Aspekte werden in der Podcast-Folge besprochen:

  • Umsetzungs-Roadmap für die IT-Strategie entwickeln [00:00:30]
  • Übergangszeit bis zur IT-Strategieumsetzung ohne Insellösungen [00:03:00]
  • Punkt 1: proaktives Anforderungsmanagement [00:04:00]
  • Punkt 2: konsequentes und selbstbewusstes Architekturmanagement [00:08:30]

Viel Spaß beim Hören des Podcasts. Ich freue mich, wenn Sie ein kurzes Feedback hinterlassen, wie Ihnen die Folge gefallen hat und Sie mit diskutieren.

Ihre Hörerfrage

Die Hörerfrage lautet:

„Wie kann man die IT-Strategie mit einem starken Vernetzungsgedanken der IT-Architektur umsetzen und gleichzeitig den Betrieb aufrechterhalten ohne den Aufbau von Insellösungen weiter zu fördern.“

Umsetzungs-Roadmap für die IT-Strategie entwickeln

Zunächst mal vielen lieben Dank für die Frage, die ich natürlich gerne beantworte und ich denke dieses Mal auch beantworte in Form eines Podcast und nicht separat an Sie, weil dieses Thema sicherlich für viele sehr, sehr spannend ist und interessant ist und darauf möchte ich jetzt in diesem Podcast dieser Folge heute mal genauer drauf eingehen.

Zunächst mal impliziert die Frage, dass Sie die IT-Strategie bereits entwickelt haben und damit Ihre Zielrichtung schon klar ist. Also diese haben Sie bereits ermittelt und in dem Fall wie ich das verstanden habe, soll die IT-Architektur modular gehalten werden und stark miteinander vernetzt sein.

Ein weiteres Ziel ist, dass Sie Insellösungen abbauen wollen und nicht weiter fördern wollen. Das ist glaube ich in vielen IT-Organisationen weit verbreitet, dass es viele verschiedene Insellösungen gibt, die auch alle gute Dienste tun und für ihre Funktionalität sicherlich sehr, sehr gut und wertvoll sind, aber eben in einer vernetzten Welt nicht mehr ganz so optimal sind und manchmal sind es auch die großen monolithischen Systeme, die wenig Schnittstellen zu anderen Systemen haben, die dann sehr viel Aufwand produzieren im Betrieb und im Unterhalt wenn es ein neues Update gibt und so weiter, dann machen diese Systeme meistens sehr, sehr viel Arbeit und das ist natürlich ein sehr, sehr gutes Ziel das etwas reduzieren zu wollen. #00:02:24.5#

Und im ersten Schritt würde ich empfehlen, dass Sie eine gesamte Umsetzungs-Roadmap entwickeln für Ihre IT-Strategie, wo Sie die strategischen Projekte und die strategischen Maßnahmen erstmal einplanen und vielleicht auch schon mal eine Reihenfolge überlegen, vielleicht auch Verknüpfungen überlegen, also was zunächst abgeschlossen sein muss bevor Sie mit einer anderen Maßnahme starten können und zumindest schon mal die groben zeitlichen Eckdaten für sich festlegen. Das ist sicherlich sehr, sehr hilfreich.

Dann haben Sie einen Gesamtüberblick über alle strategischen Maßnahmen, die sich aus Ihrem Strategieprogramm ergeben, aus Ihrer IT-Strategie.

Übergangszeit bis zur IT-Strategieumsetzung ohne Insellösungen

Und wenn Sie diese Strategie dann letztendlich umsetzen wollen, dann geht’s da drum nochmal konkret zu überlegen: Wenn Sie diese ganzen Maßnahmen haben, wie Sie es jetzt schaffen in der Übergangszeit nicht noch weitere Insellösungen zu schaffen. #00:03:15.1#

Das ist das große Ziel und das ist auch das, worauf Ihre Frage abzielt, dass Sie im zweiten Schritt ohne große Schwierigkeiten die Strategie umsetzen können, da Ihre Schritte gehen können entlang der Umsetzungs-Roadmap, aber gleichzeitig eben auch einen Mechanismus entwickeln, der irgendwo eingreift, wenn es darum geht weitere Insellösungen aufzubauen.

Und da empfiehlt sich erstmal zu definieren: Was ist für Sie eigentlich eine Insellösung? Wann würden Sie sagen, wollen Sie diese Lösung nicht mehr so akzeptieren? Ich komme mal direkt zu dem Weg, wie ich das angehen würde.

Aus meiner Sicht ist es sehr wichtig, dass Sie zwei verschiedene Themen etablieren.

  1. Das erste Thema ist das Thema Anforderungsmanagement und
  2. das zweite Thema ist das Thema Architekturmanagement. #00:04:03.2#

Gehen wir mal zunächst mal auf das Anforderungsmanagement ein und dann im zweiten Schritt auf das Thema Architekturmanagement.

Punkt 1: proaktives Anforderungsmanagement

Wofür hilft das Anforderungsmanagement, wenn Sie jetzt die Strategie umsetzen wollen und keine weiteren Insellösungen aufbauen möchten?

Anforderungsmanagement-Prozess etablieren

Zunächst mal über das Anforderungsmanagement kommen alle Anforderungen an die IT. Das heißt, proaktiv können Sie da die Anforderungen, die aus dem Fachbereich kommen und die aus Ihrer eigenen IT-Organisation kommen, steuern und entsprechend managen, priorisieren und so weiter. Sie können dazu gerne auch mal die Folge 24 anhören, dort habe ich sehr detaillier auch den Anforderungsmanagement-Prozess beschrieben, wie er in seinen Phasen abläuft, sodass Sie schon mal ein Gefühl bekommen, wie man so einen Anforderungsmanagement-Prozess proaktiv aufsetzt und eben da mit seinen Fachbereichen ins Gespräch kommt.

Und übers Thema Anforderungsmanagement haben Sie eben die Möglichkeit wie schon gesagt alle Anforderungen aus den Fachbereichen, aber auch aus der IT und eben auch alle strategischen Anforderungen zu besprechen. #00:05:05.8#

Und es wird dann einen Schritt geben in dem Anforderungsmanagement-Prozess, der prüft, ob alle Belange der technischen Lösung auch konform sind mit Ihrer IT-Architekturstrategie, also mit den Komponenten, wie Sie eigentlich zukünftig Ihre IT-Architektur aufsetzen möchten und ob diese Lösung, die da angestrebt wird auch mit den Architekturprinzipien übereinstimmt.

Was ist jetzt ein Architekturprinzip? Das ist das, was Sie festlegen, wie die Architektur in ihren groben Eckdaten aufgebaut sein soll. Da gehe ich gleich nochmal drauf ein bei dem Thema Architekturmanagement, aber zunächst mal das Thema Anforderungsmanagement hilf Ihnen alles proaktiv zu steuern und eben alle Themen direkt zu bündeln und das Anforderungsmanagement hält sozusagen die Fäden zusammen. #00:06:00.0#

„Schiedsrichter“ Positionen schaffen

Sie bekommen die Anforderungen, Sie prüfen die auch auf Architekturkonformität, auf Strategiekonformität und wenn die Anforderung so bewertet wird in Ihrem Bewertungsschema, dass Sie sagen, die möchte ich auch durchlassen, das möchte ich umsetzen, das kann ich zusammen mit dem Fachbereich dann entscheiden, dann wird es ins Projektmanagement eingeplant und das Projekt findet statt und letztendlich nachher, wenn das Projekt abgeschlossen ist, ist das Anforderungsmanagement auch wieder dafür da, um zu schauen: Ist die Anforderung so umgesetzt worden wie das der Kunde eben bestellt hat? Das macht man natürlich nicht am besten erst am Ende, sondern schon im ganzen Projekt.

Da ist eben dann auch der entsprechende Architekt mit der technischen Architektur mit beschäftigt, aber eben auch der Anforderungsmanager, der genau diese Anforderungen dann auch mit begleitet und diese schauen eben im Projekt auch immer schon mal danach, ob alle Vorgaben, wie sie denn jetzt aus der Strategie kommen, auch entsprechend umgesetzt werden und können da natürlich frühzeitig einschreiten. #00:06:58.6#

Es ist so ein bisschen, können Sie sich vorstellen, wie so eine Schiedsrichterposition. Die schauen irgendwie, okay, sind beide Belange gleich gut berücksichtigt oder gibt’s irgendwo Möglichkeiten nochmal einzugreifen und vielleicht nochmal die eine oder andere Frage nochmal aufzuwerfen. Der Fachbereich kann natürlich ein Interesse da dran haben irgendwie ein eigenes System zu wollen.

Selbstbewusstes Anforderungsmanagement etabliert Leitlinien

Sie können aber aus der IT natürlich aus gutem Grunde auch sagen: Na ja, wir haben jetzt bereits ein System, das könnte deine Anforderungen abdecken. Wir fördern jetzt nicht weitere Insellösungen und kaufen jetzt wieder für diese eine kleine Funktionalität ein separates System, sondern aus der IT-Sicht heraus werden alle Funktionen, die der Fachbereich anfragt mit dieser Lösung auch abgedeckt und dann glaube ich muss man auch so selbstbewusst sein aus der IT heraus zu sagen:

„Lieber Fachbereich, das ist eine Lösung, die bildet deine Funktionalitäten ab, lass uns mal schauen, wo die das vielleicht noch nicht macht, dass wir da drüber uns nochmal Gedanken machen und da etwas für entwickeln, aber eben auch die Belange der IT mal klar zu äußern.“

#00:08:04.0# Ich glaube das ist in vielen Unternehmen, vielen IT-Organisationen eben sowas, was dann häufig nicht gemacht wird.

Da sagt man:

„Der Kunde hat das aber bestellt und die wollen das nicht so, der Fachbereich.“

Und dann ist man da als IT eher so klein und zurückhaltend und sagt:

„Nein, das machen wir nicht.“

Und ich glaube da muss man einfach mal auch mit einem gesunden Selbstbewusstsein auftreten als IT und sagen:

„Es ist aber unsere Verantwortung auch diese ganzen Systeme zu betreiben und eben auch zu schauen, dass entsprechend Daten konsistent sind und eben entsprechende Prozesse unterstützt werden und zwar nicht nur an Einzelstellen, sondern eben durchgängig.“

Und diese Durchgängigkeit, die können Sie mit dem Anforderungsmanagement-Prozess super hinbekommen.

Punkt 2: konsequentes und selbstbewusstes Architekturmanagement

Das zweite Thema, was man eben berücksichtigen sollte, ist schon angeklungen, ist das Thema Architekturmanagement.

Das ist jetzt kein Prozess so in dem Sinne, den Sie jetzt irgendwie akribisch durchgehen, sondern das ist auch eher ein Konzept, was Sie eben in den Alltag mit einbinden und eben Stellen schaffen, womit Sie dann in der Lage sind diese Architekturkonformität oder diese Architekturstrategie umzusetzen. #00:09:10.4#

Die Rollen im Architekturmanagement

Falls Sie das bisher im Unternehmen noch nicht so leben, also dass Sie noch keinen Architekten haben für bestimmte Fragestellungen, einen technischen Architekten und ein Unternehmensarchitekt.

Der Unternehmensarchitekt kümmert sich eher um die Prozesssicht, um die Gesamtprozesssicht und der technische Architekt, der kümmert sich in der Regel eher um Fragestellungen der technischen Architektur, also Schnittstellen, Programmiersprachen, bestimmte Konzepte, Datenbanken und so weiter. Bestimmte technische Rahmenparameter, die eben für bestimmte Systeme relevant sind und das hilft extrem so ein Architekturmanagement zu etablieren bevor Sie die strategischen Maßnahmen umsetzen.

Das heißt also, das Thema Anforderungsmanagement und Architekturmanagement sollten Sie aus meiner Sicht verankern bevor Sie anfangen diese gesamte Strategie-Roadmap umzusetzen. #00:10:01.5#

Und Architekturmanagement, habe ich gerade schon gesagt, heißt im Prinzip: Sie haben bestimmte Rollen geschaffen, die dann diese Aufgaben wahrnehmen. Also einen Unternehmensarchitekten, einen technischen Architekten. Wie Sie die einzelnen nennen, ist gar nicht so wichtig.

Aber dass die eben diese Rollen ausfüllen, dass der eine eher nach der gesamten Prozesssicht schaut und nach der gesamten Unternehmenssicht schaut und die Fachbereichsprozesse versteht. Und ein anderer oder eine Gruppe von Leuten, das muss nicht nur eine Person sein, wenn Sie ein großes Unternehmen haben, auch ruhig mehrere, weil der eine wird’s im Zweifel auch nicht schaffen, bei der Menge der Anfragen.

Designprinzipien als Leitlinien für die Architektur entwickeln

Der technische Architekt kann eben diese Designprinzipien auch mit entwickeln. Also Vorgaben wie eine IT-Architektur aussehen soll. Wenn Sie jetzt das Ziel haben, die soll modular sein, die soll flexibel sein und so weiter, dann brauchen Sie vielleicht Vorgaben für Schnittstellenformate, also offene Schnittstellenformate, die Sie einsetzen wollen. #00:10:59.4#

Sie brauchen vielleicht, wenn Sie Eigenentwicklungen machen oder Systemauswahl machen, auch bestimmte Sachen, die Sie abprüfen, also zum Beispiel sind bestimmte Programmiersprachen, die wir einsetzen möchten, möglich? Oder haben Sie auch das Know-how für diese Programmiersprachen vor Ort? Bestimmte Vorgaben zur Benutzeroberfläche, zum Beispiel gibt’s Firmen, die sagen:

„Na ja, ich möchte mit 3 Klicks die unterste Ebene im Menü erreichen können oder ähnliches.“

Sie können das für Ihr Unternehmen selber festlegen. Sie können auch sagen, ich muss bestimmte Datenaustauschformate haben. Wenn ich jetzt eine Datenbank einsetze, dann muss die eben bestimmte Sprachen unterstützen und so weiter. Das ist das, was der technische Architekt dann letztendlich macht und mit diesen Designprinzipien, mit diesen Vorgaben haben Sie dann Rahmenparameter, wonach Sie gucken können und eben halt diese Anforderungen, die dann über das Anforderungsmanagement reinkommen, immer wieder auf den Prüfstand stellen und sagen können:

„Moment, ich prüfe diese Anforderung. Passt die zu unseren Designprinzipien, die wir im Architekturmanagement festgelegt haben?“

#00:12:10.0# Und da können Sie immer wieder an diesem Checkpoint sozusagen, können Sie immer wieder sagen: Ja passt. Dann ist gut, dann kann die Anforderung auch ihren Weg gehen. Und ansonsten, das ist das, was ich mit selbstbewusst meine, muss auch der Architekt selbstbewusst sagen:

„Stopp! Diese Anforderung, die entspricht so wie sie momentan gestellt ist nicht unseren Architekturprinzipien.“

Und dann muss man eben schauen:

„Gibt es denn eine Lösung am Markt, die das tut? Gibt es eine Lösung, die man selber entwickeln kann, die das tut?“

Dann auch wieder natürlich Kosten-Nutzen-Fragen, alles klar. So wie man das eben machen würde.

Mit den Fachbereichen über funktionale Anforderungen diskutieren statt über Tools

Aber vor allen Dingen, wenn Anfragen kommen, schauen Sie danach, was sind die funktionalen Anforderungen, die der Fachbereich eigentlich abgedeckt haben will? Jeder kenn das, der in der IT gearbeitet. Da kommt der Fachbereich und sagt:

„Wir hätten gerne die und die Lösung. Kauf die mal, liebe IT, und führe uns die mal ein.“

#00:13:04.0# So. Da sollten Sie immer direkt stutzig werden. Wei der Fachbereich, der will nicht die und die Lösung kaufen, sondern der hat ein Problem, ein Prozessproblem, ein Produktproblem oder sonst irgendwas und hat eben eine Fragestellung, eine Anforderung für Funktionalitäten, was er vielleicht vereinfacht haben möchte, was er vielleicht digitalisiert haben möchte an Vorgängen, die heute noch manuell laufen, mit Medienbrüchen und und und. Wo er sagt:

„Ja das ist eigentlich meine funktionale Anforderung.“

Und diese funktionale Anforderung, die gilt es aus meiner Sicht auszufinden und die dann zu bewerten und eben dafür die passende Lösung zu finden. Das heißt, auch wenn der Kunde schon oder der Fachbereich schon sagt:

„Ich habe hier schon alles fertig, liebe IT, brauchst nur noch bestellen.“

Dann sollten alle Alarmglocken angehen, vor allen Dingen beim Anforderungsmanager und der sollte dann erstmal schauen:

„Okay, lieber Fachbereich, wir gehen jetzt erstmal ins Gespräch und sagen jetzt erstmal: Was möchtest du denn eigentlich fachlich wirklich haben? Wo drückt denn der Schuh?“

#00:14:05.6# Und dann findet man raus, ah dass es vielleicht doch gar nicht nur diese eine System gibt, was da in Frage kommt, sondern vielleicht gibt’s eben mögliche Lösungen, die schon im Haus sind oder es gibt eben andere Anbieter, die man sich auch noch anschauen kann und wo der Architekt eben, wenn es das noch nicht gibt, entsprechende Designprinzipien festlegen kann. Oder wenn er sie vorher schon erarbeitet hat, eben dann auch entsprechend umsetzen kann.

Verantwortungsvolle Entscheidungen mit Augenmaß für das Unternehmen

Und auch ist es glaube ich wichtig, dass immer so ein Gleichgewicht entsteht, dass der Architekt jetzt nicht irgendwie per se alles ablehnt, was vom Fachbereich kommt und der Fachbereich auch nicht per se immer sagt:

„Na ja es muss aber jetzt unbedingt diese eine Lösung sein, die dann die einzige Lösung für unser Problem ist.“

Weil da muss man eben schauen, dass man da ein bisschen vermittelt vielleicht an der einen oder anderen Stelle und eben auch das Gespräch sucht und auch mal erklärt, was denn so eine Insellösung in der IT verursacht. #00:15:01.2#

Also auch mal dem Fachbereich erklärt:

„Lieber Fachbereich, wenn du jetzt so eine Insellösung wieder machen willst, was kostet das denn jetzt in der IT?“

Dann kommt da natürlich vielleicht wieder:

„Ja es kostet ja eh dasselbe. Die Leute sind ja schon da.“

Aber da eben auch mal genau aufzuzeigen, was bedeutet das eigentlich? Was für eine Komplexität erhöht das eigentlich, wenn man immer wieder Insellösungen hat, statt wenn man ein durchgängiges Konzept hat, was vielleicht modular aufgebaut ist, wo sich aber die Schnittstellen so miteinander austauschen können, dass man eben doch eine Systemlandschaft hat, die miteinander agiert und die so aufeinander abgestimmt ist, dass die Prozesse durchgängig vom Anfang bis zum Ende eben auch digitalisiert werden können. Weil das ist auch im Moment zumindest in vielen Unternehmen sehr, sehr hoch im Kurs, dass man vermeidet Medienbrüche zu haben, nochmal manuelle Tätigkeiten dazwischen, vielleicht nochmal Daten manuell von einem System ins nächste System überträgt. #00:16:02.6# Das ist natürlich dann so ein Punkt, den man eben bei sowas vermeiden möchte. Gerade wenn man jetzt neue Systeme einführt oder eben neue Anfragen vom Fachbereich bekommt.

Checkpoints zur Prüfung im Projektverlauf einplanen

Und ich glaube, wenn Sie diese zwei Themen vorher angehen bevor Sie Ihre IT-Strategie letztendlich komplett durchgängig umsetzen wollen, dann haben Sie mit den zwei Themen eigentlich schon den, ja den großen Schritt, den großen Anfang gemacht und wenn Sie die erfolgreich umgesetzt haben, dann haben Sie immer wieder Checkpoints, wo Sie interagieren mit dem Fachbereich, der mit neuen Anforderungen kommt und Sie haben vor allen Dingen ein Instrument, womit Sie auch Ihre strategischen Maßnahmen durchplanen können und eben die auch nochmal entsprechend eintakten können im Anforderungsmanagement und auch nochmal auf den Prüfstand stellen, was die Architektur betrifft, ob das denn alles wirklich so in Ihre Landschaft passt.

Und dann sollten Sie auch Ihre IT-Strategie über den Zeithorizont, den Sie sich gegeben haben, erfolgreich einsetzen können und umsetzen können und dann auch Ihre Zielsetzung mit der IT ein ganzes Stück näherkommen. #00:17:09.9#

Ich hoffe, ich habe Ihre Hörerfrage gut beantwortet, würde mich kurz über ein Feedback freuen. Natürlich auch alle anderen Hörer ermutigen mir ihre Fragen zu schicken, wenn Sie da Fragen haben. Die beantworte ich entweder direkt persönlich oder eben auch in Form eines kleinen Podcast, wenn es jetzt was ist, was dann doch sehr viele Hörer betrifft. Und ja, das war’s auch schon wieder für diese Folge. #00:17:51.9#

Bildnachweis: © CC0 Public Domain/ pixabay.com

Ihr Feedback

Wenn Ihnen der Podcast gefällt, bewerten Sie ihn bitte auf iTunes!
Eine Anleitung finden Sie hier. Sie helfen damit den Podcast bekannter zu machen. 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):



* = Pflichtfeld

Weitere Podcast Folgen finden Sie hier.

Veröffentlicht in CIO Podcast Getagged mit: , , , ,