Standardisierung ohne Gleichmacherei

Größere Unternehmen mit diversen Geschäftsbereichen tun sich oft schwer bei dem vereinheitlichen des IT Managements. Eine Grundversorgung, die alles enthält was gemeinsam benötigt wird und ein Zusatzangebot abgeschotteter Individuallösungen, wäre ein Effizienzvorteil, der schon bei kleinen Firmengrößen leicht als Business Case zu rechnen ist. Diese Standardisierung könnte durch eine gut etablierte externe Beratung oder Mitarbeiter, die von effizienteren Firmen kommen, erfolgreich implementiert werden. Mit Erfolg meine ich nicht Papierware sondern ein Effizienzvorteil ohne Nebenwirkungen oder Mogeleien mit Eh-da-Kosten und Auslastungssümpfen.

Besonders spannend ist es eine bestehende funktionierende Landschaft aus Produkten, Services und ITSM Prozessen in Grundversorgung und Individuallösung einzuteilen. Das ist sehr viel Nervenaufreibender und Langwieriger, als die Strukturierung eines Teilaspekts der ggf. als Greenfield-Projekt umgesetzt werden kann.

Umfassende Standardisierungen sind die wirtschaftlich sinnvollsten, diese haben aber auch die höchste Abbruchquote. Meist wird der Misserfolg vernebelt und als Erfolg verkauft, jedoch tauchen diese Wasserleichen spätestens beim nächsten IT Leiter wieder auf.

Ich möchte mit zwei Extremen beginnen, um in der Mitte die Lösung zu finden:

1. Management Basta – Ihr habt Euch lange genug ausgelebt

Nach mehreren Strukturierungsversuchen, die immer wieder von lokalen Kräften torpediert wurden, reagiert das Management nun mit harter Hand. Es dauert nur kurze Zeit und schon stimmt das System in den obersten Ebenen. Nur führt ein vereinheitlichen bis ins Detail dazu, dass es im Detail auch wirklich knarzt, denn die Besitzer der harten Hand haben das notwendige Detailwissen nicht. Auch ist es ohne Fachwissen unmöglich die Zuflüsterer in Experten und Wichtigtuer zu unterscheiden, beide werden wortreich anführen: „Geht so nicht!“.

Sehr spannend wird die Reaktion des Managements auf die Argumente der Leute die frühere Re-Strukturierungen torpediert haben und nun (teilweise wahrheitsgemäß) vorbringen, dass nach der Umsetzung einige Dinge nicht mehr funktionieren oder zu umständlich geworden sind. Da muss einiges an Ressourcen in die Schatten-IT versteckt werden, weil in der Vergangenheit zu oft ohne klare Alternative aufgemuckt wurde.

2. Sicher ist Sicher – Wir könnten unser Geschäft stören

Bei umfassenden Ansätzen, die mehrere Ebenen einbeziehen fehlt hie und da Kreativität und Mut eine Basis zu finden und Dinge auch zu verändern. Das führt dazu, dass unwichtige Bereiche Strukturiert werden, schöne Diagramme gemalt werden, aber im Kern nichts verändert wird. Insbesondere mangelnder Kontakt der IT Leitung zu den wertschöpfenden Einheiten im Betrieb und gute Argumente eines lokalen IT Verantwortlichen führen dazu, dass die verschiedene Einheiten nicht verändern, obwohl genug Potential vorhanden wäre.

Strategien den Kompromiss zu finden

Der Top-Down-Ansatz ist ja gar nicht mal so schlecht. Die neue Struktur muss Platz für die alten Aufgaben bieten und langsam von oben nach unten strukturierend wirken. Bei der Informationsvielfalt, die in einer gewachsenen IT heran-gezüchtet wurde, sollte man nicht auf das Wunder hoffen, es gäbe ein Expertteam das alles auf allen Ebenen durchdringt und sortieren kann. Kein Problem, die Fachleute sind ja schon im eigenen Haus, sie müssen vermutlich lernen wie etwas moderner, einheitlicher oder auch nur anders gemacht werden kann. Oftmals sind die Fachleute durchaus motiviert, hier kann Änderungswille genutzt und Potential durch positive Verstärkung vergrößert werden.

a) Beispiel Operations

