Die Keyplayer-Falle

Marcel Caviola ist IT-Spezialist mit über 25 Jahren Erfahrung als Software-Entwickler, Projektmanager, Consultant und Bereichsleiter. Seine Spezialgebiete sind Application Lifecycle Management und IT Service Management. Seit 2004 ist er bei Trivadis, heute als Solution Manager für den Bereich Application Managed Services.

Untersuchungen zeigen, dass sich weit über 50 Prozent der Wartungsorganisationen auf die Verfügbarkeit einzelner Wissensträger verlassen. Viele davon stecken bereits in der sogenannten "Keyplayer-Falle". Worum geht es dabei und wie lassen sich die damit verbunden Risiken kontrollieren?

Beispiel: Typical Story – Teil 1

Hektik in der Informatikabteilung der TypicalStory AG . Das Auftragsverarbeitungssystem "Unikum" macht Probleme. Der wöchentliche Verarbeitungslauf liefert plötzlich falsche Zahlen und hinterlässt eine Liste unverständlicher Fehlermeldungen. Niemand kann sich das erklären. Die Fachabteilungen haben sich alle schon beschwert, weil sie ohne brauchbare Daten nicht weiterarbeiten können. Ist das Problem in den nächsten zwei Tagen nicht gelöst, wird es für das Unternehmen richtig teuer und für die Informatikabteilung äusserst unangenehm.
Herbert, der Chef der Informatikabteilung, steckt in der Klemme. Ausgerechnet jetzt tritt dieses Problem auf, mitten in der Ferienzeit.

Bernhard, der einstige Entwickler dieser Verarbeitungsroutine, ist gerade auf einer Motorrad-Tour in Marokko und erst in zwei Wochen wieder bei der Arbeit. Er würde die Fehlerquelle zweifellos in wenigen Stunden aufspüren und beheben. Er hatte das bisher immer im Griff, trotz der komplexen Verarbeitungslogik. Bernhard ist einer der erfahrensten und leistungsfähigsten Mitarbeiter von Herbert. Ausserdem kennt er alle Details der Unikum-Verarbeitungsprozeduren. Daher war es auch naheliegend, ihm allein die Wartung und Weiterentwicklung dieses anspruchsvollen Applikationsteils anzuvertrauen. Alles andere wäre ohnehin viel zu aufwändig geworden. Aber jetzt… wie weiter?

Das Prinzip der Keyplayer-Falle

Im Geschäftsalltag gibt es zahllose Beispiele, wie das der TypicalStory AG. Leistungsstarke Entwickler übernehmen anspruchsvolle Aufgaben und werden sie oft nicht mehr los. Dies führt zu Personenabhängigkeiten, die sich mit der Zeit immer mehr verfestigen. So kann es zu einer Situation kommen, die wir "Keyplayer-Falle" nennen.

Keyplayer sind einzelne Spezialisten, die für den Support und die Wartung der Applikation unverzichtbar sind. Wer sich in der Keyplayer-Falle befindet, muss im Ernstfall mit unangenehmen Folgen rechnen, wenn der Keyplayer nicht zur Verfügung steht: Applikationsstörungen ziehen dann unverhältnismässig hohe Aufwände nach sich und Software-Anpassungen lassen sich mitunter nicht rechtzeitig realisieren. Ein hohes Risiko, das in vielen Fällen übersehen wird und schmerzhafte Kostenfolgen mit sich bringen kann.

Die Verbreitung der Keyplayer-Falle

Eine von Trivadis im August 2012 durchgeführte Umfrage ergab deutliche Ergebnisse. Befragt wurden IT Consultants in Deutschland und in der Schweiz, die aufgrund ihrer Beratungstätigkeit die Wartungsorganisation der Applikationen ihrer Kunden beurteilen können. Die Studie bewertet auf diese Weise insgesamt 77 Applikationen. 74 Prozent sind dabei als geschäftskritisch einzustufen. Dies bedeutet, dass mit "hohen" bis "sehr hohen" Folgekosten zu rechnen ist, wenn diese Applikationen aufgrund von Ausfällen oder zu spät umgesetzten Anpassungen ihren Zweck nicht erfüllten.

