Zukunft
gestalten

Die IT-Strategie folgt der Unternehmensstrategie und macht Vorgaben über die zukünftige Entwicklung der Informationstechnik und IT-Infrastruktur eines Unternehmens. Idealerweise beinhaltet die IT-Strategie auch eine Roadmap, die in einem Planungshorizont von 2-5 Jahren konkrete Maßnahmen und Projekte aufsetzt.

Ziel dieses Hacks ist es, Sie darin zu unterstützen, die bestehende IT-Strategie zu überprüfen und zu aktualisieren oder eine neue IT-Strategie zu entwerfen.

• Auswertung vorhandener (IT-)Strategieunterlagen bzw. Unterlagen, aus denen die strategische Ausrichtung des Unternehmens hervorgeht.
• Analyse von Trends und Best Practices im Unternehmensumfeld
• Festlegung von Schwerpunkten für die zukünftige Unternehmensentwicklung
• Sukzessive Erarbeitung der dazu passenden IT-Strategie und daraus abgeleiteter Maßnahmen z.B. im Rahmen von Workshops.  Berücksichtigung insbesondere folgender Aspekte:
  • Anwendung und Infrastruktur
  • Mitarbeiter und Organisation
  • Services und Kundenorientierung
  • Innovation und Digitalisierung
  • Investition und Sourcing
  • Wirtschaftlichkeit und Effizienz
• Kommunikation der Ergebnisse an relevante Stakeholder
• Etablieren eines Prozesses zur iterative Wiederholung der IT-Strategieplanung in sinnvollen Abständen

• Unternehmensleitung
• IT-Führungskräfte
• IT-Architekten
• Ausgewählte Key-User, Vertreter Fachbereiche
• Betriebsrat

• Bestehende (IT-)Strategieunterlagen
• Anforderungen und strategische Entwicklungen
• Informationen zum Unternehmens-/ Marktumfeld

• Roadmap zur Erstellung bzw. Aktualisierung der IT-Strategie
• Mit Stakeholdern abgestimmte aktuelle IT-Strategie als Grundlage für die Weiterentwicklung der IT
• Roadmap mit Maßnahmen und Projekten zur Umsetzung

• Vermeiden Sie eine ballistische Flugbahn der IT-Strategie. Die Rakete startet mit viel Getöse und schafft es nicht in die Umlaufbahn. Bei Australien fällt die Rakete dann ins Wasser …
• Falls es keine formulierte Unternehmensstrategie gibt, sollten Sie nicht aufgeben. Machen Sie Annahmen.
• Eine IT-Strategie kann man niemals direkt top down aus der Unternehmensstrategie ableiten. Man muss die IT-Strategie gewissermaßen „von unten“ an die Unternehmensstrategie anpassen.
• Die IT ist eine „Maßkonfektion“. Bestehende Beispiele aus anderen Unternehmen können selten direkt verwendet werden.

Eine Enterprise Architecture (EA) beschreibt das Zusammenspiel von Business-Prozessen und IT im Unternehmen und stellt somit einen strategischen, konzeptionellen und organisatorischen Rahmen für die Ausgestaltung der IT-Landschaft zur Verfügung. Das EAM leistet damit einen Betrag zur Beherrschbarkeit der Komplexität, indem Transparenz und eine gemeinsame Abbildungssprache geschaffen werden.

Neben der Dokumentation der heutigen Situation, kann EAM die architektonische Ausrichtung für die Zukunft stützen. Dazu braucht es den Aufbau und ein nachhaltiges Management der EA. Insofern ist EAM eine permanente Investition in Dokumentation, deren „Return“ regelmäßig geprüft werden sollte.

Unsere Erfahrungen zeigen, dass EAM wesentlich zur Gestaltung und Umsetzung der Unternehmensziele betragen und zu den stabilisierenden Faktoren im Projektmanagement gehören kann.

• Definition des Scopes und des Nutzens
• Identifikation und Überzeugung von Stakeholdern: „Was will ich abbilden und wem nützt es?“
• Festlegung von konkreten Dimensionen für das EA-Modell (z. B. Geschäftsziele und -fähigkeiten, fachliche Domänen, Prozesse, Anwendungen, Schnittstellen, Daten, Organisationseinheiten, Infrastrukturelemente, Projekte, etc.)
• Prüfung vorhandener und Einführung neuer Tools sowie Prüfung des Einsatzes eines EAM-Frameworks
• Erfassen des IST-Bebauungsplan:
  • Schichtenweises Erfassen der definierten Objekttypen top down mit den heute vorhandenen Elementen
  • Horizontales und vertikales Verknüpfen der Elemente
