“Transforming Business into E-Business”.

Heute, 8 Jahre später, so könnte man meinen, ist ja schon alles “transformed” und die Oldeconomy’s dieser Welt haben ihre E-Bussines-Prozesse fest im Griff. Wie man es eben von E-Bay und Amazon gewohnt ist. Pustekuchen. Vor über 7 Tagen habe ich in so einem “Oldeconomy-Laden – eine große deutsche Warenhauskette” die in jeder Metropole vertreten ist – über das Internet bestellt. Ohne Worte! Hier eine Summary:

• Der Shop ist das Letzte
• Die verkaufen dort Ware, die nicht lieferbar ist
• Die Workflows sind grausig designed
• kein Tracking-System
• die Hotline ist nicht gerade kompetent, kostet über eine 0189er Nummer noch Geld und die Callcenter-Agenten mussten meine Auftragsnummer dreimal angeben, bevor Sie meine Bestellung auf dem Schirm hatten
• Auf die Frage, ob ich den Status der Bestellung auch im Web anschauen könnte, hieß es: “Ja klar können Sie das”. Als ich fragte wo denn im Internet, weil ich habe es zuvor nicht gefunden hatte (sonst hätte ich nämlich nicht die Hotline angerufen), antwortete der CallCenterAgent: “Das weiß ich auch nicht! Wir haben hier ein anderes System im Backend.”

Danke und nie wieder. Die ganze Abfrage hat mich wahrscheinlich auch noch ein Euro gekostet, um zu erfahren das eine große deutsche Warenhauskette ihre E-Businessprozesse nicht im Griff haben. Dann kaufe ich doch lieber bei der New Economy ein. Da funktioniert es eben einfach. Aber ein Versuch war es wert.

Nachtrag: In jedem Schlechtem gibt es ja auch was Gutes: Das Gute ist, dass “Transforming Business into E-Business” weitergeht und es einen weiteren bereich gibt. Bisher gab es ja das BPO (Business Process Optimization) … What about EBPO ?

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.

IT-Projekte sind ein Desaster. Wer die “Scene” kennt, kennt auch Bilder wie diese auf der linken Seite. Dieses Bild stammt von den Seiten Herrn Meisl. Das Schlimme daran ist, das es stimmt. Wer tiefe Einsichten in das IT-Geschäft hat, also ganz unten im operativen Bereich arbeitet und gearbeitet hat und auch die Sicht von ganz oben kennt, der weiß um diese Dinge. Ich vermute nur, das es nicht allzuviel von diesem Menschen gibt, sonst müsste die IT-Welt eigentlich anders sein. Auf der anderen Seite stellt sich die Frage, ob man die Probleme tatsächlich lösen möchte. Schließlich sichert die Komplexität der IT und das Chaos Arbeitsplätze !

Die steigende Varietät von komplexen Systemen und Technologien, hier speziell IT-Systeme, fordern immer höhere Projektmanagement- und Teamkommunikationsfähigkeiten. Dieser Artikel beschäftigt sich mit den Schwierigkeiten, die sich aus der Praxis ergeben und zeigt auf, das wir vor einem Paradigmenwechsel stehen, der erforderlich ist, um künftig erfolgreich Projekte abzuwickeln.

Industriealisierbarkeit von Wissensarbeit

Heute möchte man komplexe Projekte strukturiert, am Liebsten nach Standardprozessen und Vorgehensweisen, abwickeln. Der Wunsch dahinter ist, diese Projekte kontrolliert zu planen. Mir stellt sich oft die Frage, ob man hier nicht zwanghaft versucht, die Automatisierung von Produktionsprozessen aus der Industriaisierung auf die Automatisierung von Entwicklungsprozessen in der Informationsgesellschaft zu übertragen. Ich stelle mir immer öfter die Frage, ob dies überhaupt möglich ist? Die Automatisierung von Fertigungsprozessen ist einfach etwas anderes, als die Automatisierung von Entwicklungsprozessen, die durch Wissensarbeiter abgearbeitet werden. Wir haben es hier nicht nur mit hochkomplexen inhaltlichen Sachverhalten zu tun, sondern auch die Arbeit selbst, die “Wissensarbeit” ist hochkomplex. Es ist einfach ein Unterschied, ob ich im Fertigungsprozess einen Arbeitsschritt vollziehe, wie z.B. das Kontrollieren und Seuern eines Lackierroboters, oder ob ich im Softwareentwicklungsprozess einen Arbeitsschritt vollziehe, wie das Aufnehmen komplexer Anforderungen. Hier spielen u.a. Sprache, Kommunikationsfähigkeit, Unternehmenspolitik, komplexe fachabteilungsübergreifende Prozesse, Ziele und Werte meines Gegenübers eine entscheidende Rolle (!). Ich bin mir sicher, das herkömmliche Projektstrukturen ausgedient haben und durch einen Paradigmenwechsel langfristig abgelöst werden.

Projektkommunikation und Struktur

