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.

Thema der Woche


12.09.1997 - 

Zeitdruck und Dynamik sprechen gegen starres Pflichtenheft

Mit einem reinen Funktionskatalog, wie ihn das Pflichtenheft in seiner klassischen Ausprägung darstellte, kommen Anwender in heutigen Softwareprojekten nicht mehr weit. Wer seine IT modernisieren will, muß wissen, ob sich die zur Auswahl stehenden Produkte in bestehende Prozesse integrieren lassen oder welche Änderungen damit möglich sind. Die Anpassung neuer Software, etwa die Darstellung eines Lieferantenstamms in einem Menübaum, ist nur die eine Seite der Medaille. Sehr viel weitreichender und damit über das klassische Pflichtenheft-Verständnis hinaus geht die Analyse von Abläufen, Zuständigkeitsbereichen und Verantwortungsbeziehungen.

Vor dem Hintergrund, daß die großen Standardpakete funktional ohnehin kaum noch Lücken aufweisen, muß die Frage also nicht mehr lauten, ob die Lösung eine Rechnungsvorerfassung hat, sondern was alles mit diesem speziellen Anwendungsfall zusammenhängt. Ein oft beobachtetes, aber verhängnisvolles Projektvorgehen ist nach Meinung der Diebold-Unternehmens-berater Burkhardt Wolf und Dieter Böhm dann gegeben, wenn sich nahezu ausschließlich IT-Abteilung und Berater um eine Lösung bemühen. Wird das Produkt dann eingeführt, treten in der Regel Probleme mit den Fachabteilungen auf, die zwar eine alte Funktionalität in neuem Kleid sehen, sich aber im Prinzip neue oder veränderte Funktionen gewünscht hätten.

Diebold zufolge sollte deshalb primär das Gespräch mit den betroffenen Fachabteilungen gesucht werden, um die dort herrschenden Besonderheiten interner Arbeitsabläufe zu analysieren. Im Gegensatz zu statischen Pflichtenheften lasse sich über die Kommunikation beispielsweise in Form von Workshops die Dynamik der Prozesse herausarbeiten und dokumentieren, so daß der Anwender in die Lage versetzt wird, gegenüber dem Software-Anbieter die richtigen Fragen zu stellen.

Ein weiteres Manko von klassischen Pflichtenheften besteht darin, daß im Vorfeld eines Re-Engineering-Projekts die Konsequenzen von Ablaufänderungen vernachlässigt werden. In dem Leistungskatalog sind zwar die Funktionen etwa für Stammdaten, Lieferanten, Bestellerfassung sowie Rechnungsprüfung beschrieben. Zu kurz kommt dagegen die Analyse, welches Know-how an welcher Stelle erforderlich wird, wenn man derartige Aktivitäten entlang der Prozeßkette verschiebt.

An einen Fall einseitiger Prozeßbetrachtung erinnert sich Böhm im Zusammenhang mit der R/3-Einführung bei einem norddeutschen Großunternehmen. Dort sollte das Bestellwesen über eine Workflow-Anwendung vom Einkauf in die Fachabteilungen verlagert werden. Man hatte jedoch versäumt, den Einsparungen im Einkauf den Aufwand gegenüberzustellen, der aufgrund des dezentral benötigten, betriebswirtschaftlichen Know-hows (Kostenstellen etc.) anfiel - Projektfallen, die nichts mit dem Funktionsumfang des Standardpakets zu tun haben, aber durchaus zum Scheitern der Implementierung führen können.

Die Diebold-Experten räumen ein, daß derart verhängnisvolle Pannen auch auf die Fehler der Berater zurückzuführen sind. Anstatt die Unternehmensstrategie des Kunden zu analysieren, wird bei der Software-Einführung, die zudem als Festpreisprojekt kalkuliert wurde, ein zu starkes Gewicht auf die IT gelegt. Die Einführung beschränke sich auf eine Eins-zu-eins-Abbildung bisheriger, teilweise überkommener Funktionen, für eine strategische Projektbegleitung bleibe kaum Spielraum. Einfaches Beispiel: Aufgrund zeitlicher Engpässe würden selten Überlegungen angestellt, ob beispielsweise die Finanzdisposition weiterhin mit Hilfe einer Tabellenkalkulation erfolgen kann oder ob sie im Rahmen einer SAP-Einführung mit dem entsprechenden R/3-Modul abgewickelt werden soll.

Kontinuierliche Projektkommunikation, sei es mit der hausinternen DV-Abteilung oder mit externen Dienstleistern, mahnt auch Klaus Niemeyer von der Anwendungsentwicklung der Deutschen Post AG an. Pflichtenhefte werden zu Beginn eines Projekts erstellt und damit zu einem Zeitpunkt, an dem noch niemand genau wissen kann, wie die Praxis letztlich aussehen wird, so seine Erfahrung. Viele Anwender scheuten sich deshalb, ihre Vorgaben bis ins Detail auszuführen. Die Konsequenz: Es sollte nicht nur auf der Grundlage des Pflichtenhefts programmiert werden, auch die im Laufe eines Projekts anfallenden Änderungen sind zu berücksichtigen.

