IT als People Business (Teil 1) – Reale Rollenbilder bei Banken und Versicherern

IT ist viel weniger von technischen Fragen geprägt, als man glaubt. Dies ist die Ausgangsthese. IT ist vor allem (auch) „People Business“ samt Rollenbildern. D. h. die Konstruktionen der Realität der Beteiligten (die aus ihrer Basis-Sozialisation, vor allem aber aus ihrer – meist akademischen – Ausbildung und den Lernprozessen in Unternehmen stammt) ist wesentlich im Alltag. Denn: Alle Beteiligten haben ihre sehr spezielle Sicht zu ihren eigenen Aufgaben, zu dem, was für sie wichtig ist und dazu, warum alle anderen „Player“ leider die Realität falsch interpretieren. Dass es daher – nett gesagt – „gewisse Kommunikationsprobleme“ gibt, sollte wenig überraschen … 

von Dr. Peter Bohnenkamp

Lassen Sie uns im ersten Schritt einen Blick auf die typischen Sichtweisen der Beteiligten werfen – im Selbst- und Fremdbild. Man kann dies auch als Liste von „Klischees“ resp. „Stereotypen“ (so würden Sozialpsychologen sagen) oder als „Sozialfiguren“ bezeichnen (letzteres wäre der eher soziologische Ausdruck). Im zweiten Teil des Artikels beschäftigen wir uns dann mit der Frage, welche Organisationsmodelle zur Steuerung von IT-Projekten – angesichts dieses Bildes – mit welchen Effekten einsetzbar sind.

Die IT-Typen und Klischees: Finden Sie sich wieder?

1. Die IT-Sicherheits (etc.)- „Beauftragten“: Sie sind prinzipiell eher depressive Menschen, die überall das Risiko/ den Angriff resp. Betrug sehen.

Sie halten alle anderen Beteiligten in der Tendenz für „verantwortungslos“!

Die umgekehrte Meinung lautet: Sie sind Formalisten, d.h. „machen nie etwas selbst“, fordern alle anderen immer (nur) auf, eine Risikoanalyse und passende Maßnahmen zu liefern, die sie prüfen werden; sie entscheiden nie etwas selbst, senden immer nur Vorschläge (ohne Beachtung von Zeit- und Kosteneffekten) und legen diese Mails dann ab, um sie bei Bedarf präsentieren zu können, wenn später etwas passiert…

2. Der IT-Architekt: Er ist typischerweise ein „Techniklastiger Methoden-Freak“, der immer auf der Suche nach Einsatzgebieten in Pilotprojekten für seine neuen Standardisierungsideen ist, die möglichst „groß und umfassend“ wirken sollen (Musterbeispiele: SOA. d. h. serviceoriented architecture, unternehmensweites Entity-Relationship-Modell, XY-Framework für Z-Entwicklungen); hält die meisten anderen für technisch inkompetent oder innovationsfeindlich; hat aber leider aus umgekehrter Sicht „von Geld und Zeitdruck keine Ahnung“.

Auch er ist eher ein For­ma­list, der gern Kon­zep­te an­de­rer prüft ge­gen sei­ne Stan­dards (die er sel­ten selbst schreibt, aber schon eher als der IT-Si­cher­heits­be­auf­trag­te).

Es ist nicht sel­ten aber auch frus­triert, da sich nie­mand an sei­ne Stan­dards hal­ten will und er we­ni­ger Macht als der IT Si­cher­heits­be­auf­trag­te hat, die­se – mit Dro­hun­gen – durchzusetzen.”

3. Die Entwickler: Auch sie sind meist „Freaks“ (aus der Sicht aller anderen Beteiligten), tragen aus Prinzip keine Krawatten, reden gern auch fachlich mit (wünschen hier gefragt und respektiert zu werden). Sie mauern gern, wenn ihnen etwas nicht passt, in dem sie dann Tabellen-/ Programmstruktur-Probleme, Probleme mit der Entwicklungsumgebung, der Hard- und Middleware anführen; mögen keinerlei Dokumentations-Aktivitäten.

Entwickler lesen ein Fachkonzept nie ganz genau (da es „ja nie vollständig sein kann“ und es sie in ihrer Entwicklungskreativität einschränkt); sie liefern gern auch Module halb getestet aus („soll doch der Fachbereich es testen…“), betrachten Zeit- und Geldvorgaben als „Management-Unsinn“.

Entwickler verbünden sich gelegentlich mit dem Architekten (wenn sie etwas technisch interessant finden) oder auch dem Fachbereich (wenn sie Lust haben, mehr zu machen als die Projektleitung will).”

