Zeit zum Umbruch Never change a running system?

Die IT-Organisation ist heute in weiten Teilen mehr von Reaktion denn von Aktion geprägt. Das liegt weniger an der fehlenden Expertise der handelnden Personen, sondern ist durch die Dauerschleife aus schnellen Reaktionen auf auftretende Situationen und den daraus wieder entstehenden Problemen geprägt.

Anbieter zum Thema

SonicWall Germany

Arvato Systems

SEPPmail - Deutschland GmbH

(ISC)2 Inc.

„Never change a running system“, lautet ein in der IT gerne benutzter Ausspruch. Nur funktioniert so manches IT-System im Verbund tatsächlich nicht immer so geschmeidig, wie das der Verantwortliche wahrnimmt. Um im Tagesgeschäft nicht weiter auf das leidige Thema IT-Betrieb eingehen zu müssen, wird zumeist mit kleinen Anpassungen die Arbeitsfähigkeit aufrechterhalten.

Mit der Zeit häufen sich Klagen der Mitarbeiter aus den Fachabteilungen, weil das Eine oder Andere im System nicht mehr so wie erwartet funktioniert. Und die Behebung führt – soweit sie überhaupt möglich ist – zu höheren Aufwendungen, als man das zunächst erwarten würde.

Mehr und mehr drängt sich die Erkenntnis ins Bewusstsein, das die IT-Landschaft nicht optimal funktioniert – ja sogar zur tickenden Zeitbombe werden kann. Kommt dann noch ein Ereignis wie unlängst die Abkündigung von Microsoft Windows XP dazu, kommt man als Unternehmen nicht mehr um umfangreiche Renovierungsarbeiten herum.

Gleichzeitig steigen die Anforderungen an die IT. So wird mit „Industrie 4.0“, also der Vernetzung aller am Produktionsprozess beteiligten Faktoren, die Komplexität der IT-Landschaft nochmal stark angehoben. Zukünftige Investitions- und Konsumgüterprodukte werden einen höheren digitalen Anteil besitzen und zu einer intensiveren Auseinandersetzung mit der unterstützenden IT-Infrastruktur geradezu zwingen. So treibt Smart Metering viele kommunale Unternehmen zur Anpassung der IT gestützten Mess- und Regelprozesse an.

IT-Infrastruktur fit machen für die Zukunft

Sobald man sich als Verantwortlicher mit den daraus resultierenden Anpassungen beschäftigt, stellt man zwangsläufig fest, dass mehr Fragen zu klären sind, als ursprünglich angenommen.

• Habe ich einen vollständigen Überblick über die Kosten meiner IT?

• Macht es Sinn Aufgaben an einen Dritten zu übertragen und was muss ich eventuell selbst dafür beitragen?

• Wenn schon größere Änderungen nötig sind, sollten dann veraltete oder nicht mehr benötigte Anteile der IT geändert werden?

• Wie stelle ich fest, ob meine IT für die kommenden Aufgaben die richtige Basis ist?

• Eigentlich kann das keine Herkulesaufgabe sein, schließlich sind zum Beispiel nur 80 Mitarbeiter im Betrieb beschäftigt, die einen PC brauchen. Das ist sogar richtig, wenn man die nötigen Voraussetzungen für eine Migration berücksichtigt hat. Nur welche sind das?

Befragt man Mitarbeiter und IT-Betreuer zu Problemen mit der Materie, bekommt man häufig Antworten wie:

• Die Auslieferung eines neuen Arbeitsplatzes dauert zu lange.

• Der Anwender kann an einem anderen PC seine Arbeit nicht erledigen.

• Sobald ein Mitarbeiter wechselt bzw. der PC neu ausgegeben wird, muss alles neu eingestellt werden.

• Änderungen und Fehlerbehebung am E-Mail- oder anderen Services können nicht selbst durchgeführt werden. Externe Unternehmen müssen – auch im Fehlerfall – beauftragt werden und stehen zudem nicht immer zur Verfügung.

• Unwissen über die Gegebenheiten verschiedener Server (Services). Denn bisher hat man sich noch nicht darum kümmern müssen, dass der Kontakt zum Serviceunternehmen durch den Fachbereich gehalten wird.

• Es gibt immer wieder unterschiedliche, eigentlich einfache Probleme, die ein Team binden wie z.B. Nacharbeitungen nach Auslieferungen sind nötig oder Einstellungen gehen „verloren“.

• Es werden zu viele E-Mails geschrieben.

