Entscheidungen und IT

28. Mai 2008

Als ich die Tage mal wieder durch Dirk Baeker’s „Postheroisches Management“ geblättert habe, bin ich über die Ausführungen „Der Grundbegriff der Entscheidung“ gestolpert (S 101).

Im Kern: Entscheidungen in Organisationen werden auf Basis von Entscheidungsprämissen getroffen. Oder anders ausgedrückt: die eigentliche Entscheidung ergibt sich fast zwangsläufig aus den Prämissen.

Das kennen wir in der IT wenn es darum geht, eine Produktevaluation durchzuführen: schon mit Festlegung der Evaluationskriterien und der Gewichte wird das auszuwählende Produkt festgelegt. Je nach politischer Situation stellt der Evaluationsprozess somit eigentlich nur die formale Rechtfertigung derjenigen Entscheidung dar, die man vorher schon gerne gefällt hätte.

Aber darauf wollte ich gar nicht hinaus.

Für mich haben diese Entscheidungsprämissen eine zentrale Bedeutung wenn es darum geht die Wirkung von IT-Systemen auf Gesamtorganisationen richtig zu bewerten. Diese Entscheidungsprämissen fliessen auf allen Ebenen in die Gestaltung der IT-Systeme, da sie struktureller und impliziter Bestandteil des Anforderungskatalogs und damit der IT-Architektur werden.

Nehmen wir eine x-beliebige Abteilung. Der Abteilungsleiter ist macht- und kontrollfokussiert, und legt viel Wert darauf, daß seine Mitarbeiter nur jeweils das tun können, was sie explizit tun dürfen. Spezifiziert die Abteilung nun ein IT-System, so wird das Thema „Rechte“ deutliche Beachtung finden. Die Kern-Prämisse des Rechtesystems wird sein: es kann nur etwas getan werden wenn es explizit erlaubt ist. Die Gruppen- und Teamleiter werden als Folge einen organisatorischen Overhead hinsichtlich „wer darf was“ mitschleppen (oder das Rechtesystem unterlaufen in dem sie intern sehr viele Rechte freizügig vergeben).

Stellen wir uns mal vor der Abteilungsleiter wechselt. „Der neue“ setzt auf Integrität und Selbststeuerung, und möchte nur sichergestellt wissen, daß bestimmte Dinge wie z.B. Freigabe von großen Beträgen nur von explizit berechtigten Mitarbeitern durchgeführt werden.

Das passt nicht zum alten Rechtesystem. Die Regelmechanik kann „einfach“ nur explizite Erlaubnis – aber eben nicht explizite Verbote. Gehen wir mal davon aus das die IT’ler an dieser Stelle strikt nach Anforderung programmiert haben, und keinerlei Generik oder Voraussicht haben walten lassen. In einer solchen Situation kann man zwar die gewünschte Rechtestruktur über Positiv-Regeln zwar formulieren, aber nur sehr umständlich. Jeder Mitarbeiter bekommt dann alle Rechte auf alles – bis auf diejenigen Funktionen die nur einzelne durchführen dürfen. Worüber man natürlich gesondert Buch führen muss – die herausgestellten Mitarbeiter kann man nur angesichts der vielen Erlaubnisse nur schwer erkennen.

Was machen die Gruppen- und Teamleiter: die werden zum großen Teil aus Selbstschutz (Aufwandsvermeidung) den alten Stil „explizite Erlaubnis“ fortführen. Die Mitarbeiter bekommen an dieser Stelle eine doppelte Botschaft: der neue Chef sagt „Integrität und Vertrauen“, und in der täglichen Arbeit ändert sich nichts. „Für jeden Sch*** musste zum Teamleiter laufen um die Rechte zu bekommen…“

Die alte Entscheidungsprämisse „explizite Erlaubnis“ – das Vermächtnis des alten Chefs – wirkt wie ein dunkler Schatten in die Organisation hinein. Und der neue Abteilungsleiter wundert sich, daß seine Mitarbeiter nicht wirklich befreit loslegen. Die IT wundert sich, warum die Abteilung mit dem alten System plötzlich unzufrieden ist.

Das Schlimmste was jetzt passieren kann: das Rechtesystem wird über Änderungsaufträge nach und nach umgestrickt – man will ja nicht zuviel Geld ausgeben für etwas, was man schon bezahlt hat. Die Folge ist eine grausame Vermischung von impliziten und expliziten Erlaubnis- und Verbotsregeln, weil man nie richtig Geld ausgibt, um das alte System entweder komplett auszutauschen oder vernünftigt neu zu machen.

Das Rechtesystem wird letztlich ein Unrechtssystem, und die Formulierung der Regeln ein Mysterium. Was wiederum Lücken und Fehler provoziert – hoffentlich nicht mit der Folge krimineller Machenschaften.

