Neue Website online

24. Februar 2011

Ich habe die letzte Zeit genutzt um die Systemische-IT-Website neu aufzusetzen. Das eigentliche Ziel war die Umstellung der technischen Plattform (weg vom selbst-implementierten Python-CMS) hin zu Joomla, um dort dann schneller Inhalte & Co pflegen zu können.

Weil ich aber gerade so in Schwung war bekam die Seite ein neues Layout und ist jetzt „irgendwie“ auch massiv umstrukturiert und erweitert worden. Da hat mich die Umstellung auf Joomla quasi inspiriert und sich dadurch gleich mehrfach bezahlt gemacht.

Der erste Wurf ist jetzt online (Korrekturlesen steht noch aus, man möge mir etwaige Schreibfehler verzeihen), ich habe aber noch ein paar Erweiterungsideen:

  • Für die Homepage/Erste Seite soll es für die jeweiligen Zielgruppen (IT’ler, Systemiker, Manager, Fachseiten) Einstiegsseiten geben, welche den Ansatz aus der jeweiligen Perspektive abbilden.
  • Ich würde gerne noch einen Bereich für Fallbeschreibungen aufbauen, in denen Beispiele für die Anwendung von „Systemischer IT“ dargestellt werden.
  • Ein Ergebnisbereich für unsere Forschungsergebnisse wäre ebenfalls sinnvoll.
  • Jeder Mitspieler im Netzwerk kann jetzt ein Login erhalten – wir können damit auch eine Differenzierung der Inhalte erreichen.
  • Durch die Registrierung können wir allen Netzwerk-Partnern die Möglichkeit eröffnen, selbst Inhalte zu erstellen.
  • Unsere Netzwerk-Partner und Teilnehmer könnten dank Joomla in einer kleinen Datenbank erfasst und verlinkt werden. Wobei die Vertraulichkeit dadurch gewährt bleibt, dass Kontaktdaten & Co z.B. nur  registrierten Mitgliedern angezeigt werden.
  • Im Bereich Links & Bücher & Co muss noch aufgeräumt werden – und ich hätte hier gerne eine möglichst vollständige und hochwertige Sammlung von Bezügen nach „draussen“. Dazu kommt eine weitere Kategorie „Presse“ in der auf aktuelle Themen oder Berichte über die Systemik verwiesen wird.

Im Kern möchte ich die Homepage als zentralen Wissen-Knoten rund um „systemische IT“ aufbauen – und die Plattform für Dritte öffnen, die – anders als Leo und Anja – keinen direkten und persönlichen Zugang zum Admin der Seite haben 😉

Ich würde mich über Feedback, Inhalte und Anfragen auf Registrierung freuen 😉


Der Workflow führt die Führung vor…

17. Januar 2009

Im Rahmen meiner Architekturtätigkeit beschäftige ich mich intensiver mit „BPM“ – Business Process Management. Die technischen Details erspare ich euch jetzt mal… Im Kern geht es darum das sämtliche Aktivitäten im Unternehmen über Workflow-Systeme abgebildet werden.

Als die Tage vor dem obligatorischen Espresso saß und über die (systemische) Wirkung von BPM sinnierte ist mir ein interessanter Gedanke gekommen: mal angenommen alle wesentlichen Aktivitäten der Firma, der Abteilungen, der Gruppen und Teams sind über ein BPM-System/Workflows realisiert: wer hat dann eigentlich die Führung? Ich meine „Führung“ im Sinne von „ich als Leiter dieses Team entscheide darüber wer im Prinzip wann was macht. Ich delegiere, ich steuere, ich behandle Eskalationen“. Damit inbegriffen: die innere Sicht des Managers, sein Selbstverständis von sich und dem Begriff „Führung“.

All das, was man als Chef früher tun musste, werden bei einer vollwertigen Workflow-Unterstützung durch das BPM gesteuert. Das BPM entscheidet wann ein Vorgang eskaliert wird. Das BPM entscheidet wer wann welche Tätigkeiten zugeordnet bekommt. Nur das BPM hat einen vollständigen Überblick über alle Aktivitäten – die Mitarbeiter reden nicht mehr mit ihrem Chef darüber den Vorgang X erstmal beseite zu legen um auf ein Feedback zu warten. Das wird direkt im BPM – System hinterlegt.

Der Chef hat natürlich einen eigenen Zugang zum BPM-System – er kann (oder darf?) Parameter einstellen, die zur Steuerung der Mitarbeiter dienen, er kann in jeden Vorgang Einsicht nehmen, Statistiken abrufen, Vorgänge zuweisen und er muss natürlich auch die Vorgänge abarbeiten, die die Mitarbeiter eskalieren lassen. Klingt fast wie ein einfacher Mitarbeiter mit einer speziellen Rolle und daraus abgeleiteten Rechten…  Und für das BPM-System ist das genau so…

Der (systemische) Punkt für mich ist: wieviel „Chef“ bleibt vom Chef übrig? Ist die Einführung einer übergeordneten, steuernden Instanz nicht auch implizit eine Degradierung von der herkömmlichen Rolle eines „Chefs“?

Aus der Perspektive der IT-Abteilung ist dieser Gesichtspunkt ggf. relevant: je nach Unternehmenskultur und dem damit verbundenen Führungsverständnis des Managements kann die Einführung eines BPM-Systems als Angriff auf die Selbstbehauptung des Managements sein. Es kann gewisse Widerstände im Unternehmen gegen Workflows & Co erklären, oder auch erklären warum die erwarteten Benefits eine Workflow-Systems sich nicht heben lassen… weil die Mitarbeiter (oder das Management) das System aufgezwungen bekommen und es nun – ggf. unterbewusst – torpedieren…

Es gibt noch einen zweiten Aspekt: wer beherrscht das BPM-System im Sinne von Anpassungen an geänderte Rahmenbedingungen? Die IT – wer sonst? Sollte sich ein Abteilungsleiter dazu entscheiden seine Mitarbeiter-/Teamorganisation anders aufzusetzen, und er braucht dafür neue Regeln (weil sonst das BPM nicht entsprechend angepasst werden kann) dann muss er zur IT-Abteilung gehen.

Ein Gang nach Canossa weil man vergessen hat im letzten Projekt die anstehende Reorganisation mit einzuplanen?

Früher hat man die IT nur benötigt wenns um Funktionalitäten geht. Heute muss man selbst dann die IT belästigen (oder bitten) wenn man die Art und Weise, wie die Mannschaften aufgestellten werden, verändern will. Ist das nicht das letzte große freie Betätigungsfeld des Managements, dort wo es sich „beweisen“ kann: Teams und Gruppen optimal an geänderte Geschäftsbedingungen anzupassen? Ist es nicht ein massiver Eingriff ins Selbstverständnis eines echten Managers wenn er selbst das nicht mehr ohne IT-Anpassungen vornehmen kann?

Wer führt eigentlich – das Workflowsystem oder das Management?


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.