Ein "Abschalten" der Altanwendungen wird in der Regel ebensowenig in Frage kommen wie eine schnelle Migration auf eine moderne Produktionsumgebung. Andererseits ist die weitere Einsetzbarkeit der Altsoftware begrenzt. In dieser Situation hat sich die Durchfuehrung einer "Software-Inventur" bewaehrt. Ziel einer solchen Inventur ist es, den Bestand der im Unternehmen vorhandenen Software zu identifizieren und in Hinblick auf die damit verbundenen

Nutzen- und Risikopotentiale zu bewerten.

Von Peter Windhoefel*

Erster Schritt einer Software-Inventur ist die Identifikation der im Einsatz befindlichen Anwendungen. Es hat sich bewaehrt, als ersten Schritt hierzu das Unternehmen modellhaft in Form einer Wertschoepfungskette darzustellen, ueber deren einzelne Glieder die jeweils unterstuetzenden IV-Anwendungen abgetragen werden (vgl. Abb. 1). Die so identifizierten Anwendungen sind sodann in einem weiteren Schritt zu bewerten. Diese Bewertung sollte zunaechst in einer eher freien Form erfolgen, um IV-Abteilungen, Anwender der Fachabteilungen sowie gegebenenfalls die Unternehmensleitung moeglichst unkompliziert einbeziehen zu koennen. Es hat sich als sinnvoll herausgestellt, eine solche Bewertung im Rahmen eines Workshops durchzufuehren, um die Anwendungen jeweils nach folgenden Kriterien zu beurteilen:

- Funktion: Welche betrieblichen Funktionen unterstuetzt die Anwendung?

- Anwender: Er nutzt die Anwendung? Wie oft? Wie intensiv?

- Nutzen: Was wird mit der Anwendung erreicht? Was traegt diese Anwendung zur Wertschoepfung bei?

- Strategie: Welche Wettbewerbsvorteile bietet die Anwendung?

- Risiko: Was wuerde passieren, wenn die Anwendung nicht zur Verfuegung stuende? Wie oft faellt die Anwendung aus? Wie hoch ist der aktuelle Aufwand fuer Wartung und Pflege?

-Perspektive: Wird diese Anwendung auch in einem, drei oder fuenf Jahren noch benoetigt? Welche Anforderungen muss die Anwendung dann erfuellen?

Uebersicht ueber die Anwendungslandschaft

Auf diese Weise entsteht eine aktuelle Uebersicht der Anwendungslandschaft eines Unternehmens, in der auch die Einschaetzung der Anwender enthalten ist und die so bereits ein erstes Bild von den Nutzen, Risiken und Potentialen der eingesetzten Anwendungen liefert.

Dieses Bild gilt es nun, in einem zweiten Schritt weiter zu objektivieren. Hierzu werden die in dem erwaehnten Fragenkatalog enthaltenen Beurteilungskriterien in zwei Schluesselgroessen zusammengefasst. Es ist empfehlenswert, die Indikatoren "Produktivitaet" (verstanden als Beitrag zur Wertschoepfung) sowie "Grad der Komplexitaet" einer Anwendung zu bilden.

Diese beiden Werte spannen gemeinsam ein Kraeftefeld auf, in dem jede Anwendung ihren Platz identifizieren und einnehmen muss: Einerseits muss eine Anwendung ihren Beitrag zur Wertschoepfung des Unternehmens leisten, andererseits aber so ueberschaubar, beherrschbar und stabil sein, dass ihre Handhabung, der Betrieb und die Wartung mit vernuenftigem Aufwand zu gewaehrleisten sind.

Beide Indikatoren werden mit Punkten von 1 bis 5 bewertet, wobei man zur Sicherstellung der Objektivierbarkeit einen Kriterienkatalog heranzieht, in dem Einflussfaktoren fuer "Produktivitaet" und "Komplexitaet" identifiziert und bewertet werden.

Solche Einflussfaktoren sind zum Beispiel fuer die Kenngroesse "Produktivitaet":

-Koennte das Unternehmen grundsaetzlich ohne diese Anwendung auskommen?

-Welche zusaetzlichen Kosten wuerden bei Wegfall dieser Anwendung entstehen?

-Hat die Anwendung Auswirkungen auf die Produktivitaet in der Produktion, in der Logistik oder im Vertrieb?

-Erlaubt die Anwendung die bessere Auslastung der vorhandenen Kapazitaeten?

-Wie viele Anwender arbeiten mit dieser Anwendung? Wie oft?

-Hat die Anwendungen direkte Auswirkungen auf ein- oder ausgehende Zahlungen?

Zur Ermittlung der Groesse "Komplexitaet" werden unter anderem folgende Kriterien herangezogen:

- Welche Kosten sind in den letzten sechs Monaten fuer Wartung und Pflege angefallen?

- Wieviel davon war echte Fehlerbehebung?

- Wie oft stand die Anwendung in den letzten sechs Monaten wegen eines Anwendungsfehlers nicht zur Verfuegung?

- Wie viele Mitarbeiter sind permanent oder ueberwiegend mit der Anwendungsbetreuung befasst?

- Wie viele Programme, Masken und Listen sind Bestandteil der Anwendung?

- Existiert eine aktuelle Dokumentation der Anwendung?

Diese - hier nur ausschnittsweise aufgefuehrten - Kriterien und Einflussfaktoren werden in zwei separaten Tabellen ermittelt und zum Teil verschieden gewichtet. Auf diese Weise entstehen pro Anwendung zwei Schluesselwerte, die, in einer Portfolio-Matrix abgetragen, einen grafischen, schnell fassbaren Ueberblick ueber die Anwendungs-Topologie eines Unternehmens bieten (vgl. Abb. 2). Diese Darstellung erlaubt - ganz unabhaengig von allen Ueberlegungen und Wertungen etwaiger Altlasten - allen Beteiligten bis hin zur Unternehmenleitung, jede Anwendung auf ihren Stellenwert fuer das Unternehmen hin zu beurteilen.

