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.

16.07.1993 - 

Einheitliche Tools und Methoden bei Lieferant und Anwender

Lean Management laesst sich auf DV-Projekt uebertragen

Bei der Realisierung komplexer DV-Projekte gibt es erhebliche Moeglichkeiten zur Kosteneinsparung. Sie setzen allerdings einen Perspektivenwechsel voraus - weg von der Orientierung am fertigen Anwendungssystem und hin zu einer ganzheitlichen, prozessorientierten Betrachtungsweise. Wie sich die vieldiskutierten Prinzipien des Lean Managements auf komplexe DV- Projekte uebertragen lassen, zeigt der folgende Beitrag.

Kostenbewusstes Vorgehen bei der Realisierung von Projekten ist mittlerweile auch fuer DV-Abteilungen ein Muss. Sie geniessen nicht mehr die Narrenfreiheit der Anfangsjahre und muessen - wie alle anderen Unternehmensbereiche auch - Verfahren finden, mit denen sich Vorhaben optimal umsetzen lassen.

Zur Kostensenkung bieten sich Methoden an, die sich schon in anderen Branchen bewaehrt haben. Vergleicht man etwa die Entwicklung und Produktion eines neuen Automobiltyps mit der Realisierung komplexer DV-Projekte, ergeben sich in vielen Punkten verblueffende Uebereinstimmungen. Insbesondere die in der japanischen Automobilindustrie erfolgreich eingesetzten Prinzipien des Lean Managements lassen sich auf komplexe DV-Projekte uebertragen. Hier wie dort geht es in erster Linie um Einsparungen durch optimale Produktionsverfahren.

Lean Production zeichnet sich vor allem dadurch aus, dass bisher vernachlaessigte Faktoren beruecksichtigt werden, die bei der Wertschoepfung eine Rolle spielen. Dazu gehoert das Verhaeltnis zwischen Vorlieferanten, Lieferanten und Kunden. Ziel der Orientierung ist auch der Prozess der Produktentwicklung, da die Qualitaet eines Produktes in engem Zusammenhang steht mit der Art und Weise, wie es produziert wird. Generell laesst sich sagen, dass der Produktionsfaktor Mensch im Vergleich zum Produktionsfaktor Technik sehr viel mehr Beachtung erfaehrt als bei herkoemmlichen Formen der Projektabwicklung.

Was laesst sich nun aus den Prinzipien des Lean Managements konkret fuer die Gestaltung von DV-Projekten ableiten, und welche Probleme treten dabei auf?

In groesseren Unternehmen der DV-Branche ist es ueblich, neu zu erstellende Anwendungen auszuschreiben. Die DV-Abteilung erstellt zunaechst ein Pflichtenheft, das die Anforderungen an das System mehr oder weniger exakt definiert. Nun erfolgt mit erheblichem Aufwand die eigentliche Vergabeprozedur. Eine ganze Kette von Lieferanten und Sublieferanten tritt in Aktion. Die an der Ausschreibung beteiligten renommierten Hardwarehersteller haben in der Regel mit der Erstellung der eigentlichen Anwendungssoftware nichts zu tun. Ohne in jedem Fall die Qualitaet des entstehenden Angebotes beurteilen zu koennen, geben sie daher die Ausschreibung an Softwarehaeuser weiter. Diese wiederum treiben ebenfalls einen enormen Aufwand, um Angebote auf Basis der gewuenschten Vorgehensmodelle und der geforderten CASE-, Oberflaechen-, und Entwicklungs-Tools machen zu koennen. Dabei wird sehr viel Energie und Zeit auf Absprachen verwendet, um das Verhaeltnis zwischen Lieferanten und Kunden auf allen Ebenen in jedem einzelnen Projekt neu zu klaeren.

Wie unschwer zu erkennen ist, bringt diese Vorgehensweise vielfaeltige Kosten mit sich. Sie entstehen auf jeder Stufe, beginnend bei den Herstellern der Tools ueber die Anwendungsentwickler und Generalunternehmer bis zu den DV- Abteilungen des Auftraggebers. Der Lieferant produziert Kosten, um die Erwartungen des Kunden zu erfuellen. Den Auftraggeber kommt die aufwendige Auswahl unter vielen Angeboten teuer.

