Musings on IT-Teams für qualifizierten Eigenbetrieb

Dieses Jahr habe ich wieder mehrmals die Gelegenheit, an prominenter
Stelle die Eigenheiten zeitgemäßen IT- Betriebes zu diskutieren und in Summe
einige der fest zementierten Glaubenssätze der deutschen IT Community in
Frage zu stellen. Dabei wiederholt sich ein Aspekt der Diskussion regelmäßig
wieder, gleich ob es um die Cloud, neue Plattformen zur Virtualisierung,
Hyperconvergenz, des Anwendungsbetriebes oder gleich ganz allgemein um
eine zeitgemäße IT Organisation geht.

Das ist mühsam, zumal sich gerade bei den Glaubenssätzen um mit Millionenbudgets
gefestigte Aussagen all derer handelt, welche an der Cloud oder XaaS –
Irgendetwas As A Service – ein ernst zu nehmendes Gewinn- Interesse haben und
allein mit der Effizienz der Skala zu argumentieren versuchen. Dass diese
Effizienz Mandantenfähigkeit, überbordende Organisation, Service Management,
externe Prozessschnittstellen, technische und finanzielle Risikovorsorge und
das genannte Gewinninteresse abdecken sollen, den Nachweis dessen ist mir bis
Heute jeder Anbieter schuldig geblieben.

Seit Jahren werde ich nicht müde die Aussage, dass “Ein Qualifizierter
Eigenbetrieb die günstigste und effektivste Methode sein muss, IT zu betreiben”.
Dabei bin ich durchaus bereit zu zu geben, dass das “qualifiziert” durchaus
der Knackpunkt an dieser Aussage ist, was mich eben zu diesem Post bewegt.

Mancher wirft mir vor für einen Head of IT zu wenig Manager und zu Technik-
verliebt zu sein und es fällt mir auch schwer zu behaupten ich wäre nicht
zumindest sehr Technik- nah – zumal gerade der aktuelle Stand derselben auch
kleinen und mittleren Organisationen ganz erstaunliche Möglichkeiten eröffnet.

Jedoch Antworte ich aktuell mit schöner Regelmäßigkeit, wenn ich nach dem
Wesen und dem Kern meiner Aufgabe Head of IT gefragt werde: Ich stelle das
Team auf, das die IT organisiert und managt.

Tief Luft holen. Sacken lassen. Ich antworte mitnichten, dass ich die
Unternehmensziele in eine IT Strategie übersetze, dass ich die Kosten
kontrolliere, die Budgets erarbeite oder die Organisation gestalte. Sollte
ich alles richtig gemacht haben werden schon diese, meine typischerweise an
erster Stelle genannten Management Aufgaben von meinem Team erledigt.

Mein Selbstverständnis als Head of IT ist es das Team in die Lage zu versetzen
all dies zu tun, und meine Aufgabe ist es ihnen die Möglichkeiten und die
Fähigkeiten zu geben all das um zu setzen. Ich setze Leitplanken und gebe
Impulse zur Organisation, ich setze Ziele und vertrete nach außen das, was
die KolegInnen erarbeitet und geleistet haben. Ich muss sie motivieren ihre
Grenzen zu überschreiten und ihnen die Gewissheit geben, dass sie an Hürden
Unterstützung erfahren, dass sie alle notwendigen Schritte auch in ihrem
Tempo gehen können – selbst wenn ich zu Weilen ein bisschen antreiben muss
und soll.

Aber was bedeutet das?

Ein kleiner Ausflug in die Welt operativer IT und ihrer typischen
Organisationsformen:

Meine Erfahrungen in anderen Organisationen und in der Beratungen haben mich
immer wieder mit der Situation konfrontiert, dass tailoristische – arbeits-
teilige Züge aus der klassischen Produktion in die IT übertragen wurden. Die
Idee, dass eine ausgesprochene Spezialisierung verschiedener Arbeitskräfte
deren Effizienz erhöht findet sich ein zu eins in vielen Organisationen wieder.
Es gibt das Server Team, das Windows Team, das Storage Team, das Firewall Team,
das Netzwerkteam …. am letzten Punkt sollte der geneigte Leser schon zucken.