• Verlinkung des EA-Modells mit „benachbarten“ Dokumentationsformen: Configuration Management DB, Systemdokumentation, Betriebshandbücher. Damit erhöht sich die Durchgängigkeit der Informationen
• Entwicklung einer Roadmap mit Quick Wins
  • Beschreibung der SOLL-Bebauung in der EA in Abstimmung mit der Unternehmens- und IT-Strategie
  • Angebot von Quick Wins und überraschender Auswertungen befeuern das Vorhaben
• Eingruppierung des EAM in die Linie.
• Etablieren eines Prozesses zur regelmäßigen Aktualisierung der Inhalte z. B. durch Architekten und Architektur-Community

• Anwendungsverantwortliche/ Application Manager/ Leiter Anwendungen
• Fachliche und technische IT-Architekten
• Infrastrukturverantwortliche
• Produkt- und Projektverantwortliche
• Projektportfoliomanager

• Strategieunterlagen
• Unternehmensorganigramme
• Anwendungslisten, Datenmodelle
• Infrastruktur- und Plattformarchitekturen

• IST- und SOLL-Bebauungsplan
• Roadmap zum Aufbau eines Enterprise Architecture Management

• Nicht in Details verzetteln, z. B. durch die Erfassung des „gelben Patch-Kabels“. EAM muss notwendigerweise abstrakt bleiben, sodass die Vollständigkeit nicht durch die Detaillierung geopfert werden muss.
• Bitte klären: Abgrenzung zu ähnlichen Themengebieten, wie z. B., CMDB Configuration Management Database, Asset Management, Tools zur Prozess-Erfassung, Projektportfoliomanagement oder weiteren Formen der Dokumentation. Dies sollte a priori abgestimmt sein.
• Ein großes Spektakel am Anfang, das nach wenigen Monaten eingeschlafen ist. Erzwingen Sie Kontinuität.
• Aufbau einer Online-Plattform (Intranet) über die die gesammelten Informationen für bereichsinterne Personen eingesehen werden können.

Projektvorgehensmodelle und -Methoden können einen Betrag zur Verbesserung der Projekt-Qualität leisten, z.B. wird durch ein standardisiertes Vorgehen die Vollständigkeit der zu liefernden Ergebnisse am ehesten gewährleistet. Weiterhin können Entwicklungs- und Wartungskosten verringert, Risiken eher identifiziert sowie Fehlentwicklungen früher erkannt werden. Zudem verbessern sie die Kommunikation zwischen allen Beteiligten, z.B. durch die Verwendung definierter Begriffe und einer gemeinsamen Terminologie.

In der Folge führt dies zu einer Reduktion von Reibungsverlusten zwischen den Projektbeteiligten.

• Festlegung des prinzipiellen Vorgehensmodell z.B. als
  • agiles
  • klassisches oder
  • hybrides Vorgehensmodell
• Berücksichtigung der Unternehmenskultur und der Reifegrades der Organisation spielt hier eine wesentliche Rolle.
• Überprüfung des ausgewählten Vorgehensmodells im Rahmen eines Ratings und individuelle Anpassung
• Etablieren von zum Vorgehensmodell passenden Templates und Instrumenten

• Ausgewählte Projektleiter
• Projekt Management Office
• IT-Führungskräfte

• Typische, tatsächliche Projektpläne

• Abgestimmtes, einheitliches Vorgehensmodell
• Klar definierte Instrumente und Methoden

• Fangen Sie beim Vorgehensmodell von „Oben“ an und nicht von „Unten“. Berücksichtigen Sie den Reifegrad des kompletten Unternehmens.
• Eine Organisation braucht Zeit, sich an ein neues Vorgehensmodell zu gewöhnen. Aber bleiben Sie beharrlich.
• Ein Vorgehensmodell ist kein Selbstzweck. Das Modell muss mehr helfen, als es an Aufwand generiert.