Aufwand/Nutzen-Nachrechnung mit Abweichungsanalyse zeigt bei vielen enttäuschenden DV-Projekten die gleichen Schwachpunkte: im sorgfältigen Planen und im Einhalten der Planung! Die betriebswirtschaftlichen Projektziele zu halten, erfordert funktionsweise die Vorteile für jede Anwenderabteilung zu prüfen, um immer nach Nutzwertanalyse zu entscheiden, wie komfortabel, in welcher Qualität und damit wie teuer im einzelnen realisiert wird. Spezifische Schwierigkeiten gibt es natürlich; vor allem aber unterschätzt man aus zu geringer Erfahrung die Folgen der Komplexität. Die gleichen Fehler werden ja auch bei komplexen Bauprojekten immer wieder gemacht: Man plant nicht sauber und vollständig genug, man unterstellt und wünscht, ohne kritisch zu überprüfen und man versäumt schriftliche Fixierung der Ziele. Das wirtschaftliche Projektziel wird nur durch sauber gegliederte Gesamtplanung, klare Projektverantwortung sowie laufende Kontrolle und Korrektur aus ständiger funktionsweiser Aufwand/Nutzen-Analyse erreicht.

In vielen größeren DV-Projekten kommt bei Entwicklern und Management Enttäuschung auf, wenn Kosten und Termine steigen, aber Funktionsbreite und Komfort, Antwortzeiten und Sicherheit, vor allem aber der erwartete Rationalisierungseffekt in den Anwenderabteilungen "nicht so durchschlagen wie erwartet". Haben gar noch verschiedene Leute geplant und realisiert, folgt der Endkampf: Wurde Unmachbares geplant - oder waren die Realisierer unfähig?

Projektrendite falsch berechnet . . .

Oft wird eine potentielle Einsparung mehrmals bei verschiedenen Projekten angesetzt: bei einer Umstrukturierung, einem neuen DV-System, beim PC-Einsatz oder in einer Gemeinkosten-Wertanalyse.

Oder es stellt sich bei einer Nachrechnung heraus, daß die Ansätze in der ersten Begeisterung schon beim Projektstart danebenlagen: Die eigentlichen Projektmotive wie Ordnung, Machtverschiebungen, Glaube an Groß-EDV wurden hinter geschönten Einsparungsrechnungen versteckt, weil sie nicht quantifizierbar und vermeintlich nicht präsentabel schienen. Auch "nicht Quantifizierbares" muß in seinem Nutzen bewertet werden: Was vernünftig ist, muß sich auch als Vorteil darstellen lassen!

Eine Wirtschaftlichkeits-Nachrechnung muß je nach Zweck unterschiedlich erfolgen:

- geht es um eine Grundsatzbetrachtung, um für künftige Projekte aus Fehlern, der früheren zu lernen, so muß man Gesamtkosten und Gesamtnutzen ansetzen - natürlich aktualisiert auf heutiges Wissen.

- geht es um Entscheidungen im Projekt - an Phasen-Zäsuren, um weitere Realisierung oder Abbruch, um Prioritätsverschiebungen oder Eingrenzungen, um Veränderungen der Randbedingungen oder Zielsetzungen -so ist die Situation anders: Ausgegebenes Geld kommt nicht zurück, und aus geschlossenen Verträgen ist nicht einfach auszusteigen. Nur zukünftiger Aufwand und Nutzen sind noch gegeneinander abzuwägen.

. . . oder läuft das Projekt falsch?

Hinter solchen Formalien verstecken sich die eigentlichen Fehler der Projektarbeit und schlagen auf die Wirtschaftlichkeit durch.

- konsequentes Planen erfordert klare Schrittfolge - von der betriebswirtschaftlichen Systemplanung bis zur DV-Realisierung:

Erst muß man die funktionellen Wünsche aufnehmen (nicht schon versprechen!), und das Systemzusammenspiel vollständig, exakt, jedoch noch nicht im Detail konzipieren, um daraus Einmal- und laufenden Aufwand grob zu kalkulieren. Sodann folgt die mühevolle Beschränkung auf das Wichtige, Richtige, Nötige - hier sollte man Teil-Etats bilden, und in deren Rahmen dann die Planung und Abgleichung von Terminen, Aufwand und Qualität sowie Kapazität und Vorgehen! Jetzt erst darf man diesen Plan endgültig festschreiben - muß ihn aber dann auch hart durchziehen.