Diese Antworten und Themen sind Indizien für einen hohen Grad an Individualität in der IT-Landschaft. Diese Individualität steht einer Weiterentwicklung entgegen, da sie alle Ansätze zur Vereinheitlichung und damit zur einfachen Handhabung aushebelt. Daraus wird schnell klar, dass Individualität eher mehr Probleme verursacht als vermeidet. Sie bedeutet damit eine schlechte Voraussetzung für eine Migration in eine übersichtliche und einheitlichere IT, die auch noch kostentransparent und kalkulierbar betrieben werden kann.

„Wenn das alles so aufwändig ist, dann geben wir‘s außer Haus!“

Unabhängig davon ob die IT später durch einen Dritten oder in Eigenregie betrieben wird, ein IT-Verantwortlicher muss die nötige Informationstiefe haben, um Entscheidungen treffen und Qualität beurteilen zu können. Das betrifft sowohl den gewünschten Stand nach der Umsetzung der Migration als auch die Ausgangssituation.

Häufig zeigt sich gerade am Anfang, dass z.B. unterschiedliche Programme für dieselbe Funktionalität eingesetzt werden. Hier wird eine Konsolidierung die Kosten senken. Oder der Austausch einer Firewall klappt nicht so reibungslos im Hintergrund, weil einfach nicht dokumentiert wurde, welche Verbindungen hiermit auf welche Weise reglementiert werden. Intern bleibt aber selten die Zeit, um selbst eine Minimaldokumentation zu erstellen bzw. aktuell zu halten.

Bei Beauftragungen wird das zwar implizit erwartet, aber explizit nicht ausreichend eingefordert. Zudem agieren Fachbereiche häufig eigenständig und ohne gemeinsame „Spielregeln“. Dadurch entstehen nur schwer nachvollziehbare Ergebnisse. Als IT-Verantwortlicher sollte man jedoch mindestens so viele Informationen über die eigene IT vorhalten, um die Steuerung von Betrieb und Weiterentwicklung ausüben zu können. Die Intensität sich mit der IT-Infrastruktur beschäftigen zu müssen, hängt in weiten Teilen von zwei Faktoren ab:

• Die Abhängigkeit der Geschäftsprozesse von der IT oder

• die Abhängigkeit der angebotenen Produkte des Unternehmens von der IT.

Je höher diese Abhängigkeiten sind, desto mehr stellt IT auch Kernkompetenz für das Unternehmen dar und umso weniger kann die IT-Architektur durch einen Dritten gestaltet werden. Ansonsten schwindet die Marktdifferenzierung. Leistung- und Produktangebot wäre beliebig austauschbar. Das heißt: Sie bestimmen, wie Ihre Umgebung gestaltet wird und, dass die IT nicht durch Dritte betrieben werden kann.

Im Umkehrschluss kann IT, die nicht der Marktdifferenzierung dient, auch gut durch Dritte gestaltet und umgesetzt werden. Dabei ist in jedem Fall ein hoher Grad an Standardisierung Pflicht, da sonst die Betriebskosten unkalkulierbar werden. Schließlich sollte ein klar umrissener Service genutzt und eingekauft werden können.

Was macht dann eine gute IT-Architektur aus?

Die IT-Architektur ist gut mit einem Hausbau vergleichbar. Hier hilft ein Bauplan, die Ausschreibungen über verschiedene Gewerke, sowie die Definition von Abnahmekriterien und verantwortlichen Ansprechpartnern erheblich weiter. Und auch hier gilt: erst wenn alle Teile ineinandergreifen, kann das Haus am Ende der Bauzeit in seinen verschiedenen Funktionen wie vorgesehen genutzt werden. Logischerweise muss eine Küche in einem Restaurant anders ausgeprägt werden, als in einem Einfamilienhaus.

In der IT sind es die Services, welche die Funktionen darstellen. Die Einrichtung von Infrastrukturkomponenten wie PCs, Netzwerk oder Servern sind dagegen mit den Gewerken vergleichbar. Services sollten so beschrieben sein, dass klar ist, wie die „Gewerke“ ineinander greifen müssen. Sonst wird der Ausdruck eines Angebotes eben nicht mehr auf dem Drucker nebenan ausgegeben, nur weil die zu einem Dienstleister ausgelagerte Anwendung den Drucker netzwerktechnisch gar nicht erreichen kann.

