Downsizing in der Praxis:

Migration setzt vor allem klar definierte Plattformen voraus

22.11.1991

Eigentlich ist es eine unzulässige Einschränkung. Wenn Downsizing immer wieder als strategisches Konzept zur Verlagerung von Host-Lösungen auf dezentrale Server- oder PC-Systeme verstanden wird umfaßt dies nur einen Teilaspekt. Downsizing kann nämlich auch als grundlegende Strategie für eine vollkommen neue Informatiklösung durchgesetzt werden. Johannes Lang beschreibt, welche Strategien, Methoden und Werkzeuge sich in der Praxis bewährt haben.

Der konkrete Fall: Ein weltweit operierendes Pharmaunternehmen mit Niederlassungen in über 40 Ländern will ein DV-gestütztes Marketing-Informationssystem aufbauen. Die Ausgangslage spiegelt die Situation der meisten Unternehmen wider. Länder-Dependancen ohne eigene Informatikausstattung agieren neben Niederlassungen mit PC-Insellösungen. Ohne allgemein verbindliche Informationsstrategie ist selbst zwischen den computerisierten Organisationseinheiten kein elektronischer Datenaustausch möglich.

Damit alle 40 Niederlassungen weltweit den gleichen Informationsstand erreichen, ist der reibungslose Zugriff auf alle relevanten lokal gespeicherten Informationen aufzubauen. Über 400 Benutzer mit verschiedenen Arbeitsgebieten und unterschiedlicher Qualifikation sollen zukünftig grenzüberschreitend kommunizieren. Kurze Aktualisierungszyklen der Datenbestände sind dabei ein Muß, neueste Computertechnologien sollen als Pilotprojekt für eine zukünftige Informatikstrategie evaluiert werden. Das Unternehmen definiert seine Strategie, um die Informationsverfügbarkeit zu verbessern, und sucht sich einen Partner für die Umsetzung.

Die Zusammenarbeit mit einem externen Partner - in diesem Fall der Programator GmbH - liegt auf der Hand. Schließlich kann damit nicht nur die Umsetzung des Projektes beschleunigt, sondern angesichts der Komplexität auch das Realisierungs-Risiko minimiert werden. Fehlende Erfahrung des Kunden mit neuen Technologien konnte der externe Partner sowohl durch seine Marktkenntnis und realistische Einschätzung der Produktreife auffangen. Der Pharmakonzern entschied sich für Programator, dem größten skandinavischen DV-Dienstleistungsunternehmen mit über 2700 Beratern. Federführend übernimmt die deutsche Dependance das Projekt.

Von vornherein waren die Aufgaben klar abgegrenzt. Der Kunde übernahm die Projektverantwortung, stellte Personal für eine aktive Mitarbeit und war zuständig für die Plazierung des Systems in der Organisation. Der Systemintegrator konzipierte die Projektorganisation, erstellte das technische Lösungsraster, realisierte die Applikationen und unterstützte bei der Einführung. Diese enge Kooperation führte zu hoher Transparenz und klaren Entscheidungsprozessen.

Im Rahmen eines Festpreisvertrages mit definiertem Leistungsumfang etablierte der Outsourcing-Anbieter eine zentrale Projekt-Management-Gruppe. Als wesentlicher Faktor für die spätere Akzeptanz siedelten die Berater die Projektleitung in der Benutzerorganisation an. In dem homogenen Team arbeiteten zeitweise bis zu 40 Mitarbeiter vom Kunden und von Programator. Diese direkte Einbindung aller beteiligten Gruppen direkt im Entscheidungsgremium zahlte sich aus.

Besonders hohen Stellenwert hatte in diesem Zusammenhang das Prototyping. Da zum Projektstart im Jahre 1988 Bildschirm-Icons, Pull-Down-Menüs oder Push-Buttons zumindest in Anwenderkreisen noch weitgehend unbekannt waren, fehlte den Benutzern die Vorstellungskraft für die geplante grafische Benutzerschnittstelle. Eine theoretische Spezifikation hätte deshalb kaum Entscheidungssicherheit gebracht. Leistungsfähige Tools, die funktionierende Prototypen erzeugten, machten es den späteren Benutzern leicht, die Praxistauglichkeit direkt zu überprüfen. In einem inkrementellen, zyklischen Entwicklungsprozeß diente das Feedback zur Verbesserung der funktionsfähigen , Basisprototypen. Ein straffer Zeitplan führte dann termingerecht zum Zielsystem.

Wie bereits beschrieben, waren die Anforderungen der Applikationsentwicklung rechtzeitig von der Projekt-Task-force abgesteckt. Die permanente und dynamische Zielkorrektur durch direktes Feed-back sorgte zudem dafür, daß das System jederzeit mit den organisatorischen Gegebenheiten Ó jour ist.