- konsequentes Einhalten der Planung heißt beim Detaillieren beständiges Orientieren an Kernauftrag und Teil-Etat. Nur ständiges Kontrollieren von Sach- und Aufwandsfortschritt nach Meilensteintrendmethodik und Netzplan erlaubt flexibles Steuern und Korrigieren.

DV-Projektwirtschaftlichkeitsrechnungen werden in großer Zahl angefertigt: Auf eine voraussichtliche Entwicklungsdauer und anschließende Nutzungszeit wird die "Investition" der Systementwicklung den sich verändernden DV-Ablaufkosten plus rechnerischen Vorteilen in den Fachbereichen gegenübergestellt. Gleichwirkende Umwelttrends läßt man weg, und will man es recht genau machen, bringt man für die Entwicklungskosten im Hochlauf und anschließend für die Nutzungsphase noch die entsprechende Abzinsung hinein.

Eine einfache Sache - und doch passieren immer wieder Fehler, werden nicht im Projekt genannte, aber aus Herstellerreklame und anderen Quellen geholte "Selbstverständlichkeiten" als Erwartungen ungeprüft ins Projekt projiziert - und im fertigen System vermißt.

Die Motive, der Wunschablauf und die Lösungsidee müssen daher klar fixiert sein, oft wird aber aus einem ganzen Bündel nur ein Fassadenziel "Rationalisierung" herausgestellt: "dasselbe wie bisher tun, nur viel billiger". Die "Nebenziele" wie breitere Funktionen, Zukunftsvorsorge, Sicherheit, Transparenz oder andere Abläufe sollen quasi kostenlos bei der Neuentwicklung mit abfallen. Und hier liegt dann der Hauptaufwand und vielleicht auch der Hauptnutzen.

Ist mit dem neuen System eine Strukturveränderung und Aufgabenverschiebung verbunden, so sollten die neuen Verantwortungen vor der Detailplanung festgelegt werden:

denn an der Feindefinition ihres "Werkzeuges" müssen die Fachabteilungen sachkundig und verantwortlich mitgestalten - sonst wird es nie "ihr Kind".

Was "kostet" das a DV-System?

Wichtige mit dem Projekt verbundene Kosten sind leicht vergessen. Dazu gehören "Ausstiegskosten" aus dem Altsystem, wie zum Beispiel Sozial- und Pensionierungskosten, Vertragsrestlaufzeiten, Sonderabschreibungen und anteilige Testkosten sowie alle Datei-Überleitungs- oder -Neuerfassungskosten. Sodann auch Doppellaufkosten in Zeiten der Parallelläufe und einführungsstrategische Zwischenstufen. Und last but not least Schulung, Erprobung, Handbücher. Auch "Folgeschäden" in der Ablaufumgebung, an bestehenden Systemen oder Nachbarprojekten gehören mit zum Projekt! Zu eliminieren sind dagegen die Kosten am Projekt, die aus anderen Entscheidungen resultieren.

Falsch wäre, nur "SW gegen SW" zu vergleichen. Es geht um alle Konsequenzen der verschiedenen Entscheidungsalternativen beziehungsweise Vorgehensstrategien, wozu auch nicht ausgeschöpfte Vorteile früherer Entscheidungen zählen. Gefährlich ist es, ein einziges neues gegen das alte System zu setzen. Es lohnt zu prüfen, ob nach alter ABC-Erfahrung vielleicht einige Prozent Nutzenabstrich dafür weniger Risiko und niedrigere Kosten brächten: Es könnte ja sogar sein, daß eine anderswo schon erprobte Lösung oder gar gängige Standard-SW voll ausreicht.

Vor Beginn muß mit den Anwenderabteilungen erwogen und ausgehandelt werden, wie modern die Lösung sein soll und wie breit, vollständig, komfortabel die Nutzeroberfläche angelegt wird - denn so teuer und risikoreich wird das Vorhaben. Zu gern vermißt man dabei Kosten und Nutzen der DV-Qualität: Bei Planung wie Revision sollte man sie wertanalytisch hinterfragen, um die wirtschaftlich richtige und tragbare "Unschärfe" abzuwägen.

