"Compas" als Steigbügelhalter für die Standardsoftware:

Ohne Motivation der Endbenuter läuft nichts

03.01.1986

BERLIN (kul) - Höherer wirtschaftlicher Nutzen ist eines der Hauptargumente in der Diskussion um den Einsatz von Standardsoftware. Oft droht dem unbedarften Anwender jedoch eine Bauchlandung: Nicht nur technische Probleme werden zum Stolperstein, auch die Akzeptanz bei den Benutzern Iäßt oft zu wünschen übrig. Dies macht die "Compas '85" deutlich.

Die Frage, ob sich der Einsatz von Standardsoftware für den User auszahlt, reduziert Dr. Woldemar Hövel Projektleiter SW-Engineering beim Gerling-Konzern, Köln, auf einen Kernsatz: "Was kostet es, ein Produkt selbst zu erstellen, und was ist für eine entsprechende Standardsoftware zu bezahlen?" Bei einer solchen Kalkulation fallen seiner Ansicht nach die Nachteile einer Individuallösung - großer eigener Programmierstab, eigener Dokumentationsaufwand, langer Entwicklungszeitraum und hohe indirekte Kosten - meist so stark ins Gewicht, daß Vorteile wie schnelle Reaktionszeit und Unabhängigkeit auf der Strecke bleiben.

Auswirkungen auf das Systemumfeld prüfen

Die Lösung ist folglich meist, auf dem Markt vorhandene Standardsoftware als Modell für ein neues Anwendungssystem zu nutzen, meint auch Ulrich Busch, Leiter Managementberatung bei der Price Waterhouse GmbH Wirtschaftsprüfergesellschaft, Hamburg. Ob das verwendete Standardprodukt dann später auch als Softwarelösung zum Einsatz kommt, hängt für den Hamburger allerdings von weiteren technischen Anforderungskriterien ab. Insbesondere sei beispielsweise zu prüfen, welche Auswirkungen die neue Software auf das Systemumfeld hat.

Die Formulierung der organisatorischen Anforderungen müsse also mit dem Endbenutzer und allen übrigen Interessengruppen, beispielsweise der Arbeitnehmervertretung, jeweils abgestimmt sein, damit eine entsprechende Bestätigung der User-Wünsche erfolgen kann. Deshalb fordert Busch: "Die Vorbereitungen auf die Implementierung neuer Anwendungssysteme lassen sich nur dann vollständig lösen, wenn alle das neue System betreffenden Abhängigkeiten erkannt sind und als entsprechende Anforderungen formuliert werden."

Die mit der Neueinführung verbundenen Veränderungen der Ablauforganisation sollten deshalb frühzeitig mit dem Endbenutzer abgestimmt werden und zu einer entsprechenden Schulungsplanung führen. Noch zwei Tips hat der DV-Profi parat: Zum einen müsse der User mit Hilfe einer Pilot- oder Modell-Installation die Möglichkeit bekommen, seinen neuen Arbeitsplatz zu simulieren. Nur so könne er sich rechtzeitig auf veränderte Anforderungen einstellen.

Ob ein fertig gekauftes Programmpaket von seinen Benutzern gut angenommen wird, ist für Sabine Jausel-Hüsken von der Wiesbadener Innova Consulting auch eine Frage des Standardisierungsgrads: Manche Normen, so moniert sie, seien zu restriktiv. Sie sähen ihren Sinn darin, dem Benutzer bis ins letzte Detail vorzuschreiben, was er als nächstes tun soll und welche Form er für die Ergebnisdarstellung zu wählen hat.

Dabei werde keine Rücksicht darauf genommen, welche Aufgabe eigentlich zu lösen ist. Frau Jausel-Hüsken fordert deshalb: "Methoden sollen so standardisiert sein, daß sie von jedem Benutzer Integrationsfähigkeit erwarten. Sie dürfen aber nicht die notwendige Kreativität des Menschen beschneiden oder ersetzen"

Das Problem des persönlichen Freiraums stellt auch für Brigitte Bartsch-Spörl von der Münchner InterFace Concilium GmbH ein Kernproblem dar. Darüber hinaus hat sie festgestellt, daß die Akzeptanz eines Standard-Tools um so größer ist, je weniger Reibungspunkte es dem Benutzer bietet.

Die Einstellung zu Standard-Werkzeugen sei normalerweise um so positiver, je weniger die Mitarbeiter im Unternehmen von der Materie verstehen und selbst damit umgehen. Manager würden deshalb oft stolz auf die Vielzahl der in ihrem Unternehmen angeschafften Werkzeuge verweisen - während die Entwickler in genau demselben Unternehmen auf die existierenden Tools schimpften und sich gegen neue wehrten. Resümiert die Referentin: "Daß ein Tool in einem Unternehmen schon lange Zeit verfügbar ist, erlaubt keine Rückschlüsse darauf, daß es auch eingesetzt wird oder gar den erwarteten Nutzen bringt."

Akzeptanz ist abhängig von der Toolkonzeption