Dennoch gab es Restriktionen. Beispielsweise zählen dazu die schwierige Lage bei PC-Betriebssystemen, die geringe Auswahl an PC-Tools, die fehlenden objektorientierten Datenbank-Tools oder die mangelnde Integration von Benutzerschnittstellen mit Datenbank-Plattformen. Dieser Mangel ist zu gleichen Teilen vom Markt wie von den internen Gegebenheiten verursacht.

Schließlich war die Abbildung der Organisation im System eine Grundvoraussetzung. Neben den beschriebenen organisatorischen Gegebenheiten trugen insbesondere fehlende Standards im Bereich Office-Automation sowie bei Datenbanken, Netzwerken oder für die Verbindung vom PC zum Host zu den Problemen bei. Die Berater sorgten dafür, daß Altlasten nicht übernommen wurden, eingespielte und bewährte Abläufe konnten jedoch beibehalten werden.

Die Marktdefizite und die starke Benutzerorientierung lenkten das Projektteam jedoch nicht von einer zielorientierten Applikationsentwicklung ab. In einem Basiskonzept legten die Verantwortlichen deshalb alle zentralen Anforderungen fest:

- Das geplante Marketing-Informationssystem basiert auf verschiedenen Teilsystemen, die zu einem Daten- und Funktionen-Pool zusammengefaßt sind. Als drei wesentliche Säulen fungieren dabei die kundenspezifischen Applikationen im Datenbankbereich mit einem leistungsfähigen Dokumenten-Retrieval sowie Office-Automation und Kommunikation.

- Um den unterschiedlichsten Qualifikationen der Benutzer gerecht zu werden, war eine einheitliche, grafisch orientierte Benutzerschnittstelle selbstverständlich.

- Für eine transparente Applikation sollte für jeden Arbeitsplatz das Leistungsangebot maßgeschneidert werden. Dieser individuelle Zuschnitt befreit den Anwender von unnötiger Funktions- und Datenfülle und unterstützt gleichermaßen zielorientierte Abwicklungen.

- Der Aufbau eines weltweiten Informationsnetzes stützte sich auf das proprietär vorhandene Netz des Kunden. Auf diesem Trägermedium sollten weltweit verfügbare Kommunikations-Optionen etabliert werden.

Auf dieser Grundlage schälte sich das technische Konzept heraus. Offenheit für zukünftige Erweiterung ergab sich allein schon aus der geforderten Flexibilität.

- Die einheitliche grafische Benutzeroberfläche ermöglicht die direkte Einbindung von Standardpaketen. Gleichzeitig konnten punktuell bereits vorhandene Anwendungen mit dem neuen System zusammengeführt werden. Das Work-Group-Konzept verknüpft dabei neben den spezifischen Applikation, der Kommunikation und des Bereiches Office-Automation sogar private Tools der Benutzer.

- Neben der klassischen Programmierung mit "C" sollten- ganz State of the Art - erstmals geeignete Anwendungen objektorientiert realisiert werden. - Distributed Processing und verteilte Datenhaltung ergab sich als logische Konsequenz aus der gegebenen Organisationsstruktur. Daraus leiteten die Berater lokale Netze auf PC-Basis mit flexiblem Informationsdurchgriff ab. So konnte für jede Niederlassung ein kostengünstiges Server-Konzept etabliert werden. Bei überschaubaren Datenmengen bleibt jede Lokation unabhängig. Der Stern kristallisierte sich wegen seiner vereinfachten Netzunterstützung als geeignete Topologie heraus.

- Alle international relevanten Daten werden zentral in einem sogenannten Global-Server-LAN als Kopie gehalten. Dadurch entstehende Redundanzen nimmt man in Kauf. Sie sind vor allem deshalb unkritisch, weil nur der jeweilige Urheber schreibend auf sie zugreifen darf.

- Den Verbund der lokalen Netze über das vorhandene Wide Area Network (WAN) schien nicht nur nahliegend, sondern zeitigte auch Synergieeffekte. Da die lokalen LANs jedoch als autonome Einheiten arbeiten, erfolgt eine Netzbelastung im WAN nur beim aktuellen Informationszugriff. Wahlweise kann in diesem Konzept der Zugriff zu den Zentralrechnern über Gateways (Beispiel E-Mail) oder durch integrierte Terminalemulationen erfolgen.

Das Migrationskonzept sieht weiterhin vor, daß für jede zentrale Komponente eine klar definierte Plattform geschaffen wird. Grundsätzlich gilt dabei die Maxime, nur dann Eigenentwicklungen einzusetzen, wenn auf dem Markt keine geeigneten Standards zu finden sind. Daß aufgrund der spezifischen Anforderungen eine bunte Multivendor-Umgebung entsteht, paßt auch in das Konzept des Kunden. Schließlich gerät er so nicht in Abhängigkeiten. Und eine generelle Offenheit der Lösung ist durch eine gewissenhafte Auswahl zukunftsträchtiger Produkte sichergestellt.

- Selbst im schnellebigen PC-Markt können diese Vorgaben umgesetzt werden. Um dem PC als Frontend entsprechende Perspektiven offen zu halten, entschied sich das Projektteam für Windows 3.0 und die LAN-Software Novell Netware 386.