Die Uebergabe der Verantwortung an einen Generalunternehmer befriedigt seitens der Auftraggeber zwar das Beduerfnis nach Sicherheit - immerhin besteht eine einklagbare Garantie, dass ein Projekt zum vorgesehenen Zeitpunkt und im verabschiedeten Kostenrahmen auch tatsaechlich realisiert wird. Unter Kostengesichtspunkten betrachtet, ist dieses Vorgehen allerdings wenig sinnvoll. Im Prinzip zahlt der Anwender die vielen erstellten Angebote und die Lieferantenauswahl mit, weil die Kosten auf die wirklich beauftragten Projekte umgelegt und deshalb bei Angebotsabgabe einkalkuliert werden. Ein weiterer Nachteil besteht darin, dass in der Regel fallende Hardwarepreise keine Beruecksichtigung finden, sobald mit Festpreisen operiert wird.

Im so verstandenen freien Wettbewerb geht Unternehmen darueber hinaus Know-how in Form von Betriebskenntnissen und eingespieltem Vorgehen verloren. Die Wiederverwendung existierender Objekte oder Module, mit deren Hilfe sich Kosten senken liessen, wird schwierig.

Kurz gesagt, an die Optimierung der Wertschoepfungskette ist bei einem solchen Vorgehen nicht zu denken.

"Treue zahlt sich aus" - dies zeigt sich, sobald man in Projekten den Weg des Lean Managements waehlt, der die Projektabwicklung in jeder Phase erheblich optimiert. Wichtigstes Kennzeichen dieses Vorgehens ist eine neue Form der Zusammenarbeit aller Lieferanten in firmenuebergreifenden strategischen Kooperationen und Partnerschaften. Die Verbindung erstreckt sich nicht auf ein Projekt allein, sondern ist langfristig angelegt. Dadurch entwickelt sich ein eingespieltes Arbeiten der beteiligten Unternehmen. Teure Reibungsverluste lassen sich reduzieren. Der Zeitaufwand fuer Kommunikation, den der Auftraggeber immer bezahlen muss, verringert sich erheblich.

Im Interesse eines optimalen Zusammenspiels ist es vor allem wichtig, dass Lieferanten und Anwender einheitliche Tools und Vorgehensmodelle einsetzen. Das geht in der Regel nur durch Verwendung eines CASE-Tools.

Die Zusammenarbeit sollte sich darueber hinaus durch Langfristigkeit sowie Vertrauen unter den Beteiligten auszeichnen. Wiederverwendbarkeit bereits existierender Objekte muss das Ziel aller mitarbeitenden Softwarelieferanten sein. Dabei geht es auch darum, dem Pool des Anwenders neue Objekte zuzufuehren.

Wird ein solches Vorgehen gewaehlt, werden Fachabteilungen natuerlich wesentlich staerker in die Verantwortung genommen als bei der Projektuebergabe an einen Generalunternehmer. Sie muessen entweder eigenes Organisations-Know-how aufbauen oder aber auf einen Berater, der eine moeglichst optimale Projektorganisation gewaehrleistet, zurueckgreifen.

In beiden Faellen muss der Anwender mehr Mut aufbringen, Verantwortung fuer sein eigenes Projekt zu uebernehmen. Dies wird allerdings durch die Vorteile aufgewogen, die ein solches Verfahren mit sich bringt. Der Hauptnutzen entsteht durch den groesseren Entscheidungsspielraum im Laufe von Projekten, die im industriellen Bereich haeufig Laufzeiten von zwei bis drei Jahren haben. Risiken sind beim heutigen Grad der Standardisierung mit X- Windows oder Unix viel leichter einzuschaetzen und koennen durch Einsatz eines Spezialisten weiter minimiert werden.

Erfahrungen haben gezeigt, dass sich bei derartigen Projekten ein Vorgehen in folgenden Phasen bewaehrt:

- Ueberpruefung der Entscheidung fuer das geplante DV-Projekt, zum Beispiel mit Hilfe einer Portfolioanalyse, die den Nutzen fuer das Unternehmen betrachtet;

- grobe Definition der Projektanforderungen, bezogen auf Hardware, Vernetzung, Oberflaeche, Leistungsmerkmale der Anwendung, Einbeziehung existierender Module, sowie Festlegung des Vorgehensmodells zur Erstellung des DV-Systems;

- Plankostenermittlung fuer eine mitlaufende Spiegelung der Ist- Kosten;

- Auswahl von Systemlieferanten im Sinne firmenuebergreifender Vertriebskanaele, die bereits an der Entstehung des Projektes beteiligt sind sowie

- Aufteilung in kleinere Einheiten (Teilprojekte) und deren Vergabe an verschiedene, spezialisierte Realisierer.

Kosteneinsparungen von Anfang an im Auge haben

Unter Kosten-Nutzen-Gesichtspunkten betrachtet, sind solche Anwendungssysteme ueberholt, die Entwickler nach einer Kurzanalyse im Betrieb gemaess ihren eigenen Vorstellungen realisieren und dann dem Anwender in fertigem Zustand vorsetzen. Die Spielraeume fuer dieses Vorgehen sind nicht mehr vorhanden.

Ebenso wie bereits in der Angebotsphase lassen sich bei der eigentlichen Realisierung des Projektes Kosten sparen, sobald die Prinzipien des Lean Managements angewandt werden. Das Hauptaugenmerk richtet sich dabei auf die Produktentwicklung, die wesentlich transparenter erfolgt als bisher. Voraussetzung ist auch hier die enge und vertrauensvolle Zusammenarbeit von Lieferanten und Anwendern.

Eine effiziente Systementwicklung ist nur ueber einen Know-how- Transfer moeglich. Anwender und Entwickler muessen sich staendig austauschen. Dabei dient das Praxis- und Fachwissen des Anwenders dem Entwickler als staendiges Korrektiv fuer seine Arbeit. Das DV- und Anwendungssystem-Wissen des Entwicklers verhilft wiederum dem Anwender zum besseren Verstaendnis der Systemkonzeption. So entsteht genau das Anwendungssystem, das tatsaechlich gebraucht wird.

Weitere Voraussetzung fuer die Optimierung der Wertschoepfungskette im Entwicklungsprozess ist die gemeinsame Arbeit in einem interdisziplinaeren Team. Nur wenn Anwenderwissen, Methodenwissen, Analyse, Systemgestaltung, Tool-Einsatz, Implementierung und Projekt-Management zusammenfliessen und in einem gemeinsam festgelegten Vorgehensmodell kombiniert werden, garantiert dies den Erfolg eines DV-Entwicklungsprojektes. Das Vorgehen muss durch Systematik, Integriertheit und allzeitige hohe kommunikative Kompetenz gekennzeichnet sein. Als Verstaendigungs- und Dokumentationshilfsmittel haben sich CASE-Tools bewaehrt. Sie ermoeglichen eine knappe, klare und staendig aktualisierbare Dokumentation sowie eine effektive Kommunikation zwischen Entwicklern und Anwendern. Ein Problem koennen heute indes noch die Darstellungen der CASE-Tools sein, zum Beispiel der ER-Modelle, die fuer Anwender ohne ausreichende Schulung recht schwer zu verstehen sind. Hier sind die Tool-Hersteller aufgerufen, Verbesserungen vorzunehmen.

Die notwendige hohe Verantwortung und Handlungskompetenz der Teammitglieder sind nur bei sinkender Arbeitsteilung zu erreichen. Im Sinne von Lean Production wird die Qualitaetssicherung als staendiges Verbesserungsinstrumentarium in das Entwicklungsteam verlegt, denn kosten-, qualitaets- und zeitgerechtes Verhalten kann nicht erprueft, sondern muss geplant und produziert werden.