Das Problem: die Fachabteilungen wissen selbst oft nicht, nach welchen Entscheidungsprämissen sie handeln. Diese Prämissen sind oft dem Organisations-Unterbewußtsein zuzurechnen – wirksam, aber unsichtbar. Und selbst wenn diese Prämissen bekannt sind: diese zu formulieren ist ein politischer Akt, ein Statement, eine Festlegung. Fast wie der Blick in die Unterhose – so stellen sich die Fachabteilungen zumindest an wenn man versucht jene Prämissen schriftlich zu fixieren (meine persönliche Erfahrung).

Nun kann man es auf der anderen Seite verstehen, daß die Fachabteilungen die Prämissen nicht fixieren nicht möchten. Diese Prämissen sind oft Bestandteil der taktischen oder strategischen Ausrichtung, und hinmit „subject to change„.

Und genau da liegt die Krux: die Fähigkeit jene Prämissen flexibel anpassen zu können ist wesentlicher Bestandteil der Selbstorganisationsfähigkeit der Organisation (=Systems).

Und eben jene Prämissen fliessen (zum Teil unvermeidlich) in die Gestaltung der unverzichtbaren IT-Systeme ein. Diese Prämissen werden Bestandteil der in digitalen Beton gegossenen Geschäftsprozesse (= Software) und schränken dadurch die Selbstorganisationsfähigkeit der Organisation ggf. drastisch ein.

Es sei denn die Prämissen werden kommuniziert, und es wird kommuniziert das sie sich ggf. ändern können. Dann ist die IT wiederum in der Lage die Software entsprechend aufzustellen. Oder bestimmte Teile einfach gar nicht zu implementieren (was ich inzwischen immer öfters empfehle) um die Selbstorganisationsfähigkeit nicht einer 5%-tigen Effizienzsteigerung zu opfern.

Merke: „falsch“ designte IT-Systeme beschränken die Selbstorganisationsfähigkeit einer Organisation.

Advertisements

Der inhärente Konflikt „der IT“

18. Januar 2008

Ich habe mich kürzlich in einem XING-Forum in eine Diskussion rund um „Beyond Budgeting“ und IT-Abteilungen eingeklingt. Die Diskussion drehte sich um die Frage nach welchen „Nicht-Budget“-Zielen „die IT“ (im Sinne der Selbststeuerung) geführt werden könnte.

Für mich war das der Anlaß auf einen inhärenten Zielkonflikt hinzuweisen, welcher der IT innewohnt und den man bei der Suche nach Zielen bzw. der IT-Organisationsentwicklung generell nicht übersehen darf.

Der Konflikt bildet sich zwischen in dem Spannungsfeld von „Struktur“ und „Veränderung„.

Der erste Pol bildet die existierende IT mit ihrer existierenden Funktionalität ab, sowie der aktuellen Bedeutung „der IT“ im Unternehmen. Etwas sehr kurz gegriffen könnte man auch „Betrieb“ oder „Operations“ dazu sagen. Ich sehe es allerdings auch in einem weiteren, philosophischen Sinne: die Mitarbeiter und entsprechende Organisations-Substrukturen, welche in dieser Struktur arbeiten, sind tendenziell konservativ. Sie möchten den gegebenen Zustand bewahren und funktionsfähig halten – was ja auch sinnvoll ist. Es heisst nicht umsonst: never change a running system! Aber auch die aktuelle politische Lage, die gegenwärtige Macht/Verantwortung oder Nicht-Macht/Nicht-Verantwortung der IT-Abteilung zählt zum „Strukturpol“.

Die existierende IT bildet zum Teil oder fast ganz (je nach Konzerngröße) das Nervennetzwerk des Unternehmens ab. Woher stammen denn die Kennzahlen, mit denen das Management steuert? Welche Information wird nicht über eMail gesammelt bzw. weitergeleitet? Wer arbeitet nur mit Telefon und Meetings? Dieses Nervennetzwerk ist so bedeutsam und sensibel gegen Störungen, daß es massive Impulse gibt, Veränderungen daran zu verhindern – sowohl ausserhalb der IT Abteilung, aber auch recht massiv innerhalb der IT-Abteilung. Das ist angesichts der direkten und sehr unangenehmen, ggf. heftigst emotionalen Reaktionen der Nicht-IT-Mitarbeiter im Falle eines Systemausfalls oder bei Datenverlusten sicherlich auch verständlich.

Aber auch auf der politischen Ebene sind die strukturerhaltenden Kräfte vorhanden. Sobald „die IT“ mit im Boot ist und Geschäftsprozesse mit Hilfe von IT-Systemen digitalisiert werden, verliert der entsprechende Fachbereich an Macht und Flexibilität. Organisationsanpassungen, Geschäftsprozessanpassungen müssen dann mit der IT-Abteilung gemeinsam realisiert werden. Je nach aktueller Lage kann dies auf beiden Seiten sowohl begrüßt als auch abgelehnt werden:

  • vielleicht will die IT-Abteilung nicht noch zusätzliche Aufgaben und Arbeitsfelder haben,
  • vielleicht will die Fachabteilung eigentlich nicht abhängig werden von der Anpassungsgeschwindigkeit der IT-Abteilung,
  • vielleicht will aber auch die Fachabteilung das Thema loswerden und freut sich insgeheim darüber die dem Thema inheränte Problematik auf die IT-Abteilung abzuschieben…