- Um die Applikationen für die Zukunft zu rüsten, entschied man sich als Datenbank-Front-end für SQL-Windows mit der relationalen SQL-Base, beides vom US-amerikanischen Anbieter Gupta Technologies. Dieses Konzept unterstützt sowohl Stand-alone-Workstations als auch die definierte Netzplattform. Flexible Reporting-Funktionen erzielte man mit einer direkten Einbindung von Microsoft-Excel.

Konventionell programmierte das Team unter "C", bestimmte Applikationen entstanden allerdings mit dem objektorientierten Tool "Actor".

- Der internationale Verbund der einzelnen Workgroups wurde mit einem Package-switched WAN-Network nach X.25-Standard realisiert. Die Anbindung der nationalen LANs erfolgt via Eicon-Router.

- Damit die Kommunikation zwischen allen Beteiligten klappt, setzt das Unternehmen als Kommunikations-Interface zu den bestehenden Host-Systemen "All-in-1", "Disoss" sowie das Lotusprodukt "CC:Mail" ein. Letzteres PC-basierte E-Mail-Tool ist derzeit eines der wenigen Kommunikationswerkzeuge unter Windows, das bereits für die kommenden Standards X.400 oder MHS gerüstet ist. Zudem sind alle Gateways und notwendigen Interfaces vorhanden oder leicht via Softswitch implementierbar. Eine spätere Umstellung auf Application Programming Interfaces (APIs) ist möglich, diese sind jedoch derzeit nicht verfügbar.

Besonders wichtig ist in diesem technischen Realisierungs - konzept die darin vorgesehene Flexibilität. Zwar gibt es praxiserprobte Präferenzen, Programator ist jedoch insgesamt für viele Varianten offen.

Damit jede Variante trotzdem das homogene Ganze nicht gefährdet, werden gerade bei Applikationen im schnellebigen PC-Markt grundsätzlich Machbarkeitsanalysen durchgeführt. Durch technisches Prototyping kann man ein kontrolliertes Risiko durchaus eingehen. Dabei werden jedoch Alternativlösungen aufgezeigt, auf die man im schlimmsten Fall mit vertretbarem Aufwand umsteigt.

Ohne direkten Kontakt zu den Anbietern der im technischen Konzept beschriebenen Produkte ist dies allerdings nicht möglich. Weil Projekte dieser Art auch Allianzen erfordern, besteht eine Aufgabe des externen Systemintegrators darin, Partnerschaften aktiv zu pflegen. Das führt im Einzelfall durchaus auch zum Wechsel einer Plattform. So wurde die ursprünglich geplante Datenbank nicht zuletzt wegen der unzureichenden Unterstützungspolitik von Oracle durch die SQL-Base der kooperativen Gupta Technologies ersetzt. Schließlich ist der Lösungsansatzes entscheidend von der Zuverlässigkeit des Herstellers bestimmt.

Ganz generell lebt ein so komplexes internationales Projekt von der Zuverlässigkeit und Disziplin aller Beteiligten. Ohne partnerschaftliches Verständnis sind dem technisch Machbaren schnell Grenzen gesetzt. Dies zeigt sich insbesondere bei der Einführung des Systems in den operativen Betrieb.

Zuverlässigkeit und Disziplin gefordert

Wichtig bei einem Projekt wie dem beschriebenen ist es, die Verantwortung beim Kunden zu belassen. Das hat den Vorteil, daß auf lange Sicht keine Abhängigkeiten entstehen. Bei dem beschriebenen multinationalen Projekt erfordert die Komplexität User-Support auf höchstem Niveau. In der Praxis zeigt sich, daß Downsizing kaum Personal für Maintenance und Support reduziert. Da jedoch Kosten für Fremdwartungen weitgehend entfallen, dient eine Budgetverschiebung in Richtung User-Support ausschließlich der Produktivität.

Im Sinne der Benutzer wurde ein dreistufiges Betreuungskonzept entwickelt. Ganz klar ist, daß dezentrale Systeme auch dezentralen Support benötigen - zumindest für das Tagesgeschäft. Ein zentrales Support-Team fungiert als Help-Desk für komplexe Probleme. Erst auf der dritten Ebene bleibt der externe Partner im Boot, um Weiterentwicklungen sicherzustellen. Diese Aufgabenteilung minimiert externe Kosten und schafft gleichzeitig Zukunftssicherheit.

Bleibt die Frage, welche Trainingsmaßnahmen bei rund 400 Benutzern angebracht sind. Die Qualifizierung der Anwender ist denn auch integraler Bestandteil des Gesamtprojektes. Als organisationskonforme Schulungsmethode bietet sich bei der heterogenen und verstreuten Endanwendergruppe computergestütztes Training (CBT - Computer Based Training) an. Die Gesamtkosten des CBT-Systems sind in diesem Fall nicht höher als die finanziellen Mittel für die Reisekosten der zum zentralen Training delegierten Anwender.