"Optimale Qualität bei minimalen Kosten" im Projektplan ist nutzlos und muß konkretisiert werden, denn als Planungskriterium kann nur konkret sein, was auch Abnahmekriterium wird. Leider ist "Qualität" nicht objektiv definierbar: "Eignung zum vorgesehenen Einsatz" wertet subjektiv! "Mangelnde Qualität" kann daher von Kritikern, die es natürlich besser können, immer reklamiert werden.

Hier hilft ein Systemqualitätsspiegel als Status und Ausgangsbasis, das "Unbehagen" zu quantifizieren und zu kanalisieren. Die Frage "Neuentwickeln oder Verbessern" läßt sich besser untermauern, man erkennt "wertanalytisch", wo im einzelnen eine Verbesserung wieviel bringt und wieviel kostet. (Siehe Bild 3)

Schwachpunkte jeder DV-Planung sind nachträgliche Forderungen, die auftauchen, weil man sie vergessen hat, oder weil sich über die Projektlaufzeit die Umwelt veränderte. Wie beim Bau muß auch hier ein Pauschalzuschlag für "Unvorhergesehenes" eingeplant werden. Dieser Zuschlag darf aber nicht beim ersten Fall von organisatorischer, von Produkt- oder Marktveränderung sofort verbraten werden, sondern wird als "eiserne Reserve" hart verteidigt. Vor allem aber sollte kein Projekt länger als ein bis zwei Jahre dauern

- nur so sind Umweltveränderungen abzufangen!

Oft ist das Hauptproblem (mangelnde Erfahrung in Großprojekten) vor allem in der leichtfertigen Übertragung von Erfolgen an Kleinprojekten ohne den Faktor "Komplexitäten" zu suchen. Man versäumt, den exponentiell steigenden Kommunikationsaufwand bei vielen Beteiligten zu berücksichtigen, die zusätzlichen Informationsprozesse und die Reichweite von Mißverständnissen. Selbstüberschätzung (die häufig gerade nicht bei den SW-Machern anzutreffen ist) verleitet, zuviel auf einmal anzupacken.

Die Projekt-Nachkalkulation auf Basis "lines of code (LOC) pro Mannjahr" gibt eine recht gute Auskunft. Im voraus ist es aber meist unmöglich, den späteren Programmumfang zu schätzen, bevor die Aufgabe genügend im Detail durchleuchtet ist: dann aber steckt man schon so tief in Termin und Aufwand, daß oft kein Weg zurückführt.

"Falsche Versprechungen der DV-Leute" beleuchten ein häufiges Verständigungsproblem zwischen Anwender und Programmierer: "Geht des, können Sie das?", wird als intellektuell-technische Herausforderung verstanden - dabei war doch ganz konkret gemeint "ist das in Aufwand und Termin noch, mit unterzubringen?" Hier hilft nur Detaillierung und Schriftform: ein "interner Vertrag" muß alles vollständig aufführen, was sein soll - und was es kostet. Dann kann nicht mehr hinterher diskutiert werden, was man sich vorgestellt oder irgendwann gesagt hat. Wo Nachträge unvermeidbar sind, ist der Auftrag fortzuschreiben - mit Termin- und Aufwandskonsequenzen, wie bei Vertragsänderungen!

Sätze wie "das ist nicht wirtschaftlich, aber wir haben ja keine andere Wahl" zeigen ein tiefes methodisches Mißverständnis: Denn mehrere Alternativen (und wenn es nur Nuancen sind) gibt's immer. Eine davon - sei es die bisherige, sei es eine kleine Weiterentwicklung, die Neuentwicklung oder das totale Umkrempeln der Systemlandschaft - ist dann relativ "die wirtschaftlichste"! Und wenn sie nur der "Weg des geringsten Schadens" ist, weil Bisheriges technisch oder gesetzlich nicht mehr geht. Wichtig ist dabei, den Nutzen darauf "abzuklopfen", ob und was an "Cash" wirklich zurückfließt: Oft sind "Einsparungen" nur hypothetisch und müssen mit Gemeinkosten-Wertanalyse und Arbeitsverlagerung erst noch "gehoben" werden.

