Bedingungen ist eine explizite Entwicklungsstrategie

Synergie-Effekte reduzieren den SW-Entwicklungsaufwand

08.12.1989

Anwendungsentwicklung ist mehr als "reine" Projektabwicklung; im Mittelpunkt sollte eine explizit formulierte Entwicklungsstrategie stehen. Joachim Neuhaus* zeigt am Beispiel der Vertriebsfunktion bei einem Münchener Chemie-Unternehmen, wie sich eine Anwendung projektübergreifend entwickeln läßt.

In der "klassischen" EDV stehen zumeist eine oder mehrere Funktionen im Mittelpunkt der Entwicklung. Dabei bildet die DV-Lösung häufig die spezifische Ausführung der Funktion nach. Für ähnliche Funktionen ist diese sehr spezifische DV-Lösung nicht verwendbar. Der nachträgliche Einbau ist in der Regel mit erheblichem Aufwand verbunden Die Konsequenz heißt dann oft: Verzicht, doppelte Realisierung oder schnelle, aber unsachgemäße Einbeziehung.

Die Einführung logischer Datenmodelle beseitigt wesentliche Nachteile des (rein) funktionsorientierten Ansatzes. Die unternehmensweite Begriffsbildung erreicht, daß die Daten relativ stabil gegenüber funktionalen Änderungen bleiben. Datenmodellierung ist damit ein sinnvolles Vorgehen für eine effektive Software-Entwicklung.

Damit ist aber leider wenig über den Nutzen eines Projektes angesagt: Auch ein Projekt mit geringem Nutzen läßt sich sehr effektiv abwickeln. Die allgemein üblichen Nutzenrechnungen sind ebensowenig aussagekräftig.

Der Nutzenvergleich bestimmt das Vorgehen

Angesichts des auf lange Sicht nicht abbaubaren Anwendungstaus kann nur ein Nutzenvergleich der möglichen Projekte das eigene Vorgehen bestimmen (abgesehen von technischen Abhängigkeiten). Den Nutzenvergleich beschränken wir dabei auf die möglichen Projekte einer Anwendung.

Eine Anwendung ist für uns die spezifische Lösung für eine Grundaufgabe eines Unternehmens. Unter Anwendungsentwicklung verstehen wir deren gezielte Weiterentwicklung.

Grundlage für ein anwendungsorientiertes Vorgehen ist die projektunabhängige Übersicht über die Anwendung. Weiter ist - wiederum projektunabhängig - eine Schulvorstellung (Vision) davon zu entwickeln, wie die DV-Unterstützung mittel- und langfristig auszusehen hat.

Davon kann dann eine Entwicklungsstrategie dafür angeleitet werden, wie die Sollvorstellung zu erreichen ist. Diese Strategie enthält im technische n Teil Aussagen über die gewünschte Entwicklungsumgebung sowie über die einzusetzenden Methoden und Werkzeuge. Im fachlichen Teil wird die Reihenfolge der durchzuführenden Vorhaben definiert.

Während der Vorhabensabwicklung erfolgt eine permanente Koordination und Kontrolle, ob die laufenden Arbeiten die fachlichen Ziele und die technische Qualität respektieren. Eventuell sind steuernde Maßnahmen notwendig. Zu bestimmten Zeitpunkten werden auch die Sollvorstellung und gegebenenfalls die Entwicklungsstrategie überarbeitet.

Als Beispiel soll hier die Anwendung "Vertrieb bei der Wacker-Chemie" betrachtet werden. Dabei umfaßt der "Vertrieb" alle Tätigkeiten, die im Sinne der Leistungsverwertung einen Absatz bewirken beziehungsweise bewirken sollen.

Der Vertrieb braucht mehr Software-Leistungen

