Terminverzögerungen, Kostenüberschreitungen und Projektabbrüche begleiten auch heute noch in unzähligen Fällen die Arbeit in den DV-Abteilungen. Insbesondere bei der Implementierung von neuer Software in ein bestehendes System treten Probleme auf, die nach Meinung des Münchener Systemberaters Detlef von Dehn zumindest in ihren Auswirkungen verringert werden können. Der Autor beschreibt in seinem Beitrag Fehlerquellen, die ihm in seiner Beratungstätigkeit aufgefallen sind, und gibt Hinweise zu deren Beseitigung.
Die Einführung von Softwarepaketen ist meist nicht so problemlos, wie man sich das vorher gedacht hat. Trotz hochtheoretischer Abhandlungen und aufwendiger Planungshilfen geht ein solches Vorhaben oft schief. Was sind die Gründe dafür? Nicht immer sind einfach der "Computer", die Software oder die Mitarbeiter schuld. Oft sind es die Binsenweisheiten, die schon so selbstverständlich sind, daß sie ganz einfach vergessen werden. So blüht das Verhängnis im verborgenen, und man bemerkt es erst, wenn es schon zu spät ist.
Lösung gemeinsam erarbeiten
Es gibt zwei Extreme bei der Entscheidung für ein Softwarepaket, zwischen denen man sich in der Praxis bewegt. So wird die Entscheidung aus irgendeinem Grunde von der Firmenleitung getroffen, und zwar über die Köpfe der Mitarbeiter hinweg. Die Anordnungen werden im Befehlston weitergegeben. So gut kann ein Softwarepaket gar nicht sein, daß es nicht abgelehnt würde. Die Mitarbeiter identifizieren sich bei dieser Vorgehensweise einfach nicht mit dem eingekauften Produkt und arbeiten widerwillig mit der Software.
Ein Team, das auch aus freiwilligen Mitarbeitern der betroffenen Fachabteilungen, DV-Fachleuten und eventuell objektiven Beratern besteht, erarbeitet gemeinsam einen Lösungsvorschlag. Die notwendige DV-Erfahrung erhalten die Fachabteilungen durch Einführungsvorträge und Standardprogramme, mit denen sie spielen können. Auf diese Weise werden sie am leichtesten mit der Problematik vertraut und nehmen willig auch größere organisatorische Änderungen in Kauf, weil sie die Verarbeitungsabläufe verstehen und die Entscheidung auch als "ihr Kind" betrachten.
Die möglichen Funktionen des Softwarepaketes sollten im gesunden Verhältnis zu den tatsächlich angewendeten stehen. Zu große Systeme, die viel mehr können, als man benötigt, werden zu teuer (Anpassungsaufwand, Wartung, Hardware, Ausbildung der eigenen Mitarbeiter und die Kosten für die Überlassung des Softwarepaketes). Zu klein ausgelegte Systeme sind zum Zeitpunkt des Einsatzes in bezug auf Funktionen, Laufzeiten oder Menügerüste schon völlig ausgereizt, also nicht mehr erweiterungsfähig.
Verhindert werden kann eine solche Fehlentscheidung, indem man das Menügerüst und vor allem die "Schlüsselfunktionen" zum Zeitpunkt der Entscheidung genau kennt. Sind zu viele Unbekannte enthalten, stimmt etwas nicht. Unter dem Motto: lieber eine Hand voll guter, motivierter Leute als ein Heer von Mittelmäßigen, sind schon viele Projekte erfolgreich durchgeführt worden.
Verantwortung von oben nach unten fehlt
Gefährlich vor allem in der Konzeptphase sind DV-Fanatiker und Theoretiker, die in höheren Ebenen schweben und sich durch ihr System ein Denkmal setzen wollen (Folge: Kostenaufwand gegen unendlich und ein nie laufendes Programm).
Dies wird zwar immer befürchtet, aber vielleicht gelingt es, einen "Gesamtschuldigen" zu finden, der kurz vor Untergang abgesetzt wird und für alle gemachten Fehler herhalten muß. Verantwortung, von "oben" nach unten, sinnvoll gegliedert und klar abgegrenzt, gibt es leider kaum.
Ein mögliches Lösungskonzept liegt im Einsatz eines Fachprojektleiters, der den "großen Überblick" haben sollte und verantwortlich für Integration, Schnittstellen und die "Schlüsselprobleme" ist. In der Planungsphase muß er sich dafür einsetzen, daß nur sinnvolle Funktionen realisiert werden, denn in der allgemeinen Euphorie besteht die Gefahr, daß eine Vielzahl von unnötigen Funktionen geplant wird, die nie gebraucht werden. Häufig findet man sogenannte Fachprojektleiter, die den notwendigen Überblick nicht haben; sei es, daß ihnen die fachliche Qualifikation fehlt oder daß sie sich in Detailprobleme verkriechen. In diesem Fall arbeitet jeder vor sich hin, ohne auf den Nachbarn zu schauen. Die Folgen liegen klar auf der Hand.
Kleine Schritte für DV-Neulinge
Nachdem die Entscheidung gefallen ist, wird der Projektablauf geplant. Es passiert mitunter, daß Planungsfachleute mit teuren Verfahren schöne Bilder produzieren, die aber nicht stimmen, weil nur "Köpfe" und Termine geschoben wurden.
Gründlichkeit und sehr viel Fachwissen erfordert das Zerlegen des Gesamtprojektes in loslösbare Teilprojekte mit klaren Schnittstellen und das Festlegen der Abhängigkeiten der Teilprojekte untereinander. Unternehmen, die noch keine DV-Erfahrung haben, gehen oft erhobenen Hauptes ihrem Untergang entgegen. Sie sollten das Gesamtsystem in ganz kleinen Schritten einfuhren. Dazwischen muß genug Zeit sein, um die gemachten Erfahrungen zu verwerten.
Nachdem der Terminplan für das Gesamtprojekt steht, kann man darangehen, das Detailkonzept für die Teilprojekte zu erarbeiten. Das ist ein iterativer Prozeß, denn oft werden Daten in "frühen" Teilprojekten gebraucht, die erst in späteren festgelegt werden können, und umgekehrt. Die Programmvorgaben müssen so genau sein, daß sie ohne Rückfragen, notfalls extern realisiert werden können. Terminverzug ist deshalb so "umwerfend", weil sich dadurch auch die Folgeprojekte verschieben. Dann muß das Ganze neu durchgeplant werden, wenn man nicht will, daß eingeplante Mitarbeiter auf ihre Arbeit warten und andere damit beschäftigt sind, Schnittstellen und Dateien zu simulieren, um weiterarbeiten zu können. Es sind immer wieder die gleichen Ursachen, die zu Terminverzögerungen führen, denn Fachabteilungen brauchen viel Zeit.
Man unterschätzt bei weitem den Aufwand der betroffenen Fachabteilungen, denn diese müssen eine entsprechende DV-Ausbildung erhalten, die neuen Organisationsabläufe durchspielen und überprüfen, die Listenbilder, Bildschirmmasken und Datensätze entwerfen und schließlich auch noch fehlerfreie Testdaten liefern, mit denen sich ein überprüfbarer Funktionstest durchführen lassen kann (sehr großer Aufwand).
Nur bedingt läßt sich Terminverzug durch zusätzliche Manpower abfangen, denn die Formel "Mannmonate geteilt durch Mitarbeiter ist gleich Realisierungszeit" (errechnet mit dem Mauerdreisatz) bringt oft das entgegengesetzte Ergebnis. Wenn mehrere Leute gleichzeitig programmieren und testen, dann wird jemand benötigt, der die verschiedenen Programmversionen und Testdateien verwaltet, für Rechenzeit und Terminals sorgt und der darüber wacht, daß die Test- und Programmiervorschriften eingehalten werden.
Krise rechtzeitig erkennen
Nach Abschluß eines Teilprojektes wird dieses in das Gesamtsystem eingefügt. Nach dem Test aller Funktionen müssen die Ergebnisse genau überprüft werden. Das kann durch geeignete Testdaten sehr erleichtert werden.
Nach erfolgreichem Abschluß sorgte an dem Teilprojekt nichts mehr verändert werden. Besser ist es, in einer zweiten Projektphase die bisher aufgelaufenen Änderungen nachzufahren, um das Gesamtprojekt nicht zu gefährden. Wird festgestellt, daß aus irgendeinem Grund das Projekt "auf Grund gefahren wird", dann sollte man den Mut haben, so schnell wie möglich das Ganze abzublasen und ganz von vorne anzufangen. Es gibt kaum Fälle, in denen in sogenannten Krisenaktionen am Schluß noch eine befriedigende Lösung zustande kam. Typisches Anzeichen für eine Krise ist: Man hat den Weg zum Projektende nicht mehr im Auge. Aber es gibt auch äußere Anzeichen, wenn zum Beispiel festgestellt wird, daß trotz hektischer Betriebsamkeit nichts mehr weitergeht; daß zu viele Insellösungen sich nicht ins Gesamtprojekt integrieren lassen; daß das System doch nicht den Bedürfnissen der Praxis entspricht; daß die Projektsitzungen zu Verschleierungs- und Schuldverschiebungsveranstaltungen werden.
Die Einführung vor allem von integrierten Softwarepaketen erfordert vom Anwender viel DV-Erfahrung, eine lange und bis ins letzte durchgedachte Planungsphase, die richtige Einschätzung des Aufwandes für die Fach- und Organisationsabteilungen und - nicht zu vergessen - eine gehörige Portion Motivation.