Während der zurückliegenden fünf Jahre hat fast jede IT-Organisation in Konzernen und großen Mittelstandunternehmen Prozessinitiativen gestartet, die auf den effizienten und störungsfreien Ablauf von Projekten oder IT-Prozessen zielten. Die Vorhaben orientierten sich meist an Best Practices und Quasistandards wie Itil, Prince2, Cobit, BS 15000 oder ISO 20000.
Die Initiativen haben unterschiedliche Ziele. Oft dienen sie dazu, gesetzliche Compliance-Anforderungen zu erfüllen. Ein Itil-Projekt soll häufig sicherstellen, dass alle an einem IT-Service Beteiligten dieselbe Sprache sprechen. Ein wichtiger Grund für solche Vorhaben ist auch der, Best Practices übertragbar und Benchmarks aussagefähig zu machen.
Aber die Marktstandards haben auch einen Nachteil: Sie verleiten die Unternehmen dazu, das Thema Prozess-Management auf die Formalisierung und die Zertifizierung beziehungsweise den Audit der Prozesse zu begrenzen.
Prozessdesign ist die leichtere Übung
Die Standards vereinfachen vor allem das Prozessdesign. In den meisten Fällen werden die Abläufe also möglichst nah am Standard modelliert, trainiert und eingeführt. Damit erreichen sie bei einem Audit nach CMMI (Capability Maturity Model Integration) aber höchstens den Reifegrad 3. Unerreicht bleiben die Stufen 4 und 5, die für das quantitative und qualitative Messen und Managen der Prozessleistung stehen.
Das fällt umso mehr ins Gewicht, als das Prozessdesign nur etwa 20 Prozent des Gesamtaufwands in derartigen Initiativen ausmacht. Die Aufwandsersparnis ist also begrenzt. Der tatsächliche Kraftakt besteht in der - für eine Zertifizierung notwendigen - Implementierung der Prozesse. Und genau hier sind die Grundlagen für ein Performance-Management zu legen. Eine Rückbesinnung auf die Ziele von TQM (Total Quality Management) im Allgemeinen und die des Prozess- und Performance-Managements im Speziellen tut Not.
COMPUTERWOCHE-Serie: "Zertifikat - was nun?"
Dieser Artikel gehört zu einer dreiteiligen Serie. Sie widmet sich folgenden Themen:
-
Itil ist nur im Gesamtrahmen sinnvoll;
-
Warum Projekte trotz Methode schiefgehen.
Die häufigste Probleme
Wer kennt nicht zumindest einige der folgenden typischen Probleme, die während eines IT-Prozess-Vorhabens auftreten können? In der Beraterpraxis bei Dewey, Plegge, Raff & Partner tauchen sie immer wieder auf.
-
Moving Targets: Die ohnehin unter der Mehrbelastung für Prozessentwicklung und -implementierung leidenden Mitarbeiter geraten durch immer neue Rahmenbedingungen und Regelwerke in einen kontinuierlichen "Change-Mode". Also können sie sich nicht mehr auf eine effektive Implementierung konzentrieren. Ein strategisches Monitoring der Rahmenbedingungen (Gesetze, Marktstandards, Stakeholder-Erwartungen, Unternehmensstrategie) fehlt.
-
Ressourcenengpässe: Wenn die Prioritäten der IT-Organisation ständig wechseln, kommt es zu Konflikten zwischen dem IT-Betrieb und der Prozessinitiative. Schließlich sind für beide Aufgaben dieselben Experten notwendig. Eine integrierte Planung wäre hier hilfreich.
-
Zu viel auf einmal: Im "Geschäftssystem" einer IT-Organisation gibt es etwa 15 bis 20 sinnvoll unterscheidbare Kernprozesse - aus Führung und Verwaltung, Projektgeschäft und Betrieb. Wenn eine übergeordnete strategische Stoßrichtung und Planung fehlen und das Projektteam zudem den Aufwand unter- sowie die eigenen Möglichkeiten überschätzt, werden möglicherweise zu viele Prozesse gleichzeitig eingeführt beziehungsweise verändert. Die Organisation sieht vor lauter Bäumen den Wald nicht mehr. Stattdessen sollte das Projektteam die Prioritäten mit der Geschäftsstrategie abstimmen sowie die Prozesse gemäß ihrer Wirkung auf Kundenzufriedenheit, Servicequalität und die aktuellen operativen Stärken oder Schwächen bewerten.
-
Uneinheitliche Prozesshierarchie und Dokumentation: Die Prozessverantwortung sollte möglichst nah an der Arbeitsebene liegen. Daraus ergibt sich eine verteilte Verantwortung. Ohne einen Dokumentenstandard und eine durchgehende Prozesshierarchie sind die Entwicklungsergebnisse inkonsistent und damit schwer verständlich, so dass die IT-Management-Ebene sie kaum freigeben kann. Meist fällt die Granularität der Prozessbeschreibung auch höchst unterschiedlich aus. So gestaltet sich eine spätere Prozessintegration aufwändig oder gar unmöglich. Und die Abbildung der beschriebenen IT-Services auf die in Anspruch genommenen Prozesse wird zu einer Herkulesaufgabe.
-
Unklare Rollen im Prozess-Management: Sind die Rollen und Verantwortlichkeiten für Qualitäts-Manager, Prozesseigner und lokale Prozessexperten nicht klar und einheitlich geregelt, regieren Konflikte und Doppelarbeit statt Fortschritt und kontinuierlicher Verbesserung. Das gilt insbesondere an der Schnittstelle zu den Linienfunktionen der IT.
-
Unklare Abgrenzung von Prozessen: Sind die Prozesse nicht eindeutig voneinander unterschieden, kommt es ebenfalls zu Doppelarbeiten - durch parallel laufende Aktivitäten, die sich mit denselben Aufgaben beschäftigen.
-
Mangelnde Kommunikation und verpasstes Lernen: Strukturierte Kommunikation kann man nicht delegieren, sie muss gefördet werden. Oft reden die handelnden Personen aneinander vorbei, weil die Probleme nicht aus der Gesamtsicht in Angriff genommen werden, sondern aus der Teilsicht des Einzelprozesses. Allzu oft sehen Prozessverantwortliche die Qualität der Daten oder die Arbeitsstände am Eingang ihres Prozesses als unzureichend und schlecht an, während sie die eigenen Ergebnisse am Prozessausgang als "den Umständen entsprechend optimal" betrachten. Regelmäßige Meetings mit allen Prozesseignern einzuberufen und diesen Punkt auf die Agenda zu setzen gehört zu den fachlichen Führungsaufgaben eines prozessübergreifenden Qualitäts-Managers.
Das Prozess-Management-System
Solche nagativen Erfahrungen führen oft zu einem Misskredit des Projekts, zum gebetsmühlenartigen Abwägen der Pros und Contras sowie letztlich zum unentschlossenen Fortführen oder gar unvermittelten Abbruch des Vorhabens. Prozessstandards wie Itil oder Prince2 helfen hier nicht.
Ein Prozessprojekt muss strategisch vorbereitet, geplant und aufgesetzt werden. Es darf sich nicht auf den puren Lösungsansatz eines operativen Einzelproblems oder einer Problemgruppe beschränken. Nur mit einem systematischen Ansatz lassen sich Prozesse und Performance transparent machen. Und das ist die Voraussetzung dafür, dass das Unternehmen aus dem Zertifizierungsaufwand auch Honig saugen kann. Ohne die integrative Klammer eines Prozess-Management-Systems gestaltet sich die Arbeit als "Mission Impossible".
Bei einem Prozess-Management-System handelt es sich um ein Konzept, das ausgesuchte Praktiken aus IT-Service-Management (ITSM), Six Sigma und TQM effektiv zu einem Führungsansatz für die IT verbindet. Es umfasst eine strategische und eine operative Ebene sowie eine Governance zur Abstimmung. Wird ein solches System im Unternehmen implementiert, wirkt es als Katalysator für das Erreichen der Ziele, die mit dem Einführen von Prozessstandards und der Zertifizierung verbundenen waren: Neben der Benchmark-Fähigkeit und der gemeinsamen Sprache ergeben sich Prozesstransparenz, Performance-Management und kontinuierliche Verbesserung.
Wird ein Prozess-Management-System gleich zu Beginn der Prozessinitiative aufgesetzt, lassen sich Geld und Zeit sparen. Doch ein Wort der Warnung vorweg: Standards können auch auf der Prozessebene kein Management ersetzen. Analytik, Urteilsvermögen, gestalterische Kraft und Durchhaltevermögen sind unabdingbar.
Wesentliche Elemente eines solchen Systems sind Business Alignment, strategisches und operatives Prozess-Management sowie die zugrunde liegende Governance, mit der sich Rollen und Verantwortlichkeiten der Stakeholder, Prozesswürdigkeit, Vorgehensmodell sowie Dokumentation überwachen lassen. Zwischen diesen Elementen sollte bereits ein kontinuierlicher Verbesserungsprozess nach dem Muster: Plan - Do - Check - Act stattfinden.
Klare Orientierung
Der Hauptnutzen des Prozess-Management-Systems liegt darin, dass die Initiative von Anfang an geführt wird. Damit erhalten die "Arbeitsbienen" im operativen Prozess-Management eine klare Orientierung. Sie kennen die erwarteten Ergebnisse und deren Bedeutung für die Servicequalität. Sie müssen sich also nicht mehr in schwammigen Rahmenbedingungen und Kompetenzstreitigkeiten aufreiben. Die Arbeitsergebnisse sind nachhaltig verwertbar, vergleichbar und an den Prozessschnittstellen integrierbar. Die Struktur der Ergebnisse unterstützt bereits die Implementierung.
Aber auch Management und Kunden profitieren: Durch das Alignment des strategischen Prozess-Managements mit der Geschäftsstrategie lassen sich Prioritäten für Prozesseinführungen festlegen. Die Kriterien ergeben sich aus dem tatsächlichen Handlungsbedarf für die Servicequalität, ob es sich nun um Verfügbarkeit, Reaktions- und Lösungsgeschwindigkeit oder Kosten handelt. Dadurch steigt die Kundenzufriedenheit, und das Risiko des Scheiterns schrumpft
Messen und steuern
Bleibt noch ein wichtiger Punkt: Für ein systematisches Prozess-Management müssen unbedingt die Grundlagen des Performance-Managements gelegt werden. Hilfreich ist es, die Kernleistungszahlen (Key Performance Indicators) der Prozesse festzulegen und in einer Balanced Scorecard mit Wechselwirkungen zu einem IT-Management-Cockpit zu konfigurieren. Ohne Metriken und ein darauf aufsetzendes Performance-Management lässt sich der durch Prozessorientierung erzielte Nutzen nicht objektiv darstellen, sprich: die Zweifler werden nicht zu Überzeugten.
Auch für Steuerungsaufgaben wie kontinuierliche Verbesserung, prozessbezogene Problemlösung oder Effizienzuntersuchungen ist Transparenz notwendig. Um sie herzustellen, hat sich das Sipoc-Prinzip (Supplier, Input, Process, Output, Customer) bewährt. Dabei handelt es sich um ein Six-Sigma-Werkzeug, das den Geschäftsvorgang vom Kunden ausgehend durch den Prozess zurück zum Lieferanten abarbeitet. Entlang dieser Wertschöpfungskette sollte es aussagekräftige Metriken geben.
Auf diese Weise lässt sich beispielsweise aufzeigen, wo beim Incident-Management am Ticket-System vorbei gearbeitet wird, wo vermutlich - abzuleiten aus einer nicht repräsentativen Entwicklung der Tickets - Nachschulungen der User notwendig sind, in welchen Servicebereichen eine gemeldete Störung sofort zu einem Change Request statt zu einem Problem-Ticket führt und welche Service-Requests in nicht nachvollziehbarer Häufigkeit vorkamen. Und auf dieser Grundlage können die Prozessteams proaktiv agieren und informieren - nach dem Motto: Erkenne ein Problem, bevor der Kunde sich beschwert oder gar das Topmanagement einschaltet! (qua)