In einer unternehmensweiten lnterview-Reihe mit allen Betroffenen auf allen Hierarchie-Ebenen haben wir abgefragt, wer an welchen Geschäftsprozessen teilnimmt und welche Informationen er dafür benötigt. Als Ergebnis wurden die wesentlichen Geschäftsprozesse benannt, definiert und hierarchisch geordnet. Der Informationsbedarf und die vorhandene DV- technische Unterstützung zeigten eine große Nachfrage nach Software-Leistungen im Vertrieb. Insbesondere wurden auch die Probleme der Ist-Situation deutlich.

Mit ausgewählten Vertretern der einzelnen am Vertrieb beteiligten Konzernteile wurde dann in Form von Workshops eine Konzeption für eine neue Vertriebssoftware erarbeitet. Im Vordergrund standen dabei

- die Definition von Zielen für eine künftige Vertriebssoftware,

- eine Grob-Beschreibung der Ausgangssituation,

- die systematische Beschreibung der gegenwärtigen Schwachstellen,

- die daraus resultierenden Anforderungen,

- die Präzisierung der Geschäftsprozesse und der Informationen,

- die Benennung, Abgrenzung und Priorisierung der verschiedenen Projekte sowie

- die Identifikation der gemeinsamen fachlichen Basis aller Projekte.

Mitte der 70er Jahre erfolgte bei der Wacker-Chemie der Übergang, von der getrennten Datenverarbeitung - zum einen im Werk und zum anderen, in der Hauptverwaltung - hin zu einer zentralen Datenverarbeitung begleitet von einem Wechsel des Hardware-HerstelIers. Dazu wurde die den Verkauf unterstützende Software vollständig neuentwickelt. Schwerpunkte waren dabei die Auftragsbearbeitung (Online)und die Fakturierung (Batch), die Auftragslisten, eine Absatz-/ Umsatzstatistik sowie die Übergabe von Forderungen an die Finanzbuchhaltung.

In den Folgejahren wurde das System in unterschiedliche Richtungen weiterentwickelt. Die wichtigsten Meilensteine waren:

- die Kommunikation mit dem Produktionsinformationssystem,

- die Basis für die Produktergebnisrechnung,

--- die Übernahme der Auftragsdaten von Auslandstöchtern auf dem Wege der Datenfernübertragung,

--- die Verwaltung von Vertreterprovisionen,

--- diverse Funktionen der Versandabwicklung und ihre einseitige Anbindung an das Verkaufssystem (isolierte Systeme),

- die Gutschrift-/Lastschrifterstellung,

- die Behandlung von RückIieferungen,

- erweiterte beziehungsweise neue Auftragslisten und Statistiken,

- eine Langzeitstatistik des Verkaufs sowie

- die Verwaltung von Prognosedaten (isoliertes System).

Die Implementierung erfolgte zunächst mit PLI und CICS in Makro-Level, die Erweiterungen im HLPI-Level, später mit dem 4GL-Produkt Mantis und dem Listgenerator Easytrieve Plus. Als Datenbanksystem wurde IMS/DB benutzt, teilweise aber auch die "klassische" Datenverwaltung mit VSAM. Seit 1985 kamen die Programmiersprache Nomad 2 mit einer eigenen Dateiverwaltung und das Datenbanksystem DB2 hinzu.

Das bestehende System ist in mehrfacher Hinsicht problematisch: Beispielsweise sind wesentliche Vertriebsfunktionen nicht oder nur schwach abgedeckt - so die Verkaufsplanung oder die Angebotsverwaltung. Das gleiche gilt für die Vertriebsinformationen: Unter anderem fehlen Marktinformationen und Kundenkonditionen; beide werden nicht in den Stammdaten festgehalten. Außerdem stellt die Anzahl der eingesetzten Systeme extrem hohe technische Anforderungen an die Wartung.

Dazu kommt, daß die Systemarchitektur keine "wartungsfreundlichen" Programmiertechniken (wie zum Beispiel strukturierte oder modulare Programmierung) verwendet. Bei der branchenüblichen Fluktuation ist die Software damit in erhebliches "Betriebsrisiko"

Aufgrund der Ausgangssituation ist die Vertriebssoftware völlig neu zu organisieren. Dabei müssen folgende Vorgaben berücksichtigt werden:

1. Die Realisierung des neuen Systems in einem Akt ist nicht möglich; also sind mehrere Leitungsstufen notwendig, die sukzessive das alte System ersetzen beziehungsweise ergänzen

2. Während der Koexistenz alter und neuer Software-Komponenten darf der Vertrieb nicht beeinträchtigt werden; gegebenenfalls müssen alte und neue Komponenten miteinander kommunizieren .

3. Die "Schnittstellensysteme" können - zumindest im größeren Umfang - nur langfristig verändert werden; das neue System soll deshalb nach Möglichkeit die alten Schnittstellen versorgen .

4. Entwickelt wird gemäß den Richtlinien des Wacker-Vorgehensmodells (VGM). Dieses zerlegt den Software-Zyklus in die Phasen Voruntersuchung, Fachkonzept, Systementwurf, Programmierung und Test, Übergabe in die Produktion und Einführung sowie Wartung und Weiterentwicklung,

5. Der gesamte Vertrieb soll auf einem gemeinsamen logischen Datenmodell beruhen, und dieses wiederum wird in das unternehmensweite Datenmodell eingebettet. Physische Abweichungen sind zu begründen und nachvollziehbar zu dokumentieren (zum Beispiel bei Konflikten mit der Standardsoftware oder mit der Performance).

6. Soweit möglich, wird Standardsoftware eingesetzt. Für die Auftragsabwicklung ist dies eine Mußvorgabe, für andere Themen ist die Situation gegebenenfalls zu untersuchen.

7. Eigenentwicklungen erfolgen grundsätzlich in der 4CL-Sprache Nomad 2 und nach Möglichkeit mit DB2 als Datenbanksystem.

Fachlich wurden in der Neukonzeption folgende vier Projekte definiert:

-- Verkaufsplanung

-- Auftragsabwicklung,

-- Vertriebsstatistik und -berichtswesen sowie

-- Marktinformationssystem

Das Projekt Vertriebsstatistik und - berichtswesen wurde vorab nach hinten gestellt (Versorgung der alten Schnittstellen). Für die anderen Projekte ergingen Voruntersuchungsaufträge, in denen teilweise bereits bestimmte Leistungsstufen definiert waren.

Das Projekt Verkaufsplanung begann demnach mit der Leistungsstufe "Jahres- und Fünfjahresplanung". Die "Ergebnisvorausschau und Monatsplanung" wurde als zweite Leistungsstufe festgelegt, deren Realisierung nach dem Ende der ersten Leistungsstufe erfolgen soll. Es bleibt ein Projekt "Strategische Planung", über dessen Inhalt und Einordnung noch keine Übereinkunft getroffen werden konnte.

Im Projekt "Auftragsabwicklung" wurden einige Themen auf spätere Leistungsstufen verschoben, zum Beispiel die Provisionsabrechnung (Versorgung der alten Schnittstellen) oder die Edifact-Anbindung (noch nicht vorhanden). Eine weitere Aufteilung soll nach dem Fachkonzept erfolgen und ist vom Projektteam vorzuschlagen.

"Kompas" koordiniert die Einzelprojekte

Im Rahmen der Auftragsabwicklung wurde ein Projekt "Preisverwaltung" begonnen. Dieses Projekt soll als "arbeitsfähiger" Prototyp helfen, einen Themenkomplex neu zu organisieren, in dem bisher keine DV-Unterstützung stattfand, und die von uns gewählte Entwicklungsstrategie zu testen, bevor die "großen" Projekte die entsprechenden Projektphasen erreichen .

Für das Marktinformationssystem wurde zunächst eine zusätzliche Studie durch einen Hochschulprofessor im Rahmen eines Praxissemesters erstellt. Anschließend begann das Projekt mit der Voruntersuchung.

