Die häufig praktizierte Form der Standardsoftware-Einführung mit den Methoden, Verfahren und Tools der Eigenentwicklung oder mit Universalmethoden stellt sich ziemlich schnell als unbefriedigend heraus. Der Grund: Bei der Einführung von Standardsoftware ändern sich die Projektaktivitäten grundlegend. Gerd Pfister* zeigt anhand eines Beispiels, wie eine solche Einführung laufen kann.

Immer mehr Aufgabenstellungen der lnformationsverarbeitung werden nicht mehr durch Eigenentwicklung, sondern durch den Einsatz von Standardsoftware abgedeckt, und dieser Trend dürfte weiter zunehmen; denn die Qualität der heute angebotenen Standardsoftware befindet sich auf hohem Niveau.

Dennoch bleiben viele Vorteile auf der Strecke, weil sich die Einführung der Standardsoftware oftmals problematischer gestaltet, als man annimmt. Die wesentlichen Gründe dafür sind der fehlende Einsatz eines geeigneten Projekt-Management-Systems und sie unzureichende maschinelle Unterstützung bei der Projektdurchführung.

Im wesentlichen unterscheidet sich die Einführung von Standardsoftware im Vergleich zu üblichen SW-Verfahren durch folgenden Kriterien:

- Bei Standardsoftware ist das tieue DV-System (außer Schnittstellen-beziehungsweise Datenübernahmeprogramme) vom ersten Projekttag an vorhanden, so daß sich die Projektaktivitäten zwangsläufig von der Programmierung zur Organisation verlagern.

- Bereits nach Auswahl der Standardsoftware sind das zukünftige betriebswirtschaftliche System und Ablauforganisation weitestgehend vorgeprägt, weil keine Standardsoftware so flexibel ist, daß alle firmenspezifischen Wege einfach übernommen werden können. Daher ist es unbedingt erforderlich, daß die Organisation der Standardsoftware angepaßt wird.

Änderung der Grundlagen - Änderung der Ausbildung

Da sich die Projektaktivitäten bei der Einführung von Standardsoftware grundlegend ändern, erfordert es notwendigerweise nicht nur geeignete Methoden, Verfahren und Tools. Auch bei der Ausbildung der Mitarbeiter muß dies entsprechend berücksichtigt werden. Da Firmen zum Teil schon über 50 Prozent der Aufgabenstellungen durch Standardsoftware abdecken, ist es verwunderlich, daß die Ausbildung der ORG-/ DV-Mitarbeiter immer noch sehr stark auf die Belange der Eigenentwicklung abgestellt ist. Cobol, strukturierte Programmierung, CASE etc, helfen wenig bei Einführung von Starndardsoftware.

Ohne Berücksichtigung der veränderten Rahmenbedingungen ist häufig folgende Situation anzutreffen: Das Rad wird immer wieder neu erfunden. Wenn für die Einführung von Standardsoftware kein geeignetes Projekt-Management-System vorhanden ist, muß das Projektteam bei jedem Projekt beziehungsweise Chargenwechsel immer wieder die gleichen Punkte regeln, wie zum Beispiel:

- Projektvorgehensweise,

- Projektplatiung,

- Auswahl der Aktivitäten,

- Reihenfolge der Aktivitäten,

- Definition der einzelnen Aktivitäten,

- Art der Dokumentation,

- Auswahl der Tools sowie

- Vorgehensweise der Projektsteuerung und -kontrolle.

Die Erfahrutig zeigt, daß nach Abschluß der Projektvorphase - die häufig mehrere Wochen dauert - wenig festgelegt ist. Selbst beim Einsatz von teuren externen Beratern ist oft noch leicht einmal ein von allen getragener "Projektaktivitätenplän" vorhanden, so daß auch kein Termin beziehungsweise Ressourcenplan vorliegen kann geschweige eine klare Regelung, wie die einzelnen Aktivitäten durchzuführen sind beziehungsweise leistungsfähige Tools vorliegen, die bei der Projektdurchführung eine echte Hilfe darstelle.

Obwohl wenig geregelt wurde, beginnt das Projektteam mit der Arbeit. Dadurch sind viele Irr- und Umwege während der Projekdurchführung programmiert. Von Zeit zu Zeit wird versticht, diese Mängel in den Griff zu bekommen, nach dem Motto: "Wir müssen uns mal zusammensetzen", damit alle den gleichen lnformatiotisstand haben. Aber alle diese Versuche enden immer wieder ohne befriedigendes Ergebnis. Unter diesen Umständen läßt sich auch kein gutes Ergebnis erzielen, weil es sowohl für eine einzelne Firma und erst recht für ein einzelnes Projekt viel zu aufwendig wäre, ein ausgereiftes, von allen akzeptiertes Projekt-Management-System zu entwickeln.

Bei der Eigenentwicklung ist es unbedingt erforderlich, daß das Unternehmen zunächst die Anforderungen an das neue System detailliert festlegt, weil man ohne diese Anforderungen das passende DV-System nicht programmieren kann.

Wenn diese Vorgehensweise auch bei Einführung von Standardsoftware angewendet wird, was häufig geschieht, ist das der Anfang vielele Probleme was nachfolgender Ablauf zeigt:

Erstes Problem: Anforderungen an das neue System definieren. Der Projektleiter fordert die Projektbeteiligten auf, die Anforderungen an das neue System möglichst detailliert darzustellen. Es stellt sich nun die Frage, warum die Mitarbeiter diese Arbeit durchfuhren sollen, denn wenn ein komplett fertiges Auto (die Standardsoftware) gekauft wurde, ist es einerseits nicht mehr notwendig,

ein neues zu konstruieren. Andererseits entsteht viel unnötiger Aufwand, weil häufig ein mix zwischen einem Mercedes und einem Trabbi entsteht.

Zweites Problem. Abgleich der Anforderungen rnit der Standardsoftware. Mit den mehr oder weniger guten Anforderungen und dem zu die, sein Zeitpunkt dürftigen Standardsoftware-Wissen prüft das Projektteam in aufwendigen Abstimmrunden, ob die Standard-Software die Anforderungen abdeckt. Natürlich ist bei dieser Vorgehensweise nicht, zu vermeiden, daß viele Punkte nicht passen.

Drittes Problem: Anforderungen, die nicht passen, werden wegdiskutiert. Da heute jedes Projekt den Gundsatz hat "Die Standardsoftware soll nicht modifiziert werden", ist das dritte Problem nicht zu vermeiden. Denn Standardsoftware wirklich nicht zu modifizieren heißt:

- Verzicht auf alle Anforderungen, die nicht init der Standardsoftware übereinstimmen. Das schafft Frustrationen wenn man kurz vorher in mühevoller Arbeit die Anforderungen definiert hat.

- Die ersten Standardsoftware-Modifikationen werden festgeschrieben, unabhängig davon, ob sie wirklich notwendig sind, weil es einfach gegen die menschliche Natur ist, "immer nachzugeben". Folge: Die Akzeptanz hinsichtlich der Standardsoftware sinkt beträchtlich.

Diesen Problemkreis, der letztlich die Folge einer rnangelnden Anpassung der Vorgehensweise an die eingangs beschriebene geänderte Ausgangssituation sei der Einführung von Standardsoftware ist, durchbricht das nachfolgend beschriebene System, welches eine Kompaktlösung in bezug auf Projekt-Management, Vorgehensweise, Akzeptanzprobleme, Handling etc. darstellt und damit eine eihte Hilfe bietet.

Die maschinell hinterlegte Lösung

Um die Einführung von Standardsoftware zu erleichtern, hat BSE ein praxiserprobtes, Softwarehaus-unabhängiges Projekt-Management-System/Projekt, vorgehens-System entwickelt (siehe Abbildung 1), das sich durch folgende Eigenschaften auszeichnet:

- Die Projektabwicklung vom ersten "Spatenstich" bis zur Systemeinführung/Wartung ist geregelt.

- Sofort bei Projektstart kann allen Beteiligten der komplette Projektablauf detailliert dargestellt werden.

- Bei allen Projektaktivitäten ist eine Dialogunterstützung sichergestellt.

Der Schwerpunkt der Projektkünftigen Ablauforganisation erfolgt im Organisations-Prototyping (siehe Abbildung 2)

Statt vorab detaillierte Anforderungen an das neue System zu definieren, wird auf Basis der unveränderten Standardsoftware ein Prototyp der zukünftigen Ablauforganisation entwickelt (Prototyp 0), wobei es unbedingt erforderlich ist, daß die Fachbereiche intensiv mitarbeiten.

