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.

10.07.1987 - 

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

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.

Das auslösende Moment für Umstellungen im DV-Bereich kommt meist von außen: In diesem Fall war die Situation durch eine starke Unzufriedenheit der Anwender geprägt. Entscheidend war hierbei jedoch, daß diese Unzufriedenheit nicht in Konfrontation mündete, sondern in die gemeinsame Erkenntnis, daß durch eine konstruktive Zusammenarbeit eine fortschrittliche Entwicklung einzuleiten sei. Kurzfristige Entscheidungen hätten damals wohl auch kurzfristige Erfolge gebracht; bis zum heutigen Zeitpunkt hätten sie die DV des Unternehmens jedoch ins Abseits manövriert.

Durch den um 1980 einsetzenden Preisverfall auf dem Hardwaremarkt wurde die Ressource Hardware mit einer höheren Leistungsfähigkeit erschwinglich. Die in jahrelanger Kleinarbeit produzierten Programme hatten ihre Überschaubarkeit schon lange verloren und waren zudem durch eine trickreiche Assemblerprogrammierung personenabhängig.

Hier setzte die erste Entscheidung an: nur noch eine einzige Programmiersprache. Man entschied sich für die Sprache mit dem größten personellen Marktpotential - für Cobol. Die modulare und strukturierte Programmierung wurde nicht nur als Richtlinie definiert, sondern auch praktiziert. Hinzu kamen neue Forderungen: Die Anwendungen sollten dialogorientiert, tabellengesteuert, datenbankorientiert, hardwareunabhängig und somit zu einem gewissen Maße portabel konzipiert werden.

Umstellung auf ein neues Betriebssystem

Gleichzeitig fiel die Entscheidung, auf ein neues Betriebssystem umzustellen. Damit bot sich die Möglichkeit für die Neukonzeption einiger Anwendungen mit gleichzeitiger Funktionserweiterung. Das Personal im DV-Bereich wurde verdreifacht.

Eine der wichtigsten Entscheidungen war die Forderung nach einer neutralen und unternehmensweiten "Entscheidungsfeld-Analyse und DV-Systemplanung". Der Auftrag dazu wurde einer Unternehmensberatung erteilt und brachte 1981 einen 5-Jahres-Plan für erforderliche DV-Projekte und Organisationsstrukturänderungen hervor. Dieses Papier definierte erstmalig die Projekte mit ihren Inhalten und Zielen in einer zeitlichen Reihenfolge.

Die Tatsache, daß sich die Geschäftsleitung mit dieser Problematik auseinandersetzte, gab der Sache die erforderliche Bedeutung. Dieser Umstand allein hätte wahrscheinlich nicht den gewünschten Erfolg gebracht. Ausschlaggebend war vielmehr die Erkenntnis über die gegenseitige Beeinflussung der Komponenten: Projektplanung, Personalplanung, Hardwareplanung und Kostenplanung (siehe Abbildung).

Verstärkter Einsatz von Standardsoftware

Dieser Regelkreis stellt die Grundlage für jede erfolgreiche DV-Entwicklung dar. Verdeutlichen sollen das die folgenden Erläuterungen:

- Projektplanung: Wenn es das Ziel ist, ein PPS-System einzuführen, ist es unbedingt erforderlich, eine funktionierende Lagerwirtschaft und Bestellabwicklung zu haben. Andernfalls könnten nur Teilfunktionen dieses PPS-Systems genutzt werden.

- Personalplanung: Ohne Personalkapazität ist nichts auszurichten. Hier sind jedoch auch und vor allem folgende Aspekte gemeint: kontinuierliche Weiterbildung, eventuell erforderliche Umorganisationen, rechtzeitiges Aufbauen neuer Mitarbeiter - um einer normalen Fluktuation entgegenzuwirken - und last but noch least eine marktkonforme finanzielle Gehaltsentwicklung.

- Hardwareplanung: Alle Weiterentwicklungen benötigen naturgemäß zusätzliche Ressourcen. Diese Erweiterungen müssen zeitlich auf die Entwicklung der Hardwaremöglichkeiten abgestimmt werden. Zu frühe Weiterentwicklungen können sehr teuer werden.

- Kostenplanung: Die Hardware- und Softwareanforderungen müssen finanzierbar sein und sich somit an der Ertragslage des Unternehmens orientieren.