Kernproblem vieler DV-Projekte ist leider eine sachliche Ziel-Unsicherheit: Unbekümmert wird gefordert "so ein System, wie Firma X hat" - ohne daß der Anwender sein eigenes Problem überhaupt genügend kennt: Er bräuchte dann zuerst einmal Fachberatung zum Erkennen und Formulieren seiner Ziele und ihrer Gewichte. Häufig wird Unnötiges entwickelt - und das wirklich Nötige muß in der Einführungsphase nachgebaut werden.

Ein erheblicher Teil der entgleitenden Wirtschaftlichkeit beruht auf zu später Erkenntnis, was zur Erreichung des organisatorischen Zieles gegenüber dem jetzigen System überhaupt verbessert werden soll: Dazu bedarf es der Kenntnis der bestehenden Informations- und Werteflüsse und der Abläufe. Deren gewachsene Besonderheiten sind bei Vorgesetzten und Planern oftmals unbekannt.

Mangelnde Kenntnis paart sich gern mit Absolutheitsanspruch: Man lehnt jegliche Methodik, Schriftform ab - denn was sein soll, ist doch klar! Man ersetzt Systematik doch Pragmatismus, klares Entscheidungsvermögen bei der Projektplanung durch Wollen, Durchboxen, An-sich-Reißen: Hier muß die DV-Abteilung oft Strukturiertechnik, Entscheidungsqualifikation und Verantwortung der Anwenderseite noch kräftig schulen!

Die Funktionshäufigkeiten und Durchläufe die Mengengerüste nach Transaktionsarten sowie ihre Jahres-, Monats-, Tagesspitzen müssen bekannt sein - ebenso ihre künftige Entwicklung: Sie sind Ausgangsbasis für tragfähige DV-Konzepte. Leider kennzeichnet eine gewisse Unbeweglichkeit den Funktionsspezialisten, der doch sein bisheriges Handeln im DV-System exakt wiederfinden will.

"Natürlicher Selbstschutz" bewirkt oft, daß zuvor beschworene Einsparungspotentiale ins Nichts zerfließen. Wurden sie "im Vorgriff" schon erhoben, dann gehörten sie nicht in die Projektrechnung! Will man sie jetzt beim "Abkassieren der Ratio" nicht mehr zugeben, dann haben durch DV freigewordene Mitarbeiter wohl längst zusätzliche Aufgaben Funktionen, - Umsatzsteigerungen aufgebrummt bekommen. Falsches Profitcenter-Denken setzt zudem oft Abteilungsoptimum vor Gesamtoptimum, heizt Emotionen an. Um wieder auf nüchternen Boden zu kommen, braucht man kühle Fakten, eine "Ratio-Nachprüfung nach Abteilungen". Bei Überlappen mehrerer Projekte wird daraus je Abteilung die "Ratio-Fortschreibung". (Bild 2)

Projektkonzept zusammen erarbeiten

Gemeinsame Detailplanung von Auftraggeber, Anwender und den DV-Spezialisten ist ein Kooperations und Akzeptanzproblem: Im Streß wird gegenseitig Ignoranz vorgeworfen, werden eigene Einsichten überbewertet und fremde Erfahrungen als nicht zutreffend abgetan. Jeder möchte das System persönlich gestalten - solange es Aufwind hat - aber es nicht gewesen sein, wenn es Probleme gibt.

Erfolgreiche "Projektziel-Kommunikation" erfordert bei allen Beteiligten Fachkompetenz und Fähigkeit zur Zusammenarbeit: Hier hilft mehrtägiges Teamtraining, vor allem gemeinsames Erfahren von Problemsituationen. Oft muß noch über längere Zeit ein Externer "ohne Aktien am Thema" Mißverständnisse und Beziehungen versachlichen, das Entwicklungsprojekt begleitend moderieren, bei Statusanalyse und Kurskorrekturen helfen.

Gefahr zu starker Abteilung

Viele Partner haben bei einer Systementwicklung Teil an einer "PIanungskommunikation". Der "Anwender" muß am Ende mit dem System arbeiten, der Chef hat Vorstellungen, wie man heute arbeitet und künftig arbeiten soll und der ins Team delegierte "Kenner" wird die Anforderungen ans betriebswirtschaftliche System formulieren:

