Organisation und Führung der IT: Die neue Rolle der IT und des CIOs in der digitalen Transformation [1. Aufl.] 9783658120078, 9783658120085

Citation preview

Volker Johanning

Organisation und Führung der IT Die neue Rolle der IT und des CIOs in der digitalen Transformation

Organisation und Führung der IT

Volker Johanning

Organisation und Führung der IT Die neue Rolle der IT und des CIOs in der digitalen Transformation

Volker Johanning Marl am Dümmersee, Deutschland

ISBN 978-3-658-12007-8    ISBN 978-3-658-12008-5  (eBook) https://doi.org/10.1007/978-3-658-12008-5 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Springer Vieweg © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von allgemein beschreibenden Bezeichnungen, Marken, Unternehmensnamen etc. in diesem Werk bedeutet nicht, dass diese frei durch jedermann benutzt werden dürfen. Die Berechtigung zur Benutzung unterliegt, auch ohne gesonderten Hinweis hierzu, den Regeln des Markenrechts. Die Rechte des jeweiligen Zeicheninhabers sind zu beachten. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag, noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral. Springer Vieweg ist ein Imprint der eingetragenen Gesellschaft Springer Fachmedien Wiesbaden GmbH und ist ein Teil von Springer Nature. Die Anschrift der Gesellschaft ist: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany

Vorwort

Was ist der Zweck von IT-Organisationen in einem Unternehmen? Wie müssen IT-Organisationen aufgebaut sein, damit sie effizient und effektiv ihren Zweck erfüllen können? Welche Rolle muss die IT und deren Chef als CIO im Unternehmen einnehmen, damit sie erfolgreich arbeiten kann? Welche wirklich zielführenden Führungsmaximen gibt es im digitalen Zeitalter mit hoher Dynamik? Welche Rollen und Personalprofile braucht eine IT-Organisation, um im digitalen Wettbewerb von morgen Stand zu halten? Das sind die zentralen Fragestellungen, die in diesem Buch beantwortet werden. Allerdings: Damit die IT ihre Bestimmung im Unternehmen erfüllt, reicht nicht nur der Aufbau einer neuen IT-Organisation. Die neuen Konstrukte müssen durch neue Führungsansätze und -instrumente der IT konsequent umgesetzt werden. Daher verfolgt dieses Buch den Ansatz, die Rolle der IT im Unternehmen neu zu schreiben, dazu passende Organisationsmodelle und Governancestrukturen aufzubauen und diese durch Führung im Unternehmen so zu leben, dass die IT die reine Dienstleisterrolle gegen die des aktiven Gestalters eintauscht. Diese neue Rolle ist für Unternehmen ein strategischer Wettbewerbsfaktor, denn mittlerweile bauen in vielen, wenn nicht den meisten Unternehmen, die Geschäftsmodelle auf IT auf. Damit wird die IT immer mehr zum Herz des Unternehmens. Der CIO ist aufgerufen, die Rolle des Gestalters einzunehmen und auch künftig Verantwortung auf erster Ebene des Vorstands und der Geschäftsführung zu übernehmen. Solche Organisationsanpassungen oder Reorganisationen sind allerdings wahre ChangeHerausforderungen. In keinem anderen Projekt geht es so direkt und offensichtlich um neue Rollen, Aufgaben und Posten wie bei einer Reorganisation. Daher ist ein solches Projekt für die Verantwortlichen eine echte Herkulesaufgabe. Wenn dann noch Aufgaben in der neu entstehenden IT-Organisation an externe Dienstleister ausgelagert werden, ist das Projekthöchstmaß erreicht. Anspruchsvoller geht es kaum. Es macht aber gleichzeitig auch Spaß zu sehen, wie etwas Neues wächst, wie sich auf einmal alte P ­ robleme in Luft V

VI

Vorwort

auflösen, wie die IT an Ansehen gewinnt und eine neue Rolle als Gestalter übernimmt. Daher lohnt sich dieser Weg immer und auf jeden Fall! Einschränkend sei an dieser Stelle jedoch darauf hingewiesen, dass ständige Reorganisationen lähmen und nicht mehr ernst genommen werden. Daher sollte die so genannte „Organisitis“ vermieden werden. Nur eine einmalige und gut durchgeführte Organisationsänderung mit anschließender Zeit zum Durchatmen nach dem großen Change kann nach dem großen Umbau erfolgreich sein. Die neue Organisation muss ankommen dürfen, sich setzen können und kann nur über die Zeit stabile Verhältnisse im Unternehmen schaffen. Menschen in Organisationen können Veränderungen und Wandel durchaus verkraften, sie brauchen jedoch auch Phasen von Ruhe und Stabilität, um produktive Leistungen zu gewährleisten. Darüber hinaus sei gesagt, dass es keine perfekte Organisation gibt. Alle Organisationen erfordern Kompromisse und haben ihre Vor- und Nachteile. Die reine Theorie der Organisationslehre findet in der Praxis keinen Widerhall und es wird immer nahezu unmöglich sein, die optimale Organisation zu kreieren und umzusetzen. Mit Malik [1] und Drucker [2] gesprochen gibt es aber 4 konkrete Anforderungen an Organisationen, die auch für IT-Organisationen im Besonderen gelten: 1. Klarer Fokus auf den Kunden, sprich: die Unternehmensziele und die Fachbereichsengpässe, die von der IT gelöst werden müssen. 2. Schaffen einer Organisation, die dafür sorgt, dass die Mitarbeiter – sowohl in der IT als auch im Fachbereich – tatsächlich ihre Aufgaben erfüllen können. 3. Führung von Wissensarbeitern kann nur auf Augenhöhe geschehen. Sie ist Befähigung und auf keinen Fall Belehrung oder Korrektur nach althergebrachter Command &  Control-­Art aus Taylor-Zeitalter. 4. Sinn und Purpose sind entscheidend: Die IT-Organisationen braucht eine klare Vision und ein Zielbild. Die Frage nach dem „Warum“ muss nicht nur top-down, sondern von der gesamten Organisation beantwortet werden und diese tragen können. Das vor Ihnen liegende Buch gibt Ihnen eine sehr praxisorientierte Anleitung für die Organisationsänderung oder Reorganisation der IT mit vielen Tipps zum Thema Changemanagement, Führung sowie agilen Methoden und Ansätzen in der neuen IT-Organisation. Die Maxime lautet: Führen Sie die Veränderung der Organisation sehr gewissenhaft, mit viel Geduld, sehr guter Planung und Feinfühligkeit durch und beachten Sie die 4 oben genannten Anforderungen. Nur dann wird sie erfolgreich sein und erst wieder in einigen Jahren auf der Agenda stehen, anstatt zu ständigen Reorganisationen zu führen. Es grüßt Sie herzlich Marl am Dümmersee, Deutschland Winter 2020

Volker Johanning

Vorwort

VII

Literatur [1] Malik, Fredmund: Führen Leisten Leben, 6. Auflage, Campus Verlag, 2006. [2] Drucker, Peter F.: „Management’s New Paradigm“, http://www.mit.edu/~mbarker/ ideas/drucker.html, MIT, abgerufen am 30.12.2019.

Inhaltsverzeichnis

Teil I  Einführung: Die IT-Organisation im Wandel der Zeit 1 Organisationen im Allgemeinen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3 1.1 Eine Begriffsdefinition����������������������������������������������������������������������������������   3 1.2 Organisationen heute������������������������������������������������������������������������������������   4 Literatur������������������������������������������������������������������������������������������������������������������   6 2 IT-Organisationen im Speziellen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   7 2.1 Von den Anfängen der IT bis 2010 ��������������������������������������������������������������   7 2.2 Wo steht die IT heute?����������������������������������������������������������������������������������  12 Literatur������������������������������������������������������������������������������������������������������������������  13 Teil II  Der Aufbau von IT-Organisationen 3 Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  17 3.1 Die 4 Möglichkeiten der Einbindung von IT in die Unternehmensorganisation���������������������������������������������������������������������������  17 3.1.1 Vor- und Nachteile����������������������������������������������������������������������������  18 3.2 Übersicht von Aufbauorganisationen der IT ������������������������������������������������  19 3.2.1 Das Modell der klassischen IT-Organisation������������������������������������  21 3.2.2 Das Modell „Plan-Build-Run“����������������������������������������������������������  22 3.2.3 Das Modell „Source-Make-Deliver“������������������������������������������������  24 3.2.4 Das Modell „Innovate-Design-Transform“��������������������������������������  25 3.2.5 Shared-Service-Modelle ������������������������������������������������������������������  27 3.2.6 Das Demand-Supply-Modell������������������������������������������������������������  28 3.3 Besonderheiten in der Aufbauorganisation der IT����������������������������������������  31 3.3.1 DevOps ��������������������������������������������������������������������������������������������  31 3.3.2 BizOps bzw. BizDevOps������������������������������������������������������������������  32 3.3.3 Eine bimodale IT-Organisation ��������������������������������������������������������  34 3.3.4 Die IT Organisation im internationalen Kontext������������������������������  35 3.3.5 Linienzentrierte versus projektzentrierte IT-Organisation����������������  37 IX

X

Inhaltsverzeichnis

3.4 Agile Methoden in der IT-Organisationsgestaltung��������������������������������������  39 3.4.1 SCRUM��������������������������������������������������������������������������������������������  39 3.4.2 IT-KANBAN������������������������������������������������������������������������������������  43 3.4.3 Selbstorganisation und Holokratie in der IT������������������������������������  45 3.4.4 Digital Labs��������������������������������������������������������������������������������������  47 3.4.5 Tipp aus der Praxis: Wann und wo machen agile Ansätze Sinn?������  54 3.5 Die Prozessorganisation als Schnittstelle zu den Fachbereichen������������������  54 3.5.1 Die Frage nach der Verantwortlichkeit einer Prozessorganisation��������������������������������������������������������������������������  56 3.5.2 Die 3 Ebenen des Anforderungsmanagements ��������������������������������  56 3.5.3 Wichtige Rollen in der Prozessorganisation ������������������������������������  57 3.5.4 Aufbau einer Prozessorganisation����������������������������������������������������  59 3.6 Resümee und Plädoyer für eine moderne IT-Organisation ��������������������������  64 Literatur������������������������������������������������������������������������������������������������������������������  65 4 Die Ablauforganisation der IT – Welche IT-­Prozesse und Strukturen braucht eine moderne und schlanke IT-Organisation der Zukunft?. . . . . . . .  67 4.1 IT-Governance als Rahmenwerk für die Ablauforganisation der IT������������  67 4.2 Überblick zu den gängigen Rahmenwerken für die IT-­Ablauforganisation ����������������������������������������������������������������������������������  68 4.2.1 COBIT als ein mögliches Referenzmodell für die IT-­Ablauforganisation ����������������������������������������������������������������������  68 4.2.2 ITIL als Rahmenwerk zur Umsetzung von IT-Service Management Standards��������������������������������������������������������������������  71 4.2.3 Ein Wegweiser durch den Begriffsdschungel von ITIL, COBIT & Co: Was ist für den CIO wirklich wichtig?����������������������  73 4.3 Ihr eigenes IT-Rahmenwerk��������������������������������������������������������������������������  74 4.3.1 IT-Strategie und IT-Governance��������������������������������������������������������  76 4.3.2 Demand-Management����������������������������������������������������������������������  86 4.3.3 Projektmanagement��������������������������������������������������������������������������  89 4.3.4 IT-Architektur ���������������������������������������������������������������������������������� 105 4.3.5 IT-Entwicklung und -Bereitstellung�������������������������������������������������� 106 4.3.6 IT-Service-Management�������������������������������������������������������������������� 107 4.3.7 IT-Operations������������������������������������������������������������������������������������ 108 4.4 IT-Personal und Rollen: Die für die IT-Prozesse richtigen Rollen definieren������������������������������������������������������������������������������������������������������ 108 4.4.1 Die erste Berichtsebene des CIOs���������������������������������������������������� 108 4.4.2 IT-Strategie und IT-Governance�������������������������������������������������������� 109 4.4.3 Demand-Management���������������������������������������������������������������������� 110 4.4.4 Projektmanagement�������������������������������������������������������������������������� 113 4.4.5 IT-Architektur, Innovation und Digitalisierung�������������������������������� 114 4.4.6 IT-Entwicklung/-Bereitstellung�������������������������������������������������������� 117 4.4.7 IT-Service-Management�������������������������������������������������������������������� 118

Inhaltsverzeichnis

XI

4.4.8 IT-Operations������������������������������������������������������������������������������������ 120 4.4.9 Schnittstellen und Entscheidungsrechte der IT-Rollen �������������������� 121 Literatur������������������������������������������������������������������������������������������������������������������ 121 Teil III  Die Rolle der IT und des CIOs im Unternehmen 5 Die Rolle der IT im Unternehmen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 5.1 Treiber und Einflussfaktoren der IT-Organisation���������������������������������������� 125 5.1.1 Digitalisierung und neue digitale Geschäftsmodelle������������������������ 126 5.1.2 Agilität, Dynamik und kollaboratives Arbeiten�������������������������������� 127 5.1.3 Consumerization der IT und IT-Security������������������������������������������ 128 5.1.4 Künstliche Intelligenz, IoT und Cloud Computing�������������������������� 128 5.1.5 Talente und Experten finden und halten�������������������������������������������� 129 5.2 Standortbestimmung: Wo steht die IT heute? ���������������������������������������������� 129 5.3 Erwartungen an die IT-Organisation klären�������������������������������������������������� 130 5.4 Die neue Rolle der IT: Alte Denkmuster müssen überwunden werden�������� 135 5.4.1 Vom Verwalter der Technik zum Gestalter des digitalen Wandels�������������������������������������������������������������������������������������������� 137 5.4.2 Die 4 Stufen der IT zum Innovationstreiber ������������������������������������ 138 5.4.3 Konfliktpotenzial 1: „Hoheitliche Aufgaben“ versus Dienstleistungsaufgabe �������������������������������������������������������������������� 138 5.4.4 Konfliktpotenzial 2: Selbstbild versus Fremdbild���������������������������� 139 5.5 Die neue Rolle der IT treibt das Unternehmen – So kann IT echten Business-Mehrwert schaffen������������������������������������������������������������������������ 139 Literatur������������������������������������������������������������������������������������������������������������������ 141 6 Quo vadis CIO? – Die Rolle des CIOs in Zeiten der digitalen Transformation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 6.1 CIO-Rollenmodelle�������������������������������������������������������������������������������������� 144 6.2 Aufgaben eines CIOs: Arbeit an der IT und nicht in der IT ������������������������ 145 6.3 Notwendige Fähigkeiten und Kompetenzen des CIOs �������������������������������� 149 6.3.1 Agile Leadership: moderne Führung anstatt Command &  Control���������������������������������������������������������������������������������������������� 149 6.3.2 Der CIO als Change Leader: Nicht nur die Technik zum Laufen bringen, sondern die Menschen und die Prozesse���������������� 149 6.3.3 Unternehmerisches Denken: Den Business-Impact und den Nutzen von IT deutlich machen�������������������������������������������������������� 150 6.3.4 Kommunikation & Marketing: IT verständlich machen�������������������� 150 6.3.5 Komplexität vereinfachen: Technologien verstehen und richtig für das Unternehmen einsetzen�������������������������������������������������������� 150 6.3.6 Der 7-Punkte-Plan zum Erfolg als CIO�������������������������������������������� 151 6.4 CIO versus CDO: Der CIO im digitalen Zeitalter���������������������������������������� 151 Literatur������������������������������������������������������������������������������������������������������������������ 153

XII

Inhaltsverzeichnis

Teil IV  Führung von IT-Organisationen 7 Führungsgrundsätze für CIOs und IT-Leiter . . . . . . . . . . . . . . . . . . . . . . . . . . 157 7.1 Ergebnisorientierung und Business-Impact als CIO������������������������������������ 157 7.2 Das Führen von IT-Spezialisten�������������������������������������������������������������������� 159 7.3 Konzentration auf das Wesentliche �������������������������������������������������������������� 161 7.4 Mitarbeiterförderung: Stärken stärken!�������������������������������������������������������� 162 Literatur������������������������������������������������������������������������������������������������������������������ 163 8 Sinn und Purpose als Führungs- und Steuerungsinstrument. . . . . . . . . . . . . . 165 8.1 Ein Zielbild für die IT entwickeln���������������������������������������������������������������� 165 8.2 Wie wird das IT-Zielbild erreicht? – Das Erstellen der IT-Roadmap ���������� 167 9 Agilität und Dynamik braucht eine neue Form von Führung . . . . . . . . . . . . . 171 9.1 Leadership Agility: Wirksame Führung in einer agilen und dynamischen Welt ���������������������������������������������������������������������������������������� 171 9.1.1 Der Ausgangspunkt von Leadership Agility ������������������������������������ 171 9.1.2 Wie wird man zum Innovationstreiber?�������������������������������������������� 173 9.1.3 Leadership Agility: Von konventioneller Führung zu agiler Führung �������������������������������������������������������������������������������������������� 174 9.1.4 Wie kann agile Führung in der IT-Organisation umgesetzt werden? �������������������������������������������������������������������������������������������� 178 9.2 Besonderheiten der Führung im digitalen Zeitalter�������������������������������������� 180 Literatur������������������������������������������������������������������������������������������������������������������ 181 10 Führung der IT über Ziele? – OKRs statt Management by Objectives (MbO). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 10.1 Definition und Ziele von OKRs������������������������������������������������������������������ 183 10.2 Vorgehensweise bei der Erstellung von OKRs für die IT �������������������������� 185 11 Führung und Teambildung: Die 5 Phasen nach Tuckmann. . . . . . . . . . . . . . . 189 12 Wichtige Kulturaspekte einer IT-Organisation. . . . . . . . . . . . . . . . . . . . . . . . . 195 12.1 Kultur und IT���������������������������������������������������������������������������������������������� 195 12.2 Vertrauen ist die Basis für eine gesunde Unternehmenskultur in der IT���������������������������������������������������������������������������������������������������������� 197 12.3 Die systemische Sichtweise auf IT-Organisationen: Innovation durch IT und Umgang mit Unsicherheit ���������������������������������������������������� 198 12.4 Die digitale Kultur als Fundament für eine moderne IT-­Organisation���������� 199 Literatur������������������������������������������������������������������������������������������������������������������ 201 13 Resümee. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Literatur������������������������������������������������������������������������������������������������������������������������ 205 Stichwortverzeichnis��������������������������������������������������������������������������������������������������� 207

Teil I Einführung: Die IT-Organisation im Wandel der Zeit

1

Organisationen im Allgemeinen

Zusammenfassung

In diesem Einführungskapitel geht es zunächst um die generelle Definition des Begriffes „Organisation“ im Unternehmen. Anschließend wird die historische und die organisatorische Entwicklung der IT betrachtet – von den zaghaften Anfängen als Organisationsabteilung mit riesigen Rechenmaschinen bis hin zur IT im heutigen digitalen Zeitalter. Diese historische Einordnung der IT ist wichtig, um die heute oft noch vorherrschenden Meinungen und (Vor-)Urteile gegenüber einer IT-Organisation zu verstehen. Denn dieses Verständnis ist die Basis für die Transformation der IT vom Maschinenraum zum Gestalter und Innovator.

1.1

Eine Begriffsdefinition

Woher kommt der Begriff der „Organisation“ und wann wurde es zum ersten Mal gebräuchlich, ihn für die Strukturierung und das Management von Unternehmensabläufen zu verwenden? Breits zu Beginn der Industrialisierung in den Anfängen des 19. Jahrhunderts wurde die Arbeitsteilung in der Fertigung so komplex, dass sie geregelt, sprich organisiert werden musste. In diesem Zusammenhang bedeutet „Organisieren … das Schaffen von Strukturen“ [1]. Wichtig ist hierbei die Erkenntnis, dass Strukturen in Unternehmen nicht allein nur zur Bändigung der Komplexität geschaffen werden, sondern vor allem, um die Strategie des Unternehmens zu unterstützen. „Structure follows Strategy“ ist die dafür bekannte Grundregel, nach der die Organisation so zu gestalten ist, dass die die Unternehmensstrategie bestmöglich unterstützt wird.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 V. Johanning, Organisation und Führung der IT, https://doi.org/10.1007/978-3-658-12008-5_1

3

4

1  Organisationen im Allgemeinen

Effektivität

Effizienz

Die richtigen Dinge tun!

Die Dinge richtig tun!

Was tun wir?

Wie tun wir es?

Grad der Zielerreichung (Wirksamkeit)

Maß für die Wirtschaftlichkeit (Kosten-/Nutzen-Relation)

Abb. 1.1  Effektivität versus Effizienz

Da die Organisation der Strategie folgt und in vielen Unternehmen heutzutage die strategischen Leitlinien einem ständigen Marktdruck unterliegen, hat dies Auswirkungen auf die Organisation. Denn diese ist nicht beständig, sondern einem steten Wandel unterworfen. Daher sind viele organisatorischen Strukturen in Unternehmen oftmals „historisch gewachsen“ und gar nicht so sehr einem bewussten Gestaltungsprozess unterworfen (siehe dazu [1]). Im Rahmen der weitergehenden Definition des Begriffs „Organisation“ ist eine Differenzierung zwischen Aufbau- und Ablauforganisation von großer Bedeutung. Die Aufbauorganisation regelt die Abgrenzung von Aufgaben, Kompetenzen und Unterstellungsverhältnissen, die in der Praxis in einem Organigramm münden. Typische Fragestellungen in Bezug auf die Aufbauorganisation sind: „Was ist zu tun?“ und „Wer macht was?“. Wenn es allerdings zu der Frage nach dem „Was ist wann in welcher Reihenfolge zu tun?“ kommt, bezieht sich dies auf die Ablauforganisation. Diese regelt die internen Abläufe innerhalb eines Unternehmens, die sogenannten Geschäftsprozesse und wird heute oft einfach Prozessmanagement genannt. In diesem Rahmen spielen auch die beiden Begriffe Effektivität und Effizienz eine Rolle. Wie in Abb. 1.1 zu sehen, steht Effizienz für die „Die Dinge richtig tun“ und Effektivität für „Die richtigen Dinge tun“. Beides wird benötigt, um komplexe Unternehmenskonstrukte, wie z. B. die IT-Organisation, zu organisieren und führbar zu machen.

1.2

Organisationen heute

Viele Unternehmen sind heute einem sehr starken Marktdruck ausgesetzt. Lieferungen erfolgen aufgrund modernster IT im Minutentakt, Informationen fließen ständig und sind von jedem Ort und zu jeder Zeit von jedem abrufbar und verfügbar. Wie verändert dies

1.2  Organisationen heute

5

nicht nur unser Leben allgemein, sondern auch die Art zu arbeiten und damit die Art wie Organisationen im Unternehmen gestaltet werden? Der Autor Nils Pfläging hat dieses Phänomen in seinem Buch Organisation für Komplexität näher untersucht. Er sieht einen grundsätzlichen Unterschied in der Art und Weise der Arbeit wie sie heute aussieht gegenüber dem Zeitpunkt, in dem Organisationen erschaffen wurden: dem Industriezeitalter. Mit der sogenannten „Taylor-Wanne“ beschreibt Pfläging 3 Zeitalter (siehe dazu Abb. 1.2): • Das Manufakturzeitalter mit hoher Dynamik aufbauend auf lokalen Märkten und hoher Kustomisierung (bis ca. 1850/1900) • Das Industriezeitalter mit geringer Dynamik, fast schon Trägheit, aufbauend auf weiten Märkten mit wenig Wettbewerb (von 1850/1900 bis ca. 1970) • Das heutige Wissenszeitalter, welches durch sehr hohe Dynamik auf globalen Märkten gekennzeichnet ist Spannend ist bei Pfläging der Übergang zwischen Industriezeitalter und Wissenszeitalter. Geprägt durch starke Umwälzungen, wie dem Internet, der Globalisierung und völlig neuer Kommunikationsmöglichkeiten ist zwischen 1990 und heute so viel passiert, dass die Unternehmen aus dem Industriezeitalter gar nicht recht wussten und teilweise bis heute nicht wissen, wie darauf zu reagieren ist. Es entstanden und entstehen plötzlich völlig neue Wettbewerber quasi aus dem Nichts, die auch großen Unternehmen und Konzernen – den Dinosauriern aus dem Industriezeitalter – gefährlich werden können. Erinnert

Abb. 1.2  Die Taylor-Wanne

6

1  Organisationen im Allgemeinen

sei nur an die völlig neuen Konkurrenten im Handel (Stichwort „Zalando“) oder den völlig neuen Konkurrenten auf dem Automarkt (Google hat bereits das autonome Fahren unter Beweis gestellt). Was sind die Mittel der Wahl für die Unternehmen, die noch althergebrachte Organisations- und Managementregeln aus den Zeiten der Arbeitsteilung des Taylorismus verfolgen? Eine Reorganisation jagt die nächste. Hinzu kommen Kostensenkungsprogramme. Im Industriezeitalter war es üblich, dass nach einer Reorganisation zunächst eine Pause eingelegt wurde. Die neue Organisation sollte sich „setzen“ und jedes Organisationsmitglied hatte Zeit, seine neue Rolle zu finden, diese auszugestalten und so die Schnittstellen im Unternehmen langsam wachsen und funktionieren zu sehen. Heute allerdings muss es sofort klappen und wenn nicht, dann folgt mitunter gleich die nächste Reorganisation. Es wird erwartet, dass Ergebnisse sofort sichtbar sind, sonst drohen die Shareholder mit dem Verkauf der Aktien und das wiederum kann den plötzlichen Arbeitsplatzverlust von Managern bedeuten. Der Druck auf das althergebrachte, tayloristische Organisationsdenken ist riesig geworden und führt zu einem steten Wandel in Form von Reorganisationen. Dies scheint der einzige Ausweg zu sein. Aber wie müssen sich Unternehmen im Wissenszeitalter organisieren und welche Rolle spielt die IT dabei?

Literatur 1. Capgemini: „IT-Trends 2019“, https://www.capgemini.com/de-de/wp-content/uploads/sites/ 5/2019/02/IT-Trends-Studie-2019.pdf, abgerufen am 28.12.2019.

2

IT-Organisationen im Speziellen

Zusammenfassung

Insbesondere die IT als der Treiber des Wissenszeitalters in Unternehmen spielt eine geradezu prädestinierte Rolle bei der Ausgestaltung einer Organisation in Zeiten hoher Dynamik mit globalen Märkten. In diesem Kapitel wird daher näher untersucht, woher die IT kommt, welche Rolle die IT heute spielt und was ihre zukünftige Rolle sein kann.

2.1

Von den Anfängen der IT bis 2010

In den Anfängen war die IT – meistens als „EDV“ bezeichnet – auch für das Thema Organisation verantwortlich. Das spiegelte sich in Organisationsbezeichnungen wie „EDV/ ORG“ oder „Organisation und EDV“ wider. Es gab sogar die Rolle und Stelle des „Organisators“. Doch um zu verstehen wie es dazu kam, muss man die Anfänge der IT genauer betrachten. Brenner und Witte haben dazu in ihrem Buch Erfolgsrezepte für CIOs die historische Entwicklung der IT in Unternehmen abgebildet (siehe Abb.  2.1). Diese Darstellung ist sehr wichtig für das Verständnis der heutigen Rolle der IT und des CIOs in Unternehmen. Denn laut Brenner und Witte hat es sich aufgrund der historischen Entwicklung der IT bei den Verantwortlichen in den Fachbereichen und der Unternehmensleitung so tief eingebrannt, dass der CIO und die IT „Maschinisten“ anstatt „Gestalter“ sind [1]. Sehr verkürzt, aber im Kern auf die Frage nach der Entwicklung der IT schauend, ­werden im Folgenden die in Abb. 2.1 dargestellten Zeiträume der IT zusammengefasst (in Anlehnung an [1]): Die 1950er-Jahre waren der Startpunkt für die IT. Ausgangspunkt waren hochkomplexe Berechnungen im militärischen Bereich, die nur mithilfe von Computertechnik durchgeführt werden konnten. Mehr und mehr wurde IT Mitte der 1950er-Jahre auch im © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 V. Johanning, Organisation und Führung der IT, https://doi.org/10.1007/978-3-658-12008-5_2

7

8

2  IT-Organisationen im Speziellen

hoch

KI, QuantenComputing

Grad der Effizienz

Digitale Transformation

Vernetzung, Internet Standard-SW, Prozessmgmt. Erste PCs, Client/Server

niedrig

Große Projekte Erste Anwendungen Rechenmaschinen

1960

1970

1980

1990

2000

2010

2020

Abb. 2.1  Die historische Entwicklung der IT

zivilen Bereich eingesetzt. Reine Techniker (oftmals Physiker oder Elektrotechniker, denn Informatiker gab es damals noch gar nicht) sorgten dafür, dass die riesigen Maschinen in den Unternehmen schwierige Berechnungen durchführen konnten. Anwendungen oder gar Apps, wie wir sie heute kennen, gab es noch nicht. Es wurde Hardware geliefert und es mussten auf Systemebene Programme selbst geschrieben werden, die dann bestimmte Funktionen ausführten. In den 1960er-Jahren entwickelte sich die IT weiter in Richtung Massendatenverarbeitung. Die Wirtschaft florierte nach dem 2. Weltkrieg und gerade Versandhändler, Banken und Versicherungen profitierten von IT durch die möglich gewordene Verarbeitung großer Datenmengen. Dabei muss man sich vor Augen führen, dass diese Art der ­Datenverarbeitung nicht für jeden einzelnen Anwender möglich war. Denn es gab keine Personal Computer oder Terminals für jeden Mitarbeiter, sondern das Ergebnis der Datenverarbeitung wurde in Form von Lochkarten auf Papier präsentiert. Man muss sich das so vorstellen, dass nur ausgewählte Techniker den Zugang zu den entstehenden Rechenzen­ tren hatten. Diese brachten ihre selbst erstellten Programme dorthin und hatten – teilweise erst Tage später – ihre Ergebnisse in Form von Lochkarten zurück. Das erste große Einsatzgebiet der damaligen EDV war die Automatisierung der Abläufe in der Buchhaltung. Daher war der EDV-Leiter auch dem Finanzchef unterstellt. Und das ist auch der Grund warum noch heute – 50 Jahre später – viele CIOs dem CFO unterstellt sind! Allerdings

2.1  Von den Anfängen der IT bis 2010

9

hatte der EDV-Leiter damals einen sehr angesehenen Beruf. Er wurde hochgeachtet dafür, dass er diese riesigen Maschinen in den völlig neuartigen und Respekt einflößenden Rechenzentren in den Griff bekam. Die 1970er-Jahre waren geprägt vom Wandel zur Anwendung. Nicht mehr nur die Hardware stand im Vordergrund, sondern es wurden vermehrt Anwendungen erstellt. Von der Verarbeitung der Daten im Batchbetrieb wurde auf Echtzeitsysteme umgestellt. Das bedeutete, dass man nicht mehr eine Nacht oder ganze Tage auf die Ergebnisse der Computer warten musste, sondern direkt und in Echtzeit Ergebnisse auf Monitore bekam und nicht mehr nur auf Lochkarten. Das war auch die Zeit, in der zum ersten Mal IT-Projekte das Licht der Welt erblickten. Die Anforderungen der Fachbereiche wuchsen, da man ­erkannte, dass viel Potenzial in der EDV steckte. Projektmanagement war das Mittel der Wahl, aber – wie auch heute noch leidvoll bekannt – konnten oft die Termine nicht gehalten werden, die Budgets liefen aus dem Ruder und am Ende war man froh, wenn wenigstens die Hälfte der Anforderungen umgesetzt werden konnte. Anders als heute war allerdings das Vertrauen in diese neue Technik so groß, dass man Fehler verzieh und sie als unvermeidlichen Lernprozess ansah. Der Stellenwert der EDV und des EDV-Leiters stieg zunehmend und er machte vielfach Karriere im Unternehmen. Die Abhängigkeit von der EDV wurde immer größer. Trotzdem wurden die EDV-Leute als Experten angesehen, die einer Art Geheimwissenschaft mit abstrakten Konzepten und Geräten nachgingen. Die typischen Anglizismen und Abkürzungen aus der EDV-Welt waren den herkömmlichen Führungskräften und Mitarbeitern aus den Fachbereichen sehr fremd. Es verfestigte sich das Bild des gut bezahlten, aber doch geschäftsfremden Informatikers. In den 1980er-Jahren nahm der Personal Computer (PC) Einzug in die Unternehmen. Allein die Tatsache, dass mithilfe einer Textverarbeitungssoftware die elektrische Schreibmaschine abgelöst wurde, war schon ein wenig revolutionär. Die neuen PCs waren allerdings für die EDV-Leiter zunächst eine enorme Bürde, ja wurden teilweise sogar als Gefahr angesehen. Denn bisher konnte die EDV mit ihrem Rechenzentrum bestimmen, welche Anwendung für wen läuft. Jetzt auf einmal konnten die Fachbereiche sich selbst Anwendungen kaufen und es kam zu einem „Wildwuchs“ der nicht mehr kontrollierbar schien. Viele Anwendungen wurden mehrfach gekauft, die Datenhoheit der EDV ging verloren und jeder speicherte lokal Daten auf seinem PC, die nicht mehr für andere verfügbar waren. Dementsprechend waren sie oft doppelt oder mehrfach im Unternehmen vorhanden und mitunter auch noch in verschiedenen Versionen. Die Pflege und Weiterentwicklung von Anwendungen, die auf einmal von den Fachbereichen selbst entwickelt werden konnten, wurde unmöglich und führte zu einer strikten Ablehnung von PCs durch die EDV-Leiter. Deren Hoheit über die EDV war in Gefahr, aber PCs wurden immer günstiger und bedienfreundlicher, sodass die EDV sich nicht gegen die massenweise Verbreitung von PCs auf jedem Arbeitsplatz wehren konnte. Hinzu kam, dass sich neue Player im IT-Markt etablierten, die verstanden hatten, dass durch die Trennung von PC und Server eine neue Form der Datenhaltung für mehrere Anwendungen gleichzeitig möglich und nötig wurde. Allen voran sei hier Oracle genannt, die neben IBM mit ihrem DB2-Produkt sehr schnell zum Anführer eines völlig neuen Marktes der Datenbanken avancierte. In

10

2  IT-Organisationen im Speziellen

diesen Markt gesellte sich auch die in den 1970er-Jahren gegründete SAP AG. Durch die Integration und Verknüpfung aller Funktionen der Betriebswirtschaft auf Basis einer Datenbank war eine Anwendung entstanden, die riesige Automatisierungs- und Vereinfachungsvorteile für Unternehmen besaß. Spätestens Mitte bis Ende der 1980er-Jahre hatten die meisten EDV-Leiter dann auch erkannt, dass der Siegeszug der neuen PC- und Servertechnologien nicht aufzuhalten war. Man ordnete sich diesem Diktum unter und es entstanden Abteilungen, die nicht mehr EDV hießen, sondern Informationsmanagement. Diese kümmerten sich nicht mehr primär um die Technik, sondern um Datenmodellierung, Informationshaltung sowie die Implementierung von Anwendungen, die nicht mehr selbst geschrieben waren, sondern von großen Playern wie SAP und Oracle gekauft und im Unternehmen integriert und implementiert werden mussten. Die 1990er-Jahre waren das Zeitalter der Prozesse und der Standardsoftware. Bis Ende der 1980er-Jahre wurden die Organisationen von Unternehmen den Anwendungen angepasst. Dadurch entstanden viele Insellösungen und jeder Fachbereich hatte seine eigene, von den anderen meist abgetrennte Organisation und Abläufe. Am MIT in Boston dachte man darüber nach, eine ablauf- und bereichsübergreifende Sicht auf die Organisation zu entwickeln. Dies führte zu einer prozessorientierten Unternehmensgestaltung, dem sogenannten „Business Process Reengineering“. Viele Unternehmen begannen mithilfe von Beratern, ihre Prozesse zu analysieren und umzugestalten. Diese sehr auf die Bedürfnisse des Unternehmens eingehende Neumodellierung der Prozesslandschaft war allerdings extrem komplex. Und als Anwendungen für genau diese individuellen Prozesse ­entwickelt werden musste, war schnell ersichtlich, dass dieses Unterfangen nicht nur unbezahlbar, sondern schier unmöglich erschien. Das war die Stunde der Standardanwendungen, allen voran der sogenannten ERP-Systeme wie SAP. Denn diese Standardsoftware verfügte bereits über Prozessmodelle, die für die meisten Unternehmen grob passten. Sie wurden vor allem in den administrativen Bereichen wie Finanz- und Rechnungswesen sowie Personal Standardanwendungen eingeführt. Dadurch passten sich die Unternehmen wieder den Anwendungen an. Ausgenommen waren nur Sonderprozesse, die zum Teil mit viel Aufwand und Kosten von den Anbietern der Standardsoftware in ihrer Anwendung angepasst bzw. im Fachjargon „gecustomized“ wurden. Die Rolle der „Organisatoren“ gab es nicht mehr und so ging die Verantwortung für die Einführung dieser Standardsoftware und damit auch die Gestaltung der Abläufe, Prozesse und der Organisation im Unternehmen vielfach in die IT und die Hand des CIOs. Die Fachbereiche wehrten sich aber teilweise heftig dagegen und wollten die Verantwortung für ihre eigenen Prozesse und Abläufe behalten. Das führte dazu, dass die IT die Verantwortung für die Einführung der Standardanwendungen übernahm, das Thema Prozessoptimierung bzw. die Gestaltung von Prozessen und Abläufen aber oftmals nicht eindeutig geklärt war. Die „ITler“ galten als zu technisch, weshalb man ihnen nicht zutraute, die Prozesse und Abläufe des gesamten Unternehmens zu gestalten. Die Fachbereiche ihrerseits hatten großen Respekt vor schwierigen und aus ihrer Sicht unverständlichen und komplexen Systemeinführungen und hielten sich teilweise bewusst heraus, um hinterher der IT und dem CIO (Chief Information Officer) die Schuld für misslungene Einführungen in die Schuhe zu schieben.

2.1  Von den Anfängen der IT bis 2010

11

Heute spricht man von Veränderungsprojekten und Changemanagement, aber das Problem scheint weiterhin nicht optimal gelöst zu sein. Die 2000er-Jahre standen im Zeichen der Vernetzung und des Internets. Das bedeutete, dass Prozesse und Produkte in die neue Welt des Internets transformiert werden sollten. Virtuelle Marktplätze zum Austausch von Waren entstanden, Electronic Business war in aller Munde und hat dazu geführt, dass Daten und Informationen über den gesamten Erdball von einer auf die andere Sekunde zur Verfügung stehen. Dies hat viele Branchen revolutioniert, allen voran den Handel, der von der stationären Filiale in die elektronische Filiale des Online-Kaufhauses verwandelt wurde. Amazon oder Zalando sind typische Beispiele dafür. Auch Bankfilialen brauchen keine Vielzahl an Angestellten mehr i vor Ort, denn die Bankgeschäfte werden heute zum allergrößten Teil online abgewickelt. Das Internet hat durch die Einführung des iPhone und die sich daran anschließende Vielfalt an Smartphones oder Tablets den Weg zu jedem Konsumenten gefunden. Egal wo und zu welcher Zeit: Der Zugang zum Internet und damit zu Wissen, Informationen und Daten ist ständig und überall möglich. Was bedeutet das für die IT in den Unternehmen? In den Anfängen des Internets wurde von einigen fortschrittlichen Unternehmenslenkern dessen Potenzial erkannt. Das führte dazu, dass neue Unternehmen gegründet oder neue Abteilungen geschaffen wurden, die sich mit dem Thema „Nutzung des Internets“ auseinandersetzten. Es wurden Berater angeheuert, um neue Geschäftsmodelle zu kreieren und bestehende Geschäftsmodelle dem Internetzeitalter anzupassen. Wer allerdings meistens nicht gefragt wurde, ist der CIO und seine Kolleginnen und Kollegen aus der IT. Man sah die IT immer noch in der Technikecke verhaftet, die Einführung der Standardsoftware im vorherigen Jahrzehnt war auch nicht immer zur Zufriedenheit aller verlaufen und daher bekam kaum ein CIO oder eine IT-Abteilung die Chance, beim Thema Internet die Gestaltungsrolle im Unternehmen einzunehmen. Ein weiteres, großes Thema dieses Jahrzehnts war die Möglichkeit, Prozesse nicht nur im Unternehmen und seinen Abteilungen abzubilden, sondern sogar unternehmensübergreifend. Auf einmal rückte aufgrund des schnellen und weltumspannenden Internets die gesamte Wertschöpfungskette eines Unternehmens in den Blickpunkt: Vom Lieferanten bis hin zum Endkunden konnte eine digitale Ader alle mit den notwendigen Daten versorgen. Damit wurden bestehende Geschäftsmodelle weiter optimiert, indem zum Beispiel der Lieferant die Lagerhaltung übernommen hat und sekundengenau zuliefern konnte; der Endkunde wusste dann jederzeit, wann sein Produkt bei ihm ankommt. Auch bei diesen Entwicklungen hat die IT den technischen Part übernommen, aber die Idee, die Konzeptionierung und die damit einhergehende gestalterische Rolle lagen in den Fachbereichen. Zwischen 2010 und 2015 hatte sich dann das Thema „Digitalisierung“ seinen Weg gebannt. Die Vernetzung durch das Internet ging in eine neue Ära. Immer bessere Infrastruktur sorgte für schnellere Verbindungen und führte dazu, dass nahezu überall auf der Welt zu jeder Zeit IT-Technologie genutzt werden konnte. Viele Begrifflichkeiten prägen die Welt der Digitalisierung: Big Data, Cloud, IoT (Das Internet der Dinge), Smart Industry, M2M (Maschine-zu-Maschine-Kommunikation) sowie die künstliche Intelligenz, die ganz groß im Kommen ist. Allen diesen Begriffen ist

12

2  IT-Organisationen im Speziellen

gemeinsam, dass sie der IT entspringen und im Kern Weiterentwicklungen der gezeigten historischen Entwicklung der IT sind. Spätestens jetzt wird auch dem Letzten klar, dass IT den Übergang vom Industriezeitalter mit Fließbandarbeit zu einer echten Informations- und Wissensgesellschaft geschaffen hat.

2.2

Wo steht die IT heute?

Wenn man sich die gerade dargestellte Entwicklung der IT über die Jahrzehnte ansieht, so fällt insbesondere auf, dass die Rolle und Wahrnehmung der IT irgendwo in den 1990erund Anfang der 2000er-Jahre stecken geblieben ist. Die IT hat sich aus der Strafecke des Zu-Teuer-Seins und der reinen Technik bis heute zur Gestalterrolle freistrampeln können. Noch heute ist es in vielen Unternehmen so, dass der Alltag der IT durch die Einführung von Standardsoftware und dessen Customizing wie in den 1990er-Jahren geprägt ist. Und es sind immer noch dieselben Fragen nach der Verantwortung für die Gestaltung der Organisation und Prozesse, die weiterhin ungeklärt scheinen. Es gibt aber mittlerweile die sogenannte Cloud, über die Software jederzeit und überall bezogen werden kann. Der Cloud-Vorreiter Salesforce beispielsweise hat dieses Konzept mittlerweile in eine solche Reifephase gebracht, dass es ganz einfach ist, Salesforce zu bedienen und an die individuellen Bedürfnisse anzupassen, weshalb es der Fachbereich in den meisten Fällen selbst macht. Die IT kriegt davon zumeist überhaupt nichts mit. Denn es wird inhouse kein Server mehr benötigt und auch die Einstellungen, das Customizing und die Administration von Usern kann jeder aus dem Fachbereich selbst organisieren und durchführen. Das bedeutet, dass die IT selbst ihre ureigene Aufgabe der Technikbereitstellung mittlerweile verloren hat oder im Begriff ist, diese zu verlieren. Die Gestalteraufgabe wurde ihr bisher nicht zugetraut, jetzt entfalle zudem noch die ureigene Rolle des Maschinisten, wie Brenner und Witte es formulieren. Auf den ersten Blick scheint dies den Untergang der IT-Abteilung einzuläuten. Aber vielleicht ist es auch eine Chance, um die IT endlich ins rechte Licht zu rücken bzw. ein Plädoyer für die Schaffung einer neuen Rolle für die IT und die des CIOs. Was unternehmen die IT-Verantwortlichen, um diesem Dilemma zu entgehen? Wenn man sich die Literatur zu Themen des IT-Managements anschaut, dann fällt auf, dass es hauptsächlich um die Gestaltung der Governancefunktion sowie der Optimierung von Ablauffunktionen der IT geht. Es sind dazu unzählige Best-Practice-Ansätze in den letzten 15 Jahren entstanden, die mittlerweile zum Standard in einer größeren IT-Organisation gehören. Dazu zählen vor allem die Standardisierung von Prozessen des Service-Managements mithilfe von ITIL, aber auch die sogenannten Cobit-Prozesse für die Ausgestaltung der Governancefunktion. Die Optimierung der IT-Prozesse hat in den vergangenen Jahren viel

Literatur

13

Zeit und Energie gekostet. Das Ergebnis sind optimale Abläufe innerhalb der IT-­ Organisation. Aber was ist mit den Schnittstellen zum Fachbereich? Ist die Anerkennung der IT im Unternehmen damit gestiegen? Können Kundenprobleme hier wirklich gelöst werden? Hat die IT dadurch an Bedeutung gewonnen und schon die Rolle des Gestalters einnehmen können? Oftmals ist das Ergebnis der Optimierung der Ablauffunktionen innerhalb der eignen IT-Organisationsgrenzen leider so wenig zufriedenstellend, dass sich die Fachbereiche und die Kunden noch weiter abwenden. Denn Tickets von anonymen E-Mails, hochgradig standardisierte Hotlines, die nur noch Standardanfragen beantworten und sonst nicht helfen können sind nicht gerade kundenfreundlich. Schlimmer noch sind die IT-Prozesse im sogenannten Change- und Request-Management. wenn dieses soweit standardisiert wurde, dass Kundenwünsche egal sind und die IT selbst vorgibt, wann neue Changes eingespielt werden oder wann ein Request als Anforderung vom Fachbereich aufgenommen wird und wann nicht. Es ist kein Wunder, wenn die Fachbereiche resignieren und keine Lust mehr haben mit der IT zu diskutieren, wie man es besser machen könnte. Der CIO oder IT-Leiter hat diese Standardisierungen eingefordert, weil die IT-Systemlandschaft so komplex wurde und damit kaum noch steuerbar ist. Er hatte auch keine andere Chance, weil die Standardisierung in dieser schnellen Welt soweit fortgeschritten ist, dass die IT mit den immer neuen Anforderungen an IT-Systeme nicht mehr mithalten kann. War die Optimierung und Standardisierung der IT-Prozesse also falsch oder hat man die Schraube einfach nur etwas zu stark überdreht? Das sind Fragen, die heute sehr aktuell sind und die nicht alleine mithilfe weiterer Optimierungen der Ablauforganisation zu beantworten sind. Jetzt geht es darum, IT neu zu denken, die Aufbauorganisation der IT im Unternehmen neu zu gestalten und vor allem eine neue Rolle für die IT im Unternehmen zu entwerfen. Eine alleinige Betrachtung der IT-Organisation reicht dazu nicht aus: Die Perspektive muss erweitert werden. Es muss aus Unternehmenssicht – quasi aus Vogelperspektive – auf die Anforderungen der Fachbereiche und der IT geschaut werden. Wie soll das Unternehmen aufgebaut werden, damit die IT als Gestalter aktiv werden kann, zum Teil selbst als Fachbereich auftritt und darüber hinaus die Technologie als Commodity am Laufen hält?

Literatur 1. AXELOS/TSO (The Stationery Office): „ITIL Foundation, ITIL v4“, 1.  Auflage, AXELOS/ TSO 2019.

Teil II Der Aufbau von IT-Organisationen

3

Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

Zusammenfassung

Organisationen haben die Aufgabe, Leistung zu erbringen und Ergebnisse zu erzielen. In diesem Kontext sollen IT-Organisationen so einfach und funktional gehalten werden, dass sie für die Fachbereiche und die Kunden des Unternehmens exzellente Leistungen erbringen können. Die Ablauforganisation beantwortet in diesem Kontext die Fragen nach dem „WAS ist zu tun“ und „WER macht WAS?“

3.1

 ie 4 Möglichkeiten der Einbindung von IT D in die Unternehmensorganisation

Begonnen wird mit den aus der BWL bekannten klassischen Zuordnungsfunktionen, die zunächst klären, wie die IT-Organisation im Unternehmen eingebunden ist. Generell sind dies die folgenden 4 Organisationsformen, die auch heute noch im Mittelstand stark verbreitet sind (siehe dazu die Abb. 3.1): • • • •

Die IT-Organisation als Abteilung innerhalb eines Bereiches Die IT-Organisation als eigenständiger Bereich Die IT-Organisation als Stabsstelle Die IT in einer Matrixorganisation als zentrale und gleichzeitig dezentrale IT

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 V. Johanning, Organisation und Führung der IT, https://doi.org/10.1007/978-3-658-12008-5_3

17

18

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra IT als Abteilung innerhalb eines Bereiches

IT als Bereich

UN-Leitung

UN-Leitung

Finanzen

Einkauf

Produktion Finanzen

Controlling

IT

Einkauf

Produktion

IT

IT als Stabsstelle

IT in einer Matrixorganisation

UN-Leitung

UN-Leitung

Finanzen

IT

Finanzen

Einkauf

Produktion

Zentrale IT

Einkauf

Produktion

Controlling dezentrale

dezentraler

dezentrale

IT Fin.

IT Einkauf

IT Prod.

Abb. 3.1  Die 4 klassischen IT-Organisationsformen im Überblick

3.1.1 Vor- und Nachteile Um die 4 typischen Organisationsformen näher zu beschreiben, die Führungsstruktur und gleichzeitig deren Vor- und Nachteile näher zu untersuchen, dient die Tab. 3.1. Die Tab. 3.1 verdeutlicht, dass alle genannten Organisationsformen nicht nur Vorteile, sondern auch gewichtige Nachteile haben. Daher haben sich für die IT in der Vergangenheit oftmals sehr spezifische Organisationsformen ergeben, die im Folgenden dargestellt und näher untersucht werden sollen. Insgesamt ist festzuhalten, dass das Feld der IT-Organisationsgestaltung in der Literatur und auch in wissenschaftlichen Abhandlungen bisher nicht sehr ausführlich betrachtet wurde. Die betriebswirtschaftlichen Organisationsformen, wie sie in der Praxis heute ­gelebt werden, stoßen bei der Anwendung für IT-Organisationen aber immer wieder an ihre Grenzen. Ob es an der Komplexität der IT liegt, an der klar geforderten Serviceorientierung oder an Kommunikationsproblemen zwischen Technikern und den „Anderen“ sei dahingestellt. Trotzdem erscheint es hier wichtig, auch andere Optionen anzuschauen, die sich mittlerweile in der Praxis etabliert haben.

3.2 Übersicht von Aufbauorganisationen der IT

3.2

19

Übersicht von Aufbauorganisationen der IT

Eine IT-Organisation im Unternehmen kann in vielen verschiedenen Varianten gestaltet werden: von einer nahezu vollständig ausgelagerten IT an einen externen Dienstleister, über das Modell einer Tochterfirma bis hin zu einer internen IT-Abteilung. Im Folgenden werden nahezu alle Möglichkeiten des Aufbaus einer IT-Organisation mit ihren Zielen sowie Vor- und Nachteilen vorgestellt. Wichtig sind in diesem Kontext 2 Fragestellungen: • Wie ist die IT-Organisation in das Unternehmen eingebunden? • Wie ist die IT-Organisation in ihrem „Inneren“ organisatorisch aufgebaut? Wichtig ist dabei immer folgender Grundsatz: „Structure follows Strategy“ und „Technology follows Structure“. Das bedeutet, dass erst die Strategie des Unternehmens stehen Tab. 3.1  Vor- und Nachteile von IT-Organisationsformen Organisationsform IT-Organisation als Abteilung innerhalb eines Bereiches

Beschreibung Die IT-Organisation ist in diesem Fall nicht direkt der Unternehmensleitung zugeordnet, sondern gehört zu einem Bereich wie zum Beispiel Finanzen oder Produktion.

Vorteile Aufgrund der Bereichsführung (hier Finanzen) kann es sein, dass ein klarer Fokus auf spezifische IT-Aufgaben dieses Bereiches für das Unternehmen wichtig ist. Damit wäre eine klare Zentralisierung und Führung durch den Bereich gegeben

IT-Organisation als eigenständiger Bereich

Die IT-Organisation ist in diesem Fall direkt der Unternehmensleitung untergeordnet und nicht einem spezifischen Bereich, wie z. B. Finanzen oder Produktion

Größere Kundenbzw. Fachbereichs-­ orientierung, größere Flexibilität und Schnelligkeit bei Entscheidungen, mehr Autonomie und mehr Eigenverantwortung

Nachteile Die IT wird in solchen Fällen oftmals stark beherrscht von dem zugehörigen Bereich (im Beispiel Finanzen); dies führt oftmals dazu, dass andere Fachbereiche vernachlässigt werden (→ mangelnde Gesamtsicht) IT wird – gerade bei der Zugehörigkeit zum Bereich Finanzen – oftmals stark budgetär ausgerichtet (die Zielsetzung konzertiert sich auf Kosteneinsparungen) und nicht nach Zielen für das Gesamtunternehmen und für alle Fachbereiche Höhere Zahl an Schnittstellen zu anderen Bereichen, dadurch mehr Komplexität und Verzettelungsgefahr. Es besteht eine latente Tendenz zum Bereichsegoismus, weil dieser sich selbst zu wichtig nimmt (Fortsetzung)

20

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

Tab. 3.1 (Fortsetzung) Organisationsform Beschreibung IT-Organisation In diesem als Stabsstelle Organisationstyp ist die IT-Organisation als direkte Stabsstelle der Unternehmensleitung zugeordnet. Stabsstellen werden gebildet, um Expertenwissen bereitzustellen und beratend tätig zu sein. Wichtig sind ihre Unabhängigkeit und die Tatsache, dass sie keine Weisungsbefugnisse haben, also nur beratend tätig sind. Demnach sind sie nur ausführend als eine Art IT-Servicestelle tätig und dürfen nicht selbst entscheiden IT-Organisation Diese Form der als Matrix (zentral Organisations-­ und dezentral) gestaltung verbindet die zentrale und dezentrale Funktion von IT in Unternehmen. Es gibt eine zentrale IT-­ Organisation, die direkt der Unternehmensleitung unterstellt ist und die Rahmenrichtlinien vorgibt sowie die dezentralen IT-­ Einheiten, die den Bereichen zugeordnet sind. Diese sind zum großen Teil autark und nur den Rahmenrichtlinien und Standards der zentralen IT untergeordnet, können aber im Einzelfall für ihren Bereich entscheiden und fungieren

Vorteile Die IT bekommt klare Standards gesetzt und hat diese im Sinne des Gesamtunternehmens auszuführen. Klare Fokussierung auf Expertentum und beratende Funktion ohne Weisungsbefugnis (keine Konflikte und Kompetenzgerangel mit Fachbereichen)

Nachteile Hohes Konfliktpotenzial mit Bereichen, da informell durch die Beratung und das Expertentum sowie die Nähe zur Unternehmensleitung oftmals doch Entscheidungen getroffen werden, die eigentlich den Bereichen zustehen würden

Näher an den Problemen bzw. Wünschen der Bereiche dran und daher besser angesehen (gutes Business-IT-­ Alignement möglich). Förderung der engen Zusammenarbeit mit den Fachbereichen.

Sehr komplex durch hohes Koordinationsaufkommen. Entscheidungen werden oftmals nur langsam oder halbherzig gefällt, da sich zentrale und dezentrale Instanz oft widersprechen. Vielfach mit hohen Kosten verbunden, sofern Zentralinstanz nicht klare Standards vorgibt

3.2 Übersicht von Aufbauorganisationen der IT

21

muss, darauf aufbauend die Struktur, sprich die Organisation entstehen muss und darauf aufbauend die Technologie, sprich die IT-Systeme passend zur Organisation entworfen werden.

3.2.1 Das Modell der klassischen IT-Organisation 3.2.1.1 Definition und Ziele des Modells Noch heute trifft man in vielen mittelständischen Unternehmen auf die klassische IT-­ Organisation mit meistens 2 Abteilungen oder Teams: • eine eher softwarebasierte Abteilung: oftmals „IT-Software/ERP“ genannt und • eine eher hardwareorientierte Abteilung: meistens „IT-Betrieb und Infrastruktur“ genannt. Oft gibt es auch eine weitere Abteilung, die sich auf die Steuerung und Koordination der beiden Software- und Hardwareabteilungen konzentriert. Früher wurde sie „Organisation“ genannt und beinhaltete das Prozessmanagement, den Organisationsaufbau sowie die Betreuung sonstiger Dienstleistungen. Heute finden sich darin oft die Themen Projektmanagement, IT-Controlling, IT-Governance oder Architektur wieder. Zuweilen wird sie auch als das „CIO-Office“ bezeichnet, da sie die hoheitlichen Aufgaben der IT koordiniert und steuert. Ein Beispiel für eine klassische IT-Abteilung ist in der Abb. 3.2 zu sehen.

3.2.1.2 Vor- und Nachteile Ein historisch gewachsener Vorteil dieser klassischen Organisation ist die Trennung von Software und Hardware, um Führung und Koordination dieser beiden unterschiedlichen Welten zu gewährleisten. Damit wird auch der reibungslose Betrieb der IT durch eine eigene Abteilung, oft „IT Infrastruktur und Betrieb“ genannt, sichergestellt. In Zeiten, in denen der Betrieb noch zu mehr als 90 % intern im eigenen Rechenzentrum erfolgte, waren dies die wesentlichen Kriterien für das Unternehmen in Bezug auf IT. Stabilität und Sicherheit mussten gewährleistet sein. Durch Cloud Computing sind diese Werte und Ziele immer noch wesentlich, sind aber oftmals ausgelagert. Man spricht von „IT aus der Steckdose“ oder IT als Commodity. Damit kommen neue Ziele für die IT in den Blickpunkt des Unternehmens. Im digitalen Kontext sollen möglichst schnell neue Apps entwickelt werden, es müssen Lösungen für Industrie 4.0 gefunden werden und Big Data zum Auswerten von neuen Geschäftsmöglichkeiten sind auf der Tagesordnung. Dies verlangt nach einer neu ausgerichteten IT, die agil und stets nah am Kunden arbeiten muss, statt einfach mit den 2 Bereichen Software und Betrieb auszukommen. Damit hat sich dieses klassische Modell endgültig überlebt und wird durch neuartige Ansätze, die in Abschn. 3.2.6.1 und 3.3.5 im Detail vorgestellt werden, abgelöst.

22

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

UN-Leitung

Finanzen

IT

Produktion & Logistik

IT Operations

IT Applikationen

IT Office

Rechenzentrum / Provider Management

SAP FI/CO

IT-Sicherheit

SAP Logistik

& TK

& Produktion

IT Arbeitsplatz / Netzwerk

SAP Basis und ABAP

Einkauf

ProjektManagement

IT Controlling & Administration

Corporate Systems Abb. 3.2  Die klassische Darstellung einer internen IT-Organisation

3.2.2 Das Modell „Plan-Build-Run“ 3.2.2.1 Definition und Ziele des Modells In den Anfängen der 2000er-Jahre und teilweise schon vorher entstand eine vollkommen neue und andersartige Strukturierung der IT, die sich nicht mehr an den oben dargestellten, typischen Organisationsformen aus der Betriebswirtschaftslehre orientierte. Im Rahmen des sogenannten „Plan-Build-Run“-Konzeptes wird diese interne IT in 3 Bereiche ­aufgegliedert: • PLAN: Planung, Steuerung und Kontrolle (insbesondere Anforderungsmanagement, IT-Controlling, IT-Architektur, IT-Projektoffice, IT-Prozesse) • BUILD: Erstellung, Weiterentwicklung und Pflege der Anwendungen/Applikationen (Anwendungsentwicklung bzw. Customizing von allen Anwendungen/Applikationen sowie Test- und Qualitätsmanagement) • RUN: Betreuung und Wartung der IT-Infrastruktur und des IT-Betriebs sowie der IT-Hotline

3.2 Übersicht von Aufbauorganisationen der IT

23

Nachdem sich das Modell zum Ende des letzten Jahrtausends etablierte, erfreute es sich in den darauffolgenden Jahre zunehmender Beliebtheit und ist teilweise auch heute noch in IT-Organisationen anzutreffen. Es hat sich im Laufe der Zeit weiterentwickelt und ist in anderen Organisationsformen aufgegangen, z. B. im sogenannten „Source-Make-­Deliver“Konzept von Brenner/Zarnekow [1], welches um 2003 an der Hochschule St. Gallen entwickelt wurde. Dieses Konzept hat die IT schon wesentlich stärker im Rahmen eines Marktmechanismus verortet und ist dementsprechend eine gelungene Weiterentwicklung (Abb. 3.3).

3.2.2.2 Vor- und Nachteile Ein gewichtiger Vorteil von Plan-Build-Run ist die stark ausgeprägte Innensicht auf die IT, die sehr detailliert die wesentlichen Performance-Aspekte einer IT, nämlich Stabilität, Verfügbarkeit, Datensicherheit und IT Security fokussiert. Das wird durch dieses Modell sehr gut sichergestellt. Diese stark nach innen gerichtete Sicht auf die IT kann in der heute vorherrschenden Dynamik der digitalen Transformation allerdings auch als ein eklatanter Nachteil angesehen werden. Denn die Schnittstellen zu den Fachbereichen sind im Plan zwar angelegt, aber nicht durchgängig in allen IT-Prozessen. Das Problem wird noch größer, wenn man sich heutige Softwareentwicklungszyklen anschaut. Das was im „Plan“ gerade konzeptioniert wurde, ist, wenn es im „Build“ ankommt, in vielen Fällen schon veraltet. Es fehlt die Agilität, Sprints wie bei SCRUM sind nicht vorgesehen. Das schön strukturierte Modell ist in die Jahre gekommen und in dieser schnelllebigen Welt leider nicht mehr zukunftsfähig.

Abb. 3.3  Das Modell Plan-Build-Run

24

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

3.2.3 Das Modell „Source-Make-Deliver“ 3.2.3.1 Definition und Ziele des Modells Die Weiterentwicklung von „Plan-Build-Run“, maßgeblich durch Brenner und Zarnekow am ISG in St. Gallen entworfen (siehe [2]), basiert auf dem etablierten Prozessmodell für das Supply-Chain-Management: das sogenannte SCOR-Modell (SCOR = Supply Chain Operations Reference). Das SCOR-Modell unterteilt die Managementprozesse eines Unternehmens in 5 Prozessbereiche: Plan, Source, Make, Deliver und Return. Diese wurden von Brenner und Zarnekow für die Abbildung auf die IT-Belange genutzt, wie in Abb. 3.4 zu erkennen. In Anlehnung an das Plan-Build-Run-Modell wird auch hier zwischen IT-Leistungserbringung und IT-Leistungsabnahme differenziert. So entstehen die 3 wesentlichen Kernprozesse einer IT-Organisation: • SOURCE: Als Source wird der Beschaffungsprozess bezeichnet. Hierunter fallen das Lieferantenmanagement und die Beschaffung aller für die IT notwendigen Ressourcen. Dazu gehören z.  B.  Software und Hardware, aber auch IT-Dienstleistungen, wie z. B. für die Softwareentwicklung oder den Betrieb der IT-Infrastruktur. • MAKE: Dies meint die Leistungserstellung innerhalb der IT in Form von Services. Hierzu gehören die Entwicklung, das Portfoliomanagement sowie das sogenannte Produktionsmanagement. • DELIVER: Darunter wird die Bereitstellung der IT-Services verstanden. Diese umfasst das Management der Kundenbeziehung, die Erfassung der Anforderungen der Kunden sowie die operative Steuerung der Kundenschnittstelle.

Abb. 3.4  Das Modell Source-Make-Deliver

3.2 Übersicht von Aufbauorganisationen der IT

25

Als weiterer Prozess wird der „PLAN“-Prozess beschrieben, welcher Führungs- und Governance-Aufgaben umfasst.

3.2.3.2 Vor- und Nachteile Stärker als beim Plan-Build-Run-Paradigma wird Wert auf Kundennähe und die Befriedigung von Kundenbedürfnissen gelegt. Folgende Vorteile ergeben sich (nach Zarnekow, Brenner [2]): • Aufgaben und Rollen der IT-Leistungserbringung und IT-Leistungsabnahme sind klar getrennt • Zwischen IT-Leistungserbringer und IT-Leistungsabnehmer existiert eine Kunden-­ Lieferanten-­Beziehung, die über einen unternehmensinternen oder externen Markt abgewickelt wird • Erstmals bilden Produkte die Grundlage des Leistungsaustausches Als Nachteile für dieses Modell der Abbildung einer IT-Organisation kann die oftmals zu komplex wirkende Abbildung dieses Modells in der Praxis sein. Fachbereiche und auch das IT-Management tun sich oft schwer, ein solches Modell zu implementieren und vor allem mit Best Practices wirklich im Alltag zu leben.

3.2.4 Das Modell „Innovate-Design-Transform“ 3.2.4.1 Definition und Ziele des Modells Die aktuelle Weiterentwicklung von Plan-Build-Run über Source-Make-Deliver führt zu einem von Ahlemann und Urbach entwickelten Modell namens „Innovate-Design-­Transform“ [3]. Um die oben skizzierten Herausforderungen im IT-Management bewältigen zu können, erfordert es ein neues Zielbild der IT-Organisation, in dem die Anforderungen an die Innovations-, Gestaltungs- und Transformationsfähigkeit erfüllt werden können. Das neue Paradigma Innovate-Design-Transform (IDT-Modell) ermöglicht es, den 3 Kernpunkten der Anforderungen an ein neues Paradigma gerecht zu werden (Abb. 3.5).

Abb. 3.5  Das Modell Innovate-Design-Transform

26

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

Nach Ahlemann und Urbach sind die 3 Kernelemente des neuen Modells wie folgt definiert [3]: • INNOVATE: Hier geht es darum, gemeinsam mit den Fachbereichen und externen Partnern neue und innovative Geschäfts- und Wertschöpfungsmodelle zu entwickeln. Dieses Vorgehen ist geprägt von Kreativität, Agilität und Flexibilität. Zentrale Frage: Mit welchen IT-gestützten Innovationen Geschäfts- und Wertschöpfungsmodellen kann das Unternehmen erfolgreicher werden? • DESIGN: Die zuvor entwickelten Innovationsideen werden hier in Detailkonzepte für innovative und kundenorientierte Lösungen und IT/IS-Services überführt. Der Schwerpunkt liegt dabei auf funktionalen Designs und Ergonomie, aber auch auf Effizienz und Effektivität der Lösungen. Zentrale Frage: Wie sollen Lösungen und IT/IS-Services zur Umsetzung der Innovationen aussehen? • TRANSFORM: Nachdem die Innovation in Designs überführt (und implementiert) wurde, geht es nun darum, das Unternehmen so zu verändern, dass das neue Geschäftsoder Wertschöpfungsmodell zur Ausführung gelangt. Hierbei geht es vor allem um Struktur-, Prozess- und Kulturwandel, die ein intensives Veränderungsmanagement benötigen. Zentrale Frage: Wie ist die Gesamtorganisation zu verändern, damit die Innovationen tatsächlich zur Anwendung kommen und das Unternehmen erfolgreicher machen?

3.2.4.2 Vor- und Nachteile Nach Ahlemann und Urbach [3] sind 1. Innovationsfähigkeit, 2. Gestaltungsfähigkeit und 3. Transformationsfähigkeit die wesentlichen Paradigmen moderner IT-Organisationen, woraus sich das neue Modell des „Innovate-Design-Transform“ ableitet. Ein gewichtiger Vorteil gegenüber anderen oder älteren Modellen wie Plan-Build-Run liegt in der gemeinsamen Gestaltung von neuen IT-Produkten mit den Fachbereichen, die durch die enge Verflechtung zwischen IT und Fachbereich zu echten Innovationen entlang der gesamten Wertschöpfungskette des Unternehmens führen können. Im Mittelpunkt dieses Modells steht weniger die bisher so wichtige Implementierungsoder Programmierkompetenz, sondern mehr heute wesentliche Themen wie Kreativität, Flexibilität, Designkompetenz und auch Partnermanagement. Dies geht auch mit einem Kulturwandel einher. Haben viele IT-Organisationen lange Jahre versucht eine Dienstleistungskultur zu etablieren, geht es nun vielmehr um eine Innovationskultur, die auch unternehmerisches und risikoorientiertes Handeln und Entscheiden einschließt.

3.2 Übersicht von Aufbauorganisationen der IT

27

3.2.5 Shared-Service-Modelle 3.2.5.1 Definition und Ziele des Modells Die schon angesprochene Dienstleistungsfunktion der IT hat in der Mitte der 2000er-Jahre dazu geführt, dass IT-Organisationen oftmals in sogenannte Shared Service Center ausgegliedert wurden. Es entstanden eigene Gesellschaften, die IT als Services für das U ­ nternehmen anboten und teilweise darüber hinaus auch externe Dritte mit IT-Services bedienten. Zum Teil wurden die IT-Organisationen nicht direkt in eigene Gesellschaften ausgelagert, sondern in Form von internem Outsourcing in Einheiten verwandelt, die als internes Shared Service Center fungierten. Wichtig war dabei die Tatsache, dass gegenüber den Fachbereichen des Unternehmens eine Art Kundenverhältnis zum Shared Service Center IT geschaffen wurde. 3.2.5.2 Vor- und Nachteile Man hat sich damit folgende Vorteile erhofft: • Größere Transparenz bzgl. der IT-Kosten: Es mussten zum ersten Mal Preise für IT-­ Services etabliert werden. • Die IT sollte aufgrund des entstehenden Marktmechanismus Angebot und Nachfrage nach IT-Leistungen bewusster erkennen, anstatt nur auf Anfragen des Fachbereiches zu reagieren. • Das IT-Management sollte unternehmerisch handeln und nicht einfach nur – wie bisher – verwalten. • Eine stärkere Kundenorientierung und damit eine bessere Service-Qualität sollte erreicht werden. • IT-Leistungen sollten bestmöglich standardisiert werden. • Ein Benchmarking von IT-Leistungen sollte für die Unternehmensleitung möglich sein, um zum ersten Mal transparent zu machen, wie gut oder schlecht die IT tatsächlich ist. Shared-Service-Konzepte sind noch heute anzutreffen. Sie hatten einen sehr großen Einfluss auf die Weiterentwicklung der IT in Richtung Dienstleistungsmentalität, Transparenz und Kundenorientierung, die heute im Demand-Supply-Konzept aufgegangen ist. Dieses Konzept soll mit dem aktuellen Stand von 2014 als Grundlage für dieses Buch gelten. Hieran orientieren sich auch die Arbeitsfragen. Bevor das Demand-Supply-­Konzept näher betrachtet wird, soll aber die aktuelle IT-Organisation des Beispielunternehmens untersucht werden. Sie zeigt sehr plastisch den Weg von der in den 2000er-Jahren zu mehr als 90 % anzutreffenden, typischen IT-Organisation hin zum Demand-­Supply-Konzept.

28

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

3.2.6 Das Demand-Supply-Modell Die IT-Organisationen von mittelständischen und größeren Unternehmen sowie Konzernen sind auf Basis des „Plan-Build-Run“ oftmals den Weg gegangen, die IT-Organisation anstatt in 3 in 2 große Teilbereiche zu untergliedern: • Die Nachfrageorganisation (Demand genannt) • Die Lieferorganisation (Supply genannt) Man spricht daher von der sogenannten Nachfrage-/Lieferorganisation (kurz Demand-­ Supply Organisation), wie sie in der Abb.  3.6 exemplarisch nach Gadatsch [4] dargestellt ist. Durch das Demand-Supply-Organisationsmodell kann die IT aus der Technikrolle he­ rauswachsen und mit dem Nachfragezweig (ehemals PLAN und/oder Fachbereich) wesentlich enger an die Fachbereiche und die Unternehmensleitung heranrücken, um dort frühzeitig und proaktiv die Anforderungen in Form von Nachfrage zu erkennen und zu befriedigen. Die Unternehmensspitze wird ebenfalls aktiv mit eingebunden und gibt die Strategie vor, auf deren Basis die IT die Beschaffungs- und Nachfragestrukturen im Unternehmen als einer Art Markt abbilden kann. Der Leistungszweig (ehemals BUILD und RUN) ist der ehemalige Technikkern der IT, der als Supply die IT-Services entsprechend der Nachfrage aus dem Demand bereitstellt. Konkret heißt das für die Ausgestaltung der IT-Organisation, dass im Demand-Zweig hauptsächlich die folgenden Bereiche oder Abteilungen enthalten sind: • Request- und Changemanagement (Anforderungsmanagement) • Kosten-/Nutzen- sowie Wirtschaftlichkeitsanalysen • Prozessmanagement (dies ist von Fall zu Fall entweder eher im Fachbereich oder in der Demand-IT) Der Supply-Zweig kann sowohl intern als auch extern betrieben werden, aber auch als eine Art Mischform von internen und externen Anteilen. Supply beinhaltet dabei die Bereitstellung der IT-Leistungen in Form von Applikationen und dessen Basis durch Infrastruktur/Betrieb. Folgende Bereiche bzw. Abteilungen sind im Supply-Zweig typisch: • Anwendungsentwicklung und -betreuung • IT-Qualitäts- und Testmanagement • Betrieb & Infrastruktur Die richtungsweisende Frage ist jetzt: Wer führt den Demand-Zweig und wer den Supply-­Zweig bzw. werden beide zentral geführt? Was passiert mit den „Querschnittsauf-

3.2 Übersicht von Aufbauorganisationen der IT

Demand (Nachfrage-Organisation)

Strategie

Fachbereich 1 Fachbereich …

Fachbereich n

Supply (Liefer-Organisation)

IT-Management / CIO-Office

IT-Dienstleister (mit Rahmenvertrag)

Aufgaben: • IT-Strategie • IT-Controlling • ITAnforderungsmanagement • ITDienstleistermanagement

• Interne ITAbteilungen • IT als Tochterunternehmen • OutsourcingProvider

Regelungen

Nachfrage

Konzernvorstand

29

Nachfrage

Freie IT-Dienstleister (ohne Rahmenvertrag)

Abb. 3.6  IT Demand und Supply Organisation im Überblick

gaben“ wie Strategie, Projektmanagement oder Architektur: Gehören diese zu Demand oder Supply? Hier sind 3 verschiedene Modelle möglich, die auch in Abb. 3.7 als Blueprint dargestellt sind: • Dezentrale Demand-IT: Besitzt ein CIO-Office für den Demand-Zweig und ein CTO-Office für den Supply-Zweig (Anmerkung: CIO steht für Chief Information Officer und CTO steht für Chief Technology Officer) • Zentralisierte Demand-IT: Genauso wie bei der dezentralen Demand-IT, nur ist hier das Anforderungs- und Prozessmanagement direkt bei den Demand-Managern und nicht im CIO-Office • Demand/Supply in einem CIO-Office: Beide Zweige haben ein gemeinsames CIO-Office Generell befinden sich im CIO-Office des Demand-Zweigs folgende Abteilungen bzw. Bereiche:

30

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

Getrennte Verantwortungen für Demand und Supply IT-Management / CIO-Office IT Strategie, IT-Architektur IT-Controlling und Administration IT Projektmanagement • • •

• •

Request & Change Management Kosten- / Nutzen sowie Wirtschaftlichkeitsanalyse Prozess-Management (evtl. auch Fachbereich)

Supply

Demand

• • •

CTO-Office IT-Providermanagement Service Management Prozesse

• • •

Anwendungsentwicklung- und betreuung Systemintegration Betrieb & Infrastruktur

Demand-Supply in einem Management-Office IT-Management / CIO-Office IT Strategie, IT-Architektur , IT-Controlling und Administration IT Projektmanagement IT Sicherheit und Qualitätsmanagement IT-Providermanagement Service Management Prozesse • • •

Request & Change Management Kosten- / Nutzen sowie Wirtschaftlichkeitsanalyse Prozess-Management (evtl. auch Fachbereich)

Supply

Demand

• • • • •

• • •

Anwendungsentwicklung- und betreuung Systemintegration Betrieb & Infrastruktur

Abb. 3.7  Blueprint Demand-Supply-Organisation

• IT-Strategie, IT-Architektur (wobei die Frage nach der Hoheit über die IT-Architektur durchaus strittig ist und viele Unternehmen die IT-Architektur auch im Supply-­ Zweig sehen) • IT-Controlling und Administration • IT-Projektmanagement Im Supply-Zweig des CTO-Office befinden sich folgende Abteilungen bzw. Bereiche, die Supply-übergreifend Dienstleistungen bereitstellen: • IT-Providermanagement • Service-Management-Prozesse (Definition und Standards für die Competence Center des Supply-Zweiges) Bei nur einem CIO-Office für Demand und Supply werden die o. g. Bereiche gemeinsam in diesem Office geführt. Die Bereiche „IT-Sicherheit“ sowie „IT-Qualitäts- und Testmanagement“ sind ebenfalls oftmals als Querschnittsfunktion im Supply-Zweig zu finden. Viele Unternehmen

3.3 Besonderheiten in der Aufbauorganisation der IT

31

haben diese allerdings auch als eigenes Competence Center im Supply-Zweig oder aufgrund der Wichtigkeit für das Unternehmen zumindest den Bereich „IT-Sicherheit“ auch im CIO-Office eingegliedert. Mit dieser Aufteilung in Demand und Supply etabliert sich die IT als eine zweigeteilte Organisation, die mit dem Demand-Teil wesentlich enger in das Business und den Fachbereich eingebunden ist und damit proaktiver gestalten, steuern und moderieren kann. Der Supply-Teil ist die wirkliche „Factory“, in der IT-Leistungen entwickelt, angepasst (customized), betrieben und betreut werden. Dies kann bei klar definierten Schnittstellen zwischen Demand und Supply sowohl durch eine interne Organisation oder durch externe Partner bzw. eine Mischung aus beidem erfolgen.

3.2.6.1 Vor- und Nachteile des Demand-/Supply-Modells Die Vorteile des Demand/Supply-Konzeptes können folgendermaßen dargestellt werden: • Business-IT-Alignement: IT-Leistungen lassen sich klar und nachvollziehbar aus den geschäftlichen Anforderungen herleiten. Für Leistungen kann ein Business Case gerechnet werden. • Trennung von IT-Nachfrage und IT-Angebot: Durch Trennung von Nachfrage und Angebot ist der Interessenkonflikt zwischen bestmöglicher individueller IT-Lösung und kostensenkender Standardisierung lösbar. • Es entsteht Transparenz bzgl. Kosten, Leistungen und Aufgaben. • Durch kürzere Entscheidungswege und klare Verantwortlichkeiten wird eine Effizienzverbesserung erreicht. • Klarere Aufgaben- und Rollendefinitionen sowie bessere Abgrenzung zu den Aufgaben der Fachbereiche sorgen für Mitarbeitermotivation. Ein oft dargestellter Nachteil: Der Supply-Part sei zu weit entfernt vom Business. Generell bleibt aber festzuhalten, dass bei einer Kopplung mit modernen Methoden der agilen Softwareentwicklung, z. B. in Form von SCRUM, das Demand-Supply-Modell durchaus zukunftsfähig ist und ein gut geeignetes Modell für die Gestaltung einer IT-Organisation darstellt.

3.3

Besonderheiten in der Aufbauorganisation der IT

3.3.1 DevOps DevOps ist ein Kunstwort bestehend auf „Development“ (Entwicklung) und „Operations“ (IT-Betrieb). Durch eine wesentlich engere Zusammenarbeit dieser beiden Bereiche soll eine stark verbesserte IT-Leistung in Form von höherer Geschwindigkeit bei der Entwicklung, effizientere Auslieferung und bessere Qualität der Software erreicht werden.

32

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

Durch das Rollenverständnis – oftmals geprägt durch das vielfach in der Praxis eingesetzte Plan-Build-Run-Modell (siehe Abschn.  3.2.1.2)  – fand ein Silodenken zwischen Entwicklung und IT-Betrieb statt. Oft wurde eine fertig entwickelte Software aus dem Build einfach über den Zaun zum Run geworfen und dort wusste niemand Bescheid. Das führte zu Verzögerungen in der Auslieferung der Software und auch die Qualität litt darunter. Durch DevOps wurden Methoden und Prozesse entwickelt, die diese Zusammenarbeit wesentlich effektiver gestalten. Oft sitzen auch die entsprechenden Protagonisten aus ­Build und Run gemeinsam in einem Raum, um ständig über den aktuellen Stand informiert zu sein und so schon in der Entwicklungsphase alles so zu gestalten, dass es für die Betriebsphase passt. Die Abb. 3.8 zeigt schematisch den Ablauf eines DevOps-Modells. Im Dev-Teil finden die Prozesse „Plan – Code – Build – Test“ statt. Der „Release“-Prozess findet gemeinsam zwischen Dev und Ops statt und auf Ops-Seite wird dann die Verantwortung für die Prozesse „Deploy – Operate – Monitor“ übernommen. Man spricht bei der Verzahnung von Code-Entwicklung und Code-Ausführung auch von „Continuous Integration“. Es gibt dazu seit einigen Jahren spezifische Continuous-Integration-Software, die dafür sorgt, dass die Code-Qualität verbessert wird. Auch im Rahmen von DevOps ist der Begriff des „Continuous Delivery“ (kontinuierliche Bereitstellung) zu nennen. Dies ist eine Softwareentwicklungsmethode, bei der Codeänderungen automatisch erstellt, getestet und für eine Produktionsversion vorbereitet werden. Die Continuous Delivery ist eine Erweiterung der Continuous Integration. Dabei werden alle Codeänderungen nach dem Entwurf in einer Test- und/oder Produktionsumgebung bereitgestellt. Bei einer korrekten Implementierung der Continuous Delivery steht Entwicklern stets ein Erstellungsartefakt für die Bereitstellung zur Verfügung, das bereits einen standardisierten Testprozess durchlaufen hat.

3.3.2 BizOps bzw. BizDevOps Wenn es um eine bessere Verzahnung zwischen IT und Fachbereich ging, dann wurde bisher viel von professionellem Anforderungsmanagement geredet oder von agilen Teams oder Abb. 3.8 Schematische Darstellung des DevOps-Modells

3.3 Besonderheiten in der Aufbauorganisation der IT

33

Product-Management. Dies ist alles nicht falsch, aber es gibt jetzt einen neuen Ansatz, der endlich die Business-Treiber und die Belange der IT zusammenbringt und dabei den Fokus immer auf den Nutzen und Mehrwert eines jedes IT-Projektes legt. Es nennt sich „BizOps“! BizOps ist im Grunde eine Erweiterung von DevOps. So zielt DevOps etwa darauf ab, die beiden Silos Softwareentwicklung und IT-Betrieb bewusst aufzubrechen und eng miteinander zu verzahnen. BizOps hebt diesen Gedanken nun auf die nächste Ebene. Denn es geht nicht länger um eine agile IT allein, sondern um bessere und schnellere Ergebnisse im Unternehmen insgesamt. Durch BizOps werden Entscheidungen nicht nur beschleunigt, sondern unterliegen immer mindestens einem Nutzenkriterium für das Unternehmen. Ein wichtiger Faktor ist hierbei, dass der Fachbereich als Kunde frühzeitig in Prozesse einbezogen und die Zusammenarbeit zwischen Teams verbessert wird. Wie sieht das in der Praxis aus? BizOps-Teams bestehen aus IT- und Fachbereichsmitarbeitern und können für unterschiedliche Aufgaben eingesetzt werden: 1. Eng an einen Fachbereich angebunden für spezifische, aber unternehmenskriti sche Tasks. 2. Direkt an die Geschäftsführung angebunden für die strategische Planung und Erarbeitung sowie Validierung von neuen, IT-, Daten- oder technologiegetrieben Geschäftsmodellen. 3. In der IT eingebunden, aber mit starkem Bezug zu einem Fachbereich oder Prozessthema (idealerweise disziplinarisch in der IT mit fachlicher Führung aus dem Fachbereich sowie einem Arbeitsplatz sowohl in der IT als auch im Fachbereich). Was braucht ein solches BizOps-Team? Das typische Skill-Set eines BizOps-Mitarbeiters könnte wie folgt aussehen: • • • • • • •

Change Attitude Umsetzer- und Macherqualitäten Einfühlungsvermögen Agile und flexible Denkhaltung Eher Generalist als Spezialist – Allrounder IT-Background Strategisches Wissen und Geschäftsmodell-Know-how

Eine ideale Erweiterung des BizOps-Gedanken ist die Vereinigung mit DevOps zu einem Konzept, welches man BizDevOps nennen könnte. Damit ist die tatsächliche End-to-End-Verantwortung für ein IT-Produkt vom Fachbereich über die Entwicklung bis zur Operations gegeben. Wollte man diese Erweiterung von BizDevOps grafisch darstellen, dann sähe diese wie in Abb. 3.9 aus.

34

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

Abb. 3.9  BizDevOps in der Übersicht

3.3.3 Eine bimodale IT-Organisation Von einer bimodalen IT spricht man, wenn die IT-Organisation in 2 Teile aufgesplittet wird. Der eine Teil kann als die „traditionelle IT“ bezeichnet werden, mit einer herkömmlichen Entwicklungs- und Betriebsorganisation. Der 2. Teil ist die „neue“ oder besser „agile IT“, die auf einer Art Überholspur Projekte mit hohem Geschwindigkeits- und Innovationsanspruch sowie dafür notwendigen Methoden zum Ziel führt. Die Abb.  3.10 zeigt die bimodale IT-Organisation in einer Matrix mit den Achsen „Geschwindigkeit“ und „Stabilität/Zuverlässigkeit“. Es ist deutlich zu sehen, dass die „agile IT“ deutlich schneller zu Ergebnissen kommt als die „traditionelle IT“; diese allerdings hat den Vorteil der etwas größeren Stabilität und Zuverlässigkeit. Je nachdem was im Unternehmen gefordert ist, kann zwischen diesen beiden Arten der IT-Organisation gewählt werden. Die Entwicklung von Apps als digitaler Service zu einem Produkt sollte schnell am Markt verfügbar sein und braucht daher eher den agilen Ansatz der „agilen IT“. ERP-Projekte können in einer Mischung aus beiden Ansätzen erfolgreich sein. Entstanden ist die bimodale IT durch höhere Ansprüche im digitalen Kontext. Denn die Produktzyklen sind nicht nur im Automobilbau oder bei Smartphones rapide gesunken. Auch in der Softwareentwicklung ist der Lebenszyklus einer heute entwickelten App bereits in ein paar Monaten überholt. Die Tab. 3.2 macht die Unterschiede zwischen traditioneller und agiler IT anschaulich und bringt damit auf den Punkt, warum viele CIOs sich eine bimodale IT wünschen. Denn der komplette Change der IT hin zu nur noch modernen Entwicklungsmethoden ist oftmals nicht so einfach möglich. Sperrige Legacy-Systeme, das riesige ERP und andere alte Schätze verhindern oft den kompletten Change. Ein Ausweg ist dann eine bimodale IT, um so zumindest für anspruchsvolle Kunden lieferfähig zu sein. Allerdings wird die bimodale IT von vielen Experten nur als eine Art Übergangsmodell hin zu einer vollständig agilen IT-Organisation angesehen. Darüber hinaus scheitert der

3.3 Besonderheiten in der Aufbauorganisation der IT

35

hoch

Abb. 3.10  Die bimodale IT-Organisation

Geschwindigkeit

Modus 2: Agile IT

niedrig

Modus 1: Traditionelle IT

niedrig

Stabilität & Zuverlässigkeit

hoch

Tab. 3.2  Der Unterschied zwischen traditioneller und agiler IT Ziel Fokus Planungshorizont Methoden Entwicklungszyklen Entwicklung und Betrieb

Traditionelle IT Stabilität und Zuverlässigkeit Systemzentriert Langfristig Plangetrieben Lang Strikt getrennt

Agile IT Innovation und Differenzierung Benutzerzentriert Kurzfristig Iterativ und agil Kurz Integriert

Quelle: Volker Johanning

bimodale Ansatz in vielen Fällen an einer absolut nachvollziehbaren, menschlichen Eigenschaft: Keiner will zu den „Langsamen“ zählen. So nahm z. B. Ende 2017 der CIO von BMW genau aus diesem Grund vom bimodalen Modell bzw. der „Two-Speed-IT“ Abstand, um alle Projekte auf „100 Prozent agil“ umzustellen [5]. Dies zeigt sehr deutlich, dass „Misch-Ansätze“ zwar zumeist gut gemeint, aber in der Praxis gar nicht umsetzbar sind. Mehr zu den notwendigen Methoden zur Einführung von 100 % agil werden etwas weiter unten ab Abschn. 3.3.5. dargestellt.

3.3.4 Die IT Organisation im internationalen Kontext Deutschland ist seit vielen Jahren Exportweltmeister. Die meisten Unternehmen sind daher global aufgestellt mit vielen Produktionsstätten und Vertriebsniederlassungen auf der ganzen Welt.

36

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

Was bedeutet das für die IT-Organisation? Wie kann die IT sich so organisieren, dass sie diesem weltweiten Anspruch nach hohen Standards auch in Bezug auf IT gerecht wird? Im Mittelpunkt der Überlegung steht aus Sicht der IT und des CIOs das Thema Standardisierung – sowohl auf der Ebene der IT-System-Standards als auch in Bezug auf die IT-Kosten im globalen Kontext. Wie in Abb. 3.11 zu sehen, sinken die IT-Kosten mit dem Grad der Standardisierung. Dies ist der wesentliche Grund, warum IT-Systeme bei international agierenden Unternehmen überall auf der Welt möglichst nah am Standard sein sollten. Gleiches gilt für die Prozesseffizienz: Je stärker der Grad der Standardisierung des IT-Systems, desto größer ist auch die Prozesseffizienz des Unternehmens. Für die Struktur der IT-Organisation bedeutet dies, dass die IT-Standards weltweit durchgesetzt werden müssen und daher eine zentrale IT-Organisation für die Vorgaben dieser IT-Standards verantwortlich sein muss. Generell gibt es 2 Arten der Strukturierung einer IT im internationalen Kontext: 1 . Headquarter-orientierte IT-Organisation = zentrales IT-Management 2. Werksorientierte IT-Organisation = dezentrales IT-Management

niedrig

IT-Kosten

hoch

Im 1. Fall der Headquarter-orientierten IT-Organisation können bzw. werden IT-­ Entscheidungen zentral im Headquarter getroffen. Damit können auch IT-Standards in allen Werken bzw. Niederlassungen durchgesetzt werden, welches zu den gezeigten Kosten-Prozesseffizienzen führt.

niedrig

Grad der Standardisierung

Abb. 3.11  Die IT im internationalen Kontext

hoch

3.3 Besonderheiten in der Aufbauorganisation der IT

37

Auf der anderen Seite ist auch ein dezentrales IT-Management möglich, in dem die Werke bzw. Niederlassungen eine eigene Systemlandschaft aufbauen und verwalten. Dies kann bei sehr unterschiedlichen Produkten und Prozessen durchaus Sinn machen. Wenn z. B. ein Werk in den USA ganz andere Produkte herstellt als das Werk in China und auch die Prozesse vollständig unterschiedlich sind, dann macht eine dezentrale IT-Organisation durchaus Sinn. Es ist auch ein Kompromiss zwischen zentral und dezentral möglich. Dabei werden z. B. nur bestimmte Prozesse aus dem Headquarter vorgegeben und andere können individuell und dezentral an die jeweiligen Bedürfnissen angepasst werden. Darüber hinaus müssen neben der IT-Systemlandschaft auch der Betrieb, die Infrastruktur und vor allem der Support betrachtet werden. Hier können auch zentrale und ­dezentrale Ansätze in Betracht gezogen werden, wobei der Support nur eingeschränkt global funktionieren wird. Stattdessen muss dieser eher lokal erfolgen, zumindest bei Themen, die nur physisch vor Ort zu erfüllen sind. Vom User aus gedacht, sollte die internationale IT die folgenden Anforderungen im Sinne einer global standardisierten IT erfüllen: • Gleiches Betriebssystem und User-Accounts: dadurch überall gleiche Anmeldeprozeduren (Accounts) für alle Niederlassungen des Unternehmens • Gleiche Hardware: Support sowie Wartung/Pflege sind überall gleich und man kann sich gegenseitig helfen • Ein User kann sich überall auf der Welt mit den immer gleichen User-Account- und Passwörtern im Firmennetzwerk anmelden • Es gibt überall die gleiche Office- und E-Mail-Software zum besseren Austausch aller Mitarbeiter weltweit untereinander • In Bezug auf ERP existieren die gleichen Regeln weltweit  – zumindest für die Stammdaten • Financial Reports sind überall gleich aufgebaut und damit vergleichbar • CRM-Gemeinsamkeiten: weltweite Kunden-Datenbank, sodass ebenso global agierende Kunden nicht in x Datenbanken auftauchen, sondern nur einmal in einer CRM-Datenbank (dies generiert Synergien in der Kundenansprache) • Es werden die gleichen Kollaborationstools zum einfachen Austausch untereinander benutzt • Der Service Desk ist überall gleich bzw. standardisiert

3.3.5 Linienzentrierte versus projektzentrierte IT-Organisation IT-Organisationen sind immer auch Projektorganisationen. Da in den meisten Fällen die Projektorganisation ein Dasein im Schatten der eigentlichen IT-Organisation mit den disziplinarischen Verantwortlichkeiten führt, kommt es hier vermehrt zu Kompetenzgerangel aufgrund ungeklärter Verantwortlichkeiten.

38

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

Dabei ist die Differenzierung zwischen fachlicher und disziplinarischer Verantwortung nur das eine Thema. Ein anderes ist in diesem Zusammenhang die „Leihgabe“ der Mitarbeiter aus der disziplinarischen Linienorganisation in eine temporäre Projektorganisation. Hier kommt es vielfach nicht nur zwischen Projektleiter und disziplinarischem Vorgesetzten zu Problemen, sondern auch die Projektmitarbeiter leiden unter ungeklärten Konflikten auf anderer Ebene. Dieses skizzierte Alltagsproblem entspricht der am häufigsten vorkommenden sogenannten linienzentrierten IT-Organisation. Dem gegenüber gibt es die projektzentrierte IT-Organisation, die in Abb. 3.12 der linienzentrierten Organisation gegenübergestellt wird. Die linienzentrierte IT-Organisation ist geprägt durch eine klar strukturierte, oftmals funktionale Organisationsform. Aufgrund dieser Prägung haben die Linienverantwortlichen mehr Macht als die Projektleiter und sehen ihr Tagesgeschäft als prioritär gegenüber den temporär angelegten Projekten. Projekte sind zum großen Teil linienübergreifend organisiert. Durch die Herrschaft der Linie gestaltet sich die Projektkoordination über Liniengrenzen hinweg für den Projektleiter jedoch immer sehr schwierig. Eine ausgeprägte Projektkultur kann sich unter diesen Umständen nicht entwickeln, da jeder Mitarbeiter sich eher an seiner Linienorganisation orientiert, um langfristig Karriere machen zu können. Das Thema Personalentwicklung und Qualifizierung ist in solchen Fällen ebenfalls stärker durch die Linie geprägt. Es wird nicht so sehr auf temporäre Projektkenntnisse geachtet, sondern mehr auf die eigene Spezialisierung der Linienorganisation. Die Verantwortung für die Projekte liegt bei Linienverantwortlichen, die Projekte beauftragen und überwachen. Der Projektleiter ist dementsprechend immer einem Linienverantwortlichen untergeordnet. Die projektzentrierte IT-Organisation dagegen ist dadurch geprägt, dass nicht die Linie mit dem Tagesgeschäft im Vordergrund steht, sondern das Voranbringen von IT-Projekten. Dazu ist eine linienübergreifende Koordination in Form von Projektmanagement-Offices Linienzentrierte IT-Organisation

Projektzentrierte IT-Organisation

vs.

Abb. 3.12  Linienzentrierte versus projektzentrierte IT-Organisation

3.4 Agile Methoden in der IT-Organisationsgestaltung

39

gegeben, die direkt am CIO angegliedert sind. Hier findet die Priorisierung, Bewertung und Beauftragung von IT-Projekten mit der Unterstützung von Projektportfolios statt. Business-­IT-Alignement steht in solchen Organisationsformen im Mittelpunkt und wird durch Projekte mit den Fachbereichen forciert. Die Linienorganisationen stellen das Personal für die Projekte zur Verfügung und sorgen für die Koordination und Sicherstellung der Balance zwischen Linienaufgaben (Tagesgeschäft) und Projektaufgaben. Die Qualifizierung und Personalentwicklung ist stark an großen Projektvorhaben orientiert und leitet sich aus den Bedürfnissen und Anforderungen der Fachbereiche ab. Bei großen Projekten ist es wichtig, dass der Projekt- oder Programmleiter unabhängig von Linienentscheidungen ist, daher wir dieser oftmals direkt dem CIO in einer Art Projektpool unterstellt.

3.4 cc

Agile Methoden in der IT-Organisationsgestaltung Der digitale Wandel und die Start-up-Welt haben dazu beigetragen, dass auch die IT-Organisationen sich einem großen Wandel unterziehen. Insbesondere agile Methoden, der systemische Denkansatz und Netzwerkstrukturen sind die Effizienztreiber einer modernen IT-Organisation.

3.4.1 SCRUM 3.4.1.1 Definition und Ziele von SCRUM SCRUM ist keine Organisationsform, sondern eine Projektmanagementmethode, welche die agile Denkweise insbesondere in der Softwareentwicklung einsetzt. Der aus dem Englischen abgeleitete Terminus „SCRUM“ ist keine Abkürzung, sondern stammt aus dem Rugby und bedeutet übersetzt soviel wie „dichtes Gedränge“. Im Rugby entsteht dies immer dann, wenn sich alle Spieler um den Ball versammeln. Bezogen auf die Softwareentwicklung steckt dahinter der Gedanke, dass die Entwicklung von Software nur durch Einzelkämpfer nicht mehr den heutigen Anforderungen von Schnelligkeit und Flexibilität gewachsen ist. SCRUM setzt hier an, indem es den Teamgedanken in den Vordergrund stellt. Anstatt dichtem Gedränge soll nur das Hin- und Her-Spielen des Balles nach Regeln den Erfolg bei der Softwareentwicklung in puncto Schnelligkeit und Flexibilität herstellen. Diese Form der Selbstorganisation eines Entwicklerteams braucht keine starren Projektregeln und auch keinen expliziten Projektleiter. Ein SCRUM-Master sorgt dafür, dass die Regeln des SCRUMs im Entwicklungsprozess eingehalten werden. Dieser SCRUM-Master ist also für die Prozesse verantwortlich. Im Gegensatz zum Product Owner, der als Produktverantwortlicher eigenverantwortlich die Anforderungen definiert und priorisiert. Innerhalb eines sogenannten Sprints, in dem die Entwicklung vonstattengeht, darf das Entwicklerteam jedoch nicht gestört werden und kann sich voll auf seine Aufgaben konzentrieren.

40

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

SCRUM ist verhältnismäßig einfach und unmittelbar einsetzbar, um strukturiert aber dennoch flexibel zu entwickeln. SCRUM funktioniert dabei empirisch, inkrementell und iterativ, das heißt, die Anwendung erfolgt aufgrund von Erfahrungen, in kleinen Schritten und sich wiederholenden Etappen.

3.4.1.2 Die Funktionsweise und die Artefakte von SCRUM SCRUM besteht aus sogenannten Artefakten, die die Funktionsweise von SCRUM beschreiben. Dazu gehören der Ablauf, die Rollen und die Artefakte bzw. Dokumente selbst. Diese werden zum besseren Verständnis im Folgenden vorgestellt und sind in Abb. 3.13 grafisch dargestellt. Generell ist zum Ablauf zu sagen, dass ein SCRUM-Prozess in sogenannte Sprints eingeteilt ist, die zwischen 2 und maximal 4 Wochen dauern können. Dabei besteht ein Sprint aus folgenden Bestandteilen: • Dem „SPRINT PLANNING“: • Den „DAILY SCRUMS“: Das Daily SCRUM dauert 15 Minuten. Jedes Teammitglied beantwortet kurz 3 Fragen: 1. Was habe ich seit dem letzten Daily SCRUM getan? 2. Was hat mich dabei behindert? 3. Was werde ich bis zum nächsten Daily SCRUM tun? • Dem „SPRINT REVIEW“ • Und der „SPRINT RETROSPEKTIVE“: Was haben wir gelernt? Was lässt sich verbessern? SCRUM Master

Product Owner

Product Backlog

Sprint Backlog

Anforderungen User-Story

Abb. 3.13  Die SCUM-Methode im Überblick

Daily SCRUM

SPRINTS

Sprint Retrospektive

SCRUM Team

Produkt

3.4 Agile Methoden in der IT-Organisationsgestaltung

41

Der SCRUM-Prozess liefert am Ende wie in der Abb.  3.13 zu sehen ist, ein erstes, funktionsfähiges (!) Produkt aus. Dies wird dem Auftraggeber vorgelegt, der dieses Produkt prüft und dazu Rückmeldungen gibt, was noch fehlt, anders sein soll oder schon passt. Dieses Feedback des Auftraggebers geht jetzt wieder in den Product Backlog ein und der SCRUM-Prozess beginnt von neuem. Die folgenden 3 Rollen sind im SCRUM-Prozess wichtig: Product Owner Er steht stellvertretend für die Anwender des Produkts oder die Stakeholder des Projekts. Im Falle einer Software wären das beispielsweise die Nutzer, die sich einen reibungslosen Ablauf wünschen. Im Falle eines Produktes sind es die Produktmanager, die ihre Kunden repräsentieren. Team Das Team organisiert sich selbst, es braucht schon aufgrund seiner geringen Größe (2–9 Teammitglieder) keinen klassischen Projektleiter. Daher erhält es keinerlei Vorschriften, wie es vorzugehen hat. Aufgrund seines interdisziplinären Aufbaus finden sich dort Softwarearchitekten ebenso wie beispielsweise Programmierer, Qualitätssicherer und Tester. SCRUM Master Er übernimmt die Funktion eines Moderators. Das bedeutet, dass er dafür sorgt, dass im Team die Theorie, die Praktiken und die Regeln der SCRUM-Methode eingehalten werden. Außerdem ist er Ansprechpartner für Außenstehende, indem er klärt, welche Interaktionen mit dem Team förderlich sind und welche nicht. Darüber hinaus gibt es wie in der Abb. 3.13 zu sehen, 3 Artefakte oder Dokumente, um den SCRUM-Prozess regelkonform durchzuführen: Product Backlog Das Product Backlog ist eine To-do-Liste mit Anforderungen (Requirements). Es wird ständig weiterentwickelt und vom Product Owner geführt. Da das Product Backlog dynamisch ist, ist es niemals vollständig – der Product Owner passt es ständig an das Produkt an. Sprint Backlog Aus den Anforderungen des Product Backlogs wird eine Auswahl an Anforderungen getroffen, die das Team innerhalb eines Sprints bearbeiten wird. Die einzelnen Aufgaben im Sprint Backlog werden Tickets genannt. Jedes Teammitglied übernimmt die Verantwortung für ein eigenes Ticket. Das Sprint Backlog gibt eine Prognose darüber, inwieweit das nächste Inkrement funktionstüchtig sein wird bzw. welche Arbeit noch notwendig ist, um ein funktionsfähiges Done liefern zu können. Hier wird zur besseren Visualisierung oft mit dem KANBAN Board gearbeitet.

42

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

Product Increment Am Ende jedes Sprints steht ein funktionsfähiges Zwischenprodukt – das Produktinkrement. Es muss auch dann einsatzfähig sein, wenn der Product Owner es noch nicht ausliefern will. Was jetzt noch fehlt, sind die Regeln und Planungen für den SCRUM-Prozess. Hier sind 4 wesentliche Meetings vorgesehen: Sprint Planning Im Sprint Planning plant das Team den nächsten Sprint. Dabei werden die Anforderungen in konkrete Aufgaben (Tasks) zerlegt. Diese sollten innerhalb eines Tages bearbeitet werden können. Großen Wert wird hier auf effiziente Kommunikation gelegt; die wird „Face to Face“ und keinesfalls lediglich durch Übergabe von Dokumenten praktiziert. Das Ergebnis des Sprint Planning ist der Sprint Backlog. Daily SCRUM Zu Beginn eines jeden Arbeitstages trifft sich das Team zu einem maximal viertelstündigen Meeting, dem Daily SCRUM. Es wird bevorzugt im Stehen abgehalten, da dies die Konzentration auf wichtige Punkte fördern soll. Einmal am Tag wird so der Austausch mit allen Teammitgliedern gewährleistet. Jedes Teammitglied erläutert kurz seinen Stand der Dinge: • Was wurde seit dem letzten Meeting erledigt? • Was wird bis zum nächsten Meeting geplant? • Welche Hindernisse/Probleme behindern das Vorankommen? Probleme, die sich nicht innerhalb einer Viertelstunde lösen lassen, werden an den SCRUM Master übergeben. Daily SCRUM ist ein wesentliches Mittel zur Reflexion und Selbstorganisation des Teams. Sprint Review Am Ende eines jeden Sprints steht eine Sprint Review. Hier präsentiert das Entwicklungsteam das Produktinkrement (im Sinne von „Done“). Dabei wird das Produkt überprüft und der Product Backlog gegebenenfalls angepasst. Der Product Owner ebenso wie die Stakeholder können Input geben, allerdings obliegt die letzte Entscheidung darüber, ob Anforderungen verändert werden, dem Product Owner. Sprint Retrospective Bei der Retrospektive geht es um eine Überprüfung der Arbeit des Projektteams, um sie kontinuierlich zu verbessern. Zentrale Fragen sind hier beispielsweise: • Was hat die Zusammenarbeit behindert? • Was war besonders förderlich für die Zusammenarbeit? • Welche neuen Ansätze sollten stärker berücksichtigt werden?

3.4 Agile Methoden in der IT-Organisationsgestaltung

43

Nicht direkt zum offiziellen Teil von SCRUM dazugehörig, aber doch empfehlenswert ist ein weiteres Meeting: Die Lesson Learned oder „Fuck-up Hour“. Die Anhänger der Agilität wollen konstruktiv mit Fehlern umgehen. Deshalb reden sie bei der Fuck-up Hour offen über Rückschläge und deren Lektionen. Das ist nicht nur lehrreich, sondern stärkt auch das Vertrauen im Team. Als kurzes Fazit lässt sich sagen, dass die SCRUM-Methode durch die sehr gute Struktur mit wenigen Hilfsmitteln schnell umzusetzen ist und wirkliche Transparenz bei der Umsetzung oder beim Hadern mit nicht fertig werdenden Projekten schafft.

3.4.2 IT-KANBAN 3.4.2.1 Definition und Ziele von KANBAN in der IT KANBAN stammt ursprünglich aus der Automobilindustrie. Es wurde schon 1947 von Taiichi Ohno bei Toyota entwickelt und ist ein Kernbestandteil des sogenannten Toyota-­Produktionssystems (TPS). Mit Karten signalisiert man im TPS dem jeweils vorgelagerten Produktionsbereich, was in welchen Mengen produziert werden soll. Die so entstehende Just-in-Time-Produktion stellt nur genau das her, was wirklich gebraucht wird. Genau dieses Prinzip lässt sich auch in der Softwareentwicklung anwenden. David Anderson übertrug dieses Konzept auf diesen Bereich. Er integrierte die Grundidee von KANBAN mit grundlegenden Prinzipien – sowohl aus der Lean Production als auch aus dem Lean Product Development  – und ergänzte diese durch die Theory of Constraints sowie durch das klassische Risikomanagement [6]. KANBAN ist damit – genauso wie SCRUM – kein Organisationsmodell, sondern eine Methode zur Auftragssteuerung und -überwachung in der IT. 3.4.2.2 Die Funktionsweise von KANBAN in der IT David Anderson, einer der Begründer agiler Softwareentwicklung, beschrieb 4 Grundprinzipien und 6 Praktiken, die Unternehmen bei der Anwendung von KANBAN in ihre Arbeitsweise einbauen. Die 4 Grundprinzipien (sogenannte „Foundational Principles“) sind: • Grundprinzip 1: „Start with what you do now!“: Beginne mit dem, was du gerade tust. • Grundprinzip 2: „Agree to pursue incremental, evolutionary change“: Verfolge inkrementelle, evolutionäre Veränderung. • Grundprinzip 3: „Respect the current process, roles, responsibilities and titles“: Respektiere gegenwärtige Prozesse, Rollen, Verantwortlichkeiten und Ansprüche. • Grundprinzip 4: „Encourage acts of leadership at all levels in your organization – from individual contributor to senior management“: Fördere führendes Handeln auf allen Ebenen der Organisation  – vom einzelnen Mitarbeiter bis zur Geschäftsleitung.

44

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

Wesentlich ist bei diesen Prinzipien der Gedanke, dass vorläufig am Bestehenden nichts geändert werden muss. Zwar versteht sich KANBAN als eine evolutionäre Form des Changemanagements, aber die Veränderungen ergeben sich nach und nach aus der konkreten Anwendung des KANBAN-Prinzips. Die folgenden 6 Praktiken nach Anderson entfalten ihre Wirkung vor allem bei der Umsetzung der ersten Schritte mit KANBAN: Prinzip 1: Visualisierung der Arbeiten Häufig werden die einzelnen Prozessschritte der Wertschöpfungskette mit einem Whiteboard sichtbar gemacht. Dieses wird mit Post-it‘s zu einem KANBAN-Board gestaltet, auf dem die Spalten die einzelnen Stationen darstellen (siehe dazu die Abb. 3.14). Auf den Haftnotizzetteln (wahlweise auch Karteikarten) stehen die einzelnen Tasks, Features, User Stories und dergleichen, die im Laufe des Prozesses von links nach rechts auf dem KANBAN Board wandern. Prinzip 2: Begrenzung und Limitierung der Arbeiten Um einen gleichmäßigen Workflow zu gewährleisten, wird die Anzahl der Tickets (Work in Progress – WiP) begrenzt, die zur selben Zeit an einer Station bearbeitet werden dürfen. Wenn eine Station gerade an 3 Tickets arbeitet und diese Station auf 3 Tickets limitiert wurde, darf sie kein weiteres 4. Ticket annehmen, auch wenn die zuarbeitende Station ein weiteres liefern könnte. Dieses Vorgehen wird Pull-Prinzip genannt: Jede Station holt ihre Arbeit bei der Vorgängerstation ab, anstatt fertige Arbeit einfach an die nächste Station weiterzureichen. So hat jede Station auch die Chance, ihre Aufgaben abzuarbeiten.

Backlog

Bereit

Entwickeln doing

done

Abb. 3.14  KANBAN in der IT – das Board

Testen doing

done

Release

Fertig

3.4 Agile Methoden in der IT-Organisationsgestaltung

45

Prinzip 3: Steuerung des Arbeitsflusses Im gesamten KANBAN-Prozess werden einzelne Bereiche wie Warteschlangen, Zykluszeit und Durchsatz überprüft. So lässt sich feststellen, an welchen Stellen die Arbeit gut organisiert ist und wo eventuell Verbesserungen notwendig sind. Damit wird gleichzeitig auch die Verlässlichkeit im Arbeitsfluss erhöht und optimiert. Prinzip 4: Verdeutlichung und Prozessregeln Um zu gewährleisten, dass sämtliche Beteiligte von denselben Annahmen und Gesetzmäßigkeiten ausgehen, müssen alle Regeln festgelegt werden. Dazu gehören beispielsweise: Klärung, wer wann zieht. Unter welchen Bedingungen wird das nächste Ticket aus der Warteliste gezogen? Prinzip 5: Rückmeldung KANBAN ist ein flexibles Modell, daher werden beständig Überprüfungen durchgeführt und Rückmeldungen gegeben. Ziel von KANBAN ist es zu schauen, wo es zu Stauungen (bottlenecks) kommt – dafür wird ein Rückmeldungssystem eingeführt. Anhand von Feedbacks kann jede Station erkennen, wo es gerade hängt, wo vielleicht Unterstützung notwendig ist. Verbesserung Wie im vorherigen Punkt erläutert, sind Rückmeldungen ein wichtiger Bestandteil von KANBAN.  Die eingeführten Feedback-Mechanismen führen zu Verbesserungen, indem in manchen Stationen verschlankt oder ergänzt werden kann – je nach Rückstau bzw. Bedarf. Damit KANBAN erfolgreich eingesetzt werden kann, sollten folgende 3 Tipps berücksichtigt werden: • Es darf immer nur ein Projekt aktuell in Bearbeitung sein. • Es befinden sich nie mehr als 6 Projekte in Wartestellung. • Alltägliche Aufgaben haben auf dem Board nichts zu suchen. Die packen Sie in eine ganz normale To-do-Liste (KANBAN ist nicht für die tägliche Organisation gedacht).

3.4.3 Selbstorganisation und Holokratie in der IT 3.4.3.1 Definition und Ziele von Selbstorganisation Selbstorganisation und Holokratie werden hier in einem Zuge genannt und tatsächlich ist das Gleiche gemeint. Daneben existieren einige weitere Begriffe, die im Grunde Ähnliches meinen bzw. im Kern eines immer gemeinsam haben: Entscheidungen, und damit die Machtverteilung, finden nicht mehr von oben nach unten statt, sondern werden autonomisiert, d. h. die Entscheidungen werden dort getroffen, wo sie anfallen. Beispiele für Organisationsformen, die dazu gehören sind:

46

• • • • •

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

Agile Organisationen Demokratische Unternehmen Netzwerkorganisationen Holokratische Organisationen Selbstorganisierte Organisationen

Damit steht eines schon mal fest: Diese Form der Organisationen schafft Hierarchen fast vollständig ab. Abb.  3.15 zeigt deutlich den Unterschied zwischen der klassischen hierarchiegeprägten Organisation und einer holokratischen Organisation, die auf den Prinzipien der Selbstorganisation fußt. Der übergeordnete Kreis in einem holokratischen System entspricht der gesamten Arbeit, die in einer Organisation geleistet werden muss. Ein Sub-Kreis in diesem Kontext ist ein Bündel von artverwandter oder ähnlicher Arbeit und die Rolle als kleinster Kreis steht für denjenigen, der die Arbeit erfüllt. Es geht im holokratischen System um das Prinzip der Selbstorganisation. Mitarbeiter übernehmen dabei (Eigen-)Verantwortung und organisieren sich selbst. Viele IT-Organisationen haben sich schon auf den Weg gemacht und einige Ansätze von Selbstorganisation getestet. Und obwohl Entscheidungen immer autonom getroffen werden sollen, wird überall festgestellt: Selbstorganisation braucht auch Führung und damit Macht. Wenn man sich die Abb. 3.15 anschaut, dann könnte man meinen, dass es keine Hie­ rarchien mehr gibt und diese auch gar nicht mehr benötigt werden. Das stimmt so nicht. Was es nicht mehr gibt, ist Command & Control. Jedoch muss natürlich klar geregelt sein, wer wofür verantwortlich ist. Daher sind Mitarbeiter in selbstverwalteten Kreisen organisiert, in denen sie Führungsaufgaben übernehmen können. Jeder kann Ideen in den Kreis einbringen, zu dem sie oder er gehört. Funktionsführer (im nächsthöheren Kreis ernannt) und Delegierte (im unteren Kreis ernannte Personen) fungieren als Bindeglieder zwischen den Kreisen. Im System gibt es eindeutige Verant-

Übergeordneter Kreis CEO SubKreis

Oberes Management vs.

Mittleres Mgmt. Unteres Mgmt.

Rolle Abb. 3.15  Selbstorganisation im Überblick

Mitarbeiter

3.4 Agile Methoden in der IT-Organisationsgestaltung

47

wortlichkeiten und Entscheidungsbefugnisse. Eine bedeutende Investition z. B. muss ein Direktor des obersten Kreises genehmigen. Des Weiteren ist es wichtig zu verstehen, dass auch das Prinzip der Selbstorganisation nicht ohne Führungskräfte funktioniert. Wenn sich Führungskräfte aus der Gleichung herausnehmen, weil sie denken, dass die Änderung nur operative und mittlere Manager betrifft, dann ist Selbstorganisation zum Scheitern verurteilt. Vielmehr bringt das Modell eine Umverteilung von Macht und Autorität in der gesamten Organisation mit sich. Die Führungskraft agiert in einem solchen Konzept als Coach und Gestalter eines Rahmens. Auf dieser Basis können holokratische Systeme und Selbstorganisation für IT-Abteilungen durchaus interessante Ansätze für eine neue Zusammenarbeit liefern und in Zukunft insbesondere das schwierige Thema der Zusammenarbeit mit den Fachbereichen lösen.

3.4.4 Digital Labs 3.4.4.1 Definition und Ziele Die Intention und Strategie hinter einem Digital Lab besteht in der Schaffung eines geschützten Raumes zur Generierung und Umsetzung neuer, innovativer Ideen. Im Tagesgeschäft und laufenden Betrieb eines Unternehmens fänden diese nicht die benötigte Zuwendung, Beachtung und Zeit, um reifen und wachsen zu können. In Digital Labs kann frei von Hierarchien sowie Bürokratie und Prozessvorschriften entwickelt und umgesetzt werden. Die Digitalisierung macht keinen Halt vor Branchen oder bestehenden Geschäftsmodellen. Daher dienen die Digital Labs als Brutstätte für die Entwicklung neuer digitaler Geschäftsmodelle als Transformationsstätte von rein physischen Produkten hin zu smarten Lösungen. Die digitale Zukunft eines Unternehmens wird in solchen Labs vorgedacht und ausprobiert. Wenn es um die Begrifflichkeiten geht, dann darf bei Digital Labs nicht Halt gemacht werden. Oft werden diese auch Innovation Labs oder Digital bzw. Innovation Units genannt. Die Ziele eines solchen Labs oder einer solchen Unit sind immer sehr ähnlich: • Erstellung von Machbarkeitsanalysen (Proof of Concepts, sogenannten POCs), Entstehung von innovativen Ideen und Produkten. • Gemeinsame Evaluation von Anwendungsfällen (sogenannten Use Cases) zu digitalen Themen. • Realisierung von sogenannten Minimal Viable Products (MVPs), die dazu dienen, auf dem schnellstmöglichen Weg mit den maximal notwendigen Funktionen ein Produkt zur Marktreife zu führen. • Erarbeitung und Verprobung von digitalen Geschäftsmodellen. • Erarbeitung von IoT- und Big-Data-Lösungen.

48

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

• Unterstützung beim Aufbau eigener digitaler Einheiten (interne Abteilungen oder externe Ausgründungen). • Schaffen von Kontakten und einem Netzwerk mit Start-ups, Software- und Digitalexperten sowie Forschungseinrichtungen. • Aufbau von Methodenwissen bzw. Vorgehensmodellen, wie z.  B.  Design Thinking, SCRUM, Prototyping oder Business Model Canvas. • Schulungen und Weiterbildung zu digitalen Themen. Es gibt auch sehr spezifische Labs, welche sich auf Nischenthemen der Digitalisierung fokussieren. So z. B. die Data Labs oder Data Analytic Labs mit Schwerpunkt auf dem Gebiet Big Data. Dann gibt es IoT-Labs oder KI-Labs etc. Gemeinsam ist diesen immer die Nischenfokussierung. Neben den Digital Labs gibt es noch 3 weitere Formen von digitalen Initiativen, die für traditionelle Unternehmen sehr lukrativ sein können (siehe dazu die Abb. 3.16): • Das Headquarter oder Mutterunternehmen als „Company Builder“ • Die Rolle des Headquarters als „Inkubator“ • Die Nutzung des Konstruktes „Accelerator“ Die Abb. 3.16 zeigt die Definition und Aufgabe dieser 3 Digitalinitiativen und vor allem schafft es eine Abgrenzung untereinander und zum Digital Lab. Generell kann gesagt werden, dass bei Digital Labs und dem Company Builder immer neue Ideen generiert werden und dazu entweder ein eigenes Digital Lab aufgebaut oder ein eigenes Start-up gegründet wird (Company Builder). Das Digital Lab ist im Gegensatz zu den selbst gegründeten Start-ups meistens etwas näher am Mutterunternehmen angesiedelt. Der größte Unterschied besteht aber wohl darin, dass das Digital Lab einen großen, bunten Strauß an digitalen Themen und Projekten übernehmen kann, während das Start-up

Abb. 3.16  Unterschiedliche Formen von Labs und deren Abgrenzung

3.4 Agile Methoden in der IT-Organisationsgestaltung

49

als Unternehmen eine klare, eigene Unternehmensstrategie hat und selbstständig am Markt auftritt und agieren muss (ein klarer Auftrag). Das Digital Lab hingegen „hängt“ eher am Mutterunternehmen und schafft die Hülle und den Experimentierraum abseits der Hektik des Mutterunternehmens, um digitale Projekte und Produkte zu entwickeln. Wenn man also ein vollständig neues Geschäftsmodell nicht nur ausprobieren, sondern in den Markt bringen will und von dem Reifegrad und dem Kundenpotenzial überzeugt ist, dann macht ein eigenes Start-up Sinn und das Mutterunternehmen fungiert folgerichtig als Company Builder. Wenn dieses neue Geschäftsmodell erst mal getestet, verprobt und reifen soll, dann macht ein Digital Lab mehr Sinn. Dem gegenüber steht der Fokus auf schon bestehenden Ideen bei den Inkubator- und Accelerator-Modellen. In der Rolle als Inkubator investiert das Mutterunternehmen in bereits bestehende Start-ups und entwickelt diese weiter. Diese Beteiligungen in Start-ups sind im Regelfall gut durchdacht und passen sehr gut in die digitale Wachstumsstrategie des Mutterunternehmens. Wenn ein Investment mit größerem Risiko in eine Idee von Gründern investiert wird, dann spricht man von der Rolle des Accelerators. Hierbei geht es um Frühpaseninvestments (Seed Capital), bei dem sich das Mutterunternehmen quasi an der Weiterentwicklung der Gründungsidee beteiligt. Es hilft bei der Start-up-­Gründung, gibt den Gründern ein Netzwerk und alles für das Gedeihen und vor allem die Verifikation der Idee mit auf den Weg. Diese Beteiligung ist eher kurzfristiger Natur (3 bis maximal 6 Monate), wohingegen die Inkubator-Rolle eher langfristig ausgelegt ist (6–24 Monate). Bei der Rolle des Accelerators ist zu beachten, dass das Mutterunternehmen zumindest schon Erfahrung im digitalen Umfeld hat oder ehemalige Start-up-Manager jetzt in eigenen Führungskreisen sein Eigen nennen darf. Denn die Gründer brauchen in der Frühphase nicht nur Kapital, sondern vor allem Unterstützung zum Reifen und Verifizieren sowie – bei positivem Marktfeedback – auch Unterstützung beim Skalieren der Idee zu einem Produkt und einem wettbewerbsfähigen Start-up-Unternehmen.

3.4.4.2 Der Aufbau eines Digital Labs Egal ob es sich um ein Data Lab, Innovation oder IoT Lab oder um die Nutzung von künstlicher Intelligenz (KI) handelt: Ein Digital Lab ist eine sehr wertvolle Institution, um die Wettbewerbsstärke ihres Unternehmen im digitalen Zeitalter massiv zu stärken. Dieses Strategiepapier hat gezeigt, wie Sie aus den Fehlern der bisherigen Labs lernen können. Und auf Basis dieser Lernerfahrungen sollen die folgenden 4 Schritte helfen, den Weg zu einem erfolgreichen Aufbau eines Digital Lab zu planen: . Vision/Strategie und Ziele 1 2. Meilensteine 3. Personal und Standort 4. Verzahnung sicherstellen Die Abb. 3.17 zeigt anhand einer Checkliste die 4 Schritte inklusive eines Beispiels, welches sich auf die Branche der Landmaschinenhersteller bezieht.

50

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

Die Ausgangssituation Bisher war es so, dass die Landmaschinenhersteller ihre Maschinen fast ausnahmslos über Händler verkauft haben. Die Digitalisierung in Form von Plattformen bzw. Marktplätzen öffnet jetzt aber die Tür für die Hersteller, ihre Maschinen selbst zu verkaufen. Das hat 2 gewichtige Vorteile: Die Marge, die sonst der Händler bekam, verbleibt beim Hersteller. Der Hersteller hat einen Direktkontakt zu seinem Endkunden und kann viel besser erahnen, welche Optimierungen an seinem Produkt/Maschine notwendig sind. Darüber hinaus können Originalersatzteile als After-Sales-Lösung ebenfalls über einen solchen Marktplatz bzw. Plattform vertrieben werden. Da die Entwicklung und Bereitstellung einer solchen Plattform eine Herausforderung für die intern beteiligten Fachabteilungen, insbesondere die IT darstellt, die auch aktuell nicht die dafür passenden Ressourcen und Skills bereitstellen kann, hat man sich entschieden, ein Digital Lab für die Ausgestaltung des Geschäftsmodells, die Entwicklung und den Betrieb dieser Plattform zu gründen. Schritt 1 Die im ersten Schritt dargestellte Frage der Vision bzw. nach dem Sinn („Wozu machen wir das?“) bezieht sich also auf die „Schaffung einer eigenen Plattform zum Verkauf der Maschinen sowie von Originalersatzteilen“. In der Konkretisierung mit Zahlen, Daten und Fakten heißt das: Diese Plattform erhöht die Marge und damit das EBIT des Herstellers um 7,5 % durch die Tatsache, dass direkt verkauft wird und die bisherige Marge des Händlers selbst einbehalten wird. Natürlich will man seine Händler nicht komplett verprellen und daher öffnet man diese Plattform auch für die Händler; dann aber mit anderen Margen als bisher, denn die Plattform gehört dem Hersteller, der die Preise der Maschine als auch die Transaktionskosten bestimmen kann. Darüber hinaus soll das Digital Lab genutzt werden, um Kontakte zu Start-ups und Know-how-Aufbau in Sachen Digital Farming zu ­entwickeln. Dadurch soll die Wettbewerbsstärke des Unternehmens in der Zukunft gesichert werden, indem man zukünftige digitale Geschäftsmodelle entdeckt und umsetzen kann.

Abb. 3.17  Der Aufbau eines Digital Labs in 4 Schritten

3.4 Agile Methoden in der IT-Organisationsgestaltung

51

Schritt 2 Diese Vision kann nun auf folgende Ziele runtergebrochen werden (es sollten maximal 3–4 Ziele sein): Ziel 1: Aufbau des Digital Labs und Entwurf eines Geschäftsmodells für die Plattform inkl. Pricingmodellen und notwendigen Vertriebs- und Marketingaktivitäten sowie Make-­or-Buy-Strategie (welche Teile der Plattform werden selbst entwickelt und betrieben oder an Externe vergeben) Ziel 2: Konzeption und Entwicklung der Plattform nach agilen Methoden (je nach Make-­ or-­Buy-Strategie auch Verhandlungen mit externen Partnern und Vertragsgestaltung inkl. sauberer SLAs für den Betrieb der Plattform) Ziel 3: Go-Live inkl. Kundenbetreuung und Marketingaktionen sowie sauber geplante und abgestimmte Übergabe in das Headquarter zum Betrieb der Plattform (je nach Make-­ or-­Buy-Strategie intern das Headquarter oder extern) Ziel 4: Entwicklung von weiteren Geschäftsmodellen für das Lab zur Sicherung der Wettbewerbsstärke des Mutterunternehmens (z. B. Screening und Kontaktaufbau zu Start-­ ups aus der Branche, Aufbau von Know-how zu Digital Farming und angrenzenden Digitalthemen. Ableitung von digitalen Geschäftsmodellen für das Mutterunternehmen)

Schritt 3 Die Standortfrage geht in diesem Beispiel vor allem auf das Thema Personalrekrutierung ein, da dies in der Ausgangssituation der entscheidende Engpass war. Da das Digital Lab nicht nur für die Konzeption und Entwicklung der Plattform genutzt werden soll, sondern auch zur Vernetzung mit anderen Start-ups und dem Aufbau von Know-how in digitalen Themen (wie z. B. Digital Farming, Konnektivitätsdienste etc.) macht ein Standort in einem bestehenden Ökosystem von vielen AgriBusiness-Start-ups Sinn. Dennoch sollte das Digital Lab nicht zu weit vom Headquarter entfernt sein, da der Betrieb der Plattform vom Headquarter übernommen werden soll und somit eine enge Bindung zwischen beiden erfolgen muss. In die engere Auswahl ist der eher ländliche Bereich Ostwestfalen-Lippe (OWL) gekommen sowie Berlin. In puncto Personalrekrutierung sowie räumliche Nähe zum Headquarter gewinnt OWL, zumal dort auch die Start-up-Szene für das AgriBusiness durchaus sehenswert ist für den Aufbau von Netzwerken sowie Forschungen an aktuellen Themen rund um das Thema Digital Farming. Bei der Personalfrage selbst wurde intern die Vision und die Ziele des Digital Labs im Rahmen eines „Pitching Days“ vorgestellt. Jeder Mitarbeiter mit einer spannenden Idee und einem Business Case konnte seine Idee pitchen und die 3 Erstplatzierten bekamen ein Budget für die Umsetzung ihrer Idee im Digital Lab und wurden für 1 Jahr als Product Owner von ihrer eigentlichen Aufgabe freigestellt und in das Digital Lab entsandt. So wurde viel Aufmerksamkeit auf das Digital Lab gelenkt und ein interner Bewerbungsprozess gestartet, der viele interne Talente in das Digital Lab entsandte. Wichtig war dem Management, dass ein IT-Architekt sowie ein Manager aus dem Geschäftsleitungskreis

52

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

selbst in das Digital Lab geht und dort Verantwortung übernimmt. So brauchte es zum Start des Digital Labs nur 2 Stellen, die von extern rekrutiert wurden (ein Agile Coach und ein SCRUM Master, da diese Kenntnisse und Erfahrungen intern noch nicht vorhanden waren). Schritt 4 Die Einbindung und Verzahnung des neuen Digital Labs mit dem Headquarter ist ein wesentliches Erfolgskriterium. Schon durch die in Schritt 3 erfolgte interne Personalrekrutierung ist viel gewonnen. Denn die intern rekrutieren Digital Lab Mitarbeiter werden sich mit ihren „alten“ Kollegen eng austauschen und kennen vor allem die bestehende IT-­ Landschaft und deren Standards. So ist sichergestellt, dass nicht aneinander vorbei entwickelt wird und die Apps des Digital Labs in die IT-Architektur des Headquarters passen und dort nahtlos in den Betrieb eingebracht werden können. Wichtig ist es nicht nur auf die IT zu achten, sondern insbesondere Fachabteilungen wie den Service oder After-Sales einzubeziehen. Denn diese müssen im Rahmen des Betriebs später die Hotline für Endkunden sein, die ein Problem mit der Plattform haben. Dazu braucht es Planungen bzgl. eines Ticketsystems sowie Schichtplanungen für die Mitarbeiter. Enge Zusammenarbeit auch mit dem Einkauf sowie Legal bei Verhandlungen mit externen Partnern sind genauso wichtig und tragen zur engen Zusammenarbeit zwischen Headquarter und Digital Lab bei.

3.4.4.3 Drei wichtige Erfolgsfaktoren für ein Digital Lab Einbindung des Mutterunternehmens und enge Zusammenarbeit Die größte Hürde ist die zu große Abkopplung des Labs vom Mutterschiff. Die positiven Ergebnisse im Lab kommen im Mutterunternehmen gar nicht an bzw. können nicht adaptiert werden. Es findet eher eine Entfremdung statt und teilweise sogar Konkurrenzdenken. Das Ziel soll aber die Unterstützung des Mutterunternehmens durch digitale Produkte und Themen sein und nicht ein Wettbewerb. Die Abb. 3.18 zeigt die Unterschiede im Wirken und Denken zwischen einem Digital Lab und einem Mutterunternehmen. Die Schnittstelle beider „Welten“ ist die Kultur; denn, wenn sich beide annähern, dann geht das nur durch Neugierde und Zulassen von Andersartigkeit. Ein weiterer Erfolgsfaktor, damit sich Mutterunternehmen und Digital Lab nicht auseinanderleben bzw. gar nicht erst zusammenkommen, kann das Pitchen von Ideen sein. Abb. 3.19 zeigt beispielhaft, wie das Mutterunternehmen solche Pitching Days organisieren kann, damit beide Welten näher zusammengebracht werden können. Denn durch das gemeinsame Überlegen sowohl im Digital Lab als auch im Mutterunternehmen werden gemeinsame Ideen geboren, die dann über die Entwicklung bis zur Serienreife gemeinsam begleitet und entwickelt werden. Digitale Tools und Entwicklungen aus dem Lab müssen durch die Corporate IT betrieben werden können Das Schlimmste was passieren kann: Das Lab entwickelt gelungene Softwareprodukte, die die interne IT jedoch nicht betreiben und weiterentwickeln kann, weil einfach die

3.4 Agile Methoden in der IT-Organisationsgestaltung

53

Abb. 3.18  Digital Lab versus Mutterunternehmen

Abb. 3.19  Vorgehensweise: Pitchen von Ideen und Produktentwicklungen

Plattform oder das interne Wissen fehlt. Das führt zu viel Frust auf beiden Seiten. Daher muss der CIO des Headquarters gemeinsam mit den Lab-Verantwortlichen die gemeinsamen Plattformen, Programmiersprachen und Standards bzgl. Hardware und Software festlegen. Die IT sollte daher auch die digitale Infrastrukturplattform zur Verfügung stellen. Keine oder nur rudimentäre Kosten- und Zeitplanung sowie schlechtes Anforderungsmanagement Viele Themen oder Projekte werden im Lab einfach gestartet ohne tatsächliche Prüfung, inwieweit diese wirtschaftlich sind und dem Kunden oder der Zielgruppe einen wirklichen Nutzen bieten? Oft ist auch nicht klar, wer aus dem Management im Mutterunternehmen dahintersteht (Pate oder Auftraggeber fehlt). Einfache Regeln aus dem Projektmanage-

54

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

ment werden im Lab oft nicht gelebt. Darüber hinaus fehlen oft klare Anforderungen an die zu entwickelnde Software oder das Produkt. Die „Ausrede“, dass man das bei einem Minimum Viable Product (MVP) und im agilen Umfeld so nicht braucht, stimmt einfach nicht. All diese Tatsachen zusammen führen oft zu halb garen Produkten oder Ergebnissen und das Erwachen in der Realität ist leider oft groß.

3.4.5 Tipp aus der Praxis: Wann und wo machen agile Ansätze Sinn? Um die Frage nach dem Einsatz von agilen Methoden beantworten zu können, macht es Sinn, auf die unterschiedlichen „Bedürfnisse“ von IT-Systemen zu schauen. Gartner differenziert dabei 3 verschiedene Ebenen von IT-Systemen, wie in der Tab. 3.3 dargestellt. Auf Basis der 3 verschiedenen Ebenen von IT-Systemen wird sehr schnell deutlich, wann und wo agile Methoden wirklich Sinn machen und Effizienz in der Applikationsentwicklung schaffen. Eine gute Übersicht dazu liefert die Abb. 3.20. Auf Basis des eingesetzten IT-Systems wird differenziert, welche Art von Entwicklungsprozess, Budget- oder Change-Request-Management-Prozess eingesetzt werden sollte. Hier wird auch deutlich, dass bei modernen IT-Systemen (bei Gartner sind dies die „Systems of Innovation“) die agilen Methoden sinnvoll und nahezu unersetzlich sind. Wohingegen die Legacy-Systeme und relativ starre ERP-Systeme (bei Gartner die sogenannten „Systems of Record“) eher das althergebrachte Wasserfallmodell zum Erfolg führt. Wobei auch im Wasserfallmodell durchaus agile Ansätze wie Sprints eingesetzt werden können. Als abschließenden Tipp aus der Praxis möchte ich Ihnen gerne 2 Dinge ans Herz legen, die schnell helfen agil zu werden, ohne sofort alle möglichen Methoden und Best Practices einzuführen: Geschwindigkeit: Was hält Sie vom „Fertig-Werden“ ab? Was kann abgestellt werden, damit Sie konzentriert und produktiv an ihrem Thema arbeiten können? Wenn Sie merken, dass sie abgelenkt werden, sofort wieder in den Produktiv-Modus umschalten. Sie müssen immer das Ziel im Auge behalten und die Dinge einfach fertig kriegen. Konsequenz: Um den „Fertig-Werden-Modus“ durchzuhalten, brauchen Sie Konsequenz. Sie müssen andere Dinge und Projekte ablehnen. Sie müssen sich voll auf eine Sache konzentrieren können und damit andere Anforderer „verprellen“ bzw. auf später vertrösten. Sie müssen Meetings absagen und Telefonate „abwehren“ und das konsequent. Dann erreichen Sie ihr Ziel auf eine möglichst „agile“ Art und Weise.

3.5

CC

 ie Prozessorganisation als Schnittstelle zu D den Fachbereichen Die IT kann niemals alleine erfolgreich sein – Wie die Fachbereiche eng in die gemeinsame Arbeit eingebunden werden, zeigt die Prozessorganisation.

3.5 Die Prozessorganisation als Schnittstelle zu den Fachbereichen

55

Tab. 3.3  Die 3 Ebenen von IT-Systemen nach Gartner [7] Attribute Pace of Change

Systems of Record Slow, infrequent and incremental. Changes every six to 12 months

Lifetime Planning Horizon Governance Model Stakeholders/ Ownership

Ten-plus years Seven-plus years

Architecture

Formal and global

Systems of Differentiation Moderate and more frequent. Configurability is key. Changes every three to six months One to three years One to two years

Responsive and businessled High business executive High business executive engagement; engagement, but driven by lines of business. alignment between Moderate end-user business and IT strategy. Low end-user engagement, with the business engaging on hot engagement, and formal handover from spots, and IT filling the gaps the business to IT Large, modular design Service-oriented dominated by formal, architecture (SOA) and cloud-based, with a mix of upfront blueprinting service consumers and phase producers

Systems of Innovation Rapid, very frequent and ad hoc. „Throwaway“ customization. Changes weekly, sometimes daily Zero to 12 months Up to six months Flexible and ad hoc Moderate business executive engagement, with some sponsored and under-theradar; tactical. High end-user engagement, often through business users or even circumventing IT Lightweight and emergent, predominantly service consumers. Mobile and cloud-dominate

Abb. 3.20  Je nach System unterschiedliche organisatorische Vorgehensweisen

Damit die IT-Organisation wirklich lieferfähig ist, muss die Schnittstelle zu den Fachbereichen klar geregelt sein. Dies geschieht idealerweise auf der Ebene der Prozesse und damit im Rahmen einer Prozessorganisation.

56

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

Des Weiteren muss in dieser Schnittstelle klar sein, wer welche Verantwortungen übernimmt. Dazu gehören die Rollen der Prozessverantwortlichen und -experten sowie Key-­ User auf Fachbereichsseite sowie deren Pendants auf der IT-Seite. Diese werden im Folgenden ausführlich beschrieben.

3.5.1 D  ie Frage nach der Verantwortlichkeit einer Prozessorganisation Es sei an dieser Stelle auch angemerkt, dass eine solche Prozessorganisation nicht von den Fachbereichen gegründet oder ins Leben gerufen wird, da diese nur ihre Prozesse betrachten und damit nie der Gesamtblick auf alle Prozesse des Unternehmens entsteht. Die ­Geschäftsführung bzw. der Vorstand sind meistens nicht auf Prozessebene unterwegs, ­sondern eher im funktionalen Rahmen der reinen Aufbauorganisation, sprich des Organigramms. Dann gibt es in produzierenden Unternehmen noch das Quality-­Management, welches nach diversen Normen und Standards, z. B. nach ISO 9001 fordert, dass jeder Prozess geplant, gesteuert, überwacht und verbessert werden muss. Das ist aber eher der Blick auf die Richtigkeit der Prozesse im Sinne von Audits und nicht der Blick auf die wirkliche Effizienz, die hinterher in IT-Systemen abgebildet werden muss. Daher obliegt es meistens dem CIO gemeinsam mit der Geschäftsführung eine solche Prozessorganisation ins Leben zu rufen. Gerade bei anstehenden ERP-Einführungen oder anderen Großprojekten ist die Prozessorganisation das ideale Bindeglied zwischen IT und Fachbereich. Gerade auch um deutlich zu machen, dass solche Projekte keine IT-Projekte sind, sondern Projekte des gesamten Unternehmens, in dem die Prozesse optimiert werden.

3.5.2 Die 3 Ebenen des Anforderungsmanagements Bevor genau erläutert wird, wie eine Prozessorganisation aufgebaut wird, macht es Sinn sich genauer anzuschauen, wofür die Rollen der Prozessorganisation verantwortlich sind und was Ihre Aufgaben sind. Es gibt 3 Ebenen des Anforderungsmanagementprozesses, die in Abb. 3.21 dargestellt sind: • Strategisches Projektportfoliomanagement: Auf dieser Ebene werden zwischen dem CIO und dem jeweiligen Process-Owner große Projekte mit mehr als 10 Personentage (dies kann je nach Unternehmen individuell angepasst werden) priorisiert und nach Bedarf freigegeben. Diese Ebene ist wichtig, da hier bei jedem Projekt auf die Einhaltung der Prozessstandards als auch der Gruppenstrategie geachtet wird. Sinnvollerweise findet diese Abstimmung regelmäßig in einem fest definiertem Rahmen und Gremium statt. • Anforderungs- und Prozessmanagement: Dies ist der typische Change-Request-­ Management(CR-Management)-Zyklus, welcher auf Ebene der Prozessexperten auf Fachbereichsseite und des Anforderungs- oder Demand-Managers auf IT-Seite stattfindet. Es geht primär um die gemeinsame Erstellung von Lastenheften und Konzeptionen zu Prozessveränderungen und -optimierungen im Tagesgeschäft. Darüber hinaus

3.5 Die Prozessorganisation als Schnittstelle zu den Fachbereichen

57

Abb. 3.21  Die 3 Ebenen des Anforderungsmanagementprozesses

findet hier der 2nd Level Support statt. Das typische Gremium für diesen Austausch ist das regelmäßig stattfindende CR-Management-Board. • Ticketmanagement: Dies ist die Ebene, auf der die Key-User auf Fachbereichsseite mit den IT-Experten zusammenarbeiten. Die Key-User haben die Aufgabe, Fehler in den IT-Systemen zu erkennen, zu formulieren und in das Ticketsystem einzugeben. Auf IT-Seite steht das Thema 1st Level Support, Ticketmanagement sowie das Durchführen von Funktionstests, um die behobenen Fehler und Probleme in den IT-Systemen erneut bereitzustellen. Zum Rollenprofil des Key-Users gehört auch das Thema Schulung und Training der ihm zugeordneten User. Mit diesem Konstrukt wird die Grundlage geschaffen für die Etablierung einer Prozessorganisation, die als Schnittstelle zwischen den Fachbereichen und der IT dient.

3.5.3 Wichtige Rollen in der Prozessorganisation Bevor die Prozessorganisation endgültig aufgebaut wird, müssen zunächst die Rollen geklärt werden. Die beiden Abbildungen Abb. 3.22 sowie Abb. 3.23 zeigen die insgesamt 6 Rollen, die für eine funktionierende Prozessorganisation nötig sind; dies sind im Einzelnen: Auf Fachbereichsebene: • • • •

Key-User Prozessexperte Prozessverantwortlicher Globaler Prozessverantwortlicher (bei internationalen Unternehmen) Auf IT-Ebene:

• Demand-Manager bzw. Account-Manager • IT-Experte

58

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

Abb. 3.22  Die Rollen in der Prozessorganisation Teil I

Abb. 3.23  Die Rollen in der Prozessorganisation Teil II

Die Rollendarstellungen enthalten bewusst jeweils das Thema „Übergabepunkte“ sowie „Out of Scope“. Dies dient dazu, dass klar geregelt ist, wer welche Themen übernimmt oder auch nicht. Darüber hinaus sei erwähnt, dass die Rolle des globalen Prozessverantwortlichen nur in Unternehmen zu finden ist, die international agieren und im Ausland nennenswerte Produktions- oder Vertriebsstandorte haben. Denn in diesem Fall macht es Sinn, dass eine Rolle die globale Einhaltung von Standards bzgl. Prozesse und Strategie übernimmt. Pro Standort, Gesellschaft oder Land gibt es dann für den jeweiligen Prozess einen eigenen Prozessverantwortlichen, der allerdings auch in Personalunion globaler Prozessverantwortlicher sein kann.

3.5 Die Prozessorganisation als Schnittstelle zu den Fachbereichen

59

3.5.4 Aufbau einer Prozessorganisation Der Aufbau einer Prozessorganisation kann in 3 Schritten erfolgen.

3.5.4.1 Schritt 1: Ende-zu-Ende-Prozesse definieren Eine gute Prozessorganisation orientiert sich idealerweise an sogenannten Ende-zu-Ende-­ Prozessen. Diese haben den Vorteil, dass tatsächlich abteilungs- und bereichsübergreifend gedacht und gehandelt wird. Dies bedeutet, dass z.  B. in dem End-to-End-Prozess „Bestellung-­zu-Lieferung“ („Order-to-Ship“) die Bereiche Vertrieb, Produktion und Logistik gleichermaßen an den Prozess beteiligt sind. Daher sollte es vermieden werden, die oftmals typische Aufbauorganisation für eine Prozessorganisation zu nutzen. Eine Übersicht über typische Ende-zu-Ende-Prozesse finden Sie mit einem Beispiel für Mehrwerte in einem ERP-Projekt versehen in Abb. 3.24. Die Aufgabe besteht jetzt also darin, die für Ihr Unternehmen wesentlichen Ende-­zu-­ Ende-Prozesse zu definieren und diese mit der Geschäftsführung und den Fachbereichsleitern abzustimmen. In einem produzierenden Unternehmen kann dies beispielsweise wie in Tab.  3.4 aussehen: 3.5.4.2 Schritt 2: Die Rollen verteilen Jetzt geht es darum, die entsprechenden Rollen wie in Abschn. 3.5.2 dargestellt, den entsprechenden Personen pro Ende-zu-Ende-Prozess zuzuordnen (siehe Abb. 3.25). Es sind folgende Besonderheiten zu beachten: • Nicht überall wird eine Aufteilung bei der Prozessverantwortung benötigt. Und diese Aufteilung kann unterschiedlich sein. Beispielsweise im Ende-zu-Ende Prozess P2S (Plan to Ship) macht es Sinn, nach Werken aufzuteilen. Hingegen bei Finanz- und Personalprozessen genauso wie beim Vertrieb nach Regionen (in diesem Beispiel die Regionen Europa, Amerika und Asien). Die Prozesse D2D und S2P brauchen keine Aufteilung, da diese zentral aus dem Headquarter geführt werden. • Global Process Owner und Process Owner sind zumindest für eine Region oftmals dieselben (beispielsweise ist der deutsche Process Owner auch der global verantwortliche Process Owner). • Bei den Process Experts kann sich noch einmal eine Unterteilung ergeben. Diese Granularität macht beispielsweise bei der Aufteilung nach Hallen Sinn, wenn in den Hallen oder Werken unterschiedliche Produkte mit unterschiedlichen Prozessen gefertigt werden. • Auf Ebene des IT-Demand-Managers wird dann oftmals nicht mehr nach Prozessen differenziert, sondern es erfolgt eine Zuordnung der Prozesse zu den dafür notwendigen IT-Systemen. So sind dies in dem Prozess P2S (Plan to Ship) z. B. die SAP Module PP (Production Planning), eWM (extendes Warehouse Management) sowie ein MES. D ­ amit wird dann der Prozess offiziell mit dem IT-System verheiratet.

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

Abb. 3.24  End-to-End-Prozesse im Überblick (exemplarisch)

60

3.5 Die Prozessorganisation als Schnittstelle zu den Fachbereichen

61

Tab. 3.4  Ende-zu-Ende-Prozesse. (Beispiel für ein produzierendes Unternehmen) Ende-zu-Ende-­ Prozess P2S: Plan to Ship D2D: Design to Deploy

S2P: Source to Pay C2C: Contract to Cash

R2R: Record to Report H2R: Hire to Retire

Beschreibung Von der initialen Bedarfsplanung bis zum Versand an den Kunden. Beteiligte Bereiche: Vertrieb/Disposition, Produktion, Supply Chain, Logistik, QS Von der Erstanfrage bis zur Produktionsreife des Produkts (inkl. Änderungsdienst, Bemusterung und Ausphasen des Produktes). Beteiligte Bereiche: Technische Entwicklung/Projektierung, Produktionsplanung, QM Einkaufsprozesse von der Beschaffungsstrategie bis zur Zahlung der Lieferantenrechnung. Beteiligte Bereiche: Einkauf, Finanzen, Controlling Verkaufsprozesse von der Vertriebsstrategie bis zum Zahlungseingang und dem Handling von Retouren. Beteiligte Bereiche: Vertrieb, Finanzen, Controlling, Supply-Chain-­ Management, QM/QS Finanzprozesse und Cash-Management von der Budgetierung/Planung bis zur Bilanzierung und Reporting Personalprozesse von der Personaleinstellung bis zum Ausscheiden. Beteiligte Bereiche: Personal, Marketing, Finanzen

3.5.4.3 Schritt 3: Die IT-Organisation und die Prozessorganisation „verheiraten“ Nachdem die Rollen klar definiert sind, geht es an die Verknüpfung der IT-Organisation mit der Prozessorganisation. Wie in Abb.  3.26 dargestellt, ist die IT-Organisation auf Ebene des Bereiches „PLAN“ mit den End-to-End-Prozessverantwortlichen auf Fachbereichsebene verknüpft. Diese IT-Teams aus dem „PLAN“ wiederum sind mit dem BUILD-­ Team verbunden, die die jeweils für den End-to-End-Prozess notwendigen IT-Systeme beinhalten und verantworten. Davon abgekapselt ist der Bereich „RUN“ in Form von „Global IT Operations“, da diese unabhängig von den End-to-End-Prozessen für das gesamte Unternehmen erbracht werden müssen. Die Aufgabenverteilung sieht beispielhaft bei einer Anforderung bzw. Prozessveränderung im Fachbereich folgendermaßen aus: Auf Ebene des Fachbereichs werden in der Prozessorganisation die Prozessveränderungen festgestellt, diese dann mit dem PLAN-Team aus der IT besprochen. Die entwerfen daraus gemeinsam mit dem Build-Kollegen und den Prozessverantwortlichen ein Lastenheft oder eine Konzeption (oder nach agiler Vorgehensweise eine User-Story). Im Build-­ Team wird diese dann entwickelt und von den Prozessverantwortlichen funktional getestet. Bei Freigabe vom Prozessverantwortlichen wird die Funktion im entsprechenden IT-System von RUN (Global IT Operations) betrieben. Dies ist eine vereinfachte Prozessdarstellung, aber für die generelle Darstellung des Ablaufs zwischen IT- und Prozessorganisation soll dies zunächst reichen.

Abb. 3.25  Aufbau einer Prozessorganisation (exemplarisch anhand eines produzierenden Unternehmens)

62 3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

3.5 Die Prozessorganisation als Schnittstelle zu den Fachbereichen

63

In der beispielhaften Abb. 3.26 sieht die Zuordnung und Verknüpfung bei den 6 Endto-­End-Prozessen folgendermaßen aus: • Der End-to-End-Prozess P2S (Plan-to-Ship) ist verknüpft mit dem Team „Logistik und Produktion“ aufseiten der IT und dann wiederum mit dem Team Build, die für diesen End-to-End-Prozess die benötigen IT-Systeme verantwortet. P2S ist ein umfangreicher Prozessblock, sodass sich hier auch 4 IT-Systeme im Minimum wiederfinden. In diesem Beispiel sind das die IT-Systeme ERP, Q-Systeme, ein LVS ­(Lagerverwaltungssystem) sowie ein MES (Manufacturing-Execution-System), die alle die Prozesse von P2S unterstützen. • Eine Besonderheit bilden die End-to-End-Prozesse S2P (Source-to-Pay), R2R (Record-­ to-­Report) sowie H2R (Hire-to-Retire). Denn diese sind alle einem Team in der IT zugeordnet mit der Überschrift „Shared Services“. Der Hintergrund dafür liegt in gemeinsamen Systembenutzungen, denn diese Prozesse sind typische ERP-Prozesse, die sich alle im gleichen System wiederfinden. Daher sind diese IT-seitig „zusammengefasst“ worden. Es ist natürlich trotzdem wichtig, dass im PLAN-Team der IT die Kompetenz für alle 3 End-to-End-Prozesse vorhanden ist, sodass die Kommunikation und Konzepterstellung reibungslos verlaufen kann. • Der End-to-End-Prozess D2D (Design-to-Deploy) ist auf IT- bzw. PLAN-Seite mit dem Team „Technische Entwicklung/R&D“ verknüpft, welche dann im Build Bereich die dafür notwendigen IT-Systeme wie ein PLM oder CAD-System verantworten. • Der End-to-End-Prozess C2C (Contract to Cash) ist auf Plan-Seite mit „Marketing/ Vertrieb“ verknüpft, um dort die IT-Systeme im Build Part CRM und ERP und Portale zu betreuen.

Abb. 3.26  Die IT- und Prozessorganisation „verheiraten“

64

3  Die Aufbauorganisation der IT – Verschiedene Modelle im pro und contra

3.5.4.4 Schritt 4: Die Prozessorganisation offiziell einführen Damit die Prozessorganisation ihre volle Kraft entfalten kann, muss zunächst die Verabschiedung durch die Geschäftsführung erfolgen. Und dann ist vor allem die Kommunikation und Schulung wichtig. Dabei geht es primär darum, alle Process Owner sowie Experts, Key-User und IT-­ Demand-­Manager in ihren neuen Rollen mit den folgenden Inhalten zu schulen: • • • •

Was sind die Aufgaben und Verantwortlichkeiten? Welche Schnittstellen habe ich zu den anderen Rollen? Wie läuft das „Zusammenspiel“ zwischen den Rollen ab (siehe Abschn. 3.5.4.2) Wie viel Zeit benötigt die Rolle (in welcher Projektphase)?

Gerade die Frage wie viel Zeit eine solche Rolle benötigt ist für die Führungskräfte sehr wichtig. Denn in Projekten, wie z. B. bei einer ERP-Einführung, sind Prozessverantwortliche je nach Projektphase zu nahezu 100  % ausgelastet. Um bei dem Beispiel ERP-­ Einführung zu bleiben: In einem größeren mittelständischen Unternehmen mit ca. 2000 Mitarbeitern und einem Greenfield-Ansatz kann eine solche ERP-Einführung schon mal 5 Jahre dauern. In diesen 5 Jahren ist nicht jeder Prozessexperte zu 100 % mit dem ERP-Projekt ausgelastet, aber in Spitzenphasen, wie vor dem Go-Live, bei Schulungen und Trainings sowie der Business-Blueprint-Phase, aber sicherlich schon. Dies ist vielen Führungskräften nicht klar und daher sind solche Projekte auch oft sehr zäh in ihrer Abarbeitung. Im Tagesgeschäft, wenn keine großen Projekte anstehen, ist ein Prozessexperte hauptsächlich mit Prozessveränderungen beschäftigt, die dann in den IT-Systemen auf üblichem CR-Weg (als Change Request) eingeführt werden. Dies sollte Routine sein und nimmt je nach Prozessoptimierungspotenzial zwischen 20 % und 50 % seiner Zeit in Anspruch.

3.6

Resümee und Plädoyer für eine moderne IT-Organisation

Wenn es um das Thema der Gestaltung einer IT-Organisation geht, gelten die 3 in Anlehnung an Malik [8] formulierten Fragen, die als Handlungsmaxime für die Geschäftsführung und den CIO bei der (Um-)Gestaltung einer IT-Organisation unbedingt zu berücksichtigen sind: 1. Wie muss eine IT-Organisation gestaltet sein, damit das, wofür der Kunde uns bezahlt, im Zentrum der Aufmerksamkeit steht und von dort nicht wieder verschwinden kann? 2. Wie muss eine IT-Organisation gestaltet sein, damit das, wofür wir unsere IT-­Mitarbeiter bezahlen, von diesen auch wirklich getan werden kann? 3. Wie muss eine IT-Organisation gestaltet sein, damit das, wofür der CIO und das IT-­ Management bezahlt werden, von diesen auch wirklich getan werden kann?

Literatur

65

Der Punkt 1 hört sich logisch und leicht an und natürlich stehen die Fachbereiche im Fokus. Man ist als IT ja zumindest Dienstleister, wenn man modern aufgestellt ist. Aber es ist gerade für eine IT-Organisation oftmals sehr schwer zu erkennen, wofür der Kunde die IT bezahlt. Zunächst stellt sich die Frage: „Wer ist eigentlich genau unser Kunde?“. Ist es das Topmanagement im Sinne der Geschäftsführung oder des Vorstandes, ist es der Eigentümer oder Gesellschafter des Unternehmens oder sind es die Fachbereiche und vielleicht sogar die Endkunden? Allein die Beantwortung dieser Frage ist aber schon sehr wichtig, denn zwischen all den genannten möglichen Kunden gibt es mit sehr hoher Wahrscheinlichkeit sehr unterschiedliche Auffassungen über eine „gute“ oder die „richtige“ IT. Die IT ist meistens nicht als eigenständige Firma in Form z. B. einer GmbH ausgegliedert, sondern eine interne Organisation, die ein Budget von der Geschäftsführung bekommt und für die diversen IT-Projekte sollte es idealerweise immer einen Auftraggeber und Sponsor geben, der das Projekt bezahlt. Dieser ist meistens aus dem Fachbereich. Zum Teil wird die IT zum Produkt, ist also beispielsweise auch im Auto integriert und daher für den Endkunden wichtig. Das sind wieder ganz andere Ansprüche als bei internen Kunden. Es ist also sehr schwer, all diese unterschiedlichen Interessen und Absichten der möglichen Kunden unter einen Hut zu bekommen. Daher: Gerade in Bezug auf den dritten Punkt, muss sehr klar von der Geschäftsführung oder dem Vorstand definiert werden, wofür die IT und der CIO stehen. Es ist wichtig, dass die Organisation so gestaltet ist, dass der CIO und das IT-Management nicht im Tagesgeschäft untergehen, sondern wirklich mit Blick aus der Vogelperspektive die IT weiterentwickeln können. Dies wird in diesem Buch ausführlich in Abschn. 4.4.9 dargestellt, in dem die Rollenfindung der IT und des CIOs im Unternehmen beschrieben wird.

Literatur 1. Zarnekow, Brenner, Grohmann: Informationsmanagement: Konzepte und Strategien für die Praxis, 1. Auflage, dpunkt.Verlag, 2004. 2. Zarnekow, Brenner, Pilgram: Integriertes Informationsmanagement, 1. Auflager, Springer, 2005. 3. Urbach, Ahlemann: (2017). Die IT-Organisation im Wandel: Implikationen der Digitalisierung für das IT-Management. HMD Praxis der Wirtschaftsinformatik. 54. 300–312. 4. Drucker, Peter F.: „Management’s New Paradigm“, http://www.mit.edu/~mbarker/ideas/drucker. html, MIT, abgerufen am 30.12.2019. 5. Ellermann, Horst: „BMW-CIO hält Bimodal IT für einen Irrweg“, abgerufen am 28.12.2019, https://www.cio.de/a/bmw-cio-haelt-bimodal-it-fuer-einen-irrweg,3562374 6. Anderson, David J.: „Kanban: Evolutionäres Change Management für IT-Organisationen“, 1. Auflage, dpunkt, 2011. 7. Gartner: Mary Mesaglio, Matthew Hotel: „Pace-Layered Application Strategy and IT Organizational Design: How to Structure the Application Team for Success“, https://www.gartner.com/binaries/content/assets/events/keywords/applications/apn30/pace-layered-applications-research-report.pdf, abgerufen am 07.01.2020. 8. Malik, Fredmund: Führen Leisten Leben, 6. Auflage, Campus Verlag, 2006.

4

Die Ablauforganisation der IT – Welche IT-­ Prozesse und Strukturen braucht eine moderne und schlanke IT-Organisation der Zukunft?

Zusammenfassung

Im Rahmen der Ablauforganisation einer IT geht es um die Frage: „Was ist wann in welcher Reihenfolge zu tun?“. Es geht um die internen Abläufe in der IT, also die IT-Prozesse.

4.1

I T-Governance als Rahmenwerk für die Ablauforganisation der IT

In diesem Punkt kommt man automatisch zum Thema „IT-Governance“. Die IT-­ Governance beschreibt nämlich die Prozesse und Organisationsstrukturen, die sicherstellen, dass die IT die Unternehmensstrategie und -ziele unterstützt. (in Anlehnung an [1]). In diesem Zusammenhang sind 2 Ziele für die IT-Governance wichtig: • Das Schaffen von Unternehmenswert • das Minimieren von IT-Risiken Um diese Ziele zu erreichen, setzt die IT-Governance dabei auf die folgenden, mittlerweile standardisierten und international akzeptierten Rahmenwerke auf: • Standard der Corporate Governance: COSO, ISO/IEC 38500:2008 • Übergeordneter Standard und Verbindung zur Corporate Governance: CobiT (Control Objectives for Information and related Technology) • Umsetzung von IT-Service-Management: ISO 20000, ITIL (Information Technology Infrastructure Library) • Informationssicherheit: ISO/IEC 2700 x und IT-Grundschutz-Kataloge © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 V. Johanning, Organisation und Führung der IT, https://doi.org/10.1007/978-3-658-12008-5_4

67

68

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

• Projektmanagement: PMBOK, ICB und PRINCE2 • Architektur: TOGAF • Systementwicklung: TickIT und CMMI Für die Ausgestaltung einer IT-Ablauforganisation sind im Wesentlichen zwei Rahmenwerke von größerer Bedeutung. Dies sind CobiT und ITIL. Diese werden daher im Folgenden näher vorgestellt und auf praktische Nutzbarkeit untersucht.

4.2

 berblick zu den gängigen Rahmenwerken für die Ü IT-­Ablauforganisation

4.2.1 C  OBIT als ein mögliches Referenzmodell für die IT-­Ablauforganisation 4.2.1.1 Definition und Ziel von COBIT COBIT war bis zur Version 4.1 eine Abkürzung für „Control Objectives for Information and Related Technology“. In der aktuellen Version 5.0 wird COBIT nur noch als Akronym verwendet. Herausgeber und Entwickler dieses Rahmenwerkes COBIT ist der internationale Verband der IT-Prüfer mit Namen ISACA („Information Systems Audit and Control Association“). In der ursprünglichen Version von 1996 war es gedacht als ein Werkzeug für standardisierte IT-Prüfungen und IT-Audits. Darüber hinaus wird es als ein Modell für die Sicherstellung der Einhaltung gesetzlicher Anforderungen, der sogenannten Compliance, genutzt. Mittlerweile hat es sich zumindest in großen Teilen auch zu einem weit verbreiteten Standard in Großunternehmen entwickelt. Dort dient es vornehmlich weiterhin der Sicherstellung von Compliance-Regelungen. Darüber hinaus dient es oftmals als Bindeglied zwischen IT-spezifischen Rahmenwerken wie ITIL und dem Modell für die generelle Einhaltung einer Corporate Governance COSO. 4.2.1.2 Der Aufbau und die Funktionsweise von COBIT Laut ISACA [1] sind die 5 grundlegenden Prinzipien für die Governance und das Management der Unternehmens-IT wie folgt (siehe auch Abb. 4.1): • • • • •

Erfüllung der Anforderungen der Anspruchsgruppen Abdeckung des gesamten Unternehmens Anwendung eines einheitlichen, integrierten Rahmenwerks Ermöglichung eines ganzheitlichen Ansatzes Unterscheidung zwischen Governance und Management

4.2  Überblick zu den gängigen Rahmenwerken für die IT-Ablauforganisation

69

Abb. 4.1  COBIT 5 Prinzipien

Das COBIT 5-Prozessreferenzmodell definiert 37  Prozesse, welche in 5 Domänen gruppiert sind, davon 1 Governance-Domäne (EDM) und 4 Management-Domänen (APO, BAI, DSS und MEA), auch als PBRM (Plan, Build, Run, Monitor) bezeichnet. Diese Prozesse können etwa den 26 Prozessen aus ITIL 2011 gegenübergestellt werden, welche in die 5 Module Service Strategy (SS), Service Design (SD), Service ­Transition (ST), Service Operation (SO) und Continual Service Improvement (CSI) gruppiert sind [2]. Die 37 COBIT 5 Prozesse sind in Abb. 4.2 als „Prozesse für die Governance der Unternehmens-­IT“ abgebildet und gestalten sich wie folgt [1]: • EDM  – Evaluieren, Vorgeben und Überwachen (englisch: „Evaluate, Direct and Monitor“) –– EDM01 Sicherstellen der Einrichtung und Pflege des Governance-Rahmenwerks –– EDM02 Sicherstellen der Lieferung von Wertbeiträgen –– EDM03 Sicherstellen der Risiko-Optimierung –– EDM04 Sicherstellen der Ressourcenoptimierung –– EDM05 Sicherstellen der Transparenz gegenüber Anspruchsgruppen • APO – Anpassen, Planen und Organisieren (englisch: „Align, Plan and Organise“) –– APO01 Managen des IT-Management-Rahmenwerks –– APO02 Managen der Strategie –– APO03 Managen der Unternehmensarchitektur –– APO04 Managen von Innovationen

70

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

Abb. 4.2  Prozesse für die Governance der Unternehmens-IT

–– APO05 Managen des Portfolios –– APO06 Managen von Budget und Kosten –– APO07 Managen des Personals –– APO08 Managen von Beziehungen –– APO09 Managen von Servicevereinbarungen –– APO10 Managen von Lieferanten –– APO11 Managen der Qualität –– APO12 Managen von Risiko –– APO13 Managen der Sicherheit • BAI – Aufbauen, Beschaffen und Implementieren (englisch: „Build, Acquire and Implement“) –– BAI01 Managen von Programmen und Projekten –– BAI02 Managen der Definition von Anforderungen –– BAI03 Managen von Lösungsidentifizierung und Lösungsbau –– BAI04 Managen von Verfügbarkeit und Kapazität –– BAI05 Managen der Ermöglichung organisatorischer Veränderungen –– BAI06 Managen von Änderungen –– BAI07 Managen der Abnahme und Überführung von Änderungen –– BAI08 Managen von Wissen

4.2  Überblick zu den gängigen Rahmenwerken für die IT-Ablauforganisation

71

–– BAI09 Managen von Betriebsmitteln –– BAI10 Managen der Konfiguration • DSS  – Bereitstellen, Betreiben und Unterstützen (englisch: „Deliver, Service and Support“) –– DSS01 Managen des Betriebs –– DSS02 Managen von Serviceanfragen und Störungen –– DSS03 Managen von Problemen –– DSS04 Managen der Kontinuität –– DSS05 Managen von Sicherheitsservices –– DSS06 Managen von Geschäftsprozesskontrollen • MEA  – Überwachen, Evaluieren und Beurteilen (englisch: „Monitor, Evaluate and Assess“) –– MEA01 Überwachen, Evaluieren und Beurteilen von Leistung und Konformität –– MEA02 Überwachen, Evaluieren und Beurteilen des internen Kontrollsystems –– MEA03 Überwachen, Evaluieren und Beurteilen der Compliance mit externen Anforderungen

4.2.2 I TIL als Rahmenwerk zur Umsetzung von IT-Service Management Standards 4.2.2.1 Definition und Ziel von ITIL ITIL ist die Abkürzung für „Information Technology Infrastructure Library“ und beinhaltet eine Sammlung vordefinierter Prozesse sowie Funktionen und Rollen für das IT-­ Service-­Management. Es hat sich zu einem Quasi-Standard für die Prozessgestaltung der IT-Operations und Infrastruktur-Abteilungen von mittelständischen Unternehmen und Konzernen etabliert. ITIL wurde in den 1980er-Jahren von der Central Computing and Telecommunications Agency (CCTA), bis 2010 Office of Government Commerce (OGC) und nun Cabinet Office, Teil des Her Majesty’s Government (HMG), einer Regierungsbehörde in Großbritannien, entwickelt. In der aktuellen Fassung ist ITIL in der Version 4 am 18.02.2019 veröffentlich worden. Seit 2014 ist der Herausgeber und Eigentümer des kompletten ITIL Frameworks die Firma AXELOS. AXELOS Ltd. ist ein Joint Venture, welches von der Regierung des Vereinigten Königreichs und Capita gegründet wurde, um nach bewährten Verfahren Qualifikationen zu entwickeln, zu verwalten und anzuwenden, die früher im Besitz des Office of Government Commerce waren. Es tritt unter dem Brand „AXELOS – Global Best Practice Solutions“ unter www.axelos.com auf. AXELOS ist ebenso Eigentümer von PRINCE2, eines ebenfalls in IT-Kreisen sehr bekannten Standards für IT-Projektmanagement.

72

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

4.2.2.2 Übersicht über die Management-Praktiken von ITIL Die aktuelle Version ITIL v4 beinhaltet 4 Dimensionen des Service-Managements sowie 34 sogenannte Management-Practices. Für die Betrachtung in diesem Buch bzgl. der IT-Ablauforganisation sind die 34  Management-Practices von großem Interesse. Diese sind in 3 Bereiche (Allgemeine Management-Praktiken, Service-Management-Praktiken sowie „Technische Management-Praktiken“) gegliedert und sehen nach AXELOS wie folgt aus [3]: Allgemeine Management-Praktiken • Strategy-Management • Portfoliomanagement • Architecture-Management • Service-Financial-Management • Workforce-and-Talent-Management • Continual-Improvement • Measurement-and-Reporting • Risk-Management • Information-Security-Management • Knowledge-Management • Organizational-Changemanagement • Project-Management • Relationship-Management • Supplier-Management Service-Management-Praktiken • Business Analysis • Service-Catalogue-Management • Service Design • Service-Level-Management • Availability-Management • Capacity-and-Performance-Management • Service-Continuity-Management • Monitoring-and-Event-Management • Service Desk • Incident-Management • Service-Request-Management • Problem-Management • Release-Management • Change Enablement • Service Validation and Testing • Service-Configuration-Management • IT-Asset-Management

4.2  Überblick zu den gängigen Rahmenwerken für die IT-Ablauforganisation

73

Technische Management-Praktiken • Deployment-Management • Infrastructure and Platform-Management • Software-Development-and-Management ITIL v4 bietet damit einen sehr umfangreichen Katalog an vorgefertigten IT-Prozessen, insbesondere für das IT-Service-Management, aber auch für übergreifende Prozesse, die in den steuernden und führenden Bereich der IT-Governance hineinreichen.

4.2.3 E  in Wegweiser durch den Begriffsdschungel von ITIL, COBIT & Co: Was ist für den CIO wirklich wichtig? Neben ITIL und COBIT können noch weitere Rahmenwerke hinzugezogen werden, die sich dann aber immer auf ein spezifisches Fachgebiet bzw. einen IT-Prozess fokussieren. Das kann z. B. das ebenfalls von AXELOS geführte PRINCE2 sein, welches einen Quasi-­ Standard für das IT-Projektmanagement zur Verfügung stellt. Für die IT-­Architektur steht TOGAF als Quasi-Standard zur Verfügung. Für den IT-Verantwortlichen wird es zuweilen schon sehr unübersichtlich. Daher fällt die Entscheidung, welches der Rahmenwerke nun für welchen IT-Prozess zum Einsatz kommen sollen, zuweilen nachvollziehbar sehr schwer. Die Abb. 4.3 zeigt eine Übersicht aus der COBIT-Perspektive auf alle Rahmenwerke. Dabei wird ebenfalls nochmal deutlich, dass viele Rahmenwerke sehr spezifisch nur einen Teilbereich abdecken und nicht die gesamte IT. COBIT nimmt in dieser Abbildung zwar für sich den Quasi-Allgemeinstandard über alle anderen Rahmenwerke an. Dies sollte aber als CIO kritisch hinterfragt werden. Denn COBIT ist immer noch aus der Historie heraus von und für IT-Auditoren entwickelt worden. Diese Handschrift trägt es immer noch, da es sehr stark auf das Messen, Regeln und Kontrollieren abzielt. COBIT ist auch sehr umfassend und damit sehr komplex geworden. Als CIO kann man sich schnell erschlagen fühlen. Und tatsächlich stellt sich die Frage, wie man es als IT-Verantwortlicher schaffen soll, sich bei COBIT vollständig auszukennen und es damit sinnvoll anwenden zu können. Aus Sicht des Autors macht eine vollständige COBIT-Implementierung nur für Unternehmen Sinn, die Regulierungen und Compliance-Anforderungen aus z. B. SOX (Sarbanes Oxley Act), SAS-70 oder anderen hohen Regulierungsanforderungen haben. Für alle anderen Unternehmen wäre es eventuell sogar hinderlich, sich an diese sehr konkreten IT-Prozesse halten zu müssen. ITIL ist in den Jahren auch stark gewachsen und mit der Version 4 hat man versucht, die Tendenzen hin zu agilem Denken und Handeln einzubeziehen, um nicht den Zug der Zeit zu verpassen. ITIL ist aber im Gegensatz zu COBIT in manchen Teilen praxisnäher und es können relativ schnell auch nur einzelne IT-Prozesse genutzt und eingeführt werden. Dies ist insbesondere für kleine und mittelständische Unternehmen sehr hilfreich. Es

74

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

Abb. 4.3  Abdeckung anderer Standards und Rahmenwerke durch COBIT 5

muss nicht extra ein großes Projekt gestartet werden für die Einführung eines Rahmenwerkes, sondern es kann jederzeit ein entsprechender IT-Prozess hinzugenommen oder geändert werden. Insgesamt bleibt festzuhalten, dass sich ITIL und COBIT durchaus gut ergänzen: ITIL hilft beim Aufbau von Prozessen, Strategien und Services, COBIT stellt sicher, dass das Aufgebaute regel- und strategiekonform ist. Das Fazit aus Autorensicht lautet daher: Nutzen Sie die beiden Rahmenwerke als eine Art Werkzeugkasten oder Toolbox. Greifen Sie herein und schauen Sie, was bei Ihnen sinnvoll eingesetzt werden kann oder sollte. Dazu hilft Ihnen das folgende Kapitel, in dem im Rahmen von 7 Gruppen IT-Prozesse für den praktischen Einsatz vorgeschlagen werden.

4.3

Ihr eigenes IT-Rahmenwerk

Ihre IT-Organisation ist so individuell wie Ihr Unternehmen: Nicht alles passt in die vorgestellten Standardrahmenwerke wie COBIT, ITIL und Co. cc

Daher ist der Tipp aus der Praxis: Nutzen Sie passende Teile der Rahmenwerke und definieren Sie Ihren eigenen IT-Prozess-Standard

4.3  Ihr eigenes IT-Rahmenwerk

75

IT Strategie und IT-Governance

Marketing/Kommunikation Human Resource Management IT Strategie Provider Management

Demand Management Requirements Management IT-/Process Consulting IT-/Process Design

IT Architektur und Innovation Incident Management Change Request Management Problem Management Configuration Management Support Strategy

IT Controlling & Verträge IT Governance & QM Digitalization & Data Strategie

Projekt Management Project Management Portfolio Management Release Management Rollout Management

IT Entwicklung und Bereitstellung xx

IT Operations and Service Support

IT Service Management

Monitoring & Reporting Infrastructure, Network & Datacenter Business Continuity Management Operations Planning & STrategy

Incident Management Change Request Management Problem Management Configuration Management Support Strategy

Abb. 4.4  Ein eigenes Rahmenwerk für die Ablauforganisation der IT

In der Abb. 4.4 ist ein Beispiel für ein eigenes Rahmenwerk für die Ablauforganisation der IT beschrieben. In den einzelnen Prozessen können Teile aus ITIL oder COBIT übernommen, angepasst oder vollständig eigene Prozesse kreiert werden. Es dient lediglich als Rahmen, um die IT-Prozesse und Abläufe konkret zu beschreiben. cc

In Zukunft sind die steuernden Funktionen und Prozesse wesentlich für den Erfolg Ihrer IT!

76

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

Bevor es losgeht mit der Definition der IT-Prozesse sei die Frage gestattet: Was ist der Mehrwert von IT-Prozessen? Der Nutzen und Mehrwert von IT-Prozessen besteht insbesondere in der Schaffung von Standards bei der Arbeit in und mit der IT. Sowohl den IT-Mitarbeitern wird durch die IT-Prozesse sehr deutlich und klar wie gearbeitet wird als auch den Fachbereichen. So wissen Key-User und Prozessverantwortliche genau wie die IT arbeitet, wo Schnittstellen zur IT sind und wie die Zusammenarbeit funktioniert. Innerhalb der IT dient es neben der Transparenz auch zur Schaffung von Qualität durch Standardprozesse. Und nicht zuletzt ist es für interne Audits oder die Vorbereitung auf Zertifizierungen eine sehr hilfreiche Dokumentation. Die 7 Gruppen von IT-Prozessen im Überblick Im Folgenden werden die 7 Gruppen der IT-Prozesse aus dem Rahmenwerk in Abb. 4.4 dargestellt und mit ein paar Beispielen versehen. Dies dient der Orientierung und kann als eine Art Schablone benutzt werden für die eigene Kreation der benötigten IT-Prozesse.

4.3.1 IT-Strategie und IT-Governance Die IT-Strategie und IT-Governance bilden bildlich gesprochen das Dach des gesamten IT-Hauses. Die wesentlichen IT-Prozesse in dieser Gruppe sind die folgenden: • • • • • • •

IT-Strategie und IT-Roadmap Marketing/Kommunikation IT-Controlling & Verträge Human Resource Management IT-Governance & IT-Qualitätsmanagement IT-Einkauf & SRM Provider bzw. Lieferantenmanagement (inkl. Sourcing-Strategie)

Gerade im Umfeld von hohen Compliance-Anforderungen wie FDA oder GxP ist ein erhöhtes Augenmerk insbesondere auf die IT-Prozesse im Umfeld IT-Governance sowie Qualitätsmanagement erforderlich. Diese Prozesse sind daher aber auch immer unternehmensspezifisch, sodass sie hier nicht im Detail dargestellt werden.

4.3.1.1 IT Strategie und IT-Roadmap Die IT-Strategie und die IT-Roadmap sind das Fundament einer funktionierenden IT-­ Organisation. Daher sind sie als IT-Prozesse auch sehr wichtig für den CIO und die Geschäftsleitung, um zu verstehen, wie eine solche IT-Strategie bzw. IT-Roadmap entwickelt wird. Es werden hier 2 mögliche Ansätze neben vielen anderen im Markt befindlichen dargestellt, da sie sehr praxisnah sind.

4.3  Ihr eigenes IT-Rahmenwerk

77

2

IT Strategie

StrategieEntwurf

1 - Standortbestimmung  Schritt 1: Ist-Analyse  IT-Prozesse  IT-Organisation  Technologie  Finanzen  Schritt 2: Heraus-

2 - Strategie-Entwurf  Schritt 3: ApplikationsStrategie

 Applikationsportfolio  Applikationslebenszyklus  Schritt 4: SourcingStrategie

forderungen

 Sourcing-Strategie

 Analyse der Unter-

entwerfen

nehmensstrategie

 Herausforderungen IT  IT-Vision erstellen

3 - Strategie-Umsetzung  Schritt 6: Umsetzung  Projektportfolio  IT-Roadmap  Budget-Strategie  Schritt 7: Cockpit  IT-Strategie-Cockpit  Kommunikation  Change Management

 Schritt 5: IT-Organisation  Demand/Supply  IT Governance

Abb. 4.5  IT-Strategie in 7 Schritten

Zum einen ist das die Entwicklung einer IT-Strategie in 7 Schritten, wie sie im Buch IT-Strategie des Autors dargelegt wird. Die Abb. 4.5 zeigt die 7 Schritte zur Entwicklung einer IT-Strategie. Die Details zum Vorgehen entnehmen Sie bitte dem Buch des Autors. Etwas ausführlicher an dieser Stelle soll die Entwicklung einer IT-Roadmap erläutert werden. Die IT-Roadmap wird in 5 Schritten erstellt, wie in der Abb. 4.6 zu sehen ist. Der Schritt 2 („Vision und Zielbild der IT erstellen“) und der Schritt 3 („IT-Roadmap erstellen“) sollen hier näher dargestellt werden. Die anderen Schritte sind den meisten IT-Führungskräften hinlänglich bekannt oder werden an anderer Stelle dieses Buch dargestellt (siehe dazu z. B. das IT-Portfolio unter Abschn. 4.3.3.1). Die Vision und das Zielbild der IT erstellen In deutschen Unternehmen wird immer noch sehr rational gearbeitet. Prozesse, Strukturen, klare Hierarchien und Arbeitsanweisungen bilden weiterhin den Rahmen der Arbeit. Agilität, Netzwerkorganisationen und die Start-up-Welle bringen Bewegung in das stramme Gerüst aus dem Industriezeitalter. Viele wehren sich aber noch dagegen und tun dies als „neumodischen Schnickschnack“ ab.

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

Abb. 4.6  Die IT-Roadmap in 5 Schritten

78

4.3  Ihr eigenes IT-Rahmenwerk

79

Nicht alles, was neu daher kommt, muss auch gut sein. Aber beim Thema Vision oder heute auch oft Purpose genannt soll hier klar Stellung bezogen werden. Wenn man selbst in einigen Projekten erleben durfte, welche Kraft von einer gemeinsam getragenen Vision ausgeht, so erlebt man seine Arbeit wieder sinnerfüllt. Seit Jahren erzählen uns Studien, dass mehr als die Hälfte der internen Mitarbeiter innerlich gekündigt haben. Mag es daran liegen, dass diesen der Sinn ihrer Tätigkeit abhandengekommen ist? Von daher: Was ist die Funktion einer Vision bzw. was soll das bringen? cc Definition von Vision und Zielbild • Die Vision ist das Fundament und die Basis für die Strategie. • Sie liefert Orientierung für das eigene Handeln. • Visionen sind Landebahnen für Ziele. • Eine Vision, die klar und mit Fakten unterlegt Mehrwerte und Nutzen stiftet und hinter der alle stehen, weckt Überzeugung und vor allem Motivation für alle Mitarbeiter. Zugegeben: Viele Visionen – insbesondere die von großen Konzernen – kommen oft hölzern daher und wirken irgendwie alle gleich. Wie soll da eine Identifikation stattfinden? Warum sollte man als einer von Tausenden von Mitarbeitern das gut finden? Aber: Soll man deswegen sofort kündigen? Konzerne haben es da auch nicht leicht. Für eine IT-Organisation zwischen 20 und 500 Mitarbeitern ist es einfacher, eine für die gesamte IT und zum Unternehmen passenden IT-Vision zu formulieren. Folgende Fragen stehen auf dem Weg zu dieser Vision primär im Fokus: • Wozu gibt es uns als IT im Unternehmen? • Was treibt uns an? • Wo wollen wir in 3 oder 5 Jahren stehen? Die Vision wird dadurch entwickelt, dass man sich auf eine Zeitreise begibt. Das mag zunächst komisch klingen, aber genau das macht die Vision aus. Es darf während der Arbeit geträumt werden. Welche Geschehnisse sind anders als heute und mit welchen erlebbaren Folgen? Bilder sind dabei wichtiger als Zahlen! Die Manager sollen perspektivisch und emotional gefühlt schon da gewesen sein, wo sie real hinkommen wollen. Es hat sich bewährt, die Vision gemeinsam mit dem IT-Leitungsteam sowie der Geschäftsleitung zu entwickeln. Das heißt, es sind ca. 5–10 Personen beteiligt. Es muss kein gemeinsamer Workshop sein, sondern jeder Teilnehmer der Gruppe kann das für sich machen an einem Ort seiner Wahl und wann er Lust und Zeit dafür hat (man sollte den Teilnehmern eine Woche dafür zur Verfügung stellen).

80

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

Als Moderator bietet sich ein neutrale Person an, aber der CIO kann das auch selbst machen, wobei dann die Neutralität infrage gestellt ist. Als Erstes muss ein Zieldatum festgelegt werden. Es bietet sich ein Zeitraum von mindestens 3–4 Jahren und maximal 7–8 Jahren in der Zukunft an. Fünf Jahre bildet da oft die goldene Mitte und so nehmen wird hier den 01.01.2025 als Zieldatum an. Um diese Vision oder das sogenannte Zielbild zu entwickeln, helfen die folgenden Fragen und Anleitungen: • • • • • •

Jeder der Teilnehmer versetzt sich jetzt in das Jahr 2025. Man schaut sich an, was gerade passiert. An welchen Themen wird gearbeitet? Was sind wichtige Projekte? Worauf ist man im Jahr 2025 stolz? Was hat man gemeinsam erreicht? Was ist alles schon da und worauf kann man aufbauen? Wie fühlt sich das an?

Wichtig ist es nun, diese ganzen Erkenntnisse in Prosa runterzuschreiben; ein weißes Blatt Papier, das man ganzseitig füllt, ist vollkommen ausreichend. Diese Werke sammelt der Moderator als objektiver und neutraler Experte für die Strategiearbeit. Es können durchaus 2 oder 3 Versionen von der Vision bzw. dem Zielbild erstellt werden. Jetzt bekommt jeder Teilnehmer alle Dokumente zugeschickt mit der Bitte diese zu bewerten: Was ist gut? Was ist schlecht? Was fehlt? Anschließend kommt erst der Workshop, in dem als Ziel eine Gesamtvision bzw. ein Gesamtzielbild aus allen Einzeldokumenten erstellt wird. Dazu treffen sich alle Teilnehmer, um aus den bekannten Einzeldokumenten ein Gesamtdokument und ein Gesamtzielbild zu erstellen. Dazu sind ca. 3 Stunden einzuplanen; idealerweise erfolgt die Erstellung des Gesamtdokumentes „live“, für alle ersichtlich in einem Word-Dokument, sodass alle mit dem gleichen Ergebnis vor Augen nach Hause gehen. Die IT-Roadmap erstellen Jetzt kann der Weg von der heute bestehenden Ausgangssituation zur gerade entstandenen IT-Vision entwickelt werden. Dabei ist es ganz wichtig, nicht von heute bis zur IT-Vision im Jahr 2025 zu denken, sondern rückwärts. Das heißt konkret: • Man versetzt sich wieder in das Jahr, in dem das eigene Zielbild als IT-Vision konkretisiert wurde! • Was ist dort zu sehen? Was wurde erreicht? • Was waren damals erste Schritte, die konkret gegangen wurden? • Welche Maßnahmen wurden abgeleitet? • Welchen Schwierigkeiten ist man begegnet? • Wie wurden diese gemeistert? • Was braucht man also schon heute, um überhaupt dahin zu gelangen?

4.3  Ihr eigenes IT-Rahmenwerk

81

Abb. 4.7  Die IT-Roadmap im Überblick

Das ist die sogenannte Arbeit an der „strategischen Lücke“. Diese strategische Lücke bezeichnet den Bereich, der zwischen dem im Zielbild Gesehenen liegt und dem was heute tatsächlich ist. Anders formuliert: „Was ist das Gap zwischen der Vision und dem heutigen Ist-Zustand?“ Die IT-Roadmap gibt eine Übersicht über alle wichtigen Themen, Aufgaben und Projekte für die kommenden 2–3 Jahre auf einem Zeitstrahl. Der generelle Aufbau folgt der Strategiearbeit aus der Phase 3. Ausgangspunkt der IT-Roadmap ist das IT-Assessment mit seinen Ergebnissen und Gaps bzw. Deltas. Das Ziel der IT-Roadmap ist die IT-Vision, in der die Gaps und Deltas möglichst zum großen Teil durch mehrere Transformationsschritte aufgelöst worden sind. Die Grafik Abb. 4.7 zeigt die IT-Roadmap im Überblick. Die IT-Roadmap bildet damit einen verbindlichen Rahmen, der die Ergebnisse des IT-Assessments und der IT-Vision mit den dafür nötigen Transformationsschritten vereint. Um diese Transformationsschritte lebendig zu machen, kann ein Bebauungsplan da­ raufgesetzt werden. Die Schritte der Transformation bekommen dann Kontur und werden auf Jahresscheiben geteilt mit konkreten IT-Projekten „bebaut“. Beispielhaft ist in der Abb.  4.8 eine IT-Roadmap mit Projekten in der Ausrichtung auf das Zielbild der IT in 2025 dargestellt. So wird sehr schnell deutlich, was auf der IT-Roadmap in den kommenden Jahren „geliefert“ wird und wie das auf die IT-Vision des Unternehmens einzahlt.

4.3.1.2 Marketing/Kommunikation Bevor strategische Themen angegangen werden, muss bewusst Zeit dafür vorhanden sein. Ansonsten ist die Gefahr einer unreifen und vor allem nichtakzeptierten Strategie und Vision sehr groß. Und ganz ehrlich: Das richtet mehr Unheil an als das es einem als CIO nützt! • Kommunikationsplan: Wen trifft man wann? Hierfür müssen Regeltermine eingestellt werden!

Abb. 4.8  Ein Beispiel für eine IT-Roadmap mit konkreten Projekten und Zielbild IT 2025

82 4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

4.3  Ihr eigenes IT-Rahmenwerk

83

• Newsletter: keine Prosa, sondern 3 bis maximal 4 Themen und diese Themenabschnitte maximal 500–60 Wörter, mit professionellen Bildern auflockern (bitte keine ScreenshotSammlung, sondern Bilder mit den Beteiligten), Erfolgsprojekte darstellen, aber auch mal das eine oder andere Negative offen zugeben und zeigen, wie man das Thema in den Griff kriegen will (und sich daran auch messen lassen). Jetzt ist es an der Zeit, diese IT-Roadmap vorzustellen und idealerweise in einer Art „IT-Roadshow“ im Unternehmen bekannt zu machen. Damit schlägt man 2 Fliegen mit einer Klappe: • Man schafft Transparenz und kann Feedbackschleifen mit allen wichtigen Stakeholdern drehen und damit die IT-Roadmap weiter optimieren. • Man zurrt ein echtes Programm für die IT fest, welches auch geliefert werden muss. Das bringt einen in Zugzwang, was aber auch positiv ist, da man daran messen lassen kann.

4.3.1.3 IT-Controlling  &  Verträge IT-Controlling gehört zu den Managementinstrumenten des CIOs und ist gleichfalls für die Geschäftsleitung ein wichtiges Instrument zur Steuerung der IT. Wesentliche Fragen der IT können – zumindest ansatzweise – durch das IT-Controlling beantwortet werden: • Was ist die IT eines Unternehmens wert? • Wieviel darf die IT eines Unternehmens kosten? • Wie könnte man den Wert bestimmen? Die IT hat sich in den vergangenen Jahren und Jahrzehnten rasant entwickelt. Auch das hat sich im IT-Controlling gespiegelt. Wie in der Abb.  4.9 zu sehen, hat man in den 1990er-Jahren und Anfang der 2000er-Jahre die IT als Kostenfaktor angesehen, so war auf der Ebene des Controllings die IT ein Cost Center. Mit der Erkenntnis, dass die IT zu einem Vermögensgegenstand wird und sogar als ein Partner auf Augenhöhe angesehen wird, wurde die IT nicht mehr als Cost Center, sondern als Service Center evtl. sogar als Profit Center betrachtet und im Unternehmen geführt. Durch die Digitalisierung und neue Technologien ist die IT in einigen Unternehmen sogar in der Lage, echte strategische Wettbewerbsvorteile zu erschaffen. Da macht ein Cost Center natürlich keinen Sinn mehr und man spricht heute von einem „IT Strategic Investment Center“. Was sind die Ziele des IT-Controllings? • IT-Controlling ist verantwortlich für die Transparenz, die das IT-Management braucht, um „richtige“ Entscheidungen zu treffen.

84

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

IT ist ein Kostenfaktor

IT ist ein Vermögenswert

IT ist ein Partner

IT ermöglicht strategische Wettbewerbsvor teile IT Strategic Investment Center

IT Profit Center IT Service Center IT Cost Center

Abb. 4.9  Was ist die IT eines Unternehmens wert?

• Dies geschieht durch aktive Begleitung und kritische Beratung des IT-Managements in den Controlling-Regelkreisen der IT: Planung, Umsetzung (Bereitstellung und Betrieb), Abweichungsanalyse sowie Korrektur (Maßnahmen). In Anlehnung an Prof. Gadatsch zeigt die Abb. 4.10 die Bestandteile des IT-­Controllings sehr übersichtlich und differenziert zwischen den verschiedenen Arten des IT-Con­ trollings [4]. Es kann an dieser Stelle zur weiterführenden Auseinandersetzung mit dem Thema IT-Controlling das Buch Masterkurs IT-Controlling von Prof. Gadatsch, welches ebenfalls im Springer-Verlag erschienen ist, empfohlen werden. Das Thema „Verträge und Vertragsmanagement in der IT“ ist neben dem Thema „IT-Controlling“ für den CIO sehr wichtig. Es soll an dieser Stelle auf das Rahmenwerk COBIT verwiesen werden. Unter AI5 wird das Thema „Beschaffe IT-Ressourcen“ mit dem Unterthema AI5.2 „Supplier Contract Management“ (auf Deutsch: „Vertragsmanagement für Lieferanten“) beschrieben. Als Übersicht über das Thema „Vertragsmanagement“ soll hier nur eine erste Skizzierung dienen, die IT-relevante Bestandteile aufzeigt, die vertraglich geregelt werden sollten: • • • • • •

Outsourcing Standard- und auch Individualsoftwareentwicklung Beratungsleistungen Schulungen und Trainings Hardware-/Netzwerkkauf und -einrichtung Wartung und Pflege

4.3  Ihr eigenes IT-Rahmenwerk

85

PLAN   

IT-Strategie / Architektur HW, SW, SecurityStandards Portfolio-Planung

BUILD 

 

Einführung und Implementierung / Entwicklung von Software Projekte (Management) IT Wartung und Pflege

RUN    

Betrieb und Pflege der IT-Systeme IT-Infrastruktur Service Support Hotline

IT Service Center

Operatives IT-Controlling

Strategisches IT-Controlling

IT Produkt Controlling IT Portfolio Controlling

IT Projekt Controlling IT Infrastruktur Controlling IT Technologie Controlling IT Ressourcen Controlling

Abb. 4.10  Bestandteile des IT-Controllings

4.3.1.4 IT HR (Human Resource Management) Die Personalthemen in der IT werden zumeist von der Personalabteilung (HR) verantwortet. Trotzdem ist das Thema HR in der IT mehr als relevant, da IT-Experten am Personalmarkt sehr rar sind und es sehr schwer ist, die richtigen Wissensarbeiter zu rekrutieren. Daher soll in diesem Kontext kurz auf die wesentlichen Themen des CIOs und der IT-Führung eingegangen werden, die strategisch wichtig für die IT sind. Dies sind die folgenden 3 Themen, auf die sich die IT-Führung konzentrieren sollte: • IT-Personalentwicklung und Potenzialmanagement • Schulung und Weiterbildung für IT-Mitarbeiter • IT-Personalmarketing

86

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

Hinzu kommt ein weiterer Punkt, der ausführlich im Abschn.  4.3.7 dargestellt wird, nämlich die Stellenbeschreibung bzw. Job-Role-Definition aller IT-Mitarbeiter. Zum Punkt IT-Personalentwicklung kann verwiesen werden auf einen sehr wichtigen Punkt in der Führung, nämlich das Thema „Stärken stärken“ im Abschn. 3.3. Schulung und Weiterbildung sind in der heutigen Zeit einer der wesentlichen Treiber für erfolgreiche IT-Organisationen. Daher sollte in diesem Rahmen ein detailliertes Schulung- und Weiterbildungskonzept existieren, welches sich an den Stärken der IT-Experten orientiert (siehe dazu mehr unter Abschn. 3.3).

4.3.1.5 IT-Einkauf & Provider- bzw. Lieferantenmanagement Das strategische und aktive Management der IT-Dienstleister und -Lieferanten ist eine wichtige Aufgabe der IT-Führung und wird leider oftmals noch zu sehr vernachlässigt. Hier kann zum einen wieder auf COBIT verwiesen werden. AI5 regelt die Beschaffung von Lieferanten mit all seinen Unternehmen. Die Abb. 4.11 zeigt einen Überblick über die Definition und die 4 wesentlichen Aufgaben des IT-­Lieferantenmanagements. Ein wichtiger Unterpunkt des Lieferantenmanagements ist die Sourcing-Strategie. In Abb. 4.12 ist eine beispielhafte Sourcing-Strategie dargestellt. Differenziert wird auf den Achsen nach Unternehmenskritikalität und internem Know-how. Dabei wird sehr schnell deutlich, welche Leistungen ausgelagert, geprüft, gestärkt oder auf jeden Fall belassen werden sollen. Dies gibt einen sehr schnellen Überblick und eine gute und transparente Kommunikation der Lieferantenstrategie gegenüber der Geschäftsleitung.

4.3.2 Demand-Management Die folgenden 4 IT-Prozesse gehören zur Gruppe des Demand-Managements: • • • •

Requirements-Management IT-/Process-Consulting IT-/Process-Design Demand-Portfolio-Management

Zu den Themen IT-/Process-Consulting und -Design wird an dieser Stelle auf die ausführliche Darstellung der IT-Prozessorganisation verwiesen, die in Abschn.  3.4.5 beschrieben ist.

4.3.2.1 Requirements-Management Eine ausführliche Beschreibung eines IT-Anforderungsmanagement-Prozesses findet man in COBIT unter AI1 (Identify Automated Solutions [identifiziere automatisierte Lösungen]). Dort sind im Grunde alle für das Anforderungsmanagement wesentlichen Teile dargestellt. Daher wird in diesem Kontext nur auf die Unterschiede des Anforderungsma-

4.3  Ihr eigenes IT-Rahmenwerk

87

IT Lieferanten Management Gestaltung der ITLieferantenbasis

ITLieferantenbewe rtung

IT-Lieferanten Entwicklung und Integration

IT Lieferanten Audit

Definition der ITSourcingStrategie

Auswahl von strategischen ITLieferanten

Definition und Verlagerung von Aufgabenumfäng en an die ITLieferanten und permanente Erhöhung der Leistungsfähigkeit

Ständiges Monitoring und Kontrolle der ITLieferantenLeistung und Beziehung

Abb. 4.11  IT-Lieferantenmanagement im Überblick

Abb. 4.12  Eine beispielhafte Sourcing-Strategie

nagements im klassischen Sinne versus agilem Vorgehen Wert gelegt. Dies ist eine wesentliche Neuerung seit einigen Jahren, die berücksichtigt werden muss. Das Anforderungsmanagement hat sich nämlich in den letzten Jahren aufgrund der Digitalisierung und zunehmenden Komplexität und Dynamik wesentlicher agiler gestaltet. Galt früher noch das typische Wasserfallmodell für die Planung von größeren IT-­ Projekten, so ist heute das agile Vorgehen, z. B. nach SCRUM vorherrschend.

88

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine … Leistung / Umfang fest

Aufwand variabel

Zeit variabel Agiles Anforderungs- / Projekt Management

Klassisches Anforderungs/ Projektmanagement Aufwand variabel

Zeit variabel

Leistung / Umfang variabel

Abb. 4.13  Klassisches vs. agiles Anforderungsmanagement

Die Abb. 4.13 zeigt sehr schön die Unterschiede zwischen klassischen Anforderungsbzw. Projektmanagement und dem agilen Vorgehen. Primär wird das Leistungsdreieck auf den Kopf gestellt. Bei klassischem Vorgehen ist die Leistung bzw. der Umfang des Projektes klar umrissen und beschrieben in zum Teil sehr großen Lasten- und Pflichtenheften im Anforderungsprozess. Die Zeit und der Aufwand allerdings sind dementsprechend variabel und schwer bis gar nicht planbar. Im agilen Kontext ist es genau umgekehrt. Aufwand und Zeit sind durch klar geregelte Sprints und wiederkehrende Tests festgezurrt, aber der Umfang ist variabel; je nachdem was in den Sprint reinpasst und wie weit man in dem Prototypenansatz tatsächlich kommt. Ein weiterer Unterschied im Kontext des Anforderungsmanagements zwischen agil und klassisch liegt darin, dass die Phasen des Analysierens und Planens im agilen Kontext wiederkehrend sind und nicht nur einmal stattfinden wie in der klassischen Planung nach dem Wasserfallmodell. Die Abb. 4.14 zeigt diesen Unterschied sehr deutlich. Gerade im Bereich des Anforderungsmanagements ist dies ein deutlicher Unterschied zum bisherigen klassischen Vorgehensmodell. Denn Anforderungsmanagement findet nicht nur zu Beginn und quasi als Vorbereitung auf das Projekt statt, sondern ist ein wiederkehrender Prozess, der nach jedem Sprint bzw. fertigen Prototypen wiederholt wird. Dies hat neben der reinen Methodik auch Auswirkung auf die Rolle des Anforderungsmanagers. Er ist festes Teammitglied in agilen Teams und keine eigene und mehr oder weniger auf sich allein ausgerichtete In­ stanz mehr. Weitere Details zum Thema SCRUM und agile Vorgehensmodelle entnehmen Sie bitte dem Abschn. 3.3.5.

4.3  Ihr eigenes IT-Rahmenwerk

89

Abb. 4.14  Wasserfall versus agiler Planung

4.3.3 Projektmanagement Die 2 wesentlichen Prozesse aus der Gruppe des Projektmanagements sind das Projektmanagement selbst und das Portfoliomanagement. Diese werden im Folgenden näher beschrieben und beleuchtet. Weitere Prozesse des Projektmanagements können im Release- und Roll-Out-Ma­ nagement gesehen werden. Diese sind nach ITIL genau definiert und bedürfen daher hier keiner weiteren Begriffsdefinition.

4.3.3.1 Projektmanagement Das IT-Projektmanagement zeigt den klassischen Prozess, wie ein IT-Projekt zu planen und zu führen ist. Dies ist ausführlich in den grundlegenden Rahmenwerke von z. B. PRINCE2 dargelegt und soll hier nicht in aller Tiefe wiedergegeben werden. Dennoch sind ein paar Dinge für ihr Unternehmen individuell zu regeln. Zum Beispiel sollte klar sein, wann bzw. ab welcher Größenordnung in Ihrem Unternehmen von einem IT-Projekt geredet wird und welche Klassifikationen es dazu gibt. Die Abb. 4.15 gibt dazu einen Überblick und kann als Grundlage für die weitere Spezifikation für Ihr Unternehmen dienen. Des Weiteren macht die Unterteilung eines IT-Projektes Sinn, sodass die Komplexität herausgenommen und die Führung und Steuerung erfolgreich sein kann. Dazu kann beispielsweise eine Gliederung in die folgenden 4 Projektphasen dienlich sein: • • • •

Auftragsklärung Konzeption Realisierung Abschluss

90

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

Abb. 4.15  Klassifikation von IT-Projekten

Abb. 4.16  Die 4 Projektphasen im Überblick

Die Abb. 4.16 zeigt die 4 Phasen mit den Kernfragen im Überblick. Eine Abgrenzung der Aufgaben pro Projektphase zeigt die Abb. 4.17. Eine Übersicht über die Dokumente, die pro Projektphase benötigt werden, ist für die IT-Prozessgestaltung ebenso wichtig. Denn durch klare Standards kann eine Professionalisierung und vor allem Qualitätssicherung sichergestellt werden. Die Abb. 4.18 zeigt die Dokumente, die in jeder Projektphase angefertigt werden müssen. Klarheit über die Rollen im Projekt und deren Verantwortlichkeiten ist eines der Schlüsselfaktoren für ein gelungenes und erfolgreiches Projekt. Die Abb. 4.19 zeigt die Projektrollen mit ihren Verantwortlichkeiten im Überblick. Hilfreich neben den allgemeinen Methoden und Prozessen zum Projektablauf wie die in PRINCE2 und anderen Rahmenwerken beschrieben werden sind die typischen Fragestellungen pro Projektphase. Diese sind in den folgenden Abbildungen pro Projektphase dargestellt (Abb. 4.20, 4.21, 4.22 und 4.23). Bei dem Thema Projektmanagement spielt natürlich auch das Thema Agilität im Sinne von SCRUM eine große Rolle. So können und sollten die Projektmanagement-Prozesse zumindest in der Realisierungsphase auch nach agilen Methoden mithilfe von Sprints abgewickelt werden. Siehe zu dem Einsatz von SCRUM ausführlich Abschn. 3.4.

Abb. 4.17  Die typischen Aufgaben in den 4 Projektphasen

4.3  Ihr eigenes IT-Rahmenwerk 91

92

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

Abb. 4.18  Dokumente in den jeweiligen Projektphasen

Abb. 4.19  Die Projektrollen im Überblick

4.3.3.2 Portfoliomanagement In den meisten Unternehmen sind Projekte Alltag. Damit hat sich – gerade auch in der IT – ein regelrechter Wust an Projekten etabliert. Um den Überblick zu behalten, hat man sich vor einigen Jahren der Finanztheorie bedient und das Portfoliomanagement als Basis für die Schaffung von Transparenz bei Projekten hergenommen. Genauso wie Ihnen Ihr Finanzportfolio zeigt, welche Aktien, Rentenpapiere oder Fonds Sie mit welcher Entwicklung haben, kann dies auch mit Projekten geschehen. Auf die IT-Welt übertragen, hat McKinsey untersucht, wie Portfolios in der IT eingesetzt werden und zu welchem Ergebnis sie beitragen. Die Studie ist zwar von 2012, aber in ihrer Relevanz auch heute noch valide. Folgendes ist dabei herausgekommen:

4.3  Ihr eigenes IT-Rahmenwerk

93

Abb. 4.20  Fragenkatalog zur Auftragsklärung

Abb. 4.21  Fragenkatalog zur Konzeption

• Etwa 30 % der IT-Projekte dienen nicht der Unterstützung der Fachbereiche und stellen reine IT-Projekte dar, deren Effizienz für das Unternehmen oftmals nur unzureichend quantifizierbar ist. • 15–20 % der IT-Projekte eines Portfolios können aufgegeben werden, weil sie nicht messbar zum Unternehmenserfolg beitragen. • Weitere 25 % der IT-Projekte müssen nicht in vollem Umfang fortgeführt werden, sondern erfüllen auch in reduzierter Form ihre Aufgaben. • Zwischen 40–50 % aller E-Business-Initiativen unterstützen nicht die Geschäftsziele und führen zu keinem messbaren Mehrwert.

94

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

Abb. 4.22  Fragenkatalog Realisierung

Abb. 4.23  Fragenkatalog Projektabschluss

Sie sehen: Ein Projektportfolio kann Ihnen schnell helfen, nicht nur den Überblick zu bekommen bzw. zu bewahren, sondern vor allem effizienter zu werden. Dies wird Ihnen die Unternehmensleitung danken und daher ist das Portfoliomanagement eines der wesentlichen Tools für CIOs, IT-Leiter und OIT-Manager geworden. Notwendige Abgrenzungen Bevor wir starten, sollten wir zum besseren Verständnis eine Abgrenzung vornehmen. Denn die Begriffe Projekt, Teilprojekt, Programm und Portfolio werden oftmals durcheinandergebracht. Um eine einheitliche Sichtweise zu bekommen und Verwechslungen zu vermeiden, dient die folgende Abgrenzung wie in Abb. 4.24 dargestellt.

4.3  Ihr eigenes IT-Rahmenwerk

95

Abb. 4.24  Eine Abgrenzung: Projekte, Programme und Portfolios

Es sind folgende Dinge zu unterscheiden: • Projekte sind die kleinste Einheit. Sie werden durch einen Projektleiter verantwortet. • Als Untereinheit entstehen bei größeren Projekten vereinzelt Teilprojekte, die sich mit spezifischen Themen oder Inhalten beschäftigen. Diese werden von Teilprojektleitern geführt, die an den Projektleiter berichten. • Ein Programm ist definiert als eine Zusammenfassung von Projekten, die thematisch, inhaltlich zusammenpassen bzw. ein gemeinsames Ziel besitzen. Die Führung obliegt einem Programmleiter • Ein Projektportfolio ist kein Projekt und kein Programm, sondern ein Instrument, welches alle Projekte und Programme gleichzeitig betrachtet unter dem Gesichtspunkt der strategischen Priorisierung. Es ist eine dauerhafte Aufgabe in Abgrenzung zum Projekt bzw. Programm, welche immer zeitlich eingegrenzt ist. Das Projektportfoliomanagement bietet eine projektübergreifende Übersicht zur Analyse, Steuerung und Führung aller Projekte und Programme. Man befindet sich hier in der Vogelperspektive und kann schnell und übersichtlich alle Projekte und Programme strategisch bewerten, priorisieren und Entscheidungen treffen. Damit sind auch schnell Synergien zwischen den Projekten erkennbar. Es geht um die Frage: „Welches sind die richtigen Projekte für unser Unternehmen zu diesem Zeitpunkt?“. Im Rahmen des Projektportfoliomanagements sind strategische und finanzielle Bewertungsaspekte wie der ROI oder Ausrichtung auf die UN-Strategie die wesentlichen Bezugsgrößen. Daher ist das Projektportfolioma-

96

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

nagement ein ideales Werkzeug für CIOs und IT-Leiter zur strategischen Führung der IT-Organisation. Es gibt ein weiteres Instrument, welches oftmals mit dem Projektportfolio verwechselt wird. Die Rede ist vom Multiprojektmanagement. Der Unterschied liegt in der Betrachtungsweise: Das Projektportfoliomanagement hat eine Sicht auf die Projekte aus der Vogelperspektive und prüft Synergien sowie die strategisch richtige Ausrichtung der Projekte, wohingegen das Multiprojektmanagement durch einen starken operativen Charakter geprägt ist, also eher auf inhaltlicher Ebene der einzelnen Projekte agiert. Multiprojektmanagement beschreibt mehr das operative Handeln der Führung und des Managements einer Vielzahl von Projekten, wohingegen das Projektportfoliomanagement eher strategischen Charakter im Sinne der Prüfung, Beurteilung und des Monitorings von Projekten besitzt. Scoping: Wo macht der Einsatz von Projektportfolios Sinn und wo nicht. Nicht für alle Anwendungsgebiete sind Projektportfolios sinnvoll. Die folgende Übersicht soll Ihnen helfen, zu beurteilen, für welche Anwendungsfälle ein Projektportfolio für Sie und Ihre IT-Organisation richtig ist. Das sind die Gebiete, für die ein Projektportfolio passt: • Erkennen von Redundanzen zwischen Projekten • Die Projektziele können besser aufeinander abgestimmt werden • Priorisierung, Kategorisierung und Evaluation von neuen und laufenden Projekten und Programmen • Kontrolle und Monitoring des Mehrwerts von Projekten und Programmen • Ideale Diskussionsgrundlage für die Abstimmung der Ziele mit den Fachbereichen • Basiswerkzeug für die Entwicklung einer IT-Strategie • Treffen von Make-or-Buy-Entscheidungen Was ein IT-Projektportfolio nicht leisten kann (Out-of-Scope): • Kein Ersatz für das Demand- und Anforderungsmanagement • Es kann nicht eine IT-Strategie ersetzen • Es ersetzt nicht das detaillierte Tracking und Monitoring innerhalb eines Projektes (Projektcontrolling), sondern ist ein strategisches Instrument zur Auswahl und Überwachung aller Projekte im Unternehmen Zusammenfassung Mithilfe eines professionellen Projektportfoliomanagements lässt sich sehr schnell erkennen, wo Ihr IT-Budget optimal für den Unternehmenszweck eingesetzt wurde und wo nicht. Es entstehen daraus Handlungs- und Entscheidungsstränge, die sonst oftmals nicht transparent sind. Darüber hinaus ist schnell zu erkennen, wann IT-Projekte strategisch nicht mehr sinnvoll sind. In solchen Fällen sollte ein IT-Verantwortlicher „schlechtem“

4.3  Ihr eigenes IT-Rahmenwerk

97

Geld nicht weiterhin gutes hinterherwerfen, sondern das jeweilige IT-Projekt sofort beenden und die entstandene „Ruine“ einfach abreißen lassen. Aufgaben des Projektportfoliomanagements Bewertungsphase • Bewertung von Projektanträgen und Projekten nach Chancen, Risiken, Wirtschaftlichkeit und strategischer Bedeutung für das Unternehmen • Analyse von Abhängigkeiten zwischen geplanten und laufenden Projekten • Priorisierung von Projektanträgen auf Basis dieser Bewertungen und Analysen • Genehmigung bzw. Ablehnung von Projektanträgen Fortschrittskontrolle • Laufende Überprüfung des Projektportfolios hinsichtlich seiner Ausrichtung auf die Unternehmensziele • Koordination zwischen den laufenden Projekten hinsichtlich Ressourcen, Synergien und Konflikten • Überwachung der laufenden Projekte Lessons Learned • Abschließende Bewertung von beendeten Projekten • Sicherung der Erfahrungswerte aus laufenden und abgeschlossenen Projekten (dies kann in Form einer „Wissensdatenbank“ sehr hilfreich für folgende Projekte gespeichert werden) Die Bandbreite an Aufgaben für das Projektportfoliomanagement ist sehr groß. So beginnt in vielen IT-Organisationen die Portfolioarbeit schon beim Sammeln und Einbringen von Projektideen, geht über die Portfolioerstellung und den Monitoringprozess und endet mit der Nachkalkulation von beendeten Projekten. Oft werden viele der genannten Aufgaben allerdings nicht zum Portfolioprozess gezählt und gehören eher zum Projektmanagement. Wir werden hier allerdings alle oben beschriebenen Aufgaben zum Portfolioprozess zählen und ausführlich im jetzt folgenden Teil II beschreiben und erläutern. Der Portfolioprozess Der Portfolioprozess besteht aus 4 Hauptprozessen, denen jeweils 4 Unterprozesse zugeordnet sind, wie in Abb. 4.25 dargestellt. Bevor eine ausführliche Beschreibung des Portfolioprozesses erfolgt, macht es Sinn, sich über den Lebenszyklus von Projekten als eine Art Exkurs Gedanken zu machen. Exkurs: Lebenszyklus von Projekten Jedes Projekt unterliegt einem Lebenszyklus, ähnlich den Produkten im Produktlebenszyklus. Bevor mit dem Portfolioprozess gestartet wird, sollte geklärt werden, in welcher Zyklusphase sich ein Projekt gerade befindet oder generell befinden kann.

98

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

Abb. 4.25  Der Portfolioprozess

Zusammengefasst gibt es, wie in Abb. 4.26 zu sehen, folgende Projektzustände: a. Projekte vor der Aufnahme in das Portfolio • Projektidee („on the horizon“) • Beantragtes Projekt • Zurückgestelltes Projekt b. Projekte im Portfolio-Monitoring-Prozess • Genehmigtes Projekt • Laufendes Projekt • Unterbrochenes Projekt c. Abgenommene und inaktive Projekte • Abgenommene Projekte • Nichtgestartete Projekte • Abgebrochene Projekte

4.3  Ihr eigenes IT-Rahmenwerk

99

Abb. 4.26  Der Lebenszyklus von Projekten

Phase 1: Der Aufnahme- und Bewertungsprozess Der 1. Hauptprozess beginnt mit der Aufnahme von Projekten in Form von Projektideen, die dann zu einem Projektantrag führen, sofern dem Vorhaben eine gewisse Realisierungswahrscheinlichkeit zugetraut wird. Im Projektantrag werden zum ersten Mal einige Informationen zum Projekt strukturiert zusammengefasst, so z. B.: • • • • • • • • •

Projektname Projektnummer (falls vorhanden) Verantwortliche Abteilung oder Fachbereich für das Projekt Kostenstelle (interne Übernahme der Projektkosten) Projektziel Projektfokus: In-Scope und Out-of-Scope Möglicher Projektstart Ungefähre Projektdauer Projektrisiken

100

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

Alle Projekte, die offiziell beantragt werden, müssen dann von einem Gremium, welches für den Portfolioprozess verantwortlich ist, bewertet und priorisiert und somit in gewisser Form nach bestimmten Kriterien gefiltert werden. Es ist wichtig, zwischen der Projektbewertung und der Projektpriorisierung zu differenzieren. Die Bewertung der Projekte dient der Maßgabe, ob ein Projekt durchgeführt wird oder nicht. Die Priorisierung eines Projektes dient der Erarbeitung einer Durchführungsreihenfolge und gilt damit nur für die Projekte, die bei der Bewertung als Mussprojekt nicht durch den Filter gefallen sind. Die Kriterien zur Bewertung von Projekten sind individuell festzulegen und beziehen sich auf monetäre Faktoren, Risikofaktoren, Wirtschaftlichkeits- oder Kosten-/Nutzen-­ Faktoren. Bei der Priorisierung sind die Kriterien oftmals schwerer zu erfassen und in vielen Unternehmen unterliegt diese Bewertung subjektiven Entscheidungen der Gremienleiter. In der kommenden Phase 2 (Portfolioerstellungsprozess) wird das Projektportfolio zum ersten Mal erstellt oder auf den neuesten Stand gebracht und 3 mögliche Sichtweisen zur Beurteilung der Priorisierung der Projekte vorgestellt. Phase 2: Der Portfolioerstellungsprozess Nachdem die Projekte in der 1. Phase grob vorgefiltert wurden, werden diese Projekte jetzt in das Portfolio eingebracht. In dieser Phase wird entweder ein bestehendes Projektportfolio auf den neuesten Stand gebracht oder zum ersten Mal ein Projektportfolio erstellt. Als erstes müssen neben den in der Phase 1 erfassten Projektdaten insbesondere folgende Informationen ermittelt werden: • Wirtschaftlichkeit des Projektes in Form eines ROI (Return on Investment) • Das Risiko des Projektes (meistens eine eher subjektiv zu bewertende anstatt einer mathematisch herzuleitenden Kenngröße) Um die Projekte nach den gerade beschriebenen Kriterien zu priorisieren, gibt es verschiedene Sichten auf das Portfolio: Die für das IT-Portfolio verwendeten Achsenwerte sind auf der Ordinate der „Return on Investment (ROI)“ als quantitativer Wert des jeweiligen Projektes oder qualitativ ausgedrückt, wenn der ROI schwer zu ermitteln ist: Der Nutzen des Projektes für das Unternehmen. Auf der Abszisse können die benutzten Werte variieren, um verschiedene Aussagen über die Projekte zu erhalten. Mögliche Aussagen können sein: • Beitrag zur Unterstützung der Unternehmensstrategie (sogenanntes „nutzen- und strategieorientiertes IT-Portfolio“) • Realisierungsrisiko oder „nutzen- und risikoorientiertes Portfolio“ Das nutzen- und strategieorientierte IT-Portfolio Im nutzen- und strategieorientierten IT-Portfolio wird bewertet, wie sehr das Projekt der Unternehmensstrategie dient (siehe dazu die Abb. 4.27).

4.3  Ihr eigenes IT-Rahmenwerk

101

Abb. 4.27  Das nutzen- und strategieorientierte IT-Portfolio

Es ist in der Abbildung deutlich zu sehen, dass alle 4 Beispielprojekte (P1.1, P1.2, P1.3 und P2) im Portfolio einen anderen Platz eingenommen haben. So ist das Teilprojekt P1.1 z.  B. ein „Einführungsprojekt von SAP in Auslandsstandorten“ in dem rechten oberen Quadranten als „kostensenkendes und wertsteigerndes Projekt“ klassifiziert worden. Im Gegensatz zu P2 (DMS-Einführung), welches ebenfalls in diesem Quadranten dargestellt wurde, ist bei P1.1 der Nutzen für das Unternehmen bzw. der ROI nicht so hoch wie bei der DMS-Einführung. Diese Einteilung kann auf klaren Berechnungen basieren, bei der Einführung des Portfoliomanagements allerdings kann dies auch auf subjektiven Meinungen der Gremien basieren, die natürlich argumentativ festgehalten werden müssen. In diesem Fall ist es so, dass das Portfoliogremium (mehr zur Zusammensetzung eines solchen Gremiums im Abschnitt „Organisatorische Einbindung“ am Ende des Dokumentes) entschieden hat, dass die DMS-Einführung einen größeren Nutzen hat als die SAP-­Einführung in den Auslandsstandorten, da aktuell alle Dokumente manuell in Ordnern abgelegt werden und die Buchungen zwar im SAP vorhanden sind, aber trotzdem noch physisch aufbewahrt werden müssen. Dies kann automatisiert werden und dadurch können Arbeitsplätze eingespart werden und eine wesentlich effizientere Struktur beim Suchen und Finden von Dokumenten wird ermöglicht. Das Teilprojekt P1.3 (Einführung SAP FI/CO) geht mit den beiden Teilprojekten P1.1 und P1.2 einher und wird ebenfalls gerade noch im oberen rechten Quadranten einsortiert. Allerdings ist hier die Wertsteigerung und die Kosteneinsparung nicht ganz so hoch wie bei den zusammenhängenden Teilprojekten, da die aktuellen Aufwände nicht

102

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

direkt durch die Einführung von SAP FI/CO verringert werden und damit kein direkter ROI sofort erkennbar sein wird. Allerdings muss aufgrund der Abhängigkeit der 3 Teilprojekte gesagt werden, dass sie sich gegenseitig unterstützen und daher nicht weit auseinander im Portfolio klassifiziert werden. Das Projekt P2 (Einführung SEPA) ist im unteren rechten Quadranten einsortiert worden, da es dem Unternehmen strategisch keinen Vorteil bietet, da die bisherige Abrechnung genauso gut funktioniert hat und auf der Kosten- oder Return-Seite ebenfalls keinen Nutzen bringt, sondern nur Geld kostet. Es ist als ­gesetzliche Anforderung zwar durchzuführen, bringt aber im Grunde nur Mehraufwand, der keinen strategischen Nutzen liefert. Projekte, die in diesem Quadranten landen, sollten nach nochmaliger Prüfung möglichst schnell beendet werden, da sie keinen Nutzen liefern und nur Kosten verursachen. In solchen Fällen ist ein Portfolio sehr hilfreich, da es sehr schnell visuell aufzeigt, welche Projekte wirklichen Nutzen liefern und welche Projekte schnell beendet werden können, da sie nur Kosten produzieren, aber keinen Nutzen liefern. Das nutzen- und risikoorientierte IT-Portfolio Häufig wird das Risiko von IT-Projekten zwar in dem jeweiligen Projekt betrachtet, aber häufig nicht im Gesamtkontext aller laufenden Projekte. Das führt leider oft zu einer hohen Quote von gescheiterten IT-Projekten. Deshalb ist eine Risikobetrachtung aller Projekte empfehlenswert. In unserem Beispiel ist in der folgenden Abbildung – in Anlehnung an das nutzen- und strategieorientierte Portfolio – auf der Ordinate wieder der ROI angegeben und auf der Abszisse das Risiko des Projektes. Es wird in diesem Portfolio visuell sehr schnell deutlich, dass alle Projekte durchaus ein Risiko beinhalten, welches größer als 30 % ist. Daher muss bei allen Projekten ein detailliertes Risiko- und Qualitätsmanagement eingeführt werden, um die Risiken im Griff zu behalten (Abb. 4.28). Allerdings ist nur ein Projekt mit einem Risiko des Scheiterns von größer als 50 % im Portfolio zu finden: die Einführung von SAP in den Auslandsstandorten. Wichtig ist bei der Klassifizierung und der Bewertung, welche Art von Risiko dem Projekt zugrunde liegt. Hier ist es nicht so sehr die eigentliche technische Implementierung von SAP in den Auslandsstandorten, sondern die Schulung und anschließende Nutzung von SAP. Das Problem ist die geringe Qualifikation in den Auslandsstandorten in den Fachbereichen, die dann mit SAP arbeiten müssen. Die beste SAP-Installation bringt nichts, wenn die Bedienung und die Funktionen nicht richtig genutzt werden. Daher ist hier insbesondere eine enge und direkte Zusammenarbeit sowohl mit den betroffenen Fachbereichen im Headquarter als auch in den Auslandsstandorten anzuraten, damit das Projekt zum Erfolg werden kann. Phase 3: Der Portfolio-Monitoring-Prozess Nachdem das Projektportfolio erstellt oder auf den neusten Stand gebracht wurde, geht es um die Analyse und das Monitoring der Projekte. Im Rahmen der Überwachung der Projekte stehen folgende Aufgaben an: • Prüfung der Projekte nach den üblichen Projektdreieckfaktoren Zeit, Kosten und Qualität

4.3  Ihr eigenes IT-Rahmenwerk

103

Abb. 4.28  Das nutzen- und risikoorientierte IT-Portfolio

• Prüfung und Einordnung der Projekte nach den 3  in Phase 2 dargestellten Portfolioebenen • Beitrag zur Unterstützung der Unternehmensstrategie • Realisierungsrisiko • Realisierungswahrscheinlichkeit • Treffen von Entscheidungen über die Neueinordnung oder das Weiterführen oder Stoppen von Projekten im Projektportfolio (siehe dazu als Entscheidungsmatrix die folgende Grafik Abb. 4.29) Nachdem die Entscheidungen getroffen wurden, müssen diese mit den daraus abgeleiteten Maßnahmen an alle Betroffenen kommuniziert werden (wichtig ist hier die Einbindung aller im Fachbereich Betroffenen, sofern sie nicht an der Entscheidung beteiligt waren). Phase 4: Projektende: Abnahme und Bewertung In der letzten Phase des Projekt-Portfolio-Prozesses geht es um den Abschluss von Projekten. Auch hier werden wieder 4 Teilschritte betrachtet: • Die offizielle Übergabe des Projektes an den Fachbereich • Der offizielle Projektabschluss: Das Projekt muss final vom Fachbereich bewertet und abgenommen werden; erst dann kann das Projekt in der IT als offiziell beendet betrach-

104

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

Abb. 4.29 Projektentscheidungen

tet werden und es geht in den Betrieb über, der durch einen Wartungsvertrag die weitere Unterstützung der zugrunde liegenden Applikation regelt • Abweichungen und Erfolge messen: nach dem offiziellen Abschluss müssen noch ausstehende Abweichungen festgehalten werden • Lessons Learned: In einer von Offenheit geprägten Workshoprunde werden wichtige Erkenntnisse diskutiert und Maßnahmen für Folgeprojekte daraus abgeleitet. Damit ist der Prozess der Portfoliobetrachtung von IT-Projekten abgeschlossen. Organisatorische Einbindung Die Verantwortung für den Projektportfoliomanagement-Prozess sollte direkt dem CIO oder IT-Leiter unterstellt sein und als Stabsstelle fungieren. Nur durch die direkte Anbindung an den CIO kann die Effizienz sichergestellt werden und politische Grabenkämpfe können proaktiv ausgeschlossen werden. Neben der direkten CIO-Verantwortung ist die enge Einbindung der Fachbereiche erfolgskritisch. Dies erfolgt durch ein Gremium oder Komitee, welches regelmäßig tagen muss. Wichtig ist die Kommunikation und Transparenz der Entscheidungen aus dem Portfoliokomitee. Jeder Mitarbeiter muss wissen, welche Projekte aus welchem Grunde priori-

4.3  Ihr eigenes IT-Rahmenwerk

105

siert wurden. Dies ist die tägliche Arbeits- und Motivationsbasis im Projektgeschäft einer IT-Organisation.

4.3.4 IT-Architektur So wie Prince2 für Projektmanagement der Standard ist, so hat das IT-Architektur­ management TOGAF. Die Abkürzung TOGAF steht für „The Open Group Architecture Framework“ und bietet laut Wikipedia [5] „einen Ansatz für Entwurf, Planung, Implementierung und Wartung von Unternehmensarchitekturen“. Das Framework TOGAF wird von der Open Group kostenfrei angeboten. Eine IT-­ Architektur nach TOGAF basiert auf 3 unterschiedlichen Ebenen, den sogenannten Domänen: 1. Geschäftsarchitektur 2. Informationssystemarchitektur (bestehend aus Anwendungsarchitektur und Datenarchitektur) 3. Technologiearchitektur Angelehnt an Wikipedia [5] betrachtet die Geschäftsarchitektur primär die Strategie, die Aufbauorganisation, die Geschäftsprozesse und die Geschäftsfähigkeiten. Die Informationssystemarchitektur besteht aus der Datenarchitektur, in der die Daten mit ihren Beziehungen, die für die Durchführung der Geschäftsprozesse benötigt werden, identifiziert und beschrieben werden. Daneben ist in der Informationssystemarchitektur die Anwendungsarchitektur vorhanden, in der die Anwendungen verwaltet werden, die für die Ausführung der Geschäftsprozesse erforderlich sind. Neben der Bestandsführung aller Anwendungen werden auch die Beziehungen und Schnittstellen zwischen den Anwendungen im Rahmen der Anwendungsarchitektur betrachtet. Die Anwendungen werden anhand ihrer fachlichen Funktionalität und der durch sie verarbeiteten Informationen kategorisiert. Zum Schluss beschreibt die Technologiearchitektur die Architekturelemente für Aufbau und Betrieb der IT-Infrastruktur. Sie definiert die Basis, auf der Anwendungen beschafft, integriert und betrieben werden können. Diese Basisarchitekturen können, je nach Sichtweise, um weitere Architekturen ergänzt werden, beispielsweise die Sicherheitsarchitektur (Beschreibung der Sicherheitsprozesse, Sicherheitssysteme und die Aufgaben der beteiligten Organisationseinheiten mit der die für die Organisation geeignete Informationssicherheit erreicht wird) und die Betriebsarchitektur (Betrieb und Verwaltung der Software, Hardware und Kommunikationsinfrastruktur). Es sei an dieser Stelle das grob skizzierte TOGAF-Framework für die Arbeit an der IT-Architektur empfohlen. Weitergehende Informationen finden Sie kostenlos bei https:// www.opengroup.org/togaf (aktuell ist dort die Version 9.2 herunterladbar).

106

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

4.3.5 IT-Entwicklung und -Bereitstellung Bei der Softwareentwicklung lassen sich diverse Vorgehensmodelle unterscheiden. Die Abb. 4.30 zeigt 8 verschiedene Möglichkeiten, Software zu entwickeln und differenziert dabei nach dem Grad der Formalisierung im Vorgehensmodell und der Geschwindigkeit. Es zeigt sich, dass die agilen und prototypenbasierten Vorgehensmodelle den klassischen Modellen wie Wasserfall- und V-Modell deutlich in der Geschwindigkeit überlegen sind. Auch in Bezug auf den Grad der Formalisierung sind die neuen Softwareentwicklungsmodelle deutlich informeller und einfacher zu handhaben. Trotzdem macht es je nach Anforderungssituation und Komplexität Sinn, genau hinzuschauen welches dieser Vorgehensmodelle die größte Erfolgswahrscheinlichkeit hat. SCRUM und KANBAN wurden in diesem Buch ausführlich im Rahmen der modernen Organisationsformen vorgestellt (siehe Abschn. 3.4 und 3.4.1.2). Zu den anderen Vorgehensmodellen kann man im Internet kostenfrei sehr viele Informationen bekommen, sodass an dieser Stelle auf eine detaillierte Beschreibung verzichtet wird.

hoch

KANBAN SCRUM

inkrementell

XP

niedrig

Geschwindigkeit

RUP Sprialmodell

V-Modell

hoch

Wasserfall

Formalisierungsgrad

Abb. 4.30  Vorgehensmodelle bei der Softwareentwicklung

niedrig

4.3  Ihr eigenes IT-Rahmenwerk

107

4.3.6 IT-Service-Management Wenn es um das IT-Service-Management geht, hat sich ITIL schon seit vielen Jahren zu dem Alleinstandard entwickelt. Auf ITIL ist bereits Abschn. 4.2.1.2 eingegangen. Daher sind an dieser Stelle, wenn es um die individuelle Betrachtung der unternehmenseigenen IT-Prozesse geht, nicht alle ITIL Prozesse da-gestellt, sondern es sind die aus Sicht des Autors 5 wesentlichen ITIL-Prozesse ganz kurz erläutert. Denn diese sind aus Erfahrungswissen zumindest für mittelständische Unternehmen die wesentlichen Treiber zu mehr Effizienz im IT-Service-Management: • • • • •

Support Strategy Incident-Management Problemmanagement Change-Request-Management Configuration-Management

In diesem Kontext kann als Beispiel das Thema IT-Helpdesk dienen. Dieses ist oft noch so geregelt, dass jeder IT-Mitarbeiter an das Telefon geht und sich um Störungen oder Probleme kümmert. Dies ist in den meisten Unternehmen historisch so gewachsen, führt aber dazu, dass viele IT-Mitarbeiter ständig aus ihrer Arbeit herausgerissen werden. Gerade IT-Experten als Wissensarbeiter brauchen Ruhe, um konzentriert arbeiten zu können oder müssen in Teams Projekte voranbringen. Eine Lösung für dieses Problem kann z. B. durch klare Servicedefinitionen, wie es in ITIL in der Support Strategy zu finden ist, gefunden werden. Damit können sehr schnell Effizienzgewinne realisiert werden, wie beispielsweise: • Eine „first-time-solution-rate“ von z. B. 60–70 %, das heißt: 60–70 % aller eingehenden Störungsanrufe können sofort behoben werden • Das „Schichtproblem“ und die „halb-legale“ Bereitschaft der IT-Mitarbeiter nachts und am Wochenende wäre legalisiert • Erhöhung der Kundenzufriedenheit • Jedes Problem/Störung wird dokumentiert und ist für jeden (IT und Fachbereich) transparent und nachvollziehbar • Reports und Statistiken sind möglich, zur besseren Führung und Steuerung des Service Desks • Klar definierte SLAs (Service Level Agreements), mit der Möglichkeit diese mit Pönalen bei Unterschreitung zu ahnden Darüber hinaus sind in dem Kontext die Definition und Auflistung aller im Unternehmen erforderlichen IT-Services, deren zugehörige IT-Systeme und Systemverantwortlichen eine sehr sinnvolle Aufgabe.

108

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

Hilfreich ist es auch, wenn jeder IT-Service einer Wartungsart zugeordnet ist, d. h. wie oft und wann wird ein solcher IT-Service gewartet und gepflegt. Dies sollte auf Basis der Kritikalität des dem IT-Service zugrunde liegenden Geschäftsprozesses erfolgen.

4.3.7 IT-Operations Neben dem reinen IT-Service-Management beschäftigt sich die IT-Operations oder im deutschen der IT-Betrieb mit der Bereitstellung und Wartung von Hardware und Software. Dazu zählen auch die folgenden Prozesse, die hier nicht in aller Vollständigkeit, sondern als exemplarische IT-Prozesse dargestellt werden: • • • •

Operations Planning & Strategy Monitoring & Reporting Infrastructure, Network & Datacenter Business Continuity Management/Notfallplanung

4.4

I T-Personal und Rollen: Die für die IT-Prozesse richtigen Rollen definieren

4.4.1 Die erste Berichtsebene des CIOs Eine ausführliche Rollenbeschreibung des CIOs ist in einem eigenen Kapitel dieses Buches vorgenommen worden (Abschn.  3.4.4). Hier geht es um die erste Berichtsebene des CIOs. Klassischerweise hat der CIO 3 oder 4 Direct Reports, die im Allgemeinen entweder nach Plan, Build, Run aufgestellt sind und klassisch nach Anwendungsentwicklung, Operations & Infrastruktur sowie evtl. Prozesse/Organisation oder Projektmanagement. Das ist noch heute im Mittelstand vielfach anzutreffen. Die Abb. 4.31 zeigt dies beispielhaft. Darüber hinaus gibt es Assistenzfunktionen und Stabsfunktionen für die Themen Controlling, Finanzen, Recht, Einkauf sowie Strategie und Governance. Je nach Größe des Unternehmens kann dies in einer Person bzw. Rolle aufgehen oder bei großen Konzernen gibt es dafür jeweils eine Rolle oder sogar noch mehr. In den heutigen Zeiten der digitalen Transformation haben sich darüber hinaus 2 Rollen als sehr wichtig für den CIO erwiesen. Das ist zum einen der IT-Chefarchitekt (siehe dazu die Rollenbeschreibung in der Abb. 4.32), da die Systemlandschaft in den Jahren immer komplexer geworden ist. Zum andern ist dies der CISO (siehe dazu die Rollenbeschreibung in der Abb. 4.33), der Chief Information Security Officer als Zuständiger für IT- und Cyber-Security. Ein auch immer wichtiger werdendes Feld in einer modernen ­IT-­Organisation.

4.4  IT-Personal und Rollen: Die für die IT-Prozesse richtigen Rollen definieren

109

Führungskraft PLAN / BUILD / RUN Stellenziele: 

Disziplinarische und fachliche Führung der Mitarbeiter



Strategische Ausrichtung, Organisation und Führung der Abteilung

Aufgaben 

Führen der Mitarbeiter im IT-Bereich



Personal-, Budget- und Ergebnisverantwortung



Evaluierung neuer Technologien und deren Einsatz für die kontinuierliche Optimierung



Ansprechpartner und Koordinator für externe IT-Dienstleister



PLAN: Verantwortlich für das Anforderungs- und Portfolio-Management sowie erster Ansprechpartner für alle Fachabteilungen.



BUILD: Verantwortlich für die Definition und Pflege der Softwareentwicklungsprozesse



RUN: Verantwortlich für den Betrieb und die Sicherheit der gesamten ITOperations / Verantwortlich für das reibungslose IT Service Management

Abb. 4.31  Führungskraft Direct Report zum CIO

4.4.2 IT-Strategie und IT-Governance Im Bereich IT-Strategie und -Governance sind die typischen Stabsfunktionen des CIOs gegliedert. In der Abb. 4.34 ist die Rolle des IT-Controllers dargestellt. Eine weitere wichtige Rolle in diesem Cluster ist die des Referenten für IT-Governance und in diesem Beispiel auch für IT-Einkauf (siehe dazu die Abb. 4.35). Der Einkauf von IT-Dienstleistungen sowie Hard- und Software kann natürlich auch durch den Zentraleinkauf des Unternehmens erfolgen, aber hier ist bewusst eine Rolle geschaffen worden, die sich innerhalb der IT explizit damit beschäftigt, aber natürlich die fachlichen Vorgaben des Zentraleinkauf einhält. Es sind darüber hinaus in großen Unternehmen weitere Rollen denkbar, wie z. B.: • Referenten für IT-Stratege • Provider-Manager

110

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

IT Chefarchitekt Stellenziele: 

Skalierbare und zukunftsfähige IT-Architektur für das Unternehmen etablieren



Kundenorientiertes und agiles Agieren im Rahmen eines strategischen Bebauungsplanes

Aufgaben 

Leitung des IT-Architekturteams



Research zu neuen Technologien und Produkten



Dokumentation der Ist- und Soll- IT Systemlandschaft



Fachliche Führung der Solution Architekten



Verantwortung für das technischen Designs der IT-Lösungen

Headcount:  FTE

Abb. 4.32  Der IT-Chef-Architekt

• • • •

Organisations- und Transformations-Manager Asset- und Lizenz-Manager Qualitäts-Manager HR- und Skill-Manager

4.4.3 Demand-Management Im Cluster Demand- bzw. Anforderungsmanagement steht der Anforderungs-Manager wie in Abb. 4.36 beispielhaft als Rolle skizziert, im Vordergrund. Der Anforderungs-Manager hat vielfach unterschiedliche Bezeichnungen. So trifft man häufig auf den Inhouse Consultant, den Process Consultant, den Design Expert, Requirements Engineer und vermutlich noch viele andere Bezeichnungen. Allen gleich bzw. ähnlich ist die Aufgabe des Anforderungsmanagements, der Konzeption, der Wirtschaftlichkeitsbetrachtung und der Schnittstelle zwischen IT und Fachbereichen. Ein Beispiel für einen Inhouse Consultant im Vergleich zum Anforderungs-Manager ist in Abb. 4.37 zu sehen.

4.4  IT-Personal und Rollen: Die für die IT-Prozesse richtigen Rollen definieren

CISO – Chief Information Security Officer Stellenziele: 

Vorausschauendes IT Sicherheitsmanagement unter Beachtung der Erzielung des optimalen Nutzens



Erzielung von vertraglichen Leistungsvereinbarungen mit IT Vertragspartnern

Aufgaben 

Sie etablieren ein Informationssicherheits-Managementsystems (ISMS), definieren Schutzziele und erstellen Informationssicherheitsvorgaben



Sie verantworten den Informationssicherheitsprozess



Sie schätzen Gefährdungen ein, führen Schutzbedarfs- und umfassende Risikoanalysen durch, leiten erforderliche Informationssicherheitsmaßnahmen ein und überprüfen deren Wirksamkeit.



Sie sind zentraler Ansprechpartner für Meldungen und Fragen zum Thema



Sie managen Vorfälle in der Informationssicherheit, Schwachstellen und Gefährdungen und erarbeiten hierfür passende und praktikable Lösungen.



Sie initiieren und koordinieren Sensibilisierungs- und Schulungsmaßnahmen. Sie berichten regelmäßig an den Vorstand und beraten diesen in Angelegenheiten der Informationssicherheit und berichten an das Informationssicherheits-Team über Status, Risiken und Sicherheitsvorfälle

Abb. 4.33  CISO – Chief Information Security Officer

111

112

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

IT-Controlling und Recht Stellenziele: 

Vorausschauendes Kostenmanagement unter Beachtung der Erzielung des optimalen Nutzens



Erzielung von vertraglichen Leistungsvereinbarungen mit IT Vertragspartnern

Aufgaben 

Kostenmanagement mit Kostenarten-, stellen und – trägern



Mitwirkung bzgl. der Wirtschaftlichkeit/TCO Ermittlung von IT Strategien

 

Verursachungsgerechte Kostenzuordnung zu den Kunden der IT Prognose der Investitions- und Betriebskosten, Verifizierung von Kostentreibern



Entwicklung und Verfolgung von Kennzahlen für IT Systeme und Prozesse



Aufbau eines Lizenzmanagements



Erstellung und Abstimmung von IT-Verträgen (Projekte, Geheimhaltungsvereinbarungen, Betriebsführung/SLA`s)



Mitwirkung bei Themen des Datenschutzes

Headcount: FTE Abb. 4.34 IT-Controller

In einigen Unternehmen findet man auch den sogenannten Business-Relationship-­ Manager (BRM) und in einer Führungsfunktion den sogenannten DIO (Divisional ­Information Officer), angelehnt an den CIO, der die Verantwortlichkeit unterhalb des CIOs für eine bestimmte Division bzw. Geschäftsbereich trägt. Ebenfalls zu diesem Cluster gezählt werden sollte der Lösungsarchitekt oder Solution Architect. Denn er bildet auch das Bindeglied zwischen Demand und Supply und kann von der funktionalen Beschreibung bis zur Umsetzung die fachlichen Anforderungen vollständig überblicken, bewerten und schlussendlich entscheiden, welche Software für welche Anforderungen idealerweise einzusetzen ist.

4.4  IT-Personal und Rollen: Die für die IT-Prozesse richtigen Rollen definieren

113

IT-Einkauf / IT-Governance Stellenziele: 

Koordination der Beschaffungen in der IT und Schnittstelle zum Zentraleinkauf



Marketingmaßnahmen für die Corporate IT zur Schaffung von Transparenz über Projekte und Aufgaben der IT sowie als Kommunikationskanal zu den Usern



Sicherstellung und Pflege aller relevanten IT Dokumentationen

Aufgaben 

IT-Einkauf: Koordination aller Beschaffungsvorgänge in der IT, projektbezogene Ausschreibungen begleiten, Prüfung von eingehenden Lieferungen für die IT, Rechnungsprüfung mit IT-Controlling, Schnittstelle zur Abteilung Zentraleinkauf

 

Verwalten des IT-Bereichs im hauseigenen Intranet Vorbereitung, Verfassen, Interviews, Korrektur und Versenden des ITNewsletters



Pflegen und Erstellen der notwendigen Governance-Dokumente (z. B. Book of Standards)

Headcount:  FTE

Abb. 4.35 IT-Einkauf/IT-Governance

4.4.4 Projektmanagement Im Vordergrund steht natürlich der Projekt-Manager, wie er beispielhaft in Abb. 4.38 dargestellt ist. Auch hier bietet Prince2 oder die Gesellschaft für Projektmanagement in Deutschland zahlreiche Zertifizierungen mit unterschiedlichsten Qualifikationen an und dementsprechend natürlich auch unterschiedliche Rollenmodelle. Neben dem Projekt-Manager ist der Portfolio-Manager eine wichtige Rolle für das strategische Management aller Projekte (Abb. 4.39). Auch die Projektassistenz als PMO (Project Management Office) ist hier wichtig und wird in (Abb. 4.40) beschrieben.

114

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

Anforderungsmanager (Beispiel End-to-End-Prozess: Plan-to-Ship oder Produktion / Logistik) Stellenziele: 

Aufnahme, Aufbereitung, Bewertung und Vermittlung von IT-Anforderungen aus dem Bereich Logistik, Produktion



Prozessmanagement für den Fachbereich Produktion und Logistik



Projektleitung ausgewählter Themen

Aufgaben 

Entwicklung der Prozessstrategie und der Geschäftsprozesslandkarte



Leitung von Projekten zur Einführung, Anpassung oder Ablösung von Systemen zur Unterstützung von Logistik- und Produktionsprozessen



Anforderungsmanagement i. S. von Aufnehmen von Veränderungsbedarfen in der Prod/Logistik, Priorisierung, Ressourcenplanung sowie Kommunikation und Abstimmung mit den Fachbereichen Prod/Log und IT/BUILD



Planen und Modellieren von Prozessen



Simulation und Kosten- sowie Kennzahlenplanung sowie –tracking von Prozessen im Bereich Prod/Log (Prozesscontrolling), inkl. Potentialanalysen von Prozessen



Präsenz in den Gremien der Prozessverantwortlichen für Prod/Log

Headcount:  FTE Abb. 4.36 Anforderungs-Manager

Darüber hinaus gibt es Rollen wie den Projekt-Controller oder den Projekt-Coach oder Facilitator.

4.4.5 IT-Architektur, Innovation und Digitalisierung Auf der Architekturebene können 2 verschiedene Rollen differenziert werden: • Der Enterprise-Architekt • Der Applikationsarchitekt

4.4  IT-Personal und Rollen: Die für die IT-Prozesse richtigen Rollen definieren

115

IT Inhouse Consultant (End-to-End-Prozess: Plan-to-Ship oder Produktion / Logistik) Stellenziele: 

Standard-Anpassungen an den IT-Systemen koordinieren und vornehmen



Projektleitung ausgewählter Themen

Aufgaben 

Leitung von Projekten zur Einführung, Anpassung oder Ablösung von Systemen zur Unterstützung von Logistik- und Produktionsprozessen (SCM)



Verfolgung von technologischen Trends um Mehrwert zu generieren (hier z. B. Industrie 4.0, Digitale Fabrik, etc.)



Koordination von Change Requests (CRs) mit den Key Usern



Unterstützung von ERP-Releases und Koordination der prozessseitigen Themen



Konfiguration i.S. von Customizing oder Parametrisierung, Durchführung von Roll-outs, Weiterentwicklungen, Abstimmungen mit externen Beratern



2nd level support für alle IT-Systeme im Prozessbereich Prod/Log



Vertreter im CAB (Change Advisory Board) für alle CRs aus Prod/Log

Headcount:  FTE

Abb. 4.37  Inhouse Consultant

Der Enterprise-Architekt ist verantwortlich für Entscheidungen über die ganze IT-­ Systemlandschaft. Dazu zählen z. B. Entscheidungen zu Architekturrahmenwerken (sog. Frameworks), der Art wie Architektur betrieben wird (z. B. serviceorientiert), aber auch zu Entwicklungsumgebungen trifft er die Entscheidungen und vor allem zu allen Systemen der IT-Landkarte und er pflegt den Bebauungsplan systemübergreifend. Der Applikationsarchitekt (auch Systemarchitekt genannt) ist verantwortlich für Architekturentscheidungen für eine ganz bestimmte Applikation bzw. ein IT-System (z. B. SAP). Auf dieser Ebene ist er auch verantwortlich für die Applikationsarchitektur, beispielsweise für alle Untersysteme des SAP-Systems sowie deren Schnittstellen und Datenmanagement. Des Weiteren gibt es vielfach andere Rollen, die Ähnliches bedeuten. So z. B. den Lösungsarchitekten (Solutions-Architekt). Dieser ist oftmals für eine bestimmte Businesslösung über mehrere Softwaresysteme hinweg verantwortlich.

116

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

IT Projektleiter Stellenziele: 

Leitung von Projekten zur Einführung, Anpassung oder Ablösung von ITSystemen mit den folgenden Kernaufgaben:

Aufgaben 

Projektdefinition: Aufsetzen von IT-Projekten mit den Themen Ziel, Auftrag klären, Budget, Zeitrahmen, Konzeption der Anforderungen



Durchführung der Projektplanung (Setzen von Meilensteinen und Aktivitäten, Aufwandschätzung)



IT-Projektorganisation im Sinne der beteiligten Rollen im Projekt, der Governance (z. B. Lenkungsausschuss), Kommunikationsverhalten und Regeln der Zusammenarbeit festlegen



IT-Projekte führen und steuern: Fachliche Führung der Projektmitarbeiter



Projektcontrolling/ Statusprüfung (Ermittlung der Ist-/ Soll-Abweichungen im Projekt und Information über den Stand des Projektes)



Eskalation von Konfliktsituationen, wenn die Termin- oder Kostenvorgaben nicht eingehalten werden



Einhaltung der terminlichen und wirtschaftlichen Projektziele gemäß Projektauftrag innerhalb der vorgegebenen Rahmenbedingungen



Rechtzeitige Information des Projektausschusses bei Gefährdung der ProjektTermine und Vorschlag geeigneter Maßnahmen zur Gegensteuerung

Abb. 4.38 Projekt-Manager

Im Bereich der Digitalisierung und neuer Technologien tun sich eine Menge neuer Jobprofile und Rollen auf. Darunter kann beispielhaft der Big Data Expert oder Business/ Data Scientist oder ein IoT-/KI-Experte sein. Insbesondere im SCRUM-Umfeld gibt es folgende Rollen, die hier nicht weiter beschrieben werden sollen, aber bei Bedarf zur Einstimmung und weiteren Recherche dienen können: • Product Owner • Scrum Master

4.4  IT-Personal und Rollen: Die für die IT-Prozesse richtigen Rollen definieren

117

Portfolio-Manager Stellenziele: 

Strategisches Monitoring und Tracking des IT-Portfolios



Ansprechpartner für alle Fachbereiche in Bezug auf die Gesamtsicht aller ITProjekte (beratend und methodisch)

Aufgaben 

Entwicklung des IT-Portfolioprozesses sowie Mitarbeit bei der Operationalisierung der Portfoliostrategie



Vereinbarung und Anwendung von Auswahlkriterien für die Aufnahme und Herausnahme von Projekten des gemeinsamen Geschäftsfeld-übergreifenden Projektportfolios



Die Zusammenstellung, Priorisierung und Steuerung des Portfolios nach vereinbarten Kriterien in Zusammenarbeit mit den relevanten Stakeholdern



Durch Analysen, Portfolio-Monitoring, Stakeholdermanagement und Know How Transfer schafft der IT-Portfolio Manager Transparenz und Konsistenz sowie Konformität zwischen Konzernstrategien und Interessen der Geschäftsfelder



Ableitung von neuen Projekten und Programmen

Abb. 4.39 Portfolio-Manager

• • • • • • •

Developer DevOps Softwarearchitekten UX-Designer/Usability Experts Field Experts Chief Product Owner Agile Coach

4.4.6 IT-Entwicklung/-Bereitstellung Im Bereich IT-Entwicklung und -Bereitstellung können grob 3 Rollen differenziert werden:

118

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

PMO (Project Management Office) Stellenziele: 

Tracking von Budget und Time bei allen IT-Projekten



Ansprechpartner für alle Projekt Stakeholder

Aufgaben 

Verantwortlich für das Erstellen, die Pflege und die Schulung sowie bei allen Fragen rund um das IT Projektmanagementvorgehensmodell



Pflege und Erstellung von allen Vorlagen und Dokumenten zum IT Projektmanagement



Tracking von Projektzielen und Projektmeetings / Meilensteinen



Tracking von Budget und Time bei allen IT Projekten



Sparringspartner für IT Projektleiter



Aufsetzen und Pflege sowie Tracking des Projektportfoliomanagements / Information und Bereitstellung des PPM an das Management

Abb. 4.40  PMO (Project Management Office)

• Applikationsdesigner • Applikationsentwickler • Testspezialist

4.4.7 IT-Service-Management Das Service-Management in der IT ist geprägt von den ITIL-Rollen. Diese sind auf Basis der IT Process Map von Andrea und Stefan Kempter sehr übersichtlich dargestellt und umfassen insgesamt 34 Rollen [6], die auch in der Abb. 4.41 dargestellt sind. Es ist davon auszugehen, dass nur in großen Konzernen diese Anzahl von über 30 Rollen allein für das Service-Management der IT wirklich gelebt werden wird. In mittelständischen Unternehmen sind meistens nur einige wenige Rollen wirklich notwendig und sinnvoll. Diese Rollen übernehmen dann Teile der anderen Rollen mit, da diese nicht so viel Gewicht in der Organisation haben und damit auch nicht so viel Zeit kosten. Die wesentlichen Rollen aus dem ITIL v4-Kontext sind die folgenden (angelehnt an [6]):

4.4  IT-Personal und Rollen: Die für die IT-Prozesse richtigen Rollen definieren

Abb. 4.41  Alle ITIL-Rollen in der Übersicht (ITIL v4)

119

120

4  Die Ablauforganisation der IT – Welche IT-Prozesse und Strukturen braucht eine …

Incident-Manager Der Incident-Manager ist verantwortlich für die effektive Durchführung des Incident-­ Management-­Prozesses und führt das entsprechende Berichtswesen durch. 1st Level Support Der Bearbeiter im 1st Level Support sorgt bei eingehenden Störungsmeldungen für die Registrierung und Einordnung und unternimmt einen unmittelbaren Lösungsversuch zur schnellstmöglichen Wiederherstellung des definierten Betriebszustands eines Service. 2nd Level Support Der Bearbeiter im 2nd Level Support übernimmt Störungsmeldungen vom 1st Level Support, die dieser nicht selbstständig lösen kann. Ziel ist die schnellstmögliche Wiederherstellung des definierten Betriebszustands eines Service. Change-Manager Der Change-Manager autorisiert und dokumentiert sämtliche Änderungen an der IT-­ Infrastruktur und ihrer Komponenten (Configuration Items), um störende Auswirkungen auf den laufenden Betrieb so gering wie möglich zu halten. Release-Manager Der Release Manager ist verantwortlich für die Planung und Überwachung der Überführung von Releases in die Test- und Live-Umgebungen.

4.4.8 IT-Operations Folgende Rollen sind im Bereich IT-Operations von Bedeutung: • • • • • • • •

Anwendungsbetreuer/Manager Systemadministrator Operator Arbeitsplatztechniker Mitarbeiter Service Desk IT-Service-Desk-Manager IT-Quality-Manager IT-Service-Manager

Auf eine weitergehende Stellenbeschreibung wird hier verzichtet, da diese im oben genannten ITIL-Rollenmodell sehr übersichtlich dargestellt werden.

Literatur

121

4.4.9 Schnittstellen und Entscheidungsrechte der IT-Rollen Um die Schnittstellen und Entscheidungsrechte der beschriebenen Rollen deutlich zu machen, kann eine sogenannte RACI-Matrix sehr hilfreich sein. RACI bedeutet: • Responsible: Sie sind verantwortlich im Sinne der Durchführungsverantwortung, also Sie führen diese Aufgabe dann aktiv durch. • Accountable: Sie sind rechenschaftspflichtig, also kosten- oder gesamtverantwortlich für das Thema. • Consulted: Das sind die Personen, die dann konsultiert werden bei Fragen, bei spezifischen Themen. • Informed: Diese Personen oder diese Rollen sind zu informieren, wenn dieser Prozessschritt oder diese Tätigkeit eintritt. Aufbau der RACI-Matrix Und Sie können sich eine RACI-Matrix als eine klassische Tabelle vorstellen, in der Sie auf der linken Seite erst mal die einzelnen Aufgaben untereinander auflisten und dann oben in der Horizontalen die ganzen Rollen auflisten und dann in dieser Matrix quasi zuordnen, welche Rolle hat bei welcher Aufgabe jetzt ein R, ein A, ein C oder ein I. So können Sie eigentlich recht schnell auch visualisieren, wie die Verantwortlichkeiten denn aufgeteilt sind. Das heißt, mit dieser RACI-Matrix haben Sie ein Tool, einen Mechanismus, wie Sie recht schnell visualisieren können, wie die Verantwortlichkeiten tatsächlich aussehen sollen. Und die kann man eben nach dieser Matrix dann auch entsprechend leben.

Literatur 1. ISACA: „COBIT 5: Rahmenwerk für Governance und Management der Unternehmens-IT“, abgerufen unter isaca.org durch Anmeldung als Member. Abgerufen am 15.01.2020. 2. Capgemini: „IT-Trends 2019“, https://www.capgemini.com/de-de/wp-content/uploads/­ sites/5/2019/02/IT-Trends-Studie-2019.pdf, abgerufen am 28.12.2019. 3. AXELOS/TSO (The Stationery Office): „ITIL Foundation, ITIL v4“, 1.  Auflage, AXELOS/ TSO 2019. 4. Gadatsch, A.: IT-Controlling, Praxiswissen für IT-Controller und Chief Information Officer, 1. Auflage, Springer Verlag, 2012. 5. Urbach, Ahlemann: (2017). Die IT-Organisation im Wandel: Implikationen der Digitalisierung für das IT-Management. HMD Praxis der Wirtschaftsinformatik. 54. 300–312. 6. Kempter, Andrea und Kempter, Stefan: „Rollen it ITIL | IT-Process-Map“, https://wiki.de.it-­ processmaps.com/index.php/Rollen_in_ITIL, abgerufen am 29.12.2019.

Teil III Die Rolle der IT und des CIOs im Unternehmen

5

Die Rolle der IT im Unternehmen

Zusammenfassung

Die IT ist einer der wesentlichen Erfolgsfaktoren für Unternehmen im digitalen Zeitalter. Es werden in diesem Kapitel die Treiber und Einflussfaktoren für eine IT-Organisation dargestellt und auf Basis einer Standortbestimmung und den Erwartungshaltungen an die IT auch die neue Rolle der IT in einer digitalen Welt ausführlich beschrieben.

5.1

Treiber und Einflussfaktoren der IT-Organisation

Bevor die Rolle der IT im Unternehmen definiert werden kann, muss klar sein, welches die Treiber und Faktoren sind, die eine IT-Organisation in der heutigen Zeit beeinflussen. Dabei begegnet die IT-Organisation mannigfaltigen Herausforderungen  – sowohl von ­außen in Form des Marktdrucks als auch von innen durch die Fachbereiche und die Geschäftsleitung. Die folgenden 5 Herausforderungen stechen dabei in den 2020er-­ ­ Jahren hervor: • • • • •

Digitalisierung und neue digitale Geschäftsmodelle Agilität, Dynamik und kollaboratives Arbeiten Consumerization der IT und IT-Security Künstliche Intelligenz, IoT und Cloud Computing Talente und Experten finden und halten

Im Folgenden werden diese Herausforderungen genauer untersucht im Hinblick auf das Veränderungspotenzial für die IT.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 V. Johanning, Organisation und Führung der IT, https://doi.org/10.1007/978-3-658-12008-5_5

125

126

5  Die Rolle der IT im Unternehmen

5.1.1 Digitalisierung und neue digitale Geschäftsmodelle Wie in der Abb. 5.1 dargestellt, kann die Digitalisierung auf 3 Ebenen differenziert werden: • Digitale Prozesse • Digitale Produkte • Digitale Geschäftsmodelle Im unteren Feld der Abbildung ist jeweils die Rolle der IT dargestellt und es werden die Ziele und Beispiele für diese 3 Ebenen der Digitalisierung abgebildet. Wichtig ist in ­diesem Zusammenhang immer die Frage: „Wer im Unternehmen muss sich auf welcher Ebene mit Digitalisierung beschäftigen und wer hat welche Rolle?“ Denn auch wenn jeder betroffen ist, müssen die Verantwortlichkeiten auch im digitalen Zeitalter klar sein. Digitale Prozesse hat es im Grunde schon immer gegeben – daher auch oftmals der Zusatz 4.0, dem offensichtlich schon 1.0, 2.0, vorangegangen sind. Diese begründen die typischen Automatisierungs- und Prozessoptimierungsthemen. Im Grunde war das immer schon Aufgabe der IT, die Automatisierung voranzutreiben. Das geschah und geschieht weiterhin in enger Abstimmung mit den Prozessverantwortlichen oder Fachbereichsleitern. Auf der Ebene der digitalen Produkte ermöglichen neue Technologien wie Sensoren seit einiger Zeit umfangreiche Konnektivität und neue „smarte“ Funktionen. Produkte werden vernetzt, können untereinander kommunizieren oder werden durch Sensortechnologie oder Elektronik „smart“. Dies ist primäre Aufgabe des Produktmanagements bzw. der technischen Entwicklung oder R & D-Abteilung. Die IT ist hier ebenfalls wichtig, denn sie liefert die notwendigen Apps und Service-Portale für die Steuerung und Verwaltung der smarten und vernetzten Produkte.

Abb. 5.1  Die 3 Ebenen der Digitalisierung

5.1  Treiber und Einflussfaktoren der IT-Organisation

127

Das Thema „Digitale Geschäftsmodelle“ ist tatsächlich ein „Game Changer“. Denn auf dieser Ebene entstehen durch geschickte Nutzung der neuen Technologien neue Geschäftsmodelle und Vertriebsansätze, die wirklich revolutionär sein können  – siehe die Plattform-Beispiele Airbnb (größter Vermieter, ohne Hotels oder Häuser zu besitzen) und Uber (größter Mobilitätsanbieter, ohne Autos zu besitzen etc.). Hier müssen die Geschäftsführung und das Topmanagement wirklich verstehen, welche neuen Möglichkeiten sich durch neue Technologien ergeben. Plattformen, Marktplätze, aber auch Vertriebsmodelle wie „pay-per-use“ oder „… as-a-Service“ können das bestehende Geschäft tatsächlich auf einen neuen Level heben. Die IT ist hier in der Rolle des Dienstleisters zur Entwicklung und zum Betrieb von neuen Plattformen oder der Abbildung neuer Vertriebsmodelle in bestehenden Systemen. Festzuhalten bleibt, dass allein durch digitale Produkte und neue digitale Geschäftsmodelle völlig neue Anforderungen auf die IT zukommen. Und neben den beschriebenen Apps, Service-Portalen und Plattformen, die zu planen, entwickeln und betreiben sind, spielt die IT auf einer anderen Ebene eine ganz wichtige Rolle: Sie ist nicht nur der technische Entwickler und Betreiber dieser Systeme, sondern ein Partner und Berater für die Geschäftsführung und das Produktmanagement. Die IT wird darüber hinaus zunehmend Bestandteil des Produktes. So ist z. B. das mit dem Internet verbundene Auto, das sog. Connected Car, ein gutes Beispiel für die Tatsache, dass Autos in Zukunft kleine, rollende Rechenzentren sein werden. Noch übernehmen die technische Entwicklung oder das Produktmanagement viele der eigentlichen IT-Aufgaben, aber in Zukunft muss die IT und ihr CIO hier wesentlich mehr Verantwortung übernehmen. Die IT wird vom Dienstleister für die Bereitstellung von ERP-Systemen zum echten Gestalter des Produktes und Entwickler von neuen Geschäftsmodellen. Eine völlig neue Rolle!

5.1.2 Agilität, Dynamik und kollaboratives Arbeiten Ebenfalls durch Digitalisierung und deren Technologiesprünge hat sich die Form der ­Arbeit und des Zusammenarbeitens vollständig gewandelt (siehe dazu im Detail den ­Abschn. 9.1.2, wo im Rahmen der Leadership Agility der Wandel in der Arbeitswelt ausführlich beschrieben wird). Im Industriezeitalter war der Taylorismus am Beispiel von Ford gekennzeichnet durch Fließbandarbeit und Akkordlöhne. Relativ stupide Arbeiten mussten durchgeführt werden und das Gehirn konnte am Werkstor abgegeben werden. Dies ist einem radikalen Wandel unterworfen, denn gerade in der IT geht es primär um immer neue Wissensleistungen. IT-Mitarbeiter sind Wissensarbeiter und wollen nicht mehr in starren Zeit- und Lohnkonstrukten aus industrieller Vorzeit gefangen sein. Viele produzierende Unternehmen tun sich damit aber auch heute noch sehr schwer. Auch auf der Ebene der Führung ändert sich die Welt radikal: vom Command & Control aus der Zeit der Industrie über das Führen nach Zielen (Management by Objectives – MbO) hin zum Mentoring im Wissenszeitalter. Viele

128

5  Die Rolle der IT im Unternehmen

IT-Leiter tun sich damit noch schwer, denn man hat es noch anders „gelernt“ in den 1990er- und 2000er-Jahren. Auch auf Ebene der Vorgehensmodelle finden radikale Änderungen statt. Beispielhaft sei nur das vielen noch bekannte Wasserfallmodell genannt mit ewig langen Lasten- und Pflichtenheften. Das ist heute gar nicht mehr vorstellbar. Ein Pflichtenheft mir mehr als 200 oder 300 Seiten braucht vermutlich ein Jahr, um final durch zig Instanzen abgesegnet zu werden. Der Inhalt wäre in der heutigen Zeit schon veraltet. Von daher haben SCRUM und andere agile Methoden Einzug gehalten (siehe dazu im Detail Abschn. 5.4). Für die IT und deren Verantwortliche bedeutet dieser Wandel ein Umdenken auf fast allen Ebenen, von der Führung bis hin zu den Vorgehensmodellen wandelt sich die Welt gerade von der etwas sperrigen Industriearbeitsweise hin zur Wissensökonomie mit vollständig anderen Gesetzen.

5.1.3 Consumerization der IT und IT-Security IT ist mittlerweile im Privatbereich aller Anwender gang und gäbe. Jeder Mitarbeiter hat privat mindestes ein Smartphone und einen PC oder Notebook sowie ein Tablet. Man kennt die neuesten Apps und weiß Bescheid über Neuerungen in der IT-Industrie. Das war in den 1990er-Jahren noch Aufgabe der IT, indes tun sich heute viele IT-Abteilungen schwer damit, mit den Usern Schritt zu halten. Natürlich kann der IT-Mitarbeiter nicht jede App kennen, aber die Anforderungen sind insgesamt enorm gewachsen. Hinzu kommt, dass der Mitarbeiter und User im Betrieb sich genauso „frei“ auf seinem Diensthandy als auch dem Dienst-PC bewegen möchte wie im privaten Umfeld. Sicherheitsbedenken stehen der freien Nutzung oftmals diametral gegenüber. Wie soll die IT darauf reagieren: Was darf zugelassen werden, was muss gesperrt werden und warum? IT- und Cyber-Security sind sehr ernste Themen, können sie doch dafür sorgen, dass Unternehmen in der heutigen Zeiten durch Probleme in diesem Bereich von heute auf morgen vom Markt verschwinden können. Früher musste physisch in die Firma eingebrochen werden; heute kann von überall auf der Welt der nächste Hackerangriff drohen, durch den Firmengeheimnisse geklaut oder das ganze Unternehmen lahm gelegt wird. Auch hier muss die IT verantwortbare, verantwortliche Lösungen finden und ihrer Rolle als moderner Gestalter sowie Bewahrer von schützenswerten Daten finden.

5.1.4 Künstliche Intelligenz, IoT und Cloud Computing Neue Technologien wie die künstliche Intelligenz oder IoT sind auf Anwendungsebene in bestehenden oder neuen IT-Systemen sehr wertvolle Hilfsmittel. Beispielhaft kann hier Predictive Maintenance genannt werden oder die Maschine-zu-Maschine-­Kommunikation. Das sind nutzbringende Ergänzungen für Unternehmen.

5.2  Standortbestimmung: Wo steht die IT heute?

129

Auf einer anderen Ebene führen diese neuen Technologien dazu, dass IT gar nicht mehr in der IT-Abteilung stattfindet, sondern im Fachbereich selbst. Denn durch Cloud Computing, wie z. B. bei Salesforce, braucht die Vertriebsabteilung gar nicht mehr die IT. Das Programm muss nicht mehr auf einem Server im unternehmenseigenen Rechenzentrum laufen, nachdem es dort von der IT installiert wurde, sondern der Vertriebsmitarbeiter kauft die Lizenz im Internet und kann sofort loslegen. Das stellt die IT vor vollkommen andere Herausforderungen. Denn spätestens, wenn solche Cloud-Applikationen wachsen, Customizing erforderlich wird und vor allem wenn Schnittstellen zu bestehenden IT-­ Systemen notwendig werden, muss die IT wieder helfen. Auch dies bedeutet für die IT eine neue Rolle: Sie wird nicht mehr als Dienstleister benötigt, muss aber trotzdem dafür sorgen, dass die Systemlandschaft beherrschbar bleibt. Diese Rolle allen bewusst zu machen, ist oft genug schwierig.

5.1.5 Talente und Experten finden und halten Um den umfangreichen neuen Herausforderungen gerecht zu werden, ist gutes Personal in der IT unverzichtbar. Leider herrscht hier in Deutschland weiterhin Mangelware. Viele junge Leute scheuen noch immer das Informatik-Studium und diejenigen, die das Wissen mitbringen, wollen nicht in starren Strukturen aus dem alten Industriezeitalter arbeiten. Nicht nur die IT, sondern auch die Personalabteilung muss hier neue Lösungen finden. Personalmarketing ist eines der großen und wichtigen Felder und Social Media sollte als ein wichtiger Kanal zu potenziellen IT-Experten auf jeden Fall genutzt werden. Auch interne Prämien für die Werbung eines Bekannten oder Verwandten können sehr hilfreich sein in der Rekrutierungsphase. Auf jeden Fall entscheidet das Finden als auch das Halten von IT-Experten zu einem großen Teil über den Erfolg Ihrer IT und damit des gesamten Unternehmens.

5.2

Standortbestimmung: Wo steht die IT heute?

Um die aktuelle Rolle der IT im Unternehmen zu bestimmen, hilft es, in Form einer Reflektion darauf zu schauen, wie die IT im Unternehmen gesehen wird, welche Rolle sie einnimmt und warum. In Abb. 5.2 werden die typischen 5 Entwicklungsstufen der IT dargestellt – vom sogenannten „Technik-Profi“ bis zu einer möglichen Rolle der „IT als Geschäftsmodell“. Es ist nicht als gut oder schlecht zu bewerten, auf welcher Stufe die eigene IT sich befindet, sondern es hängt vom Unternehmenszweck und von anvisierten Zielen ab, auf welcher Stufe sich die IT befinden sollte. Folgende Fragen zur Reflektion helfen dabei, die eigene Ausgangssituation und die eigene Rolle als IT und CIO klar zu erkennen:

130

5  Die Rolle der IT im Unternehmen

Abb. 5.2  Die 5 Stufen der IT vom Technik-Profi zur IT als Geschäftsmodell

• • • • •

Auf welcher Stufe stehe ich aktuell? Was bedeutet das für mich und die IT? Können Stufen übersprungen oder muss Stufe für Stufe erklommen werden? Auf welcher Stufe möchte die Geschäftsleitung die IT sehen? Sieht man dies genauso und wie groß wird die Anstrengung sein, von der heutigen auf die gewünschte Stufe zu gelangen?

Die Beantwortung dieser Frage ist immens wichtig für die Einordnung der Ausgangssituation. Diese wiederum ist ein wichtiges Fundament und Ausgangspunkt für das Erreichen der IT-Vision, die im Anschluss entwickelt wird.

5.3

Erwartungen an die IT-Organisation klären

Neben der Standortbestimmung der eigenen IT ist es sehr wichtig zu erkennen, was von der IT erwartet wird. Folgende Fragen können zur Ermittlung der Erwartungen hilfreich sein: • Wer aus der Geschäftsleitung ist besonders IT- oder digital-affin und will mitreden? • Was sind Themen, die der Geschäftsführung oder dem Vorstand aktuell unter den Nägeln brennen? • Welche sind die größten „Anforderungsabteilungen“, sprich: woher kommen die meisten Anforderungen an die IT und warum? • Wie ist das Ansehen der IT im Unternehmen und bei welchen Stakeholdern ist es am besten und bei wem am schlechtesten und warum? • Wir groß ist die Wertschätzung und Würdigung der IT und deren Leistungen? • Was denkt der Inhaber, der Gesellschafterkreis oder der Finanzinvestor über die IT und wie wichtig sind ihm IT-Themen für die Zukunft?

5.3  Erwartungen an die IT-Organisation klären

131

Die IT-Organisation unterliegt mannigfaltigen Herausforderungen – sowohl von außen in Form des Marktdrucks als auch von innen durch die Fachbereiche und die Geschäftsleitung. Mögliche Ideen und typische Antworten auf die Frage nach den Erwartungen an die IT können folgende sein: • Bessere Kosteneffizienz: Durch die in der IT-Branche anhaltend hohe Innovationsgeschwindigkeit entsteht ein ständiger hoher Kapitalbedarf in der IT-Organisation, zusätzlich muss kontinuierlich Know-how erneuert bzw. hinzugekauft werden • Kundenorientierung: Die Einbindung der IT in die Unternehmenshierarchie gestaltet sich immer schwieriger (Die Rolle der IT im Unternehmen ist zum Teil unklar bzw. die Verantwortlichkeit für IT in der Unternehmensspitze wird oft mit reinem Fokus auf Finanzen/Kosten durch den CFO oder kaufmännischen Leiter wahrgenommen) • Was ist der Wertbeitrag zum Unternehmenserfolg? • Time to Market: Warum ist die Flexibilität & Agilität in der IT nicht so hoch, dass Anforderungen endlich schneller umgesetzt werden können? • Service Qualität und Verfügbarkeit: Warum ist es in Zeiten von „IT als Commodity“ – ähnlich dem Strom aus der Steckdose – nicht möglich, dass IT-Leistungen und Services rund um die Uhr stabil und zuverlässig zur Verfügung stehen? Es ist in den Fragen schon angeklungen und es macht Sinn, sich näher mit den Stakeholdern zu beschäftigen. Dazu kann eine einfache Stakeholderanalyse dienen. Schritt 1: Identifikation aller relevanten Stakeholder In einem ersten Schritt muss eine Liste aller für die IT-relevanten Stakeholder entwickelt werden. Einen ersten Überblick kann die in Abb. 5.3 dargestellte Übersicht an möglichen Stakeholdern für die IT liefern. Das ist ein großer Kreis an Menschen, die Erwartungen an die IT und deren Führungskraft bzw. den CIO haben. Es ist dabei wichtig, zwischen den Erwartungen an die Funktion bzw. Rolle und den Erwartungen an die Person zu unterscheiden, die diese Rolle oder Funktion einnimmt. Denn die Erwartungshaltungen an die Funktion/Rolle können gänzlich andere sein als die Erwartungen an die einzelne Person. Trotzdem sind Führungskräfte im Unternehmen über ihre Rolle an die Erwartungen an sie gebunden. Wie geht man nun vor, um die Erwartungen zu analysieren? Eine Stakeholderanalyse ist keine Aufgabe, die innerhalb einer Stunde erledigt ist, sondern die fortwährend immer weiter ausgefüllt wird. In den ersten Tagen und Wochen setzen sich die Mosaiksteinchen zu einem immer klarer erkennbaren Bild zusammen. Basierend auf den 9 in der Grafik dargestellten Stakeholdergruppen müssen jetzt die einzelnen Stakeholder erfasst werden. Um alle Stakeholder zu erfassen, hilft es in dieser ersten Phase sich Fragen zu stellen, wie z. B.: • Wer benötigt IT-Lösungen? • Wer hat einen großen Nutzen von guten IT-Leistungen?

132

5  Die Rolle der IT im Unternehmen

Geschäftsführung / Vorstand

man selbst im Sinne der „Erwartungen an sich selbst“ die Geschäftsleitung (Geschäftsführer bzw. Vorstände)

der direkte Vorgesetzte

Aktuelle ITDienstleister / Zulieferer

Stakeholder der IT Kollegen auf gleicher Führungsebene (sog. Peers) Mitarbeiter des eigenen Teams

die Fachbereiche der IT (die internen Kunden)

Abb. 5.3  Möglicher Kreis an relevanten Stakeholdern für die IT

• • • •

Wer hat Angst vor möglichen IT-Projekten bzw. deren Auswirkungen? Gibt es jemanden, der sich ständig über die IT aufregt? Wer ist für das IT-Budget verantwortlich? Wer kann sich aufgrund von IT Lorbeeren in der Geschäftsführung oder im Gesellschafterkreis erhoffen? • Welche Zulieferer oder Dienstleister sind nötig oder beteiligt und welche Intention haben diese? Jeder Stakeholder wird in eine Excel-Tabelle eingetragen. Schritt 2: Die Erwartungen notieren und eine Bewertung vornehmen Jetzt erfolgt die Bewertung jeder Person nach den folgenden 3 Kriterien: • Einfluss des Stakeholders (von 1 = sehr hoch bis 5 = sehr niedrig) • Erwartungen des Stakeholders (1 = sehr hoch bis 5 = sehr niedrig) • Interesse am Erfolg der IT (1 = sehr hoch bis 5 = sehr niedrig) Diese Bewertung wird in die Excel-Liste eingetragen und sieht beispielhaft aus wie in Abb. 5.4. Schritt 3: Entscheidungen zum Umgang mit Erwartungen treffen Nachdem die Bewertungen vorgenommen wurden, erfolgt eine Auswertung der Erwartung und die Frage, wie damit umzugehen ist. Dazu sind folgende Schritte hilfreich:

5.3  Erwartungen an die IT-Organisation klären

Nr. Name

1 2

Max Mustermann Maxi Musterfrau

Funktion / Rolle

Geschäftsführer Finanzen IT Service Manager

Einfluss des Stakeholders 1 = sehr gering 2 = gering 3 = mittel 4 = groß 5 = sehr groß

Erwartungen des Stakeholders 1 = sehr gering 2 = gering 3 = mittel 4 = groß 5 = sehr groß

5

3

2

133 Interesse am Erfolg der IT 1 = sehr gering 2 = gering 3 = neutral 4 = hoch 5 = sehr hoch

4

Spezifische Erwartungen

Mögliche Maßnahmen

4

Endlich Reports mit allen Finanzkennzahlen für alle Standorte

Erwartung kann nicht sofort erfüllt werden; Abstimmung und Erklärung nötig

4

Anerkennung für die Arbeit der ITInfrastruktur; mehr Budget für Server

Anerkennung fördern durch IT-Ops-Meeting; die Argumente für mehr Budget sind nicht klar; Abstimmung erforderlich

3 4 5

Abb. 5.4  Die Erwartungen der Stakeholder notieren

• Das Markieren von Erwartungen, die gut erfüllt werden können (Stärken) und von solchen, die schwierig sind (Schwächen). • Schwierig zu erfüllende Erwartungen betrachten und über Lösungsansätze nachdenken. Hier ist es sinnvoll, sich zunächst auf 3 Erwartungen zu beschränken. • Nun gilt es zu prüfen, welche Kann- und Soll-Erwartungen den eigenen Werten und Zielen widersprechen. • Welche Konsequenzen hat es, diese Erwartungen nicht zu erfüllen? Es gilt, nach Lösungsansätzen zu suchen und eigene Erwartungen mit denen der anderen in Einklang zu bringen oder zumindest unangenehme Konsequenzen zu mildern. • Eigene Lösungsansätze: 3 schwierig zu erfüllende Erwartungen, besonders bei Mussund Sollerwartungen. • Was will man selbst nicht erfüllen? – Kann- und Sollerwartungen, die eigenen Werten und Zielen widersprechen und mögliche Lösungen zur Vermeidung von Konflikten. Die Gesamtauswertung wird automatisch aus der Excel-Datei auf Basis der Bewertung generiert und ist beispielhaft in Abb. 5.5. Dabei entspricht der Umfang bzw. das Volumen des Kreises dem Interesse am Erfolg der IT.  Die anderen beiden Bewertungskriterien sind als x- und y-Achse dargestellt (x = Einfluss und y = Erwartung). Reflexionsfragen zu den größten Stakeholdergruppen in der Übersicht Reflexionsfragen für die Geschäftsführung: • Was ist der Geschäftsleitung in Bezug auf IT wirklich wichtig? • Welche Rolle soll die IT aus Sicht der Geschäftsleitung einnehmen? • Was waren bisher die „Pain Points“ in Bezug auf die IT und wie kann man es besser machen? Fragen zum direkten Vorgesetzten:

134

5  Die Rolle der IT im Unternehmen

6

Erwartung des Stakeholders

5 Maxi Musterfrau

4

Max Mustermann

3 2 1 0 0

1

2 3 4 Einfluss des Stakeholders

5

6

Abb. 5.5  Das Ergebnis der Stakeholderanalyse in der Übersicht

• Was ist dem eigenen Vorgesetzten – neben Loyalität – besonders wichtig an Werten in der Zusammenarbeit? • Inwieweit will der Vorgesetzte bei Strategie und Management der IT mitreden und wie viel Freiraum hat man selbst? • Wer vertritt die IT und deren Belange in der Geschäftsleitung? Sie als CIO oder Ihr Vorgesetzter? • Gibt es unausgesprochene Erwartungen? Fragen an Kollegen auf gleicher Führungsebene (Peers): • Wer ist der „heimliche“ Führer auf Peer-Ebene? • Welcher der Peers steht „gut“ zur IT und welcher eher „schlecht“ und warum ist das so? • Genaues Zuhören und die Durchführung von Einzelgesprächen hilft dabei, das Machtgeflecht zu verstehen und das „Wer mit Wem?“ • Wo gibt es oder kann es Kompetenzgerangel geben (CIO versus CDO oder CMO)? Auf diese Weise kann die IT zu einem verbindenden Element zwischen der Unternehmensstrategie, den Fachabteilungen sowie den Kunden werden und so zum Aufbau der vernetzen Einheit beitragen bzw. diese maßgeblich gestalten. Dieses Zusammenwirken von Business und IT holt die IT aus der Rolle des Getriebenen und trägt dazu bei, dass Unternehmen als Ganzes erfolgreich am Markt bestehen.

5.4  Die neue Rolle der IT: Alte Denkmuster müssen überwunden werden

5.4

135

 ie neue Rolle der IT: Alte Denkmuster müssen D überwunden werden

Die IT in Unternehmen unterliegt in den letzten Jahren durch die fortschreitende „Technisierung“ der Geschäftsmodelle einem großen, stetigen Wandel. Keine andere Organisationseinheit hat sich aufgrund des immer schneller werdenden Technologielebenszyklus in den letzten Jahren so stark verändert. Immer neue Technik-Hypes sorgen dafür, dass Unternehmen noch effizienter arbeiten können, dass Prozesse noch stärker automatisiert und Informationen noch besser ausgewertet werden können. Wie sich die IT in diesem starken Wandel durch Technologie behaupten kann und welche Rolle die IT in diesem Kontext einnehmen kann und sollte, zeigt die Abb. 5.6. Auf 2 Ebenen bzw. Achsen dargestellt, kann die IT folgende Rollen einnehmen: • Die Rolle der IT entweder als –– Dienstleister, –– Partner/Enabler oder –– Business-Treiber. • Das Verhältnis zwischen Fachbereich und IT –– business-dominiert, –– ausgewogen, –– IT-dominiert. Beispielhaft ist in der Abb.  5.6 dargestellt, dass die IT sich aktuell in der Rolle als Dienstleister und eher business-dominiert wiederfindet. Es stellt sich jetzt die Frage, wie

Abb. 5.6  Die Rolle der IT im Überblick

136

5  Die Rolle der IT im Unternehmen

sich eine solche IT weiterentwickeln kann und was für das Unternehmen eine möglicherweise passendere Rolle sein könnte? Dazu sind in der Abbildung beispielhaft 3 Szenarien dargestellt. Szenario 1: Die IT wird zum Business-Treiber und das Verhältnis zwischen Fachbereich und IT ist ausgewogen In diesem Beispiel ändert die IT ihre Rolle relativ radikal und überspringt sogar eine Phase, nämlich die des Partners bzw. Enablers. Was bedeutet die Rolle der IT als ­Business-­Treiber? Als Dienstleister ist die IT stark auf Fachbereiche, deren Anforderungen und Wünsche angewiesen. Das Ergebnis davon sind zumeist stark angepasst IT-Systeme, die sich an die individuellen Wünsche der Fachbereiche angepasst haben. Das führt zu teuren Wartungs- und Update-Aufwänden. Die IT wird langsam und die Fachbereiche sind zunehmend verärgert über die langsame und teure IT, obwohl es ihre Wünsche außerhalb des Standards waren, die dazu geführt haben. In der Rolle des Business-Treibers hingegen geht die IT selbst in die Verantwortung und sorgt dafür, dass Projekte und Initiativen gestartet werden, die eng an den Geschäftszielen ausgerichtet Mehrwert und echten Nutzen für das Unternehmen schaffen. Beim Aufsetzen und Einführen neuer IT-Systeme nimmt die IT das Heft in die Hand, führt Change-Prozesse an und treibt damit das Business in die für das Unternehmen richtige Richtung. Darüber hinaus sind die IT und deren Führungsmannschaft eng eingebunden bei der Erarbeitung von neuen Unternehmensstrategien und entwickelt auf Basis von neuen Technologien Ansätze für additive Geschäftsmodelle. Die IT übernimmt also echte Verantwortung für die positive Entwicklung des Business und damit des Unternehmens. Szenario 2: Die IT wird zum Partner mit einem ebenfalls ausgewogenen Verhältnis zwischen Fachbereich und IT Im 2. Beispiel wird die IT zu einem Partner mit ausgewogenem Verhältnis zwischen Fachbereich und IT. Diese Partnerrolle wird auch als Enabler bezeichnet. Dies bedeutet, dass die IT das Unternehmen und die Fachbereiche befähigt, neue Geschäftsmodelle und Möglichkeiten zu identifizieren und zu sehen, die den Unternehmenswert weiter steigern. Die IT übernimmt eine Art Beraterrolle, in der nicht mehr nur Dienstleistungen erbracht werden, sondern auf Augenhöhe mit den Fachbereichen nach Lösungsmöglichkeiten gesucht wird und aktiv Vorschläge und Ideen von der IT kommen. In diesem Sinne kann die IT auch zu einem echten Partner für viele Initiativen und Projekte im Bereich der digitalen Transformation werden. Szenario 3: Die IT bleibt weiterhin Dienstleister, aber das Verhältnis zwischen Fachbereich und IT wird von der IT dominiert In diesem Szenario bleibt die IT ihrer Rolle als Dienstleister treu, aber die Entscheidungen über die Umsetzung und Machbarkeit von IT-Projekten obliegt nun der IT und nicht mehr den Fachbereichen. Die IT nimmt vermehrt eine Rolle ein, die sich nicht in das Business einmischt, dafür aber auf Ebene der Anforderungen und Projekte wesentlich stärker Ak-

5.4  Die neue Rolle der IT: Alte Denkmuster müssen überwunden werden

137

zente setzt und Führung übernimmt. Man bleibt sich als Dienstleister treu, wächst aber in eine Rolle hinein, die klare Vorgaben macht, beispielsweise zum Bebauungsplan sowie zur Vorgehensweise und Methodik bei Projekten. Zudem setzt sie klare Richtlinien zu IT-­ Security und Cloud-Strategien, die auch nicht infrage gestellt werden von den Fachbereichen. Man wächst innerhalb seiner Dienstleisterrolle und kann dort bewusst stärker agieren, anstatt immer nur auf Anforderungen der Fachbereiche zu reagieren.

5.4.1 Vom Verwalter der Technik zum Gestalter des digitalen Wandels Wie schon grob in Szenario 1 dargestellt, ist es in vielen Unternehmen so, dass die IT ihre Rolle vom Dienstleister mit eher technischen Wurzeln hin zum Business-Treiber und Gestalter des digitalen Wandels ändert. Um diese neue Position im Unternehmen einnehmen zu können und den Weg dahin erfolgreich zu bestreiten, ist vor allem eines wichtig: Alte Denkmuster müssen überwunden werden. Was bedeutet das? Wie schon in Abschn. 5.1 dargestellt, sind die großen Treiber und Einflussfaktoren für Unternehmen und die IT heute die Digitalisierung, neue Technologien wie KI und damit einhergehend neue Anforderungen vom Kunden, von Lieferanten, aber auch von Mitarbeitern (siehe New Work oder digitaler Arbeitsplatz etc.). All diesen Dingen ist gemein, dass Antworten auf Fragen nach neuen Absatzkanälen, Kundenwünschen oder Wünschen der Gesellschafter schneller erfüllt werden müssen als früher. Dies hat eine gewaltige Auswirkung auf die IT. Denn durch relativ starre Altsysteme sind Anforderungen und neue Funktionalitäten oftmals nur schwer und damit zeitaufwändig implementierbar. Die IT stöhnt aufgrund von permanenter Überlastung, die Fachbereiche bzw. Kunden frustriert die langwierige Umsetzung von Anforderungen und die Geschäftsführung fürchtet, den Anschluss an den Markt und die Wettbewerber zu verlieren. Das bisherige Denkmuster der IT als Technikprofi und purer Service-Erbringer ist in diesem Kontext nicht mehr vorstellbar, da dies massive Auswirkungen auf den Unternehmenserfolg hätte. Die große Frage ist folglich: Wie kann die IT zum Gestalter des Wandels werden? Das dazu wichtigste Mittel ist tatsächlich die Änderung des Denkens – des Denkens über neue Organisationen und Verantwortlichkeiten. Es ist so stark in den Köpfen der Mitarbeiter, Führungskräfte und damit in der DNA eines Unternehmens eingeprägt, dass die IT mit ihren Technikprofis Services bereitstellt und diese sicher betreibt. Und die IT selbst hat dieses Muster auch so stark verinnerlicht, dass selbst die IT-­ Mitarbeiter so über sich denken. Wie kann dieses Denken aufgelöst und durch ein neues Selbstverständnis ersetzt werden? Hier sind viel Kommunikation und die Beantwortung des „Warum“ gefragt! Warum soll sich die IT überhaupt ändern? Was bringt das dem Unternehmen und der IT? Diese Fragen müssen im Führungskreis und der Geschäftsleitung besprochen werden. Und dann

138

5  Die Rolle der IT im Unternehmen

muss idealerweise eine Story entwickelt werden, die immer wieder übermittelt wird und die sich so tief in den Köpfen aller Beteiligten festigt, dass nach einer gewissen Zeit niemand mehr fragt, warum die IT sich mittlerweile um Change-Themen, Business-Ausrichtung und strategische Dinge kümmert. Es ist einfach so und macht Sinn.

5.4.2 Die 4 Stufen der IT zum Innovationstreiber Im Kontext des Gestaltens von Wandel steht ganz oben das Thema Innovation. Wie kann die IT hier Akzente setzen und echte Innovationen im Unternehmen vorantreiben? Ein Beispiel kann die sogenannte „IT-Strategie 2.0“ der BMW AG geben. Sie stützt sich auf 4 Säulen [1]: • • • •

Tech-driven Products, Processes and Services, Data and Technology-based Business Innovation, Stable and Performant Platforms and IT Products sowie Empowered People and Agile Platforms.

Die BMW-Strategen haben dazu 5 Game Changer identifiziert, auf die sich die IT in den kommenden Jahren konzentrieren soll: 1 . Data Driven Company 2. BizDevOps-Strukturen 3. Cloud-basierte Plattformen 4. IT-Security 5. Interne Software-Skills Letztere sind den IT-Chefs besonders wichtig. BMW will damit die „Kerneigenleistung“ der IT stärken, also vor allem wieder mehr Know-how in Sachen Softwareentwicklung im Konzern aufbauen. Der frühere BMW-CIO Klaus Straub hatte zu diesem Zweck die Initiative Back2Code angestoßen und damit eine Rolle rückwärts gemacht, die außerordentlich viel Erfolg hat, weil endlich wieder alle technisch auf Augenhöhe miteinander reden.

5.4.3 K  onfliktpotenzial 1: „Hoheitliche Aufgaben“ versus Dienstleistungsaufgabe Die Systemlandschaft und IT-Architektur des Unternehmens kann und darf nur durch die IT vorgegeben werden. Das gleiche gilt für die IT-Security-Standards. Denn nur der CIO und sein Team haben die Kompetenz im Unternehmen, um dies abschließend zu beurteilen

5.5 Die neue Rolle der IT treibt das Unternehmen – So kann IT echten …

139

und es ist ihr ureigener Auftrag für die Sicherstellung einer funktionierenden, skalierbaren IT-Architektur und einer hohen IT-Security zu sorgen. Dabei ist immer auf die Balance zwischen den Anforderungen der Mitarbeiter und die dadurch entstehenden Kosten auf der einen Seite sowie die der Sicherheit und der Skalierbarkeit auf der anderen Seite zu achten. Wenn die IT eine Dienstleisterrolle einnimmt, die alles zulässt, was sich die Mitarbeiter bzw. die Fachbereiche wünschen, dann können die genannten hoheitlichen Aufgaben nicht mehr wahrgenommen werden. Daher muss die Dienstleisterrolle immer mit der Beschränkung versehen sein, dass Services, die im Unternehmen gebraucht werden, zügig, skalierbar und möglichst kostengünstig erbracht werden. Hier spielt oft das Thema Standards versus Customizing eine Rolle. Viele Fachbereiche wollen ihre eigene Lösung, die dann teuer individuell entwickelt werden muss. Diesem Wunsch steht oftmals das Thema Kosten, vor allem im Sinne der nachfolgenden Kosten wie Wartung und Pflege entgegen. Denn im Worst Case ist durch die Individualentwicklung kein Update und Releasezyklus mehr möglich, der dafür sorgt, dass die Software auf dem aktuellen Stand bleibt. Daher ist es für die Geschäftsleitung wichtig zu erkennen, dass die IT und deren CIO zwar Dienstleister im Sinne einer für das Unternehmen skalierbaren und agilen IT-­ Architektur und einer sicheren Systemlandschaft ist, logischerweise aber auch nicht jeden Wunsch 1:1 erfüllen kann. Es reicht meistens, wenn dieses Konfliktpotenzial erklärt und erkannt wurde. Dann löst sich meistens schon der Konflikt auf, denn für die meisten Anforderer ist diese hoheitliche Aufgabe nach Erklärung nachvollziehbar und daher akzeptabel.

5.4.4 Konfliktpotenzial 2: Selbstbild versus Fremdbild Hinzu kommt, dass es immer verschiedene Sichtweisen auf die Rolle gibt. So sieht z. B. die Unternehmensleitung die Rolle der IT als Dienstleister, der CIO sieht sich jedoch als Busi­ ness Innovator. Dann ist die Differenz im Rollenverständnis groß und Differenzen sind vorprogrammiert. Daher ist der Abgleich der Perspektiven und die Diskussion der richtigen Positionierung der IT mit der Unternehmensleitung sehr wichtig für den Erfolg – nicht nur für den des CIOs, sondern der gesamten IT-Organisation. Die Entwicklung einer IT-Strategie oder IT-Roadmap kann ein idealer Ansatz sein, um die Rolle der IT ausführlich zu diskutieren und einen gemeinsamen Weg zu deren Bestimmung in 3–5 Jahren zu definieren.

5.5

 ie neue Rolle der IT treibt das Unternehmen – So kann IT D echten Business-Mehrwert schaffen

Basierend auf dem Modell der Entwicklung der IT in 5 Stufen (siehe Abb. 5.2) können die Implikationen der veränderten Rolle der IT auf das Unternehmen abgeleitet werden.

140

5  Die Rolle der IT im Unternehmen

Abb. 5.7  So treibt die IT das Unternehmen voran

Die Abb. 5.7 zeigt anschaulich, wie sich durch die Veränderung der Rolle der IT auch das Unternehmen wandelt. Dies ist nicht nur für den CIO, sondern auch für die gesamte Geschäftsleitung von großem Interesse und Wert. Denn aus der historisch bekannten Stufe I der „IT als Technikprofis“ kamen wenig bis keine Impulse durch die IT in das Unternehmen. Die IT wurde in dieser Phase zumeist eher belächelt und die IT-Kollegen oft als „Nerds“ abgetan, mit denen eine effiziente Business-­Kommunikation nicht möglich war. Auf Business-Ebene ist bei solchen Unternehmen eher oftmals eine noch stark hierarchische Struktur anzutreffen mit einem Command & Order-Führungsstil oder eine „Chaos-Struktur“, in der niemand genau weiß was zu tun ist, da auf Führungsebene aufgrund fehlender Strukturen Überforderung an der Tagesordnung ist. In Stufe 2, in der die IT als Dienstleister fungiert, nimmt die IT zum ersten Mal einen stärkere Kundenorientierung, ist aber weiterhin nicht auf Augenhöhe mit den Fachbereichen und wird von dort noch als Support-Funktion wahrgenommen. Für das Business bedeutet dieser Schritt auf Stufe II, dass oftmals das Projektmanagement und die Führung auf Basis von Zielen (Management by Objectives – MbO) stärker ausgeprägt ist. Es findet auch erstmalig eine Standardisierung von Prozessen statt. Stufe III ist für die IT ein großer Sprung auf das Tableau der echten Augenhöhe mit den Fachbereichen. Die IT wird „ernst“ genommen und als wichtig erachtet, da zum ersten Mal deutlich wird, dass die IT für Effizienzsteigerung und Kostensenkung im Unternehmen sehr wichtig ist. Auf Ebene des Business wird dies deutlich durch eine starke Prozesskompetenz in Form von Prozessoptimierungen und Re-Engineerings, um die Ziele der Effizienzsteigerung und Kostensenkung umzusetzen. Durch große Transformationsprojekte, die nicht mehr nur als IT-Projekte verstanden werden, wächst die Bereitschaft und Reflektion für Veränderungen und Changemanagement im Unternehmen durch IT.  Auf Stufe IV ist auch die strategische Wichtigkeit neben der Effizienzsteigerung erkannt. In diesem Rahmen wächst die IT noch enger mit den Fachbereichen zusammen und hat ausgeprägte und sehr professionelle Prozesse zur Umsetzung von großen Transformationen. Auf Business-Ebene zeigt sich dieses neue Rollenverständnis der IT durch stärker ausge-

Literatur

141

prägtes Innovationsbewusstsein, viel Kollaboration und Agilität. Damit können große Transformationen wesentlich schneller und effizienter umgesetzt werden und der Kundenfokus rückt noch stärker in den Mittelpunkt. Die finale Stufe V der IT bedeutet einen radikalen Wandel des Unternehmens hin zu einem Techunternehmen. Von der eher prozessgetriebenen Handlungsweise wandelt sich das Unternehmen zu einem durch IT getriebenen Geschäftsmodell. Oftmals ist dies verbunden mit einer sehr stark auf Daten getriebenen Organisation (Data-Driven-Company). Merkmale einer solchen Organisation sind Selbstständigkeit, ständiges Innovieren, unternehmerisches Denken und Agilität.

Literatur 1. Herrmann, Wolfgang (Computerwoche): „BMW IT Strategie 2.0“, https://www.cio.de/a/bmw-itsetzt-auf-mehr-eigenleistung,3625034, abgerufen am 15.01.2020.

6

Quo vadis CIO? – Die Rolle des CIOs in Zeiten der digitalen Transformation

Zusammenfassung

Wenn die IT eine neue und stärker werdende Rolle im Unternehmen einnimmt, so hat dies natürlich Auswirkungen auf die Rolle des CIOs! Neben der Beschreibung und Definition von CIO Rollenmodellen geht es in diesem Kapitel primär um die neuen Aufgaben des CIOs und der Darstellung welche Fähigkeiten und Kompetenzen ein CIO in einem modernen Unternehmen mitbringen muss.

Die Rolle des CIOs wandelt sich mit der neuen Bestimmung der IT rasant: Vom einstigen Cost-Center-Manager zum digitalen Strategen mit der Aufgabe, Innovationen innerhalb des Unternehmens voranzutreiben. Durch die genannten Umwälzungen der IT-Organisation in Richtung Business ändert sich auch die Rolle des CIO. Früher zumeist technisch ausgerichtet, sind heute Manager gefragt, die das Business genau verstehen und in der Lage sind, genau einzuschätzen, wo der Mehrwerthebel für die IT im Unternehmen anzusetzen ist. Es ist offensichtlich, dass die Herausforderungen an den CIO und seine Organisation sich in dem Tempo weiter entwickeln werden, wie mit neuen Technologien neue Möglichkeiten für unternehmerische Innovationen entstehen. Die Weiterentwicklung und damit Wettbewerbsfähigkeit des Unternehmens liegt somit ebenso in seiner Verantwortung wie in der seiner Kollegen auf der Business-Seite. Er ist nicht nur als Experte für neue Technologien, sondern eben auch als Führungskraft gefordert, die das Unternehmen nach vorne bringt. Auf dieser Basis soll genauer untersucht werden, welche CIO-Rollenmodelle es gibt, was die Aufgaben des CIOs sind und wie diese sich geändert haben. Dazu gehört auch, dass ein genauer Blick auf die heute notwendigen Fähigkeiten und Kompetenzen gewor© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 V. Johanning, Organisation und Führung der IT, https://doi.org/10.1007/978-3-658-12008-5_6

143

144

6  Quo vadis CIO? – Die Rolle des CIOs in Zeiten der digitalen Transformation

fen wird. Zum Abschluss folgt eine Gegenüberstellung zwischen CDO und CIO, um abzugrenzen, wer für die digitale Transformation nun eigentlich Verantwortung trägt.

6.1

CIO-Rollenmodelle

Die Rolle des CIOs aber wandelt sich weiter: Es zeichnet sich ein Weg vom „technischen Umsetzer“ hin zum „Gestalter des digitalen Wandels“ ab, der als Partner und Enabler des Business auf Augenhöhe gesehen wird. Damit ändert sich auch die Rolle des CIOs im Gesamtkontext des Unternehmens. Die Tab. 6.1 zeigt in Anlehnung an Brenner [1] diesen Wandel der Rolle des CIOs. Zunächst sei angemerkt, dass im Folgenden die Rolle des CIOs synonym verwendet wird zu den im Markt ebenfalls gebräuchlichen Begriffen des IT-Leiters, des CTOs (Chief Technology Officers) oder des EDV-Leiters. Wie wir im Rahmen der Entwicklung von Demand-/Supply-Strukturen gesehen haben, gibt es einen Unterschied zwischen CIO und CTO, da der CIO den Demand-Zweig führt und der CTO den Supply-Zweig als „IT-­ Factory“. Diese Differenzierung ist wichtig für die Demand-/Supply-Struktur, aber hier geht es um die Person, die direkt an die Unternehmensleitung berichtet und das ist in aller Regel der CIO oder der IT-Leiter. Es sei des Weiteren erwähnt, dass im Rahmen der Demand-/Supply-Struktur der CTO an den CIO berichtet und der CIO wiederum an die Unternehmensleitung. Was sind die Hauptaufgaben eines CIOs? Analog zu den Querschnittsfunktionen wie sie im Demand-/Supply-Konstrukt beschrieben werden, sind dies vor allem die folgenden Bereiche: • IT-Strategie (Alignment von Unternehmens- und IT-Strategie, strategische Ausrichtung der IT) • IT-Architektur (Schaffen von Standards und Skaleneffekten im Rahmen von Bebauungsplänen) • Führen der IT-Organisation (IT-Leadership und Governance) • Management der externen Lieferanten (Providermanagement) • Portfolioplanung und Priorisierung • Risikomanagement und IT-Sicherheit Tab. 6.1  Wandel der Rolle des CIOs. (Brenner et al. [1])

Alte Rolle Technikorientiert

Neue Rolle Geschäftsmodell- und prozessorientiert IT als Inhalt IT als Mittel zum Zweck Technikqualifiziert Führungsqualifiziert Spezialist Generalist Denkt in Kosten Denkt in Ergebnissen Internorientiert Externorientiert Kennt Technologie Kennt Technik und Geschäft

6.2  Aufgaben eines CIOs: Arbeit an der IT und nicht in der IT

145

Neben dieser Auflistung an Hauptaufgaben eines CIOs, können 3 Rollen unterschieden werden, die auf Wikipedia treffend dargestellt sind und in Tab. 6.2 vorgestellt werden. Der in Wikipedia dargestellte Ansatz zeigt sehr anschaulich die Wandlung der Rolle des CIOs vom Techniker („Run the Business“) zum IT-Manager auf Augenhöhe mit der Unternehmensleitung. Er beherrscht nicht nur die Technik, sondern kennt auch das Geschäft und kann damit die IT noch effizienter als Innovationsmotor („Change the Business“) oder sogar zum Zwecke der tatsächlichen Wertsteigerung als strategischer Berater („Engineer the Business“) einsetzen.

6.2

Aufgaben eines CIOs: Arbeit an der IT und nicht in der IT

Wenn man sich die Aufgaben eines CIOs anschaut, dann ist es hilfreich, einen kurzen Blick in die letzten beiden Dekaden zu werfen. Denn CIOs legen ihren Fokus nach wie vor oft auf die Technik. Seine wesentliche Aufgabe besteht bislang darin, IT zur Verfügung zu stellen und am Laufen zu halten, sodass die eigentlich wertschöpfenden Prozesse im Unternehmen optimal unterstützt sind. Wenn es um die Aufgaben des CIOs geht, ist ein kurzer Blick zurück in die 2000er-Jahre sehr hilfreich. Die Aufgaben in den 2000er-Jahren können so zusammengefasst werden: • CIOs sind verantwortlich für das reaktive Demand-Management. Sie nehmen Anforderungen aus den Fachbereichen auf, kanalisieren und harmonisieren sie. • CIOs sind verantwortlich für die gesamte IT-Infrastruktur: von den Servern im Rechenzentrum und den Netzwerken über die Datenbanken bis zu den einzelnen Anwendungen. Das umfasst auch IT-Security und IT-Support. • CIOs entwickeln die IT-Infrastruktur mit dem Ziel weiter, Business-Continuity sicherzustellen – hier geht es also beispielsweise um neue Releases bestehender Lösungen. • CIOs sind zum Teil für die Analyse und das Design von Geschäftsprozessen zuständig, um diese IT-seitig abbilden zu können. • CIOs entwickeln die IT-Infrastruktur weiter, um sämtliche Geschäftsprozesse kontinuierlich zu optimieren und zu automatisieren und um die fachlichen Anforderungen zu erfüllen. Hier geht es auch um Best-of-Breed-Lösungen, die sehr spezifische Anforderungen adressieren. • CIOs führen die Teamleiter aus den Bereichen IT-Entwicklung, technische Administration und technischer Support. • CIOs sind für die Qualitätssicherung und das Projektmanagement verantwortlich. • CIOs sind verantwortlich für die Definition und die Umsetzung der Investitionen im IT-Bereich samt IT-Support für interne Anwender. Aus diesen spezifischen Anforderungen resultiert ein typisches Profil, das CIOs in der Regel bisher erfüllen mussten (wieder mit Blick zurück in die 2000er-Jahre):

146

6  Quo vadis CIO? – Die Rolle des CIOs in Zeiten der digitalen Transformation

Tab. 6.2  Drei mögliche Rollen eines CIOs. (entnommen aus Wikipedia [2]) Rolle „Run the Business“ (operative Funktionen)

„Change the Business“ (Innovationsmanagement)

Beschreibung der Rolle Die Basisaufgaben eines IT-Verantwortlichen: Die Sicherstellung des reibungslosen Betriebs des IT-Systems und die Betreuung der IT-Infrastruktur. Aufgrund der hohen Abhängigkeit und des Einflusses der IT auf alle anderen Unternehmensbereiche ist die Gewährleistung der Funktionsfähigkeit des IT-Systems im Unternehmen als eine grundlegende Aufgabe anzusehen. Dazu gehört ebenso, dass mit dem IT-System den Anforderungen der Anwender in Hinsicht auf Qualität, Service und Verfügbarkeit entsprochen wird. Der CIO muss den Einsatz der Technologiekapazitäten koordinieren und leiten, um die betrieblichen Arbeitsprozesse und Serviceabläufe zu verbessern. Er ist ebenso dafür zuständig, den Informationsfluss unternehmensübergreifend zu fördern sowie die Verflechtung und das Daten-Sharing innerhalb des Unternehmens. Gleichzeitig ist aber auch die Sicherstellung des Datenschutzes jedes Einzelnen wichtig. Generell muss die Sicherheit des gesamten IT-Systems auf einem hohen Niveau gewährleistet werden. Er ist somit dafür verantwortlich, ein zuverlässiges und sicheres Informationstechnologiesystem zur Verfügung zu stellen, damit ein effizienter Betrieb des Geschäftes ermöglicht wird. Das ist besonders wichtig, um Vertrauen in die IT aufzubauen und Transparenz zu schaffen. Das alles muss bei angemessenen Kosten von der IT-Abteilung bereitgestellt werden. Der CIO muss die Möglichkeiten moderner IKT für das Unternehmen aufzeigen und stetig Innovationen vorantreiben, damit die vorhandenen Verbesserungspotenziale ausgeschöpft werden können. Dazu muss er die aktuellen Entwicklungen von potenziell relevanten technischen Innovationen beobachten und dann deren Bedeutung für das Unternehmen beurteilen Er muss dann den Anstoß zu neuen Technologieprojekten geben. Es ist ebenso die Aufgabe des IT-Managers, das richtige Timing für die Einführung der technischen Innovationen zu finden. Das alles muss spezifisch auf das eigene Unternehmen hin angepasst werden, damit technische Innovationen auch wirklich wertschöpfend eingesetzt werden können. Anschließend muss der richtige Einsatz neuer Technologien unterstützt und überwacht werden. Er muss neue, für das Unternehmen wertbringende Technologien konsistent in das bestehende Unternehmensportfolio integrieren. (Fortsetzung)

6.2  Aufgaben eines CIOs: Arbeit an der IT und nicht in der IT

147

Tab. 6.2 (Fortsetzung) Rolle „Engineer the Business“ (Geschäftseffizienz und strategische Beratung)

Beschreibung der Rolle Der IT-Manager ist mitverantwortlich für die effiziente Gestaltung des Unternehmens. Für dieses analysiert er auf Basis der IT verschiedene Möglichkeiten. So kann beispielsweise die Werthaltigkeit einzelner Bereiche oder Prozesse im Unternehmen bestimmt werden oder auch der potenzielle Wertzuwachs durch neue Möglichkeiten. Dadurch kann ein Beitrag zu „Make-or-­ Buy“-Fragen geliefert werden. Dafür muss ein CIO die Strukturen und Zusammenhänge im Unternehmen gut kennen. Er hat damit eine beratende Funktion für die Geschäftsführung. Dazu benötigt er umfangreiches Verständnis über die aktuellen Markttrends. Er identifiziert Möglichkeiten für eine wettbewerbsorientierte Differenzierung. So können zukünftige Geschäftsfelder für das Unternehmen ermittelt werden. Die vorhandenen Vertriebs- und Distributionskanäle können gegebenenfalls neu überarbeitet oder neue entwickelt werden. Dadurch kann er zukünftige Technologierichtungen und -prioritäten aufzeigen, die für die Wertsteigerung des Unternehmens wichtig sind. Die Entwicklung und Anpassung von IT-Strategien muss jeweils in Übereinstimmung mit der Unternehmensstrategie vollzogen werden, wobei es ebenso möglich ist, dass sich Geschäftsstrategien erst aufgrund von neuen IKT-Potenzialen entwickeln oder daraufhin verfeinern lassen. Die notwendigen Strategien, Informationen, Erfahrungen, Methoden und IT-­ Unterstützung müssen für die Umsetzung in den jeweiligen Bereichen zur Verfügung gestellt werden.

• CIOs haben ein Studium der Informatik oder Wirtschaftsinformatik erfolgreich abgeschlossen. • CIOs greifen auf eine mehrjährige Berufserfahrung in der IT-Entwicklung oder der IT-Governance zurück – inklusive Führungserfahrung. • CIOs verfügen über fundierte IT-Fachkenntnisse und praktische Erfahrung im Bereich Netzwerktechnik. • CIOs besitzen umfangreiche Programmiererfahrung. • CIOs verfügen über sehr gute analytische und kommunikative Fähigkeiten, Umsetzungsstärke und Eigeninitiative. • CIOs haben sehr gute Projektmanagementfähigkeiten und Erfahrung in großen IT-Projekten. Wenn wir in die Gegenwart der beginnenden 2020er-Jahre schauen, dann hat sich dieses Aufgaben- und Anforderungsbild des CIOs sehr deutlich gewandelt. Die Digitalisierung mit ihren Game Changern künstliche Intelligenz, IoT, ihrer Dynamik und agilen ­Arbeitsweise erfordert ein neues Aufgabenspektrum und stellt vor allem andere Anforderungen an den CIO als bisher.

148

6  Quo vadis CIO? – Die Rolle des CIOs in Zeiten der digitalen Transformation

Man kann es mit dem folgenden Satz auf einen Punkt bringen: Der heutige CIO muss nicht mehr in der IT arbeiten, sondern an der IT! Ein Artikel aus der Zeitschrift Computerwoche bringt es auf den Punkt [3]: Anstatt also alles, was mit IT zu tun hat, zu managen, muss der CIO heute • den Mehrwert und die Bedeutung neuer Technologien für das Gesamtunternehmen antizipieren, • Standards und Strukturen für Datenintegration mit den Fachbereichen so vereinbaren, dass unterschiedliche Technologien miteinander kommunizieren und gemeinsam auf Daten zugreifen können, • Standards für Datensicherheit definieren und umsetzen, • End-to-End-Service-Levels zur Verfügung stellen. Es ist offensichtlich, dass die Herausforderungen an den CIO und seine Organisation sich in dem Tempo weiter entwickeln werden, wie mit neuen Technologien neue Möglichkeiten für unternehmerische Innovationen entstehen. Die Weiterentwicklung und damit Wettbewerbsfähigkeit des Unternehmens liegt somit ebenso in seiner Verantwortung wie in der seiner Kollegen auf der Business-Seite. Er ist nicht nur als Experte für neue Technologien, sondern eben auch als Führungskraft gefordert, die das Unternehmen nach vorne bringt. Die Abb. 6.1 zeigt den Wandel der CIO-Rolle anhand seiner Aufgaben, die bisher immer stark reagierend geprägt waren und jetzt in einer agierenden Rolle aufgehen.

HEUTE Optimierung des IT-Betriebs

Kosten- und Budgetmanage ment

ZUKUNFT

Ständiges Problem Solving

Neue Technologien erproben und einsetzen

Strategisches Ausrichtung der IT und des UNs

Ständiges Bekämpfen der „Brandstellen“

Innovationen vorantreiben

IT als AgilitätsVordenker

Abb. 6.1  Agieren statt reagieren

6.3  Notwendige Fähigkeiten und Kompetenzen des CIOs

6.3

149

Notwendige Fähigkeiten und Kompetenzen des CIOs

Die neue Rolle des CIOs verlangt nach neuen Kompetenzen. Neben dem Thema „neue Führung“ rangieren weitere 4 Themen ganz weit oben auf der Agenda der benötigten Fähigkeiten eines zukunftsfähigen CIOs: . Agile Leadership: moderne Führung anstatt Command & Control 1 2. Veränderungen managen und führen: nicht nur die Technik zum Laufen bringen, sondern die Menschen und die Prozesse 3. Unternehmerisches Denken: den Business-Impact sowie Nutzen von IT deutlich machen 4. Kommunikation & Marketing: IT verständlich machen 5. Komplexität vereinfachen: Technologien verstehen und richtig für das Unternehmen einsetzen

6.3.1 A  gile Leadership: moderne Führung anstatt Command & Control Führung wird zu einem wichtigeren Thema. Nicht nur weil Command & Order sowie pures Führen nach Zielen (Management by Objectives – MbO) ihre Grenzen schon überschritten haben, sondern weil die neue Generation an IT-Experten es sich aussuchen kann, wo und wie sie arbeiten möchten. Ohne den so schwierig zu rekrutierenden IT-Nachwuchs geht es nicht und allein deshalb ist agiles Leadership gefragt. Dazu gehört auch die Form des Mentoring und Coaching der IT-Mitarbeiter im Sinne von „Fordern und Fördern“.

6.3.2 D  er CIO als Change Leader: Nicht nur die Technik zum Laufen bringen, sondern die Menschen und die Prozesse CIOs benötigen ein gutes Maß an Kenntnissen in den Bereichen Veränderungsmanagement, Umgang mit Konflikten und Widerständen sowie eine gut funktionierende Selbstreflektion. Warum ist das heute so wichtig? Es geht bei Einführungen von IT-Systemen primär um das Steuern von Veränderungsprozessen. Die Technik dahinter hat man schnell im Griff, aber das ganze „Drumherum“ von der rollierenden Planung, agilen Methodiken, den Änderungen der Arbeitsabläufe von Mitarbeitern und Usern sowie damit zusammenhängenden Anpassungen von Rollenbeschreibungen oder wegfallenden Arbeitsplätze durch Automatisierung stellt den CIO vor ganz andere Aufgaben als das Managen der Technik. Auch die solchen Projekten innewohnende Komplexität und das darin liegende

150

6  Quo vadis CIO? – Die Rolle des CIOs in Zeiten der digitalen Transformation

­ onfliktpotenzial sind sehr hoch und bilden eine nicht alltägliche Hürde für jeden K CIO.  Diese muss aber von guten CIOs genommen werden, weshalb die Kenntnisse in Bereich des Veränderungsmanagements so immens wichtig geworden sind.

6.3.3 U  nternehmerisches Denken: Den Business-Impact und den Nutzen von IT deutlich machen Es ist schön, wenn das neue IT-System und die IT als solches gut im Sinne von stabil und kostengünstig funktionieren und eventuell sogar noch skalierbar sind. Das war früher der Anspruch an CIOs. Heute geht man einen gehörigen Schritt weiter: Die Frage nach dem Nutzen, dem Mehrwert einer IT und seiner Systeme steht im Vordergrund. Nur das, was dem Unternehmen einen echten Marktvorteil bietet, wird in Zukunft gewinnen. Dies stellt den CIO vor neue Herausforderungen: Er muss sich stärker mit Business-Cases beschäftigen, muss den Mehrwert vor der Geschäftsleitung transparent machen und verteidigen und hat darüber hinaus die Aufgabe, neue Geschäftspotenziale durch neue Technologien zu identifizieren und für das Unternehmen einzuführen.

6.3.4 Kommunikation & Marketing: IT verständlich machen Auch wenn der Mehrwert verstanden wurde, die Technik und Operations reibungslos läuft und so skalierbar ist, dass für die Zukunft alles möglich ist, so ist noch nicht gesagt, dass die IT und der CIO ihren Job vollends und zu aller Zufriedenheit erledigt haben. Es geht darum, dass der CIO die neuen Technologien, die Digitalisierung und beider Nutzen für das Geschäft transparent machen muss. Transparent in dem Sinne, dass die Geschäftsleitung, aber auch die Fachbereiche verstehen, wie diese Dinge genutzt werden können, welche Vor- und Nachteile zu beachten sind und was das für ihr Geschäft bedeutet. Das ist die Rolle des Enablers. Dazu hilft auch ein gerüttelt Maß an Marketingverständnis zur Nutzung im eigenen Interesse. Roadshows, Newsletter, Kommunikationsveranstaltungen und weitere Marketingaktivitäten können dazu beitragen, dass der CIO und die IT in ­einem neuen Licht gesehen werden. Dies ist zwingend notwendig, um als Enabler Gehör zu finden.

6.3.5 K  omplexität vereinfachen: Technologien verstehen und richtig für das Unternehmen einsetzen Im Zusammenhang des CIOs als Enabler spielt dieser letzte Punkt eine wichtige Rolle: Der CIO muss die Komplexität vereinfachen. Die Welt scheint komplexer, undurchsichtiger geworden zu sein. Neue Technologien erreichen Anwendungsreife, stellen aber oftmals mehr Fragen, als das sie Antworten geben. Hier ist der CIO gefordert. Es ist seine

6.4  CIO versus CDO: Der CIO im digitalen Zeitalter

151

Aufgabe, für Antworten zu sorgen und neue Technologien, aber auch dadurch entstehende neue Geschäftsmodelle zu erklären. Der CIO muss zeigen können, wie es funktioniert und welchen Mehrwert es für das Unternehmen bringt. Es ist auch seine Aufgabe aufzuzeigen, was möglich ist und was nicht. Ebenso ist es an ihm, zu veranschaulichen, was für das Unternehmen wirklich Sinn und Nutzen stiftet und was vielleicht auch nicht angewendet werden sollte, obwohl es gerade ein Hype ist und viele andere es nutzen. Hier muss der CIO aktiv zum Ermöglicher werden, der Dinge selbst versteht und dann auch anderen beibringen kann. Darüber hinaus muss er die Erklärung liefern können, warum was gerade sinnvoll ist oder auch nicht.

6.3.6 Der 7-Punkte-Plan zum Erfolg als CIO Auf Basis der EKS (Engpasskonzentrierte Strategie nach Prof. Mewes) sind es die folgenden 7 Schritte, die für den CIO entscheidend sind für den Erfolg: . Die eigenen Engpässe finden 1 2. Das brennendste Problem der Fachbereiche und des Unternehmens herausfinden 3. Den Nutzen der IT auf das brennende Problem ausrichten 4. Strategie und Vision der IT mit der Geschäftsleitung herausarbeiten 5. Die neue Rolle leben und ausbauen 6. Verbündete suchen und an sich binden 7. Eine Innovationsstrategie erarbeiten

6.4

CIO versus CDO: Der CIO im digitalen Zeitalter

Anders als der CIO ist der CDO deutlich aktiver in die Entwicklung des Unternehmens eingebunden. Er soll die digitale Transformation maßgeblich gestalten, und zwar auf Ebene der Organisation, der Prozesse und der Technologie. Dafür muss er die Entwicklungen am Markt und die Wünsche der Kunden im Blick behalten und diese verstehen, um daraus die richtigen Schlüsse für die Produkte und Services des Unternehmens zu ziehen. Gleichzeitig muss er die Konsequenzen bedenken, die sich daraus für das Unternehmen und die IT-Infrastruktur ergeben. Die Abb. 6.2 zeigt die Unterschiede und Gemeinsamkeiten in den Aufgaben und Anforderungen des CDOs versus CIOs. Ähnlich wie beim CIO im vorangegangenen Kapitel sollen hier die Aufgaben des CDOs im Überblick dargestellt werden: • CDOs analysieren stetig alle zeitlich relevanten Aspekte, sie behalten die Dynamik und Beständigkeit von Trends und Veränderungen im Unternehmensumfeld im Blick. • CDOs bewerten und priorisieren die Marktanforderungen kritisch.

152

6  Quo vadis CIO? – Die Rolle des CIOs in Zeiten der digitalen Transformation

CDO

CIO Schaffung der technologischen Infrastruktur

Digitalen Kulturwandel herbeiführen Entwicklung neuer Geschäftsmodelle

Digital Leadership – Führen von digitalen Initativen

Erkennen von Trends und neuen Technologien

Neue Methoden und Konzepte einführen und testen (Agilität,..)

Innovationen vorantreiben

Prozesse optimieren & automatisieren

Strategisches Ausrichtung der IT

IT und Cyber Security sicherstellen

Abb. 6.2  CDO versus CIO: Aufgaben und Anforderungen im Überblick

• CDOs sind verantwortlich für die Definition und Umsetzung von digitalen Trends, neuen Geschäftsmodellen und unternehmensweiten Strategieveränderungen. • CDOs sind verantwortlich für das aktive Demand-Management. Sie führen Machbarkeits- sowie Trend-/Marktanalysen durch und schlagen den Fachbereichen neue Anforderungen vor. • CDOs entwickeln die Unternehmensarchitektur kontinuierlich weiter. • CDOs erstellen Transformationspläne, kontrollieren deren Umsetzung und greifen bei Bedarf ein. • CDOs koordinieren die Digital Executives aus den einzelnen Fachbereichen. • CDOs bilden die Schnittstelle zum Chief Information Officer, Chief Finance Officer, Chief Operating Officer und dem Chief Execution Officer. Auch aus diesem Aufgabenspektrum lässt sich ein typisches Profil ableiten: • CDOs haben ein Studium der Wirtschaftsinformatik, der BWL, des Ingenieurwesens oder eines vergleichbaren Bereichs erfolgreich abgeschlossen. • CDOs greifen auf eine mehrjährige Berufserfahrung im Bereich Entwicklungs- und Innovationsmanagement zurück – inklusive Führungserfahrung. • CDOs verfügen über die Fähigkeit, wirtschaftliche Erwägungen mit technologischen Möglichkeiten zusammenzudenken, sie kombinieren ein Bewusstsein für Innovationen mit realistischen Einschätzungen.

Literatur

153

• CDOs besitzen Erfahrungen in den Bereichen Projektmanagement und Changemanagement sowie bei der Leitung von Teams  – idealerweise in einem Transformationskontext. • CDOs sind im höchsten Maße kommunikations- und verhandlungssicher und können ihre Vorstellungen durchsetzen. Im Gegensatz zum Aufgabenspektrum des CIOs ist das des CDOs stärker am Markt und am Kunden orientiert. Es stellt sich die große Frage, wie CIO und CDO idealerweise nebeneinander bzw. zusammenarbeiten oder wer von beiden welche Rolle einnimmt und wie er sich damit von der jeweils anderen Rolle abgrenzt. Beide Rollen müssen damit rechnen, dass sie sich nach Aufgaben organisch im Unternehmen verändern werden. Allein durch die offene Anlage der einzelnen Teams, die sich austauschen und agil im Unternehmen Aufgaben übernehmen, delegieren und unterschiedlich lösen, ergeben sich automatisch solche Veränderungen. Beide Bereiche, die des CDOs und die des CIOs reagieren nicht mehr anforderungsgesteuert, sondern gestalten aktiv mit – immer in Bezug auf Erfolg, Leistung und Gewinnorientierung. Kleinere Unternehmen werden sich nicht beide Positionen leisten können, sie vielleicht auch gar nicht benötigen. Hier wird der CIO aller Wahrscheinlichkeit nach zum CDO „aufsteigen“. Denn er hat die technischen Voraussetzungen, die weichen Skills eignet er sich an.

Literatur 1. AXELOS/TSO (The Stationery Office): „ITIL Foundation, ITIL v4“, 1.  Auflage, AXELOS/ TSO 2019. 2. Wikipedia: „Chief Information Officer“, https://de.wikipedia.org/wiki/Chief_Information_Officer, abgerufen am 12.02.2020. 3. Spiegelhoff, Andrea: „5 Aufgaben für IT-Transformation“, Computerwoche, 28.03.2019.

Teil IV Führung von IT-Organisationen

7

Führungsgrundsätze für CIOs und IT-Leiter

Zusammenfassung

Vier Faktoren bilden das Fundament einer erfolgreichen Führung einer IT-­Organisation. Dazu gehört die Ergebnisorientierung, das Wissen um die speziellen Herausforderungen der Führung von Spezialisten, die Konzentration auf das Wesentliche und die Mitarbeiterförderung. Diese 4 Erfolgsfaktoren eines modernen CIOs werden im Folgenden ausführlich dargestellt.

7.1

Ergebnisorientierung und Business-Impact als CIO

Das Image der IT-Abteilung und damit auch des CIOs als Führungskraft sehen einige im Unternehmen nicht immer positiv. Es dauert alles immer viel zu lange bis es fertig ist und ständig funktioniert irgendetwas nicht so wie es der User gerne hätte. Die ganze Welt spricht von Digitalisierung, aber die IT liefert nicht. Daher haben viele Unternehmen eigene digitale Abteilungen aufgebaut, man stellt einen CDO ein und entwickelt eigene Apps. Im ungünstigsten Fall passen diese Anwendungen dann gar nicht in die bestehende Systemlandschaft und können intern überhaupt nicht betrieben werden. Das macht die Situation nicht wirklich besser. Daher ist die Gretchenfrage: Wie kann die IT und der CIO endlich zeigen, dass die IT wichtig ist und auch liefern kann? Leider denken die IT und deren Führungsmannschaft oftmals nur inputorientiert und legen zu wenig Augenmerk auf den Output. Was aber im Unternehmen allein zählt ist der Output! Beispielhaft sieht man das an den Lebensläufen und Gesprächen mit CIOs. Es sind viele bemerkenswerte Positionen und spannende Projekte aufgeführt. Was aber fehlt, ist häufig das Ergebnis: Was wurde wirklich erreicht? Was waren die messbaren Verbesserungen für das Unternehmen?

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 V. Johanning, Organisation und Führung der IT, https://doi.org/10.1007/978-3-658-12008-5_7

157

158

7  Führungsgrundsätze für CIOs und IT-Leiter

Denn es zählen nur klare Mehrwerte für das Unternehmen: Welchen Nutzen habe ich gestiftet und was ist hinterher besser als vorher? Beispiele dafür können sein: • Time-to-Market im Bereich Vertrieb um 40 % verbessert. • Erhöhung des Automatisierungsgrades: Die Produktionslinie x schafft durch eine neue Software einen um 30 % höheren Output. Damit kann die Produktionslinie wesentlich mehr produzieren, ist effizienter ausgelastet und der Deckungsbeitrag pro Produkt erhöht sich um 20 %! Dies hat direkte Auswirkungen auf das EBIT und die Marge des Unternehmens, denn diese steigt um 0,8 %, was x T€ ausmacht! Wirkliche Ergebnisorientierung ist immer mit harten Fakten unterlegt. Das bedeutet für das oben genannte erste Beispiel: Time-to-Market um 40 % erhöht, d. h. konkret: Wenn eine Anforderung zum Thema Vertrieb/CRM eingeht, braucht man im Schnitt nur noch 6 Tage bis zur fertigen Funktion, während es vorher immer mehr als 10 Tage waren. Es geht immer um den Business-Impact: Jede Tätigkeit in der IT muss einen Einfluss auf die Verbesserung der Wirtschaftlichkeit des Unternehmens haben. Und dies bedeutet nicht, dass man inputorientiert viele Überstunden machen, überproportional hart arbeiten und viel Stress haben muss. Es geht vor allem um Effizienz beim Erreichen von Ergebnissen. Im Übrigen ist es egal, wie lange man für ein Ergebnis braucht. Es ist für das Unternehmen, das Ergebnis und für den Chef nicht relevant, ob man 3 Tage für ein Ergebnis braucht oder 30 Tage mit täglich 4 Überstunden und Wochenendarbeit. Im Gegenteil: Je effizienter das Ziel und Ergebnis erreicht wird, desto besser für das Unternehmen und stressfreier für die Mitarbeiter. Zielorientiertes Arbeiten darf daher nicht gleichgesetzt werden mit viel Aufwand, sondern mit entschiedener Fokussierung auf die angestrebten Ergebnisse. Wenn die SAP-­ Einführung in einem kleinen Werk in 3 Wochen zu schaffen ist, warum sollte man dann vorher 3  Wochen lang in theoretischen Gant-Diagrammen planen und 3  Monate dafür vorsehen? Es empfiehlt sich, zu überlegen, was für die tatsächliche Zielerreichung notwendig ist und von Anfang an sich das angestrebte Ergebnis vor Augen zu halten: Was verbessert sich, wenn SAP im Werk eingeführt ist? Welche 3 Punkte sind das und wie kann ich diese möglichst schnell und effizient erreichen? Es gilt stets zu bedenken, dass allein das Ergebnis zählt und nicht wie man dort hingekommen ist oder wie elegant und mit welchen eindrucksvollen Projektmanagementmethoden und SCRUM dies realisiert wurde. Das ist pure Ergebnisorientierung und im Sinne eines Unternehmens nutzbringend. Gerade die IT hat die Aufgabe, Prozesse zu automatisieren und damit das Unternehmen effizienter zu machen. Diese höhere Effizienz eröffnet häufig neue Einsparpotenziale. Eine Begleiterscheinung dieser Einsparungen ist hin und wieder auch der Verlust von Arbeitsplätzen, weil Tätigkeiten automatisiert wurden und nicht mehr von Menschen ausgeführt werden müssen. Wenn dann z. B. durch eine neue Software ein Prozess so weit automatisiert wird, dass jetzt nicht mehr 3 Vollzeitarbeitskräfte benötigt werden, sondern nur

7.2  Das Führen von IT-Spezialisten

159

noch eine halbe Arbeitskraft, dann stellt sich die Frage, was mit den 2,5 FTE passieren soll. Insbesondere in diesen Situationen wird klar, dass die Arbeit als Führungskraft in der IT nicht immer nur Freude macht und machen kann. Das Postulat vieler Politiker, teilweise sogar Manager oder Unternehmensführer, dass Arbeit immer Freude und Spaß bereiten soll wird durch solche Situationen infrage gestellt. Natürlich ist es schön, wenn man mehr freudvolle Momente bei der Arbeit hat, aber das kann nicht fortwährend der Fall sein. Es gibt immer wieder Aufgaben, die einfach gemacht werden müssen und es gibt leider auch Dinge, die keine Begeisterung auslösen, wie z. B. Kündigungen auszusprechen. Gerade in der IT kommt es häufig vor, dass man für Systemausfälle, ungelöste Tickets oder Banalitäten wie „der Beamer geht nicht! Die IT ist schuld“ in die ­Verantwortung gezogen wird. Die Arbeit in der IT, gerade als Führungskraft, stellt den Gleichmut mitunter auf eine harte Probe. Wenn man allerdings den Fokus auf die Freude über die Ergebnisse lenkt, dann hebt das die Stimmung und die Arbeit macht wieder Spaß. CIOs und IT-Manager sind angehalten, die Rahmenbedingungen dafür zu schaffen, dass ihre Mitarbeiter wirksam und erfolgreich Ergebnisse erreichen. Das kann Stolz erzeugen auf die Dinge, die erreicht wurden (auch wenn es nicht immer einfach war).

7.2

Das Führen von IT-Spezialisten

Unsere Unternehmen und speziell unsere hochgradig fein gegliederte Industrie braucht Spezialisten und Expertentum. Ohne echte Spezialisten ist die heute zu erbringende Wertschöpfung gar nicht abbildbar. Insbesondere in der IT-Abteilung eines Unternehmens finden sich solche Spezialisten. Manchmal eher abwertend, für manche aber auch lobend und durchaus mit Stolz als Nerds bezeichnet. Um eine IT-Organisation führen zu können, braucht es zweifelsohne diese Spezialisten für die diversen Programmiersprachen, für den Betrieb der Infrastruktur und auch für die IT-spezifischen Prozesse nach ITIL oder anderen, ebenfalls sehr speziellen Standards. Wenn der Chef einer solchen Abteilung nicht selbst als Spezialist in der Führungswelt untergehen will, dann muss er verstehen, wie Spezialisten geführt werden. Auf der anderen Seite darf der Spezialist nicht nur mit engstirnigem Blick auf sein Fachgebiet schauen, sondern er muss den Blick „fürs Ganze“ haben! Nehmen wir eine ERP-Einführung im Produktionsumfeld als Beispiel: Die am Projekt beteiligten Spezialisten achten nur auf „ihre“ Spezialaufgabe im Gesamtkomplex. In diesem Fall z. B. auf das Einstellen oder Customizing einer Funktion für das Wiegen von Fertigteilen. Das wird irgendwann auch wunderbar funktionieren, aber haben die beteiligten Spezialisten erkannt, wozu diese Funktion des Wiegens von Fertigteilen für das Unternehmen und seine Kunden wichtig ist, also den „Beitrag zum Ganzen“ leistet? Diese Wiegefunktion gab es vorher nicht und der Vertrieb hat immer nach Stückmengen verkauft in

160

7  Führungsgrundsätze für CIOs und IT-Leiter

der Hoffnung, dass alle Fertigteile gleich viel wiegen. Jetzt hat sich aber herausgestellt, dass nicht alle Fertigteile gleich viel wiegen und das Unternehmen bisher einen deutlichen Anteil des eigentlich vorhandenen Umsatzes nicht realisieren konnte. Mit dieser neuen Funktion kann nach Gewicht genau abgerechnet werden und der Umsatz steigt. Wären diese Auswirkungen den Spezialisten bekannt gewesen, dann hätte man auch gleich einen Report für die statistische Auswertung des Gewichts der Fertigteile und deren Umsatzentwicklung entwickeln können, um zu schauen wie sich dies auswirkt. Das wäre der Blick „für das Ganze“ gewesen. Man versucht dies heute durch Ende-zu-Ende-Prozesse besser in den Griff zu bekommen, trotzdem ist es häufig noch ein Problem das „große Ganze“ und das „Warum“ im Blick zu haben. Was ist jetzt in Bezug auf die IT aber der „Beitrag zum Ganzen“, wie kann der Spezialist zum Ganzen beitragen, anstatt nur auf sein Spezialgebiet zu schauen? Die Fragen, die sich hier stellen, sind: Was ist die Rolle der IT? Welchen Beitrag liefert die IT zum Gelingen des Unternehmens? Welchen Beitrag kann ich als IT-Spezialist zum besseren Ergebnis des Unternehmens beitragen? Das ist wichtig zu verstehen. Denn leider sind viele IT-Spezialisten z. B. einfach nur Experten im Programmieren mit Java oder dem Entwickeln von Apps. Das ist per se eine wichtige Kenntnis. Die wesentliche Frage ist aber: „Wo trifft dieses Spezialistenwissen auf einen Nutzen im Unternehmen?“. Anders gesagt: Wie kann der App-Entwickler einen Mehrwert für das Unternehmen schaffen? Es geht darüber hinaus nicht um das „Ich bin …“ (z.  B.  App-Entwickler, CIO oder ITIL-Service-Manager). Da wird nur der Titel, also die Position im Unternehmen angegeben. Es geht vielmehr um eine Aussage, was er oder sie tatsächlich macht. Also: „Ich sorge in diesem Unternehmen dafür, dass …“. Der Satz könnte, um bei den oben genannten 3 Beispielpositionen zu bleiben, abgeschlossen werden mit „Ich sorge in diesem Unternehmen dafür, dass • … unsere Kunden nicht mehr umständlich per Telefon oder Fax bestellen müssen, sondern einfach über eine App auf dem Smartphone bestellen können und damit Zeit sparen und der Auftrag vor allem genauso ankommt wie er gemeint war (App-Entwickler). • … durch eine performante und moderne IT das Unternehmen effizient arbeiten kann und unsere Kunden den bestmöglichen Service zu ihren Produkten bekommen (CIO. • … alle User im Unternehmen eine stabile, jederzeit verfügbare IT-Umgebung zum Arbeiten haben und Fehler schnell behoben werden, sodass jeder immer effizient arbeiten kann“ (ITIL-Service-Manager). Überspitzt gesagt: Wenn jedem Spezialisten klar ist, wie er durch seine Arbeit zum großen Ganzen beiträgt, dann muss er im Grunde auch nicht mehr geführt werden. Denn er weiß ja, warum er es macht, wozu er beitragen wird und kann sich somit selbst führen.

7.3  Konzentration auf das Wesentliche

7.3

161

Konzentration auf das Wesentliche

Insbesondere der CIO oder der IT-Leiter haben es in diesem Punkt schwer: Es sind je nach Unternehmen oftmals mehr als 7 oder 8 Fachbereiche mit unterschiedlichsten Anforderungen zu bedienen, die Technik entwickelt sich rasend schnell und es ist mehr als verständlich, wenn man sich schwertut hier immer auf dem neuesten Stand zu bleiben. Digitalisierung, künstliche Intelligenz und andere Themen müssen verstanden und angewandt werden können. Die Komplexität der Systemlandschaft muss man irgendwie in den Griff bekommen und dann wird auch noch verlangt, dass man neben der komplexen Technik eine Führungskraft ist und Change-Themen voranbringt. Wie soll man diesem bunten und vor allem großen Strauß an Herausforderungen gerecht werden? – Die Gefahr der Verzettelung ist enorm! Eine Maßnahme liegt in der Konzentration auf das Wesentliche. Das heißt nicht, dass man jetzt 3 von 8 Fachbereichen einfach ignoriert und die Systemlandschaft einfach so lässt wie sie ist. Sondern es heißt: Nicht alles auf einmal, sondern schön der Reihe nach. Denn das menschliche Gehirn ist nicht in der Lage, viele verschiedene Dinge gleichzeitig zu managen. Das bedeutet, dass man nicht auf allen Gebieten gleichzeitig erfolgreich sein kann. Nur durch Konzentration auf das Wesentliche und gerade akute Problem lässt sich Effizienz und Effektivität im Management der IT erreichen. Dazu ist Disziplin, im engeren Sinne viel Selbstdisziplin erforderlich. Denn die Gefahr ist sehr groß, gerade in der sich so rasant entwickelnden IT dem nächsten Thema hinterherzujagen und die Konzentration auf das eigentliche Thema zu vernachlässigen. Man könnte zuweilen sogar von Sturheit reden, die hier gefordert ist, um die Konzentration nicht zu verlieren. Ein großer Vorwurf an IT-Organisationen ist oft, dass sie nichts fertigkriegen und alles viel zu lange dauert. Gerade diesem Vorurteil kann nur durch Konzentration auf das Wesentliche begegnet werden. Denn es mangelt nicht an Methodenkenntnis oder Technikverständnis, dass in der IT Projekte oft verzögert sind oder sogar scheitern. Es mangelt in den allermeisten Fällen einzig und allein an dem „Zuviel“ von parallelen Themen und damit an mangelnder Fokussierung auf das Wesentliche. Manager und Führungskraft der IT haben die Aufgabe, das zu erkennen und umzusetzen. Es geht um Wirksamkeit und Umsetzungserfolge, die nur durch Konzentration auf das Wenige und Wesentliche erfolgen können. Was bzw. wie viel ist das Wenige? Der Psychologe George Miller hat in einer Untersuchung herausgefunden, dass maximal 7 plus/minus 2 Dinge pro Zeiteinheit zu schaffen sind [1]. Wer meint, dass auch mehr geht, der wird schnell feststellen, dass seine Arbeitsbilanz ganz hervorragend ausschaut, seine Ergebnisbilanz aber sehr kläglich sein wird. Und das ist dann die schon beschriebene Situation, die man in der IT häufig vorfindet: Es laufen zig Projekte, doch keines wird so richtig fertig und meistens auch nicht so erfolgreich wie geplant. Der CIO befindet sich dann nämlich immer in „Vielfrontenkriegen“, die nie zu gewinnen sind.

162

7.4

7  Führungsgrundsätze für CIOs und IT-Leiter

Mitarbeiterförderung: Stärken stärken!

Eine Führungskraft ist verantwortlich für den richtigen Einsatz von Mitarbeitern. Suchen CIOs oder Geschäftsführer Rat bei einer Vertrauensperson, so bekommt diese oft zu hören, dass das größte Problem das IT-Personal sei. Es sei nicht auf der Höhe der Zeit, es gebe viel zu viele Schwächen in den modernen und absolut notwendigen agilen Methodenkenntnissen und es seien alles „nur“ Techniker im Sinne von Nerds, mit denen man gar nicht „normal“ sprechen könne. Wer bei solchen Gesprächen tiefer bohrt, dem werden in der Mehrzahl immer nur die Schwächen eines IT-Mitarbeiters dargestellt: Die meisten haben keine Ahnung von agilen Methoden, es fehlen gute Programmierer und die Teamleiter seien auch nicht zu gebrauchen. Das ist sehr bedauerlich und es scheint, als sehen Menschen und gerade die Führungskräfte immer nur die Schwächen von Menschen. Viele teilen die Führungserfahrung, dass man bei vielen Mitarbeitern zuerst auf Fehler und Versäumnisse von Mitarbeitern gestoßen wird, nach dem Motto: „Der hat schon wieder seinen Quell-Code überhaupt nicht kommentiert.“ Oder „Die ruft einfach nie zurück!“ Sogar die Kunden sind schon erbost und wenden sich direkt an den Chef! Doch selbst wenn dies die ersten Rückmeldungen, die Führungskräfte über Mitarbeiter bekommen, hilft es nicht weiter, sich darüber aber zu beklagen und den Kopf in den Sand zu stecken. Der Ausweg ist im Grunde recht einfach: Jeder Mensch hat Stärken! Es geht darum, bei jedem Mitarbeiter die Stärken – und sei es nur eine einzige – ausfindig zu machen. Und diese muss dann so eingesetzt werden, dass sie dem Unternehmen maximal nutzt. Dann kann diese Stärke wachsen und sich noch besser entfalten. Das ist die Aufgabe einer Führungskraft. (Zum Thema „Erfolgreiches Führen von IT-Spezialisten“ finden Sie hier per Klick einen dazu passenden Artikel.) Ein häufig anzutreffender Fehler ist in diesem Zusammenhang die Beauftragung von Heerscharen an Coaches zur Minimierung der Schwächen von Mitarbeitern. Das soll nicht heißen, dass Coaching nicht wirksam ist. Im Gegenteil: Jeder, der professionelles Coaching erlebt hat kennt und schätzt die Erfolge, die ein Coaching bewirken kann. Aber was passiert wirklich? Die Schwäche des Mitarbeiters kann im Coaching nachhaltig bearbeitet werden. Der IT-Mitarbeiter ist besser geworden – aber in welchem Sinne? Er ist besser geworden im Sinne von „weniger schwach“. Aber zwischen „schwach“ und „stark“ gibt es noch ein großes Feld, nämlich das Feld der Mittelmäßigkeit. Und meistens landen die gecoachten Mitarbeiter genau in diesem Feld. Natürlich: Der bisherige Fehler oder Malus tritt nicht mehr jeden Tag auf, sondern nur noch alle 3 Tage. Das kann schnell als Fortschritt bewertet werden. Aber Vorsicht: Das ist ein Trugschluss! Als Führungskraft sollte man nicht die Schwächen von Mitarbeitern betrauern. Jeder hat Schwachstellen. Zielführender ist es, auf die Stärken zu schauen und zu überlegen, wie sich diese Stärken mit dem idealen Rollenprofil in der IT verbinden lassen. Die ideale Passung zwischen dem, was der Mitarbeiter kann und was er tun soll ist das Ziel.

Literatur

163

Wichtig ist allerdings, dass man als Führungskraft die Schwächen nicht komplett ausblendet. Schwächen von Mitarbeitern müssen bekannt sein, nicht um sie auszumerzen oder zu verbessern, sondern, um nicht den Fehler zu begehen, diesen Mitarbeiter auf eine Position zu setzen, in der er eine Schwäche hat. Wie ist jetzt vorzugehen, d. h. wie können Schwächen und Stärken erkannt werden und wie kann so eine Idealbesetzung erfolgen? Malik nimmt in seinem Buch Führen – Leisten – Leben die Analogie zum Sportlehrer oder Trainer auf. Und dieses Beispiel kann auch sehr gut für die IT gelten. Ein Trainer schaut genau, in welchen Sportarten sein Schützling wirklich gut ist. Wenn er erkennt, dass der ein guter Sprinter ist, dann wird dies sein einziges Betätigungsfeld werden. Wenn das klar ist, muss innerhalb dieser Stärke geschaut werden, wo die Schwächen liegen, damit diese verbessert werden, um in der stärksten Disziplin der Beste zu werden. Das ist beim Sprinter z.  B. das ständige Üben des Starts, denn nur bei ein bestmöglicher Start führt zum Sieg. Wenn dies klappt, nimmt man sich innerhalb der Stärke die noch vorhandene Schwäche vor und geht diese an. Es geht also um die Optimierung der wesentlichen Stärke eines Menschen im Sinne von „Stärken stärken“. Abschließend bleibt festzuhalten: Eine IT-Führungskraft hat die Aufgabe Jobprofile so zu kreieren, wie es für das Unternehmen nötig ist. Auf dieser Basis lassen sich die aufgrund ihrer individuellen Stärke am besten passenden Mitarbeiter auf die richtige Position setzen und fördern. Was nicht zu den Führungsaufgaben zählt, ist die Aufgabe, Mitarbeiter zu verändern. Das wäre ein Eingriff in die Persönlichkeit eines Menschen und damit nicht legitim. Das bedeutet aber auch: Man muss das nehmen, was einem gegeben wird und damit stärkenbasiert und möglichst effektiv arbeiten. Nicht mehr und nicht weniger.

Literatur 1. Malik, Fredmund: Führen Leisten Leben, 6. Auflage, Campus Verlag, 2006.

8

Sinn und Purpose als Führungs- und Steuerungsinstrument

Zusammenfassung

Was ist oberste Prämisse für die erfolgreiche Führung einer IT-Organisation? Der CIO muss Sinn und Purpose vermitteln können. Dazu helfen ein Zielbild und eine klare Vision für die IT. Wie ein solches Zielbild und eine dazugehörige Roadmap entwickelt werden, beschreibt dieses Kapitel.

8.1

Ein Zielbild für die IT entwickeln

Über eine Vision wird oft gelächelt und manch einer sieht es auch heute noch wie einst Helmut Schmidt: „Wer Visionen hat, soll zum Arzt gehen!“. In deutschen Unternehmen wird immer noch sehr rational gearbeitet. Prozesse, Strukturen, klare Hierarchien und Arbeitsanweisungen bilden weiterhin den Rahmen der Arbeit. Agilität, Netzwerkorganisationen und die Start-up-Welle bringen Bewegung in das stramme Gerüst aus dem Industriezeitalter. Viele wehren sich aber noch dagegen und tun dies als „neumodischen Schnickschnack“ ab. Nicht alles, was neu daher kommt, muss auch gut sein. Aber beim Thema Vision oder heute auch oft Purpose genannt soll hier klar Stellung bezogen werden. Wenn man selbst in einigen Projekten erleben durfte, welche Kraft von einer gemeinsam getragenen Vision ausgeht, so erlebt man seine Arbeit wieder sinnerfüllt. Seit Jahren erzählen uns Studien, dass mehr als die Hälfte der internen Mitarbeiter innerlich gekündigt haben. Mag es daran liegen, dass diesen der Sinn ihrer Tätigkeit abhandengekommen ist? Von daher: Was ist die Funktion einer Vision bzw. was soll sie bringen? • Die Vision ist das Fundament und die Basis für die Strategie. • Sie liefert Orientierung für das eigene Handeln. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 V. Johanning, Organisation und Führung der IT, https://doi.org/10.1007/978-3-658-12008-5_8

165

166

8  Sinn und Purpose als Führungs- und Steuerungsinstrument

• Visionen sind Landebahnen für Ziele! • Eine Vision, die klar und mit Fakten unterlegt Mehrwerte und Nutzen stiftet und hinter der alle stehen, weckt Überzeugung und vor allem Motivation für alle Mitarbeiter! Zugegeben: Viele Visionen – insbesondere die von großen Konzernen – kommen oft hölzern daher und wirken irgendwie alle gleich. Wie soll da eine Identifikation stattfinden? Warum sollte man als einer von Tausenden von Mitarbeitern das gut finden? Aber: Soll man deswegen sofort kündigen? Konzerne haben es da auch nicht leicht. Für eine IT-Organisation zwischen 20 und 500 Mitarbeitern ist es einfacher, eine für die gesamte IT und zum Unternehmen passende IT-Vision zu formulieren. Folgende Fragen stehen auf dem Weg zu dieser Vision primär im Fokus: • Wozu gibt es uns als IT im Unternehmen? • Was treibt uns an? • Wo wollen wir in 3 oder 5 Jahren stehen? Die Vision wird dadurch entwickelt, dass man sich auf eine Zeitreise begibt. Das mag zunächst komisch klingen, aber genau das macht die Vision aus. Es darf während der Arbeit geträumt werden! Welche Geschehnisse sind anders als heute und mit welchen erlebbaren Folgen? Bilder sind dabei wichtiger als Zahlen! Die Manager sollen perspektivisch und emotional gefühlt schon da gewesen sein, wo sie real hinkommen wollen. Es hat sich bewährt, die Vision gemeinsam mit dem IT-Leitungsteam sowie der Geschäftsleitung zu entwickeln. Das heißt, es sind ca. 5–10 Personen beteiligt. Als Moderator bietet sich ein neutrale Person an, aber der CIO kann das auch selbst machen, wobei dann die Neutralität infrage gestellt ist. Als erstes muss ein Zieldatum festgelegt werden. Es bietet sich ein Zeitraum von mindestens 3–4 Jahren und maximal 7–8 Jahren in der Zukunft an. Fünf Jahre bilden da oft die goldene Mitte und so wird hier der 01.01.2025 als Zieldatum angenommen. Um diese Vision oder das sogenannte Zielbild zu entwickeln, helfen die folgenden Fragen und Aktionen: • • • • • •

Jeder der Teilnehmer versetzt sich jetzt in das Jahr 2025. Man schaut sich an, was gerade passiert. An welchen Themen wird gearbeitet? Was sind wichtige Projekte? Worauf ist man im Jahr 2025 stolz? Was hat man gemeinsam erreicht? Was ist alles schon da und worauf kann man aufbauen? Wie fühlt sich das an?

Wichtig ist es nun, diese ganzen Erkenntnisse in Prosa niederzuschreiben; ein weißes Blatt Papier, das man ganzseitig füllt, ist vollkommen ausreichend. Diese Werke sammelt

8.2  Wie wird das IT-Zielbild erreicht? – Das Erstellen der IT-Roadmap

167

Abb. 8.1  Beispiel für gute und schlechte IT-Zielbilder/IT-Visionen

der Moderator als objektiver und neutraler Experte für die Strategiearbeit. Es können durchaus 2 oder 3 Versionen von der Vision bzw. dem Zielbild erstellt werden. Jetzt bekommt jeder Teilnehmer alle Dokumente zugeschickt mit der Bitte, diese zu bewerten: • Was ist gut? Was ist schlecht? Was fehlt? Anschließend kommt erst der Workshop, in dem als Ziel eine Gesamtvision bzw. ein Gesamtzielbild aus allen Einzeldokumenten erstellt wird. Dazu treffen sich alle ­Teilnehmer, um aus den bekannten Einzeldokumenten ein Gesamtdokument und ein Gesamtzielbild zu erstellen. Dazu sind ca. 3  Stunden einzuplanen; idealerweise erfolgt die Erstellung des Gesamtdokumentes „live“ für alle ersichtlich in einem Word-Dokument, sodass alle mit dem gleichen Ergebnis vor Augen nach Hause gehen. Die Abb. 8.1 zeigt abschließend Beispiele für gelungene und weniger gelungene Zielbilder, um eine Orientierung zu geben.

8.2

 ie wird das IT-Zielbild erreicht? – Das Erstellen der W IT-Roadmap

Jetzt kann der Weg von der heute bestehenden Ausgangssituation zur gerade entstandenen IT-Vision entwickelt werden.

168

8  Sinn und Purpose als Führungs- und Steuerungsinstrument

Dabei ist es ganz wichtig, nicht von heute bis zur IT-Vision im Jahr 2025 zu denken, sondern rückwärts. Das heißt konkret: • Man versetzt sich wieder in das Jahr, in dem das eigene Zielbild als IT-Vision konkretisiert wurde! • Was ist dort zu sehen? Was wurde erreicht? • Was waren damals erste Schritte, die konkret gegangen wurden? • Welche Maßnahmen wurden abgeleitet? • Welchen Schwierigkeiten ist man begegnet? • Wie wurden diese gemeistert? • Was braucht man also schon heute, um überhaupt dahin zu gelangen? Das ist die sogenannte Arbeit an der „strategischen Lücke“. Diese strategische Lücke bezeichnet den Bereich, der zwischen dem im Zielbild Gesehenen liegt und dem, was heute tatsächlich ist. Anders formuliert: „Was ist das Gap zwischen der Vision und dem heutigen Ist-Zustand?“ (Abb. 8.2). Die IT-Roadmap gibt eine Übersicht über alle wichtigen Themen, Aufgaben und Projekte für die kommenden 2–3 Jahre auf einem Zeitstrahl. Der generelle Aufbau folgt der Strategiearbeit aus der Phase 3. Ausgangspunkt der IT-Roadmap ist das IT-Assessment mit seinen Ergebnissen und Gaps bzw. Deltas. Das Ziel der IT-Roadmap ist die IT-Vision, in der die Gaps und Deltas möglichst zum großen Teil durch mehrere Transformationsschritte aufgelöst worden sind. Die IT-Roadmap bildet damit einen verbindlichen Rahmen, der die

Abb. 8.2  Die IT-Roadmap im Überblick

8.2  Wie wird das IT-Zielbild erreicht? – Das Erstellen der IT-Roadmap

169

Ergebnisse des IT-Assessments und der IT-Vision mit den dafür nötigen Transformationsschritten vereint. Um diese Transformationsschritte lebendig zu machen, kann ein Bebauungsplan da­ raufgesetzt werden. Die Schritte der Transformation bekommen dann Kontur und werden auf Jahresscheiben geteilt mit konkreten IT-Projekten „bebaut“. So wird sehr schnell deutlich, was auf der IT-Roadmap in den kommenden Jahren „geliefert“ wird und wie das auf die IT-Vision des Unternehmens einzahlt.

9

Agilität und Dynamik braucht eine neue Form von Führung

Zusammenfassung

Was sind die Besonderheiten der Führung in Zeiten von Agilität und Dynamik? Was bedeutet das für den CIO und welche Entwicklungsschritte kann und muss er gehen, um in einem dynamischen und agilen Umfeld erfolgreich führen zu können? Dazu gibt dieses Kapitel einen tiefen Einblick in das Thema „Leadership Agility“.

9.1

 eadership Agility: Wirksame Führung in einer agilen und L dynamischen Welt

9.1.1 Der Ausgangspunkt von Leadership Agility Das Buch Leadership Agility von Bill Joiner [1] hat es bereits 2006 sehr gut auf den Punkt gebracht: Die Post-Industrie-Ära mit fast vollkommener Vernetztheit durch das Internet und einer damit stark steigenden Komplexität braucht eine andere Art von Führung. Digitalisierung in all ihren Facetten von Industrie 4.0, über IoT bis hin zur künstlichen Intelligenz (KI) berührt den Kern von Zusammenarbeit, Führung und Steuerung in Organisationen. Die Abb. 9.1 verdeutlicht die historische Entwicklung von Dynamik und Komplexität und zeigt, welche Führungsmodelle jeweils im Vordergrund standen. Beginnend mit der industriellen Revolution und der Fließbandarbeit nach tayloristischen Prinzipien um 1920 stieg die Komplexität und Dynamik (also das Tempo von Veränderungen) immer weiter an. Zu dieser Zeit des Taylorismus ließ sich ein Unternehmen führen wie eine relativ einfache Maschine. Mitarbeiter konnten als Teile dieser Maschine betrachtet werden. Damit das reibungslos funktionierte, waren sie aufgefordert, menschliche Fähigkeiten wie Intelligenz, Fantasie und Initiative am Werktor abzugeben. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 V. Johanning, Organisation und Führung der IT, https://doi.org/10.1007/978-3-658-12008-5_9

171

9  Agilität und Dynamik braucht eine neue Form von Führung

Dynamik – Tempo von Veränderung

172

Hoch (2000-?) - Agile Steuerung Moderat (10 -2000) -Strategische Planung Niedrig (1 20-10) -Taylorismus

Komplexität – gegenseitige Abhängigkeiten Leadership 1.0 Predict & Control

Leadership 2.0 Dynamische Steuerung

Abb. 9.1  Die historische Entwicklung von Komplexität und Dynamik

In der 2. Hälfte des vorigen Jahrhunderts nahmen Komplexität und Dynamik erheblich zu. Dies konnte durch strategische Planung wirksam gesteuert werden. Es war die Blütezeit klassischer Strategieberatungen, die das Unternehmen mit Erfolg als eine mittlerweile deutlich kompliziertere Maschine betrachteten [2]. Diese Maschine ließ sich zerlegen und im Kontext des Marktumfelds analysieren und auf eine bessere, effektivere Art wieder neu zusammensetzen. Diese Vorgehensweise entwickelte sich im vergangenen Jahrhundert zu hoher Reife. Sie war überaus erfolgreich und ermöglichte einen enormen Zuwachs an Produktivität. Auf der Führungsebene war „Predict & Control“ im Sinne von Zielen setzen und diese versuchen zu erreichen, das maßgebliche Mittel. Dieses Management by Objectives (MbO) funktioniert in der heutigen Welt immer weniger und führt zu Frustration. Wie soll aber gesteuert und geführt werden und wie können Ziele heute erreicht werden? Es zeigt sich heute eine Vielzahl von Anhaltspunkten, warum die Führung nach Zielen sowie die alte Lehre der strategischen Planung an ihre Grenzen kommt [3]: • Die Organisation überhitzt: Es wird immer mehr gearbeitet, ohne dass sich die Ergebnisse merklich verbessern. • Bereits erledigt geglaubte Probleme oder Konflikte tauchen immer wieder auf. Lösungsversuche schaffen neue Schwierigkeiten an anderer Stelle. • Statt reflektiert Neues zu gestalten wird reflexartig reagiert – entweder mit Aktionismus oder sich ausbreitender Lähmung. • Das Kontroll- und Berichtswesen (also die alten Steuerungsansätze) werden angezogen in dem Versuch, das so immer schlechter steuerbare doch noch in den Griff zu kriegen. • Die Zahl der Burn-out-Fälle steigt an.

9.1  Leadership Agility: Wirksame Führung in einer agilen und dynamischen Welt

173

Dies sind klare Anzeichen dafür, dass das Steuerungsmodell selbst an seine Denk-, Handlungs- und Wirksamkeitsgrenzen geraten ist. Insbesondere die IT-Abteilung und deren Führungskräfte sind von diesem Wandel im Innersten be- und getroffen. In der IT ist die Dynamik und Komplexität insbesondere durch die immer schneller voranschreitende Technologisierung (siehe Mooresches G ­ esetz) besonders hoch. Um auf dieser Ebene nicht von ständigen Innovationen getrieben zu werden, muss der CIO zum Innovationstreiber werden.

9.1.2 Wie wird man zum Innovationstreiber? Zunächst ist es wichtig zu wissen, dass es Innovationen sozusagen inhärent ist, dass sie nahezu niemals strategiegetrieben von oben nach unten stattfinden. Innovationen können nicht per Strategiemeeting „verordnet“ werden, sondern finden an vielen Stellen im Unternehmen gleichzeitig einfach statt. Aber nur, wenn bestimmte Voraussetzungen erfüllt sind. Dazu gehören z. B. ein hohes Maß an Selbstverantwortung bei den Mitarbeitern, Eigeninitiative und Dinge wie Job-Rotation und Job-Enlargement. Auf Spannungen und Probleme wird sofort reagiert und die die darin enthaltene Information wird als kreatives Potenzial genutzt. Hinzu kommt, dass Hierarchien sehr flach oder durch netzwerkartige Strukturen ersetzt worden sind. In dem sehr lesenswerten Buch Reinventing Organizations von Frederic Laloux [3] können Beispiele für solche Organisationen gefunden werden. Es wird beispielhaft anhand von 12 Unternehmen gezeigt, wie Selbstorganisation stattfindet und welche Auswirkungen diese auf die Mitarbeiter selbst, aber auch auf die Wettbewerbsfähigkeit des Unternehmens hat. Agil geführte Unternehmen sind wirtschaftlich deutlich erfolgreicher als Unternehmen mit eher starren Strukturen und Prozessen. Deshalb sehen wir auch in konventionell geführten Organisationen vielerorts Initiativen wie selbststeuernde Teams oder agiles Projektmanagement, die auch die IT-Organisation agiler machen sollen. Woran liegt es nun, dass einige dieser Experimente viel Energie freisetzen und Themen lösen, die vorher unlösbar erschienen, während andere nach manchmal schon kurzer Zeit eher Frustration und Enttäuschung hervorrufen und „agil“ zum modernen Management-Unwort machen? Oft liegt es einfach an 2 Dingen: . Man unterliegt dem Irrglauben, dass Agilität keiner Führung bedarf. 1 2. Man kopiert einfach nur Vorgehensweisen und Modelle, ohne diese zu verstehen. Zu Punkt 1 ist zu sagen, dass agile Initiativen nur dann erfolgreich sein können, wenn sie von Menschen gestaltet werden, die eine agile Führungshaltung mitbringen. Agile Führung braucht nicht nur ein neues Set von Kompetenzen und Methoden, sondern eine Haltung, die klassischem Führungs- und Steuerungsdenken an vielen Stellen diametral entgegengesetzt ist.

174

9  Agilität und Dynamik braucht eine neue Form von Führung

Um agile Projekte zum Erfolg zu führen, braucht es also nicht nur ein Methodenset, sondern vor allem einen sehr spezifischen Mind-Set. Fehlt dieser, ist ein Scheitern oft vorprogrammiert. So ist Laloux [3] bei seiner Untersuchung agiler Organisationen zu dem Schluss gekommen, dass es genau diese agile Führungshaltung braucht, um eine agile Organisation gestalten zu können. Daraus leitet sich die Frage ab, was denn nun genau eine „agile Führungshaltung“ ist und wie sich diese von klassischem Führungsverständnis unterscheidet.

9.1.3 L  eadership Agility: Von konventioneller Führung zu agiler Führung Im Rahmen von vielen Forschungsprojekten hat sich gezeigt, dass sich Manager mit zunehmender Reife der Führungspersönlichkeit durch unterschiedliche, beschreibbare Ebenen von Führungsagilität entwickeln, die sich in ihrer Haltung und ihrem Verständnis von Führung grundlegend unterscheiden. Dabei wurden nicht nur charakteristisches beobachtbares Führungsverhalten, sondern auch die mental-emotionale Kapazitäten untersucht, die diesem Verhalten zugrunde liegen. Die Abb.  9.2 zeigt in welchen Bereichen von Komplexität und Dynamik die 3 im ­Führungskontext wichtigsten Ebenen ihre größte Wirksamkeit zeigen  – vom taktisch-­ problemlösungsorientierten „Expert“ über den strategisch-zielorientierten „Achiever“ (beides Varianten konventioneller Führung) hin zum visionär-entwicklungsorientierten „Catalyst“ (agile Führung). Der Expert: „Ich weiß es“ Wenn Komplexität und Dynamik überschaubar sind, ist es möglich zu führen als der der weiß, wie es geht. Manager auf der Expert-Ebene sehen in ihrer fachlichen Kompetenz die Basis ihrer Autorität als Führungskraft. Von daher legen sie großen Wert darauf, fachlich auf dem aktuellen Stand zu sein, um so ihren Mitarbeitern fundiert Anweisungen geben zu können. Expert-Management ist stark darin, bekannte Themen in die operative Umsetzung zu bringen. Dabei gibt es ein starkes Bestreben, mittels eigener Erfahrung Probleme zu lösen. Gleichzeitig ist hier die Heimat von Mikromanagement, oft verbunden mit der Bürde einer hohen Arbeitslast. Der Blick ist taktisch-operativ und richtet sich in erster Linie auf den eigenen Verantwortungsbereich. Dabei wird ein Problem, eine Person, eine Funktion zurzeit in den Fokus genommen, mit wenig Blick auf funktionsübergreifende Abhängigkeiten. Der Achiever: „Ich kenne das Ziel“ Während eine Expert-Führungskraft Aufgaben managt, sieht es der Achiever-Manager als seine Aufgabe, Menschen zu führen. Ihm geht es darum, ein ganzes System auf strategi-

175

Dynamik – Tempo von Veränderung

9.1  Leadership Agility: Wirksame Führung in einer agilen und dynamischen Welt

Komplexität – gegenseitige Abhängigkeiten Leadership 1.0 Konventionelle Führung Predict & Control

Leadership 2.0 Agile Führung Dynamische Steuerung

Abb. 9.2  Die Führungsebenen im Kontext von Dynamik und Komplexität

sche Ziele hin in Bewegung zu setzen und andere durch befriedigende Mitarbeit an einem herausfordernden Ziel zu motivieren. Der Fokus ist strategisch mit Blick auf den Kunden, sei er intern oder extern. Ziele und Ergebnisse spielen eine zentrale Rolle. Dabei stützt er sich stark auf Mitarbeiter mit einem ähnlichen „Mind-Set“, die schnell als Leistungsträger identifiziert werden. Diesen lässt er Freiheit bei der Umsetzung. Ein Achiever-Manager hat einen klaren Blick auf das gesamte funktionale System und damit einen guten Überblick über die Stakeholder, die für das Erreichen seiner Ziele wichtig sind. Er sieht Teamarbeit als Schlüssel zum Erfolg. So wird er in regelmäßigen Teammeetings dafür sorgen, dass es Austausch und Debatten zu für ihn wichtigen Themen gibt. Der Catalyst: „Ich gestalte wirksame Zusammenarbeit“ Wenn für den Achiever-Manager das Erreichen strategischer Ziele im Mittelpunkt steht, reicht die Vision eines Catalyst Leader darüber hinaus. Ihm ist klar, dass die Antwort auf zunehmende Unsicherheit in einer agilen Organisationskultur liegt. In der Kampfkunst gibt es die Technik, durch das Ziel hindurch das Ziel hinter dem Ziel anzuvisieren. In Analogie dazu wird er versuchen, den Weg zu strategischen Zielen so zu gestalten, dass dieser die Schaffung einer agilen und partizipativen Hochleistungskultur fördert, geprägt durch Werte wie Transparenz, Selbstverantwortung, Offenheit und gleiche Augenhöhe. Dabei denkt er die Organisation und ihre Themen nicht nur als funktionalen Organismus, sondern auch als komplexes soziales System mit einer hohen Wahrnehmung für die damit verbunden menschlichen und emotionalen Themen.

176

9  Agilität und Dynamik braucht eine neue Form von Führung

Der IT-Leiter eines schnell wachsenden Internet-Start-ups hat es einmal so ausgedrückt: „Früher war ich Architekt von IT-Systemen. Heute bin ich Architekt eines sozialen Systems.“ In Abb.  9.3 wird der Unterschied zwischen konventioneller und agiler Führung verdeutlicht. In dem linken Kästchen ist die konventionelle Führung dargestellt. Der primäre Fokus liegt auf dem Erreichen von Zielen durch direkte Führung von Führungskraft (FK) zu Mitarbeiter (MA). Dies geschieht durch Anweisung, Zielvereinbarung oder Delegation. Im Gegensatz dazu ist die Führungskraft in der rechten Abbildung nicht mehr im Kasten dargestellt, sondern bildet diesen als eine Art Handlungsrahmen ab. Die Mitarbeiter sind untereinander eng vernetzt. Dies führt dazu, dass diese Form der Organisation schnell auf noch unbekannte Entwicklungen antworten kann. Auch ist keine direkte Verbindung zwischen Führungskraft und Mitarbeiter erkennbar, denn Führung funktioniert hier nicht auf Basis von direkter Anweisung und Kontrolle, sondern die Führungskraft steckt den Rahmen ab. Dieser Rahmen kann durch die folgenden Fragen deutlich werden: • • • • •

Wer sind wir? Wofür stehen wir? Was sind unsere handlungsleitenden Prinzipien? Was ist unsere Ausrichtung? Wohin wollen wir uns entwickeln? Was sind Ziele und Vorgaben, die wir erreichen müssen? Wie können wir unsere individuellen Talente am besten nutzen, um diese zu erreichen? Was sind Rahmenbedingungen und Leitplanken unseres Handelns?

Innerhalb dieses Rahmens entsteht Raum für effektive Selbstorganisation und individuelle Potenzialentfaltung. Der Zusammenhalt des Unternehmens wird also nicht mehr in erster Linie durch zentrale Steuerung, sondern durch ein gemeinsames Verständnis von strategischer Ausrichtung und handlungsleitenden Prinzipien gewährleistet. Kulturtransformation beginnt bei mir

FK FK

MA

MA

MA

MA MA

MA

Konventionelle Führung Predict & Control Abb. 9.3  Konventionelle versus agile Führung

MA

Agile Führung Dynamische Steuerung

9.1  Leadership Agility: Wirksame Führung in einer agilen und dynamischen Welt

177

Ein Catalyst Leader weiß, dass Kultur bei ihm selbst beginnt. Von daher wird er Kulturentwicklung nicht an HR delegieren, sondern in seinem eigenen Managementteam ­beginnen und dieses als eine Art Labor nutzen, in dem seine Zielkultur gelebt wird und in die Organisation ausstrahlt. Die Tab.  9.1 zeigt die Unterschiedlichkeiten der Expert-, Achiever- und Catalyst-­ Führung. Es ist wichtig zu verstehen, dass die nächsthöhere Ebene die vorhergehende(n) mit einschließt. Das heißt also: Der Achiever kann jederzeit auf die als Expert erlernten Elemente zurückgreifen. Genauso kann der Catalyst sowohl auf Achiever- als auch auf Expert-Erfahrungen zurückgreifen und diese bei Bedarf nutzen. Tab. 9.1  Der Unterschied zwischen Expert, Achiever und Catalyst

Fokus

Denken und handeln

Umgang mit Konflikten

Konventionelle Führung Expert Taktisch und problemlösungsorientiert. Basis von Führung ist fachliche Autorität Blick auf einzelne Themen. Denken in der fachlichen Logik

Agile Führung Catalyst Visionär, potenzial- und entwicklungsorientiert. Führung inspiriert und befähigt Blick auf das funktionale und soziale System. Bewusste Gestaltung des Zusammenspiels von Menschen zum Erreichen gemeinsamer Ziele

Konflikt als kreatives Potenzial, Suche nach Win-win-Lösungen Reden und Kommunikation der Diskussion, Kreative Betätigung zur zuhören „richtigen“ Idee Wettstreit definierter Weiterentwicklung von Ideen Ideen Führungsstil Fokus da wo es brennt, Mehr einbeziehen Gestaltung selbst Hauptthemen fokussieren und delegieren als entwickelnder Prozesse selber lösen Unternehmen und Markt Unternehmen als Steuerungsmodell Unternehmen als als komplexe Systeme komplizierte komplizierte Maschine agiler Steuerung: Maschine „Predict & Control“: „Predict & Control“: schnelle Antworten auf effiziente Umsetzung effiziente Umsetzung unbekannte bekannter Ziele Entwicklungen bekannter Ziele Werte Berechenbarkeit, Klarheit, Leistung, Effizienz, Lernen, Entwicklung, Potenzialentfaltung, Eindeutigkeit, Fakten Messbarkeit, Perspektivenintegration, Wachstum, Flexibilität, Kreativität, Wettbewerb, Balance, Sinn Ergebnis Verbreitung in % 55 35 10 In Anlehnung an [3]

Richtig und falsch, gewinnen und verlieren

Achiever Strategisch und ergebnisorientiert. Führung mobilisiert für Zielerreichung Blick auf das funktionale System. Zielorientiert, rational, analytisch, Fokus auf Sachebene (Zahlen, Daten Fakten) Kompromiss/Deal

178

9  Agilität und Dynamik braucht eine neue Form von Führung

Was ist nun der Kern von Catalyst-Führung und was liegt ihr zugrunde? • Die Fähigkeit unterschiedliche, auch sich scheinbar widersprechende Perspektiven zu einer Gesamtschau zusammenzufügen und auf Basis dieser Gesamtschau zu entscheiden. • Das schnelle Einnehmen einer „Adlerperspektive“, um auf dieser Ebene komplexe Probleme zusammenzuführen und völlig neue Entscheidungen zu ermöglichen. • Achtsamkeit als eine kontinuierliche (sozusagen „online“) Reflexionskapazität: ein wahrnehmender Abstand zur eigenen Sicht der Dinge und der Quelle des eigenen Denkens, Fühlens und Handelns. • Perspektivenwechsel: die Fähigkeit, sich von der eigenen Sicht so weit zu lösen, dass es möglich wird, sich für eine ganz andere Sichtweise authentisch zu interessieren. • Diese Haltung ist die Basis für multiperspektivisches Denken: Die Fähigkeit unterschiedliche, auch sehr widersprüchliche Sichtweisen auf eine Situation, ein Thema oder ein Problem gleichzeitig wahrzunehmen und diese auf einer höheren Ebene wieder zusammenzuführen. • Darüber hinaus ist ein gelassener Umgang mit eigenen Ängsten und Schwächen unbedingte Voraussetzung dafür, diese Fähigkeiten nicht nur bei Schönwetterlage, sondern auch in unvermeidlichen Krisen stabil zu verkörpern. Diese Kompetenzen sind Voraussetzung, um agile Strukturen und Prozesse zu gestalten, den dafür notwendigen Raum zu schaffen und auch unter Druck zu halten.

9.1.4 W  ie kann agile Führung in der IT-Organisation umgesetzt werden? Zunächst bleibt aus den bisherigen Erkenntnissen des Konzeptes der „Leadership Agility“ folgendes festzuhalten: • In vielen Unternehmen und IT-Organisationen stößt die konventionelle Führung nach Predict & Control sowie strategischer Planung und Führung nach Zielen zunehmend an Grenzen. • Agile Führung hat sich noch nicht als heilende Alternativmethode durchgesetzt und wird oft als „Schablone“ oder Vorgehensmodell verstanden und damit nicht richtig eingeführt. • Dabei unterscheidet sich agile Steuerung radikal von konventioneller Steuerung. • Der wichtigste Erfolgsbaustein: Agile Initiativen brauchen Führung, allerdings nicht mehr auf Expert- oder Achiever-Ebene, sondern auf Catalyst-Niveau.

9.1  Leadership Agility: Wirksame Führung in einer agilen und dynamischen Welt

CC

179

Agile Strukturen erfordern nicht weniger Führung, sondern vielmehr eine gänzlich andere Art von Führung. Der Catalyst verkörpert den Prototypen des agilen Führungsverständnisses.

Fest steht, dass nur durch das entsprechende Führungs-Mind-Set agile Organisationen erfolgreich eingeführt und gelebt werden können. Aus dieser Betrachtungsweise heraus ergeben sich folgende Fragen für die IT-Führung und die Personalentwicklung: • Wie können der CIO und die Geschäftsleitung zum Sponsor agiler Initiativen werden? • Wo in einer IT-Organisation besteht der höchsten Bedarf für mehr Agilität? • Wie identifiziert man Entscheider oder Führungskräfte, die in der Lage sind, agile Initiativen zu treiben? • Was ist zu tun, um diese Leute an die richtigen Plätze zu bringen? • Wie schafft man den Freiraum, der es diesen Pionieren als Catalyst erst ermöglicht, auch neue Strukturen und Prozesse zu entwickeln? • Wie kann die Personalentwicklung helfen, um solche Catalyst-­Führungspersönlichkeiten zu identifizieren und zu entwickeln? • Wie werden Personen mit Catalyst-Potenzial rekrutiert? Hier kann es hilfreich sein, Innovatoren mit Catalyst-Potenzial zu identifizieren, sie mithilfe gezielter Entwicklungsprogramme zu fördern und sie untereinander zu vernetzen, beispielsweise indem sie gemeinsam an bedeutsamen Veränderungsprojekten arbeiten. Ein positiver Nebeneffekt ist, dass auf diese Weise Potenzialträger an das Unternehmen gebunden werden. Darüber hinaus stehen Unternehmen und deren IT-Organisation, in denen Expert-­ Achiever-­Führung seit Jahrzehnten die Norm ist, vor der historischen Herausforderung, eine ausreichende Zahl von Managern auf eine ganz neue Ebene von Führung hinzuführen. Traditionelle Führungskräfteentwicklung bietet eine Vielzahl erprobter und leistungsfähiger Werkzeuge, um den Entwicklungsschritt von der taktisch-operativen Expert-Ebene auf die strategisch-zielorientierte Achiever-Ebene zu unterstützen. Diese klassischen Führungskompetenzen schaffen die Basis für agile Führung. Agile Führung erfordert allerdings, Führung ganzheitlich neu zu denken. Sie beruht auf einer Haltung, die sich von bisherigen Bildern von Führung radikal unterscheidet. Die Entwicklung einer neuen Haltung geschieht nicht allein durch kognitive Einsicht, sondern vor allem durch tief greifende persönliche Erfahrung. Auf agile Führung zielende Entwicklungsprogramme brauchen deshalb einen hohen Anteil an Selbstreflexion und erfahrungsbasierter Persönlichkeitsentwicklung. Auch transformatives Coaching kann in diesem Übergang ein entscheidender Katalysator sein.

180

9.2

9  Agilität und Dynamik braucht eine neue Form von Führung

Besonderheiten der Führung im digitalen Zeitalter

Der digitale Wandel hat das Schlüsselwort schon in sich tragend: Wandel. Es geht also um einen Veränderungsprozess. Diese Veränderung findet auf vielen Ebenen statt: Strategie, Prozesse, Kultur und eben auch Führung. Was ist bei solchen Veränderungsprozessen das Wichtigste, gerade in Bezug auf gute Führung im digitalen Wandel? • Offenheit, • Ehrlichkeit und • Authentizität. Daneben spielen auch digitale Themen eine Rolle, wie z. B.: • Offenheit für Neues – Innovationsgeist wecken • Komplexität meistern und reduzieren können • Neue Technologien verstehen und adaptieren können Hinzu kommt ein wesentlicher Punkt: das Fordern und Fördern der Mitarbeiter. Denn es geht um lebenslanges Lernen. Es geht darum, immer wieder neue Herausforderungen verstehen, antizipieren und dann meistern zu können. Denn Digitalisierung ist keine Modeerscheinung, die übermorgen durch etwas anderes abgelöst wird. Gerade beim Thema Fördern und lebenslanges Lernen ist es sehr wichtig, wirklich alle im Unternehmen mit auf die Reise zu nehmen: Sowohl die Generation der Babyboomer als auch die Digital Natives (siehe zum Thema des Zusammenwachsens der Generationen im digitalen Unternehmen auch den Teil I dieser Leadership 4.0-Reihe). Ein anderer Punkt bei der Führung im digitalen Zeitalter dreht sich um die Prozesse. Anstatt des internen Fokus auf die Optimierung des Unternehmens durch effizientere Prozesse, liegt das Augenmerk in der digitalen Welt endlich wieder beim Kunden. Das Stichwort lautet: Customer Centricity. Last but surely not least steht das Thema „Strategie und Vision“. Die Führungskraft muss in der Lage sein, die digitale Strategie und Vision vorzuleben und immer wieder mit Leben zu füllen. Bei allen Aspekten, die hier genannt wurden, gilt eines stets als selbstverständlich: Die Führungskraft geht mit gutem Vorbild voran. Denn nur so kann Authentizität gewährleistet werden. Zusammenfassend ergeben sich die folgenden Punkte: 1 . Offenheit für Neues – Innovationsgeist wecken 2. Komplexität meistern und reduzieren können 3. Neue Technologien verstehen und adaptieren können

Literatur

181

. Fordern & Fördern von Mitarbeitern – lebenslanges Lernen/Wissensmanagement 4 5. Customer Centricity anstatt interner Prozessoptimierung 6. Geschwindigkeit 7. Strategie & Vision als Fundament

Literatur 1. Joiner, Bill & Josephs, Steven: „Leadership Agility: Five Levels of Mastery for Anticipating and Initiating Change“, 2. Auflage, Jossey-Bass. 2006. 2. Brenner, W./Witte, C.: „Erfolgsrezepte für CIOs“, 1. Auflage, Hanser, 2007. 3. Küster, Hermann: „Leadership Agility – die Führungsherausforderung in der IT“ erschienen in Michael Lang: „CIO 3.0: Die neue Rolle des IT Managers“, Symposium Publishing 2014.

Führung der IT über Ziele? – OKRs statt Management by Objectives (MbO)

10

Zusammenfassung

Früher was Management by Objective (MbO) – also das Führen über klare Zielvorgaben und Kontrolle der Ziele modernes Management. Das hat sich vollständig überholt. Das neue Motto lautet: Führen über OKRs wie man es von Google kennt. Was es damit auf sich hat, erfahren Sie im folgenden Kapitel.

10.1 Definition und Ziele von OKRs Google wird oft als Pionier und Erfinder der OKRs (Objectives and Key Results) genannt und nutzt diese Methode schon seit den frühen 2000er-Jahren. Seit einigen Jahren hat sich die OKRs-Methode auch bei deutschen Start-ups durchgesetzt und findet gerade den Weg in die traditionellen Unternehmen. Schlicht gesagt steckt hinter den OKRs ein Führungsmodell auf Basis von Zielen. Nichts wirklich Neues könnte man auf den ersten Blick meinen, denn Zielvereinbarungen und Management by Objectives (MbO) ist in den Konzernen seit vielen Jahren Usus. Der Vorteil von OKRs gegenüber den bisherigen Zielvereinbarungen liegt in den folgenden Punkten: • OKRs verbinden die Strategie/Vision direkt mit den Zielen von kleinen Teams. • Dabei sind die Ziele „auf Sicht“ angelegt, d. h. maximal 3–6 Monate in der Zukunft – im Gegensatz zur Strategie, die sehr langfristig (3–5 Jahre) angelegt ist und auch im Gegensatz zu den Zielvereinbarungen, die meistens 1 Jahr umfassen. • Die Ziele (Objectives) müssen dabei immer auf die Strategie einzahlen, d. h. auf dem Weg zur Strategie die aktuell passenden Ziele sein, die den Weg zur Strategie weiter ebnen. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 V. Johanning, Organisation und Führung der IT, https://doi.org/10.1007/978-3-658-12008-5_10

183

184

10  Führung der IT über Ziele? – OKR statt Management by Objectives (MbO)

• OKRs schaffen damit Klarheit über die kurzfristig zu erledigenden Aufgaben im Unternehmen und sorgen für Transparenz • Der Clou dabei ist, dass die emotionale Verbundenheit zu einem kurzfristig zu erlangenden Ziel über die 3 Monate aufrechterhalten bleibt und damit die Motivation groß ist, dieses auch zu erreichen. Bei der puren Verfolgung einer Strategie mit einem langfristigen Horizont geht einem schnell der Atem aus und der Strategieprozess stockt oder wird abgebrochen. Das „O“ von OKRs steht für „Objectives“ (=Ziele; „WARUM machen wir das?“) und das „KR“ für „Key Results“ (=Ergebniskriterien; „WIE erreichen wir das Ziel?“). Um diese Ziele und Ergebnisse machbar und realistisch zu halten, darf es maximal 5 Objectives und 4 Key Results geben. Weniger ist hier oftmals mehr: Es reichen daher oft 3 Objectives mit z. B. maximal 3 Key Results pro Objective (Abb. 10.1). Die Ziele müssen immer auf die Strategie einzahlen und sollen sowohl top-down (von der GF bzw. dem Vorstand) als auch bottom-up (vom Mitarbeiter oder Team) definiert werden. Dabei hat sich die 40–60 Regel als sinnvoller Mix etabliert, also: 40 % der Ziele kommen aus dem Management und 60 % der Ziele stammen aus der operativen Ebene. Das fördert bei allen Mitarbeitern ungemein die Verantwortlichkeit und emotionale Verbundenheit für die Ziele bzw. Objectives.

IT-Zielbild / Vision OKRs

Objective Objectives sind das WAS  Qualitative Ziele  Motivierend und als Vision formuliert  Das Ergebnis ist ein klarer Mehrwert für die IT-Organisation

Abb. 10.1  OKR: eine Übersicht

Key Result Key Results sind das WIE  Quantitative Ziele  Sind SMART formuliert  Sind Zwischenergebnisse, die den Erfolg der Objectives zeigen

10.2  Vorgehensweise bei der Erstellung von OKR für die IT

185

10.2 Vorgehensweise bei der Erstellung von OKRs für die IT Diese Findung und Definition der Ziele bzw. Objectives findet quartalsweise, also alle 3 Monate von Neuem statt. Daneben haben sich 3 wesentliche Meetings zur effektiven Führung von OKRs als sinnvoll herauskristallisiert: • Weeklies: Das sind wöchentliche Meetings, bei denen alle Beteiligten die erzielten Fortschritte mit Blick auf die Zielerreichung besprechen und die Maßnahmenplanung den Erfordernissen entsprechend anpassen. • Reviews: Hier werden die Objectives, die Key Results sowie aufgetretene Hindernisse miteinander diskutiert. Es gibt dabei generell immer einen Backlog sowie eine Liste von „Dingen, die wir nicht tun!“, die in diesem Review immer zur Hilfe genommen werden. • Retros: In diesem Meeting wird der OKRs-Prozess als solcher von allen Beteiligten unter die Lupe genommen, mit dem Ziel Rückschlüsse auf künftige Verbesserungsmöglichkeiten zu ziehen. Was ist bei der Definition der OKRs wichtig? Bei den Objectives müssen folgende Dinge eingehalten werden: • Objectives müssen die Frage nach dem „WARUM“ beantworten und nicht das „WAS“. • Ein Objective muss so formuliert sein, dass es einen Zustand in der Zukunft beschreibt. • Objectives sind qualitativer Natur, d. h. keine Zahlen oder Prozentwerte, sondern der zu erreichende Nutzen und Mehrwert. • Objectives müssen immer ambitioniert sein und sollen sich im Idealfall unbequem anfühlen und herausfordernd sein. Bei den Key-Results sind folgende Dinge zu beachten: • Die Key-Results als Ergebniskriterien beschreiben das „WIE“, z. B. mit dem Satzgefüge „… in dem …“ • Key Results sind immer messbar, d. h. ZDF verwenden (Zahlen, Daten, Fakten) • Relevanz ist wichtig: Trägt mein Key Result zum Objective bei im Sinne von „Welche Kernergebnisse sorgen wirklich dafür, dass das Ziel (Objective) eintritt?“ Ein kleines Beispiel für OKRs: Vision: „Wir bauen Autos, in denen niemand mehr ums Leben kommt!“

186

10  Führung der IT über Ziele? – OKR statt Management by Objectives (MbO)

Strategie im Sinne eines strategischen Zielbildes: „Durch die modernste Software- und Forecasting-Technik können unsere Autos alle Verkehrshindernisse voraussehen, diese richtig einschätzen und damit sehr früh reagieren und Unfälle vermeiden“. Auf dieser Langfriststrategie werden jetzt die ersten OKRs auf 3-Monats-Basis definiert, die sogenannte 1. OKRs-Periode: Objective: „Es ist eine erste Roadmap und Konzeptionsentwürfe für die Entwicklung der benötigten Software- und Forecasting-Technik entstanden“. Key Result: „Durch Research wurden die modernsten 10 KI-Softwaretools in Bezug auf Verkehrsanalytik ermittelt“. Key Result: „Validierung von 5 aktuellen Radar- und Sensormodulen im Sinne der Eignung für die Vision“. Key Result: „Es sind 5 Ideen entstanden für die Neugestaltung des Autos im Sinne der Vision“. Kaskadierung der OKRs auf die Bereiche (hier beispielhaft 2 Bereiche): Objective für die IT-Abteilung: „Um die Strategie zu erreichen, baut die IT KI-Kompetenz und Machine-Learning-Know-how auf“. Key Result: „Es ist eine Skill-Matrix für alle Mitarbeiter der IT entstanden zur Analyse der KI-Kenntnisse inkl. Fit-/Gap-Analyse“. Key Result: „Es sind 7 Unternehmen am Markt identifiziert worden, die beim Aufbau von KI-Know-how helfen bzw. KI-Software besitzen, die intern adaptiert werden kann“. Objective für den Bereich Technische Entwicklung (TE): „Suche nach einer Radar-­Lösung am Markt, die den Anforderungen der Strategie gerecht wird“. Key Result: Die Anforderungen an ein hochpräzises Radar sind zu 80 % detailliert spezifiziert. Alte Welt

Neue Welt

Ziele

OKRs

Budget

Verschwendung vermeiden

Plan

Skalieren

Effizienz

Fail early -Learn fast

Abb. 10.2  Alte Welt versus neue Welt (Ziele vs. OKR)

10.2  Vorgehensweise bei der Erstellung von OKR für die IT

187

Key Result: Es wurden 5 Unternehmen identifiziert, die sich auf die hochpräzise Radarentwicklung spezialisiert haben. Neben diesem Beispiel dient die Abb. 10.2 noch einmal dazu die alte mit der neuen Welt zu vergleichen. Neben dem Ersetzen von Zielen durch die OKRs, wie in diesem Beispiel deutlich geworden, sind es vor allem 3 Dinge, die anders und neu sind: • Anstatt über Budgets zu planen, geht es darum, Verschwendung zu vermeiden • Anstatt den Plan in den Vordergrund zu stellen und zu versuchen alles minutiös vorauszuplanen, geht es bei der OKRs-Denke um Skalierung. • Anstatt weiter an der Effizienzschraube zu drehen, geht es eher um das Prinzip „learn fast – fail early“. Scheitern bei neuen Lernerfahrungen ist erlaubt und alles ist denkbar.

Führung und Teambildung: Die 5 Phasen nach Tuckmann

11

Zusammenfassung

Die Entwicklung eines Teams ist eine der wesentlichen Aufgaben des CIOs. Tuckman hat herausgefunden, dass eine solche Teamentwicklung immer nach ähnlichen Mustern und Vorgehensweisen abläuft. Das ist eine große Hilfe für IT-Manager, um den Teamentwicklungsprozess bewusst und aktiv zu steuern, Hier sind die 5 Phasen der Teambildung ausführlich dargestellt.

Für IT-Führungskräfte und insbesondere auch IT-Projektleiter spielt die Teambildung und -entwicklung eine große Rolle. Sie entscheidet über den tatsächlichen Erfolg eines Projektes. Die Führung von IT-Spezialisten als sogenannte Wissensarbeiter wurde schon in einem vorherigen Artikel eingehend beleuchtet. Hier geht es nunmehr um die Teambildung in IT-Projekten oder auch in neu gebildeten IT-Abteilungen. Spannenderweise erfolgt eine solche Teambildung immer nach relativ ähnlichen Mustern, wie der amerikanische Psychologe Bruce Tuckman schon Mitte der 1960er-Jahre herausgefunden hat. Die nach ihm genannten „5 Phasen der Teambildung“ zeigen dies sehr deutlich und geben damit allen Team- und Projektleitern einen sehr hilfreichen Leitfaden an die Hand. Ähnlich der Change- oder Veränderungskurve zeigen die 5 Phasen sehr genau, wo sich das Team in der Entwicklung gerade befindet und was nötig ist, damit die Entwicklung weiter voranschreitet. Im Folgenden werden die 5 Phasen nach Tuckman wie in Abb. 11.1 beschrieben und eine Leistungseinschätzung des Teams sowie die möglichen oder notwendigen Handlungen der Führungskraft oder des Teamleiters dargestellt:

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 V. Johanning, Organisation und Führung der IT, https://doi.org/10.1007/978-3-658-12008-5_11

189

11  Führung und Teambildung: Die 5 Phasen nach Tuckmann

Leistungsgrad des Teams

190

 - PERFORMING - FORMING - NORMING

 - ADJOURNING

- STORMING

Zeit

Abb. 11.1  Die 5 Phasen nach Tuckman

1. – FORMING (die Orientierung- und Findungsphase) Bei einem IT-Projekt startet diese Phase mit dem offiziellen Kick-off des Projektes. Alle Projektmitglieder treffen sich und die sogenannte Orientierungs- und Findungsphase („forming“) beginnt. Die einzelnen Projekt- oder Teammitglieder lernen sich kennen und versuchen ein erstes Gruppengefühl aufzubauen. Dieses Kennenlernen birgt Unsicherheiten und daher ist die Stimmung in dieser Phase von vorsichtiger Zurückhaltung geprägt. Es herrscht noch Unklarheit über die Rollen und Positionen der einzelnen Teammitglieder. Um diese Unklarheit aufzulösen, wird beispielsweise geprüft, wie man sich in dieser Gruppe verhalten soll oder darf. Jeder versucht seine eigene Rolle im Team zu finden. Auf der anderen Seite ist die Motivation in dieser 1. Phase bei manchem Teammitgliedern noch relativ hoch, denn man ist gespannt und freut sich über die neue Aufgabe in der Gruppe. Wichtig ist jetzt, dass grundlegende Strukturen und Regeln gemeinsam gefunden und formuliert werden. Kennzeichen: Diese Phase ist oft von einem eher formellen und vorsichtigen „Abtasten“ gekennzeichnet. Leistung des Teams: Noch nicht sehr hoch, weil Ziele und Regeln noch nicht klar sind und die eigene Findung und Platzierung im Team gefunden werden muss und daher im Vordergrund steht. Aufgabe der Teamleitung • Orientierung und Rahmen geben: gemeinsame Regeln vereinbaren. • Für ein angenehmes Klima sorgen, sodass sich jeder Willkommen fühlt. • Den Prozess des Kennenlernens der Teammitglieder untereinander fördern. • Jedem Einzelnen die Möglichkeit bieten, seinen eigenen Platz im Team zu finden. • Vertrauen innerhalb des Teams aufbauen. • Aktive Steuerung des Teams.

11  Führung und Teambildung: Die 5 Phasen nach Tuckmann

191

2. – STORMING (die Konfliktphase) Die 2. Phase ist als Konfliktphase oder auch „Nahkampfphase“ definiert und wird nach Tuckman „Storming“ genannt. Nach dem vorsichtigen Abtasten und Kennenlernen in der ersten Phase, kommen jetzt die ersten Konflikte zutage. Typische Konfliktsituationen drehen sich dabei häufig um Machtverteilung, Prioritäten- und Zielsetzungen. Dabei lassen sich Problemsituationen 2 wesentlichen Arten von Konflikten zuordnen, den Aufgabenund den Rollenkonflikten. Bei den Aufgabenkonflikten geht es darum, dass ein Teammitglied seine Aufgabe nicht so erledigt oder bewältigen kann, wie es einzelne Gruppenmitglieder erwarten. Dies führt schnell zu sehr emotionalen Konflikten. Neben Aufgabenkonflikten gibt es in der Stormingphase auch Rollenkonflikte. Es kann sich beispielsweise herausstellen, dass Vorstellungen einzelner Teammitglieder unvereinbar mit der Realität sind. An dieser Stelle finden erste Versuche statt, das eigene Revier abzustecken. Dabei kann das Aufeinanderstoßen dominanter Charaktere den gesamten Arbeitsprozess eines Teams beeinflussen. Kennzeichen dieser Phase: Aus Sicht der Führung ist diese 2. Phase schwierig und zuweilen unangenehm, aber auch die wichtigste Phase. Denn wenn die vorhandenen Konflikte in dieser Phase richtig bearbeitet werden, wird das Team später gute Ergebnisse erreichen können. Leistung des Teams: nimmt deutlich ab und sinkt auf einen Tiefpunkt. Aufgabe der Teamleitung • Konflikte innerhalb der Gruppe nicht unterbinden, sondern zulassen • Wege der Konfliktbearbeitung vorschlagen und dabei jeden zu Wort kommen lassen • Hier haben Teamleiter zum einen die Rolle des Schlichters, indem sie Konfliktpotenzial entschärfen, sowie die Rolle des Antreibers, indem sie konkrete Ziele vorgeben und den Fokus des Teams auf diese lenken • Es gilt, die Basis für eine erfolgreiche Zusammenarbeit des Teams zu schaffen. Dies wird möglich, sobald die einzelnen Teammitglieder ihre Rollen und Positionen gefunden haben • Aktive Führung mit kühlem Kopf und viel Einfühlungsvermögen

3. – NORMING (die Regelungsphase) Man erkennt die Phase 3 daran, dass die Konflikte aus Phase 2 beigelegt werden und ein Miteinander entsteht, sodass sich die Teammitglieder mehr am Team orientieren als an sich selbst. Es entstehen neue Regeln der Zusammenarbeit und das ist auch die prägende Überschrift beim Norming: Regelungsphase. Idealerweise entsteht ein gemeinsames Ziel, das die Teilziele der einzelnen Personen aufnimmt. Rollen und Verhältnisse der einzelnen Teammitglieder kristallisieren sich heraus und die Kooperation wird immer enger. Dadurch kann sich das Team auch besser den eigentlichen Aufgaben widmen und Leistung erbringen.

192

11  Führung und Teambildung: Die 5 Phasen nach Tuckmann

Das „Wir“-Gefühl nimmt stark zu. Das führt meist auch zu einer deutlich gesteigerten Motivation, weil jeder seinen Teil zum größeren Ganzen beitragen will und jetzt auch genau weiß, was seine Aufgabe ist. Kennzeichen dieser Phase: Die Kommunikation des Teams ist zu diesem Zeitpunkt zunehmend aufgabenorientiert und weniger beziehungsorientiert. Es gibt gemeinsame Regeln über die Zusammenarbeit. Leistung des Teams: zu Anfang noch niedrig, nimmt aber deutlich zu. Aufgabe der Teamleitung • Moderationsfunktion einnehmen • Verbindendes betonen • Das Team bei der Einigung auf Regeln des Zusammenlebens beraten • Auf Einhaltung der Ziele achten

4. – PERFORMING (die Leistungsphase) Die 4. Phase ist die sogenannte Leistungsphase (Performing nach Tuckman) und sie macht ihrem Namen alle Ehre: Denn jetzt ist das Team auf der höchsten Leistungsstufe angekommen. Dies ist nur möglich geworden durch die konstruktiven Auseinandersetzungen in den beiden vorhergehenden Phasen. Denn man ist jetzt zu einem echten Team geworden, in dem füreinander gearbeitet wird und man sich gegenseitig unterstützt. Der Umgang im Team ist dementsprechend von gegenseitiger Akzeptanz, von Respekt und Wertschätzung geprägt. Unterschiede zwischen den Teammitgliedern werden nicht mehr für Konflikte genutzt, sondern aktiv für die optimierte Umsetzung von Zielen verwendet. Denn jetzt gilt nicht mehr die Leistung des Einzelnen, sondern das Erreichen von Gruppenzielen. Kennzeichen dieser Phase: In dieser Phase sind die Ergebnisse des Teams mehr als die Summe ihrer Einzelteile. Leistung des Teams: nimmt stark zu und pendelt sich auf einer hohen Ebene ein. Aufgabe der Teamleitung • Führung des Teams eher zurückhalten, Fokussierung eher auf Stakeholder außerhalb des Teams und dessen Repräsentation in Richtung Geschäftsleitung • Förderung einzelner Teammitglieder (falls nötig) • Wiederholte Reflektion und Prüfung der Teamziele • Weiterhin Vertrauen in das Team setzen

5. – ADJOURNING (die Auflösungsphase) Insbesondere bei Projekten ist diese letzte Phase nach Tuckman sehr wichtig. Denn jedes Projekt ist ein zeitlich begrenztes Vorhaben mit einem klaren Ende. Dieses macht sich daran fest, dass die Projektziele erreicht sind. Die Projektmitglieder gehen zurück in die

11  Führung und Teambildung: Die 5 Phasen nach Tuckmann

193

Linie und zu ihrem Tagesgeschäft. Aber auch Teams existieren nicht ewig und auch hier ist diese Phase sehr wichtig, um Teamziele abzuschließen oder zumindest professionell übergabefähig zu machen. Ein wichtiges Merkmal dieser Auflösungsphase ist, dass es oftmals schon einige Zeit vor der Trennung des Teams zu einer Reduzierung der Leistungsfähigkeit kommen kann. Unklarheit über die weiteren Aufgaben nach dem Projekt, manche möchten nicht zurück in ihr altes Tagesgeschäft. Dies sorgt für Ungewissheit, die Motivation im Team oder Projekt sinkt und die Gefahr der Ablenkung von den eigentlichen Zielen ist relativ groß. Hier ist viel Fingerspitzengefühl und vor allem Führung gefragt. Wenn dann aber das Ziel erreicht ist, gilt es, sich von der erledigten Aufgabe zu trennen. Zum Prozess des Abschieds gehört selbstverständlich auch der Stolz auf die vom Team gelöste Herausforderung oder Aufgabe. Es gilt, sich gebührend zu verabschieden und das Projekt adäquat zu beenden. Kennzeichen dieser Phase: Ungewissheit wie es mit dem einzelnen Teammitglied weitergeht, kann zu Motivationsabfällen und damit zu einer Gefahr für die Zielerreichung werden. Viel Führungsgeschick ist hier gefragt. Leistung des Teams: nimmt ab. Aufgabe der Teamleitung • Jetzt wieder aktive Führung und Steuerung übernehmen, damit die Ziele wirklich erreicht werden und ein krönender Abschluss erfolgen kann • Feedback und Reflektion für die Teammitglieder anbieten. Potenziale und Zukunftsperspektiven erkennen und mit Linienvorgesetzten besprechen • Gestaltung des Abschieds vom Team und jedem Einzelnen Zum Abschluss ist es wichtig zu wissen, dass die Phasen auch gleichzeitig und wiederholt auftreten können. So ist es beispielsweise möglich, dass sich Teile eines Teams bereits aus früheren Projekten kennen und deshalb relativ schnell bei der Performingphase ankommen. Andere Teammitglieder befinden sich aber noch in der Formingphase. Gleiches kann passieren, wenn ein neues Mitglied in ein bereits bestehendes Team aufgenommen wird oder auch wenn ein wichtiges Mitglied ausscheidet. Ist einer Führungskraft diese Tatsache bewusst, kann er/sie in den verschiedenen möglichen „Phasen-Kombinationen“ entsprechend reagieren. Wenn z. B. ein Teammitglied – im Gegensatz zum restlichen Team – noch nicht in einer bestimmten Phase angekommen ist, kann es hilfreicher sein, dieser Person auf die nächste Ebene zu helfen, anstatt Druck auszuüben. Fazit: Durch die 5 Phasen nach Tuckman wird sehr klar, dass man als Führungskraft für ein Team oder Projekt sehr unterschiedliche Aufgaben wahrnehmen muss, um die optimale Performance zu erreichen. Die Phasen dienen dabei als Spiegel und zeigen deutlich, wo man sich gerade befindet und wie in dieser Phase zu handeln ist. Es stellt sich damit als ein sehr hilfreiches Führungswerkzeug heraus, welches leicht anwendbar und trotzdem hocheffektiv ist.

Wichtige Kulturaspekte einer IT-Organisation

12

Zusammenfassung

Führung und Kultur gehören zusammen. Aber wie entwickelt man eine „gute“ Kultur in der IT? Was können Hilfsmittel, Strukturen und systemische Merkmale sein, die dem CIO helfen zu verstehen, wo die IT kulturell steht und wie man die Entwicklung einer Kultur beeinflussen kann? Dazu hilft Ihnen dieses Kapitel.

12.1 Kultur und IT Neben den harten Fakten einer IT-Organisation, wie z. B. den IT-Prozessen, der Aufbauund Ablauforganisation, gibt es viele weiche Faktoren. Diese werden allgemein als Kultur bezeichnet. Dazu zählt z. B. die Art und Weise, wie in der IT-Organisation gedacht, entschieden und gehandelt wird, wie die IT-Organisation „atmet“. Es geht um die Fragen: „Welche Muster und Verhaltensweisen werden in der IT-Organisation gelebt? Was sind unsere Glaubenssätze und an was orientieren wir uns – auch unbewusst – bei wichtigen Entscheidungen?“ Der bekannte Management-Mäzen Peter Drucker hat es sehr schön auf den Punkt gebracht: „Culture eats Strategy for Breakfast!“. Dies meint nicht, dass Strategie nicht wichtig wäre. Aber die scheinbar unsichtbare und schwer zu greifende Kultur hat einen großen Einfluss auf den Erfolg eines Unternehmens und damit auch einer IT-Organisation. Gerade wenn es um Veränderungen geht, ist die kulturelle Komponente entscheidend. Man könnte auch sagen: Die Strategie liefert die Handlungsanweisungen, die Umsetzung und das „tatsächliche Leben“ dieser Strategie ist ein Veränderungsprozess. Und dieser Prozess der Veränderung hat mit Menschen und deren Werte, Normen, Verhaltensweisen und Glaubenssätzen zu tun. Und genau diese Dinge beschreibt die Kultur. Wichtig ist

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 V. Johanning, Organisation und Führung der IT, https://doi.org/10.1007/978-3-658-12008-5_12

195

196

12  Wichtige Kulturaspekte einer IT-Organisation

hierbei zu verstehen, dass es keine „gute“ oder „schlechte“ Kultur gibt. Jede Kultur ist auf ihre Art für die Mitarbeiter sinnvoll und sinnstiftend. Um dieses oft etwas unkonkrete und nichtgreifbare Thema der Kultur anfassbar zu machen, differenziert man verschiedenen Ebenen der Kultur. Edgar Schein ist ein Organisationspsychologe aus den USA und gilt als einer der Pioniere auf dem Gebiet der Unternehmenskultur. Er hat zum besseren Verständnis des Kulturbegriffs 3 Ebenen entwickelt, die in Abb. 12.1 dargestellt sind. Nach Schein sind die 3 Ebenen der Kultur wie folgt zu beschreiben (angelehnt an [1]): • Ebene 1: An der Oberfläche liegen die sichtbaren Verhaltensweisen, wie z. B. die gemeinsame Sprache, die Geschichte und Rituale. Beispiele dafür können sein: Wie unterhalten sich IT-Mitarbeiter untereinander? Welche besonderen Poster und Logos gibt es in den Büroräumen? Was sind die beliebtesten Software-Tools und was geht gar nicht. • Ebene 2: Unter der Ebene 1 liegen die zu den Verhaltensweisen gehörenden Normen und Werte. Das kann sich z. B. im Umgang miteinander in der IT oder auch in Richtung der Fachbereiche spiegeln. Welche Werte sind uns wichtig? Sind es z. B. Ehrlichkeit? Sind wir eher technikverliebt oder sehen wir die Welt eher konservativ oder sehr zukunftsoptimistisch? • Ebene 3: Auf der tiefsten Ebene sind die Dinge, die als selbstverständlich angenommen werden für die Art und Weise, wie man auf die Umwelt reagiert (die sogenannten Grundannahmen). Diese Grundannahmen („basic assumptions“) werden nicht hinterfragt oder diskutiert. Sie sind so tief im Denken verwurzelt, dass sie von Mitgliedern der Organisation nicht bewusst wahrgenommen. Dazu gehören z.  B. auch die Glau-

Abb. 12.1  Die 3 Ebenen von Kultur nach Edgar Schein

12.2  Vertrauen ist die Basis für eine gesunde Unternehmenskultur in der IT

197

benssätze und tiefen Überzeugungen (z. B.: „SAP ist das beste ERP und alles andere macht überhaupt keinen Sinn!“). Die Einführung und Nutzung von agilen Methoden, wie z. B. SCRUM in IT-Projekten ist ein typisches Beispiel für einen größeren Veränderungsprozess in der IT. Für den Erfolg des Einsatzes von SCRUM ist nicht die richtige Anwendung dieser Methode maßgebend, sondern der Umgang untereinander und das Akzeptieren und Verstehen des „Warum nutzen wir das?“. Man ist auf einer ganz anderen Ebene erfolgreich, nämlich der von Kultur. Bestehende Glaubenssätze aus den Zeiten des Wasserfallmodells können z. B. sein: „Ohne konkrete Planung des gesamten Themas, kann das nichts werden!“. Solche Glaubenssätze können schnell dazu führen, dass man die agilen Methoden von vornherein ablehnt. Wenn man sie aufgrund von Vorgaben durch den Vorgesetzten trotzdem einsetzen muss, wird es nicht erfolgreich sein. Kultur ist somit der wesentliche Einflussfaktor und inhaltliche „Gegenstand“, wenn es um Veränderungen in IT-Organisationen geht. Im Folgenden werden 3 wesentliche Themen ausführlicher betrachtet, um eine für die anstehenden Aufgaben erfolgreiche Kultur in der IT zu etablieren: • Das Fundament für eine erfolgreiche IT-Kultur ist das Thema Vertrauen. • Wie kann die systemische Sichtweise helfen, Kultur noch besser zu verstehen? • Was ist das Besondere an einer Kultur im digitalen Zeitalter?

12.2 V  ertrauen ist die Basis für eine gesunde Unternehmenskultur in der IT Vertrauen ist nicht der einzige Baustein eines erfolgreichen Kulturfundaments, aber doch ein wesentlicher. Daher soll mit Blick auf Führung in der IT die Frage aufgeworfen werden: „Wie schafft man Vertrauen in einer IT-Organisation und was bedeutet das für den Führungsalltag?“ Viele IT-Manager haben die harten Fakten des Managements gelernt und wenden diese lehrbuchmäßig in ihrer IT-Abteilung an und machen theoretisch alles richtig. Trotzdem gelingen große Einführungsprojekte immer nur sehr zäh und mit viel Kampf und Zeiteinsatz. Woran liegt das und was fehlt? Wenn man dieser Frage auf den Grund geht, kommt oft das Thema Vertrauen auf die Tagesordnung. Denn wenn die IT-Führungskräfte das Vertrauen ihrer Mitarbeiter haben und auf dieser Basis ein gutes Klima in der Mannschaft herrscht und Arbeit so richtig Lust macht, dann gelingen Dinge viel einfacher. Große Projekte sind immer Transformationen, also nicht Änderungen auf technischer Ebene, sondern vor allem auf menschlicher. Durch Automatisierungen entstehen neue Prozesse und Arbeitsabläufe und diese haben enormen Einfluss auf die Menschen: Tätigkeiten ändern sich oder fallen sogar ganz weg. Gewohn-

198

12  Wichtige Kulturaspekte einer IT-Organisation

heiten müssen sich ändern und alte Glaubenssätze sind auf einmal nicht mehr richtig. Das rüttelt am Innersten des Menschen. Nur wenn in solchen Situationen ein enges Vertrauensverhältnis besteht und man sich gegenseitig traut, können solche Phasen gemeinsam und erfolgreich gestaltet werden. Malik hat dazu ein paar Regeln für Führungskräfte aufgestellt, die auch für IT-Manager sehr wertvoll sind, wenn es darum geht, Vertrauen aufzubauen [2]: • Fehler der Mitarbeiter sind auch Fehler des Chefs • Fehler des Chefs sind Fehler des Chefs • Erfolge der Mitarbeiter gehören den Mitarbeitern: Als Chef schmückt man sich nicht mit fremden Federn • Erfolge des Chefs – falls er allein solche haben sollte – kann er für sich beanspruchen: Gute Manager allerdings sagen auch dann noch: „Wir“ haben es gemeinsam erreicht Abschließend gibt es 4 Regeln für IT-Führungskräfte, um Vertrauen aufzubauen und zu schaffen (angelehnt an Mailk [2]): 1 . Wer Vertrauen schaffen will, muss zuhören 2. Wer an Vertrauen interessiert ist, muss echt sein 3. Wer Vertrauen schaffen will, muss charakterlich integer sein 4. Wer Vertrauen schaffen will, muss sich von Intriganten trennen

12.3 D  ie systemische Sichtweise auf IT-Organisationen: Innovation durch IT und Umgang mit Unsicherheit Das jetzige und kommende Marktumfeld wird oft mit dem Kürzel VUKA umrissen. Das steht für Volatilität, Ungewissheit, Komplexität und Ambiguität (englisch VUCA: „volatility, uncertainty, complexity, ambiguity“). In einer solchen Welt von hoher Dynamik, Komplexität und Ungewissheit ist das traditionelle, eher mechanistische Bild der IT mit langfristiger Planung, standardisierten Vorgehensmodellen und starren IT-Systemen nicht mehr lebensfähig. Der Wandel vollzieht sich dabei sowohl auf der Ebene der Technologie als auch beim Menschen. Die Tab. 12.1 zeigt den Unterschied zwischen dem Denken in einer traditionellen, mechanistisch geprägten Welt und in einem systemischen Weltbild, welches der heutigen Wirklichkeit näher kommt bzw. diese besser abbildet. Was bedeutet das jetzt für die IT und die Führung einer IT-Organisation? Beispielhaft sei die neue Denke des DevOps-Ansatzes genommen. Folgt man nun DevOps-Vordenker und „DevOps-Cookbook“-Autor Gene Kim, ergeben sich 3 Wege zum Ziel DevOps. Entweder betrachten und optimieren Unternehmen die IT-Wertschöpfungskette von den Anforderungen bis zum IT-Betrieb. Oder es gibt Feedback-­Schleifen auf allen Ebenen des IT-Systems – nicht nur zwischen Entwicklern

12.4  Die digitale Kultur als Fundament für eine moderne IT-Organisation

199

Tab. 12.1  Mechanistisches versus systemisches Weltbild Mechanistisches Weltbild Objektivität, eine Wahrheit, unveränderliche Gesetze Richtig – falsch, schuldig – unschuldig (Fremd-)Steuerung Lineare Kausalketten Methoden: Instruktion, Anordnung, Befehl, Lernen durch Versuch und Irrtum Rollen: Macher, Führer und Geführte, Manipulation Formale Logik, Widerspruchsfreiheit, Ausschluss Harte Fakten, rationale Beziehungen

Systemisches Weltbild Wirklichkeitskonstruktion, viele „Wahrheiten“, Thesen Kontextabhängigkeit, Nützlichkeit, Anschlussfähigkeit Selbststeuerung, Selbstorganisation vielfältige Wechselwirkungen, Feedback-Schleifen Methoden: zuhören, fragen, Dialog, Diskussion, Reflexion, Lernen des Lernens Rollen: Impulsgeber, Gärtner, Befähiger, Entwicklungshelfer, Coach Integration von Widersprüchen, Einbeziehung Integration von harten und weichen Faktoren (Emotionen, Intuitionen, Kommunikationsprozesse)

und Auftraggebern. Bei der 3. Implementierungsstrategie setzen die Beteiligten auf die kontinuierliche Verbesserung, die sie über kontrollierte Experimente erreichen. In der Praxis hat sich bewährt, in einem IT-Betriebs-Team mit DevOps zu starten und die dort automatisierten Prozesse als Basis für die Entwicklung zu nehmen. Der umgekehrte Ansatz, in der Entwicklung anzufangen, kann aber genauso funktionieren. Für andere Einsteiger erweist sich das Installieren eines Pilotteams, welches DevOps ausprobiert, als der beste Türöffner in die agile IT-Welt. Firmen gehen das größtmögliche Risiko ein, wenn sie das neue IT-Wertesystem sofort für die gesamte Organisation einführen. In dem Fall ist es umso wichtiger, die eigenen Fachkräfte zu motivieren, zu trainieren und zu schulen.

12.4 D  ie digitale Kultur als Fundament für eine moderne IT-­Organisation Ein wesentliches Element zur digitalen Transformation von Unternehmen ist die Kultur oder konkret: die Veränderung der Unternehmenskultur. In diesem Zusammenhang spricht man von der Schaffung einer digitalen Kultur. Eine Kultur als solche ist zunächst ein sehr schwammiges Gebilde. Es zählt zu den sogenannten immateriellen Wirtschaftsgütern, die oftmals schwer zu greifen, aber so wichtiger sind für die Wandlung des Unternehmens hin zu mehr Zufriedenheit und Motivation der Mitarbeiter. Auch zu größerer Kundenzufriedenheit und Kundenbindung leistet dieser Kulturwandel einen wesentlichen Beitrag. Was verbirgt sich aber konkret hinter diesem Begriff und vor allem: Was können die Merkmale einer solchen digitalen Kultur sein?

200

12  Wichtige Kulturaspekte einer IT-Organisation

• Eine neue Art der Zusammenarbeit durch autonome Arbeitsbedingungen und Kollaboration • Offenheit und Transparenz • Agilität und Flexibilität/Entrepreneurship • Kundenorientierung (Customer Centricity) • Lernen und Innovationsgeist • Datengetriebener Ansatz, auf dessen Basis Entscheidungen getroffen werden Auf dem Weg zu solch einer digitalen Kultur ist eines sehr wichtig: Die Technologie ist nur Enabler, also Ermöglicher einer solchen Kultur! Wichtig im Veränderungsprozess hin zu einer digitalen Kultur ist der Mensch. Es muss eine Vertrauenskultur erschaffen w ­ erden, denn Vertrauen und Zutrauen sowie Authentizität sind der Schlüssel für den erfolgreichen Weg durch die Transformation. Ein großes Wort dieser Zeit des Wandels ist die „Agilität“. Im Kontext der digitalen Kultur spielt Agilität oder eine agile Organisation eine große Rolle, weil sie den Nukleus des Arbeitens widerspiegelt. Nicht mehr sture Vorgaben (Command & Control) sowie prozessgetreue und hochstrukturierte Arbeitsvorgänge aus dem Ford-Taylorismus der Bandarbeit sind heute gefordert, sondern agile Arbeitsweisen. Was sind die Merkmale von Organisationen, die erfolgreich agiles Arbeiten eingeführt haben? • • • •

Es gibt eine Kultur der Innovation und des ständigen Lernens Flache Hierarchien prägen die Zusammenarbeit Veränderungen am Markt können frühzeitig wahrgenommen werden Die Bedürfnisse sich ständig wechselnder Märkte sowie deren Kunden werden fortwährend adaptiert • Chancen im Markt werden schneller erkannt und damit Marktlücken effizient besetzt Wie kann das im Unternehmensalltag umgesetzt werden? Was ist nötig für die Transformation? Hinderlich ist eine mögliche Kluft zwischen Mitarbeitern und Führungskräften, z. B. in der Form, dass Führungskräfte noch im alten Command & Control-Modus führen, die Mitarbeiter aber schon auf einer anderen Ebene angekommen sind und sich durch diesen Führungsstil nicht ernst genommen fühlen. Das führt konsequenterweise dann auch zu Minderleistungen. Daher ist es wichtig zu erkennen, dass eine Kulturveränderung bei Führung ansetzt. Offenheit, Transparenz und Authentizität sind nicht nur wichtig, sondern maßgebend. An 2. Stelle, direkt nach der Führung, kommt die digitale Vision (LINK). Zwei weitere Punkte sind flexible Arbeitszeitmodelle und das Motto: „Aus Fehlern lernen – der Fail-­Fast-­Ansatz“. Abschließend stehen die 4 Erfolgsfaktoren, welche die digitale Kultur zur Realität werden lassen:

Literatur

201

1. Führung: Verantwortlichkeiten für die Digitalisierung und den dazugehörigen Kulturwandel festlegen. 2. Digitale Vision: eine klare Digitalisierungsstrategie und -vision formulieren und ständig kommunizieren. 3. Vertrauen & Authentizität: Mitarbeitern Vertrauen und Zutrauen schenken und aktiv in den Veränderungsprozess einbinden. 4. Agilität und Change Leadership: eine Kultur des ständigen Lernens und der Innovation durch Change Leader eröffnen.

Literatur 1. Schein, Edgar: „Organizational Culture and Leadership“, San Francisco: Jossey-Bass in Emmanuel Ogbonna (abridged from E. Ogbonna, Managing organisational culture: fantasy or reality, Human Resource Management Journal, 3, 2 (1993), pp. 42–54 in Jon Billsberry (ed.) The Effective Manager, Open University, Milton Keynes 1997). 2. Malik, Fredmund: Führen Leisten Leben, 6. Auflage, Campus Verlag, 2006.

Resümee

13

Zusammenfassung

Nicht nur die technologische Perspektive der IT, sondern immer mehr die menschliche Seite der IT rückt in den Fokus. IT treibt den Wandel und muss mit großer Dynamik umgehen können. Das stellt hohe Anforderungen an die Führung der IT jenseits jeglicher Technik. Ganz neue Fähigkeiten und Kompetenzen sind gefragt. Das zu verdeutlichen ist der Sinn und Zweck dieses Buch und das Resümee soll dies noch einmal prägnant zusammenfassen und auf den Punkt bringen.

Von der historischen Entwicklung der IT-Abteilung mit Plan-Build-Run bis hin zu den aktuellen agilen Methoden und Formen der Selbstorganisation wurde die gesamte Spannbreite möglicher IT-Organisationen aufgezeigt. Was ist die richtige Rolle der IT im Unternehmen, wie muss sich der CIO dementsprechend aufstellen? Auch dies ist eines der zentralen Themen in diesen sich sehr dynamisch wandelnden Zeiten. Zum Abschluss wurden die relevanten Führungsinstrumenten für CIOs und IT-Manager aufgezeigt, die für eine erfolgreiche Transformation des Unternehmens im digitalen Zeitalter so wichtig sind. Damit ist ein Rundumschlag über alle für den CIO und die Geschäftsführung wichtigen Themen erfolgt. Was soll hängen bleiben. Aus Sicht des Autors sind 7 Merkmale für eine echte High-­ Performance-­IT-Organisation wichtig: 1. Klare Ergebnisorientierung und Fokus auf den Business-Impact bzw. die Wertgenerierung 2. Nicht vertikal in Hierarchien denken, sondern horizontal in der Wertschöpfung handeln 3. Innovationsfähigkeit und Gestaltungswille © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 V. Johanning, Organisation und Führung der IT, https://doi.org/10.1007/978-3-658-12008-5_13

203

204

13 Resümee

4 . CIO auf Boardlevel und klares Committment aus der Geschäftsführung 5. Skalierbare Architektur und Cyber Security 6. Die IT hat ein klares Zielbild/Vision 7. Change Leadership und Talentmanagement Daran anschließend sollen zum Abschluss 5 goldene Regeln für eine erfolgreiche IT-Organisation aufgestellt werden: Regel 1: So wenig Hierarchie wie möglich – Ablauforganisation ist „old school“ Regel 2: Agil und Wasserfall als bimodale Organisation – Vergessen Sie es! Alles ist agil! Regel 3: Jeder übernimmt Führung! Regel 4: Der Sinn und das Zielbild sind das Fundament einer erfolgreichen IT-Organisation Regel 5: Glaubwürdigkeit herstellen und Vertrauen schaffen Damit bleibt festzuhalten: Die IT ist für die Unternehmen zu einem der wesentlichen Treiber von Innovation und Wettbewerbsstärke geworden. Aus der reinen Technik- und Dienstleistermentalität erwächst eine Rolle des Gestalters und Innovators. Es muss der Weg von der traditionellen, hierarchisch geprägten IT-Organisation in die neue Welt der Agilität, Dynamik, Veränderung und von Sinn und Purpose gefunden und gegangen werden. Daher lautet das Motto für alle CIOs und IT-Leiter: Machen Sie sich auf den Weg und gehen Sie proaktiv voran, anstatt lange zu warten wie es andere machen.

Literatur

2. Agarwal R., Sambamurthy V.: „Principles and Models for organizing the IT-Function“, MIS Quarterly Executive, Vol. 1, No. 1, March 2002. 4. Beck, Kent et al.: „Manifest für agile Softwareentwicklung“, https://agilemanifesto.org/iso/de/ manifesto.html, abgerufen am 29.12.2019. 6. Brenner, Walter, Wulf Jochen, Winkler Till: „Organisationsgestaltung der Demand-IT“, http:// warhol.wiwi.hu-berlin.de/aigaion2/index.php/attachments/single/58, abgerufen am 14.04.2014. 8. Detecon: Wolter Bernd, Chiesa Marco, Reich Christian: IT-Organsiation 2015: Facelift oder Modellwechsel? (in Zusammenarbeit mit Bitkom), http://www.msm.uni-due.de/index. ­ php?id=3335&no_cache=1&tx_eduext_pi4%5BshowUid%5D=2227&tx_eduext_pi4%5BspecialCMD%5D=download&tx_eduext_pi4%5Bfilename%5D=Detecon_ITOrga_2015.pdf, abgerufen am: 12.08.2014, Präsentation der Detecon Consulting von 05/2011. 11. Fink, Franziska/Moeller, Michael: „Purpose Driven Organizations“, 1. Auflage, Schäffer Poeschel, 2018. 15. Heinevetter, Thomas: „IT-Organisation 2016: Faktor Mensch!“, eine Studie von Kienbaum unter Kooperation von BITKOM, http://www.partnering.org/fileadmin/Event/BPC/2012/Vortr%C3% A4ge/Studie%20IT%20Organisation%202016%20-%20Faktor%20Mensch_Thomas%20Heinevetter_Kienbaum.pdf, abgerufen am 28.05.2014. 16. Hierzer, Rupert: „Prozessoptimierung 4.0: Den digitalen Wandel als Chance nutzen“, 1. Auflage, Haufe, 2017. 18. Johanning, Volker: „IT-Strategie: Die IT für die digitale Transformation in der Industrie fit machen“, 2. Auflage, Springer, 2019. 20. Keese, Christoph: „Silicon Valley: Was aus dem mächtigsten Tal der Welt auf uns zukommt“, 4. Auflage, Knaus Verlag, 2014. 22. Königswieser, Roswita/Hillebrand, Martin: „Einführung in die systemische Organisationsberatung.“, 5. Auflage, Carl-Auer, 2015. 23. Krüger, W.: Organisation der Unternehmung, 3. Auflage, Verlag W. Kohlhammer, 1994. 25. Laloux, Frederic: „Reinventing Organizations: Ein Leitfaden zur Gestaltung sinnstiftender Formen der Zusammenarbeit“, 1. Auflage, Verlag Franz Vahlen, 2015. 27. Mohr, Günther: „Systemische Organisationsanalyse“, Verlag EHP, 2006. 28. Pfläging, Nils: Organisation für Komplexität, 1. Auflage, BoD – Books on Demand, 2013.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 V. Johanning, Organisation und Führung der IT, https://doi.org/10.1007/978-3-658-12008-5

205

206

Literatur

29. Raitner, Marcus: „Manifest für menschliche Führung: Sechs Thesen für neue Führung im Zeitalter der Digitalisierung“, 1. Auflage, independently published, 2019. 31. Schüller, Anne M./Steffen Alex T.: „Die ORBIT-Organisation“, 1. Auflage, GABAL, 2019. 34. Wikipedia: „TOGAF“, https://de.wikipedia.org/wiki/TOGAF, abgerufen am 12.02.2020. 36. Wunderer, Rolf: Führung und Zusammenarbeit, Eine unternehmerische Führungslehre, ­3. Auflage, Hermann Luchterhand Verlag, 2000.

Stichwortverzeichnis

A Ablauforganisation 4 agiles Vorgehen 88 Agilität 165, 200 Anforderung 161 Anforderungsmanagement 28, 56, 86, 110 Applikationsarchitekt 115 Aufbauorganisation 4, 13, 19 Aufgaben eines CIOs 145

D Demand-Management 86, 145, 152 Demand-Supply-Konzept 27 Demand-Supply-Organisationsmodell 28 DevOps 31–33, 117, 198 Dienstleister 136 Dienstleisterrolle 139 Digitalisierung 125, 127 Digital Lab 47 Dynamik 174, 198

B BizDevOps 33 Business-Impact 157 Business-Relationship-Manager 112 Business-Treiber 136

E Enabler 136, 144, 200 Ende-zu-Ende-Prozess 59 Enterprise-Architekt 115 Ergebnisorientierung 203

C CDO 151 Change-Manager 120 CIO 7, 10, 11, 13, 29, 35, 53, 73, 76, 84, 104, 108, 112, 127, 129, 131, 134, 138, 139, 143, 146, 148, 151, 157, 161, 166, 173, 179, 203 Cloud 129 CobiT 67 COBIT 68, 73 Commodity 13 Consumerization 128 Continuous Delivery 32 Continuous Integration 32 Cost Center 83

F Fachbereich 7, 129 Fachbereichen 26 Fremdbild 139 Führen 159 Führung 192, 198 agile 176, 178 Führungskraft 161, 162, 174 G Geschäftsführung 130, 133 Geschäftsmodell 51, 127, 135 digitales 47 Governancefunktion 12

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 V. Johanning, Organisation und Führung der IT, https://doi.org/10.1007/978-3-658-12008-5

207

208 I Incident-Management 107 Inhouse Consultant 110 Innovate-Design-Transform 25 Innovationsmanagement 152 Innovationstreiber 138, 173 IoT 128, 171 IT agile 34 bimodale 34 im internationalen Kontext 36 IT-Architekturmanagement 105 IT-Controlling 83 IT-Einkauf 109 IT-Experte 85 IT-Führungskraft 189 IT-Governance 67, 76, 109, 147 ITIL 71, 73, 159 IT-Kosten 27 IT-Leistungserbringung 25 IT-Leiter 176 IT-Management 65 dezentrales 36 zentrales 36 IT-Operations 108 IT-Organisation 125, 166, 178, 195, 197 klassische 21 linienzentrierte 38 projektzentrierte 38 IT-Portfolio 100 IT-Projekt 89 IT-Roadmap 76, 80, 168 IT-Security 128 IT-Service-Management 107, 118 IT-Strategie 76, 109 IT-Verantwortlicher 96 IT-Vision 81, 165, 167

K KANBAN 43 Key Result 186 Key-User 57 Kommunikation 192 Komplexität 174, 180, 198 Konfliktphase 191 Kosteneffizienz 131 Künstliche Intelligenz 128, 171 Kultur 195

Stichwortverzeichnis Kunde 65, 153 Kundenorientierung 131 L Leadership agile 149 Leadership Agility 127, 171 Lieferantenmanagement 86 M Make or Buy 147 Management by Objectives 172, 183 Marketing 81, 149 Marktanforderungen 151 Methode agile 54 Mitarbeiterförderung 162 O Objectives 185 OKR 183, 184 Organisationsaufbau 21 Organisationsform 17 P Partner 144 Pflichtenheft 128 Pitching Day 52 Plan-Build-Run 22 PMO 113 Portfolio 94 Portfoliomanagement 92 Portfolio-Manager 113 Portfolioprozess 97 PRINCE2 73 Problemmanagement 107 Product Backlog 41 Product Owner 39 Programm 94 Projektmanagement 89, 145 Projekt-Manager 113 Projektorganisation 37 Projektportfolio 102 Projektportfoliomanagement 56 Projektpriorisierung 100 Prozesse 135, 158

Stichwortverzeichnis Prozessexperte 57 Prozessorganisation 55, 61 Prozessreferenzmodell 69 Prozessverantwortlicher 57 Purpose 165 R Rolle 12, 57 Rolle der IT 125, 129, 135, 160 Rollenkonflikt 191 Rollenmodell 143 S SCRUM 39, 48, 88, 90, 106, 128, 197 Selbstbild 139 Selbstorganisation 45 Selbstverantwortung 175 Service-Management 72 Shared Service 27 Sinn 165 Softwareentwicklung 106 Source-Make-Deliver 24 SPRINT 40 Sprint Review 42 Stabsfunktion 108 Stakeholder 131 Stakeholderanalyse 131 Standard 148

209 Standardisierung 36 Strategie 19, 180 Support Strategy 107 Systemlandschaft 138, 157 T Teambildung 189 Ticketmanagement 57 Transformation digitale 199 Transparenz 175 V Veränderungsprozess 180 Verantwortlichkeit 137 Vision/Strategie 49 W Wandel 198 digitaler 180 Wasserfallmodell 87 Wertbeitrag 131 Wettbewerbsfähigkeit 143 Z Zielbild 166, 168