Ein Problem ergibt sich laut Niemeyer außerdem, wenn Programmierer mehr ins Detail gehen müssen, als dies vorab im Pflichtenheft vereinbart wurde. Dabei gilt es zu vermeiden, daß die Auftragnehmer entweder aus Bequemlichkeit oder aus Zeitgründen keine Rücksprache mit der Fachabteilung halten und die fehlenden Informationen nach eigener Interpretation ergänzen.

Wie unterschiedlich mittlerweile das Thema Pflichtenheft angegangen wird, zeigen die zwei folgenden, nahezu konträren Beispiele:

- Im Augsburger Werk der Daimler Benz Aerospace AG kommt eine komplette PPS-Reorganisation nahezu ohne jedes Pflichtenheft aus.

- Die Stadtwerke Münster GmbH stellt ihre IT im Zuge von 22 Projekten, darunter eine R/3-Einführung, auf neue Füße und hat dies in äußerst detaillierten Dokumenten vorbereitet.

Die rund 1500 Mitarbeiter der Augsburger Dasa-Niederlassung produzieren Rumpfkomponenten für den Airbus und Tornado, wobei die Prozesse von der Massen- bis zur Einzelfertigung reichen. Im Rahmen einer konzernweiten Wettbewerbsinitiative wurde im vergangenen Jahr mit der Umstrukturierung begonnen. Für das Werk bedeutete dies den Wechsel von bislang komplexen, unübersichtlichen Geschäftsabläufen zu dezentral organisierten Leistungseinheiten. IT-seitig wurde dazu die Host-basierte PPS abgelöst und durch hierachisch angeordnete Einzelsysteme ersetzt. Das heißt, ein von außen kommender Auftrag wird zerlegt und in Form mehrerer Unteraufträge im Haus weitergegeben. Je nach Komplexität einer Baugruppe wiederholen sich diese Schritte, so daß eine Art Zulieferkette innerhalb des Unternehmens entsteht. Die Schnittstellen zwischen den jeweiligen PPS-Systemen beschränken sich auf die Funktionen "Bestellung" und "Lieferung" - eine gemeinsame Sicht gibt es ausschließlich auf den Teilestamm und den Produktkatalog.

Projektleiter Edgar Kalb erinnert sich, daß man bei früheren Vorhaben zunächst ein Grob-, dann ein Feinpflichtenheft erstellt hat, um anschließend das in mehrere hundert Seiten "gegossene" Dokument zur Programmierung nach außen zu geben. Diesmal läuft es erstmals anders. Während der Vorphase wurde intern das grobe Konzept ausgearbeitet und der externe Partner gesucht. Die Wahl fiel auf Infor und dessen Windows-NT-Lösung "VPPS". Gemeinsam wollte man sich über Pilotanwendungen im Prototyping-Verfahren sukzessive an das Ziel herantasten.

Ein Pflichtenheft erstellten Kalb und seine Kollegen lediglich für die Umstellung der Materialwirtschaft, die eine Anbindung an die R/3-Finanzbuchhaltung und -Kostenrechnung in der Konzernzentrale erhalten wird. Da mit dem kommenden Jahreswechsel ein Stichtag für die Umstellung der Materialwirtschaft vorgegeben ist, sei dieses Thema klassisch angegangen worden. Das gemischte Verfahren hat sich laut Kalb bewährt - insgesamt bewege sich das Projekt im Zeit- und Kostenrahmen.

Trotzdem sah sich der Experte mit Problemen konfrontiert, die allerdings auch mit einem Pflichtenheft kaum zu vermeiden gewesen wären. Als potentielle Gefahrenquelle bezeichnet Kalb etwa die Tendenz, sich bezüglich spezieller Projektaspekte in Feinheiten zu verlieren, während andere Themen allzu großzügig behandelt werden. Was anfangs mit Argusaugen beobachtet wurde, stellt sich manchmal als unkritisch heraus, dafür entstehen neue Probleme an unerwarteter Stelle, so seine Erfahrung.

Nicht vorsichtig genug kann laut Kalb beispielsweise der strategische Wechsel vom Host in die Windows-Welt angegangen werden.

Wer das stabile Mainframe-Umfeld gewohnt sei, für den bedeute der PC zunächst Chaos. Applikationen stürzten ab, und es lasse sich nicht immer nachvollziehen, ob der Fehler von der Applikation, vom Betriebssystem oder Netzwerk herrühre. In diesem Zusammenhang werde auch die Qualifikation der Mitarbeiter nicht frühzeitig genug berücksichtigt.

