Schlagwort-Archive: MIP

Wasch mir den Pelz, aber mach‘ mich nicht nass

Migrations- und Integrationsprojekte (MIP) sind immer auch Veränderungsprojekte. Jedes System widersteht aber Veränderungen, wie wir schon bei der Bildung der Bénard-Zellen gesehen hatten. Ein grosses Problem bei der Durchführung von MIP ist die Tatsache, dass man ihr Veränderungspotential unterschätzt. Es ist allgemein anerkannt, dass ein Organisationsentwicklungsprojekt selbstreferentiell ist und daher ein grosses Veränderungsmoment entwickelt. Bei MIP denkt man, es gehe „bloss“ um die Integrierung eines technischen Subsystems, also von ein bisschen Blech und paar gespeicherten Daten oder gar „nur“ um die Migration einer bereits im Einsatz stehenden technischen Apparatur. „Störungen“, wie sie durch MIP hervorgerufen werden, können in komplexen Organisationen jedoch grosse Probleme nach sich ziehen. Komplexität zeichnet sich durch eine hochentwickelte Differenzierung des Systems aus und daher durch eine gewisse Inkohärenz in Bezug auf

  • Interpretation von Unternehmenszielen durch einzelne Abteilungen
  • Aufeinander bezogene Handlungszusammenhänge
  • Partikuläre Interessen
  • Homogenität, bzw. Heterogenität der Datenbestände
  • Flexibel definierte Aufgaben1

In einem MIP werden diese Inkohärenzen manifest und stellen die Organisation in ihrem bisherigen Funktionieren mehr oder weniger global in Frage. Auch ein sehr lokales Projekt kann weite Wellen schlagen. So habe ich mehrmals eine Migration eines sehr begrenzten Subsystems begleitet, die bei einem für den Gesamtkonzern des Lieferanten relativ unbedeutenden Kunden durchgeführt werden musste. Dennoch waren von der Entwicklung über das Produktmarketing und die weltweite Rollout-Abteilung bis zur lokalen Handelsgesellschaft mehrere Organisationsbereiche betroffen. Eskalationen des Kunden erschütterten jeweils ganze Managementketten quer durch das Lieferantenunternehmen.
Man kann davon ausgehen, dass sich technischer und organisatorischer Wandel im Fall einer Integration von Informationstechnologien in die Prozesslandschaft einer Organisation nicht trennen lassen1. Trotzdem verliert sich das Bewusstsein dieser Verknüpfung im Zuge der Konzeptrealisierung immer mehr, so dass es bei der Planung letzen Endes jeweils nur noch um Technik geht2. Meiner Meinung nach sollten Projektleiter von MIP weniger Engineers sein als vielmehr Systemiker. Das hat auch eine Bedeutung für die Curricula von Ausbildungsstätten für Wirtschaftsinformatiker. Diese sind in der Regel viel zu techniklastig, haben aber wenig Ahnung von systemdynamischen Zusammenhängen, wie sie in diesem Blog dargeboten werden. Zwar wissen unsere Wirtschaftsinformatiker wie man mit dem Chinesischen Restsatz Daten verschlüsselt, aber wie das Gehirn eines Projektleiters funktioniert oder welche unterschiedlichen Verzögerungen es in MIP geben kann, weiss selten einer. Auch Institute, die dedizierte Projektmanagementausbildungen anbieten sowie die bekannten Zertifizierer, wie IPMA oder PMI, beziehen den Projektmanagementprozess fast ausschliesslich auf die Lösung technischer Fragen. Sogar in einem Kapitel zum Thema „Kommunikation“ werden vor allem Fragen behandelt, in denen es darum geht, wie man über die technische Lösung kommunizieren soll. Zwar haben Lullies et al. schon 1990 darauf hingewiesen, dass bei verschiedenen Stellen verschiedene Vorstellungen, Ideen und Perspektiven zu einem Planungsthema bestehen und MIP stets Machtpositionen zur Disposition stellen, aber Verfahren fehlen, um unterschiedliche Sichtweisen zu integrieren2. Dass es sich dabei nicht nur um ein Kommunikationsproblem handelt, sondern dass es letztendlich um unbewusste Denkfallen und archetypische Handlungsmuster geht, die unter Umständen schlecht an den Komplexitätsgrad eines MIP angepasst sind, wird in den gegenwärtigen Curricula nicht thematisiert. Solange das so bleibt, werden MIP unter dem Motto „Wasch mir den Pelz aber mach‘ mich nicht nass“ durchgeführt, und die Zahlen im Chaos Report der Standish Group werden sich kaum zum Besseren entwickeln (s. Migrations- und Integrationsprojekte sind anders).

1Hans-Dieter Burkhard und Werner Rammert. Integration kooperationsfähiger Agenten in komplexen Organisationen. Technical University Technology Studies Working Papers. Institute for Social Sciences. Berlin 2000
2V. Lullies, H. Bollinger, F. Weltz. Konfliktfeld Informationstechnik – Innovation als Managementproblem. Campusverlag, Frankfurt a.M. 1990