Wieso sind Firewalls plötzlich keine Netzwerkkomponenten mehr? Es finden sich
tausend Gründe das zu rechtfertigen, sei es darum.

Diese Organisations- Proliferation führt zu zwei Dingen: einem ausufernden
Change
-Prozess, da komplexe Aufgaben tatsächlich auf komplexe Art und Weise in Teil-
Schritte zerlegt und in der Umsetzung dann aufwändig koordiniert werden
müssen. Und Zweitens dazu, dass jede Disziplin ihren Fokus auf ihre eigene
operative Excellenz legt und sich Methoden erarbeitet die sicher und robust
den eigenen Wirkungskreis realisieren, jedoch die Komplexität außerhalb
der eigenen Schaffens- Sphäre typischerweise außer Acht lassen. Wozu auch?
Die ITIL Prozess- Implementierung hat saubere Schnittstellen sowohl im Prozess
als auch in der Resolvergruppe implementiert. Die Organisation ist sauber.

Was bedeutet das für große Projekte? Sie explodieren und verusachen Kosten,
welche in keinem Verhältnis ihrer Effizienz- Gewinne stehen. Sie werden in
die Länge gezogen, da die Prozessabarbeitung jede Geschwindigkeit aus dem
Vorgang heraus nimmt.

Ein Beispiel: In meiner Zeit als Fachführungskraft, hatte ich das
zweifelhafte Vergnügen einmal das Durchstarten zweier Switche zu verantworten.
Zugegebenermaßen zweier sehr zentraler Switche mit einer gewissen Reichweite,
jedoch in einem Hochverfügbaren- Setup, das darauf ausgerichtet war den
kompletten Ausfall eines der beiden Switches ab zu sichern. Wohl wissend,
dass viele Verfügbarkeitstechnologien ihre Grenzen haben und sowohl die
Abhängigkeiten und Komplexität als auch der Faktor Mensch durchaus der
Technik Grenzen auf zeigen, ist gerade diese Aktivität “reload \<Enter>”
zu tippen, zehn minuten zu warten und das Ganze auf dem zweiten Switch zu
wiederholen, durchaus ein überschaubares Szenario, dessen Abhängikeiten mit
Menschenverstand und Kontrolle einiger kritischer Komponenten zu klären
wären.

Nichts hat mich auf das vorbereitet, was es zu bewältigen galt um diese zwei
Netzwerkkomponenten durch zu starten. Ich habe “postmortem” die Prozeskosten
ausgearbeitet, in meiner Freizeit, aus persönlichem Interesse, und bin auf
einen Betrag jenseits der zweihunderttausend Euro gekommen. Für das starten
zweier Systeme.

An dem Tag habe ich jeden Gedanken an die Effizienz tailoristischer IT-
Organisation begraben. Sie ist die Perversion des Change- Prozesses.

Was sind die Erkenntnisse?

Zunächst das Organisatorische:
Der Change Prozess hat nichts desto trotz seine Berechtigung, er dient
der Dokumentation und der Reversibilität der System- Eingriffe. ITIL als
der heilige Gral der IT Prozessorganisation hat bei genauerer Betrachtung
nichts mit dem Ergebnis zu tun. ITIL erlaubt einem frei die Organisations-
Form zu wählen.

Das Menschliche:
Auf Grund der zahlreichen Abhängigkeiten hatte jedet Mitarbeiter, jedes Team
und insbesondere jeder Abteilungsleiter Bedenken, um nicht zu sagen Angst, dass
im Falle eines unvoerhergesehnen Verhaltens etwas auf seinen Wirkungskreis
zurück fallen könnte. Niemand war bereit ein Risiko auch nur zu akzeptieren.
Das wäre akzeptabel wenn eine Wahrnehmung der Abhägigkeiten und der Risiko-
Domänen gegeben gewesen wäre, jedoch durch die starre Fokussierung auf den
eigenen Wirkungskreis wurden eben nicht reale Risiken bewertet, sondern eine
hypothetische Menge von Risiken unter der Voraussetzung, dass keine andere
Fachgruppe auch nur ansatzweise ihren Job richtig gemacht hätte. Die
Spezialisten haben jede noch so kleine Möglichkeit in den Prozess ein
gesteuert, welche sie mangels der Akzeptanz von Aussagen anderer Disziplinen
haben identifizieren können.

