[sage] ITIL, ISO9000 et al. (was: Re: Warum ich keine Bandlaufwerke mag)

[Helmut Springer]

Hi,


On 27 Sep 2010 at 14:51 +0200, Benedikt Stockebrand wrote:
> >> Sorry, ist wirklich nicht böse gemeint, aber ITIL, ISO9000 und
> >> wie sie alle heißen führen oft genug zu solchen Entwicklungen,
> >> wenn man diesem Phänomen nicht aktiv entgegenwirkt.
> >
> > Das gilt so pauschal fuer jede Art der umfaenglichen
> > Dokumentation.
> 
> nein, nicht unbedingt:

Ich sehe in...

> Das Problem tritt erst auf, wenn die Befürchtung besteht, dass
> Dokumentation "gegen einen verwendet werden kann" oder sonstwie
> als Machtinstrument missbraucht wird.

...keinen Widerspruch zum, uebrigens von Dir, oben gesagten.


> Leider kann man in Umgebungen ab einer gewissen Größe seine Arbeit
> nicht mehr vernünftig machen, wenn es keine Dokumentation,
> Prozesse etc. gibt.

Der limitierende Faktor ist mE Komplexitaet, nicht nur reine Groesse.

Und mEn haben gerade kleine hochkomplexe Umgebungen sehr starke
Prozesse...allerdings oft im unbewussten common understanding der
eng verbunden Handelnden verankert, nicht in formalisierter
Dokumentation.


> Ich habe durch die Workshops ein paar Umgebungen erlebt, die
> einerseits sehr wohl extrem strukturiert -- ob nun nach ITIL,
> ISO9000 oder gesundem Menschenverstand -- gearbeitet haben, aber
> andererseits genau diese Probleme mit Schuldzuweisungen und
> Machtkämpfen einfach nicht aufkam.

Ich sehe schlicht keine Kausalitaet zwischen Prozessdefinitionen
und derartigen Problemen.  Weder logisch, noch in meiner Erfahrung.

Uebrigens lassen sich mEn die Strukturierungen nach "gesundem
Menschenverstand" idR problemlos in ITIL oder ISO9000 ausdruecken,
wenn sie hinreichend konsistent sind.  Da einen Widerspruch
konstruieren zu wollen deutet mE schon auf ein Missverstehen der
Standards hin: die sind keine umzusetzende Alternative, die sind ein
Framework zum Umsetzen der eigenen Vorstellungen und Beduerfnisse.
Setzt offensichtlich voraus, die eigenen Vorstellungen und
Beduerfnisse zu erfassen...


> Die Standards ignorieren meines Wissens dieses Problem (und ein
> paar andere obendrauf) oder widmen ihnen zumindest nicht den
> Stellenwert, der ihnen nach den vorliegenden Erfahrungen
> eigentlich zukommen müsste

ITIL, ISO9000 u.ae. sind jeweils best practises fuer einen
definierten (Teil)Bereich, sie stellen keine vollumfaenglichen
Handlungsleitfaeden fuer den Geschaeftsbetrieb dar.  Die Einfuehrung
derartiger Standards hilft uU bei der Etablierung eines effizienten
wie effektiven Geschaeftsbetriebs, ist aber weder notwendig (man
kann alles anders machen) noch hinreichend (man muss noch eine ganze
Menge mehr machen) dafuer.

Du beantwortest das weiter unten mE selber...

> Andererseits liefern die Standards den Nährboden für genau diese
> Probleme, wie man sie bei den Implementierungen immer wieder
> erlebt.

Fuer jede andere Form der Organisation gilt das gleiche.  Standards
sind lediglich standardisierte Werkzeuge.

 
> Die wesentliche Frage ist in meinen Augen, vor allem in wachsenden
> Umgebungen, wie man sich die Standards sinnvoll zunutze macht, ohne
> dabei in genau diese Probleme hineinzulaufen.  Und das ist eine Frage,
> die erstens nichttrivial ist, zweitens zum guten Teil nur individuell
> zu beantworten ist und drittens oft genug massiv unterschätzt wird.

Korrekt.  Und die von den Standards voellig unabhaengig ist, denn
sie gilt fuer jede Organisationsform.  Wie gesagt: diese Standards
sind lediglich standardisierte und generalisierte Werkzeuge und best
practises.  Die Vorstellung, man koenne die einfach nach Handbuch
implementieren und alles wird gut ist so verbreitet wie irrig.
Eigentlich eine der Unix toolbox sehr aehnliche Denkweise: tool.1
erklaert das tool, nicht die Umstaende seine Einsatzes.

Man kann natuerlich einen vollumfaenglichen Standard entwerfen, das
ist dann mehr oder weniger das Portfolio einer hinreichend
kompetenten Unternehmensberatung.  Man sollte auch nicht uebersehen,
dass Standards oft von Beratern und Zertifizierern (mit)erarbeitet
werden.  Von daher sollte es niemanden ueberraschen, wenn sie genug
Raum fuer entsprechende Dienstleistungen lassen    8)


> Wenn dieser Punkt erreicht ist, dann ist es meiner Meinung und auf
> Basis meiner persönlichen Erfahrungen wichtiger, überhaupt erstmal
> eine konstruktive Zusammenarbeit zwischen Technikern und
> Nicht-Technikern (ob nun Managment, End User oder was auch immer)
> wiederherzustellen, statt Prozesse festzulegen oder Dokumentationen
> und Konzepte zu schreiben.

Das eine ist kein Widerspruch zu dem anderen.  Alleine die Einigung
auf definierte und gleichverstandene Begriffe ist sowohl Grundlage
der Zusammenarbeit wie auch Prozessdefinition.

Die mir bekannten Standard setzen voraus, dass es diese
Zusammenarbeit gibt und ein funktionierendes Technik-Mgmt agiert,
teilweise sogar explizit.


> Dummerweise ist es einfacher, Papier zu bearbeiten und dann --
> dank offizieller Zertifizierung -- so zu tun, als ob damit die
> Probleme gelöst wären.

D'accord.  Allerdings ist Zertifizierung nochmal ganz etwas anderes
als Prozessimplementierung...


> Umgekehrt ist es ähnlich faszinierend, wie bei manchen(!) Managern
> mit kaufmännischem Hintergrund keinerlei Rücksicht auf elementare
> Grundrechenarten genommen wird und offensichtlicher kaufmännischer
> Pfusch als "Management-Entscheidung" kaschiert und bis zum
> Rausschmiss (des Managers) oder Konkurs fortgeführt wird.

D'accord, aber das hier ist ja eher keine Gruppe von Managern mit
kaufmaennischem Hintergrund   8)


Cheers
helmut

-- 
Best Regards
helmut springer                                           panta rhei