Mit Dipl.-Ing. Hans Kober, EDV-Leiter bei der Wacker Chemie GmbH, München, sprach Dr. Gerhard Maurer
-Bei der Wacher Chemie gibt es seit Anfang 1975 an der Schnittstelle Fachabteilung/EDV-Abteilung nur noch ein Kommunikationsmittel, nämlich das HIPO-Diagram. Warum?
In den vergangenen Jahre hörte man immer häufiger die Parole "Computer auf dem Weg zum Endbenutzer" - und zwar durchaus zu Recht. Wenn man als EDV-Chef diesen Trend unterstützen will, dann ergibt sich sehr schnell das Problem, wie die EDV-Abteilung mit dem Endbenutzer kommunizieren soll. In dem Maße, in dem Computerleistung am Arbeitsplatz verfügbar wird, etwa in Form von Bildschirm-Terminals, muß eine Brücke von der EDV zum Anwender geschlagen werden. Auf der Suche nach geeigneten Systemen stößt man sehr schnell auf die Antwort. Und die heißt: Dokumentation, die sich nicht im Präsentieren von Flußdiagrammen, Blockdiagrammen oder Umwandlungslisten darstellt, sondern möglichst projektbegleitend entsteht, und zwar in einer Form, die dem Anwender verständlich ist und sein Problem möglichst umfassend und eindeutig beschreibt.
-Das zu leisten, geben heutzutage verschiedene Verfahren vor. Überbegriff: Orgware. Details: Normierte Programmierung, Strukturierte Programmierung, Chief-Programmer-Team und vieles mehr. Sie haben sich statt dessen für HIPO entschieden.
HIPO ist keineswegs als Mitbewerber zu den von Ihnen erwähnten neuen Methoden zu sehen, sondern als deren Bestandteil. HIPO ist eingebettet einmal in Methoden der Projektabwicklung und des Projektmanagements sowie in Methoden der Programmierung und Implementierung Komplexer EDV-Systeme. HIPO begleitet den Benutzer von der Strukturierung seines Problems, über unterschiedlich detaillierte Dokumentation in den einzelnen Projektphasen, bis hin zur Einführung.
-Hier müssen wir auf die Fachliteratur verweisen, dies nur kurz: HIPO steht für Hierarchy-Input-Processing-Otput und wurde Anfang des Jahrzehnts in IBM-Labors als Verfahren für die Systemprogrammierung entwickelt. Wann haben Sie zum ersten Mal von HIPO gehört?
Ich bin HIPO zum ersten Mal 1974 auf einer USA-Reise im Zusammenhang mit Diskussionen über den Einsatz von Chief-Programmer-Teams begegnet. Da wir uns zu diesem Zeitpunkt auf der Suche nach einem gegeigneten Dokumentationssystem befanden, wurde beschlossen, diese Methode als Brücke der EDV zum Benutzer einzuführen.
-Wie ging das organisatorisch vor sich? Wie hoch war der Schulungsaufwand?
Wir haben im Dezember 1974 für Mitarbeiter der Fachabteilungen eine hausinterne Schulung durchgeführt. Dauer: Etwa zweieinhalb Tage. Es handelte sich dabei um Mitarbeiter der Fachabteilungen, die als EDV-Koordinatoren tätig waren oder tätig werden sollten.
-Geschah dies nun, damit Sie sich als EDV-Abteilung die Arbeit erleichtern konnten?
Für die EDV-Abteilung bedeutete die Einführung des Verfahrens in die Praxis zunächst Mehraufwand. Es stellte sich jedoch sehr schnell heraus, daß der Gesamtaufwand für ein Projekt unter Einbeziehung der Dokumentation geringer war. Bekanntlich kommt ja die Dokumentation im Verlauf eines Projektes aus Zeitgründen immer zu kurz.
-Betrachten Sie das HIPO-Verfahren nun als eine Dokumentations-Methode oder System-Design-Methode.
Primär ist das HIPO-Verfahren sicher eine System-Design-Methode - mit dem Vorteil, daß die Dokumentation projektbegleitend - sozusagen notwendigerweise - mit anfällt, als höchstnotwendiges Nebenprodukt.
-Wer nun erarbeitet die HIPO-Diagramme?
Entweder EDV-Spezialisten oder die Projektleiter der Fachabteilungen. Die HIPO-Diagramme entstehen in den gemeinsamen Ausschußsitzungen der Datenverarbeitung mit den betroffenen Fachabteilungen. Es spielt dabei keine Rolle, wer letzlich die dort erarbeiteten Ergebnisse zu Papier bringt. Es gibt Beispiele dafür, daß dies vom Benutzer ebenso geschehen kann wie von seiten der Datenverarbeitung.
-Also ist HIPO eine neue gemeinsame Sprache für Problemlösungen?
Sie haben recht. Dies ist nur möglich, weil im Verkehr zwischen Fachabteilung und Datenverarbeitung EDV-technische Details keinen Platz mehr haben. Der Anwender wird nicht mehr damit konfortiert, wie ein Problem für ihn maschinentechnisch gelöst wird. Gemeinsam erarbeitet wird vielmahr, welche Daten benötigt werden, um die von der Fachabteilung gewünschten Ergebnisse zu erzielen. Nicht die mehr ablauforientierten Flußdiagramme stehen dabei im Vordergrund, sondern die für eine Problemlösung benötigten Informationen, also die notwedingen Eingabedaten. Das ist, wie wir überzeugt sind, ein ganz erheblicher Fortschritt gegenüber der früheren Vorgehensweise, bei der der Benutzer in den meisten Fällen gezwungen wurde, Kompromissen zuzustimmen, die Einschränkungen im EDV-System aufzwangen.
-Für die EDV-Spezialisten heißt das doch wohl, daß nicht sie weiterhin Ziel und Verfahren der Systementwicklung prägen, sondern daß sie sich den Benutzerwünschen unterzuordnen haben.
Neue Methoden für die Zusammenarbeit mit der Fachabteilung - wie etwa HIPO -werden von EDV-Spezialisten oft als Aufgabe von in der Vergagenheit erreichten Positionen angesehen. Wir haben dennoch diesen Weg bewußt beschritten und wohl auch unser Ziel erreicht, nämlich eine enge Zusammenarbeit zwischen EDV und Fachabteilungen durch totale Transparenz dessen, was in der EDV geschieht - soweit erforderlich. Im übrigen werden an die Unternehmen in immer größerem Umfang Anforderungen an die Dokumentation von außen herangetragen: Die Anwendungen müssen für Finanzprüfer, Wirtschaftsprüfer, interne und externe Revision und nicht zuletzt für die Datenschutzbeauftragen und die jeweiligen Aufsichtsbehörden transparent sein. Die Prüfer werden sich im allgemeinen mit der Beantwortung der Frage begnügen, was in einem EDV-System passiert. Allein diese durch viele Gesetze und Verordnungen vorgeschreibenen Revisionsmöglichkeiten rechtfertigen den während der Projektlaufdauer scheinbar höheren Dokumentationsaufwand, der jedoch in der Phase der Wartung eines Projektes bei weitem wieder eingespart wird.
-An der Schnittstelle der EDV-Abteilung nach außen gibt es bei Ihnen also nur noch HIPO-Diagramme. Wie sieht es intern aus? Da gibt es ein umfangreiches DV-Handbuch, und sicherlich sind doch auch weiterhin Entscheidungstabellen, Struktogramme oder auch Flußdiagramme in der Praxis im Einsatz.
Es ist sicher anzustreben, daß HIPO auch von allen Mitarbeitender Datenverarbeitung bis hin zum Programmcodierer eingesetzt wird. Langfristig ist dies auch unser Ziel. Einer der Vorteile von HIPO liegt aber gerade darin, daß diese Methode einmal den zusätzlichen Einsatz von Entscheidungstabellen oder anderen Verarbeitungshilfen gestattet und daß zum anderen die Dokumentation nach HIPO an jeder beliebigen Phase des Projektes abgebrochen werden kann, ohne dadurch dem Projekt selbst zu schaden. Das gilt allerdings nur für die rein datenverarbeitungsorientierten Projekt-Phasen. Es gilt nicht, solange Dokumentation dazu benutzt werden muß, mit dem Anwender zu verkehren.
-So viele Vorteile bei nur zweieinhalb Tage Schulungsaufwand! Gibt es eigentlich auch Nachteile?
Selbstverständlich erschöpft sich der zu erbringende Aufwand nicht in zweieinhalb Tagen Schulung. Während der Projektlaufdauer ist ein nicht unerheblicher Aufwand an Denk- und Schreibarbeit zu erbringen, um der Dokumentation nach HIPO gerecht zu werden. Wenn man allerdings die Notwendigkeit einer systemgerechten Dokumentation als Bestandteil eines Projektes überhaupt anerkennt, dann ist HIPO sicher eine der geeignetsten Methoden. Ich sehe auch keinerlei Nachteile, insbesondere deshalb nicht, weil HIPO im Gegensatzt zu vielen anderen Software-Entwicklungshilfen keine systembedingten Auswirkungen hat wie etwa längere Laufzeiten oder höheren Hauptspeicherbedarf.
-Die Frage erübrigt sich: Sie also empfehlen den Kollegen, das HIPO-Verfahren ebenfalls anzuwenden. Kernfrage aber ist: Kann jeder EDV-Chef so einfach auf eine neue Systementwicklungs-Methode umsteigen?
Irgendwann kommt sicher jeder EDV-Chef einmal in die Lage, ein komplexes Gesamt- oder Teilsystem auf der grünen Wiese erstellen zu müssen. Das ist sicher der geeignetste - aber auch späteste - Zeitpunkt, um nach benutzernahen Dokumentationshilfen Umschau zu halten.
-Was aber, wenn man sich bis auf weiteres nicht auf der grünen Wiese tummeln darf oder kann? Würden Sie eine Empfehlung geben, hinsichtlich der Größe der Projekte, bei denen es lohnend wird, auf das neue Verfahren umzustellen?
Das hängt sicher von zwei Faktoren ab, einmal der angenommenen Lebensdauer eines zu dokumentierenden Systems und dem dafür zu erbringenden Aufwand. Ich würde sagen, daß unter der Annahme einer mittleren Lebensdauer, die einen mittleren bis hohen Wartungsaufwand erwarten läßt, die sinnvolle Grenze bei einer Projektdauer von etwa 20 Mann-Monaten liegen würde.
Hans kober (38), studierte Nachrichtentechnik (Dipl. Ing., TU München 1964) und ging danach für sechs Jahre als S.E. zur IBM. 1970 bis 1973 war er Leiter der europäischen Niederlassung der COGAR-CORP. Seither leitet er die Abteilung Datenverabeitung bei der Wacker-Chemie GmbH, München, dem größten bayerischen Chemie-Unternehmen (über 8000 Mitarbeiter, DM 1,3 Milliarden Jahresumsatzt).
Installiert bei Wacker sind eine 370/148 (2 MB) und eine 370/145 (1 MB)-beide laufen unter DOS-sowie 100 Terminals (unter CICS/VS).