Das Konzeptteam macht den betriebswirtschaftlichen Systementwurf, der DV-Planer definiert daraus Programmsysteme und kalkuliert sie, der Programmierer entwickelt die Komponenten und testet sie aus; die Montage-, Integrations- und Verfahrenstestgruppe bringt das Gesamtsystem zum Laufen im Rechenzentrum, wo das Ganze installiert wird.

Im Durchziehen das Grundkonzept bewahren!

Wenn sie alle hierarchisch und räumlich getrennt arbeiten und an den Informationsübergängen nur zehn bis 20 Prozent der Mißverständnisse aufkommen - dann ist schnell etwas völlig anders entwickelt, als man braucht! Schriftliche "Kommunikation" zwischen den Beteiligten ist aufwendig, und gerade wegen der Menge des Papiers und bald unüberschaubar, unsicher, ungeeignet. Also heißt es, nicht zu viele "Stellen" und Stufen einzurichten, sondern alle Beteiligten zusammenzuziehen und gemeinsam, später mit wechselnder Zusammensetzung, jeweils möglichst große Übereinstimmung zu erreichen!

Im Druck des Projektablaufs ist es Hauptaufgabe des Projektleiters (PL), sich gegen Aufblähen und Abgleiten zu stemmen - wie bei kritischen Bauprojekten.

Denn meist werden SW-Projekte "schlank und sehnig" konzipiert und bewilligt: Sie sollen schnell ein essentielles Problem lösen und dabei nicht mehr nötige historische Zöpfe kappen. Realisiert werden sie dann "übergewichtig", dazu spät und teuer, weil Abteilungsfürsten dann doch Perfektion und lückenloses Fortführen der Historie durchsetzen.

Dagegen helfen keine mehrdimensionalen Führungsmodelle, keine Gremien und Instanzen: Ihnen fehlt Gesamt-Verantwortung für Funktionsanforderungs-Detaillierung und DV-Konzeption und -Durchführung! Unter Führung des PL gehören alle Betriebswirtschaftler, Systemplaner und DV-Realisierer in einen Raum: Sie müssen in engem Kontakt alle Aspekte der Lösung ausdiskutieren, bevor Forderungen auf Papier geschrieben werden. Denn was mal getippt ist, hat Eigendynamik und ist kaum mehr in Frage zu stellen . . .

Nur aus seinem Gesamtprojekttauftrag kann der PL die ständige sofortige Rückkopplung schaffen. Die Fragen "was ist der Aufwand welchen Nutzen bringt es, läßt es sich auch anders lösen, ohne Essentielles einzubüßen, stehen an. Nur so kann er ein Maximum aus seinem Entwicklungsetat herausholen.

Dabei muß der Projektleiter "top down" vorgehen und sich vor Details retten: Im mehrstufig strukturierten Systementwurf muß er prozessual nach Vorgängen erst das Gerüst des Essentiellen erarbeiten - das muß dasein! Beim Vorgehen nach Funktionsfeldern drängt sich ja auch die unwichtigste Variante zur Unzeit nach vorne.

Gerade tief genug muß er gehen, um die Ziele der System-Aufwand-Nutzenplanung nach unten als Funktionswertanalyse im Sinne des Ganzen durchzudrücken. Nur so kann er im adäquat strukturierten Kostenplan permanent die Kosten-Nutzen-Relation im Griff behalten.

Nutzwertanalyse - vorher und immer wieder!

Detail-"Ist-Aufnahme", soweit für Abzulösendes überhaupt, verdient Argwohn: Immer wird sie beeinflußt vom verwendeten Ordnungsraster, leitet das Interesse die Erkenntnis. Das "Ist" wird mehr erfunden als gefunden, und das "Soll" wird vom ursprünglichen Ziel hin zum "Ist" verbogen.

