In diesem Jahr hat die US-amerikanische Computerworld in ihrem Wettbewerb "A Search for new Heroes" auch einen deutschen Helden gefunden: Infineon zählt zu den fünf Unternehmen der Fertigungsindustrie, die ein herausragendes IT-Projekt vorweisen konnten. Mit ihrem "Market Intelligence Portal" schafften es die Münchener als einziges ausländisches Unternehmen in die Runde der letzten Fünf. Infineon-CIO Karl Pomschar hat zwei Erklärungen für diesen Erfolg: Zum einen lobt er das Team für die gute Zusammenarbeit. Jeder Beteiligte habe sich als Teil des Projekts verstanden. Zum anderen verweist er auf das System, mit dem die Mitarbeiter ihre ProjektEffektivität kontrollieren konnten. "Da stand die Ampel meistens auf Grün", erzählt Pomschar.
"Project Effectiveness" zählt zu den sieben Indikatoren, an denen sich die IT bei Infineon - und damit auch der CIO - messen lassen. Zwei davon ("Reference IT Modell" und "IT Optimization") sind so spezifisch auf den Halbleiterhersteller zugeschnitten, dass sie für Unternehmen mit anderen Voraussetzungen nicht direkt übertragbar sind. Die restlichen fünf KPIs können dafür auch anderen IT-Abteilungen als Erfolgsindikatoren dienen. Da bei Infineon die Unternehmenssprache Englisch ist, seien sie hier zunächst im Original aufgelistet:
1. Operational Cost versus Forecast,
2. Systems Uptime,
3. Standardization,
4. Architecture Compliance und
5. Project Effectiveness.
Zu 1. CIOs sind natürlich immer schon daran gemessen worden, inwieweit ihr Budgetplan mit den tatsächlichen Ausgaben übereingestimmt hat. Das war auch bei Infineon so, lange bevor die KPIs "KPIs" geheißen haben. Seit zwei Jahren zählt der zuständige Infineon-COO Andreas von Zitzewitz die Budget-Treue nun aber offiziell zu den Erfolgsindikatoren. Im letzten Jahr berichtete Pomschar dabei punktgenau an ihn: Er erzielte den Idealwert von 100 Prozent, was heißt, dass seine Prognose exakt die tatsächlichen Ausgaben traf. Bei einer Überschreitung von fünf Prozent wäre im System ein gelbes Lämpchen angesprungen. Ab zehn Prozent wechselt die Farbe auf Signalrot. Pomschar hält das aufgrund der Kontrollmechanismen zwar für unwahrscheinlich und unternehmerisch gesehen für sehr schädlich, trotzdem wüsste er für den äußersten Extremfall eine Lösung: "Ich habe zwei bis drei Mitarbeiter, die mich sehr schnell replacen könnten", grinst der CIO. "Das ist doch ein gutes Zeichen."
Zu 2. "Systems Uptime" bezeichnet die Verfügbarkeit der operativen Systeme, wobei hier zwischen drei unterschiedlichen Systemgruppen unterschieden wird. Anders als etwa bei einer Bank versucht dabei kein Infineon-Mitarbeiter, so nahe wie möglich an die 100 Prozent bei allen Systemen heranzukommen. Die Kosten für eine derartige Hochverfügbarkeit wären nicht zu rechtfertigen. "Mail-Server brauchen keine 99 Prozent Verfügbarkeit", konstatiert Pomschar. Der Idealwert für "Systems Uptime" liegt beim Chipbauer deshalb bei 97 Prozent. Als im letzten Jahr der Wert trotzdem auf 98,6 Prozent kletterte, hat der CIO natürlich niemanden dafür bestraft.
Zu 3. Unter "Standardization" versteht Pomschar die Vereinheitlichung der Anwendungssoftware. Auf rund 1000 Applikationen schätzt er die historisch gewachsene Vielfalt. Dabei leisten sich die 5000 Entwickler in der 34000-köpfigen Belegschaft einen besonders kreativen Umgang im Einsatz von Programmen. Pomschar sieht das Problem jedoch eher bei den 15000 Kollegen aus dem Business-Bereich: "Wissen Sie was es heißt, mehrere Reporting-Systeme zu betreiben?" Das Ziel des CIO lautet deshalb: Um fünf Prozent soll sich die Zahl der Applikationen pro Jahr verringern. Klar, dass es mit zunehmenden Jahren immer schwerer fallen wird, bei diesem KPI gute Werte zu erreichen.
Zu 4. "Architecture Compliance" beschreibt, wie viele der IT-Systeme sich bereits in der Zielarchitektur befinden. Damit meint Pomschar die drei Plattformen SAP, i2 und Lotus Notes. Bislang ordnen sich 72 Prozent der Systeme unter dieses Dreigestirn. Laut Zielvorgabe des CIO sollten es 82 Prozent sein. Um diesen Idealwert zu erreichen, hat Pomschar den bisherigen, dreistufigen Workflow von "Plan", "Build" und "Run" weiter ausdifferenziert. Statt von "Plan" spricht der CIO lieber von "Define" und "Design". Die Aufspaltung hat folgenden Grund: "Wenn die IT erst hinter der Define-Phase ins Spiel kommt, dann hat sie bereits verloren, dann ist sie immer die Dumme oder die Böse", warnt Pomschar. Als Folge könne man in der Architektur nur noch Kompromisse eingehen, was der CIO kategorisch ablehnt: "Das Thema Plattformen ist durch. Das diskutieren wir hier nicht mehr."
Zu 5. "Project Effectiveness" ist der KPI, in den Pomschar und sein Team die meisten Überlegungen investiert haben. Effektivität in Projekten fair zu bemessen zählt zu den schwierigsten Aufgaben, da "Zeit", "Budget" und "Scope" nicht nur von der IT bestimmt werden, sondern immer auch von Dritten sowie von weiteren, externen Einflüssen, die für die IT-Verantwortlichen unvorhersehbar sind.
Um den Projektmanagern trotzdem Gerechtigkeit widerfahren zu lassen, lässt Pomschar deshalb nicht nur einen "Project Effectiveness Quantifier" errechnen, der die drei Kriterien "Zeit", "Geld" und "Umfang" misst, sondern er lässt gleichzeitig die Verursacher von möglichen Planabweichungen identifizieren. Dies drückt sich dann im so genannten "Change Request Quantifier" aus. Beide Quantifier werden zum Schluss miteinander multipliziert und ergeben die Endnote für Effektivität.
Um den Idealwert von 1,0 zu erreichen, muss ein IT-Manager zunächst in Zeit, Geld und Umfang genau den Plan erfüllen. Er erhält dann in allen drei Kategorien den Multiplikator eins, der vom System in einem kräftigen Grün angezeigt wird. Bei kleineren Abweichungen springt die Ampelfarbe auf Gelb. Das kann zum Beispiel passieren, wenn die Projektlaufzeit um zehn Prozent oder um maximal einen Monat überschritten wird. Das passiert auch, wenn das Budget um zehn Prozent oder um maximal 100 000 Euro überreizt wird. In beiden Fällen erhält der IT-Manager den "Project Effectiveness Quantifier" von 0,9.
Richtig schlechte Werte kommen zustande, wenn Zeit, Geld und Umfang kritisch vom Plan abweichen, also um mehr als zehn Prozent bei Zeit und Geld - oder, wenn der Umfang ganz aus dem Ruder läuft. Pomschar sieht Letzteres nicht nur gegeben, wenn der Geschäftsfall sich während des Projektverlaufs grundlegend geändert hat, sondern auch, wenn die Akzeptanz beim Kunden gefährdet ist. Dann springt die Ampel auf Rot und der "Project Effectiveness Quantifier" sinkt auf 0,5. Dieser Wert wird anschließend mit dem "Change Request Quantifier" multipliziert, der zwischen folgenden Werten schwankt:
- 1,0 (der Kunde hat die Abweichung vom Projektplan verursacht),
- 0,9 (IT und Kunde sind gemeinsam für die Abweichung verantwortlich) und
- 0,8 (die IT hat den Change Request selbst verbockt).
Bei veränderten Anforderungen durch die Fachabteilung muss also der Projektmanager aus der IT nicht fürchten, dass sein Wert für Project Effectiveness in Mitleidenschaft gezogen wird. Sein Ergebnis wird mit einer runden Eins multipliziert, bleibt also gleich.
Durchschnittlich 160 Projekte jährlich lässt Pomschar auf diese Weise bewerten. Bei 0,87 liegt sein Idealwert für Project Effectiveness. 0,86 konnte die IT-Abteilung im letzten Jahr realisieren, womit das Ziel knapp verfehlt wurde. Dieses Jahr wird ein Wert über 90 Prozent erreicht. Pomschar ist mit diesem Fortschritt zufrieden.
Mit seinen KPIs kann er sauber nachhalten, was jeder Euro aus seinem Etat dem Unternehmen gebracht hat. "Fünf Prozent vom IT-Budget zu sparen - das würden wir in einem Zehn-Minuten-Meeting schaffen", sagt der CIO. Aufgrund der Effizienzpotenziale, generiert durch die KPI-Kontrollmethode, sieht Pomschar den entsprechenden Mehraufwand als absolut gerechtfertigt: "Unsere Fabriken und die anderen operativen Bereiche reporten viel detaillierter." Der CIO wird daher seine Methode noch ausbauen: "Nach den ersten Jahren der Standardisierung und Optimierung werden wir für das nächste Jahr ein weiteres KPI einführen: die Kundenzufriedenheit."