Aus der Geschäftsprozess- und Produktsicht kommend, ist die Herangehensweise trivial, da sie sich aus den oben benannten Abhängigkeiten ableitet. Die Kernfragen in jedem Dokumentationsschritt und jeder Architekturdesignphase sind:

• 1. Welche Funktionen und

• 2. welche Eingangsinformationen

• 3. in welcher Qualität und

• 4. durch wen verantwortet

benötigt der gerade betrachtete Geschäftsprozessschritt, um das gewünschte Ergebnis zu liefern?

Alle obigen Eigenschaften beschreiben zusammenfassen einen Service. Sind Eigenschaften aus anderen Services für die Erfüllung nötig, leitet sich hieraus die Abhängigkeit untereinander ab. Ohne eine Abhängigkeitsanalyse kann man für einen Service oder eine eingesetzte Technik nicht beantworten, wie wichtig eine technische Komponente tatsächlich für das Unternehmen ist. So wird beispielsweise E-Mail gerne als relativ unwichtig erachtet, weil interne und externe E-Mails für überschaubar kurze Zeit unbeantwortet bleiben können.

Bei genauerer Analyse stellt sich tatsächlich heraus, dass automatisierte Geschäftsprozesse auf zeitnahen, teilweise zeitgenauen Transport von Nachrichten angewiesen sind. Somit bekommt das E-Mail-System einen viel höheren Stellenwert als ursprünglich eingeschätzt.

• Was sind die nächsten Schritte zur passenden IT-Architektur?

Da die Komplexität der eingesetzten IT in großen wie kleinen Unternehmen relativ ähnlich ist, sind kleinere Organisationen gut beraten, sich intensiver mit Standards und eher einfachen und überschaubaren Lösungen auseinanderzusetzen sowie klare Regelungen für deren Betrieb und Nutzung vorzugeben.

Die Auseinandersetzung muss dabei so tief gehen, dass die Kontrollfähigkeit erhalten bleibt und man erkennen kann, wenn der Dienstleister zu seinem Gewerk ein paar wichtige Fragestellungen nicht vorgebracht hat, weil er den Kontext zum Geschäftsziel nicht erkennen kann. Folgende Fragen sollten beantwortet werden können:

Status Quo:

• Wo steht die IT heute? (Technik, Verantwortungen, Kenntnisse, Verträge, Dokumentation)

• Welche Kosten sind für IT, auch in den Fachbereichen, in den letzten drei Jahren angefallen? (Lizenzen, Wartung, Miete, Serviceleistungen, Anschaffungen, Personalkosten, etc.)

• Welche IT-Probleme behindern das Geschäft wirklich und welche sind nur lästig?

Welche Ziele streben wir an?

• Welche Regulatoren zwingen zur Anpassung?

• Welche Produkte müssen erneuert werden?

• Welche Marktanpassungen müssen berücksichtigt werden?

• Welche Vereinfachungen verschlanken Abläufe?

• Welche Geschäftsziele wurden neu ausgerichtet und benötigen IT Unterstützung?

Der Weg zum Ziel:

• Ist die Ausgangslage so robust beschrieben, dass sie eine Änderung im Projekt zulässt?

• Ist das Ziel eindeutig und umfassend formuliert?

• Kann ein Plan erstellt werden um in einem oder mehreren Projekten mit Meilensteinen das Ziel zu erreichen.

• Lässt der Plan Korrekturen zu?

• Sind die nötigen Ressourcen einsetzbar? (Budget, Konzeption, Personen, Zeitrahmen, Beeinträchtigung anderer Services)

• Woran erkenne ich den Fortschritt und Erreichung des Zieles?

• Wie und wo ist der Übergang in den Betrieb behandelt?

• Gibt es bereits Betriebsprozesse oder werden die Betriebsprozesse im Projekt beschrieben?

Fazit

Wenn man sich die Mühe macht, diese Fragen umfassend und abschließend zu beantworten, ist man in der Lage, die Kommunikation zu Mitarbeitern und Dienstleitern unmissverständlich zu formulieren. Dadurch werden viele Unklarheiten im Projekt und – später – im Betrieb vermieden, die Projektmitglieder können sich auf die Erfüllung des Projektes voll und ganz konzentrierten und für den Betrieb werden klare Handlungsanweisungen ermöglicht. Und wenn Unternehmen ein Architekturprojekt durch einen Dienstleister umsetzen lassen, so sollte dieser eingangs solche Fragen stellen und mit den Verantwortlichen klären.

(ID:43836230)