Zur Koordination der Einzelprojekte wurde das gemeinsame Dach "Kommunikationssystem für Marketing, Planung, Auftragsabwicklung und Steuerung" (Kompas) geschaffen. Kompas wird geführt durch eine gemeinsame Aufbauorganisation; sie besteht aus dem Auftraggeber (Geschäftsführung), einem Steuerungsgremium mit entscheidungsberechtigten Vertretern aller betroffenen Bereiche sowie aus der Projektüberwachung und den Projektteams mit je einem Kernteam und einem Fachteam

Die Projektteams können durch temporäre Teams zur Lösung spezieller (fachlicher oder technischer) Probleme ergänzt werden. Verantwortlich für die Kompas-Koordination ist die Projektüberwachung, das heißt der Leiter des Zentralbereichs "Vertriebsförderung und -administration" und der Leiter des Hauptreferats "Technik, Vertrieb und Materialwirtschaft" im Zentralbereich "Informatik und Kommunikationswesen".

Beratend unterstützt wird die Projektüberwachung durch zwei Personen, darunter eine externe Mitarbeiterin. In regelmäßigen Teamkoordinationsmeetings (alle 14 Tage) werden die Projektstatusberichte und Projektprobleme von der Projektüberwachung, ihren Beratern und den Leitern der Projektteams besprochen. An dem Projekt beteiligt sind die fünf Geschäftsbereiche, die Verkaufsregionen (Inland), die Vertriebstöchter (Ausland), das Rechnungswesen, die Konzernplanung, das Regionalmanagement, die Materialwirtschaft, die Werksleitung des Werks Burghausen, die Speditionsabbildungen der Werke und die zentrale Spedition. Insgesamt arbeiten zur Zeit etwa 50 Mitarbeiter für diverse Kompas-Aktivitäten, davon 15 als Kernteam-Mitarbeiter (Sollaufwand zwischen 50 und 100 Prozent), der Rest in den Fachteams (Aufwand zirka 20 Prozent).

Die fachlichen Koordination erfolgt je nach Bedarf über das gemeinsame logische Datenmodell und über die aus den Geschäftsprozessen abgeleitete integrierte Funktionsstruktur. Während der Neukonzeption des Vertriebs wurde ein erstes grobes logisches Datenmodell für den Vertrieb entwickelt. Dieses Datenmodell wird von den Projektteams weiterentwickelt Die jevueils pro Projekt benannten "Datenverantwortlichen" stimmen die Erweiterungen untereinander ab. Bei der endgültigen Verabschiedung ist zusätzlich die Zustimmung der Datenadministration notwendig.

Mit der Koordination des Datenmodells erfolgt auch die Abstimmung sonstiger Begriffe, da oft bei der Definition eines Begriffs noch nicht bekannt ist, ob er später zu einem Informationsobjekt wird. Dies gilt insbesondere für Begriffe, die möglicherweise Sub-Entitäten oder Generalisierungen bezeichnen.

Die grobe Funktionsstruktur aus der Neukonzeption des Vertriebs wird von jedem :Projekt verfeinert. Insbesondere wird auch der jeweilige Auslöser einer Funktion beschrieben sowie die Kommunikation mit anderen Funktionen.

Die Kommunikation kann dabei indirekt über das Datenmodell stattfinden (und ist damit nicht abstimmungsbedürftig), direkt über Meldungen oder auch über Aufrufschnittstellen. Eine gegenseitige Abstimmung zu Funktionen erfolgt grundsätzlich immer dann, wenn der Auslöser einer Funktion aus einem anderen Kompas Projekt stammt oder eine direkte Kommunikation mit einer Funktion aus einem anderen Projekt stattfindet.

Im Rahmen der technischen Koordination wird versucht gleichartige Ergebnisse durch die Bereitstellung von Dokumentations- und Entwicklungsrichtlinien zu vereinheitlichen. So wurden zum Beispiel im Rahmen der Preisverwaltung folgende allgemeine Ergebnisse erarbeitet:

-- ein Standard für die Beschreibung von Dialogen,

-- eine Systemarchitektur mit einem Schichtenmodell für die Modularisierung der Dialoge,