Es gebe sogar Werkzeuge mit einem relativ guten Image, deren Hersteller Schwierigkeiten hätten, einen Referenzkunden zu benennen, an den Kaufinteressenten mit gutem Gewissen verwiesen werden könnten. Leicht akzeptiert werden nach Erfahrung von Brigitte Bartsch-Spörl alle Tools, die tägliche Routinetätigkeiten unmittelbar erleichtern und genau eine leicht verständliche Aufgabe erfüllen. Ferner müßten sie eine selbsterklärende Benutzerschnittstelle haben und so gut in die vorhandene Umgebung passen, daß keine zusätzlichen organisatorischen Regelungen oder andere entscheidende Veränderungen am Arbeitsplatz nötig würden.

Mehr Aufmerksamkeit erforderten komplexere, methodenneutrale Werkzeuge, die eine gewisse Anlaufzeit benötigen, ehe ihr Nutzen spürbar wird. "Meist lassen solche Tools sich erst dann adäquat nutzen", weiß die InterFace-Mitarbeiterin zu berichten, "wenn sich der User eine zutreffende Modellvorstellung des gesamten Aufgabenspektrums gebildet hat"

Erschwerend komme hinzu, wenn ein schrittweises Vertrautwerden mit der handwerklichen Benutzung des Werkzeugs erforderlich sei und Maßnahmen zur Integration des Tools in die vorhandene Umgebung nötig würden, vor allem, wenn solche Modifikationen nicht nur softwaretechnischer, sondern auch ablauforganisatorischer Natur seien.

Eine hohe Akzeptanzschwelle haben laut Frau Bartsch-Spörl komplexe, methodenabhängige Tools, die ihren Nutzen oft erst nach Abschluß eines Pilotprojekts unter Beweis stellen können. Oft werde auch ein ziemlich weitgehendes Umdenken vom Benutzer verlangt. Probleme verursachten auch Werkzeuge, die entscheidende Veränderungen der gesamten Arbeitsweise sowohl beim einzelnen Benutzer als auch in seinem softwaretechnischen und organisatorischen Umfeld bewirken. Besonders erschwerend wirke sich allerdings aus, wenn die Handhabung der Werkzeuge in einer Phase erlernt werden müsse, in der die Anwender auch mit der eigentlichen Methode noch nicht genügend vertraut seien.

Auch den "Restmarkt" im Auge behalten

Als sehr übel vermerkt die Münchnerin, daß beim User bezüglich Standardsoftware oft übertriebene Erwartungen geweckt werden: "Verkäufer vermitteln nicht selten die Illusion, der Kunde könne sämtliche Schwierigkeiten seiner Software-Entwicklung mit dem angebotenen Werkzeug quasi über Nacht in den Griff bekommen. Wenn dieses Wunder hinterher nicht eintritt, wird das Tool schnell zum Sündenbock für alle nach wie vor ungelösten Probleme dieser Umgebung."

Auf ungenügende oder falsche Informationen vor dem Softwarekauf führt auch Woldemar Hövel, Projektleiter SW-Engineering bei Gerling in Köln, die meisten Probleme zurück, die in Zusammenhang mit Standardprodukten entstehen. Von entscheidender Bedeutung sei beispielsweise, nicht nur über Produkte Bescheid zu wissen, die unmittelbar für das eigene Unternehmen relevant sind; vielmehr müsse auch der "Restmarkt" im Auge behalten werden.

Aus eigener Erfahrung empfiehlt Hövel deshalb den potentiellen Kunden einen intensiven und langjährigen Kontakt zu Herstellern und - vor allem - anderen Anwendern sowie ein ständiges kritisches Hinterfragen nach konkreten Lösungsansätzen und Erfahrungen anderer User.

Eine "hemdsärmelige" Vorgehensweise bei der Auswahl eines Standardpakets propagiert Walter Saar, KG Bayerische Hausbau, München. Als Ziel dieser Strategie nennt er, die Anzahl der möglichen Anbieter in der ersten Phase restriktiver Selektion auf maximal fünf zu reduzieren, ohne eine detaillierte Überprüfung vornehmen zu müssen.

Dies setze eine genaue Anforderungsdefinition vor Angebotseinholung voraus. Saar: "Die Tatsache, daß auf diese Weise viel Zeit gespart wird, macht es möglich, sich auf die Bewertung der wirklich entscheidenden Software-Features zu konzentrieren."

Finanzdecke des Anbieters muß stimmen

Eine besondere Rüge bekommt die Industrie von Woldemar Hövel: "Besonders böse", so warnt der Kölner, "kann die Sache ausgehen, wenn das Schwergewicht der Untersuchungen nur dem Steckenpferd der Hersteller - der Benutzeroberfläche- gilt und Angaben über die Effizienz der Software unter den Tisch gekehrt werden."

Aber selbst bei Berücksichtigung all dieser technisch und psychologisch orientierten Aspekte, so kristallisierte sich in Berlin heraus, läßt sich das Problem mit der Standardsoftware meist immer noch nicht in den Griff bekommen. Die Bonität des Herstellers spielt eine mindestens ebenso entscheidende Rolle. Resümiert Hövel: "Das Ergebnis einer sorgfältigen Auswahl kann durchaus das vom softwaretechnischen Standpunkt zweit- oder drittrangige Produkt sein, wenn der besseren Software eine marode Geschäftspolitik des Herstellers zugrunde liegt. Ein gutes Produkt ist schnell überholt wenn der Anbieter pleite macht."