Nehmen wir mal an in dem Unternehmen gibt es ein Wildwuchs an Server-Diensten. In jeder Lokation und jeder Abteilung wurden diese munter aufgebaut. Die Hardware ist von unterschiedlichen Herstellern, steht auf Büroflächen, die Software ist  teilweise auf einem unsicheren Patchlevel, aber dennoch sind einige Dienste Geschäftskritisch, keiner durchblickt das Geflecht.

Der Ansatz ist:

  • Server jeglichen Einsatzgebietes auch Testmaschinen verschwinden innerhalb von 12 Monaten von den Büroflächen und sind in Serverräumen unterzubringen (Zugangsschutz, Feuerschutz, Klimatisierung).
  • Es wird ein Hardwarewarenkorb geschaffen aus dem neue Server beschafft werden müssen
  • Für bestehende Hardware muss innerhalb von 12 Monaten ein Wartungsvertrag abgeschlossen werden
  • Eine zentrale Farm virtueller Server wird geschaffen und in der internen Verrechnung sehr kostengünstig angeboten
  • Schulungen zur Virtualisierung werden kostenfrei angeboten
  • Eine CMDB bzw. Inventarisierung wird angelegt und muss gepflegt werden

Somit kann jeder seinen Unter-dem-Schreibtisch-Server weiter betreiben, ja sogar im selben Gebäude installieren. Die tatsächlichen Kosten der Unter-dem-Schreibtisch-Lösung treten nun zu Tage. Vorher war es ein Zustand eines unfachmännischen Betriebs, der Kosten in Risiko und Eh-Da versteckt hatte. Als nächsten Schritt kann das zentrale Angebot verbreitert werden bzw. kostengünstig Migrationen angeboten werden. Vor allem sollten durch Dokumentation nach einiger Zeit kritische Unter-dem-Schreibtisch-Systeme identifiziert werden, die ihrem Geschäftswert entsprechend betreiben werden sollten.

Obiges Szenario kann in meinem Beispiel mit harter Hand durchgeführt werden, da es eine Plattformfrage ist, die von einem zentralen Team gut entschieden werden kann. 90% der Abteilungsserver werden umgewidmete x86-Desktop-Computer sein, die leicht zentralisiert werden können. Sondersysteme , die nicht im Hardwarewarenkorb berücksichtigt wurden, sind unter realistisch hohen Kosten weiter zu betreiben oder zu migrieren. Spezielle Server-Plattformen könnten z.B. durch Vorgaben von Produktionssystemen definiert sein. Dies kann ein zentrales technisches Team gut beurteilen. Der Migrationswille kommt durch einen Kostendruck. Sabotage durch außer Betrieb nehmen von Systemen wird verhindert.

b) Beispiel IT Service Management

Nicht immer funktioniert ein starres Reglement. Es lassen sich auch Aufgaben vereinheitlichen ohne den Betroffenen im ersten Schritt überhaupt etwas aufzuoktroyieren. Bei zusammengewachsenen IT Abteilungen sind Service Requests im User Lifecycle ein wunderbares Beispiel für viel Streit um Nichts. Im Bereich A muss ein Systemrecht erst von einem Key User eingestellt, vom Benutzer ausgefüllt, vom Abteilungsleiter genehmigt, von der Security genehmigt und dann vom Systemowner genehmigt werden. Im Bereich B vom Benutzer ausgefüllt, dieser darf den Key User um Unterstützung bitten, dann Abteilungsleiter, etc.

Beide Bereiche werden erbittert darum streiten, dass jeweils ihr Weg der einig Wahre und Sichere ist, man droht mit Revision oder IT Sicherheit. Da ist genau mein Ansatzpunkt. Es sollte zuerst auf Ebene der Benutzer-Richtlinie (User Lifecycle Policy) festgelegt werden welche Genehmigungen unabdingbar sind. Pro System, Typ oder Request sind eigentlich nie mehr als zwei Instanzen zur Genehmigung notwendig. Um Auditierung- oder IT-Security-Vorgaben zu erfüllen reicht meist ein aktives Informieren bzw. manchmal sogar nur der passive Nachweis durch ein Access Management System.

Kostenstelle

IT Security

System Owner

User Objekt

Genehmigen

Genehmigen

E-Mail

Genehmigen

Projektlaufwerke

Genehmigen

ERP

Genehmigen

