Sechs Tipps für eine bessere Anwendungsentwicklung

20.06.2007
Obwohl betriebswirtschaftliche Standardsoftware überall auf dem Vormarsch ist, schlucken große Individualanwendungen in vielen Unternehmen immer noch einen Gutteil der IT-Ressourcen. Mit einigen Regeln lässt sich der Kostenblock unter Kontrolle bekommen.

Für Anwendungsentwicklung und –wartung geben Unternehmen weltweit Unsummen aus – auch weil sie das Management der Applikationen vernachlässigen oder nicht beherrschen. Den Beratern von McKinsey zufolge gibt es verschiedene Gründe, warum die Großanwendungen so schwer in den Griff zu bekommen sind. Sie sind komplex, werden von Anwendern und Support-Personal nur unzureichend verstanden, und wenn sie ausfallen, sind die Schäden oft beträchtlich, handelt es sich doch meist um geschäftskritische Applikationen.

Die Management-Beratung empfiehlt im Rahmen ihres "Lean"-Programms (mit Personalabbau hat es nichts zu tun!), im Unternehmen folgende sechs Kompetenzen aufzubauen, mit denen sich komplexe Individualsoftware effizient verwalten lässt.

  1. Requirements Management: Die Veränderungen der Anforderungen im Verlaufe eines Projektzeitraums zu erkennen, ist absolut essenziell. Entwicklerteams müssen früh mit den Anwendern in den Fachabteilungen zusammenarbeiten, um ihre Anforderungen priorisieren und ihnen die nötigen Ressourcen zuweisen zu können. Wer diesen Prozess beherrscht, kann den Beratern zufolge Produktivitätsgewinne von zehn bis 15 Prozent erzielen.

  2. Personelle Besetzung: In vielen Entwicklungsabteilungen sind die Manager nicht fähig, die richtige Person zur rechten Zeit für ein bestimmtes (Teil-)Projekt abzustellen. Das führt zu Engpässen im Entwicklungsprozess. Eine Zusatzausbildung der Entwickler, die sich mit verschiedenen Tools und Anwendungen auskennen sollten, kann zumindest teilweise Abhilfe schaffen.

  3. Flexibles Sourcing: McKinsey beobachtet in den IT-Abteilungen großer Konzerne, dass Entwicklerteams im Durchschnitt nur zehn bis 20 Prozent ihrer Kapazitäten offshore beziehen. Das sei zu wenig. IT-Organisationen unterschätzten, wie viel Arbeitszeit für einfache Routinearbeiten verloren geht – etwa für das Pflegen und Testen nichtkritischer Systeme. Würden die Zuständigkeiten der Entwickler neu definiert, ließen sich diese Aufgaben in Billiglohn-Regionen auslagern. Die eigenen Entwickler könnten sich auf anspruchsvollere Aufgaben wie Lösungs- und Architekturdesign konzentrieren. Zum zweiten könnten Entwickler ihr Wissen besser untereinander weitergeben. McKinsey hat entdeckt, dass in (zu) vielen Firmen geschäftskritische Skills und Informationen in den Händen von ein oder zwei Personen liegen.

  4. Prozess-Standardisierung: In der Vergangenheit haben Firmen Tools wie das Capability Maturity Model benutzt, um Prozesse zu standardisieren. Laut McKinsey sind solche Werkzeuge aber nicht unbedingt geeignet, um Flaschenhälse in den Abläufen zu beseitigen. Viele Unternehmen hätten Probleme, Projektverantwortlichkeiten von einem Mitarbeiter auf einen anderen zu übertragen. Das führe zu erheblichen Verzögerungen. Eine standardisierte Übergabeprozedur, in der derjenige, der das Projekt weitergibt, für den reibungslosen Ablauf verantwortlich ist, könne Abhilfe schaffen.

  5. Komplexität herausnehmen: Die Leiter von Entwicklungsabteilungen sollten ihre Management-Aufmerksamkeit priorisieren und nach dem Ressourcenhunger der einzelnen Projekte ausrichten. Wichtige Orientierungsgrößen sind dabei die Größe der Vorhaben, ihre Komplexität und die Häufigkeit, in der sich Anforderungen ändern. Werden Projekte dementsprechend sortiert, können Manager die ressourcenintensiveren besser beobachten und kontrollieren beziehungsweise zweitrangigen Projekten mehr Autonomie zugestehen.

  6. Performance-Management: Anstatt den Erfolg von Projekten individuell zu bewerten, sollten Entwicklerteams Standarddefinitionen für bestimmte Arbeitsvorgänge festlegen und sich auf akzeptable Fehlerquoten einigen. Ziel müsse es sein, dem Management und dem Team nachvollziehbare Effizienz- und Produktivitäts-Metriken liefern zu können. Andererseits gelte es aber ebenso den Beteiligten ausreichend Spielraum für einen kreativen Entwicklungsprozess zu gewähren. Möglich sei beispielsweise, die Anzahl der Vorfälle im Wartungsprozess über längere Zeiträume anhand von Metriken zu verfolgen und zu beobachten, ob sich etwas verbessert oder verschlechtert.

McKinsey räumt ein, dass diese Empfehlungen nicht einfach zu beherzigen sind. Während technische Herausforderungen lösbar seien, werde es dort schwierig, wo sich das Management-Verhalten ändern müsse. Wer Ziele top down setze, Performance-Lücken nachspüre und permanent Leistungen messe, müsse mit Widerstand rechnen. Trotzdem sei der Umbau wichtig.

Schwierig wird es vor allem dort, wo die Denk- und Verhaltensweisen der Mitarbeiter verändert werden müssen. Wo restrukturiert wird, blüht die Angst vor Einschnitten und Jobverlust. Viele IT-Abteilungen stehen ohnehin ständig unter dem Druck, kurzfristige Cost-cutting-Ziele zu erreichen. Entscheidend ist daher laut McKinsey, dass es gelingt, eine langfristige Perspektive aufzuzeigen. Es geht um Flexibilität und Qualität, nicht um Entlassungen - das müsse den Mitarbeitern zu Beginn deutlich gemacht werden.

Kommunikation sei wichtig, ebenso aber das Aufsetzen eines gut durchdachten Pilotprojekts. Letzteres trage dazu bei, den Mitarbeitern aufzuzeigen, wie sich Durchlaufzeiten verkürzen und Arbeitsrückstände vermeiden lassen und die dabei frei werdenden Kapazitäten für neue, sinnvollere Arbeiten genutzt werden können. (hv)