4. Der Fachbereich: Er sollte die Anforderungen definieren, kann aber – so die typische Alternativmeinung – nur selten „drei grade Sätze schreiben, die die Anforderungen tatsächlich tief genug spezifizieren und ändert dann permanent seine Meinung (er weiß ja eben gar nicht so genau, was er will; es ist auch nicht genau dokumentiert…)“. Er sollte auch die Testfälle dazu benennen und dann testen… (puh); versucht meist auch bestimmte Themen und Ideen, die er immer schon hatte, in das neue, laufende Projekt „einzuphasen“ (und dort zu verstecken).

Wenn man ihn offen fragt, fallen dem Fachbereich sicher viele „goldene Wasserhähne“ und Problem-Einzelfälle ein, die man alle unbedingt abbilden muss (das Totschlagargument lautet: „Sonst verlieren wir die Akzeptanz der Kunden, den Erlös etc.“). Er verbündet sich gelegentlich mit den Entwicklern (insbesondere, wenn sie sich schon lange kennen), um dies dann durchzubringen.

Zeit und Geld sind nur solange wichtig, wie sie seinen Vorstellungen entsprechen.”

Alle Fachbereichsmitarbeiter träumen heute von “agiler (Scrum) Methode“ – denn da darf man so richtig schön „rumwurschteln“ und muss am Anfang auf keinen Fall „Farbe bekennen“ (wenn nicht jemand eine vollständige Top-Level Use-Case-Liste und einen Plan mit fixen Kosten fordert…) – sagen die Kritiker.

5. Der Auftraggeber: Management. Will, dass alles gut ist, zumindest gut wird – ohne Ärger bitte, „in Time, Function und Budget“, die möglichst minimal sein müssen. Will nichts mit den Details zu tun haben, entscheidet fast so ungern strittige Fragen wie alle anderen Beteiligten auch.

Der Auftraggeber fürchtet sich davor, dass Menschen wie der Architekt und Sicherheitsbeauftragte Mails sammeln, in denen ihm Schuld nachgewiesen werden kann (vor der Revision oder den Behörden). Er „fällt auch gern mal um“, wenn das Management des Fachbereichs (wenn es getrennt ist) oder wenn seine Fachbereichsmitarbeiter doch „Change Requests“ haben – selbst wenn sie größer sind. „Muss sich der Projektleiter eben Mühe geben, die Pläne doch einzuhalten“. Der Projektleiter macht den Auftraggeber immer nervös (egal in welcher Art er agiert).

Harte Vertreter der Klasse Auftraggeber halten IT für ein schwarzes Loch und wollen nur eins: Dass das minimalistische Budget und ggf. auch die Einsparziele eingehalten werden, die sie so schön nach außen kommuniziert haben. Inhalte haben dann keine Bedeutung mehr. Sie mögen daher eher „harte“ Projektleiter – wenn überhaupt, eigentlich lieber Berater.”

6. Der Projektleiter: Selbigen gibt es in verschiedenen Varianten …

Politisch: Er ist wie der Auftraggeber ein klassischer Manager – Relationship-Themen sind für ihn zentral; er versucht, durch „Reden den ganzen Tag“ alle bei Laune und „in Line“ zu halten. Er mag in der Tendenz keinen Streit, ist der beste Freund des Auftraggebers… kümmert sich eher nicht um Details, sondern liest bestenfalls einen halben Tag vor dem Lenkungsausschuss die Charts und lässt sie dann ändern… benötigt ein sehr gutes Projektoffice (zumindest bei schwierigen Großprojekten), das die inhaltliche Arbeit macht.

Hart: Ist strukturell menschenverachtend (zumindest im Blick aller anderen Beteiligten) – ihn interessiert nur „In Time, Function and Budget“ („Nur fertige Projekte unter dem Plan sind gute Projekte!“). Wer zuckt, fliegt aus dem Projekt raus – von ihm gern auch mal am Anfang als Exempel statuiert, damit alle wissen, woran sie sind. Lehnt alle Change Requests des Fachbereichs mit einem kategorischen Nein ab (außer er gibt zu, dass er sich selbst geirrt hat – aber das kommt so gut wie nie vor). Er kann die zu bauenden Funktionen und den Projektplan bis in mittlere Tiefen „auch nachts um vier Uhr hersagen“, wenn man ihn weckt. Er hält den Auftraggeber für ein Weichei, die Entwickler für Verrückte, den Architekten und Sicherheitsbeauftragten für „Nervheimer“, die man politisch ausschalten muss. Trifft den ganzen Tag Entscheidungen, auch wenn es nicht sein muss (weil es eigentlich jemand anderes tun müsste). Er hasst Dienstleister, die nicht genau das machen, was er will. Er schlägt vor, sein eigenes Projekt unvollendet abzubrechen, wenn es absehbar nicht erfolgreich wird (das hassen alle Auftraggeber ganz besonders), fürchtet sich höchstens vor der Revision, weil er doch weiß, dass er nicht alles beaufsichtigen oder selbst machen konnte.