Migrations- und Integrationsprojekte sind anders

Der Standish Chaos Report erscheint seit 1994 alle zwei Jahre. Er beruht auf einer Umfrage unter mehr als 300 amerikanischen Entwicklungsunternehmen und untersucht über 8000 Projekte. Aus der Reihe der bisher erschienenen Reports geht hervor, dass der Anteil erfolgreicher Projekte bei ungefähr 28% konstant blieb, während der Anteil derjenigen Projekte, bei denen der Kosten- oder Zeitrahmen beträchtlich gesprengt wurde, zu Lasten der abgebrochenen Projekte konstant angewachsen ist. Aber es handelt sich ausschliesslich um Softwareentwicklungsprojekte. Als Grund, dass immer weniger Projekte abgebrochen werden, wird die Anwendung formaler Methoden angegeben1. Aber trotz dieser formalen Methoden – was immer das für welche sind – schiessen doch um 70% aller betrachteten Projekte an den Zielen vorbei. Als wichtiger Grund für das Scheitern von Entwicklungsprojekten ist die ungenügende Benutzereinbindung genannt. Wie soll denn das geschehen? Wie soll z. B. Microsoft die hunderten von Millionen Benutzer einbeziehen, die auf der ganzen Welt verstreut sind und in verschiedenen Kulturkreisen leben? Erhöhte Komplexität aufgrund der Globalisierung lässt grüssen. Microsoft kann nicht einmal ein signifikantes Sample von Benutzern begrüssen, das ist schlicht unmöglich. Selbstverständlich gehört eine tiefgehende Marktuntersuchung allem voran, aber von einer Benutzereinbindung kann keine Rede sein. Oder wie soll ein Hersteller von Telekommunikations- oder Bankenlösungen die Benutzer einbeziehen? Benutzer sind nämlich nicht die Betreiber, die die Lösungen kaufen und bezahlen, sondern deren ihre Kunden, also die vielen Millionen Endkunden, die telefonieren oder via E-Banking ihre Zahlungen machen.

Interessanterweise werden in der Literatur fast ausschliesslich Softwareentwicklungen untersucht, wenn es um IT-Projekte geht. Andere IT-Projekte werden eher stiefmütterlich behandelt. Dabei sollten doch auf ein Entwicklungsprojekt mehrere Dutzend Migrations- und Integrationsprojekte (MIP) folgen, denn schliesslich möchte man ja auch ausrollen, was man einmal mühsam entwickelt hat. Warum denn MIP in der Literatur ein derart steifmütterliches Dasein fristen, kann ich nicht verstehen. Es ist zu befürchten, dass sich die Zertifizierer, wie PMI und IPMA, und auch andere Herausgeber formaler Projektmanagementmethoden, an den Gegebenheiten von Entwicklungsprojekten orientieren. Aber die viel zahlreicheren MIP gehorchen anderen Gesetzen. Der mangelnde Einbezug des Kunden ist da z. B. kein Thema. Vielmehr laufen MIP die Gefahr, dass der Anwender den Hersteller zu wenig einbezieht. Es besteht momentan ein Trend weg vom Projektleiter des Herstellers. Die Anwender denken, dass es reicht, wenn sie den Projektleiter stellen. Aber wie man sich denken kann, funktioniert das nie, denn wer sorgt z.B. dafür, dass dem Projekt genügend Expertise seitens Hersteller-Entwicklungscenter zukommt? Sicher nicht der Projektleiter des Kunden, der aus der Sicht des Entwicklungscenters irgendwo auf der Welt in einem unbedeutenden Land sitzt. Sie erinnern sich ja an den Beitrag Staus im Projektmanagement vom 25. Juli 2008. Natürlich sind das Angelegenheiten, für die sich der Kunde nicht interessiert, und natürlich ist es verständlich, wenn er in der Offerte keinen entsprechenden Posten sehen will. Aber der Projektleiter des Lieferanten ist am Abend auch hungrig und kann die Arbeit nicht für Gottes Lohn machen. Hier entwickelt sich gerade eine neue Mode, die zur Komplexität beiträgt. Die Kräfte, welche die Randbedingungen liefern sind:
• Preisstandards für die Services, die mit dem System angeboten werden sollen
• Globalisierte Herstellerorganisationen vs. national operierende Betreiber
• Zunehmende Spezialisierung der Systeme für immer mehr konvergierende Applikationen
Die Players sind die Hersteller und ihre Subcontractors, die Betreiber entlang einer mehrstufigen Supply Chain sowie Millionen von Endbenutzern. Alle diese Players richten sich im herrschenden Kräftefeld so aus, dass sie das kleinste Leid haben, so wie sich ein Windzeiger in den Wind stellt, damit er der Windkraft am wenigsten ausgesetzt ist. Das führt möglicherweise zu einer Mode, die die Players „versklavt“, so dass sie schlussendlich ihre Ausrichtung nicht mehr selber wählen können. Was die Begriffe Mode und versklaven anbelangt erinnern Sie sich gewiss an den Beitrag Was ist komplex am Bierspiel vom 21. Juli 2008.