Die Umfrage ergab, dass bei 75 Prozent dieser Applikationen relevante Software-Teile von höchstens einer Person abhängig sind. Bezogen auf die Gesamtmenge leiden somit 56 Prozent der untersuchten Fälle von geschäftskritischen Software-Applikationen unter der Keyplayer-Falle. Interessanterweise wurde dieser Umstand in 14 Prozent der Fälle nicht erkannt und in weiteren 28 Prozent erkannt aber ignoriert.
Auch wenn die Umfrage nicht repräsentativ ist, lässt sie trotzdem auf eine weit verbreitete Tendenz zur Verdrängung der mit der Keyplayer-Falle verbundenen Unternehmensrisiken schliessen. Woran liegt das? Schauen wir uns das Beispiel der TypicalStory AG nochmals an.

Beispiel: Typical Story – Teil 2

Zwei Jahre ist es her, seit die Applikation "Unikum" entwickelt wurde. Das Projekt schien zunächst keine besondere Herausforderung zu sein. Erst mit der Zeit kam die Komplexität der vielen Business-Anforderungen zum Vorschein. Das Team meisterte die Aufgabe aber mit Bravour und stellte eine einwandfreie Applikation bereit.

Bernhard trug massgebend zu diesem Erfolg bei. Er war der erfahrenste Software-Spezialist im dreiköpfigen Entwicklungsteam und übernahm eine Schlüsselrolle bei der Lösungskonzeption und der Realisierung des Applikationskerns. Für einige Applikationsteile entwickelte er raffinierte Funktionsbibliotheken, mit welchen die Arbeit effizienter und die Lösung flexibler wurden. Sein Lösungsansatz für die Parametrisierung der Verarbeitungsprozesse wurde später sogar an einer technischen Fachtagung präsentiert.

Auch die Inbetriebnahme von Unikum verlief durchaus positiv. Zu Beginn gab es einiges nachzubessern – ein normaler Effekt bei IT Systemen, die in ein betriebliches Umfeld integriert werden. Glücklicherweise gelang es aber, die anfänglichen Unvollkommenheiten rasch nachzubessern und das Vertrauen der Anwender stets aufrecht zu erhalten. Bernhards Kompetenz war in dieser Phase ein wichtiger Erfolgsfaktor. Gerade bei komplexen Applikationsteilen, wie dem Auftragsverarbeitungsprozess, war kaum eine andere Person in der Lage, Fehlerursachen rasch aufzuspüren und zu beheben. Deshalb stellte das Unternehmen mit organisatorischen Massnahmen sicher, dass Bernhard hinreichend verfügbar bleibt und somit keine kritischen Situationen entstehen.

Die Entstehung der Keyplayer-Falle

Was uns die "Typical Story" erzählt, klingt auf Anhieb tadellos. Das Software-Projekt war erfolgreich und die betriebliche Einführung von Unikum verlief ebenfalls positiv. Schaut man etwas genauer hin, zeigt sich allerdings, dass sich der Weg in die Keyplayer-Falle bereits abzeichnet.

Unter den gegebenen Umständen wird Bernhard immer unentbehrlicher für den Support und die Wartung der Applikation. Aufgrund seines Detailwissens über die Applikation Unikum und seiner überdurchschnittlichen Leistungen wird man anspruchsvolle Aufgaben immer ihm übergeben wollen. Die Einbindung anderer Mitarbeiter ist im Vergleich dazu um Faktoren teurer. Angesichts des üblichen Kostendrucks wird man diese Option also kaum in Betracht ziehen. So entwickelt sich Bernhard unmerklich vom wichtigen zum einzigen Know-how-Träger in Bezug auf Applikations-Software.

Ist die Keyplayer-Falle somit unausweichlich? Werfen wir nochmals einen Blick auf die TypicalStory AG. Wie hat Herbert, der Chef von Bernhard, auf die Ereignisse reagiert?

Beispiel: Typical Story – Teil 3

Herbert hat eine harte Zeit hinter sich. Der Ausfall des Unikum-Verarbeitungslaufs warf grosse Wellen. Er mobilisierte alle Mittel, um das Problem rasch zu lösen. Das reichte aber nicht. Erst nach drei Tagen gelang es, die Fachabteilungen wieder mit brauchbaren Auftragszahlen zu versorgen. Unzählige Stellungnahmen, Sondersitzungen und Rechtfertigungsversuche waren die Folge. Ein Albtraum!

Aber Herbert hat daraus gelernt. Ihm würde so etwas nie mehr passieren. Er hat bereits damit begonnen, Massnahmen gegen die Keyplayer-Falle zu treffen. Nicht nur für Unikum, sondern für alle elf Applikationen, die in seiner Verantwortung liegen. Sein Vorgehensansatz besteht aus vier Schritten:

1. Eine Situationsanalyse für alle Applikationen durchführen
2. Die betroffenen Applikationen von den Keyplayers dokumentieren lassen
3. Das Wissen zu jeder Applikation auf mindestens drei Personen verteilen
4. Pro Applikation einen Plan für die kontinuierliche Wissenspflege erstellen

Herbert weiss jedoch, dass sein Ansatz zwei gravierende Nachteile hat. Der Eine ist das fehlende Know-how zum Thema Wissensmanagement. Sein Team hat keine Erfahrung damit, wie man die Dokumentationspflege und den Wissenserhalt zu einem zuverlässigen Teil der Application Management Prozesse macht. Das zweite Problem ist die Verfügbarkeit des Teams, das schon jetzt an der Kapazitätsgrenze arbeitet. Aufgrund beider Aspekte beschliesst Herbert, externe Spezialisten beizuziehen. Hinsichtlich der Dokumentationsfrage wird er sich methodisch beraten lassen und zur Entlastung des Teams wird er den Support und die Wartung von vier der elf Applikationen einem spezialisierten IT-Service-Provider überlassen. Zum Glück hat nach dem Unikum-Zwischenfall auch das Management eingesehen, dass sich diese Investitionen lohnen.

Der Umgang mit der Keyplayer-Falle

Wenn man sich des Phänomens der Keyplayer-Falle bewusst ist, wird man sich zweifellos Gedanken über angemessene Vorkehrungen machen. Angemessen heisst in diesem Fall, dass eine sinnvolle Balance zwischen Risikoabsicherung und Kostenminimierung zu suchen ist. Wie viel man dokumentiert und auf wie viele Personen das Applikationswissen verteilt wird, sollte dabei im Wesentlichen in Abhängigkeit zur geschäftlichen Bedeutung der Applikation beurteilt werden. Applikationen, die essenziell für Unternehmensprozesse sind, müssen besser abgestützt werden als Applikationen, die lediglich der Arbeitserleichterung dienen.

Herbert hat dies erkannt und lässt deshalb für jede Applikation die geeigneten Vorkehrungen treffen. Die damit verbundenen Probleme hat er bereits erkannt. Meist fehlt den betroffenen Teams die Kapazität und oft auch die notwendige Erfahrung, um die Massnahmen effizient und wirkungsvoll umzusetzen. In diesen Fällen empfiehlt es sich in der Tat, spezialisierte IT Dienstleister beizuziehen. Sie können nicht nur beratend unterstützen, sondern auch die Gesamtverantwortung für eine Applikation übernehmen. Neben Support, Wartung und Weiterentwicklung umfasst dies den garantierten Wissenserhalt zur Applikations-Software in Form einer strukturierten Dokumentation und eines Teams von Wissensträgern.

Unternehmen müssen also nicht zwingend in eine Keyplayer-Falle tappen - Grund genug, die Typical Story gut enden zu lassen.

Typical Story – Teil 4

Es ist wieder soweit. Bernhard fährt in den Urlaub. Diesmal führt seine Motorrad-Tour in die Türkei. Aber nicht nur sein Ferienziel hat sich geändert, sondern auch die Rahmenbedingungen. Diesmal weiss er nämlich, dass alle Vorkehrungen getroffen sind, um auch während seiner Abwesenheit auf Applikationsstörungen oder Änderungsanfragen zu reagieren. Im Hintergrund steht ein auf Applikationsbetreuung spezialisiertes Unternehmen bereit. Im Falle einer Störung steht es sofort unterstützend zur Seite. Die Berater dieses Unternehmens erstellten gemeinsam mit Bernhard eine Dokumentation und halfen anschliessend bei der Ausarbeitung eines Service-Konzepts, das beide Parteien miteinbezieht. Die Services des Dienstleisters sichern die Funktionsfähigkeit von Unikum in jedem Fall ab.
 
Zugegeben, Bernhard hatte sich anfangs etwas gesträubt, sein Spezialwissen aus der Hand zu geben. Insgeheim war vielleicht etwas Angst im Spiel - Angst, an Bedeutung zu verlieren. Es war jedoch genau umgekehrt. Die Wissensweitergabe hat seinen Wertbeitrag für die TypicalStory AG allen bewusst gemacht und ihm viel Anerkennung beschert. So lässt es sich entspannt in den Urlaub fahren.