-- ein Programmrahmen für jede Modulschicht und

-- einige allgemeine "Dienstleistungsmodule"

Die Verkaufsplanung soll im nächsten Jahr stehen

Diese Ergebnisse sind für die anderen Projekte verbindlich. Nicht ausreichende Konzepte sind im Rahmen der allgemeinen Ergebnisse zu überarbeiten, bevor sie in eines der anderen Projekte übernommen werden dürfen.

Bei der Verkaufsplanung wurde mit der Leistungsstufe "Jahres- und Fünfjahresplanung" begonnen und zunächst ein Prototyp für einen der Geschäftsbereiche bereitgestellt. Mit diesem Prototyp führten wir die Planungen für 1988 und 1989 durch. Es folgte die Fertigstellung der Voruntersuchung und des Fachkonzepts. Die Realisierung soll bis März 1990 abgeschlossen sein, so daß die Planung für das kommende Jahr bereits mit der neuen Software erfolgen kann.

Dabei kann sich die Schnittstelle zu den Auslandstöchtern ab nicht performant erweisen. Für diesen Fall haben wir Vorsorge getroffen, müssen dann jedoch in der zweiten Jahreshälfte 1990 eine Leistungsstufe "Verbesserter Anschluß der Töchter" einplanen.

Unsere Projekte fördern die Mitarbeitermotivation

Ansonsten beginnt in der zweiten Jahreshälfte die Leistungsstufe "Ergebnisvorausschau und Monatsplanung". Für diese Leistungsstufe läuft allerdings bereits jetzt ein Prototypprojekt (Aufwand: ein Mannmonat) für einen der Geschäftsbereiche.

Die Voruntersuchung für die Auftragsabwicklung wurde im März 1989 bereits fertiggestellt Das Ende des Fachkonzepts ist bis Dezember des laufenden Jahres geplant. Danach soll die Testinstallation der Standardsoftware erfolgen. Gleichzeitig läuft eine Untersuchung "Versandabwicklung", die eine Beschreibung der Ist-Abläufe und das Fachkonzept für diesen Bereich erarbeiten soll.

Für den Prototyp "Preisverwaltung" wurde die Leistungsstufe "Listenpreise" fertiggestellt und im August dieses Jahres eingeführt. Die Leistungsstufe "Kundenpreise" ist ebenfalls so gut wie fertig.

Für das Marktinformationssystem wurde eine erste Studie fertiggestellt, die zur Formulierung eines sinnvollen Projektauftrags notwendig war. Ebenfalls beendet ist die Voruntersuchung. Das Fachkonzept ist bis März 1990 geplant.

Obwohl der Vertrieb bei der Wacker-Chemie als erste Anwendung in dieser Form neu gestaltet wird, haben wir bereits einige ausgesprochen positive Erfahrungen gemacht: Die Formulierung des Vorgehens auf der Ebene der Anwendung führt zu einer "gemeinsamen Zukunftsvision" und macht das eigene Vorgehen und den zugehörigen Nutzen transparent. Dies führt zu einer "gemeinsamen Zukunftsvision" und macht das eigene Vorgehen und den zugehörigen Nutzen transparent. Dies führt bei wichtigen Entwicklungsaktivitäten zu einer erhöhten Management Beachtung und konsequenterweise zu einer verbesserten Durchsetzung der eigenen Ziele.

Bei den Mitarbeitern ergibt sich in der Regel eine bessere Kommunikation und Motivation. Aufgrund dessen haben wir bereits Probleme geklärt über die zuvor seit Jahren ohne Resultate diskutiert wurde. Allerdings sei davor gewarnt, die groben Modelle aus den ersten Schritten der Anwendungsbeschreibung zu sehr zu verabsolutieren. Oft müssen diese Modelle so sehr überarbeitet werden, daß sich ein Beharren darauf eher behindernd als fördernd auswirkt.