Weich: Bei schwierigen Großprojekten mit knapper Zeit und wenig Geld eher verloren. Er versucht auf die nette Art, irgendwie durchzukommen, trifft keine Entscheidungen, delegiert alles an den Auftraggeber nach oben, freut sich über ex- oder auch nur implizit genehmigte Änderungen, da sie meist einen neuen Puffer schaffen. Beendet nie ein Projekt offiziell (jemand könnte ja nachfragen…)

Formal: Wie a (oder auch c) allerdings ohne die Kommunikationskomponente. Er interessiert sich nur für seinen Plan bzw. die formale Abarbeitung von Tasks/ Issues / LA-Sitzungen etc. Ganz furchtbar (sagen alle anderen), keine Frage.

7. Die Revision: Kommt bei Projekten, wenn alles fertig ist, und sucht formal nach Fehlern – fängt dabei immer mit der Basis-Dokumentation an (Fach-/ DV-Konzept, Test-, Übergabe- und Notfall-Dokumentation), arbeitet sich dann in die Benutzerhandbücher sowie die Details der Programm-Dokumentation vor (und die Dokumentation von Code Reviews) sowie den Business Case und die Dienstleister-Auswahl, wenn sie am Anfang nicht gleich einen schönen Treffer hatte. Liest dann auch Lenkungsausschuss-Präsentationen und -Protokolle, prüft deren Konsistenz, zeitliche Abfolge etc., Projektstatusberichte und Zeitaufschreibungen, Fremdleister-Rechnungen und deren Freigabe, wenn sie bis dahin wirklich immer noch nichts gefunden hatte.

Prüft dann, ob Incident-, Change-, Datenmanipulations- Anweisungen u.v.m. im täglichen Leben 100-prozentig angewendet werden oder sucht in den Untiefen des IT-Betriebs zur Anwendung nach schönen Treffern.

Hat sie auch dann tatsächlich immer noch nichts gefunden, sagt sie: „Ja, war mit Einschränkungen schon ganz ok…“

8. Der IT-Betrieb: Die ganz harte Fraktion! Betriebliche Inhalte interessieren sie in keinster Weise, nur ihre Server, Router/ Switches und die zugehörige Middleware, und vor allem schöne Management-Tools dazu, mit denen sie spielen können. Haben überhaupt kein Gefühl für Geld und wenig Gefühl für Zeit. Sie hätten immer gern das neuste und größte Modell – darüber definieren sie ihr Selbstverständnis.

Haben meist selbst zu Hause auch ein Mini-Rechenzentrum (zumindest wenn sie noch intrinsisch motiviert sind); ganz Harte sind dann auch „Bastler“ (d.h. holen den Schraubenzieher raus und bauen Teile ein und aus, damit „das Ding“ besser, schneller etc. wird).”

IT-Betriebler mögen Dokumentationen noch weniger als Entwickler und können wie diese selten drei lesbare Sätze schreiben – sagen alle anderen… Sie streiten oder verbünden sich gern mit dem Architekten (seltener mit dem Sicherheitsbeauftragten), insbesondere wenn dieser auch etwas schönes Neues möchte, was dann auch schöne neue Hardware-, Netzstrukturen etc. erfordert. Mögen ansonsten keine Entwickler („Die machen immer alles durcheinander“), keine Kollegen anderer Hardware-Fraktionen (z. B. „iiih Microsoft“), und die Fachbereiche sowieso nicht…

Gute Manager(innen) in ihren Reihen sind typischerweise (bauernschlaue) „Trickser“, die schlecht schlafen. Das wird daher meist teuer für das Projekt und den späteren Betrieb – außer der „harte Projektleiter versteht genügend vom Betrieb und einigt sich mit ihnen in ihrer Denkweise. Auf den Kosten-Tiefpunkt bringt aber auch er sie nur selten.

9. IT-Controller: Stammen sie aus dem Betrieb und arbeiten für diesen, sind es nahezu immer „Verbrecher“, die die Kosten verstecken hinter seltsamen Verrechnungsmodellen, die keiner versteht, an den Stellen, die keiner nachvollziehen kann. Kommen sie aus der Software-Entwickler-Ecke, sind sie meist naiv – zumindest – im Vergleich. In zentralen Bereichen sitzen meist Protagonisten, die IT nicht wirklich wenigstens von einer der Seiten operativ gelernt haben, sie bewegen sich also primär im Formalen. Ihre Macht hängt vom Standing, vor allem der Einstellung der Auftraggeber/ des IT-Managements ab (wollen diese sparen, können sie viel „Spaß“ haben, wenn sie keinem Streit aus dem Weg gehen).

