Zwar gleicht die Durchfuehrung eines WBS-Projekts in vielem der eines konventionellen DV-Projekts, es bestehen aber auch wichtige Unterschiede. Am Anfang beider Projekttypen steht meist eine Vorstudie. Ein grosser Vorteil der WBS-Projekte besteht allerdings darin, dass ihre Machbarkeit vor der eigentlichen Projektdurchfuehrung besser verifiziert werden kann. Anhand eines Prototyps laesst sich an einem relevanten Ausschnitt kostenguenstig nachweisen, ob eine Loesung denkbar ist, die der Benutzer akzeptieren wird.

Das Management muss fuer Motivation sorgen

Bei WBS-Projekten wird nicht erst in den letzten Projektphasen programmiert, wissensbasierte Systeme werden vielmehr inkrementell entwickelt. Schon frueh koennen daher ablauffaehige Teilergebnisse praesentiert und beurteilt werden, was die Sicherheit der weiteren Projektdurchfuehrung entscheidend erhoeht. Da wissensbasierte Komponenten in der Regel schneller erstellt und auf einem geringeren Detaillierungsgrad umgesetzt werden, koennen sich bei integrierten Projekten Abweichungen bei den Meilensteinen ergeben.

Die Zuarbeit der Fachabteilung ist bei klassischen DV-Projekten vor allem bei der Konzeption und in der Anlaufphase erforderlich. Bei WBS-Projekten dagegen arbeiten die Betroffenen permanent zusammen: der Fachexperte, der sein Wissen in das WBS einbringt, der WBS-Spezialist, der fuer Shell-Einsatz, Wissensakquisition und deren Verifizierung zustaendig ist, und der klassische DV- Spezialist, der fuer die Integration und Implementierung des WBS Sorge traegt. Ergaenzend dazu ist das Management gefordert, das die strategische Einordnung eines solchen Systems beachten und alle Beteiligten entsprechend motivieren muss.

WBS-Vorhaben koennen natuerlich an den bekannten Schwierigkeiten scheitern, die auch klassische Projekte gefaehrden. Spezifische Risiken birgt jedoch die heterogene Zusammensetzung der Projektteams, wenn die Beteiligten nicht genuegend kooperieren. Fachabteilungen sind oft versucht, WBS-Projekte in Eigenregie durchzufuehren. PC-erfahrene Fachleute koennen mit Hilfe von Endanwender-Tools kleinere Expertensysteme selbst erarbeiten. Unueberwindliche Probleme stellen sich jedoch spaetestens dann ein, wenn die Anwendung an externe Datenbestaende und Programme anzubinden ist.

Die DV-Abteilung hat ihrerseits ohne Zuarbeit der Fachabteilung keine Chance, ein WBS-Projekt gut zu realisieren - es sei denn, die DV-Mitarbeiter haben zugleich das noetige Expertenwissen zum Beispiel ueber Hardware- oder Software- Fehlerdiagnosen.

Selbst die Zusammenarbeit von DV- und Fachabteilung fuehrt aber in der Regel nicht zum Projekterfolg, wenn keine Erfahrung mit wissensbasierten Systemen vorliegt. In diesem Fall ist die Mitarbeit externer WBS-Spezialisten erforderlich.

Viele Auftraggeber versuchen, XPS-Kenntnisse preiswert bei den Hochschulen einzukaufen, indem sie beispielsweise Forschungsprojekte in Form von Diplomarbeiten oder aehnlichem vergeben. Allerdings ueberwiegt bei deren Autoren das theoretische Grundwissen gegenueber der praktischen Erfahrung, die Ergebnisse sind daher fuer den Auftraggeber oft unbrauchbar. Aehnliche Resultate zeitigt haeufig die Einstellung eines in der Theorie gut ausgebildeten KI-Fachmanns direkt von der Hochschule.

Es kann aber auch ganz andere Gruende haben, wenn ein WBS-Projekt scheitert:

- Oft wird die Aufgabenstellung der geplanten Anwendung falsch gewaehlt. Ein WBS sollte immer ein klar abgrenzbares Sachgebiet behandeln, zu umfangreiche Themen sind nicht geeignet.