Das Perspektivische:
All dies erfolgte ohne jede Bewertung der Business- Perspetive, was ein
unterlassen des fraglichen Change bedeuten würde. Den verzicht auf
weiteren Infrastrukturausbau, den Verzicht auf neue Kapazitäten im
Rechenzentrum und damit auf Wachstum der Kundenbasis oder der Gewinnung
weiterer Kunden. Jedenfalls mit der einzigen Alternative ein neues
Rechenzentrum parallel auf zu bauen.

Zusammenfassend hat eine Aktivität, die in Summe nicht einmal zwanzig Minuten
dauern sollte, das mehr als viertausendfache an Prozesskosten verursacht.

Der einzige Grund, der hierfür ins Feld geführt werden kann ist, mangelndes
Urteilsvermögen, nicht zwangsläufig des Individuums, sondern der Organisation.
Ich habe in ähnlich gelagerten Organisationen den Versuch gesehen mit IT-
Architekten- Rollen dem entgegen zu wirken und in selbigen, die nicht die
operativen Anpassungen vor genommen haben die Aussage “Der Architekten-
Ansatz sei gescheitert!”.

Nein!

Damit zurück zum Thema, was macht im gegebenen Beispiel einen Architekten aus?
Dass er ein breites Wissen mit sich bringt! Er muss IT Systeme von unterster
Infrastruktur durch Rechte und Rollen bis in die Anwendungen hinein
abstrahieren können. Er muss die Komplexität seiner Aufgabe verstehen und
Abhängigkeiten identifizieren, sie ordnen und in einen sinnvollen Kontext
stellen. Von ihm zu verlangen er sei in jedem Thema Spezialist wäre bei
der Vielzahl der heutigen Möglichkeiten dann doch etwas zu viel verlangt. Und
doch wird genau das gerne in den Tailoristischen IT- Organisationen verlangt,
da jede Fachabteilung gerne auf ihrem Level abgeholt werden möchte. Die
Rolle des Moderators reicht nicht aus um die Lücken zwischen vielen Abteilungen
zu schliessen.

Folgt man diese Argumentation,
steht der Architekt bald vor der Frage, warum er noch
einzelne Mitarbeiter in seine Tätigkeit ein beziehen soll, da er ohnehin
das Fachwissen mit sich bringt, die notwendigen Schritte selbst zu tun und
die Moderation der Selben dauert oft länger als die Umsetzung. Insofern gebe
ich vielleicht dem Statement des gescheiterten Architekten- Ansatzes recht,
wenn auch aus gegenteiligen Gründen.

Mitarbeiter mit T-Profil:
Bringt man diese Überlegung mit der Notwendigkeit nach Urteilsvermögen zusammen
landet man fast zwangsläufig bei den Mitarbeitern mit dogenanntem T-Profil.
Diese Mitarbeiter bringen ein breites interdisziplinäres IT Wissen mit sich.
Einzelne Themen beherrschen sie deutlich detaillierter und qualifizierter als
andere. Idealerweise vertiefen sie mehrere Themen auf nahezu Spezialisten Niveau
ohne jedoch andere Inhalte aus dem Blick zu verlieren. Diese nicht so gut
beherrschten Inhalte Überlappen sich
dann mit dem spezialisierten Wissen von Kollegen die eben dort ihr tieferes
Wissen aufgebaut haben, und in wieder anderen Bereichen ihre allgemeineren
Fachkenntnisse mit sich bringen.

Setzt man voraus, dass sich die Anzahl der notwendigen Fähigkeiten durchaus
überschaubar gestaltet, kann man in der gesamten Betriebs- Mannschaft
ein System zum Wissens- Management etablieren, das:

1.) den Austausch und die Dokumentation vorhandenen Wissens fördert
2.) die Kollegen in ihren Stärken bekräftigt und ermutigt sich mit anderen
Themen auseinander zu setzen
3.) den Aufbau von Wissen kanalisiert und die Vorlieben
der vorhandenen Mitarbeiter abgleicht bzw. die Ziele für Personaölaufbau
klar identifiziert

