ITBlog

In einem geschlossenen System geht keine Energie verloren. Schade dass Unternehmen kein geschlossenes System sind, denn es ist erschreckend wie viel Wissen und Erfahrung in einem Unternehmen verloren gehen kann. Einer meiner Aufgaben ist die Beratung von Key Account Kunden bei komplexeren Projekten, um sicherzustellen dass Sie von unserer Erfahrung profitieren und natürlich um unsere Roadmap besser auf die Kundenbedürfnisse abzustimmen. Die Installation von Middleware ist meistens verknüpft mit Konsolidierungs- und Migrationsprojekten (in denen bestehende Anwendungen unterschiedlicher Hersteller auf eine neue Plattform zusammengefasst werden, ganz beliebt sind SAP Einführungen). Deswegen bekomme ich oft (am Rande) mit, wie schmerzhaft es sein kann in einem Unternehmen eine genaue Analyse der (Legacy) IST-Prozesse zu erstellen, oder für ein geplantes neues System die Mindestanforderungen zu definieren. Ich treffe immer wieder auf die selben Muster:

• Es werden andere (neue) Mitarbeiter mit der Umsetzung der neuen Projekte betraut. Entweder weil man den alten Hasen die neue Technologie nicht zutraut, weil die bestehende Mannschaft nicht aus dem Tagesgeschäft entlassen werden solll, oder weil die Verantwortlichkeiten schleichend neu verteilt werden sollen. Egal welchen Grund es gibt die neuen Mitarbeiter haben keine Erfahrung mit dem Gesamtproblem, und die erfahrenen Mitarbeiter haben entweder keine Motivation oder Gelegenheit mehr zu helfen.
• Die Vordenker die das alte System entworfen und vor allem weiterentwickelt haben sind nicht mehr im Unternehmen. Kleine Änderungen und Pflege wird vom Stammpersonal vorgenommen, aber keiner kann die Prozesse komplett überblicken.
• Selbst die detaillierteste Systemdokumentation kann ein System (vor allem die Überlegungen bei der Umsetzung) voll beschreiben. Und selbst wenn sie es könnte, so ist sie nicht mehr vollständig erfassbar.
• Der Teufel steckt im Detail: die Projekte sind meistens so angelegt dass keine Zeit für Fehler oder Verbesserungen eingeplant werden. Das Second System muss gleich perfekt sein, auch wenn die bestehende Anwendung über Jahrzehnte gewachsen ist. Das sind unrealistische Anforderungen, im besten Fall werden im Laufe des Projektes der Umfang der Pilotprojekte immer kleiner - und damit irgendwann machbar.
• Mitarbeiter die für die Umsetzung Hauptverantwortlich sind werden so mit Fakten und Entscheidungen überschüttet, dass Verdrängungs- und Überschätzungsmechanismen einsetzen. Das Gesamtsystem aus einer anderen Sichtweise (z.B. aus Sicht des Controllings oder des Operatings, oder des Supports, oder oder) zu betrachten wird als unnötig oder zu aufwändig angesehen. Daraus ergeben sich oft Entscheidungen die sich im späteren Betrieb als sehr ineffektiv herausstellen. Oftmals werden einfach zu wenige zentrale Rollen besetzt. Keyuser und Stakeholder aus unterschiedlichen Bereichen gibt es nicht, oder werden nicht gefördert.
• Ein weiteres Problem sind knappe Deadlines und neue Technologien. Beide führen dazu dass Unternehmen externe Berater in allen Ebenen beauftragen. Das führt zu dem Effekt, dass die Überlegungen zur Umsetzung nicht immer im Besten Interesse der Firma sind, und die gemachten Erfahrungen auch mit dem Ende des Migrationsprojektes das Unternehmen wieder verlassen. Mehrere hundert Business und Technologie Consultants sind keine Seltenheit.
• Ein Problem mit dem man fertig werden muss, ist auch die Tatsache dass die funktionierenden Prozesse nicht notwendigerweise effizient sind. Bei einer genauen Analyse werden die Schwachstellen entdeckt. Oftmals wird die Entscheidung zum Re-Engeneering aber zu leichtfertig getroffen. Der Projekt-Scope weitet sich somit aus.
• Pilotprojekte werden oft auch falsch ausgesucht: zwar ist es Sinnvoll nicht mit dem Core Business als erstes auf eine neue Plattform umzuziehen, jedoch ist das bisher manuell betriebene Business einer ausländischen Zweigstelle nicht unbedingt repräsentativ. Von den Problemen wie Zeitverschiebung, kulturelle und Sprachlichen Barrieren oder fehlende Erfahrung der Stammbelegschaft ganz zu schweigen.

Vermutlich lassen sich all diese Probleme nur bedingt vermeiden. Aber wenn man immer wieder obige Punkte vor Augen hält kann man frühzeitig gegensteuern. Zum Glück verliefen alle Projekte die ich so kenne mehr oder weniger erfolgreich. Hilfreiche waren dabei folgende Faktoren:

• Heroes die Verantwortung und Kommunikation übernehmen. Immer wieder alle Parteien an einen Tisch holen.
• Manager die Dank Sachverstand Abschätzungen hinterfragen können.
• Starke Einbindung von internen Ressourcen in allen Phasen.
• Iterative Umsetzung in kleinen Schritten.
• Die Auswahl eines Leistungsstarken und flexiblen Softwarepartners mit herausragenden Mitarbeitern (*grins*)

Amazon's Utility Computing Platform EC2 zeichnet sich durch eine einfache Skalierbarkeit aus. Für Anwender die allerdings nicht kurzfristig mehrere hundert Compute Instanzen benötigen war das Pricing nicht so attraktiv. Amazon hat nun Reserved Instances angekündigt. Kann man sich auf eine gleichmäßige Nutzung einer Instanz committen, so sinken die Nutzungspreise erheblich. Ich habe das mal (bei einer Monatsnutzng von 30*24h) hochgerechnet:

Instanz	Stundenpreis	Norm Monat	Monat 1y	Monat 3y
Small	$0,10/$0,05	$72	$48,68	$35,49
XL	$0,80/$0,24	$576	$390	$284

Das Modell scheint bisher noch nicht für die Windows Server verfügbar zu sein. Details unter EC2 Pricing. Was ich bei Amazon immer wieder gut finde ist es wie durch einfache Bezahlmodelle Anreize für ein bestimmtes Userverhalten geschaffen wird, und dies dank der Anzahl der Benutzer skaliert. Z.b. die Möglichkeit IP Addressen zu reservieren, und solange man diese nutzt sind sie kostenlos. So langsam kommt Amazon mit diesem Pricing in die Regionen von normalen V-Servern (mit dem zusätzlichen Benefit dass man jederzeit mehr Ressourcen auf Stundenbasis dazuschalten kann). Ganz konkurenzfähig sind die Server allerdings immer noch nicht - trotz Dollar Kurs.