1 Wiki Softwaretechnik, Artikel Chaos-Report

Staus im Produktemanagement

Beim gestrigen Lunch machte mich mein Gesprächspartner auf eine Tatsache aufmerksam, die für Migrations- und Integrationsprojekte (MIP) typisch ist. Die zum Einsatz gelangenden Produkte sollten zwar möglichst neu sein, ohne jedoch die Mängel von Kinderkrankheiten aufzuweisen. Meistens gibt es nur eine oder zwei Personen, die das Produkt wirklich gut kennen. Nicht einmal die Entwickler kennen das Produkt, da sie im Allgemeinen nur an einem bestimmten Modul gearbeitet haben. Der Architekt und der Entwicklungschef kennen das Produkt bloss konzeptionell, aber haben auch keine Erfahrung, wie sich das Produkt im Betrieb verhält. So gibt es wohl nur den Produktmanager innerhalb der Entwicklung, der sich mit dem Produkt in praxi wirklich auskennt. Die Projektleiter, die das Produkt bei den Kunden in aller Welt ausrollen müssen, haben oft keine Produktkenntnisse, und die Mitarbeiter der nationalen Konzerngesellschaften des Lieferanten noch viel weniger.

Figur: Rot sind Einheiten, die zentral irgendwo auf der Welt in einem Competence Center arbeiten. Blau sind lokale Einheiten, die in allen nationalen Konzerngesellschaften anzutreffen sind. Der Ring „Projektmanagement / Produktion“ kann sowohl zentral als auch lokal agieren. Aufgabe des Produktmanagement ist es, das Wissen in konzentrischen Wellen nach Aussen zu befördern.

So muss denn nun der zentrale Produktmanager zunächst seine Kollegen von den Projekten und der Trainingsabteilung schulen. Das kann er aber nicht fulltime tun, denn er muss ja auch immer das Produkt im Auge behalten. Wenn z.B. ein Trainer der Schulungsabteilung eine Frage der Kursteilnehmer nicht beantworten kann, leitete er sie an den Produktmanager weiter, denn auch der Trainer kennt das Produkt bloss theoretisch. Später, wenn sich das Produkt in einer bestimmten Kundenumgebung eigensinnig benimmt, werden die lokalen Ressourcen und der zentrale Projektmanager, versuchen, die Fehler zu reproduzieren und zu dokumentieren. Nur der zentrale Produktmanager kann abschliessend sagen, ob es sich um einen Konfigurationsfehler oder um einen Produktfehler handelt. Es kommt zu Staus und der Propagationsprozess der Produktkenntnisse zieht sich schleppend dahin. Was Sie in meinem gestrigen Artikel über Verzögerungen gelesen haben, lässt hier grüssen. Wir werden darauf zurück kommen.

Was macht man mit Bottlenecks? Gemäss Eliyahu M. Goldratt1 versucht man, die Engpassressource auszubauen. Bis es soweit ist, muss sich alles andere nach dem Engpass richten. Das bedeutet, dass andere Einheiten Wartezeiten haben werden. Auf keinen Fall dürfen die anderen Einheiten weiter arbeiten, denn das baut nur Bestände auf. In MI-Projekten sind das lange Issues- und Aktionslisten (siehe Komplexität im Projektmanagement). Das Projekt zieht sich schleppend dahin, bis das Produkt-Know-How genügend weit zum Kunden hin propagiert ist, dass sich das Projekt ohne zentrale Experten komfortabel durchführen lässt. Das kann aber dauern. Umgekehrt bedeutet die Ausweitung der Engpassressource zwei oder gar drei Produktmanager parallel laufen lassen. Bloss ist keine Kunde bereit, das zu zahlen.

Er wird aber auch nicht bereit sein, das Projekt zu verzögern. Im Gegenteil wird er mit Penalties drohen, das ist vorprogrammiert. Hier muss die nationale Konzerngesellschaft handeln, bevor ein entsprechendes Projekt kommt. Die lokalen Produktmanager müssen rechtzeitig aufgebaut werden, andernfalls baden es die lokalen Projektressourcen aus und das Unternehmen wird einen Imageverlust erleiden.

1Eliyahu M. Goldratt, Jeff Cox. Das Ziel – Höchstleistungen in der Fertigung. McGraw-Hill Book Company, Maidenhead 1990
und
Eliyahu M. Goldratt. Die Kritische Kette – Das neue Konzept im Projektmanagement. Campus Verlag. Frankfurt a. Main 2002