Soweit so akademisch. Auch hier stehen wieder Menschen mit ihren Vorlieben und
Wünschen im Mittelpunkt und natürlich findet hier nur Veränderung nur durch
Motivation statt. Diese sollte um den Wissensaufbau für die Organisation
nachhaltig zu gestalten, intrinsisch gefördert werden. Abholen der Kollegen
steht an vorderster Stelle. Ich könnte mich zu einem Ausriss über Leadership
und führen aus der Mitte hinreißen lassen, erachte das jedoch als ganz eigenes
Thema. Ein Führungs- Ideal jedoch, das die Notwendigkeiten dieser vernetzten
Team- Gestaltung fördert.

Damit der Austausch von Ideen, Wissen und auch Aufgaben erfolgreich sein kann,
muss de rUmgang im Team von gegenseitigem Respekt und Akzeptanz geprägt sein.
Aus meiner Erfahrung heraus müssen die KolegInnen keine Freunde sein, aber sie
müssen so gut zueinander passen, dass sie es sein könnten. Sie müssen
menschlich zueinander passen.

In einer solchen Atmosphäre können dann auch unangenehme Aufgaben oder
Termine positioniert werden. Das Team ist nur erfolgreich wenn sie alle
gemeinsam über die Ziellinie gehen. IT- Betrieb ist sozusagen ein Mannschafts-
Marathon. Die Ausprägung gegenseitigen Respekts erlaubt dann auch Erwartungs-
Haltungen innerhalb des Teams, das jeder einmal die “Kröte schlucken” muss.

Meine Erfahrung zeigt, dass die wirklich unangenehmen Themen, für die sich kein
Freiwilliger findet, durchaus begrenzt sind und verteilt man diese dann doch
mit sanftem Druck und der Erinnerung daran dass unlängst ein anderer Kollege
ein anderes Thema einfach vom Tisch arbeiten musste, so bleibt am Ende des
Tages nichts liegen.

Im Umkehrschluss, kann man je nach Situation bei größeren Aufgaben Projekt-
Teams benennen, die alle wesentlichen Projektaufgaben innerhalb des Projektes
erledigen und nur zum Abdecken größerer Lücken auf die Kollegen mit tieferem
Fachwissen zurück greifen. Diese Umstellung steigert die Umsetzungsfähigkeit
selbst kleiner IT-Mannschaften ungemein und erlaubt damit zeitgemäße
Innovations- Projekte zu realisieren.

Der Weg in diese Situation ist nahezu vorgezeichnet. Leadership als Stichwort
ist bereits gefallen und die Führungsaufgaben müssen so umgesetzt werden, dass
die Mitarbeiter auch vorbehaltlos die ihnen aufgezeigten Wege annehmen können.
Bei den Lieblingsthemen ist das normalerweise ein Selbstläufer, spannender wird
es bei den nicht so angenehmen Aufgaben. Hier spielt Vertrauen in den Leader
die wesentliche Rolle. Die Aufgabe sich des Themas an zu nehmen liegt in jedem
Fall beim Mitarbeiter. Ihn in dieser Situation nicht alleine zu lassen oder
nicht zu überfordern ist Aufgabe des jeweiligen Vorgesetzten. Dazu gehört neben
der offenen Diskussion des gerade identifizierten Sachstandes und der nächsten
Schritte auch eine akzeptable Fehlerkultur. Jeder darf Fehler machen, nach
Möglichkeit jeden nur ein mal und wenn es geht auch mit einem belastbaren
Plan B.

Hierbei hilft die Formulierung klarer Erwartungshaltungen. Ich werwarte
Commitment! Ich erwarte dies im Sinne con Selbstverpflichtung eines jeden
Teammitglieds, dass es sich die durch ihm “committeten” Aufgaben ansieht und
kritisch prüft, sich diesen nähert, Lösungswege versucht oder evaluiert und
wenn sich der oder diejenige über die Grenzen ihrer jeweiligen Kenntnisse
oder Leistungsfähigkeit hinaus bewegen muss, die Hand hebt und mich
strukturiert informiert.
Dann kann man gemeinsam den Status Quo bewerten, gegebenfalls neue Handlungs-
Optionen zusammen erschliessen oder sollte die Grenze des Themas nicht
gemeinsam überwinden lassen, nach externen Lösungsansätzen suchen.