Windows biete mehr Freiheiten als der abgeschottete Dialog eines Terminals, berge damit aber auch neue Fallen. Die anfängliche Euphorie für die neue Oberfläche weiche später den Forderungen nach abgesicherten Eingabefeldern und Plausibilitätsprüfungen.

Ein ebenfalls häufig unterschätztes Problem, das auch in Pflichtenheften besser geregelt werden sollte, ist laut Kalb die Datenübernahme in das Neusystem. 90 Prozent der Informationen lassen sich unter Umständen reibungslos konvertieren, aber die verbleibenden zehn Prozent, die möglicherweise schon im Altsystem individuell gehandhabt wurden, können ein Projekt erheblich verzögern.

Nahezu entgegengesetzt zum Augsburger Projekt haben die Stadtwerke Münster GmbH ihre IT-Umstellung vorbereitet. In einer Gesamtstrategie zur Erneuerung der Informationsverarbeitung wurden dort rund 20 Projekte definiert. Verantwortlich für die Auswahl von Hard- und Software sowie der Berater sind Thomas Stutenbäumer und sein Team. Vom Ablauf her erfolgt für jedes Projekt zunächst eine Organisationsstudie, auf deren Ergebnis die Systemauswahl und die Ausschreibung aufbaut. Dabei geht die Ausschreibung weit über das Verständnis klassischer Pflichtenhefte hinaus. Mit Hilfe des Aris-Toolset von der IDS GmbH entstand zunächst eine Dokumentation des Ist-Zustands, gefolgt von einer Schwachstellenanalyse, einer Soll-Beschreibung und einer Anforderungsdefinition. Die Ausschreibungen bestehen im wesentlichen aus einem für alle Projekte gleichen Mantel mit allgemeinen Informationen zu Firmenprofil, Unternehmensleitlinien, Organigrammen und Geschäftsprozessen. Projektspezifisch wurde die fachliche Situation mit ihren Abläufen, den jeweils Verantwortlichen und der Zeitplanung beschrieben. Hinzu kamen Angaben über Funktionenbaum, Daten-Mengengerüst sowie zu den benötigten Schnittstellen.

Zeitdruck macht Anwender verwundbar

Darüber hinaus wurde das Pflichtenheft so gestaltet, daß die späteren Angebote miteinander vergleichbar waren. Derart vorbereitet ließ sich laut Stutenbäumer eine interne Kostenabschätzung vornehmen, mit der die Wahl des Partners, etwa unter den zahlreichen R/3-Beratern, in nur sechs Wochen erfolgen konnte. Mit ihm wurde ein aufwandsbezogener Vertrag zur Feinkonzeption geschlossen.

Stutenbäumer empfiehlt jedoch dringend, bereits zum Zeitpunkt der Entscheidung für einen Berater den vollständigen Preis oder zumindest einen Höchstwert für die Projektumsetzung vertraglich zu vereinbaren. Besonders bei R/3-Einführungen, die unter dem Druck der Datumsproblematik stehen, sei nach der Feinkonzeption ein Wechsel zu einem anderen Beratungshaus kaum noch möglich. Hier befinde sich der Anwender in einer äußerst verwundbaren Situation.

Kein Dogma

Karl H. Bell, Kienbaum:"Das Vorgangsmodell kann noch als Leitfaden für die Erarbeitung eines Pflichtenheftes dienen, die darin enthaltenen Kann-Bestimmungen sollten jedoch sehr flexibel ausgelegt werden. Das Pflichtenheft entsteht heute zwingend im Dialog zwischen Fach- und IT-Abteilung sowie dem eventuell hinzugezogenen Berater. Da Software inzwischen meist über Rapid Application Development entwickelt wird, sitzen hier Anwender und Entwickler gemeinsam am Bildschirm, wobei das Pflichtenheft kein Dogma sein darf. Die Applikation sollte unter Akzeptanzaspekten optimiert werden, sonst wird unter Umständen an den Anforderungen vorbeiprogrammiert."

Es zählt nur der Erfolg

Wolfgang Dietze, Andersen Consulting:"Noch vor Beginn eines Pflichtenhefts muß feststehen, welche wirtschaftlichen Ergebnisse man mit einem Re-Engineering erreichen will. Spätestens ein Jahr nach Projektende sollten sich dessen Auswirkungen in der Bilanz oder GuV positiv bemerkbar machen. Angesichts dieses übergeordneten Ziels relativieren sich Konflikte darüber, ob beispielsweise der im Pflichtenheft beschriebene Funktionsumfang ausreicht oder ergänzt werden muß. Es geht nicht um Manntage oder Aufwand, sondern um den Geschäftserfolg des Auftraggebers."