Informiert

Genehmigen

Web-Proxy

Genehmigen

Genehmigen

Somit definiert sich ein System minimaler Workflows, diese lässt man zum Beispiel zentral vom Service Desk umsetzen. Falls noch nicht vorhanden, ergibt sich ein Kostenvorteil. Die Bereiche bleiben dennoch nicht außen vor, diese die können Workflows anreichern. Dazu müssen Bedingungen definiert werden, die dafür sorgen, dass der minimale Workflow niemals aufgehalten wird. Unten stehendes sehr simples System soll die Idee veranschaulichen:

Service Request Beispiel

Dieses Beispiel macht ehrlicherweise aus einem Genehmigen einen Review der irrelevant ist. Im echten Leben dürfen die Regeln etwas komplizierter ausfallen. Ziel ist schon zwingende Genehmigungen durch einfache Information zu ersetzen. In der Version 1.0 können erhitzte Gemüter durch „lazy approvals“ heruntergekühlt werden. Das sind Genehmigungen die einige Tage im System warten und bei nicht Bearbeitung automatisch vom Workflow-System genehmigt werden.

Darauf auf „lazy approvals“ ein Reporting angesetzt und schon verschwinden die überflüssigen Genehmigungen bei Version 2.0, da bei 99% „lazy approval“-Quote offensichtlich wird, dass eine einfache Information ausreichend ist.

Bitte auch bei einer sehr moderenen Workflow-Engine keine eigenständigen Prozeduren zulassen. Dies führt unweigerlich zu Wildwuchs. Es muss bei einem Standardisierungsansatz immer ein direkter Weg befolgt werden. Dieser darf zu Anfang sehr breit sein, jedoch sind Gewächshäuser rechts und links des Weges nicht erwünscht. Wirkungsvolle Mittel zum verjüngen der Wegesbreite sind als KPI

  • Anzahl der elementaren Aktionen (Mittelwerte oder bestimmter Aktionstypen)
  • Abweichung zur Dokumentation in jährlichen Reviews
  • Durchschnittliche oder maximale Durchlaufzeiten ungeachtet des Workflow-Typs

Zusammenfassung

Die beiden Beispiele sind hoffentlich eine Anregung, um in die richtige Richtung zu denken. Wie wirkungsvoll welche Mittel sind und welche Aktionen gangbar sind, hängt von der jeweiligen Firma ab. Deren Typ und Struktur ist jedoch immer gleich. Falls von Interesse kann ich solchen Vereinheitlichungsansätzen eine kleine Artikelserie widmen.

Auf diese Weise zu standardisieren ist meiner Erfahrung nach sehr viel erfolgversprechender, als kurzfristige Holzhammer-Projekte. Viel Druck in kurzer Zeit sucht sich seinen Weg, ob nun als Sabotage, sinnlose Mehrarbeit oder Schatten IT.

Der Preis für den hier dargestellten Ansatz ist: Kommunikation. Es müssen gute Leute lernen wohin der Weg geht und gemeinsam gute Ideen entwickeln, dazu benötigt es mehr Zeit als ein Wochenende. Auch müssen diese guten Leute für die Version 2.0 bereitstehen. Zum Beispiel die Version 1.0 nach einem halben Jahr auditieren und in DiskussionIdeen entwickeln. An der Bereitschaft des Managements diese Ressourcen bereitzustellen, lässt sich der aktuelle Standardisierungswille gut ablesen.

P.S.: Als kleine Kreativitätsanregung: Wer schon mal in sehr bürokratischen Ländern eingereist ist, hier wird oftmals – für den Beobachter sinnfrei – alles bestempelt, gesiegelt und abgehakt was freien Raum bietet. Definierter freier Raum ist eine prima Methode. Lasst den individuellen IT Bereichen freie Datenbankfelder, Hierarchieebenen, Tags, Keywords, etc. zum beschriften. Wichtig ist:

  • Deren Anzahl ist limitiert
  • Funktionalität auf einfaches beschriften beschränkt
  • Diese sind als frei (oder generisch) in einer Richtline ausgewiesen

Damit niemals aber wirklich niemals daraus etwas Verpflichtendes erwächst

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Dein Kommentar wird manuell freigeschaltet. Ich bitte um Geduld, das kann manchmal etwas dauern.