Ein weiterer wichtiger Aspekt der in Auftrag gegebenen Studie war der Rat, verstärkt Standardsoftware einzusetzen. Dem rechnenden Manager leuchtet das vielleicht früher ein, als dem gestandenen DV-Menschen, der hierbei ganz andere Probleme im Vordergrund sieht.

Die Meinung, sorgfältige Auswahl und Kauf eines leistungsfähigen Standard-Paketes würden ausreichen, um die anstehenden Probleme zu lösen, ist nicht ganz richtig. Damit sind lediglich etwa 15 Prozent der erforderlichen Projektleistung erbracht. Daß sich hieran je nach Organisationsform mehr oder weniger umfangreiche Neugestaltungsmaßnahmen anschließen, ist den wenigsten potentiellen Anwendern voll bewußt.

Beim Einsatz von Standardsoftware wird die Entwicklungskapazität der DV-Abteilung kaum belastet; gleichzeitig können die Kosten gegenüber der Eigenentwicklung wesentlich verringert werden.

Doch was ist Standardsoftware? - Standard wird oftmals mit Mittelmäßigkeit gleichgesetzt: Man dürfe also keine besonderen Ansprüche an diese Software stellen. Diese Annahme ist für wirkliche Standardsoftware völlig falsch. Ein großer Teil der angebotenen Standardsoftware ist zunächst für individuelle Anwender erstellt worden, um dann anschließend - durch geringe Änderungen standardisiert - auch anderen Anwendern angeboten zu werden. Diese Systeme verlieren aber nie den engen Bezug zu den individuellen Problemen des zugrundeliegenden Einzelfalles.

Ein Kennzeichen echter Standardsoftware ist dagegen, daß sie von vornherein ohne einschränkende Bindung an eine individuelle Anwendung konzipiert wurde. Nur so ist es möglich, ein allgemeines Lösungsverfahren durchzusetzen und gleichzeitig individuelle Unterschiede durch den Grad der Modularisierung zu erreichen.

Die Grundanforderungen an den Standardsoftware-Anbieter lauten: benutzerfreundliche und umfangreiche Dokumentation, Ausbildungsangebot für Fachabteilung und DV, Wartung über einen langen Zeitraum und eine gesunde Geschäftspolitik. Daneben ist es von ausschlaggebender Bedeutung für die Qualität einer Software, daß ihre geistigen Väter in der Lage sind, sich in die Anforderungsbeidürfnisse des Anwenders hineinzudenken. Dazu müssen diese Softwareproduzenten die Probleme der Anwender kennen und verstehen und nicht etwa programmtechnische Losungsmöglichkeiten in den Vordergrund ihrer Überlegungen stellen - nach dem Motto: "Nur das einfach Realisierbare ist machbar".

Der Software-Partner, der all diese Überlegungen entsprach, war schnell gefunden. Ein Produkt des Anbieters wurde bereits eingesetzt und funktionierte zufriedenstellend. Zwar zählte der Softwareproduzent nicht zu den größten der Branche, aber das Konzept und die Weiterentwicklungstendenzen waren überzeugend.

Daß dieses Softwarekonzept auch vom Hersteller der Hardware vertrieben wurde, erfüllte zusätzlich die Forderung "Hard- und Software aus einer Hand." Dieser Grundsatz mußte allerdings korrigiert werden; denn die Erfahrung zeigte, daß naturgemäß der Entwickler eines Produktes für den Anwender der kompetentere Gesprächspartner ist.

Somit waren alle Voraussetzungen geschaffen, die ersten Projekte anzugehen. Benötigt wurden ein Projekt zur Abwicklung des Bereichs Verkauf mit Auftragsabwicklung, Versand und Fakturierung sowie ein Projekt zur Abwicklung des Sektors Einkauf mit Bestellabwicklung, Rechnungsprüfung, Wareneingang und Lagerwirtschaft. Die parallele Einführung beider Projekte hat sich als sehr sinnvoll erwiesen, da somit Schnittstellenprobleme optimal berücksichtigt werden konnten und mußten. Daß beide Projekte völlig unproblematisch und reibungslos verliefen, würde mit hier sowieso niemand abnehmen, und ich möchte auch nicht den Anschein erwecken.