Tatsächlich geht die Aussage so weit, dass jeder im Team die Anweisung hat,
sollte länger als eine Stunde kein Fortschritt erziehlt worden sein, einen
Dienstleister zu Rate zu ziehen und mit diesem Zusammen die jeweiligen
nächsten Schritte in Angriff zu nehmen, zu dokumentieren und zu lernen. Zu
diesem Zweck sind mit einigen Dienstleistern Abrufkontingente vereinbart, in
anderen Fällen hat jeder Kollege ein Budget für solche Aktivitäten und bis
fünfhundert Euro in einem Call darf jeder selbst entscheiden.

Um die Themen wieder zusammen zu führen wird dabei in regelmäßigen Abständen
im Team- Meeting über Inceidents und Changes sowie der dazugehörigen Calls,
sowie alle Projekte in Kurzfassung berichtet. Jedes Teammitglied hat die Chance
den Stand und die Herausforderungen jedes anderen zu erfahren und durch eigene
Anregungen zu ergänzen bzw. mit eigenen Aktivitäten ab zu gleichen.

Zusammenfassend lässt sich sagen, dass die Maßnahmen zur Förderung:
1.) Mitarbeiter zentrierte Themenentwicklung
2.) Kommunikationskultur mit regelmäßigem inhaltlichem Abgleich
3.) Fehlerkultur
4.) Regeln für extene Hilfe und Wissensgewinnung
5.) Zusammenhalt im Team

Nach mehreren Jahren operativer Umsetzung in einen Regelprozess gemündet sind,
der die Umsetzung anspruchsvollster Projekte bei gleichzeitiger Garantie
des Regelbetriebs gewährleistet. Das soll nicht über die Knappheit von
Ressourcen hinweg täuschen, erlaubt jedoch eine Agilität und Flexibilität die
ich so zumindest in deutschen IT- Organisationen noch selten gesehen habe.

Um einigen der üblichen Rückfragen vor zu greifen, auch ich habe durchaus
Mitarbeiter gesehen welche den Erwartungen nicht gerecht wurden. Die erste
Frage die ich heute Stelle ist, “erwarte ich das Richtige?” Ich stelle nicht
den Mitarbeiter in Frage sondern im Stillen zunächst meine eigene Bewertung
der Situation. Bei einem Team im Aufbau deutet viel darauf hin, dass ich
gegebenenfalls mit meiner Einschätzung schon bei der Einstellung falsch
gelegen habe. Wenn ja sollte ich mir Maßnahmen überlegen, wie hier ein Weg
zu finden ist, zu einem adäquaten Portfolio im T-Profil zurück zu finden. Setze
ich den Kollegen richtig ein? Was kann ich tun um ihm eine Aufgabe zu geben, in
die er sich mit dem ohnehin erwarteten Aufwand hinein entwickeln kann?

Sollte man trotz aller Vorsicht sich eine toxische Persönlichkeit in das Team
geholt haben, hilft es nichts daran fest zu halten, aber meine Erfahrung ist,
dass diese doch eher selten an zu treffen sind. Wenn ich an einer Stelle
kurzfristig und vehement reagiere(n würde), ist es durch so einen Menschen
den Zusammenhalt im Team gefährden zu lassen. Durchaus etwas an dem ich auch
keinen Zweifel aufkommen lassen würde.

All diese Maßnahmen zusammen lassen dann eine Mannschaft entstehen mit der man
durchaus sehr qualifiziert einen IT- Eigenbetrieb gestalten kann und auch kaum
einen externen Benchmark scheuen braucht. So können
modernste Konzepte realisiert werden und Effizienzen gehoben,
so kann Standardisiert und Automatisiert werden und eine absolut wettberwerbs-
fähige IT Umgebung geschaffen werden.
Letztenendes wird so eine Umgebung geschaffen in der
jeder zu jedem Zeitpunkt die wirklich kritische Ressource “Urteilsvermögen”
besitzt, die Voraussetzung für die agile Umsetzung heutiger IT- Anforderungen
ist

In diesem Sinne haben die aktuellen Schalgwörter Leadership, Commitment und
Ownership eine Aktualität die nahezu nicht überbewertet werden kann.

Kyp. F.

One thought on “Musings on IT-Teams für qualifizierten Eigenbetrieb

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.