Ich habe IT-Projekte erlebt, in den man mit weniger Teammitgliedern mehr erreicht hat, als in Projekten mit mehr Teammitgliedern bei gleicher Produktkomplexität. Ich habe “aufgeblasene Projekte” erlebt, bei den es mehr “Häuptlinge” als “Indianer” gab, die weniger geleistet haben, aber das 10fache gekostet haben. Projekte haben ja ihren Sinn. Aus der Linie, aus der Hierarchie herausgelöst, sind komplexe Aufgaben ja nur als Projektform realisierbar. Meine Erfahrung einer idealen Größe eines Projektteams, welche komplexe Aufgabenstellungen zu lösen hat, liegt bei 6-9 Mitgliedern. Diese Teamgröße ergibt sich aus einer simplen Formel, nämlich der Anzahl von p Kommunikationsstränge bei n Teammitgliedern, die sich aus der Formel p = n*(n-1)/2 Kommunikationsstränge ergeben. Hier haben wir es mit einer ganz einfachen Sache zu tun, je mehr Leute im Projekt, desto mehr Abstimmungsbedarf. Das ist einleuchtend, aber und zwar ein GROSSES ABER: vielen Projektmanagern scheint die Auswirkung des klitzekleinen, unscheinbaren mathematischen Quadrates nicht klar zu sein. Geprägt von linearen und trivialisierten denken, ist hier eher folgende Denkweise anzutreffen: Wenn wir die Entwicklerressourcen verdoppeln, dann sind wir in der Hälfte der Zeit fertig.

Projektstruktur und Komplexität

Diese 6-9 Experten können eine gewissen Komplexität bearbeiten. Dies funktioniert ganz gut. Ist die zu bearbeitende Komplexität größer als die 6-9 Mitglieder bearbeiten können, dann machen wir häufig einen entscheidenden Fehler. Wir organisieren Teilprojekte, die zusammengefasst werden und organisieren diese hierarchisch! Meiner Meinung nach liegt hier der entscheidende Punkt. Man verlangt dann von einem Teilprojektleiter, das er die Komplexität des Teilprojektes seiner 6-9 Mitarbeitern so verdichten und abstrahieren kann, das er dies an den übergeordneten Projektleiter kommunizieren kann. Angenommen wir haben nur ein kleines Projekt, welches aus 2 Teilprojekten besteht, 6-9 Teammitgliedern pro Teilprojekt, je einen Teilprojektleiter pro Team und einen Gesamtprojektleiter. Dann fließt die gesamte Varietät von 12 bis 18 Menschen verdichtet über nur 2 Kommunikationsstränge nach oben. Meine Erfahrung: schon das funktioniert nicht. Ich selbst habe erlebt, das zwei solcher Teilprojekte auf einem Raum von 60 Quadratmetern Softwaremodule redundant programmiert haben. Künftig werden deshalb größere Projektstrukturen kybernetisch organisiert werden müssen, sodaß zwei Teilprojekte nicht hierarchisch vernetzt werden sondern kybernetisch, z.B. anhand von drei- oder vierdimensionalen Strukturen. (Siehe auch Stafford Beer¹ oder den Hyperkubus.

Eine weitere Veränderung kann man vornehmen, wie die Informationen zwischen den Teilprojekten ausgetauscht werden (zeitlich, räumlich, organisiert). Interessant wäre hier eine Struktur die sich selbst erzeugt bzw. reproduziert und dabei die Anzahl der Projektmitglieder vergrößert, gemäß einer Kybernetik 2. Ordnung.

Paradigmenwechsel

Die sich erhöhende Komplexität und die steigende Geschwindigkeit am Markt, erfordert diesen Paradigmenwechsel. Kleinere Unternehmen können damit problemlos umgehen. Konzerne werden damit ihre Probleme haben. Derzeit versuchen die Großen die Kleinen zu schlucken. Aufgrund ihrer Flinkheit aber, lassen sich manche Kleine nicht fressen. Diese kleinen “ebays, Amazons und Googles” werden schnell groß. Und: Wenn sich nicht vergessen und verlernt haben, warum sie nicht gefressen wurden, nämlich weil Sie flink waren, dann haben Sie eine große Chance diese Eigenschaft beizubehalten. Diese Unternehmen sind dann groß und flink. Eine andere Perspektive wäre die Anwendung der Kybernetik auf einen Konzern, um ihn gegen schnelle Marktveränderungen resistent zu machen.

IT-Offshoring und IT-Outsourcing

Hinter obigen Punkten ist deshalb zu bedenken, ob man es mit industrialisierbaren Wissensprodukten hat oder nicht. Häufig wird versucht, die Herstellung nicht oder schwer industrialisierbarer Wissensprodukte z.B. nach Indien durch Offshoring auszulagern. Die Folge: unterm’ Strich höhere Kosten durch entsprechenden Management- und Kommunikationsoverhead. Indische Briefkastenfirmen könnten ein Globalisierungseffekt sein (!)

Universalist und Generalist vs. Spezialist

Gutausgebildete Generalisten mit Tiefgang und hohen Kommunikationsfähigkeiten werden künftig benötigt, um Schnittstellenpositionen zu besetzten, die Teilprojekte miteinander vernetzen. Spezialisten sind bei komplexen Produkten notwendig, diese müssen aber auch permanent ihr Spezialistenwissen anpassen bei den marktbedingten kurzen Produktlebenszyklen. Wer auf Spezialistentum “hängenbleibt” kann schnell den Zug verpassen und abgehängt werden. Somit müssen auch Spezialisten “über den Tellerrand” hinausschauen. Letztlich ist die Spezialisierung aus der Sicht eines Generalisten eine Trivialisierung, da ein Spezialist den Fokus verengt.

Zusammenfassung

Ich glaube wir gehen einer spannenden Zeit entgegen und befinden uns bereits in der Phase eines Umbruchs zu neuen Paradigmen. Schaut man sich virtuelle fraktale Organisationsformen an, wie z.B. einige äußerst erfolgreiche OpenSource-Gemeinden, dann muss man sich fragen, wie ein Haufen chaotischer virtuell miteinander vernetzter Menschen in der Lage sind professionell qualitativ hochwertige Software zu entwickeln. Für Großkonzerne ist und wird es eine Herausforderung bleiben, solche innovativen Strukturen zu adaptieren.

Links: