Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

17.07.1987 - 

Einführung von Standardsoftware erfordert besondere organisatorische Maßnahmen (Teil 2):

Die eigentliche Arbeit kommt nach dem Kauf

Auswahl und Kauf einer Standardsoftware bedeuten nur etwa 15 Prozent der notwendigen Einführungsleistung. Die schwierigste Aufgabe ist auch nicht die individuelle Anpassung, sondern die Einbindung in die Unternehmensorganisation. Unterschiede zur individuell entwickelten Software gibt es vor allem bei der Benutzerakzeptanz. Karl-Heinz Dette* schildert Probleme und Lösungen anhand der Einführung eines integrieren Softwarepakets bei der Monheimer Schwarz GmbH.

Da Standardsoftware nicht auf einer organisatorischen grünen Wiese eingesetzt wird, läßt sich eine gewisse Anpassung nicht ganz vermeiden. Zumindest muß dieses Paket an das bestehende Softwareumfeld angepaßt werden oder umgekehrt, je nach Aufwand.

Doch auch individuelle programmtechnische Modifikationen sind manchmal unumgänglich. Änderungswünsche sollten in enger Zusammenarbeit mit dem Softwarehersteller besprochen werden und auf Standardisierbarkeit hin überprüft werden, denn auch Standardsoftware lebt vom User-Feedback.

Auf diese Weise konnten wir rund 70 Prozent unserer damaligen Modifikationen durch verbesserte Standardversionen abgelöst werden. Es war aber nicht zu verkennen, daß man seinerzeit schon geneigt war, diesem Standardpaket einen eigenen Stempel aufzudrücken!

Implementierungszeit ausreichend bemessen

Es kamen plötzlich kreative Höhenflüge auf, die einer Nutzen-Aufwands-Betrachtung nicht standgehalten hätten. Positiv betrachtet läßt sich hieraus der große Nachholbedarf und darüber hinaus eine gewisse Identifikation mit den neuen Möglichkeiten ablesen.

In solchen Situationen ist die Projektleitung gefordert, durch eine sachliche Argumentation überzogene Forderungen ohne Akzeptanzverlust in die rechte Bahn zu lenken. Hier sollte immer der Grundsatz gelten: "Eine ausreichende 80-Prozent-Lösung ist besser als eine 150-Prozent-Lösung".

Mit diesem übertriebenen Beispiel werden einige wesentliche Punkte angesprochen:

- Man sollte sich nie zuviel vornehmen.

- Die innere Bereitschaft (Akzeptanz) muß vorhanden sein.

- Das Ziel und die Vorteile sollten klar dargestellt werden.

- Auf die eventuell vorhandenen Bedenken und Ängste der Mitarbeiter aller Ebenen sollte eingegangen werden.

- Die Implementierungszeit sollte ausreichend bemessen werden, da es sich hierbei nicht nur um einen technischen Vorgang handelt.

- Die Schulungsaktivitäten sollten gut vorbereitet, zeitlich ausreichend und möglichst in kleinen Gruppen durchgeführt werden.

Der überwiegende Teil dieser angesprochenen Empfehlungen

bewegt sich im psychologischen Bereich und ist am besten unter dem Begriff "Einführungs-Strategie" zusammenzufassen. Diese Einführungsstrategie beginnt mit der Projekteröffnung, endet aber nicht mit dem offiziellen Projektende, sondern geht darüber hinaus.

Eines sollte man nie vergessen: Daß sich Akzeptanz, Motivation und Innovation nicht verordnen lassen. Weiterhin sollte man sich darüber im klaren sein, daß die Entscheidung für ein gewisses System von Leuten getroffen wird, die für das Unternehmen verantwortlich zeichnen, aber normalerweise nie mit dem konkreten System unmittelbar arbeiten werden. Nur der End-User, sprich Sachbearbeiter, entscheidet auf lange Sicht gesehen über die Nutzbarmachung dieses Systems für das Unternehmen.

Deshalb ist die Schulung der Endbenutzer ein bedeutender Erfolgsfaktor für das Projekt. Hierfür sollte dem Mitarbeiter ausreichend Zeit zur Verfügung gestellt werden. Da das Tagesgeschäft jeden Mitarbeiter voll in Anspruch nimmt, ist es ratsam, zur Bewältigung der Arbeiten in der alten Abwicklungsform Aushilfen einzusetzen, die für die erforderliche Luft sorgen.

Die oft vertretene Meinung, daß neue Systeme, gerade wenn sie online-orientiert sind, nur von jüngeren Mitarbeitern bedient werden können, ist völlig falsch. Die Annahme, daß Motivation ausreicht, ist ebenfalls nicht richtig.

Man kann grundsätzlich davon ausgehen, daß die guten Mitarbeiter in der alten Abwicklungsform auch die guten Mitarbeiter in der neuen Systemumgebung werden. Nur die in Zusammenhängen denkenden Sachbearbeiter sehen dieses System als Hilfsmittel an und verfallen nicht der Systemgläubigkeit. Bei diesen qualifizierten Mitarbeitern ist lediglich eine anfängliche Berührungsangst mit dem System zu überwinden, was aber kein Problem darstellt.

Da eine individuelle Schulung für alle Betroffenen meist nicht durchführbar ist, sollten kleine, von der Persönlichkeitsstruktur homogene Gruppen von maximal drei bis vier Personen gebildet werden. Die Hauptverantwortung für das Gelingen einer Schulungsmaßnahme kommt eindeutig dem Trainer zu. Er sollte nie vergessen, daß er es hier mit erwachsenen Menschen zu tun hat, denen das Unternehmen bereits viel zu verdanken hat und daß somit überhaupt die Möglichkeit geschaffen wurde, das neue Verfahren einzuführen. Die Oberlehrer-Manier ist wohl völlig fehl am Platz!

Hier können nur gegenseitiges Vertrauen, Sachlichkeit, Informationsbereitschaft, verständliche Information (kein Fachchinesisch), Einfühlungsvermögen, kurzum: eine natürliche Menschenführung, den gewünschten Erfolg bringen. Eine auf das Aufgabengebiet ausgerichtete Arbeitsunterlage ist ebenfalls eine unabdingbare Notwendigkeit. Die vom Softwarehersteller mitgelieferte Dokumentation ist kein Ersatz, weil sie

aufgrund der Ausführlichkeit mit viel Ballast behaftet ist.

Neue Terminologie ist zu erlernen

So vorbereitet und mit durch umfangreiche Abnahmetests gesicherten Funktionsnachweisen kann der Einführungstag kommen und die Einführungsphase beginnen. Dieser Zeitpunkt sollte sorgfältig ausgewählt und mit allen Bereichen, auch mit dem Softwarehersteller, genauestens abgesprochen werden. Die Wahrscheinlichkeit, daß mit der Einführung eines neuen Systems keine unmittelbaren Probleme auftauchen, ist relativ gering.

Da der seinerzeit festgesetzte Einsatztermin lange Zeit vorher definiert wurde und die direkten Auswirkungen damals noch nicht bekannt sein konnten, ist das Bestehen auf eine terminliche Projekterfüllung falsch verstandener Ehrgeiz oder Unumsichtigkeit. Jetzt sollte zu Zeitpunkten einer allgemeinen betrieblichen Hochphase (Jahresabschlußvorbereitungen, letzte Phase der Soll-Erfüllung, saisonbedingter Mehrarbeit) keinesfalls eine weitere Belastung von außen hereingebracht werden. Wenn also der Zeitpunkt stimmt, sollten vom ersten Tag an, für mindestens zwei bis drei Wochen, die Systemkenner der DV im Fachbereich sein, um bei Bedarf direkt helfend einzugreifen.

Nun kann man sagen, daß sich diese Vorgehensweise nicht von der einer Eigenentwicklung unterscheidet. Das ist in gewisser Weise richtig. Nur sollte man daran denken, daß Standardsysteme in einer weit höheren Komplexität eingesetzt werden. Ebenso ist das Darstellungsbild dieser Software nicht mit dem Anwender entwickelt worden. Desweiteren ist mit dem Einsatz von Standardsoftware auch eine neue Terminologie verbunden, die erst einmal allgemeiner Sprachgebrauch werden muß.

Kleiner Dienstweg wird versperrt

