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.

Wirtschaftlichkeit entscheidet sich in frühen Projektphasen:


09.11.1984 - 

Wertanalytik hilft Systemziele halten

Von Robert Pusch *

Aufwand/Nutzen-Nachrechnung mit Abweichungsanalyse zeigt bei vielen enttäuschenden DV-Projekten die gleichen Schwachpunkte. Das wirtschaftliche Projektziel wird nur durch sauber gegliederte Gesamtplanung, klare Projektverantwortung sowie laufende Kontrolle und Korrektur aus ständiger funktionsweiser Aufwand/Nutzen-Analyse erreicht. (Teil 2)

Klare Zielvereinbarungen über Funktionen, Schnittstellen, Qualität, Termin, Aufwand sind die Sicherheit des Projektleiters, sie stützen und motivieren zudem die PL-Verantwortung: Was mit anderen als dem späteren Realisierer vereinbart wurde, verpflichtet nicht so! Überschaubare Planungsunterlagen helfen, unsinnige Terminforderungen und den Dreisatz "wenn zehn Chinesen die Arbeit . . ." abzublocken und auf vorprogrammierten Mehraufwand und höheres Risiko des späteren ordentlichen Zusammenspiels zu verweisen.

Zur guten Erfüllung muß der PL sich qualifizierte Mitarbeiter holen können. Ihr Potential ist die eine Säule der Planung - die andere ihre Teamfähigkeit: Die kann und sollte man gemeinsam zu Beginn nochmals trainieren!

Der Projektleiter führt

Führen heißt, seinen Mitarbeitern vorangehen, sie motivieren und fordern - und auch mal Mut zum begrenzten Risiko zeigen. Wer zuviel absichert, zaudert, untersucht, ob es auch sicher so geht, verliert schließlich die Erfolgsgewißheit für sich selbst, für Mitarbeiter und Anwender.

Er braucht aber auch Vertrauen und Verständnis bei Anwendern und Management und muß im Gespräch bleiben. Das bedingt Partner mit Kompetenz, Methodik, Konsequenz und Ruhe, die das Projekt aufmerksam beobachten und frühzeitig fragen, auch feinste Hintergrundsignale schon aufnehmen und richtig filtern - um dann Probleme im Gespräch zu lösen.

Die Methodenfehler bei Entwicklungen sind immer gleich, es gibt keine speziellen SW-Planungsprobleme: Nicht "SW" oder "Datenverarbeitung" ist das Problem - ungewohnt neu ist dabei, komplexe Systeme zu planen und zu kontrollieren.

Freilich hat die Software noch den zusätzlichen Nachteil, eben nicht besonders anschaulich, anfaßbar, mit den Sinnen greifbar zu sein: SW ist nur über den "Umsetzer Verstand" zugänglich . . .

Gerade darum muß das betriebswirtschaftliche Konzept in allen Funktionen und Daten, in Syntax und insbesondere Semantik systemtechnisch konsistent sein - ob es nun hinterher elektronisch oder per Papier und Bleistift abläuft. Aber Systemtechniker und Wirtschaftskybernetiker gibt es leider noch zu wenige in der "Betriebsinformatik". Die meisten in der "Systemanalyse" Tätigen kommen bar jeder theoretischen

Grundlage "aus der Praxis", und diplomierte Informatiker wurden bislang von Hochschulen mit Schwerpunkt auf formalen Sprachen, Datenbankkonstrukten und ähnlichen Hersteller-SW-orientierten Fächern herangebildet. Hier braucht die Planung mehr Betriebspraxisorientierung. Denn ebenso wie bei Produktentwicklungen wird der größte Teil der späteren Kosten in den ersten Planungsstufen entschieden - wo es noch zu ändern ginge!

Von den Auftraggebern her wird in Unterschätzung von Komplexität und Risiko oft keine echte "Sandkastenplanung" durchgeführt, wo man Alternativen abklopft oder wo man noch umstellen oder aussteigen kann: Man beginnt zu früh die Realisierungs-Feinplanung, fixiert sich auf eine dann nicht optimale Lösung, von der man später nur mit sehr viel Geld wieder runterkommt.

Es fehlen in aller Regel mehrstufige Planungsrahmen, die in konsequenten Zweck-Mittel-Ketten von der Unternehmensstrategie über die Informationsmanagementstrategie und ihren DV-Rahmenplan die exakten Vorgaben für die konkrete Systemplanung ableiten. Ebenso schmerzhaft wie durch Fassadenpostulate kaschierte Unsicherheit über das wirkliche Wollen ist verzweifeltes Glauben an die Weisheit zusammengesetzter Teams und externer Gutachter.

Wo Unsicherheit und Risiko drücken, kann das Werkzeug "Methodik" doch einiges erleichtern: Systematische Analysen (zum Beispiel Kepner-Tregoe) mit Risikobetrachtung, Faktorengewichtung, Durchplanung aller potentiellen Probleme helfen zu sauberer Entscheidungsvorbereitung. Die in Amerika seit einer Generation systematischer Betriebswirtschaft üblichen Ziel-Mittel-Ketten wie auch die Netzplanung sind ebenso auf Softwarekomplexe anwendbar, wie die aus Fertigungsstückkosten-Senkung bewährten Techniken differenzierender Ratioanalysen. Fehlt der Mut, sie auch auf betriebswirtschaftliche Info-System-Entwicklung anzuwenden? (Bild 4.)

Die wirtschaftliche 95-Prozent-Lösung kostet nur einen Bruchteil und überläßt die sowieso nicht genügend definierten selteneren Sonderfälle der personellen Bearbeitung, um ihr Ergebnis an geeigneter Stelle wieder ins System aufzunehmen. So "offen" zu bleiben für noch unbekannte Veränderungen von Zielsetzungen und Umgebung ist besser als der Versuch, die 100prozentige Lösung zu erzwingen und dafür immens viel zu bezahlen.

Nutzwert-analytisch handeln!

Resümee: Um Org/DV-Projekte wirtschaftlich abzuwickeln, sind wenige Regeln konsequent einzuhalten:

- In der Gesamt-Systemlandschaft zuvor die "Rosinen" heraussuchen, genügend exakt grobplanen, ordentlich rechnen, Werte mit Fachabteilung abstimmen und erst dann ein Projekt beginnen. Nicht zu viele Projekte auf einmal, und auch nicht zu große und zu lang dauernde Projekte definieren: Das gibt kürzere "Bremswege" und weniger Risiko.

- Klare Projektleiterverantwortung und viel Bemühen um kooperatives, initiatives und kreatives Zusammenwirken der Projektbeteiligten: gegeneinander konkurrieren macht das Projekt mit Sicherheit kaputt!

- Nach Projektbeginn das Zielsystem und das Projektvorgehen strukturieren und kalkulieren. Teiletats bilden, Meilensteine abstecken und kontrollieren, und vor allem Terminhaltung beachten: über Termine heißt es, zu verhindern, daß Lösung und Aufwand "wuchern" !

- Ständige Projekt-Aufwand-Nutzen-Analyse über alle Teile und Funktionen, bevor Wünsche zu "Forderungen" und festgeschriebenen Systemdefinitionen werden.

- Den Mut haben, ein "notleidendes" Projekt rechtzeitig abzubrechen, um es gegebenenfalls mit neuem, auf die essentiellen Funktionen reduzierten Ansatz neu zu planen.

- Das Projekt konsequent auch wirtschaftlich überwachen: Das entscheidet über wirtschaftlichen Erfolg oder Mißerfolg!

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