Schlagwort-Archive: Aufwand

Die törichte Sonne und der hochmütige Mond

Als Beispiel für eine Learning Story möchte ich das Problem eines kleinen, handlichen Projekts in eine Fabel fassen. Ich kann hier leider nicht näher auf die Projektumstände eingehen, weil es möglicherweise nicht im Sinne der Parteien sein könnte, wenn ich das noch nicht ganz beendete Projekt in die Öffentlichkeit trage. Das ist aber weiter auch nicht nötig, denn eine Learning Story soll ja eben eine Lehre enthalten, die immer wieder auf Projekte angewendet werden kann.

Als die aufsteigende Sonne einmal auf den Mond traf, der sich ebenfalls (noch) am Morgenhimmel tummelte, da dachte sie, wie angenehm es sein müsse, so cool und ruhig zu sein, wie es der Mond ist. Sie war ja ständig am brodeln und litt manchmal etwas unter ihrem inneren Feuer. Da begann sie, den Mond zu loben, wie schön sein Silberschein sei, und dass sie viel darum gäbe, wenn sie dieses Silber einmal für eine kurze Zeit ausprobieren dürfte. Der Mond war geschmeichelt und überlegte sich, dass vielleicht ein wenig vom Glanz und der Grösse der Sonne an ihn abfallen möge, wenn er der Sonne den Gefallen tut und ihr vorübergehend einen Teil seines Silberscheins gibt. Also beredete er mit der Sonne die Einzelheiten der Übergabe. Doch kaum war das bisschen kühlen Silberscheins, das der Mond abtreten konnte, auf der Sonne angekommen, verpuffte er und wurde von der Hitze und dem gleissenden Licht aufgezehrt. Die Sonne verlor nichts. Der Mond jedoch hat seinen noblen Silberschein eingebüsst und zeigt sich von da an mit vielen Flecken.

Wenn Du etwas a fonds perdu investierst in der Hoffnung, dass es Früchte tragen mag, dann solltest Du genau abklären, welche Möglichkeiten überhaupt bestehen (sollte eigentlich klar sein….). Nicht nur der Mond musste an der Abklärung interessiert sein. Die Sonne hätte sich ebenfalls fragen müssen, ob ihr Wunsch nach Kühle – auch nur probehalber – erfüllbar sein kann. Denn auch die Sonne hatte natürlich Aufwand. Und so schnell muss sie vom Mond nichts mehr erwarten. Zudem werden sich der törichte Wunsch der Sonne und die hochmütigen Gedanken des Mondes am Himmel schnell herum sprechen und nicht gerade zu ihrem Image beitragen.

Die Reduktion des Hauptproblems des Projekts auf das Allerwesentlichtste und das Finden einer passenden Geschichte, welche kurz und einprägsam das Problem chiffriert, sind zwei Schwierigkeiten, die nicht zu unterschätzen sind. Obwohl das Hauptproblem offenkundig war, war es noch lange nicht klar, welche Elemente wie in einer Geschichte abgebildet werden können. Z. B. lassen die Archetypen, aus denen Geschichten aufgebaut sind, kaum einen Zugang zum Begriff „Unternehmensstruktur“. Natürlich kann man mit König, Prinz, Grafen und Lakaien eine Hirarchie abbilden, aber dennoch lassen sich nicht alle Aspekte einer Unternehmensstruktur ausleuchten. Die Transformation „Projektgeschichten, wie sie die Projektmitarbeiter erzählen —> Integration —> Reduktion auf das Wesentliche —> Learning Story (Fabel, Metapher, Allegorie, Märchen, Witz)“ erfordert Kreativität und Talent.

Jede Anwenderumgebung verhält sich anders

Migrations- und Integrationsprojekte (MIP) sind deshalb so schwierig, weil sie von lokalen Integratoren durchgeführt werden, die nur beschränkte Produkte- und Engineeringwissen haben können. Sie nehmen Produkte aus dem eigenen Konzern oder von Drittanbieteren und integrieren diese in den Umgebungen der Auftraggeber. Da die Produkte proprietär sind, kann der Integrator von den Produkteinternals nur beschränkt Kenntnisse haben. Damit fehlen ihm fast sämtliche Hebeln.

Wenn das Produkteverhalten nicht den Erwartungen entspricht, kann häufig nur der Hersteller sagen, ob es sich um einen Produktefehler oder um einen Installations- oder Bedienungsfehler handelt. Da aber die Experten beim Hersteller ebenfalls rar sind, kann das Projekt unter Umständen lange warten, bis schlüssige Informationen vorliegen. Der lokale Integrator ist jedoch der Geschäftspartner des Kunden, so dass sich dieser nicht interessiert, ob der Hersteller Zeit und Lust hat, das Projekt zu supporten. Nicht selten führt dieser Umstand zur völligen Erosion der Marge des Integrators.

Gibt es das nur in der IT? Auch im Bauwesen sind Integratoren am Werk. Ein Fensterlieferant oder ein Bauschlosser müssen Teilgewerke in einem Hauptgewerk intergrieren. Auch sie haben die Produkte vielleicht nicht selber gemacht, sondern von einem Lieferanten eingekauft und an die projektspezifischen Gegebenheiten angepasst. Dabei könnte es sich durchaus auch zeigen, dass die Produkte Mängel haben, die eine Integration an Hauptgewerk beinahe verunmöglichen. Aber ein grosser Unterschied besteht gegenüber der IT. Die Subsysteme im Bauwesen sind statisch, während sie in der IT ein Laufzeitverhalten aufweisen, das Unbestimmtheit über die eigentliche Installation hinaus mit sich bringt.
Neue Subsysteme verhalten sich fast immer instabil bei der Integration in spezielle Kundenumgebungen, auch wenn sie die Entwicklungstests (Factory Acceptance Tests) bestanden haben. Aber jede Kundenumgebung ist anders. Die Firma mValet hat 2007 eine Umfrage unter 10 der Fortune 500 IT-Anwendern durchgeführt, um tieferen Einblick in die versteckten Kosten von Migrationsprojekten zu erhalten.

Fazit:

Frequent inconsistencies and errors in so-called „environmental variables“ – applications that work in development experience difficulties when promoted into QA or other pre-production phases owing primarily to environmental differences (e.g., configuration settings of application infrastructure components being out of sync)1.

Die vielen Fehler und Instabilitäten, die während der Integration auftauchen, verlangen eine minutiöse Analyse und Reproduktion im Labor des Integrators. Er muss die Fehler genau dokumentieren, bevor er sie an den Hersteller oder ins Entwicklungscenter weiter geben kann. Ohne detaillierte Dokumentation des Fehlers, hören die Entwickler gar nicht erst zu. mValet schreibt dazu:

High change rates for applications in pre-production phases – these changes contribute to system instability and extended troubleshooting efforts which result in scheduling delays. Extensive analysis that wastes hours and days of IT staff time is required to diagnose and remediate the configuration setting differences that cause this issue1.

mValet errechnete, dass die Migrationsprojekte pro befragtem Unternehmen einen Anteil an den direkten Lohnkosten von zwischen 500 und 800 Tausend Dollars jährlich verschlingt. Eigentlich unverständlich, warum sich die Literatur vor allem auf Entwicklungsprojekte fokussiert, wo doch MIP viel mehr Unbestimmtheit aufweisen!

1mValet. Large Application Migration Projects Consume Significant and Consistent Hidden Costs. Business Wire 2007-12-12