- Manche Anwender wollen ein Problem, fuer das bisher kein Know-how im Unternehmen vorhanden war, mit Hilfe eines Expertensystems loesen. Dieses kann prinzipiell jedoch nicht mehr leisten als ein menschlicher Experte, dessen Wissen ja gerade im WBS abgebildet werden soll: "No expert, no expert system!"

- Gelegentlich ist nicht praezise definiert, wer das WBS ueberhaupt nutzen soll. Ist es als Hilfe fuer den Experten selbst gedacht, oder soll Wissen vervielfaeltigt und Nichtexperten zur Verfuegung gestellt werden? Hier muessen sorgfaeltige Wirtschaftlichkeitsueberlegungen ansetzen, damit keine Investitionsruinen entstehen.

In den Management-Etagen bildete sich durch das Scheitern von WBS-Projekten leider oft die Annahme, dass die Technologie wohl nicht geeignet fuer die Praxis sei. Ein fataler Irrtum zugunsten anderer Unternehmen, die die Zeit genutzt haben, um wissensbasierte Systeme mit unternehmensstrategischer Ausrichtung zu implementieren.

Gute Experten sind ueblicherweise rar im Unternehmen und stehen oft vor lauter Tagesgeschaeft fuer die Wissensakquisition so wenig zur Verfuegung, dass Projekte allein an diesem Kommunikationsmangel scheitern koennen. Probleme gibt es aber auch dann, wenn sich herausstellt, dass der zustaendige Fachmann seine Entscheidungen in Wahrheit nach keinerlei Methode oder Verfahren faellt, wenn er also im Projekt gewissermassen entlarvt wird.

Denkbar waere auch, dass ein Spezialist sein Wissen zurueckhaelt, weil er fuerchtet, von dem geplanten WBS um seinen Arbeitsplatz gebracht zu werden. In der Praxis geschieht allerdings meist das Gegenteil. Im Rahmen des Knowledge-Engineering erkennt der Experte, dass ein WBS nicht mehr wissen kann als er selbst. Oft nimmt ihm das System gerade die zeitraubenden Routineaufgaben ab, die ihn bisher daran hinderten, kreativ an neuen Problemstellungen zu arbeiten. Zudem sieht er die Chance, eine intelligente Checkliste in die Hand zu bekommen, die ihm hilft, Kenntnisse und Arbeitsweise zu vervollkommnen. Wenn er darueber hinaus aktiv an der Systementwicklung mitarbeitet, ist fuer ihn sichergestellt, dass ein WBS kein statisches Programm ist, sondern von ihm selbst gewartet und weiterentwickelt werden kann.

Reine Wissensingenieure sind nicht mehr gefragt

In frueheren WBS-Projekten arbeiteten meist Informatiker und Systemanalytiker mit WBS-Erfahrung als sogenannte "Wissensingenieure". So konnte es vorkommen, dass ein Diplommathematiker in einem Projekt ein wissensbasiertes System zur Beurteilung von Hypothekendarlehen entwickelte und im naechsten eine Anwendung zur Getriebediagnose bei LKWs. Um ueberhaupt an die Wissensakquisition herangehen zu koennen, war bei jedem neuen Vorhaben eine intensive Einarbeitung des Wissensingenieurs notwendig. Der Experte musste ihm sein Grundwissen beibringen. Schon aus Zeitgruenden ist dieses Verfahren nicht empfehlenswert.

Es empfiehlt sich daher, an WBS-Projekten auch solche Mitarbeiter - gegebenenfalls extern - zu beteiligen, die ausser DV-Kenntnissen das Fachwissen des jeweiligen Arbeitsgebietes mitbringen. Die Kommunikation mit dem Experten reduziert sich dann, da gemeinsames Basiswissen vorhanden ist, auf die tatsaechlich zu loesenden Probleme. Das ideale Team besteht aus Fachexperten, WBS- Spezialisten, die zumindest teilweise ueber entsprechendes Fachwissen verfuegen, dem DV-Koordinator sowie klassischen DV- Spezialisten, die fuer die Integration des WBS in Datenbanken, Programme etc. sorgen. Auch die Leiter der DV-Abteilung und der betroffenen Fachabteilungen sollten eingebunden sein.

*Dr. Joachim Frank ist geschaeftsfuehrender Gesellschafter der Experteam Unternehmensgruppe GmbH in Muenchen.