Mi 1 Nov 2006
Investitionsschutz für CIOs – eine Lösung
Posted by andreas.mertens under IT, IT-Management, businessmärchen
[5] Comments
IT-Projekte sind bekannt dafür, dass sie gegen die Wand fahren, das doppelte bis dreifache kosten und wenn Sie überhaupt jemals erfolgreich enden, dann Jahre nach dem ursprünglich geplanten Projektende.
Beispiel:
In der Ausschreibungsphase bieten drei Dienstleister an, die in die engere Auswahl kommen, natürlich zum Festpreis. Dienstleister A geht mit einem Angebot von 2 Mio € ins Rennen, Dienstleister B mit 2,2 Mio € und Dienstleister C mit 3 Mio €. Dienstleister D ist bereits rausgeflogen, er hatte für 4 Mio € angeboten. Die Entscheidung fällt letztendlich auf Anbieter C für 3 Mio €, also die Mitte. Man möchte ja später nicht den Vorwurf hören, man hätte doch gleich den kompetenteren und seriöseren Anbieter nehmen sollen, der natürlich ein wenig mehr kostet. Trotz allem stellt sich heraus, dass das Projekt unterschätzt wurde. Unter dem Strich wird das Projekt 3-4 Mal verlängert, die IT hat einen Haufen Ärger mit dem Projekt, die ursprünglich versprochenen Funktionen wurden stark abgespeckt und man musste nocheinmal draufschlagen. Der externe Dienstleister kassierte letztendlich 5 Mio € und inkl. aller intern gebundenen Ressourcen, nochmaligen Hardware-Resizing etc. kostete das Projekt dann 9 Mio €, anstatt den ursprünglich geplanten 3 Mio €. Und richtig stabil läuft die Software immer noch nicht, zu schweigen von den fehlenden Funktionen die ursprünglich angefordert wurden.
Die Lösung
Liebe geplagte CIOs, ich biete Ihnen folgenden Deal an: Ich biete gegen jeden Konkurrenten zum halben Preis. Anstatt dem Dienstleister C 3 Mio € in den Rachen zu werfen, biete ich für 1,5 Mio € an. Was sie dafür bekommen? Ganz einfach: Nichts. Dafür haben Sie aber unter dem Strich 7,5 Mio € gespart! Sie haben keinen Ärger, wir bleiben In-Time, Under-Budget und wir sind beide glücklich. Denn jeder weiß von Anfang an ganz genau was er bekommt und was nicht. Keine Tricks und kein doppelter Boden. Ich bekomme in obigen Beispiel 1,5 Mio € und Sie einfach Nichts und Sie sparen trotzdem noch dabei.
Spass bei Seite
Woran liegt es, dass Software-Projekte so oft scheitern? Nun, so schwer ist es nicht. Ein 
grundlegender Fehler ist, dass viele Unternehmen mit einer vollkommen falschen Haltung an das Thema herangehen, nämlich der Vorstellung, Software lässt sich wie ein Auto herstellen. Das dies nicht so ist, hat auch Claude Roeltgen, CIO von Credit Suisse, festgestellt. In seinem neuen Buch “Eine Million oder ein Jahr” hält er fest:
“IT ist kein Auto, in das man sich hineinsetzt, den Zündschlüssel umdreht und Gas gibt”
Einer der wichtigsten Punkte, aus kybernetischer Sicht, ist, dass ein Auto während seines Produktlebenszyklus nicht solchen starken Veränderungen wie Software unterliegt. Hier und dort ein wenig Verschleiß, ein paar Reparaturen. Nicht aber funktionale und strukturelle Veränderungen wie bei Software. Der Software mit all seinen Nebeneffekten entspricht eher einem autopoietischen System. Software ist daher eher etwas wie ein Organismus, welche sich an seinen Umweltbedingungen, z.B. den Marktbedingungen permanent anpasst. Derzeit arbeite ich deshalb mit Ralf Westphal an einem Dialog, welcher die Zusammenhänge etwas einfacher darstellt.
Ich behaupte deshalb: Solange sich nicht grundlegend etwas an der Haltung zum Thema Software ändert und solange man nicht versteht, dass Industrialisierungsprozesse wie z.B. Fertigungsprozesse für Autos nicht auf die Entwicklung von Software übertragen werden können, werden weiterhin Millionen von Euros verbrannt.
Ein paar Links zum Thema:
Software als autopoietische Entität
Das Datenbankenland, Unternehmenspolitik und Software
Evolutionäre Organisationsstrukturen
Kybernetisches IT-Value-Management
Kybernetik im IT-Management
Projektstrukturen, Konzenstrukturen, Kybernetische Strukturen
Nachtrag (03. November 2006)
Die Kybernetik hat wieder einmal durch Rückkopplung gewirkt. Claude Roelten hat mich gerade via E-Mail kontaktiert. Daraufhin bin ich auf Seine Seite zum Buch aufmerksam geworden:
http://www.einemillionodereinjahr.info
sowie eine Veröffentlichung im Luxemburger Wort, diesen Artikel kann man hier herunterladen.
November 1st, 2006 at 08:15
Lieber Andreas,
liebe Mitleser(innen)
Zustimmung und Widerspruch zugleich. Das grosse Problem bei der Softwareerstellung ist meiner Erfahrung nach, dass Design und Fertigung nicht wirklich gut getrennt sind und das professionelle Fertigungsprozesse, also das vollautomatisierte erstellen von Codes nach Designvorlage und hinreichend vollständige Simulationsmodelle vor Start der Softwareerstellung ( Fertigung ), eigentlich noch gar nicht existieren.
Jeder weiss, daß Änderungen in der Schlussphase eines Automotiventwicklungszyklus irrsinnig teuer sind und man versucht sie daher zu vermeiden und zu sanktionieren. In der Softwareentwicklung/Implementierung scheint es manchmal gar keinen Closingdate für Changes zu geben. Oder sagen wir es anders, die Budgetverantwortlichen handeln höchst unverantwortlich. Hier wird unbekümmert und blind für die finanziellen Auswirkungen agiert, nach dem Motto, das kann man ja mal eben umschreiben. KVP kann eben auch falsch verstanden werden. Wie gesagt, Alles kein Problem, solange man noch und ausschließlich im Design- und Simulationszustand ist, aber extrem teuer, wenn die Produktion ( Codeerstellung ) schon gestartet ist.
Die Pläne, für eine völlig neuartige Softwarefabrik, die nach den Prinzipien vollständiger Modellierung/Simulation und der Fließbandfertigung arbeiten kann, gibt es übrigens schon ein paar Jahre. Allerdings hat sich bisher noch keiner gefunden, der bereit gewesen wäre, die dafür notwendigen Investitionsmittel von 50-80Mio. Euro in die Hand zu nehmen. Das Leiden, auch bei den grossen Softwarefirmen ist offensichtlich immer noch nicht gross genug, obwohl inzwischen sicher das Hunderfache in vermeidbare Projektverlängerungen investiert wurde. Das ist der Preis den wir zahlen, weil man der Überzeugung ist, Softwareprogrammierung sei Kunst … Kunst ist aber nur das Softwaredesign und Können, die Grenze zur Fertigung zu erkennen.
Sometimes, the world is really crazy !
November 1st, 2006 at 09:04
Kostet es aber in der Entwicklungsphase eines Autos nicht auch mitunter Millionen bis man eines in den Autosalons wie Genf oder auf der IAA stehen hat und dann werden die “Concept Cars” einfach eingestampft ?!
Ich denke wenn mal alle Module eines Systems entwickelt wurden und ein HowTo für die Installation / den Betrieb steht, dann kann man das mit der Montage eines Autos vergleichen, ansonsten sind doch Automobile während der Entwicklung neuer Automodelle auch ständigen Änderungen unterworfen.
Gruss aus Zürich,
Francesco
November 1st, 2006 at 11:14
Offenbar habe ich den Finger in eine offene Wunde gelegt :-) Die Reaktionen zeigen den Bedarf des Austauschs, was mich außerordentlich freut. Bezüglich der “sauberen” Trennung zwischen Designphase und Fertigungsphase möchte ich etwas aus meiner Erfahrung erzählen:
(1) Zeitliche Komplexität
(2) Politik, Werte und Ziele
Zeitliche Komplexität
In größeren Projekten sehe ich hier ein zeitliches Problem. Beansprucht die Designphase mehr Zeit, weil man sie genau, exakt, eben so durchführen möchte, dass die Wahrscheinlichkeit von Changes während des Fertigungsprozesses (das Codieren) minimiert werden, dann ist meine Erfahrung, dass die Designphase in komplexen Umfeldern und Organisationen einfach zu lang dauert. Das Schlimme daran: die Veränderungszyklen, die sich durch Anforderungen des Marktes ergeben , können kürzer sein als die Dauer einer Designphase (!). Oder anders: Wenn es zur Fertigung kommt, ist die Software schon wieder veraltet. Wie gestaltet man also die Software und den Softwareentwicklungsprozess so, dass die Software zeitnah anpassungsfähig ist? Natürlich sind die Marktveränderungszyklen auch branchenabhängig, eine sehr “lebhafte” Branche ist z.B. die Telekommunikationsbranche (Technologien, Tarife, Endgeräte, ….). Aus meiner Sicht wäre es clever, als Unternehmen den Markt selbst so zu gestalten und im “Griff” zu haben, dass man dies im Einklang mit dem Change-Management fährt.
Politik, Werte und Ziele
Für mich ist die Unternehmenspolitik, welche durch Werte und Ziele der einzelnen Mitarbeiter getrieben wird, ein wesentlicher Faktor, der Softwareentwicklungsprozesse und Projekte verzögern. Die Message die ich hier rüberbringen will ist: Es reicht nicht nur auf den Softwareentwicklungsprozess zu schauen, sondern auch auf die Menschen, die diesen durchführen. Und hier kommen wir dann wieder auf komplexe soziale Systeme, Kybernetik und gar auf autopietische Systeme.
November 26th, 2007 at 13:59
Ich moechte mich fuer die guten Infos bedanken und hoffe du wirst weiterhin so qualitative Beitraege schreiben. Falls du was ber
Dezember 21st, 2007 at 21:16
Also ich bin wirklich erstaunt, habe selten so einen Informativen Blog gefunden.