Dies ist in vielen Unternehmen noch nie erfolgt und ermoeglicht oft ein ganz neues Verstaendnis der betrieblichen DV. Setzt man zum Beispiel die Kosten beziehungsweise den Aufwand fuer die Entwicklung einer Anwendung (sofern solche Werte verfuegbar sind) in Beziehung zur Position dieser Anwendung in der Matrix, so laesst sich schnell beurteilen, ob bestimmte Ausgaben fuer die Datenverarbeitung in der Vergangenheit gerechtfertigt waren oder kritisch zu sehen sind.

Analog lassen sich geplante Anwendungsprojekte bereits im Vorfeld auf ihre Position in der Portfolio-Matrix ueberpruefen, die auch wieder zu den geplanten Kosten in Beziehung gesetzt werden kann. Auch fuer die langfristige Planung innerhalb einer IV- Rahmenkonzeption ist der Matrix zu entnehmen, in welchen Bereichen man bevorzugt Investitionen fuer Neu- und Weiterentwicklungen taetigen sollte und welche Bereiche eher zurueckhaltend zu bedenken sind.

Auf diese Weise eingesetzt ist die Software-Inventur nicht nur eine Bestandsaufnahme, sondern auch ein konstruktives Werkzeug im Rahmen eines IV-Controlling und bei der Orientierung der Informatik auf die unternehmerischen Zielsetzungen.

Handlungsbedarf grafisch dargestellt

Aber auch in bezug auf die DV-Altlasten bietet die Software- Inventur vielfaeltige Moeglichkeiten. So wird kann man ganz konkret die in den Quadranten I und II angesiedelten Anwendungen daraufhin ueberpruefen, ob und in welchem Umfang sie wirklich auch in Zukunft am Leben zu erhalten sind.

Konkreter Handlungsbedarf laesst sich auch fuer die Anwendungen in den Quadranten II und III ableiten, also fuer die Anwendungen mit erhoehter Komplexitaet. Hier ist zu pruefen, inwieweit diese Komplexitaet auf Dauer noch beherrschbar bleibt und welche Moeglichkeiten es gibt, die Komplexitaet zu reduzieren, ohne dass die Produktivitaet darunter leidet.

Geht es darum, den Aufwand fuer die Wartung und Weiterentwicklung zu budgetieren, so wird man die Anwendungen in den Quadranten I und II eher nachrangig behandeln und den Schwerpunkt auf die Anwendungen in den Quadranten III und IV legen, die sehr viel mehr Bedeutung fuer das Kerngeschaeft haben.

Plant man dagegen die Auslagerung der Informationsverarbeitung im Rahmen eines Outsourcing-Vertrages, kommen gerade die Anwendungen in I und II bevorzugt fuer eine Auslagerung in Frage, um Kapazitaeten fuer die Planung und Entwicklung neuer, zukunftsorientierter Anwendungssysteme freizusetzen.

Wie man sieht, sind die Anwendungsmoeglichkeiten einer Software- Inventur so vielfaeltig, dass ihre vollstaendige Eroerterung den Rahmen eines solchen Artikels sprengen wuerde. Es genuegt an dieser Stelle der Hinweis, dass - wie jedes andere Werkzeug beziehungsweise jede andere Methode - auch die Software-Inventur einer Anpassung an die unternehmensspezifischen Ziele und Planungen bedarf, um erfolgreich einsetzbar zu sein.

Unter anderem deshalb ist eine Software-Inventur immer als eigenstaendiges Projekt zu definieren, fuer das - je nach Unternehmensgroesse - ein Zeitbedarf von sechs Monaten an aufwaerts zu veranschlagen ist.

Gleichzeitig ist zu beruecksichtigen, dass auch ein Software- Inventar nichts statisches ist. Neben der bereits erwaehnten Fortschreibung im Rahmen einer IV-Rahmenkonzeption und der Projektarbeit empfiehlt der Verfasser, die komplette Bestandsaufnahme zirka alle drei bis fuenf Jahre zu wiederholen. Nur auf diese Weise laesst sich sicherstellen, dass der technologische Fortschritt, Aenderungen der betrieblichen Umwelt und Verlagerungen der unternehmerischen Schwerpunkte auch in die Bewertung der eingesetzten Software einfliessen.

Wichtig ist auch, dass die Unternehmensleitung eine Software- Inventur von Anfang an foerdert und unterstuetzt. Eben weil eine Software-Inventur gerade die Altlasten mit all ihren Schwaechen und Risiken transparent macht, ist es wichtig, vor allem auch die konstruktive Seite hervorzuheben. Auf keinen Fall darf der Eindruck entstehen, dass die Software-Inventur Fehler der Vergangenheit entlarven und Schuldige identifizieren soll.

Abschliessend sei darauf hingewiesen, dass die Durchfuehrung einer Inventur nicht zwangslaeufig auf Individualsoftware beschraenkt sein muss, auch wenn sich der vorliegende Artikel wegen der besonderen Betonung der Altlasten darauf konzentriert.

Auch die als kostenguenstig apostrophierte Standardsoftware muss sich innerhalb des Kraeftefeldes aus Komplexitaet und Produktivitaet positionieren und sich im Wettbewerb gegen Individualsoftware behaupten.

Eine vergleichende Betrachtung von Standard- und Individualsoftware ist durchaus gerechtfertigt und kann unter Umstaenden zu verblueffenden Ergebnissen fuehren.

* Peter Windhoevel ist Berater fuer Informations-Management in Dossenheim.