Da Anwender und Entwickler festen Kontakt halten, koennen notwendige Korrekturen fruehzeitig vorgenommen und Kosten gesenkt werden.

Die Erfahrung hat gezeigt, dass die Aenderungskosten in der Anfangsphase eines Projektes noch relativ niedrig sind. Das aendert sich gravierend, je weiter ein Projekt fortschreitet. Unter Umstaenden kann eine spaete Aenderung teurer kommen als das urspruenglich geplante Vorhaben (vgl. Abbildung 1). Der Konzeption kommt daher im Vergleich zur eigentlichen Entwicklung eine immer groessere Bedeutung zu. Sie muss so gestaltet werden, dass die Wirklichkeit moeglichst genau erfasst wird und so viele Aenderungen wie moeglich gleich zu Beginn des Entwicklungsprozesses erfolgen koennen.

Zu Beginn des Projektes muessen alle Rahmenbedingungen und Zieldefinitionen abgestimmt werden, um spaetere Reibungsverluste zu vermeiden. In diesem Sinne erfordert Lean Production auch vom Management erhoehte Aufmerksamkeit in der Konzeptionsphase von Projekten.

Herkoemmliche DV-Projekte lenken in der Regel das Hauptaugenmerk auf die Realisierung der Anwendungssoftware und die Bereitstellung von Hardware und Systemsoftware. Die Einbeziehung der organisatorischen Ablaeufe wird konzeptionell in aller Regel vernachlaessigt. Genau das ist im Sinne einer schlanken Entwicklung falsch. Softwaresysteme sollen nicht einfach bestehende Organisationsablaeufe nachbilden. Mit der Einfuehrung eines neuen DV-Systems besteht die Chance, auch die Organisation zu optimieren. Organisatorische Ablaeufe sollten bei dieser Gelegenheit ueberdacht und DV-technisch vereinfacht werden. Richtig verstandene DV-Entwicklung ist also auch ein Stueck Organisationsentwicklung (vgl. Abbildung 2).

Werden die Prinzipien des Lean Managements umgesetzt, bedeutet dies in DV-Projekten die zeitlich parallele Entwicklung von Anwendungssystem und Organisation sowie die Vorbereitung der Mitarbeiter auf die neuen Arbeitsformen. Der Weg, den der Anwender gemeinsam mit dem Entwickler bei der Erstellung des Anwendungssystems zuruecklegt, hat die gleiche Bedeutung wie das fertige System.

Akzeptanzprobleme, falsche oder fehlende Funktionalitaeten und enormer Aenderungsaufwand sind grundsaetzlich auf die Vernachlaessigung des Entwicklungsprozesses zurueckzufuehren.

DV-Systeme der Zukunft basieren auf PCs und Windows

Ein DV-System im Sinne der Lean-Prinzipien muss durch Flexibilitaet, Effektivitaet, Anwenderakzeptanz, Qualitaet, einfache Wartbarkeit und Aenderbarkeit ueberzeugen. Dies fuehrt in Richtung Client-Server-Loesungen mit PCs und grafischen Oberflaechen auf Windows-Basis und weg von grossen, zentralen, unflexiblen Anwendungssystemen.

Wichtig sind ausserdem standardisierte Schnittstellen wie Object Linking and Embedding (OLE) zu bereits verwendeten arbeitsplatzorientierten Softwareprodukten wie Excel, QiE oder Word fuer Windows.

DV-Systeme, die auf diese Weise zukuenftigen Entwicklungen gerecht werden und die durchgaengig mit einem einheitlichen Vorgehensmodell aller Beteiligten entwickelt wurden, sind noch selten. Die Tatsache aber, dass es sie bereits gibt, zeigt den Weg der zukuenftigen Entwicklung.

Abb. 1: Je weiter ein Projekt fortgeschritten ist, desto teurer kommen Aenderungen.

Abb. 2: Mit neuen Programmen kann eine kostensenkende Umorganisation der Unternehmensablaeufe verbunden sein.

*Gerhard Schleef ist DV-Berater bei der Idap GmbH, Koeln.