Für die Wacker-Chemie war es neu, eine Projektaufbauorganisation mit Projektinstanzen, genauer Aufgabenteilung und daraus abgeleiteten Abstimmungsaktivitäten explizit zu formulieren. Dieses Vorgehen hat die gesamte Projektarbeit klarer gemacht und mögliche Reibungsverluste von vornherein verringert.

Die Einbindung einer externen Beraterin in die Projektüberwachung hat sich als vorteilhaft erwiesen. Als Außenstehende ist diese Mitarbeiterin nicht an Bereichsinteressen gebunden.

Manager mußten Projekterfahrung sammeln

Die häufigen Koordinationsmeetings fuhren zu einer intensiven Kommunikation zwischen "oben und unten". Fehler, die wegen mangelnder Projekterfahrung aller Beteiligten unvermeidlich sind, werden ohne große Emotionen behoben.

Offene Fragen lassen sich somit: oft erledigen, bevor sie sich zu Problemen auswachsen. Insbesondere lernt das Management, mit Projektproblemen umzugehen und seinen Anteil an deren Behebung zu leisten. Gleichzeitig erfahren die Entwickler, wie sie sich von ihrer "beschränkten" DV-Sicht lösen und stattdessen stärker im Unternehmensinteresse denken können.

Die Trennung des Projektteams in ein Kernteam (Mitarbeiter mit hoher Verfügbarkeit) und ein Fachteam (Mitarbeiter mit geringer Verfügbarkeit) hat es uns ermöglicht, viele Unternehmensbereiche in die Projekte zu integrieren und außerdem einen Zugriff auf die "guten", in der Regel kaum verfügbaren Mitarbeiter zu erhalten. Diese Maßnahme hat einen positiven Einfluß auf die Ergebnisqualität und auf die Akzeptanz im Unternehmen.

Schnittstellen-Probleme waren zentrales Thema

Die heutigen Schnittstellenprobleme wurden zumeist bei der Weiterentwicklung der Anwendungen geschaffen. Ein Hauptmotiv ist die Intransparenz der Systeme: Abläufe werden nicht optimiert, Schnittstellen als Dateien mit zeitlicher Verzögerung bereitgestellt und Rückkopplungen vergessen.

Durch die Einbindung von "Schnittstellen-Vertretern" in die Projektteams, durch eine verbesserte Transparenz und durch die Einbettung des Datenmodells Vertrieb" in das Unternehmensdatenmodell hoffen wir, die bisherigen Schnittstellenprobleme zu vermeiden, zumindestens aber erheblich zu verringern.

Die parallel laufenden Projekte bieten die Möglichkeit Synergien zu nutzen. Bereits bei der Entwicklung läßt sich Aufwand einsparen, den man seinerseits zugunsten einer hohen Qualität reinvestieren kann. Da bei sind die Vorzüge für Wartung und Weiterentwicklung noch gar nicht berücksichtigt.

So ist der Aufwand für die Systemarchitektur zur Preisverwaltung für diese allein nicht zu rechtfertigen. Durch die sofortige Weiterverwendung in anderen Projekten ergibt sich jedoch ein Mehr an Qualität und ein Weniger an Aufwand.

Die Projekte führen zu internen Standards

Die Projektergebnisse lassen sich zu allgemeinen Standards weiterentwickeln. So nimmt Kompas eine Vorreiterfunktion zugunsten der gesamten Anwendungsentwicklung wahr.

Zum Beispiel wurde die Kompas-Aufbauorganisation vom Referat "Methoden und

Standards" zu einem Konzept "Projektmanagementverfahren für die Abwicklung von IV-Projekten" weiterentwickelt.

Das Konzept wird inzwischen konzernweit geschult. Andere Bereiche interessieren sich sogar für das Konzept als Vorlage zur Formulierung ihres spezifischen Projektmanagements (zum Beispiel die Anlagenprojektierung). In Ähnlicher Weise löst sich die obenerwähnte Systemarchitektur zu einem Standard machen. +

* Joachim Neuhaus ist Referatsleiter Vertrieb in der Anwendungsentwicklung bei der Wacker-Chemie GmbH in München.