Hier scheiden sich die Entwicklungsstrategien: Will man die Grundaufgabe schaffen, so muß nach Betriebswirtschafts-Grobplanung die DV-Grobkonzeption und -kalkulation folgen - nach der gegebenenfalls der Aufgabentiefgang nochmal deutlicher fixiert wird. Diese Grobplanung gilt als absoluter Rahmen, in den sich die funktionelle Feinkonzeption dann einordnen muß. Das bedeutet frühzeitige Abstriche, aber hält Termin und wirtschaftliche Ziele. Oder man will alles vollständig lösen und läßt sich die DV-Grobplanung erst der betriebswirtschaftlichen Feinplanung folgen: dann ist vieles nicht mehr zurückzuholen, Termin und Aufwand für die Feinplanung ist verbraucht. Die Tiefenentscheidung ist praktisch präjudiziert: Man bekommt vielleicht alles und teuer - oder auch nichts.

(Absolut tödlich ist es, wenn im Projekt - von verschiedenen Köchen - an verschiedenen Stricken gezogen wird; dann baut der eine schon nach Grobkonzept die Datenhaltung, der andere konzipiert und erweitert noch die BW-Funktionen . . .)

"Wenn schon neu, dann alles rein (Aufwand ist Schicksal)"

Nach ABC-Erfahrung kosten 80 Prozent der gewünschten Funktionen 20 Prozent des Aufwandes, und für die restlichen 20 Prozent Funktionen wird dann der "Rest" von 80 Prozent verbraten! Richtig vorgehen heißt also: Zunächst ist die Hauptsache zu klären, die "main stream line" festzulegen und erstmal Selteneres auszuklammern und Schnittstellen offenzulassen. Danach ist stufenweise nach verfügbarem Etat zu entscheiden, welche der "Zusatzwünsche" wirtschaftlich noch berücksichtigt werden.

Wie bei ZBB (zero base budgeting) muß der Projektleiter zwischen "lebensnotwendig, nützlich, wünschenswert" sauber unterscheiden. Die Vollständigkeit aller Varianten, die "unbedingt 100 Prozent" werden doch verzichtbar: Vieles und weiter noch später Entstehendes kann personell "draußen" verbleiben und weiter hinten "wieder eingespeist werden". Und manches erweist sich bei genauem Hinschauen als "historisch" und kann ganz wegfallen!

Der PL hat damit im Rahmen von Teiletats die taktische Entscheidung über die Ablehnung von Implementierungsdetails: Mancher durchaus nützliche Zusatzwunsch wird auf ein eventuell späteres Erweiterungsprojekt verwiesen und mit "Kontierungsschluß" wird auch mal das Projektende erzwungen.

Der sachkundige Projektleiter weiß um die Mängel der "oberen Schichten" der Dokumentation und um das Zuviel und Nicht-wirtschaftlich-aktualisieren-Können in Detailbeschreibungen. Qualität und Sicherheit wird er nicht durch Testen erreichen, nicht durch die Fiktion regressionsfähiger vollständiger Testdateien: Sie sind in der Praxis doch weder hinreichend, denn wenn sie alles absichern sollten, müßten sie unendlich groß sein. Noch sind sie notwendig, da durch saubere Strukturierung spätere Eingriffe an einem Systemteil ohne Auswirkungen auf andere Systemteile bleiben, und so die Testkombinationen begrenzt zu halten sind!

Termin ist das Wichtigste!

Bei ordentlicher Strukturierung muß jeder einzelne Systemteil genau einmal geprüft werden - aber nicht durch Massen von Testdaten, am Ende auch noch Echtdateien: ziellos in der Hoffnung eventuell seltener Kombinationen. Auch um des sicheren Tests willen muß der Projektverantwortliche um eine saubere Struktur kämpfen!

Der sachkundige und kritische Leiter muß moderne Projektmanagement-Techniken anwenden und durchsetzen.

Ein knapper, aber in Wichtigem exakter Netzplan dient ihm zur Steuerung und Kontrolle: Das Aufstellen (noch ganz ohne DV) bringt die wichtigsten Erkenntnisse: Es zwingt mehrfach vorwärts und wieder rückwärts das Vorgehen zu durchdenken, es hilft Meilensteine zu schätzen, um danach kontrollieren zu können.

Terminverzug bedeutet Aufwand vor allem aber spätere und kürzere Nutzung: Kaum eine Verbesserung ist die verzögerte Pilot-Einsatz-Erfahrung wert!

Robert Pusch ist Org./DV-Leiter in München