Entscheidungsträger aus diversen Bereichen

Die gesamte Projektzeit für beide Systeme belief sich auf 14 Zeitmonate und wurde in folgende Teilabschnitte aufgeteilt:

Phase I:

- Ist-Aufnahme der bestehenden Abwicklung;

- Kennenlernen der Standard-Software;

- Festlegung der erforderlichen organisatorischen und programmtechnischen Änderungen.

Phase II:

- Realisierung der festgeschriebenen Modifikationen und erforderlichen Auswertungen;

- Implementierung des Systems mit hauseigenen Datenbeständen und Datenversorgung bestehender Subsysteme sowie Schulung der Anwender;

- intensive Testphase aller Komponenten;

- Einführung.

Es wurde eine Projektgruppe gebildet, die sich aus Entscheidungsträgern folgender Bereiche zusammensetzte: Verkauf, Versand, Marketing, Finanzbuchhaltung, Einkauf, Produktion/Qualitätskontrolle, Personalabteilung und Datenverarbeitung.

Durch diese Konstellation war der übergreifende Charakter der anstehenden Aufgabe dokumentiert, und erforderliche Entscheidungen konnten meist sofort getroffen werden. Aufgabenbezogene Arbeitsgruppen ergänzten die Projektgruppe temporär; sie präsentierten Arbeitsergebnisse und eventuelle Alternativvorschläge. Die Projektleitung berichtete spätestens nach drei Monaten über den Projektstatus an den Lenkungsausschuß. Dessen Aufgabe ist es, alle laufenden Projekte zu kontrollieren und bei Fehlentwicklungen frühzeitig einzuschreiten.

Projektverantwortung phasenweise zugeteilt

Bezüglich der Projektleitung ist eine Besonderheit anzumerken: Die Projektleitung wurde in der ersten Phase durch den anfordernden Fachbereich (Verkauf/Einkauf) gestellt. Mit Beginn der Realisierung ging die Projektleitung an den DV-Bereich über. Der Zeitpunkt für diesen Wechsel wurde vom Lenkungsausschuß festgelegt. Somit ist gewährleistet, daß alle fachbereichsbezogenen Anforderungen verantwortlich dokumentiert und festgeschrieben werden müssen. Eine Verzögerung in der ersten Phase hat eine direkt nachvollziehbare Auswirkung auf den angestrebten Einsatztermin. Vom Tisch ist damit das leidige Thema "Ich weiß zwar noch nicht, was ich will, aber wann".

Das Unternehmen

Die Schwarz GmbH ist ein privater Pharma-Produzent mit einem Jahresumsatz von etwa 340 Millionen Mark und insgesamt 1160 Mitarbeitern. Unternehmenssitz ist Monheim bei Düsseldorf; Tochterfirmen arbeiten in Großbritannien, Italien, der Schweiz und den USA.

Die Hardwarebasis bilden zwei Siemens-Rechner der Typen 7.570 und 7.551 mit insgesamt 150 Terminals. Als Betriebssystem wird BS2000 eingesetzt.

Die Auswahlkriterien orientierten sich am speziellen Charakter der Pharma-Produktion, nämlich der Chargenfertigung. Chargen heißen die homogenen Mengen eines Produkts auf einer bestimmten Herstellungsstufe. Bevor das zukünftige Medikament die jeweils nächste Stufe werden die Ergebnisse dokumentiert; der Produktionsprozeß soll theoretisch nachvollziehbar sein. Folglich muß der Hersteller auch die Rohstoffe einschließlich des Verpackungsmaterials nach Chargen-Nummern getrennt einkaufen, kontrollieren, lagern und verwenden. Weil Arzneien nur begrenzt haltbar sind, trägt jede Charge das Verfalldatum, das Verwendungsdatum und den letzten Auslieferungstermin für den Verkauf. Die Stückliste muß außerdem die Verarbeitung von Wirkstoffen mit unterschiedlicher Konzentration berücksichtigen, damit der Einsatz von Ausgleichsstoffen gesteuert werden kann.

Diesen Anforderungen soll das bei der Schwarz GmbH eingesetzte integrierte System mit den Komponenten "Verkauf", "Einkauf" und "Lagerwirtschaft" genügen.