Der zweite Pol des Spannungsfelds ist die Notwendigkeit sich mit der Veränderung der existierenden Strukturen beschäftigen zu müssen bzw. zu wollen. Funktionale Erweiterungen, Steigerungen der Komplexität (Differenzierung) sowie Verringerungen der Komplexität (Standardisierung) zählen dazu. Die Zielsetzungen der Veränderer sind hier ganz anders und reichen von „neueste Technologie einsetzen“ über „Gesamtsystemstabilität erhalten“ bis hin zu „Effizienz der Veränderung“.

Die Kräfte und Ziele beider Pole kollidieren innerhalb „der IT.

Ein einfaches Beispiel zu Datenstrukturen: man kann eine Adresse in verschiedenen Formen speichern. Die eine Form ist einfach und statisch: die Felder werden benannt, liegen in einer explizit dafür definierten Tabelle und bekommen eine feste Länge und eine klare Typenbezeichnung. Die zweite Form ist generisch: die Felder werden flexibel definiert, die Typen und Längendefinitionen der Adressstruktur werden durch die Programmierung nach Belieben definiert und angepasst. Die Daten liegen in einem zentralen Topf der für verschiedene Datenbereiche zuständig ist.

Die Bewahrer der Strukturen bevorzugen die erste Variante: sie ist statisch, klar definiert, es ist per Definition unmöglich das „fremde“ bzw. falsche Daten in der Tabelle gespeichert werden, die Datenbank selbst verhindert durch die vordefinierten Typen und Längen das es zu Datenschrott kommt.

Die Struktur-Veränderer bevorzugen im Zweifelsfall die zweite Variante, weil sie das Gefühl (oder das Wissen) haben, daß sich die Definition einer Adresse morgen schnell ändern kann. Hier werden quasi Regeln definiert welche beschreiben wie eine Adresse aussieht, und die Software folgt dann diesen Regeln. Muß die Adressdefinition geändert werden, dann ändert man ein paar Regeln und schon funktioniert die neue Version der Software. Definiert man die Regeln falsch, oder gibt es bei der Regelausführung Fehler dann kommt es (ggf. unbemerkt) zu Datenschrott, der erst in der Produktion bemerkt wird. Je generischer diese Regeln sind umso wahrscheinlicher ist dieser Fall, da die mögliche Komplexität exponentiell steigt und bald nicht mehr alle möglichn Fehlerfälle getestet werden.

Bei statischen Strukturen steigt der Aufwand der Anpassung, bei generischen Strukturen sinkt der Anpassungsaufwand. Ein weiterer Aspekt ist auch, daß die Softwarequalität leidet wenn man statische Strukturen zu oft anpasst. Wenn ein Programm per se entsprechend der Veränderungen generisch strukturiert ist, bleibt die Softwarequalität tendenziell stabil(er).

Diese beiden Pole prallen bei vielen kleinen wie großen Designentscheidungen aufeinander. Letztlich werden Annahmen über die Zukunft benötigt: wie wahrscheinlich ist es das sich diese Struktur, die Funktion, diese Datentonne, diese Anforderung nochmal ändert? Und wenn sie sich ändert, in welche Richtung geht die Änderung? Und wie häufig könnte sie sich danach nochmal ändern?

Man könnte nun sagen „nungut, das ist das Problem der IT, wenn kümmerts, die werden schon wissen was sie tun“. Weit gefehlt. Dieser Konflikt wird auch von außen in die IT hinein gespiegelt, denn für das restliche Unternehmen hat die IT ebenfalls zwei übergeordnete, konfliktträchtige Ziele bzw. Funktionen: beste Stabilität und optimiale Veränderung zugleich.

Beides zu erfüllen ist essentiell für den Unternehmenserfolg – das eine sichert das Tagesgeschäft, das andere den zukünftigen Unternehmenserfolg (unter der Prämisse das strategische Veränderungen am Markt auch wesentliche Anpassungen der Unternehmens-IT zur Folge haben).

Letztlich spiegelt sich in der IT das grundsätzliche Spannungsfeld des Unternehmens zwischen Effizienz und Anpassung.

Oft ist die IT-Abteilung aber nicht in der Lage eben jenen grundsätzlichen Konflikt zu erkennen und – sofern es sich eigentlich um die Frage der Unternehmensstrategie handelt – auf jene Ebene zurück zu transportieren, auf die dieser Konflikt eigentlich geklärt werden muss: der Unternehmensleitung.

Andrew Smart