Um allen Diskussionen zuvorzukommen, soll die wichtigste Frage sofort beantwortet werden: IS, also "Information Systems", ist hier in einem Sinne verstanden, der über die reine IT (Information Technology) hinausgeht.
Den Anstoß zu diesem Artikel gab ein Vortrag, den ich vor einigen Monaten gehalten habe. Sein Thema lautete: "Chancen, Risiken und Nebenwirkungen im heutigen IS-Portfolio-Management." Das Interesse an derartigen Themen ist anscheinend unvermindert groß. Das deutet darauf hin, dass den Verantwortlichen eine Menge mehr Spreu in den Nasen sitzt, als sie Weizen in den Händen halten. Im KlarteXT:Viele IS-Projekte scheitern, verbrennen gutes Geld, halten meist teure Mannschaften auf Trab, erzielen aber bei weitem nicht den gewünschten Effekt.
Ich möchte hier zehn - nicht nach Wichtigkeit geordnete - Grundsätze zur Diskussion stellen. Ihre Nichtbeachtung wird ein IS-Projekt zwar nicht unweigerlich, aber doch mit einiger Wahrscheinlichkeit zu Grabe tragen. Sobald sich ein Projekt auch nur an einem dieser Grundsätze reibt, brennt es lichterloh. Auf der anderen Seite sollte das Vorhaben immerhin zu 80 Prozent in trockenen Tüchern sein, wenn es alle zehn Grundsätze nachhaltig erfüllt.
1. Ein IS-Projekt ist ein Business-Projekt und muss von einem Business-Manager geführt werden, der ein persönliches Interesse am Erfolg hat.
Es wird wohl kaum jemanden in der IS-Gemeinde geben, der nicht sofort bestätigt, dass mindestens 50 Prozent vom Gesamtenergieverbrauch eines IS-Projekts zum Überwinden innerer Widerstände benötigt werden. Das gilt besonders für Unternehmen, die komplexe Organisationsstrukturen haben, viele Länder betreuen und in mannigfaltigen Kulturen sowie einer multidimensionalen Matrix arbeiten, also beispielsweise für ABB. Doch die Hände in den Schoß zu legen ist genauso falsch, wie einfach weiterzumachen. Innerer Widerstand dient ja auch als Schutz für die Benutzer, damit sie sich nicht täglich mit den oft geschäftsfremden Ideen der IS-Chefideologen auseinander setzen müssen.
Wer ziemlich sicher sein will, dass sein IS-Projekt einem klaren Geschäftszweck dient, sollte den Geschäftsverantwortlichen überzeugen, dass er es als sein Baby adoptiert und es mit der ganzen Kraft seiner Position über innere Widerstände hebt. Ideal ist, wenn diese Person auch noch als Geldgeber des IS-Projekts fungiert. In einem solchen Fall kann sich die IS-Mannschaft ungleich stärker auf die Technik konzentrieren.
2.Die Rollenverteilung von "Business People" und "IS People" muss glasklar sein.
Wichtig ist, wer was macht, aber wichtiger ist, dass es keine Doppelfunktionen oder unzugewiesenen ("unassigned") Rollen in einem IS-Projekt gibt. Realiter existiert eine "natürliche" Verteilung der Rollen. So bestimmt eine IS-Person in der Regel die Technik, die Datenbank, die Hardware; eine Geschäftsperson entscheidet über Funktionalität, Termine und Budget. Wenn - wie bei ABB - die weltweite gemeinsame Mail-Struktur Lotus Notes vorsieht, geht es nicht, dass sich ein Geschäftsmann in einem Projekt für CC:Mail entscheidet. Besteht die Auswahl zwischen verschiedenen Hardwareherstellern, so muss ein Einziger im Projekt das letzte Wort haben.
Die meistdiskutierten Probleme in jedem IS-Projekt betreffen die Wechselwirkung zwischen Funktionalität, Terminplan und Budget. Welches IS-Projekt bleibt mit der vollen geplanten Funktionalität innerhalb der Zeit- und Budgetpläne? Ich stehe laufend vor diesen drei Stellschrauben und frage mich: "An welcher drehe ich jetzt?" Es muss völlig klar sein, wer diese Entscheidung trifft. Ich empfehle dringend, diese Rolle den "Business People" zu lassen.
3.IS-Projekte müssen immer eine "Kostenverminderung" oder eine "Funktionserweiterung" oder beides zum Ziel haben.
Kann keines dieser Ziele erreicht werden, sollte das Projekt sofort gestoppt werden. Eine Ausnahme für diese Regel sehe ich nur dort, wo gesetzliche Bestimmungen erfüllt werden müssen (zum Beispiel das Nachhalten alter Systeme zum Zwecke der Steuerprüfung). Wichtig ist, dass ein Projekt während seines gesamten Lebenszyklusses wiederholt an dieser Latte gemessen wird.
Randbedingungen und Ziele ändern sich, in der Konsequenz kann der "Sinn" eines Projektes verschwinden. Das ist nicht tragisch; man stoppt das Projekt und spart Geld und Nerven. Schlimm ist nur, wenn man weitermacht, nur weil man angefangen hat. Bei ABB haben wir einen ganzen Prozess implementiert, der diese Prüfaufgabe mit Hilfe von "Tollgates" erfüllt. Ich komme weiter unten noch darauf zu sprechen.
4.Großprojekte sind wie Saurier: großer Körper, kleiner Kopf und nicht überlebensfähig.
Ich hatte mal einen Chef, der lehnte radikal alles ab, was länger als sechs Monate dauern sollte. Wie oft habe ich ihn zu überzeugen versucht: "Das geht nicht in sechs Monaten, ich brauche mindestens zehn!" Seine lakonische Antwort lautete: "Dann schneide das Projekt in zweimal fünf Monate. Aber das Ergebnis des ersten Teils muss eigenständig verwendbar sein. Nimm Funktionalität zurück, streiche alle Verschnörkelungen und Vergoldungen raus, bringe es auf den Punkt."
Wie recht er hatte! Heute, da sich die Geschäftsbedingungen im Zeitraum von Monaten, die Technologie gar im Wochenrhythmus ändert, sind IS-Projekte mit einem Ereignishorizont von zwei Jahren zumindest besonders sorgfältig zu managen.
5. Ohne eine intime Beziehung zwischen "Business People" und "IS People" können keine IS-Projekte mit Hand und Fuß geboren werden.
Es muss ja nicht gleich Liebe sein, aber wir brauchen heutzutage ein ungleich tieferes Verständnis für die andere Partei als je zuvor. Nur wenn die IS-Leute genug vom "Geschäft" kennen, wenn sie selbst den Kosten- und Zeitdruck eines Verkäufers, eines Produktionsleiters oder Controllers fühlen, können sie mit ihren Mitteln und Kenntnissen helfen. Zwar läuft TCP/IP überall gleich, aber die Applikationsanforderungen an ein Großprojekt in Kenia sind doch andere als die eines Schalterherstellers mit Millionenserien in den Tiefen Deutschlands.
Auf der anderen Seite muss ein Geschäftsverantwortlicher zwingend verstehen, was das Hilfsmittel IS leisten kann und was nicht. Ganze Geschäftsstrategien dürften scheitern, wenn die IS-Technologie und vor allem die Implementierungsfähigkeit überschätzt wird. Eine Produktionsintegration auf Shopfloor-Level zwischen zwei Produktionsstätten in Nigeria und China ist nicht mit Hilfe von Buschtrommeln zu erreichen.
Die innige Zusammenarbeit zwischen Business und IS mit gegenseitiger "Befruchtung" beginnt schon in der Geschäftsstrategie-Diskussion. Wenn diese Verzahnung klappt, weiß jeder vom anderen, was er will und kann - eine tolle Voraussetzung für erfolgreiche IS-Projekte.
6.Es muss eine gesamtheitliche Firmen-IS-Strategie existieren; anderenfalls scheitern IS-Projekte an ihrer Unfähigkeit zur Integration.
Nichts ist offensichtlicher als die Notwendigkeit einer konzernweiten, einheitlichen IS-Infrastruktur. Gleichzeitig lässt sich nichts schwieriger erreichen. Sicher kann man alles adaptieren und konvertieren, interfacen etc. Aber die Komplexität wächst mit jedem neuen Freiheitsgrad im Quadrat, und die Betriebskosten steigen schneller, als der Euro fällt.
Jeder kennt die Lösung: Sie heißt Standardisierung. Darüber besteht Einigkeit; Meinungsverschiedenheiten gibt es meist "nur" über den Grad der anzuwendenden Brutalität bei der Einführung und über die Grenze, ab der die Flexibilität beginnen sollte.
Fehlt ein verbindlicher Maßstab in Form einer aus den Geschäftsbedürfnissen abgeleiteten Konzern-IS-Strategie, so bekommt das Unternehmen im schlimmsten Fall so etwas wie die deutsche Kleinstaaterei des 17. Jahrhunderts, im besten Fall ein Europa der Vaterländer, aber niemals ein Machtgebilde wie die USA. Installieren Sie nur einmal ein einheitliches Internet-Portal mit vielen unterschiedlichen Backend-Systemen! Das kann zur weltmeisterlichen Akrobatik geraten.
7.Die IS-Organisation bildet die Firmenorganisation ab. Das ist besonders bei internationalen, multikulturellen Hybriden von Bedeutung.
ABB besteht aus einigen hundert Firmen in mehr als 100 Ländern dieser Erde, die jeweils einer nationalen Dachorganisation (Holding) zugeordnet sind. Das führt zu Tausenden von "Profit-Centers", "Departments" und "Units" - viele davon mit einem großen Grad an Eigenständigkeit. Hinzu kommen eine weltweite Organisation in sechs Produktsegmente und über 40 Business Areas, mehrere eigenständige Einheiten sowie selbstverständlich ein paar Stäbe; alles in allem hat manch ein Mitarbeiter zwei bis drei Chefs.
Das ist nicht neu, das hat seinen guten Grund, und andere machen das auch so. Aber was auf der geschäftlichen Ebene passiert, muss IS-seitig reflektiert werden. Jede der organisatorischen Einheiten sollte einen Ansprechpartner haben, der ihre speziellen IS-Bedürfnisse kennt und verfolgt.
Wenn auf geschäftlicher Seite mit einer Vielzahl von Blickwinkeln um die richtige Entscheidung gerungen wird, darf sich die IS diesem anstrengenden Prozess nicht entziehen. Bekommt ein Produkt den Vorrang vor einer geografischen Entscheidung, so können sich die begleitenden IS-Maßnahmen nicht ausschließlich an der Geografie ausrichten. Wird eine Gasveredelungsanlage in Turkmenistan gebaut, so muss die IS in der Lage sein, dort die nötige Infrastruktur zur Verfügung zu stellen. Ein Zuständigkeitsloch oder eine Wissenslücke dürfen nicht existieren.
8.Qualität ist nicht durch Quantität zu ersetzen.
Für heutige IS-Projekte ist das richtige Personal notwendig, besonders in den Manager-Positionen. Wer keinen Projekt-Manager hat, dem er haltlos vertraut, sollte das Projekt sein lassen. Reicht dessen Qualifikation nicht aus, ist es besser, gar nicht erst zu beginnen. Aber fangen Sie bloß nie ohne einen Projekt-Manager an!
Unterschiedliche Projekte verlangen unterschiedliche Typen, manchmal den Knochenbrecher, manchmal den Erbsenzähler, manchmal den geschickten Diplomaten etc. Niemand hat all diese Qualitäten gleichzeitig parat, zumindest nicht im selben Ausmaß. Es hilft nichts, wenn drei mittelmäßige, als Diplomaten typisierbare Projekt-Manager an einem Vorhaben sitzen, das einen superstarken Knochenbrecher mit der "Licence to fire" verlangt. Wenn Sie den passenden Mitarbeiter nicht haben, ist es oft billiger, ihn - vordergründig teuer - auf dem freien Markt einzukaufen, als interne Kompromisse einzugehen.
9.Es gibt kein planbares Volumen oder gar ein Ende der Kommunikation.
Kennen Sie Aussagen wie: "Die haben falsch angefangen und machen jetzt einfach weiter ... wenn ich etwas zu sagen hätte ... keine Ahnung, was das soll"? IS-Projekte haben oft sehr komplexe Hintergründe und können eine große Zahl von Mitarbeitern betreffen. Schon bei kleineren Projekten lohnt es sich häufig, einen Mitarbeiter abzustellen, der nichts anderes tut, als die Beteiligten zu informieren und auf dem aktuellsten Stand der Dinge zu halten - sozusagen einen "Projekt-Pressesprecher".
Das Auditorium ist sehr vielfältig. Es umfasst Anwender, Manager, Finanz-Controller, Betriebsräte, Kunden, Lieferanten, das Bundesausfuhramt (Bafa), die Exportkontrolle, den Sicherheitsdienst etc. Oft ist mehr nötig als Information, nämlich der "Propaganda-Effekt": Das Gleiche wird einfach solange gepredigt, bis auch der Letzte sagt: "So, jetzt habe ich es kapiert."
10.Gedenket der Prozesse!
Ändern sich Prozesse, so ändert sich auch das SAP-System; wenn nicht, dann hat es sich mit der Prozessänderung. Das ist vielen Leidensgenossen klar.
Ändert sich SAP (oder kommt gar SAP ins Haus), so ändern sich auch die Prozesse; wenn nicht, dann hat es sich mit SAP. Das ist nicht so vielen klar. Wenn aber ein Mitarbeiter im Vertrieb seine Arbeitsweise umstellen muss und dadurch vielleicht mehr Arbeit zu erledigen hat als vorher, damit ein Problem in der Auslieferung beseitigt werden kann, dann reicht es nicht, ihm wortlos neue Software zu geben.
Wie oben versprochen, möchte ich zum Schluss noch auf das eingehen, was bei ABB "Information Systems Delivery" (ISD) heißt: einen wohldefinierten, formalen Prozess, der ein Projekt kontinuierlich an den oben beschriebenen Grundsätzen misst. Diese Aufgabe obliegt einem Steering Committee, das die Projekte lenken und stoppen kann.
Die fünf "Zollstationen"Des Pudels Kern sind die fünf "Tollgates", die ein IS-Projekt im Laufe seines Lebens passieren muss. An jeder dieser "Zollstationen" werden Fragen gestellt, die neben besagten zehn Grundsätzen auch weitergehende Aspekte berücksichtigen.
1. Am ersten Gate gibt es eine Idee oder eine Projektanforderung. Die Frage lautet: Sollen wir ein Konzept machen?
2. Am zweiten Gate existiert das Konzept. Die Frage lautet: Sollen wir ein Design machen?
3. Am dritten Gate haben wir ein Design. Die Frage lautet: Sollen wir entwickeln?
4. Am vierten Gate ist das System entwickelt. Die Frage lautet: Sollen wir implementieren und einführen?
5. Das fünfte Gate muss das Projekt passieren, wenn es bereits implementiert ist. Die Frage lautet: Haben wir alle geplanten Ziele zufriedenstellend erreicht, und sollen wir das Projekt abschließen?
Je nach Tollgate müssen zehn bis 20 unterschiedliche Punkte mit "Ja" bestätigt sein; ein einziges "Nein" hält die Schranke unten. In diesem Fall heißt die Entscheidung: Nacharbeiten oder Projektabbruch. Mit diesem im gesamten ABB-Konzern gültigen Prozess lässt sich die Projektspreu vom Weizen trennen.
*Dr. Alfred Spill war in den vergangenen acht Jahren in verschiedenen Funktionen für den Anlagenbaukonzern ABB tätig. Derzeit leitet er von Ludwigshafen aus die IS Area Organisation, die weltweit als "verlängerter Arm" des CIO Jim Barrington fungiert.