Entscheidend ist, daß bei der Entwicklung des Prototyps 0 mögliche Software-Modifikationsanforderungen aufgezeigt, aber noch nicht DV-technisch realisiert werden, weil erfahrungsgemäß mit zunehmendem Software-Know-how die Mehrzahl der Modifikationsanforderungen entfällt. Erst wenn alle Beteiligten den Leistungsumfang der Standardsoftware detailliert kennen, wird abschließend entschieden, ob Modifikationen unbedingt notwendig sind.

Dadurch lassen sich auch die immer wiederkehrenden Chargenwechselkosten auf ein Minimum reduzieren. Nach der Entwicklung des Prototyps 0 und Prototyps 1 entsteht die Produktivversion. Aufgabenschwerpunkte bei der Entwicklung von Prototyp 0 sind:

- Softwarefunktionen/-handling kennenlernen und festlegen, welche Funktionen benötigt werden,

- firmenspezifische Ablauforganisation auf Basis der unveränderten Standardsoftware konzipieren sowie

- Schnittstellen- und Datenübernahmeprogramme konzipieren.

Bei der Entwicklung von Prototyp 1 liegt der Aufgabenschwerpunkt darin, die firmenspezifische Ablauforganisation endgültig festzulegen - notwendige DV-technische Anpassungen beziehungsweise Ergänzungen sind zu realisieren.

Aufgabenschwerpunkte bei der Einrichtung der Produktivversion:

- Simulation des Produktivbetriebs,

- Schulung der Endanwender und

- Übernahme beziehungsweise Erstaufbau der Grunddaten.

Der maschinell hinterlegte Musterprojekt-Aktivitätenplan beinhaltet bereits, welche Aktivitäten, in welcher Reihenfolge durchzuführen und welche Checkpoints zu beachten sind. Das Wälzen von Methodenhandbüchern entfällt also.

Eine exakte Beschreibung sämtlicher Projektaktivitäten mit Ergebnismustern, aus denen hervorgeht, was wie zu tun ist, liegt ebenso vor wie die Struktur der gesamten Projektergebnis-Dokumentation. Da alle Projektaktivitäten durch leistungsfähige Dialogsysteme - unterstützt werden, entfallen auch die bei Projektstart üblichen Tool-Diskussionen.

Ein Großteil der Projektdokumentation wird über Datenbanken abgewickelt, die sicherstellen, daß viele aufwendige Dokumentationsschritte entfallen, weil sich einmal erfaßte Daten nach mehreren Kriterien auswerten lassen. Selbst reine Textteile werden in maschinell hinterlegten Dokumentations-Rastern eingegeben.

Durch die Prototypingware-Datenbank sind bei der Projektdurchführung so schwierige Komplexe wie etwa:

- zukünftige Ablauforganisation,

- Geschäftsvorfälle,

- Modifikationsverwaltung sowie

- SAP-Tabellenpflege

mit erheblich weniger Aufwand durchzuführen.

Automatisch ist ein Informationssystem für die Projektwartung mit optimaler Unterstützung bei einem Release oder Chargenwechsel vorhanden. Darüber hinaus stehen sämtliche Projektdaten per Knopfdruck zur Verfügung und werden in professionell optischer Präsentation veranschaulicht.

Eigene DB-Anwendungen und gekaufte Software

Das Gesamtsystem wird durch das Prototypingware-Menü gesteuert, das heißt für alle Projektbeteiligten ist sichergestellt, wo die jeweiligen Projektdaten zu hinterlegen beziehungsweise im Dialog abzurufen sind.

Die umfassende maschinelle Unterstützung basiert auf einer Kombination aus eigenentwickelten Datenbankanwendungen und leistungsfähiger gekaufter Software. Zusätzliche Tools sind einerseits nicht erforderlich andererseits ist das Prototypingware-System so flexibel, daß eigene im Handling vertraute Tools eingebunden werden können (siehe Abbildung 3). Das integrierte Gesamtsystem ist netzwerkfähig.

Der Leistungsumfang ist schnell definiert

Die umfassende Dialogunterstützung, die vorgefertigten Lösungen und die klaren Regeltingen stellen automatisch sicher, daß auch für externe Mitarbeiter viele aufwendige Aktivitäten entfallen und eine effiziente Steuerung und Kontrolle möglich ist.

Bereits bei der Auswahl von externen Mitarbeitern spart das Unternehmen, weil der gewünschte Leistungsumfang schnell definiert ist und die Angebote vergleichbar sind.

*Gerd Pfister ist Geschäftsführer der BSE Untemehmensberatung, Hamburg.