10. Hard- & Software Hersteller: Sie sind der natürliche Feind aller Menschen, die die IT-Kosten senken (oder halten) wollen, haben meist eine „knallharte“ Vertriebsmannschaft, die auch noch das Blaue vom Himmel (obwohl es gerade regnet) verkaufen will.

Nutzen immer lustige neue Buzzwords, die man als Architektur-Standard, im Betrieb oder bei der Entwicklung unbedingt benötigt, wenn man „state-of-the-art“ sein will.”

Verbündete sind entsprechend häufig selbige Protagonisten im Unternehmen, die „weinen, wenn sie dies dann nicht auch sofort bekommen“ (sagen „harte Projektleiter“ und Auftraggeber dazu).

11. IT-Berater: Keinen Deut besser; sie erscheinen meist mit den gleichen Buzzwords oder mit Benchmark-Zahlen, die man besser nicht zu hinterfragen versucht als Top-Manager, und den üblichen Governance-Langweil-Einsparvorschlägen – dabei gern auch der Umkehrung dessen, was das Unternehmen aktuell einsetzt: „Großrechner? Nein, Client-Server!“ und umgekehrt; „So viele/ so wenige Steuerungsmethoden – das kann doch nicht sein!“, oder mit Outsourcing- und im internationalen Kontext gern auch überzogenen Vereinheitlichungs-Visionen.

IT-Berater halten ihre Auftraggeber für Amateure, den Rest für abbaubare FTE – aber das müssen sie auch, sonst würden sie verrückt in ihren Projekten.”

Sind „Schmeißfliegen“ – aus Sicht der internen IT (und meist auch der Fachbereiche, die sich dann ggf. sogar ausnahmsweise solidarisieren)! Auftraggeber nutzen sie aber gelegentlich gern, um die eigenen Mitarbeiter unter Druck zu setzen; das macht die Stimmung nur dann besser, wenn die Mitarbeiter sich zurücklehnen und lachend sagen: „Dann sollen die Jungs doch mal zeigen, ob sie es denn (besser) können“…

12. Die Mitarbeiter in den Behörden (mit IT Aufsichts-Ansprüchen): Kritiker sagen sofort: „Ihre Behörden wurden entweder gegründet, um direkt Meinungen zu erfüllen, der Überwachungsstaat habe sich um das Thema IT in Unternehmen zu kümmern, oder weil Manager in den Behörden das Thema interessant (für die eigene Profilierung) fanden“. Sicherheit und „Schutz gegen was-auch-immer“ sind die Schlüsselbegriffe, mit dem man an alles herankommt. D.h. die immer weitergehende Reglementierung ist hier Selbstzweck, um den eigenen Job aufrecht zu halten und „Spaß in selbigem“ zu haben.

Man schreibt dazu gern „prinzipienorientierte“ Gesetze oder (noch besser) legt einfach Gesetze in Verwaltungsvorschriften (permanent neu) aus, die streng, aber im konkreten Wording mit Bezug auf imaginäre Standards flexibel sind.”

Dann macht die Kontrolle bei den Unternehmen viel mehr Spaß. Man kann dann auch Dritte beauftragen (auf Kosten der Unternehmen), die Zertifizierungen oder Prüfungen durchführen, und man muss sich nicht selbst aus seinem Büro wegbewegen. Die Dritten wiederum werden einem immer dankbar sein für das schöne Geschäft und im Gegenzug mindestens schöne neue Ideen liefern, die Behörden-Mitarbeiter auf Konferenzen als Redner einladen etc.

Ganz clever ist es dann auch, in den Regularien zu verankern, dass in den Unternehmen „Alien-Stellen“ (so nennt man sie in der Praxis als Gegner dann gern – wie den „IT Sicherheitsbeauftragten“ eine „IT-Compliance Einheit“ etc.) zu etablieren sind, die dort „unabhängig“ (mit genügend Personal und Geld ausgestattet) über die Einhaltung der Regularien wachen sollen (und dies dann kontrollieren zu lassen). Da sind wir dann wieder am Anfang…

Noch Fragen an dieser Stelle?

Für Versuche, in dieser (gewachsenen, nahezu allgegenwärtigen, d. h. auch branchenneutralen) „Anarchie“ (im Sinne von Cohen/March/Olsen) eine Steuerung zu platzieren, sei auf den folgenden, zweiten Artikel  verwiesen. Sie müssen – nach hiesiger Meinung – auf der Prämisse aufsetzen, dass die Ausgangslage nahezu unüberwindbar ist, denn dies würde ansonsten Menschen voraussetzen, die es in dieser Güte (im Sinne von „gütig“ primär) eher nicht gibt.Dr. Peter Bohnenkamp