Die begriffliche Vermittlung eines integrierten Systems, also die direkte Darstellung der Abhängigkeiten zwischen dem Verkauf, Lager, Versand, Einkauf und Finanzbuchhaltung, war nicht sonderlich schwer. Dies aber umzusetzen in Handeln und Denken, ist ein Prozeß, der gut zwei bis drei Jahre in Anspruch nimmt. Die sonst mehr oder weniger gehüteten Bereichsgrenzen werden durchsichtig und der eigene Bereich transparent, der oft genutzte kleine Dienstweg wird versperrt.

Um diesen Prozeß des integrierten Denkens und Handelns weiterzuentwickeln, ist es ständig erforderlich, anhand von praktischen Fallbeispielen die Notwendigkeit zu verdeutlichen. Als eine einleuchtende Dokumentation eines integrierten Gesamtsystems hat sich eine recht einfache Methode herausgestellt: ein Treffen aller Benutzer dieses Systems, wo jeder kurz auf sein Aufgabengebiet am System eingeht und über eventuelle Schwierigkeiten berichtet. Jeder wird erstens sehr schnell und personifiziert den Leistungsumfang dieser Anwendung begreifen und zweitens sein Aufgabengebiet nicht mehr als isolierte Teilfunktion verstehen.

Zwei Veranstaltungen in einem Abstand von etwa drei Monaten sind meist völlig ausreichend, um das gewünschte Ziel zu erreichen. Es haben sich dann viele Querverbindungen gebildet, und der Prozeß des integrativen Handelns kann sich ganz natürlich entwickeln. Darüber hinaus ist die Einrichtung einer Koordinationsstelle eine wesentliche Voraussetzung für ein sich weiterentwickelndes Integrationsverhalten.

Die Aufgaben einer solchen Gruppe sollten sein: die Ausübung der zentralen Tabellenpflege, die Koordinierung und Vereinheitlichung von Auswertungen, die Beurteilung der Einsatzmöglichkeit neuer Standardfunktionen, eine "Telefonseelsorge" für die Anwender sowie die Funktion eines filternden Gesprächspartners zur DV.

Wesentlich schwieriger ist es, das integrierte Denken zu forcieren. Zwar wird es durch das Handeln unterstützt, aber es entwickelt sich nicht daraus. Das sehr sorgsam gehütete Bereichsdenken ist nur sehr langsam in ein Ganzheitsdenken umzuwandeln. Hierdurch werden "Fürstentümer" berührt, und es kann zu erheblichen individuellen Widerständen kommen. In diesem Punkt ist das Management gefordert, den Prozeß in Gang zu setzen.

An die Einführung eines so komplexen Paketes sollte sich eine Konsolidierungsphase von mindestens ein bis zwei Jahren anschließen. Diese Zeit ist unbedingt erforderlich, um dieses System Alltag werden zu lassen und eventuell vorhandene Unschönheiten auszubügeln.

Betriebswirtschaftler sind auf den Plan gerufen

Diese Zeit sollte dazu genutzt werden, um den erforderlichen personellen DV-Unterbau auf eine breitere Basis zu stellen. Jetzt müssen aus Organisationsprogrammierern und Informatikern betriebswirtschaftlich denkende Informationsverarbeiter und Organisatoren gemacht werden. Parallel hierzu ist die technische Ausbildung am System voranzutreiben, damit alle Funktionen optimal genutzt werden und die Abhängigkeit vom Softwarehersteller abnimmt.

Auf die Streitfrage "lndividual-oder Standardsoftware?" kann man zusammenfassend antworten, daß der für ein integriertes System notwendige Funktionsumfang von einer kleinen DV-Mannschaft wohl kaum bewältigt werden kann. Doch auch Firmen mit einer wesentlich größeren DV-Abteilung sollten sich fragen, ob es wirklich sinnvoll ist, "das Rad zum 495sten Mal zu erfinden".

Zweifellos ist eine individuelle Eigenentwicklung in einigen Bereichen absolut erforderlich, und betriebliche Stärken können hiermit

wesentlich besser ausgenutzt werden. Aber gerade im

betriebswirtschaftlichen Bereich läßt die Standardsoftware kaum noch Wünsche und Anpassungsmöglichkeiten auf die eigene Betrachtungsweise offen.