Konfigurations- und Anwendungsplanung von EDV-Systemen [Reprint 2019 ed.] 9783111509716, 9783110043198

Citation preview

IS Informations-Systeme Herausgegeben von S. Dworatschek

Konfigurations- und Anwendungsplanung von EDV- Systemen von Stefan Ramer Mit 8 Abbildungen und 5 Tabellen

w DE

G Walter de Gruyter • Berlin • New York 1973

©Copyright 1973 by Walter de Gruyter & Co., vormals G. J. Göschen'sche Verlagshandlung - J. Guttentag, Verlagsbuchhandlung - Georg Reimer - Karl J. Trübner - Veit & Comp., Berlin 30. - Satz: IBM-Composer, Fotosatz Prill, Berlin. - Druck: Mercedes-Druck, Berlin Alle Rechte, insbesondere das Recht der Vervielfältigung und Verbreitung sowie der Ubersetzung, vorbehalten. Kein Teil des Werkes darf in irgendeiner Form (durch Photokopie, Mikrofilm oder ein anderes Verfahren) ohne schriftliche Genehmigung des Verlages reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. Printed in Germany. ISBN 3 11 0 0 4 3 1 9 X

Vorwort Das Entscheidungsproblem zur Einführung des ersten oder eines neuen Computer-Systems in einem Betrieb bedarf in zunehmendem Maße der kritischen Investitionsanalyse. Diese Erkenntnis setzt sich aus verschiedenen Gründen zunehmend durch: Viele Unternehmen stehen zum zweiten- oder drittenmal vor diesem Entscheidungsproblem und können auf jahrelange Erfahrungen mit Datenverarbeitungsprojekten aufbauen. Die direkten und vor allem die indirekten Computer-Kosten steigen. Das Verhältnis der technischen Computer-Leistung zum Management-Nutzen wird als unbefriedigend empfunden. Die zukünftigen Probleme der Informationsversorgung orientieren sich an den Fragen des Informationsbedarfs und der Informationskosten. Betriebliche Informationssysteme (MIS) sind organisationsbestimmend. Wenn Investitionsanalysen bei der Informationsversorgung als notwendig erkannt werden, so stellt sich die Forderung nach geeigneten Analysemethoden. Der Autor dieser Arbeit weist darauf hin, daß vier Gruppen an der Entwicklung derartiger Methoden interessiert und beteiligt sein sollten: Hersteller, Anwender, Berater und Hochschulen. Er selbst bietet ein OR-Verfahren an, mit dem der Entscheidungsprozeß zur Bestimmung des Computer-Systems (Organisationsstudie, Konfigurationsauswahl) transparent gemacht, verkürzt und optimiert werden kann. Zu begrüßen ist, daß die Probleme der Datenbeschaffung nicht vernachlässigt werden. Vielmehr zeigt der Autor Schätzmethoden zur Bestimmung technischer und ökonomischer Koeffizienten. Ein realistisches Beispiel zeigt das Gesamtmodell. Diese Arbeit bietet jedem Anregungen und Hilfen, der am Projekt-Management von Datenverarbeitungsvorhaben beteiligt ist.

Bad Zwischenahn, Februar 1973

Der Herausgeber

Inhaltsverzeichnis Vorwort

5

1. Einleitung. Methodologie der Unternehmensforschung

9

2. Das EDV-Planungsproblem 2.1

2.2

15

Allgemeine Darstellung des Entscheidungsproblems. Abgrenzung der Thematik

15

2.1.1 Abgrenzung gegenüber Organisationsstudie und Anwendungsanalyse (Phase I)

16

2.1.2 Beziehungen zwischen Phase I und der eigentlichen EDV-Systemplanung (Phase II)

19

2.1.3 Die eingeschränkte Problemstellung

21

2.1.4 Investitionstheoretische Gesichtspunkte

24

2.1.5 Alternative Formulierungen von Investitionsproblemen im Zusammenhang mit der EDV-Planung

27

2.1.6 Ziele und Beurteilungskriterien bei der EDV-Planung

32

Entwicklung der Entscheidungsalternativen

45

2.2.1 Alternativen bei der Auswahl der Informationsprojekte (Zusammenstellung eines „Anwendungskataloges")

46

2.2.2 Technische Alternativen

48

2.2.2.1

Hardware

50

2.2.2.2

Software

55

2.2.2.3

Datenverarbeitung außer Haus (DVaH). Kooperative Nutzung einer bereits existierenden Anlage. Gemischte Lösungen

64

2.2.2.4

Anzahl der technischen Alternativen

69

2.2.3 Organisatorische und Programmierungsalternativen

72

2.2.4 Sonstige Alternativen

80

3. Lösungsansatz mit Hilfe eines OR-Modells (Ganzzahliges lineares Programm)

...

84

3.1

Die Struktur der Zielfunktion

85

3.2

Restriktionen

93

3.2.1 Kapazitätsrestriktionen und Systemgenerierung 3.2.1.1

Generierende Restriktionen und Systemelemente

3.2.1.2

Zeitrestriktionen

3.2.1.3

Speicherrestriktionen

94 94 99 101

3.2.2 Anwendungsrestriktionen

104

3.2.3 Kopplungsrestriktionen

105

Inhaltsverzeichnis

8

4. Modelldaten 4.1

4.2

107

Abschätzung der technischen Koeffizienten (Belastungen)

107

4.1.1 Schätzmethoden bei sequentieller Verarbeitungsweise

107

4.1.2 Schätzmethoden bei Stapelverarbeitung im MultiprogrammingModus

116

4.1.3 Schätzmethoden bei Datenfernverarbeitung nach dem Stapelprinzip (Remote-Batch-Verarbeitung)

118

4.1.4 Schätzmethoden bei Systemen mit Echtzeitverarbeitung und Time-Sharing-Systemen

118

Bestimmung der Aufwands-und Ertragskoeffizienten

121

4.2.1 Aufwandskoeffizienten

121

4.2.2 Ertragskoeffizienten

124

5. Der praktische Einsatz des Modells. Berücksichtigung der Unsicherheit. Kombination mit Simulationsmodellen

127

Anhang: Zahlenbeispiel

134

Literaturverzeichnis

148

1. Einleitung. Methodologie der Unternehmensforschung Der Begriff „Information" hat in den letzten Jahren sowohl in der Wirtschaftspraxis wie auch in der wirtschaftswissenschaftlichen Forschung eine zentrale Bedeutung erlangt. Der stürmische Aufschwung der elektronischen Datenverarbeitung ist nur ein — wenn auch besonders ins Auge springender — Teil dieser weitreichenden Entwicklungen 1 . Information darf jedoch nie zum Selbstzweck werden. Ihre Bedeutung ist vielmehr daran zu messen, in welchem Grade sie zur Erfüllung der Gesamtaufgabe des Betriebes beiträgt. Mehr und mehr rückt die Tatsache ins Bewußtsein, daß auch Informationen ihren Preis haben und daß die Kosten ihrer Erzeugung bzw. Beschaffung sorgfältig gegenüber dem Nutzen abzuwägen sind, den die Unternehmensleitung von ihnen erwarten kann. Investitionen im Bereich des Informationswesens sollten demnach grundsätzlich denselben Maßstäben und Beurteilungskriterien unterliegen, die in anderen Bereichen, insbesondere im Produktionssektor, längst selbstverständlich sind. Derartige Feststellungen mögen trivial, ja fast überflüssig, erscheinen. Der Blick in die Praxis zeigt jedoch, daß der „Informationsplanung" in vielen Unternehmen noch eine gewisse Sonderstellung eingeräumt wird. Während in anderen Bereichen Modernisierungsverfahren von der Unternehmensleitung anhand quantitativer Kriterien sorgfältigst geprüft werden, findet man sich mit den nicht selten Millionenbeträge erfordernden Investitionen im EDV-Bereich oft nur allzu leicht ab 2 . Die diesbezüglichen Wirtschaftlichkeitsüberlegungen müssen in zahlreichen Fällen als mehr oder minder unbefriedigend bezeichnet werden 3 . Sie können zudem nicht darüber hinwegtäuschen, daß die Höhe des zur Verfugung stehenden „Informationsbudgets" - und damit Art und Umfang des künftigen EDV-Systems — kaum das Ergebnis wissenschaftlich fundierter Planung ist. Stattdessen sind es 1

Vgl. z.B. [146, S. 48 und S. 60 ff; 145, S. 24]. Im Unterschied zu dort soll in der vorliegenden Arbeit der Begriff „Informationssystem" mehr im Sinne des terminus technicus „Management-Informationssystem" Verwendung finden.

2

Die durchschnittliche Jahresmiete bzw. Abschreibung pro Anlage lag 1970 in der BRD bei etwa 300 000 DM. Die Gesamtkosten der Datenverarbeitung betragen jedoch das Doppelte bis Dreifache dieser Summe [254, S. 43]. Zu diesen „reinen EDV-Kosten" kommen in wachsendem Maße erhebliche Entwicklungskosten für Projekte, z.B. partielle oder gar „totale" Informationssysteme.

3

Eine ausfuhrliche Darstellung der hierbei auftretenden Schwierigkeiten findet sich in [163],

10

1. Einleitung. Methodologie der Unternehmensforschung

zum großen Teil irrationale Faktoren, die hierfür bestimmend sind: Aufgeschlossenheit oder Skepsis gegenüber neuen Techniken, Prestige-Gesichtspunkte und generelle Investitionsneigung des Betriebes bzw. der Branche 4 . Die Gefahr einer Vernachlässigung des Investitionsstandpunkts bei der Planung von EDV-Systemen und -Anwendungen scheint mit dem Trend zu immer größeren und komplexeren Unternehmen und zu aktuelleren und vollständigeren Informationen eher zu- statt abzunehmen. Für gravierende Fehlinvestitionen gerade bei Großunternehmen lassen sich zahlreiche Beispiele anführen [106; 66]. Selbst ex post-Berechnungen der Rentabilität von EDV-Investitionen werden in der Praxis selten versucht. Ergebnisse hierüber hegen vor allem von Beratungsfirmen vor [19, S. 15; 109; 231; 232]. Die berichteten Erfahrungen lassen sich dahingehend zusammenfassen, daß ca. 50 - 70 % der untersuchten EDV-Systeme bisher noch keine befriedigende Rendite erbracht haben. Aber auch bei denjenigen Systemen, die bereits wirtschaftlich arbeiten, kann von einer vollen Ausschöpfung des theoretisch vorhandenen Potentials nicht die Rede sein. Die imponierende Leistung einzelner Komponenten, insbesondere der Zentraleinheiten, steht trotz neuester Entwicklungen wie Multiprogrammierung und Time-Sharing in keinem angemessenen Verhältnis zum effektiven Durchsatz ("throughput") der Gesamtsysteme. Aufgrund menschlicher Unzulänglichkeit beim Einsatz von Computersystemen entstehen Uberkapazitäten, Totzeiten und „Reibungsverluste", die nach Schätzung von Experten mit 70 — 90 % der technischen „Brutto-Leistung" anzusetzen sind [254, S. 43], So problematisch derartige Zahlenangaben auch sein mögen — sie sollten doch einen starken Anreiz zu einer Verbesserung der heute bei der Planung von EDV-Systemen angewandten Methoden bilden. Die wissenschaftliche Aktivität auf diesen Gebieten ist jedoch nach wie vor relativ gering. Sowohl in der EDV-Forschung der Hersteller wie auch in der Hochschulforschung dominiert die Weiterentwicklung der „Technologie" 5 - ungeachtet der Tatsache, daß „das Werkzeug heute bereits besser ist als der Nutzen, den wir daraus ziehen" [254, S. 47]. Nur ein verhältnismäßig kleiner Teil aus der Flut neuer EDV-Publikationen ist ökonomischen Fragen gewidmet bzw. versucht, die wissenschaftliche Methodik zur optimalen Lösung der anstehenden betriebswirtschaftlichen Probleme anzuwenden [20; 136; 206; 270; 303; 346], Einer der Hauptgründe für diesen allge-

4

Zur Praxis der Festlegung einer Budgetgrenze durch „Faustformeln" vgl. [78, S. 16; 232, S. 43].

5

Der Begriff soll in diesem Zusammenhang auch die „Software" einschließen, also Betriebssysteme, Compiler, etc.

1. Einleitung. Methodologie der Unternehmensforschung

11

mein bedauerten Mangel ist sicher in der für die Datenverarbeitung charakteristischen besonders engen Verzahnung zwischen ökonomischen und technischen Aspekten zu suchen [270, S. 5], EDV-Forschung ist demnach typisch interdisziplinäre Forschung. Eine genaue Kenntnis der Prinzipien von „Hardware" (= Maschinen oder Geräte) und „Software" (= Programme, insbesondere Dienstprogramme, Übersetzer und Betriebssysteme) ist unabdingbar, wenn es darum geht, die Anwendbarkeit betriebswirtschaftlicher Theorien und Methoden auf die Planung elektronischer Datenverarbeitungssysteme zu untersuchen. Hier besteht ein deutlicher Unterschied zu anderen Entscheidungsproblemen, etwa im Produktionsbereich. Die Leistungsfähigkeit eines technischen Aggregates zur Herstellung bestimmter materieller Erzeugnisse läßt sich praktisch immer durch wenige klar definierte Kennzahlen ausdrücken. Die „Leistung" eines bestimmten EDV-Systems dagegen läßt sich streng genommen überhaupt nicht generell definieren, sondern ist immer auf den speziellen Anwendungsfall zu beziehen! Ihre Abschätzung oder Messung erfordert neben umfangreichem technischen Wissen auch eine recht genaue Kenntnis der zu bewältigenden Arbeiten und Abläufe. Eine weitere Schwierigkeit, welche gegenüber dem Produktionsbereich ins Auge fällt, ist die zentrale Stellung der EDV im Betriebsgeschehen — vergleichbar dem Nervensystem (sowie gewissen Gehirnfunktionen, z.B. dem Gedächtnis) bei Tier und Mensch [18 ]. Ein modernes, gut konzipiertes („integriertes") Datenverarbeitungssystem erfaßt sämtliche Unternehmensbereiche und -ebenen. Die Anwendungen reichen von der Bewältigung reiner „Massenarbeiten" bis zur Bereitstellung kondensierter Führungsinformationen für die Unternehmensleitung. In Anwendungsprogrammen und Dateien konkretisieren sich in wachsendem Maße betriebsorganisatorische Phänomene wie Informationsflüsse und große Teile der Ablauforganisation, so daß die optimale Gestaltung der Datenverarbeitung und -speicherung heute als essentieller Teil der betrieblichen Planung gesehen werden muß. Grundsatzentscheidungen über Art und Umfang der von der EDV-Anlage zu bewältigenden Aufgaben bzw. der zu speichernden Daten haben zudem den Charakter von „Metaentscheidungen". Sie schaffen einen Bezugsrahmen für zahlreiche weitere betriebliche Entscheidungen („Objektentscheidungen") und wirken bestimmend auf deren Effizienz ein [146, S. 48 und S. 125; 346, S. 2]. Diese enge Verbindung zwischen EDV-Planung und Unternehmens- (insbesondere Organisations-)planung schlechthin sowie der ungewöhnlich hohe Stellenwert rein technischer Aspekte kennzeichnen den Rang, aber auch die Schwierigkeit des Problems. Der rapide technologische Fortschritt, vornehmlich auf der Hardware-Seite, bringt dem EDV-Benutzer zwar unbestreitbare Vorteile wie verbesserte PreisLeistungs-Verhältnisse, doch hat es nicht selten den Anschein, als ob die mit die-

12

1. Einleitung. Methodologie der Unternehmensforschung

sem raschen Wandlungsprozeß verbundenen Nachteile, wie Veralten bewährter Systeme bzw. Programme, Veralten von Kenntnissen und Erfahrungen, der ständige Zwang, sich über eine Fülle neuartiger Produkte zu informieren, schließlich - bei relativ kurzen Konsolidierungspausen - der hohe Aufwand für Konzeption, Planung und Implementierung der neuen Systeme letzten Endes überwiegen würden 6 . Es ist hier nicht der Ort, auf die Gründe für diese nach Meinung zahlreicher Fachleute überhöhte Marktdynamik einzugehen7. Sicher erscheint jedenfalls, daß von einer vollen Ausschöpfung des vorhandenen technologischen Potentials zu keinem Zeitpunkt die Rede sein konnte. Wenn unsere Behauptung zutrifft, daß eine Verbesserung des „Wirkungsgrades" datenverarbeitender Systeme eher durch erhöhte Anstrengungen bei der Systemplanung — unterstützt durch Forschungsarbeit auf allen mit dem wirtschaftlichen Einsatz von Computern zusammenhängenden Gebieten — als durch die Verwendung der jeweils „modernsten" Produkte des EDV-Markts erzielbar ist, so wäre es doch wenig realistisch, von den EDV-Herstellern einen freiwilligen Verzicht auf die Wahrnehmung von Marktchancen zu erwarten. Es ist vielmehr Sache der Anwender selbst, ihre mehr oder minder passive Rolle zu verlassen und stattdessen der EDV-Industrie als gleichwertige und kompetente Partner gegenüberzutreten. Eine solche stärkere Position würde sich nicht nur positiv auf die Wirtschaftlichkeit individueller Systemplanungen auswirken, sie wäre darüber hinaus geeignet, die gesamten Entwicklungen auf dem EDV-Markt mehr im Kundensinne mitzubestimmen und zu steuern [71; 241]. Die starke Verstrikkung der meisten kommerziellen Rechenzentren in der Problematik, ihre Systeme überhaupt zu reibungslosem Funktionieren zu bringen sowie die leider noch vorherrschende Unterschätzung des EDV-Potentials durch das Top-Management [254, S. 47] lassen ein solches Engagement, insbesondere eigene EDV-Forschung in nennenswertem Umfang, jedoch fast als utopisch erscheinen. Der Großteil der Anwender hat nach wie vor darauf zu vertrauen, daß das von den Systemingenieuren des Anbieters konzipierte System für die betrieblichen Belange nicht nur eine „zulässige Lösung" darstellt, sondern darüber hinaus auch wirklich dem wirtschaftlichen Optimum nahekommt. Wenn auch in jüngster Zeit eine stärkere Aktivität herstellerunabhängiger Beratungsfirmen auf den Gebieten der Konzeption und Planung von Datenverarbeitungssystemen zu beobachten ist, so erscheint doch auch die Hochschulforschung 6

Vgl. [35] sowie das Januarheft (1969) der Zeitschrift Datamation, das ganz unter das Leitmotiv "Obsolescence" gestellt ist.

7

Das Ausbleiben einer von vielen erwarteten vierten Computergeneration ist möglicherweise als erstes Anzeichen für eine Verlangsamung und damit Normalisierung dieser Entwicklung zu werten. Vgl. hierzu auch [233],

1. Einleitung. Methodologie der Unternehmensforschung

13

— insbesondere die Betriebswirtschaftslehre — aufgerufen, sich als vierter Partner an dem für unsere Zukunft so entscheidenden Dialog über Rolle und Einsatz von Computern in der Industrie stärker als bisher zu beteiligen [314]. Hierbei könnten sich auch für die Forschung selbst wieder starke und fruchtbare Impulse ergeben — handelt es sich doch um Fragestellungen, die eine ganze Reihe von Disziplinen, u.a. Investitionstheorie, Entscheidungstheorie, Organisationslehre und Informatik herausfordern und zur Zusammenarbeit zwingen. Nicht zuletzt ist es die Unternehmensforschung [147; 201], die hier eine Schlüsselstellung einnehmen könnte, da sie in der Lage ist, mit Hilfe von Entscheidungsmodellen eine Vielzahl von Alternativen zu erfassen, technische und ökonomische Einschränkungen exakt zu berücksichtigen und eine Optimierung auch bei sehr komplexen Zusammenhängen durchzuführen. Aus diesem Grunde sei an den Schluß dieses Abschnitts eine kurze Zusammenfassung der Grundgedanken dieses neuen Zweiges der Betriebswirtschaftslehre gestellt. Hanssmann [133, S. 5—12] führt folgende neun Punkte als kennzeichnend für das Vorgehen des Unternehmensforschers auf: 1. 2. 3. 4. 5.

6. 7. 8. 9.

Allgemeine Orientierung über das „Entscheidungsfeld" Wahl von Entscheidungskriterien Definition von Umweltparametern Entwicklung von Entscheidungsalternativen Modellkonstruktion = Aufstellung eines mathematischen oder logischen Zusammenhangs zwischen den gewählten Kriterien einerseits und Entscheidungsalternativen bzw. Umweltparametern andererseits Schätzung bzw. Vorhersage der Umweltparameter Auswahl besonders interessierender Alternativen Unterbreitung von Vorschlägen an die Unternehmensleitung Implementierung und, gegebenenfalls, spätere Modifikation der von der Unternehmensleitung getroffenen Entscheidung aufgrund neuer Untersuchungen.

Mit diesen Punkten ist bereits im großen und ganzen der Gang der vorliegenden Studie skizziert. Besonders hervorzuheben sind 4. und 5.: Es erscheint als eine besondere Stärke der OR-Methode8, daß a) eine weitgehend vollständige Erfassung aller überhaupt in Betracht kommenden und sinnvollen Alternativen angestrebt und b) mit Hilfe von Modelltechnik und mathematischer Analyse eine vollständige Durchrechnung dieser Alternativen ermöglicht wird. Mit Hilfe geeigneter Algorithmen (oder sog. „heuristischer" Verfahren) gelingt es in vielen Fällen, aus der oft unübersehbaren Vielzahl zulässiger Lösungen diejenigen auszuwählen, die einen maximalen Zielerreichungsgrad gewährleisten. 8

O. R. = Operations Research (internationale Bezeichnung für Unternehmensforschung).

14

1. Einleitung. Methodologie der Unternehmensforschung

Besonders betont werden muß in diesem Zusammenhang, daß die Unternehmensforschung nicht den Anspruch erhebt, den betrieblichen Entscheidungsprozeß völlig zu mathematisieren bzw. zu automatisieren 9 . ' T h e Output of 0 . R. is not decisions but information" [133, S. 13]. Da ein Modell, auch wenn es noch so umfangreich ist, immer nur eine approximative Abbildung der Realität darstellt, bleibt es Aufgabe des Entscheidungsträgers, die im Modell erfaßten quantitativen Gesichtspunkte durch die Hinzuziehung nichtquantiflzierbarer Aspekte („Imponderabilien") zu ergänzen. Es steht jedoch außer Zweifel, daß die mathematische Optimierung eines quantitativen Kriteriums (sofern dieses nur „richtig" gewählt wurde) zumindest eine wertvolle Grundlage für den Prozeß der Entscheidungsfindung bei komplexen Sachverhalten bietet. Die Existenz imponderabler Faktoren darf - ebensowenig wie das praktisch immer gegebene Moment der Unsicherheit — nicht als Argument gegen die quantitative Methodik angeführt werden. Es ist das Ziel der vorliegenden Studie, die Anwendbarkeit dieser Gedanken auf das Problem der simultanen Optimierung von EDV-Systemen und , »Anwendungskatalog" zu diskutieren. Ein fiktives Beispiel, dessen Umfang aber durchaus realistische Dimensionen hat, soll abschließend die angestellten Überlegungen noch einmal zusammenfassen und zahlenmäßig verdeutlichen.

9

Bezüglich der Möglichkeiten und Grenzen der Unternehmensforschung, insbesondere „geschlossener analytischer Entscheidungsmodelle", sei auch verwiesen auf [147].

2. Das EDV-Planungsproblem 2.1 Allgemeine Darstellung des Entscheidungsproblems. Abgrenzung der Thematik Einige wesentliche Aspekte der innerbetrieblichen Informationsplanung wurden bereits in der Einleitung erwähnt: -

Starkes Ineinandergreifen von technischen und ökonomischen Gesichtspunkten Hochgradige Komplexität Auswirkung auf sämtliche Unternehmensbereiche und -ebenen Hohe Kosten Zahlreiche Alternativen

Es erscheint jedoch am Platze, auf die Fragestellung selbst näher einzugehen und sie vor allem präziser zu definieren. Mit den sich durch die elektronische Datenverarbeitung eröffnenden technischen Möglichkeiten hat sich heute praktisch jeder Betrieb (ebenso wie zahlreiche andere private und öffentliche Institutionen) in irgendeiner Form zu befassen. Ein Kleinbetrieb befindet sich dabei in einer völlig anderen Situation als ein Großunternehmen. Dasselbe gilt für den Vergleich zwischen Unternehmen,die erstmals mit Fragen der EDV konfrontiert werden mit solchen, die bereits über ausgiebige eigene Erfahrungen auf diesem Gebiet verfügen und die eine vorhandene Anlage nur erweitern oder modernisieren möchten. Obwohl die im folgenden dargelegten Gedankengänge weitgehend allgemeingültigen Charakter haben dürften, sei doch betont, daß als typischer Anwendungsfall ein mindestens mittelgroßes Unternehmen ins Auge gefaßt wird. In welchem Umfang die betriebliche Datenverarbeitung bereits automatisiert ist, erscheint in diesem Zusammenhang weniger wichtig. Auch bei Ausbauüberlegungen sollte das System noch einmal von Grund auf neu durchdacht werden [96,insbes. S. 15 und S. 18]! Unbeschadet möglicher Kosteneinsparungen im Falle der Weiterverwendung vorhandener Maschinen oder Programme wird durch eine umfassende Neuplanung vermieden, daß die in der „Lernphase" unvermeidlich begangenen Fehler in alle Zukunft „weitergeschleppt" werden. Im Idealfall sollte die EDV-Planung einhergehen mit einer kritischen Überprüfung der gesamten Aufbau- und Ablauforganisation. Das Ergebnis dieser Phase hat beträchtlichen Einfluß auf die spätere Entscheidung zugunsten eines bestimmten Computersystems1. Sie reicht aber in ihrer Bedeutung weit über diesen Rahmen hinaus und ist deshalb als eigenständiger Fragenkomplex zu behandeln. 1

Speziell wird die Problematik „zentrale oder dezentralisierte EDV" stark davon berührt.

16

2. Das EDV-Planungsproblem

Erwähnt sei hier nur, daß — soweit dem Verfasser bekannt — nur wenige Ansätze zu einer quantitativen Organisationsanalyse existieren[290; 224; 273; 134; 128].

2.1.1 Abgrenzung gegenüber Organisationsstudie und Anwendungsanalyse (Phase I) Obwohl zwischen den Problemkreisen Organisations- bzw. Anwendungsanalyse einerseits (im folgenden: Phase I) und EDV-Systemplanung andererseits (Phase II) starke Wechselwirkungen bestehen, ist doch aus praktischen Gründen der Versuch einer Abgrenzung erforderlich. Inhalt der vorliegenden Arbeit ist primär die Phase II, in der für Basisanwendungen (Automatisierung von Abrechnungs- und Verwaltungsvorgängen) wie für in Aussicht genommene „Informationsprojekte" zunächst technische Realisierungsmöglichkeiten konzipiert werden. Darauf aufbauend, soll Phase II schließlich zu Entscheidungsunterlagen bezüglich Konfiguration, Betriebssystem und, Anwendungspaket" führen. Der Verfasser geht dabei von der Annahme aus, daß aufgrund der Ergebnisse von Phase I 2 weitgehende Klarheit über folgende Phänomene besteht: -

Richtung und Intensität innerbetrieblicher Informationsströme anzustrebende Informationstransformationen (Sollabläufe, programmierbare RoutineEntscheidungen", Bildung kondensierter Führungszahlen) informatorische Wechselbeziehung mit der Umwelt betriebliche Basisdaten (Schlüsselsysteme, Gliederung in Dateien)

Es ist jedoch nicht erforderlich, daß die in Phase I durchgeführte Organisationsstudie schon in einen definitiven Rahmenplan für die spätere elektronische Datenverarbeitung mündet — auch wenn in der Praxis eine solche Zielvorstellung heute noch der Regelfall zu sein scheint. Die Organisationsstudie soll vielmehr allein dem Zweck dienen, eine klare Ausgangsbasis für die Aufstellung der „technologischen Alternativen", die für die Erfüllung der Informationsbedürfnisse des Betriebes in Frage kommen, zu schaffen. Eine verfrühte Fixierung von Hardware, Software oder Anwendungsprogrammen sollte in diesem Planungsstadium unbedingt vermieden werden (vgl. die späteren Ausführungen über Management-Informations-Systeme). Parallel zu dieser Suche nach „interessanten" Organisationsstrukturen und „vernünftigen" Verarbeitungsabläufen (öaswdaten bzw. -anwendungen) sollte versucht werden, Einsatzmöglichkeiten höherer Art zu erschließen.

2

Bezüglich der von uns als „Phase I" bezeichneten Tätigkeiten sei verwiesen z.B. auf [238; 74; 25].

.2.1. Allgemeine Darstellung des Entscheidungsproblems. Abgrenzung der Thematik

17

Hierbei handelt es sich einerseits um Anwendungen, an die bisher allein wegen der benötigten Datenmengen nicht zu denken war, und andererseits um die Möglichkeit, gewisse (Routine-) Entscheidungen durch den Einbau entsprechender Entscheidungsmodelle im System selbst zu treffen. Derartige Modelle sind auf allen Ebenen der Unternehmenshierarchie einsetzbar. In dem ihnen gesetzten Rahmen sind sie einem menschlichen Entscheidungsträger sowohl an Schnelligkeit der Reaktion als auch an Qualität der Entscheidung überlegen (Beispiel: Verschnittminimierung). Das Management der entsprechenden Unternehmungsstufe wird dadurch entlastet und für schwierigere, noch nicht programmierbare Entscheidungen freigesetzt ("management by exception") 3 . Ein wirklich produktiver Einsatz des Computers ist erwiesenermaßen erst bei Einbeziehung derartiger höherrangiger Anwendungen erzielbar. Als typische Möglichkeiten seien genannt: Umsatzstatistik und Absatzplanung Fertigungssteuerung Lagerdisposition Transportoptimierung Einkaufsdisposition Finanzplanung Investitionsrechnungen Projektplanung und -Überwachung Dokumentation Während bei Basisanwendungen, z.B. bei der Lohnabrechnung, die prinzipielle Notwendigkeit der entsprechenden Vorgänge außer Frage steht, geht es bei den Anwendungen höherer Art sowohl um die Entscheidung darüber, ob das entsprechende Projekt überhaupt durchgeführt werden soll, als auch darüber, wie seine Durchführung im einzelnen auszugestalten ist. Eine namhafte Unternehmensberatungsgesellschaft betont aufs Nachdrücklichste, daß erst bei Berücksichtigung dieser „fortgeschrittenen" Einsatzmöglichkeiten das Potential der EDV voll ausgeschöpft werden kann [ 106; 231; 232; 267]. Dieselben Untersuchungen zeigen aber auch deutlich die enormen Schwierigkeiten, die mit der jeweils „richtigen" Auswahl aus der vorliegenden „Projektliste" verbunden sind. Offensichtlich handelt es sich dabei um ein Investitionsproblem, das mit traditionellen Mitteln kaum lösbar sein dürfte (vgl. 2.1.4 und 2.1.5). Der besondere Charakter dieses Investitionsproblems soll später noch näher beleuchtet werden. An dieser Stelle geht es nur darum, zu betonen, wie essentiell 3

Zum Unterschied zwischen programmierten bzw. programmierbaren und nicht programmierbaren Entscheidungen vgl. [119; 307, S. 5 ff; 64, S. 29 ff.]. Bei vollkommener Programmierbarkeit sollte besser von „automatisierbaren Wahlakten" gesprochen werden. Für eine echte Entscheidung ist „begriffsnotwendig, daß es zur Bewältigung des Problems von vornherein keine eindeutige Lösung gibt" [340],

18

2. Das EDV-Planungsproblem

eine systematische Anwendungsanalyse als Grundlage für die optimale Auslegung des betrieblichen Informationssystems ist. An ihr sind unbedingt die entsprechenden Fachabteilungen zu beteiligen. Letzten Endes hängt es jedoch immer von der Aufgeschlossenheit des Top-Managements ab, ob sie so sorgfältig durchgeführt wird, daß damit eine zuverlässige Basis für die Anwendung von Entscheidungsmodellen zur Systemplanung geschaffen ist [231, S. 45 ff]. Es erscheint hier angebracht, einige spezielle Ausführungen dem viel zitierten und viel mißbrauchten Schlagwort Management-Informations-System4 zu widmen, da in der Praxis nicht selten ehrgeizige aber vage Vorstellungen von einem solchen System zu gefährlichen Präjudizierungen bezüglich der späteren Hardund Software führen [2]. Die Konzeption derartiger Systeme rückt heute mehr und mehr in den Vordergrund, da selbst Unternehmen mittlerer Größe die Phase der Automatisierung von Abrechnungs-, Buchungs- und Verwaltungsvorgängen weitgehend als abgeschlossen betrachten [106, insbes. S. 20]. Eine verbindliche Definition des Begriffs MIS existiert noch nicht. Nach Ansicht des Verfassers impliziert jedes umfassende und gut geplante EDV-System automatisch auch ein MIS. Akzeptiert man diese Auffassung, so wäre das MIS nicht als eine weitere „höchstrangige" Computeranwendung zu betrachten, sondern vielmehr als Synonym für ein Datenverarbeitungssystem, bei dem einerseits schon die Basisanwendungen (und Basisdateien) im Hinblick auf die Informationsbedürfnisse des Managements (aller Ebenen!) konzipiert sind, das aber andererseits auch Elemente enthält, die ausschließlich die Aufgabe haben, qualitativ hochwertige, weil weitgehend rational fundierte, Entscheidungen zu ermöglichen. Die folgenden fünf Punkte erscheinen notwendig und hinreichend, um den Begriff MIS zu präzisieren: 1. Informationszusammenführung und -speicherung (Dokumentationsfunktion, Datenbank) 2. Information ohne spezielle Anforderung (periodische Berichte, Warnungen bzw. Hinweise bei Auftreten bestimmter Bedingungen) 3. Information auf Anfrage ("information retrieval") innerhalb vorgegebener Antwortzeiten 4. Selektionsfunktion nach Stellung des jeweiligen Informationsempfängers in der Hierarchie 5. Informationsverarbeitung (programmierte Entscheidungen, Modelle) 4

Im folgenden: MIS.

2.1 Allgemeine Darstellung des Entscheidungsproblems. Abgrenzung der Thematik

19

Hieraus ergibt sich zwangsläufig, daß das „Projekt MIS" keinesfalls bis zum Abschluß anderer, scheinbar vordringlicherer, Umstellungsvorhaben aufgeschoben werden darf. Die Diskussion und Konzeption der Grundlagen des späteren Informationssystems sollte vielmehr unbedingt an den Anfang des Planungsprozesses gestellt werden. Sie gehört in die Phase der Organisationsstudie bzw. Anwendungsanalyse, somit also noch nicht zum eigentlichen Bereich dieser Arbeit.

2.1.2 Beziehungen zwischen Phase I und der eigentlichen EDV-Systemplanung (Phase II) Die gegebene programmatische Darstellung und Gliederung des bei der EDV-Planung ablaufenden Entscheidungsprozesses5 erscheint vor allem in begrifflicher und methodischer Hinsicht wertvoll. Eine streng sequentielle Durchführung von Phase I: und Phase II:

Organisationsstudie bzw. Anwendungsanalyse Optimale Projekt- und Konfigurationsauswahl (einschließlich Software-Optimierung) mit Hilfe eines analytischen Entscheidungsmodells

wird sich in der Praxis allerdings kaum durchführen lassen. Der reale Entscheidungsprozeß erstreckt sich nicht selten über mehrere Jahre 6 ! In einem derart langen Zeitraum ändern sich nicht nur die externen (z.B. konjunkturelle Lage) und internen Voraussetzungen, es werden auch von allen an der Umstellung Beteiligten, insbesondere Planungsteam und Management, Lernprozesse durchlaufen, die eine ständige Überprüfung der Prämissen erfordern [164]. Der zeitlichen Dimension des Planungsprozesses muß demnach durch eine ausreichende Flexibilität der verwendeten Methode Rechnung getragen werden (vgl. Kap. 5). Die OR-Methode, die auf der mathematischen Optimierung von Entscheidungsmodellen basiert, wird den gebräuchlichen, überwiegend intuitiv orientierten Planungsverfahren nur dann wirklich überlegen sein, wenn sie diese Forderung berücksichtigt! Daneben ist die strikte begriffliche Trennung zwischen den genannten Phasen von äußerster Wichtigkeit. Insbesondere steht und fällt die Anwendung eines Entscheidungsmodells zur Systemplanung mit einer gründlichen Durchführung von Phase I. 5

In diesem Zusammenhang sei auf die umfangreiche empirische Untersuchung des EDVPlanungs- und Entscheidungsprozesses durch Witte hingewiesen: [337; 338; 339].

6

Die hier vorgeschlagene Methodik könnte u.a. dazu beitragen, diesen Prozeß abzukürzen. Allein dies würde einen nicht geringen Gewinn bedeuten. Zu den Kosten des betrachteten Entscheidungsprozesses vgl. auch [339, S. 493],

20

2. Das EDV-Planungsproblem

Die im folgenden gegebene Definition der Aufgabenstellung ist demnach nicht nur unter dem Aspekt einer Aufzählung von Gegebenheiten zu sehen, die praktisch immer — mehr oder weniger klar erkannt - vorliegen, sondern auch unter dem weiteren Aspekt einer Forderung, diese Tatbestände in Phase I zu präzisieren und dabei insbesondere die Vielfalt sinnvoller Anwendungen, Ablaufkonzeptionen und Datenorganisationen soweit wie möglich auszuloten. Vielleicht wird der Praktiker die geforderte informatorische Ausgangsbasis angesichts der bei jedem größeren Umstellungsvorhaben zu überwindenden Schwierigkeiten als unrealisierbar und „akademisch" abtun. Eine theoretische wissenschaftliche Untersuchung ist naturgemäß nicht in der Lage, hierzu den Gegenbeweis anzutreten. Sie kann nur auf die Mängel bestehender Verfahren hinweisen und mögliche Wege zu ihrer Lösung aufzeigen. Da gelegentlich, insbesondere von Herstellerseite, die Meinung vertreten wird, existierende Verfahren seien vollkommen ausreichend und gewährleisteten eine „optimale" Systemplanung, erscheinen noch einige kritische Bemerkungen zu diesem Punkt angebracht. Die Verwendung wissenschaftlichen „Handwerkzeugs", wie Simulation, Warteschlangentheorie und Bewertungsverfahren kann nicht darüber hinwegtäuschen, daß das Gebiet der System- (und Anwendungs-)planung immer noch weitgehend von Erfahrung und Intuition geprägt wird. Wenn auch dieser Weg — bei entsprechender Qualifikation des mit der Aufgabe betrauten Teams — zu durchaus akzeptablen Lösungen führen kann, so erscheint doch das Erreichen der nach wirtschaftlichen Grundsätzen optimalen Lösung um so unwahrscheinlicher, je komplexer die Aufgabenstellung und je umfangreicher das Angebot an Hard- und Software werden. Der Systemingenieur ist praktisch gezwungen, aus der Fülle der Möglichkeiten intuitiv eine Auswahl zu treffen, wobei selbstverständlich gute Lösungen „verlorengehen" können. Sein Problemlösungsverhalten ist nicht immer nachvollziehbar und selbst von der Seite der Praktiker wird eingeräumt, daß nur in Ausnahmefällen zwei Analytiker bei gleicher Problemstellung auch zu identischen Lösungskonzeptionen gelangen würden. Ein amerikanischer Fachmann charakterisierte diese Situation treffend: "Systems design is an art, not a science". Wir sind der Meinung, daß vor allem durch erhöhte Anstrengungen bei der Problemdefinition, wie sie im folgenden vorausgesetzt werden, eine Verwissenschaftlichung und damit Verbesserung der Methoden des Systementwurfs möglich ist.

2.1 Allgemeine Darstellung des Entscheidungsproblems. Abgrenzung der Thematik

21

2.1.3 Die eingeschränkte Problemstellung Grundlage für die im folgenden vertretene Konzeption der Systemplanung ist eine Liste von „Arbeiten" oder „Anwendungen" (applications) i=l,. . . , n. Ein gewisser Teil davon ist in jedem Fall durchzuführen (etwa Anwendungen aus dem Bereich des Rechnungswesens). Es sind jedoch geringfügige Modifikationen in den Abläufen möglich, so daß auch bei dieser Gruppe (Basisanwendungen) im allgemeinen mehr als eine Lösungsmöglichkeit zur Diskussion steht. Bei den übrigen Anwendungen handelt es sich um neue Projekte, über deren Durchführung nach investitionstheoretischen Gesichtspunkten entschieden werden muß. Jede Anwendung ist in Phase I analysiert worden. Das Resultat dieser Analyse ist eine klare und vollständige Anwendungsbeschreibung. Wesentlich ist dabei, daß diese Charakterisierung, sei sie verbal formuliert oder in exakterer Form (z.B. als Netzwerk) vorliegend, nur Elemente enthält, die streng problembezogen sind. Jede unbewußte Bezugnahme auf einen bestimmten Konfigurationstyp oder auf bestimmte Programmiertechniken ist in diesem Stadium unbedingt zu vermeiden 7 . Abgesehen von etwaigen Modifikationen beim Problem selbst (beispielsweise Unterschiede bezüglich Quantität oder Qualität des "Outputs") handelt es sich bei dieser Art von Anwendungsbeschreibung um die sämtlichen denkbaren Lösungsmöglichkeiten zugrundeliegende und für die betreffende Aufgabe charakteristische Struktur. Konkret sind folgende Spezifikationen erforderlich: -

Herkunft, Art und Menge der Eingangsinformationen ("Input") Bestimmungsort (Datei oder menschlicher Informationsempfanger), Formate und Umfang des "Outputs" Wechselbeziehungen zwischen den einzelnen Anwendungen Frequenz der Anwendung (täglich, wöchentlich, . . . ) und „Teiminstrenge" Priorität (Basisanwendung oder Projekt) Ertragsschätzung (bei Anwendungen mit Projektcharakter) 8 Abschätzung möglicher Einsparungen (bei Basisanwendungen) 8 Wahrscheinlichkeitsaussagen über den Input und Restriktionen bezüglich Antwortzeit bei Anwendungen mit Echtzeitcharakter

7

Die Forderung ist für den Fall, daß bereits eine EDV-Anlage existiert, etwas zu modifizieren. Vorhandene Programme können u.U. auch bei Systemwechsel weiterbenutzt werden. Eine wichtige Frage lautet hier: Lohnt sich eine Neuprogrammierung oder soll ein vielleicht nicht ganz effizientes, aber dafür fertiges Programm Verwendung finden? Vgl. dazu 2.2.3.

8

Vgl. 4.2.

22

2. Das EDV-Planungsproblem

Es ist nun die Aufgabe des Systemplanungsteams bzw. der Unternehmensleitung a) Umfang und Zusammensetzung der tatsächlichen Arbeitslast zu bestimmen. Dies bedeutet insbesondere, daß eine optimale Auswahl aus der in Phase I aufgestellten Projektliste zu treffen ist b) dasjenige EDV-System zu wählen, welches die in a) festgelegte Aibeitslast (system workload) im Sinne der Entscheidungskriterien des Managements optimal bewältigt. Hierzu gehört auch die Auswahl des Betriebssystems (z.B. Multiprogrammierung). Wenn auch üblicherweise die Entscheidungen über beide Bereiche praktisch trennt voneinander (und zwar sukzessive) getroffen werden, so ist doch zu betonen, daß das echte wirtschaftliche Optimum nur mittels einer Simultanentscheidung gefunden werden kann! Wie sogleich näher auszufuhren ist, gehört zur „Aufwandsseite" der in a) auszuwählenden Projekte nicht zuletzt der technische Aufwand (etwa der Bedarf an Speicherkapazität), den die betreffende Anwendung mit sich bringt. In diesem Sinne wird also die Entscheidimg b) durch die Entscheidung a) induziert. Umgekehrt gilt aber auch, daß durch b) weitgehend festgelegt wird, welches „Anwendungspaket" von der ausgewählten Anlage bewältigt werden kann. Bei dieser Art der Betrachtung liegt demnach ein (verallgemeinertes) "knapsack problem" vor9. Während es durchaus möglich ist, dieser Problematik im Rahmen des vorzuschlagenden Entscheidungsmodells voll Rechnung zu tragen, soll ein anderer, nämlich der dynamische Aspekt bewußt vernachlässigt werden. Die Approximation durch ein statisches Modell geschieht in der Weise, daß die Kapazität der Anlage auf den erwarteten Maximalbedarf abgestellt wird10. Im Gegensatz dazu würde ein dynamisches Modell zu Aussagen über die zeitliche Entwicklung von System und Arbeitslast fuhren. Der Versuch einer Dynamisierung erscheint so lange nicht sinnvoll, als nicht die Brauchbarkeit des statischen Modells für die Praxis erwiesen ist. Hinzu kommt, daß auch der rechnerische Aufwand noch lange Zeit ein gewichtiges Hindernis für die Dynamisierung bilden dürfte. Der Zeitaspekt spielt jedoch noch in anderer Weise eine Rolle: Selbst bei — global gesehen — konstantem Informationsbedarf ist im allgemeinen zu berücksich-

9

10

Die Optimierung der Arbeitslast für eine vorgegebene Konfiguration wird ausführlich behandelt in: [303, S. 32 ff.]. Zum "knapsack-problem" als Standardproblem der Unternehmensforschung vgl. [133, S. 82; 195], „Maximal" bezieht sich hier auf die einzelne Anwendung (Datenanfall nimmt i.a. im Laufe der Zeit zu), nicht auf die Zusammensetzung des Anwendungspakets! Das Modell macht nur Aussagen darüber, ob die Anwendung durchgeführt werden soll. Die Bestimmung von Übernahmezeitpunkten ist nicht vorgesehen.

2.1 Allgemeine Darstellung des Entscheidungsproblems. Abgrenzung der Thematik

23

tigen, daß die anfallenden Einzelarbeiten ("Jobs") zeitlich nicht beliebig verschieblich sind. Aufgrund vorgegebener Termine ergeben sich Spitzen, die allerdings bei modernen Band-/Plattensystemen nicht mehr so ausgeprägt sind wie beim Lochkartenverfahren. Obwohl diesem Punkt im Fall der Durchfuhrung einer konkreten Planungsstudie unbedingt Beachtung geschenkt werden muß, spielt er für eine Untersuchung über Grundsatzfragen nur eine vergleichsweise geringe Rolle, so daß auch darauf im folgenden nicht mehr explizit eingegangen werden soll. Derartige Vereinfachungen und Vernachlässigungen sind um so eher gerechtfertigt, als das gegebene Problem überwiegend strategischen11 Charakter aufweist. Es bedarf kaum einer Erläuterung, daß Entscheidungen über ein EDV-System nur schlecht rückgängig zu machen sind und daß sie schwerwiegende und langfristige Auswirkungen, z.B. auf die Kostenstruktur des Unternehmens mit sich bringen. Die Zuverlässigkeit von Entscheidungsmodellen für mittel- und langfristige Planung wird nicht zuletzt durch die unvermeidliche Ungenauigkeit der zugrundegelegten Prognosen begrenzt. Die Aussagen werden mit zunehmender zeitlicher Distanz naturgemäß immer unsicherer. Man trägt diesem Sachverhalt in der Methodologie der Unternehmensforschung üblicherweise dadurch Rechnung, daß man einen Datenhorizont einführt, der die Prognose begrenzt. Diesem Datenhorizont wird ein Planungshorizont gegenübergestellt, durch den der Zeitraum definiert wird, während dessen merkliche Konsequenzen der zu treffenden Entscheidung erwartet werden [133, S. 30 ff; 65, S. 120 ff]. Speziell bei der EDV-Planung ist nun damit zu rechnen, daß eine Vorhersage der Arbeitslast bis zum Planungshorizont kaum durchführbar ist. Auf diese Schwierigkeit soll in Kap. 5 noch näher eingegangen werden. Glücklicherweise wird dieser Umstand wenigstens dadurch etwas gemildert, daß auch zu späteren Zeitpunkten noch Anpassungsentscheidungen (z.B. Kernspeicherausbau, Ausweichen auf ein externes Rechenzentrum etc.) möglich sind 12 . Ferner ist zu bemerken, daß es sich bei der EDV-Planung selbstredend um ein Entscheidungsproblem unter starker Unsicherheit handelt. Angesichts der Schwierigkeit, das Entscheidungsfeld überhaupt zu strukturieren und auch im Hinblick auf die rechentechnische Kompliziertheit des aus dieser Strukturierung resultierenden Modells wird jedoch verständlich, daß zunächst nur eine quasi-deterministische Behandlung in Frage kommen kann (vgl. Kap. 5). 1 1 Taktische Entscheidungen beziehen sich dagegen auf Details der Programmierung, auf leicht zu verändernde Charakteristika der Konfiguration usw. Sie können im Rahmen des vorgeschlagenen Modells ebenfalls erfaßt werden. 12

Bei Kauf oder Anmietung zusätzlicher Komponenten sind dabei allerdings oft relativ lange Lieferzeiten in Rechnung zu stellen.

24

2. Das EDV-Planungsproblem

Außer der eben besprochenen zeitlichen Dimension weist das vorliegende Entscheidungsproblem in manchen Fällen auch eine räumliche Dimension auf. Fragen wie Zentralisierung oder Dezentralisierung der Datenverarbeitung [264], Wahl der Übertragungswege (network design), Art des Verbunds geographisch getrennter Rechner etc. spielen für viele Anwender eine wichtige Rolle. Es besteht durchaus die Hoffnung, daß das vorgeschlagene Modell auch zur Lösung wenigstens eines Teils dieser Fragen herangezogen werden kann. Dessenungeachtet wird die Behandlung „punktueller" Systeme in dieser Arbeit im Vordergrund stehen. Als letztes soll noch eine Abgrenzung der Themenstellung erfolgen gegenüber psychologischen Aspekten13 sowie gegenüber allen Fragen, die mit der Finanzierung der Anlage und mit der Vertragsgestaltung zusammenhängen. Die hierbei möglichen Alternativen sollen jedoch der Vollständigkeit halber in 2.2.4 kurz aufgezählt werden.

2.1.4 Investitionstheoretische Gesichtspunkte Um die Eigenart von Entscheidungen über die Durchführung von Anwendungsprojekten und die Auswahl des hierfür geeignetsten Systems noch aus einem anderen Blickwinkel darzustellen und gleichzeitig den Charakter des Fragenkomplexes Investitionsproblem deutlich zu machen, sollen speziell hierzu noch einige Ausfuhrungen folgen. Die Darstellung wird weitgehend auf der von Hanssmann verwendeten Terminologie basieren. Hanssmann geht von einem sehr allgemeinen Investitionsbegriff aus: "main characteristic is the present commitment of major resources by a Single decision to uncertain future returns" [133, S. 3]. Wie im folgenden gezeigt werden soll, weist das vorliegende Problem eine Reihe von Wesenszügen auf, für deren Behandlung die bisherigen Ansätze der Investitionstheorie nicht mehr adäquat erscheinen. Bei Zugrundelegung des Hanssmannsehen Konzeptes lassen sich jedoch auch die hier auftretenden komplexen Zusammenhänge befriedigend erfassen. An den Anfang dieser Theorie stellt Hanssmann [133, S. 26 ff] die Grundbausteine Input und Output14. 13

Die entscheidende Bedeutung, die psychologische Gesichtspunkte für den Erfolg eines EDV-Systems (speziell eines MIS) besitzen können, soll hier keineswegs geleugnet werden. Vgl. hierzu [7].

1 4 Die hier verwendete investitionstheoretische Auffassung dieser Begriffe sollte nicht mit der in den übrigen Teilen der Arbeit dominierenden EDV-technischen Interpretation verwechselt werden.

2.1 Allgemeine Darstellung des Entscheidungsproblems. Abgrenzung der Thematik

25

Im Unterschied zu zahlreichen älteren Auffassungen handelt es sich dabei um Sachverhalte, die nicht unbedingt monetärer Natur sein müssen. Es lassen sich vielmehr auch quantifizieibar-wcft^o/ietöre und sogar qualitative Tatbestände diesen Begriffen subsummieren. Von diesen Grundelementen ausgehend definiert Hanssmann die Begriffe Aufwand ("investment") Ertrag ("return") Kriterium für die nunmehr die Meßbarkeit vorausgesetzt wird. Während der Begriff „Kriterium" ein notwendiger Bestandteil für jede Art von Investitionskalkül ist, gibt es eine Reihe von Fällen, in denen eine Quantifizierung entweder der Aufwandsseite oder der Ertragsseite nicht unbedingt erforderlich ist. Es sind dies a) Fälle, in denen der Input fest vorgegeben ist (z.B. aufgrund vorhandener technischer Ressourcen oder vom Management festgelegter Budgetgrenzen). Ziel ist dann die Maximierung des Outputs bzw. Ertrages b) Fälle, in denen der Output fixiert ist. Angestrebt wird die Erbringung dieses Outputs mit minimalem Aufwand (Beispiel: Durchführung eines Entwicklungsprojekts mit minimalen Kosten) Falls Input und Output inkommensurabel sind, ist eine Investitionsrechnung überhaupt nur für die Spezialfälle a) und b) möglich. Im Falle der Kommensurabilität dagegen kann auch die Differenz zwischen Output und Input einer Optimierung zugrundegelegt werden. Von einem höheren Standpunkt aus gesehen ist dies sicherlich die beste, wenn auch oft sehr schwierige, Vorgehensweise. Besonders bedeutsam ist der Vorteil, den die Annahmen a) bzw. b) mit sich bringen, wenn bereits die Elemente Input oder Output in sich heterogen sind, also beispielsweise sowohl monetäre wie auch nichtmonetäre Komponenten enthalten ("multiple investment resources", "multiple returns"). Obwohl in der vorliegenden Arbeit versucht wird, ohne diese Voraussetzungen auszukommen, erscheint es doch nicht überflüssig, auf die Bedeutung hinzuweisen, die ihnen bei einer Anwendung des Verfahrens in der Praxis möglicherweise zukommen könnte. Multiple Ressourcen treten bei der EDV-Planung beispielsweise in folgender Form auf: Es ist denkbar, daß eine bestimmte Computeranwendung nur geringe direkt zurechenbare Aufwendungen finanzieller Art mit sich bringt (z.B. weil der Hersteller das entsprechende Programm kostenlos zur Verfügung stellt), daß sie jedoch

26

2. Das EDV-Planungsproblem

einen ganz erheblichen technischen Aufwand erfordert 15 . Die Beschränkung auf die monetäre Inputkomponente allein würde in diesem Fall ersichtlich zu einer Fehlentscheidung führen! Die Einbeziehung multipler Ressourcen (bzw. multipler Erträge) ist vielleicht einer der wichtigsten Beiträge, die die OR-Methodik der Investitionstheorie zu liefern vermag. Als weitere Komplikation sei das Vorhandensein zahlreicher Interdependenzen sowohl technischer wie ökonomischer Art angeführt. Derartige Interdependenzen werden bei Hanssmann [133, S. 80] folgendermaßen definiert: "A project is technologically dependent on others if its physical feasibility requires that certain other projects be accomplished simultaneously or earlier. The concept of physical feasibility refers to the construction as well as the operation phase of the project... A project is economically dependent on others if the investments and returns associated with it depend on whether or not certain other projects are accomplished simultaneously or earlier . . . More precisely, a set of projects is economically independent if the total investments and returns associated with the set are equal to the sum of the investments and returns of the individual projects if carried out alone . . . "

Ältere Ansätze der Investitionstheorie basieren demgegenüber meist auf der Annahme, daß die Projekte unabhängig voneinander durchgeführt werden können und daß sowohl Aufwendungen wie Erträge individuell für jedes Projekt angegeben werden können. Beispiele für beide Arten der Abhängigkeit finden sich in den weiteren Ausführungen dieses Abschnitts. Zu bemerken ist, daß der Begriff der technologischen bzw. ökonomischen Abhängigkeit nicht identisch ist mit dem Begriff „gemeinsame Ressourcen"! Der Zusammenhang von Projekten über ein gemeinsames Budget ist praktisch immer gegeben und läßt sich auch mit „konventionellen" Mitteln behandeln. Neu ist hier allenfalls die große Zahl zu berücksichtigender Restriktionen (insbes. Kopplung über technische Ressourcen, wie Speicherkapazität u.ä.) sowie die Tatsache, daß das vollständige Optimierungsproblem auch die Ermittlung der Kapazitäten selbst mit einschließen soll. Die technischen Kapazitäten können im Gegensatz zu einem Finanzbudget nicht kontinuierlich verändert werden, sondern nur in diskreten Schritten. Damit hängt es zusammen, daß als Entscheidungsmodell nicht ein „normales" lineares Programm in Frage kommt, sondern vielmehr ein Modell vom ganzzahligen (speziell 0/1 -)Typus. 1 5 Eine Bewertung dieses technischen Aufwands wird hier als nicht durchführbar bzw. irreführend angesehen. (Vgl. S. 123).

2.1 Allgemeine Darstellung des Entscheidungsproblems. Abgrenzung der Thematik

27

Es bedarf angesichts dieser Sachlage kaum noch einer Erläuterung, daß eine Analyse von Zahlungsströmen, wie sie den bekannten Methoden der Investitionsrechnung (Kapitalwertmethode, Methode des internen Zinsfußes, pay-back-Analyse) zugrundeliegt, hier zumindest problematisch ist. Die in dieser Arbeit vorgeschlagene Vorgehensweise ist demgegenüber zwar gröber, dafür aber umfassender. Insbesondere ermöglicht sie eine Auswahl aus einer Vielzahl von Alternativen, während sich die übliche Wirtschaftlichkeitsrechnung aus praktischen Gründen auf die Durchrechnung einer Alternative (oder einiger weniger Alternativen) beschränken muß.

2.1.5 Alternative Formulierungen von Investitionsproblemen im Zusammenhang mit der EDV-Planung Je nachdem, ob sich der Blick primär auf die einzelnen Komponenten, auf das EDV-System, das sich aus diesen Komponenten zusammensetzt, oder auf das System der Anwendungen richtet und je nachdem, ob Einmalkosten periodisiert werden oder nicht, lassen sich aus dem Entscheidungsfeld unterschiedliche Entscheidungsprobleme herauskristallisieren. Die zahlreichen möglichen Interpretationen lassen sich am übersichtlichsten in schematischer Form zusammenfassen (Tab. 1). Dabei wird, um die Diskussion nicht unnötig zu komplizieren, von der Fiktion ausgegangen, daß sowohl Hardwarewie Softwarekomponenten grundsätzlich gekauft werden. Wenn auch in der Praxis die Anmietung von Komponenten oder ganzen Systemen eine erhebliche Rolle spielt — und wenn auch der Abschluß solcher Mietverträge nur noch bedingt unter den Begriff „Investition" fällt, so ist diese Schwierigkeit nach Meinung des Verfassers doch mt\ii formaler Art. So wichtig Fragen der Vertragsgestaltung und Finanzierung im Einzelfall auch sein mögen, für einen grundsätzlichen Strukturierungsversuch sind sie sicherlich von geringerer Bedeutung. Die Annahme erscheint berechtigt, daß die prinzipielle Entscheidung zugunsten einer bestimmten Konfiguration, einer bestimmten Betriebsart oder der Durchfuhrung gewisser Anwendungen davon nicht allzusehr berührt wird. Der Klarheit halber wird also in Tabelle 1 immer davon ausgegangen, daß ein „Input" monetärer Art grundsätzlich im Zeitpunkt „0" anfällt. Eine rein begriffliche Periodisierung der Aufwendungen sei jedoch zugelassen. Wir wenden uns nun den in der Tabelle dargestellten möglichen Betrachtungsweisen des EDV-Investitionsproblems im einzelnen zu. Fall A) repräsentiert eine Auffassung, in der eine einzelne Komponente, z.B. ein

28

2. Das EDV-Planungsproblem

Tab. 1. Klassifikationsschema der im Zusammenhang mit der EDV-Planung auftretenden Investitionsprobleme. Investitionsobjekt A) Komponenten B)

Input ("investment", Aufwand) monetär

Output ("return", Ertrag)

nicht monetär

monetär

nicht monetär

-

-

Kapazität

-

-

Kapazität

Kaufpreis Sonstige Einmalkosten Kaufpreis

Gesamtsystem (Hardware + Software)

Sonstige Einmalkosten

C) Einzelne Anwendungen

Programmierkosten bzw. Kaufpreis für Programm

Systemkapazität

laufende Überschüsse* in Periode i: E|(i=l,...,n)

Erfüllung einer oder „ . 4 fixierten Aufgabe

D) Einzelne Anwendungen

Nicht abgeschriebene (Rest-) Fixkosten

Systemkapazität

laufende Überschüsse* E j vermindert um Abschreibung w; = Periodennettoertrag Ej = E | - W i 0 = 1 , . . . , n)

Erfüllung einer oder . fixierten Aufgabe

E) Gesamtes Anwendungs„paket"

Totale Einmalkosten einschließlich Kaufpreis des erforderlichen Systems

F) Gesamtes Anwendungs„paket"

Nicht abgeschriebene (Rest-) Fixkosten

-

sinngemäß wie C)**

-

sinngemäß wie D)**

* lfd. Einsparungen + Erlössteigerungen - lfd. Kosten für Programmpflege. **„oder" ist hier zu ersetzen durch „und/oder", da es sich um ein ganzes „Bündel" von Anwendungen handelt. Externspeicher, das Investitionsobjekt darstellt. Eine solche Betrachtungsweise erscheint zwar angesichts der vielfältigen und bedeutsamen Wechselwirkungen innerhalb des EDV-Systems etwas eng gefaßt, sie kann nichtsdestoweniger in bestimmten Situationen sinnvoll sein. Der (nicht monetäre) Ertrag einer solchen In-

2.1 Allgemeine Darstellung des Entscheidungsproblems. Abgrenzung der Thematik

29

vestition ist die Bereitstellung einer gewissen Speicher- oder Verarbeitungskapazität. Es ist klar, daß eine diesbezügliche Maximierung nie Selbstzweck sein kann. Aus diesem Grunde kommt Fall A) nur dann in Frage, wenn es gilt, eine vorgegebene Kapazität bestimmter Art mit minimalem finanziellen Aufwand zu erreichen. Die hier gemeinte Kapazität läßt sich im allgemeinen nicht arithmetisch addieren. Es handelt sich also um wirtschaftlich (und meist auch technologisch) 16 abhängige Projekte. Es sei jedoch daraufhingewiesen, daß eine „naive" Komponentenwahl allein aufgrund einzelner Kennzahlen keine Grundlage für einen guten (d.h. ökonomischen) Systementwurf sein kann. Gleichwohl sind solche Fehlplanungen, für die in den USA das Wort vom "name and number game" kursiert, auch heute noch anzutreffen! In Fällen von speziellen Erweiterungsinvestitionen kann es sich unter Umständen auch anbieten, eine Analyse auf prognostizierte Erträge in monetärer Form zu stützen. Im Unterschied zu Fall A) ist im Fall B) die Gesamtheit der Komponenten (einschließlich Software) Investitionsobjekt. Dieser Standpunkt ist ebenfalls nur sinnvoll, wenn die Arbeitslast vorgegeben ist, d.h. ein Problem vom Typus „Inputminimierung für fixen Output" vorliegt. Sehr häufig wird die reale Entscheidungssituation durch diesen Problemtyp approximiert 1 7 . Es existiert eine umfangreiche Literatur über "System Performance and Evaluation". Speziell werden "system mixes", "benchmark-" und "throughput-Kennzahlen" herangezogen, die teils empirisch, teils durch Simulation gewonnen wurden. Auch analytische Methoden, insbesondere die Theorie der Warteschlangen, finden in diesem Zusammenhang Anwendung. Es genügt festzustellen, ob das System den geforderten Spezifikationen gerecht wird oder nicht (vgl. die Ausführungen unter 2.1.6). Eine „Optimierung" geschieht in der Weise, daß eine Reihe von Systemvorschlägen auf ihre Zulässigkeit ("feasibility") getestet wird. Aus den verbleibenden Systemen wird dann aufgrund bestimmter Kriterien (z.B. Kosten oder Zuverlässigkeit des Herstellers) das „beste" ausgewählt.

16 Die meisten Komponenten sind ohne Zentraleinheit nicht verwendbar. Umgekehrt ist die Zentraleinheit ohne bestimmte Zusatzgeräte ebenfalls sinnlos. 17

Die Annahme bedeutet nicht, daß der Anwender sich über die künftige Arbeitslast exakt im klaren sein muß. Es ist vielmehr damit gemeint, daß aufgrund mehr oder weniger intuitiver Festlegungen eine Vorstellung über die erforderliche Kapazität der Anlage besteht.

30

2. Das EDV-Planungsproblem

Ersichtlich sind die beiden Standpunkte B) und A) eng verwandt. Der Unterschied zu A) besteht darin, daß eine Auswahl nur zwischen Projekten zu treffen ist, die sich gegenseitig ausschließen. Die Frage der Additivität der Erträge und das Problem der Interdependenzen werden damit umgangen. Erkauft wird dieser Vorteil auf Kosten der Operationalität des Kapazitätsbegriffs: Wenn schon im Fall A) die Kapazität im allgemeinen eine multiple Ertragsgröße darstellt, so gilt dies erst recht für den Fall B). Zu den Fällen C) und D), die sich nur in der Behandlung der Einmalkosten unterscheiden, sei bemerkt, daß die konsequente Betrachtung der Anwendungen als Investitionsprojekte erst in jüngster Zeit, insbesondere von Plummer [267], gefordert worden ist. Die Behauptung erscheint nicht übertrieben, daß es sich bei der Einbeziehung des Anwendungspakets in die Optimierung um eine äußerst fruchtbare Weiterentwicklung des „Fixed-Output-Problems" handelt. Angesichts der erheblichen finanziellen Entwicklungsaufwendungen, die bei größeren Programmierungsprojekten (oft geht noch eine OR-Studie voraus) entstehen und unter Berücksichtigung der meist hohen technischen Anforderungen ist durch eine solche Betrachtungsweise eine merkliche Verbesserung der Wirtschaftlichkeit des elektronischen Datenverarbeitungssystems zu erwarten. Das größte Hindernis für die investitionstheoretische Behandlung einzelner Anwendungen scheint darin zu liegen, daß neben dem monetären Aufwand auch noch die technische Komponente des Inputs berücksichtigt werden muß. Jede Entscheidung über eine einzelne Anwendung impliziert u.a. das Vorhandensein von gewissen Komponenten der Hardware, z.B. eine bestimmte Mindestausbaustufe der Zentraleinheit oder ein bestimmtes Maß an (interner und externer) Speicherkapazität. Projekte dieser Art, bei denen multiple Ressourcen, insbesondere Ressourcen nichtmonetärer Art, beansprucht werden, lassen sich ohne Zuhilfenahme von Entscheidungsmodellen nur schlecht behandeln. Eine Voraussetzung wäre wohl die Herstellung eines gemeinsamen monetären Nenners für alle Inputkomponenten durch Bewertung. Wenn eine solche Bewertung hier abgelehnt wird, so nicht zuletzt deshalb, weil die Projekte nach wie vor in hohem Grade ökonomisch abhängig (vgl. S. 26) wären: Erfordert die Anwendung j die Ausstattung des Systems mit einem Plattenspeicher, so müßte bei jeder Form der Bewertung darauf Rücksicht genommen werden, ob auch noch andere Anwendungen diesen Plattenspeicher benützen! Ist das nicht der Fall, so müßten die Gesamtkosten der Einheit dieser Anwendung zugerechnet werden, unabhängig davon, welcher Bruchteil der Plattenkapazität durch j wirklich belegt wird. Die praktischen Schwierigkeiten einer Bewertung des „technologischen Inputs" werden auch daraus ersichtlich, daß moderne EDV-Anlagen im allgemeinen im

2.1 Allgemeine Darstellung des Entscheidungsproblems. Abgrenzung der Thematik

31

sogenannten Multiprogramming-Modus arbeiten, d.h. mehrere "tasks" gleichzeitig oder zumindest quasi-gleichzeitig ausfuhren. In den genannten Auffassungsweisen (Fall C) bzw. D ) ) stellt sich das EDV-Investitionsproblem im wesentlichen (dJi. abgesehen von fixierten Basisanwendungen) als ein Problem vom Typus Outputmaximierung bei fixem Input dar. Speziell handelt es sich um multiplen Input. Der monetäre Teil entspricht Aufwendungen für EDV-Projekte, für die ein bestimmtes Budget vorgegeben ist. Der technische Teil dagegen ist in sich wiederum heterogen, entsprechend den diversen Systemkomponenten, wie Zentraleinheit, Externspeicher, Drucker etc. Die diesbezüglichen Ressourcen sind identisch mit den zeitlichen bzw. Speicherkapazitäten dieser Einheiten. Die Konfiguration selbst wird also nicht in die Optimierung einbezogen - ebensowenig wie die Gesamthöhe der monetären Ressourcen. In dieser Hinsicht können die Betrachtungsweisen C) und D) als eine unmittelbare Erweiterung der bekannten SCERT-Methode zur Systemplanung (vgl. 2.1.6) angesehen werden. Während jene sich im wesentlichen damit begnügt, eine irgendwie vorgegebene Konfiguration im Hinblick auf eine ebenfalls vorgegebene Arbeitslast zu bewerten, ist das Ziel dieses Ansatzes das Erreichen maximalen Gewinnes bzw. maximaler Rentabilität durch optimale Auswahl von Anwendungen aus einer Projektliste. Zum Fall des qualitativ definierten Outputs („Erfüllung einer fixierten Aufgabe") ist zu bemerken, daß es sich hierbei um Anwendungen handelt, für die nur noch „taktische" Freiheitsgrade bestehen: Bei vorgegebenem EDV-System ist derjenige ,.Modus" zu wählen, für den der Verzehr an technischen und monetären Ressourcen zu einem Minimum wird. Die beiden letzten Ansätze, E) und F), repräsentieren die umfassendste Betrachtungsweise des EDV-Investitionsproblems. Investitionsobjekt ist nunmehr das gesamte Informationssystem, das sich aus technologischen Subsystemen (Hardund Software) einerseits sowie aus den Anwendungsprogrammen andererseits zusammensetzt. Die beiden Fälle unterscheiden sich wiederum nur bezüglich der Erfassung der Einmalkosten. Beide Male wird (ebenso wie bei C) und D)) das optimale Anwendungs„paket" gesucht — hier jedoch nicht mehr eingeschränkt durch die Vorgabe einer bestimmten Konfiguration. „Inputrestriktionen" sowohl finanzieller wie technischer Art fallen im wesentlichen weg zugunsten der Bestimmung der optimalen

Höhe dieser Ressourcen selbst. Mit anderen Worten heißt dies, daß simultan mit der Arbeitslast auch die hierfür günstigste Konfiguration (einschl. Software) bestimmt werden soll. Die Elemente des EDV-Systems treten bei dieser Vorgehensweise nur mittelbar in Erscheinung: Der Input bei der Wahl eines bestimmten Bündels von An-

32

2. Das EDV-Planungsproblem

Wendungsprojekten umfaßt sowohl Programmierkosten als auch die Kosten fiir die benötigten technischen Einrichtungen. Er ist somit rein monetär. Der Output kann ebenfalls rein monetären Charakter haben. Er kann aber auch qualitative Elemente enthalten, insofern als für bestimmte (Basis-)Anwendungen eine a priori-Entscheidung über ihre Durchführung getroffen werden kann. Beschränkt man sich auf solche Lösungen, die diesen einmal getroffenen Festlegungen Rechnung tragen, so gelangt man zu einem Investitionsproblem, bei dem Input und Output kommensurabel sind. Die Wahl eines Differenzkriteriums liegt somit nahe. (Vgl. dazu 2.1.6). Begrifflich kann die vorliegende Arbeit unter dem Aspekt F) (mit vollständig periodisierten Einmalkosten) gesehen werden. Methodisch liegt jedoch eine gewisse Anlehnung an die Auffassungen A) und D) vor, insofern als sich bei der gewählten Vorgehensweise jede Lösung und insbesondere die Optimallösung als Resultat eines kombinatorischen Prozesses ergibt, dessen einzelne Bausteine die Systemkomponenten und die Anwendungen darstellen. Selbstverständlich ließe sich das gegebene Schema noch weiter verfeinern. So ist etwa in E) bzw. F) auch der Fall des fixierten Informationsoutputs enthalten. Hierbei steht von jeder der Anwendungen fest, daß sie durchgeführt werden soll. Da jedoch noch taktische Variable offenbleiben, läßt sich auch die benötigte Kapazität nicht von vornherein angeben! Es liegt also eine andere Situation vor als in B).

2.1.6 Ziele und Beurteilungskriterien bei der EDV-Planung Die bisherige Darstellung des EDV-Planungsproblems, insbesondere die Ausführungen hinsichtlich seiner investitionstheoretischen Betrachtungsweise, nahm bereits mehrfach Bezug auf mögliche Ziele und Beurteilungskriterien. Die fundamentale Wichtigkeit gerade dieser Punkte erfordert dennoch eine nochmalige zusammenfassende Diskussion. Hierbei soll einerseits ein kritischer Blick auf die gegenwärtig angewandte Praxis (bzw. die einschlägige Literatur) geworfen werden. Andererseits soll bereits hier der Versuch einer verbesserten — weil unmittelbar an den Oberzielen der Unternehmung orientierten — Zielsetzung unternommen werden, der in den späteren Ausfuhrungen über die Zielfunktion des Entscheidungsmodells und über die Möglichkeiten der Koeffizientenschätzung seinen Niederschlag finden wird. Der in diesem Zusammenhang meist etwas großzügig verwendete Begriff „Kriterium" soll dabei weitgehend vermieden werden, da ihm in der Terminologie der Unternehmensforschung ein sehr spezieller und genau definierter Sinngehalt beikommt.

2.1 Allgemeine Daxstellung des Entscheidungsproblems. Abgrenzung der Thematik

33

Schon diese begriffliche Unsicherheit erscheint als ein Symptom für das Vorhandensein gewisser Mängel der heute gebräuchlichen Methoden und Verfahrensweisen beim Entwurf elektronischer Datenverarbeitungssysteme. Zunächst ist festzustellen, daß zur Frage der Festlegung der von der künftigen EDV-Anlage zu bewältigenden Aufgaben in der deutschsprachigen Literatur kaum Aussagen zu finden sind. Dieser Mangel mag zum Teil darin begründet sein, daß bis vor kurzem die Datenverarbeitung hierzulande im wesentlichen für Abrechnungs- und Verwaltungsvorgänge eingesetzt wurde — eine Phase, die in den USA bereits 1964 von fortschrittlichen Großunternehmen überwunden war [231]. Entsprechend dieser Vernachlässigung der Anwendungsplanung leidet nach Ansicht des Verfassers die heute übliche Systemplanung grundsätzlich daran, daß die angewandten Beurteilungsmaßstäbe vornehmlich auf die operative Ebene anstatt auf die Ebene der Unternehmensleitung zugeschnitten sind. Dies gilt für das bereits erwähnte SCERT-Verfahren [243; 156; 166] ebenso wie für die zahlreichen Punktbewertungsverfahren und für alle Arten von Wirtschaftlichkeitsüberlegungen mittels Verfahrensvergleich.18 Nicht selten wird die Wahl eines Computer-Systems sogar auf der Basis generalisierter Aussagen, d.h. ohne explizite Berücksichtigung des zu bearbeitenden individuellen Anwendungskatalogs getroffen. Heinrich [148] bemerkt hierzu: „Entgegen mancher praktischen Handhabung ist die Computer-Selektion als Entscheidungsproblem innerhalb des Prozesses der Systemarbeit zu sehen. Dies kann allein damit begründet werden, daß die Auswahl einer Datenverarbeitungsanlage im einzelnen Anwendungsfall nur vor dem Hintergrund des Datenprofils dieses Anwendungsfalles möglich ist. Unter Datenprofil ist dabei die Darstellung der einzelnen Anwendungsgebiete (Programme und Programmkomplexe), die Bestandteil des konzipierten Informationssystems sind, zu verstehen, wobei sowohl ihre Verflechtungen als auch sämtliche für die Anlagenauswahl relevanten Größen wie Art und Menge der Eingabedaten, der Dateien und ihre Zugriffshäufigkeit, Art und Menge der Ausgabedaten, die Frequenz der Bearbeitung usw. angegeben sind."

Es darf nicht übersehen werden, daß generelle Aussagen der EDV-Hersteller über ihre Produkte, z.B. die Hervorhebung eines besonders günstigen Preis-LeistungsVerhältnisses, auch bei größtem Bemühen um Wahrheit und Klarheit in der Werbung, im Einzelfall eine wesentlich geringere Bedeutung haben können. Die absolut „maßgeschneiderte" Anlage ist sowohl aus technischen wie aus wirtschaftlichen Gründen nicht denkbar. Vielmehr muß sich der Hersteller bei der Entwicklung seiner Produkte bemühen, einer Vielzahl potentieller Benutzer Rechnung zu tragen, wobei selbstverständlich Kompromisse unvermeidlich sind.

18

Bezüglich der praktischen Bedeutung verschiedener Verfahrensweisen bei der Computerauswahl sei verwiesen auf 1303, p. 294J.

34

2. Das EDV-Planungsproblem

Ein gewisser Wert derartiger Aussagen sei dennoch unbestritten, insbesondere wenn von neutraler Stelle der Versuch gemacht wird, die Fülle der für den Kunden meist undurchsichtigen Einzelangaben (Befehlsdauern, Zugriffszeiten u.ä.) in einigen wenigen Maßzahlen zu komprimieren und so eine annähernde Vergleichbarkeit der Anlagen herbeizufuhren. Hierher gehören die zahlreichen „Mixe" und Leistungskennzahlen 19 , die KernelVerfahren, sämtliche generellen Durchsatz- (throughput-)Angaben sowie die aus Leistungskennzahlen abgeleiteten Preis-Leistungs-Verhältnisse. Bei der kommerziell orientierten Problemstellung, um die es sich hier handelt, ist es für die Aussagefähigkeit eines bestimmten Verfahrens von besonderer Bedeutung, inwieweit auch Kanäle und Peripherie in die Berechnungen einbezogen sind. So wird die Bedeutung der Mixverfahren wesentlich dadurch gemindert, daß sie sich nur auf die Zentraleinheit beziehen. Einzelheiten hierzu finden sich in der entsprechenden Fachliteratur [309; 303, S. 295 ff; 238, S. 195], Es sei jedoch noch einmal auf die Hauptgefahr sämtlicher Verfahren dieser Art hingewiesen. Sie liegt darin, daß aufgrund der besonderen Situation des vorliegenden Anwendungsfalles die dem Bewertungsverfahren zugrundeliegenden Annahmen (z.B. die Annahmen über die relative Befehlshäufigkeit bei Mix-Kennziffern) nicht mehr zutreffen und die Zahlen dadurch ihre Aussagekraft verlieren. Zur erfolgreichen Anwendung derartiger Methoden ist zumindest ein gewisses „Fingerspitzengefühl" erforderlich. Als systematisches wissenschaftliches Hilfsmittel für die Computer-Auswahl sind sie kaum zu bezeichnen. Die erwähnte Gefahrenquelle wird bei den beiden folgenden Bewertungsmethoden [238, S. 227 ff; 303, S. 292 ff] weitgehend oder vollständig vermieden: a) Benchmark-Methoden: Hierbei werden fertige individuelle Anwendungsprogramme auf den zu bewertenden Anlagen gerechnet. Die resultierende Laufzeit dient als Beurteilungsmaßstab. Damit der Benchmarktest die reale Situation des Kunden richtig widerspiegelt, sollten sämtliche kritischen Anwendungen in fertig programmierter Form vorliegen. Aus diesem Grunde ist die Methode praktisch nur bei Rekonfigurationen ohne Erweiterung des existierenden Anwendungskatalogs anwendbar. Ein weiterer schwerwiegender Nachteil, der übrigens in der Literatur selten erwähnt wird, liegt darin, daß es praktisch unmöglich ist, die verwendeten Programme auf jede der zu testenden Anlagen optimal abzustimmen.

19

Für kommerzielle Zwecke seien genannt: Mix-I, die KGSt-Mixes, die Simplex-Mixes und die "Post Office Work Unit II".

2.1 Allgemeine Darstellung des Entscheidungsproblems. Abgrenzung der Thematik

35

20

b) Simulationen und verwandte Verfahren: Hier wären insbesondere die Systeme SCERT, CSS und TPAD zu nennen. Mit diesen — meist recht aufwendigen — Hilfsmitteln ist eine Beurteilung von EDV-Anlagen nach technischen „Kriterien" (gesamte Zeitbelastung, Speicherbedarf, Antwortzeiten u.ä.) im Prinzip beliebig genau durchführbar [243; 156; 169; 166], Der Verfasser steht jedoch auf dem Standpunkt, daß eine echte ökonomisch orientierte Optimierung auch mit diesen Verfahren nicht möglich ist. Sie sind vielmehr als potentielle Bausteine eines derartigen Bewertungssystems anzusehen und sollen auch später in diesem Sinne Verwendung finden (vgl. 4.1). Ein anderer einfacherer Weg zur Berücksichtigung des speziell vorliegenden Datenprofils sind die heute viel verwendeten Punktbewertungsverfahren [96, S. 7 3 - 9 0 ; 144, S. 92 ff; 148; 238, S. 229 f; 303, S. 284 ff], die im Prinzip alle in der Bildung einer gewichteten Summe von „Zielerreichungsgraden" oder „Wirksamkeitsfaktoren" bestehen. Eine beispielhafte Zusammenstellung der bewertungsrelevanten Eigenschaften mit möglichen Gewichtungen zeigt Tab. 2. Ein Vorzug dieser Beurteilungsweise ist, daß sie aufgrund der vom Organisator vorzunehmenden Gewichtung von vornherein als intuitiv fundierte Näherungsmethode kenntlich ist. Wie gut die Anpassung an das Datenprofil des Kunden gelingt, hängt allein von der Erfahrung und den Fähigkeiten des Experten ab. Von der Seite des Verfahrens her existiert hierfür jedenfalls keine prinzipielle Grenze. Auch die Verfechter der Punktbewertung räumen die Problematik der Methode ein, verweisen jedoch mit Recht auf die gegenwärtige Situation, in der objektivere und trotzdem wenig aufwendige Auswahlverfahren noch nicht verfugbar sind. Futh schreibt hierzu [96, S. 81]: „Bei der Bewertung und Beurteilung dürfen die Schwierigkeiten eines solchen zahlenmäßigen Anlagenvergleichs nicht verkannt werden. Die Gewichtung der Eigenschaften ist noch vergleichsweise einfach. Im allgemeinen weiß der EDV-Organisator, ob es zur Lösung der anstehenden Aufgaben mehr auf eine hohe Leistungsfähigkeit der auszuwählenden Anlage ankommt oder ob das Schwergewicht (weil die Leistung der Anlage vielleicht nur zur Hälfte ausgenutzt werden kann) bei möglichst geringen Kosten liegt. Sehr viel schwieriger ist dagegen eine der Wirklichkeit entsprechende Zuordnung der Faktoren. Zwar sind dem Organisator die monatlichen Mietkosten oder die Kaufpreise der Anlagen genau bekannt, wie aber soll er beispielsweise die Wirksamkeit unterschiedlicher Betriebssysteme oder den Kundendienst der Hersteller vergleichsweise beurteilen? Obwohl es kein allgemeingültiges, voll zutreffendes und leicht zu handhabendes Verfahren gibt, die Eignung von DV-Anlagen zu messen und zu vergleichen, kann der Organisator dennoch nicht auf den Anlagenvergleich verzichten. Eine Näherungsmethode, die eine gute Sicherheit bietet, ist immer noch besser, als es auf gut Glück zu versuchen oder sich der Entscheidung eines Nachbarunternehmens kritiklos anzuschließen." 20

Zum Begriff „Simulation" sei insbesondere verwiesen auf [202; 2361.

36

2. Das EDV-Planungsproblem

Auf einen wesentlichen Punkt sei hier noch aufmerksam gemacht: Während die zuerst aufgeführte Gruppe von Verfahren weitgehend technisch orientiert ist, erlauben die Punktbewertungsmethoden prinzipiell die Einbeziehung sämtlicher, auch der qualitativen, Gesichtspunkte. In diesem Zusammenhang wären als weitere häufig genannte „Faktoren" zu nennen: Sicherheit, Komfort, Flexibilität, Prestige. Man versucht nun, dem trotz allem noch sehr unbefriedigenden Charakter dieser Verfahren in der Praxis dadurch Rechnung zu tragen, daß man für die im Sinne der bisher genannten „Kriterien" bestgeeignete EDV-Anlage einen Verfahrensvergleich [96, S. 96 ff; 123, S. 178 ff; 144, S. 119 ff; 163; 292] - häufig auch als „Wirtschaftlichkeitsrechnung" bezeichnet - durchführt, in dem die Kosten des bisherigen Systems den Kosten sowie den erwarteten Einsparungen des geplanten Systems gegenübergestellt werden. Tab. 2. Beispiel einer Gewichtung gewünschter Eigenschafzen bei der geplanten Installation einer mittelgroßen EDV-Anlage. Aus [96, S. 791. Gewünschte Eigenschaften

Gewichtung

1. Leistungsfähigkeit 1.1 Hardware 15 10 10 15 10

1.11 Allgemeine Merkmale 1.12 Zentraleinheit 1.13 Ein-/Ausgabegeräte 1.14 Externe Speicher 1.15 Erweiterungs-und Ausbaufähigkeit 1.2 Software 1.21 1.22 1.23

5 10 15

Steuerprogramme Übersetzungsprogramme Anwendungsprogramme Summe

=

90

2. Kosten 20 60

2.1 Einmalkosten 2.2 Laufende Kosten Summe

=

80

3. Kundendienst des Herstellers 30 20

3.1 Organisatorischer Kundendienst 3.2 Technischer Service Summe

=

50

4. Sonstige Vertragsbedingungen 10 10 30

4.1 Allgemeine Bedingungen 4.2 Lieferung und Aufstellung 4.3 Zahlungsbeginn Summe

=

50

2.1 Allgemeine Daxstellung des Entscheidungsproblems. Abgrenzung der Thematik

37

Die Nützlichkeit von Verfahrensvergleichen für das Entscheidungsproblem der Einfuhrung eines elektronischen Datenverarbeitungs- oder Informationssystems erscheint dem Verfasser aus drei Gründen fraglich: a) der Verfahrensvergleich wird in den meisten Fällen erst nach Abschluß des Auswahlprozesses durchgeführt, hat also keinen Einfluß auf diesen selbst. Seine Bedeutung reduziert sich damit auf eine a posteriori-Bestätigung (sofern nicht die Unternehmensleitung überhaupt auf die Umstellung verzichtet) b) selbst wenn der Verfahrensvergleich echt in den Auswahlprozeß integriert wird, ist es nicht praktikabel, ihn für eine größere Zahl von Konfigurationen durchzuführen. Die selektive Wirkung muß deshalb als gering bezeichnet werden c) bereits in der Bezeichnung kommt zum Ausdruck, daß es sich bei der Durchführung von Verfahrensvergleichen nicht um die Planung des Aufgabenkomplexes selbst handelt, sondern daß vielmehr nur ein Vergleich unterschiedlicher Bearbeitungsweisen für bestimmte, bereits durchgeführte, Basisanwendungen vorgenommen werden soll. Meist wird die elektronische Verarbeitungsweise einer praktizierten „konventionellen" (d.h. manuellen oder lochkartentechnischen) Verarbeitungsweise gegenübergestellt. Eine solche Auffassung der EDV-Planung ist typisch für die erste, heute weitgehend überwundene, Phase des Computereinsatzes, deren Ziel die Automatisierung von Abrechnungs- und Verwaltungsvorgängen war. Die jetzt aktuelle zweite oder gar dritte Phase ist demgegenüber gekennzeichnet durch das Problem der Auswahl aus einer Vielzahl möglicher „fortgeschrittener" Computeranwendungen. Nach Meinung des Verfassers sind hierfür neuartige Methoden notwendig, die insbesondere eine Simultanplanung von Anwendungskatalog und EDV-System unter dem Blickwinkel der Investitionstheorie erlauben. Darüber hinaus muß hier (d.h. für das im Mittelpunkt dieser Untersuchung stehende Investitionsproblem F) — vgl. Tab. 1 auf S. 28) auch das in diesem Zusammenhang häufig genannte Beurteilungsprinzip der Rentabilität in Zweifel gezogen werden. Bevor hierfür eine theoretische Begründung gegeben wird, möge ein Beispiel den Sachverhalt verdeutlichen: Die ursprünglich ins Auge gefaßten Alternativen seien auf einem der oben beschriebenen Wege sowie durch die Stellung weiterer einschränkender Zusatzbedingungen bis auf eine Menge von zwei Konfigurationen reduziert worden. Die aufgrund des Renditekriteriums „beste" Anlage A erfordere einen Kapitaleinsatz von 1 Mio DM. Die zugehörige Rendite sei 25%. Die „zweitbeste" Anlage B sei wesentlich aufwendiger (8 Mio DM), erbringe aber nur 20% Rendite. Den angegebenen Renditen entsprechen Erträge (Einsparungen) von 2 5 0 0 0 0 DM bzw. 1600 000 DM pro Jahr.

38

2. Das EDV-Planungsproblem

Die tatsächliche Wahl der Anlage A wird indessen nur dann gerechtfertigt sein, wenn sichergestellt ist, daß das „Differenzkapital" an anderer Stelle so investiert werden kann, daß ein jährlicher Ertrag von mindestens 1350 000 DM entsteht. Ist dagegen eine solche Möglichkeit nicht gegeben und bestehen weiterhin keine Einschränkungen in Form von Budgetrestriktionen, so ist klar, daß der Alternative B trotz ihrer geringeren Rentabilität der Vorzug zu geben ist. Um hier Klarheit zu schaffen, soll der Versuch unternommen werden, die Frage der Kriterienwahl bei der Planung elektronischer Datenverarbeitungssysteme anhand des Zielsystems der Unternehmung selbst zu erörtern. Im Idealfall der Planung und Entscheidung würde jede Alternative, d.h. jede zulässige Kombination von Anwendungen einerseits sowie Hard- und Softwarekomponenten andererseits, im Lichte dieser Oberziele gesehen und bewertet. Es ist jedoch nicht zuletzt der Stand der theoretischen wie der empirischen Zielforschung selbst, der ein derartiges Vorhaben noch als utopisch erscheinen läßt. Die bisherigen Ergebnisse dieser Forschungen [145] haben zu der Erkenntnis geführt, daß dem Ziel „Gewinnmaximierung" zwar nicht der ihm früher von der Betriebswirtschaftslehre zugemessene Absolutcharakter zukommt, aber daß dieses Ziel doch eine der wesentlichsten Komponenten im Zielsystem jeder Unternehmung in einer Marktwirtschaft darstellt. Der Begriff des Gewinns wird dabei bekanntlich im langfristigen Sinne interpretiert, was sich im Hinblick auf die Formulierung langfristiger („strategischer") Entscheidungsmodelle als besonders vorteilhaft erweist. Daß erhebliche Auswirkungen der Informationsverarbeitung auf dieses Unternehmensziel existieren, bedarf an dieser Stelle keiner weiteren Erörterung. Als weitere Ziele nennt Heinen [145, S. 38 ff]: Sicherheit Soziale Verantwortung gegenüber der Belegschaft Marktanteil Unabhängigkeit Kundenpflege Wachstum Prestige Auch hierfür erscheint die elektronische Datenverarbeitung, wenn auch in sehr unterschiedlichem Ausmaß, als durchaus bedeutsam. Das Kriterienproblem läßt sich nun — schon allein wegen des überwiegend qualitativen Charakters der Ziele — keinesfalls dadurch lösen, daß man versucht, quantitative Beziehungen zwischen den Komponenten des Zielsystems einerseits und den EDV-Alternativen andererseits zu formulieren. Ein solches Globalmodell, das sämtliche relevanten Zusammenhänge — etwa in Form eines „Mehrfachkriteriums" — erfaßt, erscheint uns undenkbar.

2.1 Allgemeine Darstellung des Entscheidungsproblems. Abgrenzung der Thematik

39

Man steht hier der fundamentalen Tatsache gegenüber, daß die umfassende und vollständige Abbildung der Unternehmensziele auf eine mit mathematischen oder formallogischen Mitteln definierte Zielfunktion praktisch in keinem Fall möglich ist. Hanssmann schreibt hierzu [133, S. 6]: " . . . it is seldom possible to state the goals of an organization in a completely satisfactory form. No matter how carefully the decision criteria are chosen they cannot reflect all considerations of management. This is especially true of quantitative criteria. — Therefore we must also be satisfied with partial or proximate criteria. By definition, partial criteria embrace only part of the decision maker's considerations, but the part included should be pertinent. That is, the decision criteria should include as many relevant aspects as possible. In this sense they are "approximations" of management's true objectives. As long as we are using partial criteria we have no way of selecting the "best" alternative automatically. The final selection remains a matter of managerial j u d g e m e n t . . . "

Die Wahl des anzuwendenden Kriteriums ist dann relativ klar, wenn man das Problem der „Anwendungsoptimierung" außer acht läßt, sich also auf die Optimierung der Konfiguration fur einen gegebenen Aufgabenkatalog beschränkt. In diesem Falle ist die Minimierung der EDV-Kosten offenbar das natürliche Ziel. Zu beachten ist nur, daß es nicht genügt, allein die Kosten fur die Hardware zu betrachten. Es müssen vielmehr sämtliche entscheidungsabhängigen einmaligen und laufenden Kosten einbezogen werden! Will man dagegen das umfassendere EDV-Planungsproblem (im Sinne von E) bzw. F), vgl. S. 28) behandeln, so muß der Versuch unternommen werden, die zu erwartenden „positiven Effekte" (benefits) so weit wie möglich abzuschätzen und zu quantifizieren. Man darf wohl behaupten, daß in der Praxis die erheblichen Schwierigkeiten einer derartigen Prognose in den meisten Fällen zu einer rein intuitiven — und dabei oft auf sehr irrigen Erwartungen beruhenden — Festlegung der zu bewältigenden Aufgaben geführt hat. Nach Ansicht zahlreicher Fachleute [2; 267] ist hierin eine der Hauptursachen fur die unbefriedigenden Resultate vieler Installationen zu suchen. Die Situation wurde durch Plummer [267, S. 35] treffend charakterisiert: "It is sometimes forgotten that in business, benefits means dollars. Even short-term benefits from computer applications should be quantified in terms of dollar return on the required investment. Too often a computer application is evaluated on the basis of whether it can, rather than whether it should, be done . . . "

Ist der Versuch der Messung aller überhaupt quantifizierbaren Effekte unternommen worden, so bietet sich als geeignetes (Partial-)Kriterium die Differenz zwischen Ertrag und Aufwand an [133, S. 25—36]. Beide Größen brauchen, was bereits betont wurde, nur insoweit erfaßt zu werden, als sie tatsächlich von der

40

2. Das EDV-Planungsproblem

Entscheidung abhängen. So kommen beispielsweise die Kosten für die Grobstudie keinesfalls in Betracht, da sie auch dann anfallen, wenn die Unternehmensleitung aufgrund der vorgelegten Resultate negativ bezüglich der geplanten Umstellung oder Rekonfiguration entscheidet. Mit der Wahl des Nettoertrages bzw. Gewinns21 als Entscheidungskriterium für die Planung von Computersystemen soll jedoch keineswegs die fundamentale Bedeutung des Wirtschaftlichkeitsprinzips geleugnet werden. Dieses Prinzip gilt für den Bereich der „Informationsproduktion" ebenso wie für die Herstellung von Realgütern. Die darin enthaltene Forderung besagt bekanntlich, daß die Produktion der (materiellen oder immateriellen) Güter so effizient wie möglich erfolgen soll 22 . Aus dem Prinzip der Wirtschaftlichkeit läßt sich keine Aussage darüber herleiten, wie die Kapazitäten oder Art und Menge der herzustellenden Produkte zu wählen sind. Unter den besonderen Verhältnissen, die bei der Herstellung des Gutes „Information" vorliegen, muß darüber hinaus die Operationalität des aus der Theorie der Produktion materieller Güter stammenden Wirtschaftlichkeitsbegriffs grundsätzlich in Zweifel gezogen werden. Die bereits für „echte" Produktionsprozesse problematische Abschätzung eines Sollaufwands erscheint angesichts der Neuartigkeit und Vielfalt denkbarer Aufgabenstellungen in der elektronischen Datenverarbeitung vollends unmöglich. Vergleichbare Situationen (Konfigurationen mit ähnlicher Arbeitslast), an denen man sich orientieren könnte, sind praktisch nicht zu finden.

21

Bezüglich des Zeitraums, auf den der Gewinn bezogen werden soll, vgl. S. 92.

22

Gutenberg (125, S. 2 8 - 3 2 1 unterscheidet im technisch-organisatorischen Bereich zwischen „Produktivität" und „Wirtschaftlichkeit": „ , . ..... mengenmäßiger Faktorertrag Produktivität = —_ , . .— Faktoreinsatz Bei qualitativ unterschiedlichen Faktoreinsätzen bzw. -erträgen muß eine Bewertung vorgenommen werden, die jedoch von Preiseinflüssen frei sein sollte (preisbereinigte Ist- bzw. Normalkosten der Produktion). „Wirtschaftlichkeit" wird demgegenüber definiert: bei gegebenem Aufwand

Soll-Produktionsleistung Ist-Produktionsleistung oder Soll-Ertrag (wertmäßig) Ist-Ertrag (wertmäßig)

bei gegebener Produktionsleistung:

Ist-Aufwand Soll-Aufwand

Dabei bezieht sich „Soll" auf die Realisierung der „Minimalkostenkombination"

2.1 Allgemeine Darstellung des Entscheidungsproblems. Abgrenzung der Thematik

41

Eher scheint eine Operationalität des Wirtschaftlichkeitsbegriffs für gegebenen Aufwand (Ausstattung des Rechenzentrums mit Hardware, Software und Personal) denkbar. Dazu wäre jedoch erforderlich, die verschiedenartigen Leistungen eines EDV-Systems in einheitlicher Weise zu bewerten. Diese Bewertung müßte weiterhin, folgt man Gutenberg, preisbereinigt sein, sie dürfte also keinerlei Erfolgsvorgänge einschließen. Aus ähnlichen Gründen ist die Operationalität des oben definierten Produktivitätsbegriffs für den EDV-Bereich zu verneinen. Wenn der Begriff „Wirtschaftlichkeit" nichtsdestoweniger sehr häufig in der EDVLiteratur Verwendung findet, so erklärt sich das aus einer (leider) üblichen Vermengung von Wirtschaftlichkeits- und Rentabilitätsdenken. So wird die „Wirtschaftlichkeit" einer Anlage häufig danach beurteilt, ob die Anschaffungs- und Umstellungskosten innerhalb einer bestimmten Frist erwirtschaftet sind oder nicht. Es handelt sich also praktisch um die Bestimmung einer pay-off-Periode 23 . Nach diesen Ausführungen, die die relativ geringe praktische Bedeutung des Wirtschaftlichkeitsprinzips für die EDV-Planung aufzeigen sollten, sei noch einmal der Standpunkt der vorliegenden Arbeit dargelegt, nach dem die Differenz zwischen Erträgen bzw. Einsparungen einerseits und EDV-Aufwendungen andererseits dasjenige Kriterium darstellt, in dem der tatsächliche Beitrag der Datenverarbeitung zum Unternehmenserfolg am klarsten zum Ausdruck kommt. Akzeptiert man diese Zielsetzung einmal, so läßt sich auch Rolle und Bedeutung des Rentabilitätskriteriums klarer aufzeigen [190]. Zu diesem Zweck sei zunächst das Problem der optimalen Auswahl von Anwendungen im Rahmen eines vorgegebenen „Informationsbudgets" kurz dargestellt24: Aufgrund einer umfassenden Anwendungsanalyse liege eine Liste von Projekten Pj, i = l , . . . , n vor. Die jeweiligen Aufwendungen a; und Erträge Ei seien prognostiziert worden 25 . Angestrebt wird eine Maximierung des Gesamtertrages. Der Sachverhalt läßt sich durch folgendes Entscheidungsmodell wiedergeben: E = 2 EiXj = max! i

{

B > 2 ajXj i

1 wenn Anwendung i ausgewählt wird

23 24

25

(2.1)

0 sonst

Zur pay-off-Periode als Investitions„kriterium" vgl. [133, S. 85]. Eine starke Vereinfachung liegt nicht zuletzt darin, daß hier der „technische Input" vernachlässigt wird (vgl. S. 25). Es handelt sich hier jedoch nur um ein Demonstrationsbeispiel. Unter aj sind genauer die Einmalkosten des Projekts Pj zu verstehen. Die (Netto-)Erträge Ej beziehen sich dagegen auf die Rechnungsperiode, z.B. ein Jahr.

42

2. Das EDV-Planungsproblem

Dabei ist zu beachten, daß es sich hier — aufgrund der gemachten Vereinfachungen — um unabhängige Projekte handelt. Die praktische Durchrechnung derartiger "knapsack"-Modelle (vgl. S. 22) hat nun gezeigt, daß der Größe Ej/aj, die hier als Projektrentabilität aufgefaßt werden darf, die Rolle einer „Rangzahl" zukommt. Wählt man Projekte, beginnend mit der höchsten Rangzahl, so lange aus, bis das Investitionsbudget B erschöpft ist, so gewährleistet eine solche Vorgehensweise eine approximative Ertrags- bzw. Ge winnmaximie rung26 . Diese Optimierung nach Rentabilitätsgesichtspunkten ist insbesondere dann gerechtfertigt, wenn ausreichend technische Kapazität zur Verfügung steht. Die Systemkosten sind dann zum größten Teil als "sunk cost" zu betrachten. Die entsprechenden Komponenten sind „frei". Engpaß ist dann nur das Budget 27 . Ganz anders ist die Sachlage bei abhängigen, z.B. einander ausschließenden, Projekten, wie es beispielsweise alternative Konfigurationen sind. Die Entscheidung zugunsten eines Systems hoher Rendite hat hier zur Folge, daß sämtliche konkurrierenden Alternativen aus der Betrachtung ausscheiden — obwohl sie wegen ihres größeren „Volumens" im Hinblick auf den Gesamtgewinn des Unternehmens wesentlich interessanter sein können! Eine ausreichende Rendite ist selbstverständlich auch hier anzustreben, was mathematisch durch Einführung einer Restriktion der Form S E i X i > p • SaiXi 1

1

(2.2) p = Kalkulationszinsfuß

gesichert werden kann. Die Diskussion der bei der EDV-Planung anzustrebenden Ziele, die bisher zu einer teilweisen Konkretisierung und Quantifizierung in Form eines (partiellen) Entscheidungskriteriums geführt hat, wäre nicht vollständig ohne eine — wenigstens kursorische — Aufzählung derjenigen Gesichtspunkte, die sich der Quantifizierung entziehen, die aber nichtsdestoweniger bei der Entscheidungsfindung durch das Management beachtet werden müssen. Zum Teil beziehen sich diese „Imponderabilien" (intangible factors) [133, S. 13 f und S. 100] ganz allgemein auf die Alternative: Elektronische Datenverarbeitung oder konventionelles Verfahren?

26

Die Maximierung des Ertrages ist bei "knapsack"-Problemen i.a. identisch mit der Maximierung des Gewinns.

27

Zur Terminologie vgl. [133, p. 28].

2.1 Allgemeine Darstellung des Entscheidungsproblems. Abgrenzung der Thematik

43

Positive Effekte sind: — Die Vorteile, die mit der grundsätzlich erforderlichen präzisen Erfassung von Abläufen, Daten, Querverbindungen zwischen organisatorisch getrennten Gebieten usw. verbunden sind. Allein diese Verbesserung der Transparenz der innerbetrieblichen Vorgänge sollte eine starke Motivation fär die Umstellung sein, auch wenn ihre monetäre Erfassung nicht möglich ist. — Die Erhöhung der Sicherheit durch weitgehende Vermeidung von Fehlern, die auf menschlicher Unzulänglichkeit (z.B. Ermüdung) beruhen — Die Entlastung der Mitarbeiter von Routinearbeiten — Das Hineinwachsen in eine neue zukunftsträchtige Technologie und die damit verbundenen Lerneffekte — Die Sicherung des Firmenprestiges nach innen und außen — Die allgemeine Straffung und Vereinfachung des Verwaltungsablaufs, insbesondere Vermeidung unnötiger Parallelarbeit — Die besseren Kontroll- und Koordinationsmöglichkeiten, die insbesondere dann stark ins Gewicht fallen, wenn es sich um Unternehmen mit Zweigbetrieben, Filialen o.ä. handelt. Diesen Vorteilen stehen allerdings einige generelle und kaum vermeidbare Nachteile der EDV gegenüber: — Eine gewisse Starrheit des Systems und damit zusammenhängend relativ hohe Änderungskosten sowie die starke Abhängigkeit von der Herstellerfirma und eigenem technischen Personal. Auch die beträchtlichen Schwierigkeiten und Gefahren des Umstellungsprozesses dürfen nicht unterschätzt werden. Die bisher genannten Imponderabilien verlieren jedoch in dem Maß an Bedeutung, in dem die grundsätzliche Bereitschaft zum Einsatz der elektronischen Datenverarbeitung in den Unternehmungen zur Selbstverständlichkeit wird. Anders ist die Sachlage dagegen bei solchen Gesichtspunkten, die für das Auswahlproblem zwischen verschiedenen EDV-Anlagen bzw. -Konzeptionen eine Rolle spielen: — Bei kleineren Anlagen: durch die geringe Kernspeichergröße ergeben sich mannigfache Beschränkungen, deren Konsequenzen nicht ohne weiteres vorhersehbar sind (bestimmte Programmiersprachen bzw. Compilerversionen können nicht verwendet werden. Die Anschluß-, Erweiterungs- und Ausbaumöglichkeiten sind begrenzt. Ist Programmierung nur in Assemblersprache möglich oder sinnvoll, so werden die Programme im Falle einer späteren Umstellung wertlos u.ä.). — Bei Großanlagen: Dem erhöhten Komfort und der gewonnenen Flexibilität stehen auch einige durch die Komplexität des Systems bedingte Nachteile

44

2. Das EDV-Planungsproblem

gegenüber, z. B. geringe Transparenz, schwierige Bedienung und Störungsbeseitigung. — Auch die komplementären Gesichtspunkte der Marktreife und Modernität fallen besonders bei größeren Installationen ins Gewicht. Das Risiko erheblicher Anlaufschwierigkeiten und -kosten ist insbesondere dann gegeben, wenn noch keine Anlage des bestellten Typs installiert ist. — Es ist bekannt, daß Zuverlässigkeit und Leistung von Computersystemen mehr und mehr durch die immer komplexer werdenden Betriebssysteme bedingt werden. Bei ihrer Einschätzung kommt dem Image des Anbieters mangels objektiver Leistungsmaßstäbe eine sehr reale Bedeutung zu. — Zahlreiche Aspekte, deren quantitative Erfassung bei den früher geschilderten Punktbewertungsverfahren versucht wird, sollen in der vorliegenden Arbeit ebenfalls als Imponderabilien angesehen werden. Hierzu gehören unter anderem der Hersteller-Service sowohl organisatorischer wie technischer Art, die Verbreitung der betreffenden Anlage (insbesondere wird das Vorhandensein einer ähnlichen Konfiguration in der näheren Umgebung wegen der dadurch gegebenen Ausweichmöglichkeit stark ins Gewicht fallen), die Vertragsbedingungen und Lieferzeiten, Güte und Umfang des Software-Angebots (Dienst-, Hilfs- und Anwendungsprogramme. Auch bei Übersetzungsprogrammen, etwa für FORTRAN oder COBOL kann nicht davon ausgegangen werden, daß die Qualität in allen Fällen gleich gut ist!). Weiter dürfen die „Verträglichkeit" (Kompatibilität) und die Kombinationsmöglichkeiten mit Geräten anderer Hersteller im Hinblick auf spätere Änderungen nicht außer acht gelassen werden. — Bei der Entscheidung zugunsten eines bestimmten Anbieters werden schließlich nicht selten die allgemeinen geschäftspolitischen Interessen des Unternehmens eine gewisse Rolle spielen. Als letztes ist noch auf Imponderabilien im Zusammenhang mit dem zweiten großen Problemkreis der EDV-Planung, nämlich der Anwendungswahl, kurz einzugehen. Hier ist nach Meinung des Verfassers eine strenge Trennung zwischen quantifizierbaren und imponderablen Effekten besonders problematisch. Die Erfahrungen fortschrittlicher Firmen, insbesondere in den USA, haben gezeigt, daß sich bei entsprechendem Aufwand sehr viel mehr Wirkungen der EDV als ursprünglich angenommen quantitativ erfassen lassen [106; 267]. Eine solche Messung nimmt jedoch häufig den Charakter einer eigenständigen Studie an, deren Kosten recht erheblich sein können. Dies bedeutet, daß die Frage der Durchführung einer derartigen „Nutzenanalyse" und ebenso die Frage der anzustrebenden Prognosegenauigkeit nicht für alle zur Diskussion stehenden Anwendungen in gleicher Weise beantwortet werden kann. In manchen Fällen, insbe-

2.2 Entwicklung der Entscheidungsalternativen

45

sondere bei schwer erfaßbaren, aber weniger kostspieligen Anwendungen, wird man deshalb möglicherweise auf die Messung verzichten. Beispiele für beide Arten imponderabler Wirkungen sollen im Zusammenhang mit der Zusammenstellung einer Anwendungsliste, also im folgenden Absatz 2.2.1, angeführt werden.

2.2 Entwicklung der Entscheidungsalternativen Der Problemkreis der Planung elektronischer Datenverarbeitungssysteme zeichnet sich durch eine Vielzahl von Alternativen sowohl bezüglich der durchzuführenden Anwendungen wie auch ihrer technischen Abwicklung aus. Eine ausfuhrliche Darstellung der in Frage kommenden Möglichkeiten erscheint geboten, da die Beobachtung realer Entscheidungsprozesse auf diesem Gebiet zu der Schlußfolgerung fuhrt, daß im allgemeinen von einer systematischen Ausschöpfung dieses Alternativenspektrums nicht die Rede sein kann [337; 338; 339]- Vielleicht liegt hier sogar der Hauptnachteil der gegenwärtig verwendeten Verfahren, die — soweit dem Verfasser bekannt — keinerlei Handhabe für die Durchrechnung einer großen Zahl vonlösungsmöglichkeiten bieten (auch Simulationen bieten in dieser Hinsicht bekanntlich wenig Hilfe). Der Wert und die Berechtigung derartiger Methoden, die zum Teil einen hohen Stand aufweisen (z.B. SCERT), sollen hier keineswegs in Frage gestellt werden. Da jedoch die Auswahl der — schon aus Kostengesichtspunkten meist nur wenigen — zu testenden Alternativen heute noch praktisch völlig der Intuition überlassen bleibt, erscheint ein analytisches Hilsmittel zur Bewältigung dieser Phase als sehr wünschenswert. Die Frage lautet keineswegs: „Analytisches Modell oder Simulation als Hilfsmittel der Systemplanung? " Das Ziel muß vielmehr sein, durch geeignete Kombination sämtlicher Planungs- und Entscheidungshilfen ein Optimum sowohl hinsichtlich Lösungsqualität wie auch hinsichtlich der Effizienz des Planungsprozesses zu erreichen. Die sukzessive Einengung des Lösungsspielraums durch Stellung von Mindestbedingungen, Budgetrestriktionen, durch Ausschluß bestimmter Hersteller usw. („Filtermethode"), die charakteristisch für die heute gebräuchliche Planungspraxis zu sein scheint [96, S. 67ff], stellt eine Vorgehensweise dar, bei der die Gefahr nicht von der Hand zu weisen ist, daß durch Fehlentscheidungen untergeordneter Instanzen Weichen gestellt werden, die die Auffindung der echten Optimallösung mit hoher Wahrscheinlichkeit unmöglich machen.

46

2. Das EDV-Planungsproblem

Die geringe Zahl der genauer diskutierten Systemvorschläge (sie ist selten größer als 4 - 6 ) und die Rolle der Unternehmensspitze, die sich faktisch auf einen Finalentschluß in Ja/Nein-Form beschränkt, werden um so weniger befriedigen, je weiter die technische Entwicklung fortschreitet und das Angebot auf dem EDV-Markt vielfältiger, aber auch unübersichtlicher wird.

2.2.1 Alternativen bei der Auswahl der Informationsprojekte (Zusammenstellung eines „Anwendungskataloges ) Das Problem, Entscheidungen bezüglich der „Umstellung" bestimmter Gebiete oder der Inangriffnahme neuartiger Anwendungen zu fällen, existiert, seit man anfing, Elektronenrechner auch für kommerzielle Aufgabenstellungen zu verwenden. Empirische Untersuchungen wie die bereits des öfteren genannten trMcKinseyStudien" zeigen jedoch, daß allgemein anerkannte Grundsätze für den Computereinsatz noch kaum vorhanden sind und daß im Gegenteil beträchtliche Unterschiede hinsichtlich Art und Umfang der Anwendungsgebiete bestehen. Es scheint so, als würden die diesbezüglichen Entscheidungen trotz ihres ausgesprochen strategischen Charakters in vielen Fällen ohne ausreichende rationale Fundierung getroffen. Eine zu ehrgeizige Umstellungspolitik kann dabei erhebliche Anlaufschwierigkeiten und -kosten zur Folge haben. Die bestellte aufwendige Konfiguration erweist sich nicht selten später als überdimensioniert. Ebenso existiert natürlich der andere Extremfall, in dem wegen zu niedrig angesetzter Budgetgrenzen und wegen eines zu begrenzten („inselartigen") Einsatzes das volle Potential der Elektronik nicht zum Tragen kommen kann. Hier den richtigen Mittelweg zu finden ist sicherlich nicht leicht, doch liegt hier der Schlüssel für einen erfolgreichen Einsatz der EDV-Technologie. Auch Computeranwendungen sind Investitionsprojekte, die im Lichte von Aufwand und Ertrag zu beurteilen sind. Auf diese — scheinbar selbstverständliche — Tatsache wurde bereits bei der Formulierung der Ziele und Forderungen nachdrücklich hingewiesen. Es ist jedoch erstaunlich, daß der Investitionsaspekt der Anwendungswahl erst 1969 vom Plummer [267] systematisch untersucht und hervorgehoben wurde! Es bedarf kaum einer Betonung, daß neben dem Gesichtspunkt der Rendite bzw. des Beitrags zum Unternehmensgewinn eine Reihe weiterer Aspekte ins

2.2 Entwicklung der Entscheidungsalternativen

47

Spiel kommen, die ebenfalls nur auf der obersten Ebene beurteilt und gegen die quantitativ erfaßten Faktoren abgewogen werden können. 2 8 Insgesamt führt Plummer folgende Auswahlprinzipien an: Return on investment Distribution of benefits: It may be desirable to include at least one project for each major operating function . . . thus stimulating the identification of potentially profitable future applications Distribution of risk: . . With a number of projects under way simultaneously, the probability of achieving benefits is often significantly increased.. Balance of risk Personnel interests and capabilities: .. the selection of the project slate as a whole should usually reflect the interests and capabilities of individuals in the data processing group Departmental priority: . . no project should be scheduled unless the user department is prepared to commit the needed personnel rescources Die Anzahl der möglichen Alternativen allein für den hier diskutierten Bereich ist überraschend groß. In der zitierten Arbeit wird ein praktischer Fall erwähnt, in dem aus einer Liste von ursprünglich 200 Projekten schließlich 7 Projekte für eine Durchfuhrung in naher Zukunft ausgewählt wurden. Inwieweit für diesen Reduktionsprozeß bereits Entscheidungsmodelle Verwendung fanden, ist dem Verfasser nicht bekannt. Es dürfte jedoch außer Zweifel stehen, daß bei dem kombinatorischen Charakter des Problems die Aufstellung und Durchrechnung derartiger Modelle einen erheblichen Vorteil gegenüber manuellen Verfahren bieten kann. Eine solche Vorgehensweise soll jedenfalls in der vorliegenden Arbeit eingeschlagen werden. Liegen quantitative Daten über Aufwand (einschließlich der laufenden monetären wie technischen Anforderungen) sowie über Einsparungen und Mehrgewinne vor, so soll das Modell „automatisch" günstige Anwendungskombinationen produzieren, aus denen dann der Entscheidungsträger die ihm optimal erscheinende Lösung auswählt (vgl. hierzu Kap. 5). Obwohl in dem soeben erwähnten Fall jedes der 200 zur Diskussion stehenden Projekte durch Prognosen bezüglich Kosten, Ertragserwartung und durch eine Abschätzung der Risiken charakterisiert war, kann die Meinung vertreten werden, daß in anders gelagerten Fällen ein derart hoher Aufwand nicht fur alle Anwendungen erforderlich ist. 28

" . . selecting a project slate normally means setting priorities, often between major functional areas of the company. This is a top-management responsibility. Deciding whether the vice-president of production will have to wait a year or two for his pet project while work is being done for the vice-president of marketing is no job for the data processing manager . . .", [267, S. 38].

48

2. Das EDV-Planungsproblem

Effekte, auf deren quantitative Bestimmung bewußt verzichtet wird, sollten jedoch keinesfalls völlig unberücksichtigt bleiben. Sie sind vielmehr — ebenso wie die „echten" Imponderabilien — vom Top-Management entsprechend ihrer Bedeutung zu würdigen und bei der Entscheidungsfindung zu berücksichtigen. Darüber hinaus ist es sogar denkbar, daß über bestimmte Anwendungen allein aufgrund qualitativer Gesichtspunkte entschieden wird, wobei allenfalls taktische Optimierungsmöglichkeiten offenbleiben. Eine solche Fixierung, die insbesondere für Basisanwendungen von Bedeutung sein dürfte, wurde schon in dem auf S. 28 gegebenen Schema für die Fälle C) — F) angedeutet. Einige typische Imponderabilien, die in diesem Zusammenhang eine Rolle spielen können, sind: -

Beschleunigung der Produktionsvorgänge und Geschäftsvorfälle. Bessere Einhaltung von Terminen Verbesserter Kundendienst Gegebenenfalls Erhöhung der Produktivität von Forschung und Entwicklung (gilt besonders für Time-Sharing-Systeme) Aktuellere Informationen, sowohl interner wie externer Art. Bessere Marktkenntnis Der generelle Wert einer „Datenbank", z. B. die Möglichkeit, zu geringen Zusatzkosten Daten zu beschaffen, deren Nutzen sich erst zu einem späteren Zeitpunkt herausstellt.

Es muß jedoch sichergestellt sein, daß in der Tat ein signifikanter Einfluß auf den Erfojg des Unternehmens existiert — eine Warnung, die besonders bezüglich des letzten Punktes auszusprechen ist. Der reale Wert einer Vermehrung und Präzisierung der Betriebsinformationen ist oft überraschend gering [2; 267]!

2.2.2 Technische Alternativen Schon bei festgelegtem Aufgabenkatalog (erst recht natürlich bei noch zu fixierender Aufgabenstellung) steht der potentielle Anwender heute vor einer Fülle von technischen Möglichkeiten zu ihrer Verwirklichung. Wie allgemein bekannt, handelt es sich beim EDV-Markt um einen außerordentlich dynamischen Markt, dessen zahlreiche neuen Trends wie Multiprogrammierung, Teleprocessing, Echtzeitverarbeitung es auch dem technisch vorgebildeten Interessenten schwer machen, mit der Entwicklung Schritt zu halten. Heute scheint es sich in der Bundesrepublik noch häufig darum zu handeln, daß vom Management eine Grundsatzentscheidung zugunsten eines einzigen Anbieters aus dem relativ kleinen Kreis der EDV-Firmen getroffen wird, wobei nicht selten Herstellerprestige, Geschäftsverbindungen oder gar nationale Gesichtspunkte eine größere Rolle spielen als die technisch-ökonomischen Aspekte des eigentlichen Entscheidungsproblems. Für die Zukunft ist hier jedoch mit Sicherheit eine stärkere Differenzierung zu

2.2 Entwicklung der Entscheidungsalternativen

49

erwarten. Klare Fronten wie zwischen Hersteller A und Hersteller B, zwischen eigener Anlage und Datenverarbeitung außer Haus etc. werden mehr und mehr zugunsten von Mischsystemen verschwinden. Die Zahl der technischen Alternativen wird in dem Maße zunehmen, in dem heute noch gültige, aber eigentlich sachfremde Restriktionen wegfallen werden. Man wird in Zukunft vor der Frage stehen, ob man etwa die Zentraleinheit von der Firma A mieten (oder kaufen) soll,während die Externspeicher von der Firma B kommen, die Datenerfassung bei einer darauf spezialisierten Firma C in Auftrag gegeben wird und bei der Erstellung der Software schließlich eine Firma D eingeschaltet wird [254, S. 44f], Das Streben nach Kompatibilität und die Trennung zwischen Hard- und Softwareleistungen (unbundling), die vom führenden EDV-Hersteller kürzlich bekanntgegeben wurde, weisen in diese Richtung. Ein Blick in US-Fachzeitschriften lehrt, daß der Kreis der Anbieter, vor allem auf dem Sektor der Peripheriegeräte, in geradezu spektakulärer Weise wächst. Daneben ist ein eigener Softwaremarkt (bisher war die Software sozusagen eine „Zugabe" des Herstellers) gerade im Entstehen. Speziell bei den Produkten des zuletzt genannten Bereiches ergeben sich bereits bei der Beschreibung der Produkteigenschaften erhebliche Schwierigkeiten, die keineswegs als gelöst gelten können. Hinzu kommt die Frage der realen Leistungsfähigkeit des Produkts im gegebenen Anwendungsfall. Diese „Leistung" kann weder bei der Hardware noch bei der Software generell definiert werden — sie hängt in hohem Grade von den spezifischen Gegebenheiten des Betriebes ab. (Der Begriff „Preis-Leistungs-Verhältnis", der in der Werbung eine große Rolle spielt, erscheint dem Verfasser deshalb etwas fragwürdig). Es scheint eine für die Datenverarbeitung in besonderem Maße charakteristische Tatsache zu sein, daß jedes Einzelprodukt, sei es eine Zentraleinheit, ein Großraumspeicher oder ein Modularprogramm, gesehen und bewertet werden muß als Baustein eines umfassenden Systems, dessen einzelne Komponenten sich bezüglich ihrer Leistungsfähigkeit keineswegs immer additiv verhalten. 2 9 Beschreibungen, Argumente und Kennzahlen - und seien sie noch so imponierend — dürfen doch nie darüber hinwegtäuschen, daß es letzten Endes immer auf die optimale Bewältigung einer gestellten Gesamtaufgabe im Sinne einer letztendlichen Nutzenmaximierung der Unternehmung ankommt. Ohne die Berücksichtigung dieses fundamentalen Sachverhalts ist keine rationale EDV-Planung denkbar. So hoch man die Rolle der Intuition auch bewertet — hier findet sie sicherlich ihre Grenzen. Wenn Zentraleinheiten aufgrund von Additions- oder

29

Eine gewisse Enttäuschung der in die dritte Computergeneration gesetzten hohen Erwartungen dürfte hierin ihre Erklärung finden. Vgl. 129].

50

2. Das EDV-Planungsproblem

Zykluszeit, Mixkennzahl und ähnlichen „Kriterien" bestellt werden, wenn ein Randomspeicher allein aufgrund von Kapazität und Zugriffszeit ausgewählt wird, so kann ein solches Vorgehen trotz der scheinbar objektiven Grundlage doch nicht rational genannt werden — es gehört vielmehr in den Bereich des „name and number game", also der irrationalen Überbewertung bestimmter qualitativer (Herstellerrenommee) und quantitativer Merkmale (isolierte technische Leistungskennziffern), die in den USA inzwischen vielleicht überwunden ist, in der Bundesrepublik wohl aber noch eine gewisse Rolle spielt. Nach diesen grundsätzlichen Ausführungen soll nun versucht werden, einen schematischen Überblick über das vorliegende Hard- und Softwareangebot zu geben. Auf konkrete Zahlenangaben kann dabei weitgehend verzichtet werden, da die entsprechenden Daten ohne Schwierigkeiten den Handbüchern der Hersteller entnommen werden können bzw. auf Anfrage zur Verfugung gestellt werden. Wir betonen hier noch einmal, daß allgemeine Kennzahlen oder Bewertungsindizes für ganze Systeme wie „benchmark-Zeiten" oder „throughput-Angaben" bei Verwendung eines analytischen Modells des vorgeschlagenen Typs weitgehend überflüssig werden dürften. Stattdessen wird eine je nach Planungsstadium und personeller Kapazität möglichst exakte Belastungsschätzung (und zwar für alternative Lösungen!) vorgeschlagen. 30 Aus diesem Grunde sollen möglichst vollständig diejenigen Charakteristika erfaßt werden, die für eine solche Schätzung (vgl. 4.1) eine Rolle spielen können [95]. Die Übersicht soll neben Hard- und Software für eigene Systeme auch die verschiedenen Möglichkeiten einer Datenverarbeitung außer Haus enthalten, welche einerseits die EDV auch dem kleineren Unternehmen nutzbar machen, aber andererseits auch für Großunternehmen eine wertvolle Ergänzung des „im Hause" installierten Systems darstellen können.

2.2.2.1 Hardware Die Hardwarepalette umfaßt folgende Produkttypen:

a) Zentraleinheiten: Das Spektrum reicht vom Kleincomputer (,.mittlere Datentechnik") bis hin 30

Es soll dabei nicht verschwiegen werden, daß ein solches Vorgehen einen gewissen Mehraufwand mit sich bringt. Dieser Mehraufwand wird aber nach Meinung des Verfassers mehr als gerechtfertigt einmal durch größere Effizienz in der Programmierungsphase, zum andern aber dadurch, daß auf die immer etwas fragwürdige Übertragung generalisierter Erfahrungen und Aussagen auf die individuelle Situation eines speziellen Kunden verzichtet werden kann.

2.2 Entwicklung der Entscheidungsalternativen

51

zur Großanlage mit mehreren hunderttausend oder gar Millionen Kernspeicherstellen. Die Abgrenzung nach oben ist im konkreten Fall verhältnismäßig leicht. Eine Abgrenzung nach unten existiert jedoch nicht unbedingt, da kleinere Anlagen auch zur Datenerfassung, als „Satellitenrechner" sowie als „intelligente Terminals" in Betracht gezogen werden können. Charakteristische Eigenschaften: b)

Kapazität des Kernspeichers (besser: Internspeicher) Organisation des Kernspeichers (feste Einteilung wie bei Wort- und Bytemaschinen oder variable Einteilung bei Stellenwertmaschinen. Wortlänge bei Wortmaschinen) Takt- oder Zykluszeit Aufbau und Umfang des Befehlsrepertoires (z. B. Ein- oder Mehrfachadressierung), Operationszeiten der Einzelbefehle bzw. Mixkennzahlen Anzahl der programmierbaren Register Vorrangsteuerung Überlappungsmöglichkeiten beim Verkehr mit der Peripherie Binäre oder dezimale Arbeitsweise Multiplikation/Division: verdrahtet oder über Software? Gleitkomma Mehrfachpräzision Ausstattung der Konsole Grad der Parallelarbeit („internes Multiprocessing") Zahl und Art der standardmäßig vorhandenen Kanäle Anschluß- und Erweiterungsmöglichkeiten (Kernspeicherausbau „im Feld", Datenfernverarbeitung)

Magnetbandgeräte: Im Rahmen der durch die Zentraleinheit (CPU) vorgegebenen Grenzen existieren zahlreiche Variationsmöglichkeiten, da in ein und derselben Konfiguration Bandeinheiten unterschiedlichen Typs (evtl. sogar unterschiedlicher Hersteller) eingesetzt werden können. Die wichtigsten Merkmale sind: -

31

Aufzeichnungsdichte Schreib-/Lese-Geschwindigkeit Anzahl der Spuren 3 1 Kluftlänge Start/Stop-Zeit Möglichkeit des Rückwärtslesens Erforderlichkeit einer Steuereinheit Anzahl der Laufwerke Möglichkeit des gleichzeitigen Schreibens und Lesens Art und Weise der Kontrollen Verwendbare Formate, Speicher- und Verarbeitungsmethoden

Man spricht auch hier von „Kanälen". Es besteht jedoch keinerlei Zusammenhang mit den bereits erwähnten „Datenkanälen", die für die Übertragung der Daten zwischen Zentraleinheit und Peripherie sorgen.

2. Das EDV-Planungsproblem

52

c) Externe Speicher mit wahlfreiem Zugriff (Randomspeicher): Man verwendet sie, wenn die Reihenfolge, in der die Daten zu verarbeiten sind, wechselt oder noch nicht bekannt ist. Dadurch werden Sortierläufe, die bei Band- oder Kartensystemen einen erheblichen Teil der Kapazität beanspruchen, weitgehend überflüssig. Zu achten ist auf: -

Auswechselbarkeit des Speichermediums Kapazität Zugriffszeit (minimal, durchschnittlich, maximal) 3 2 Erforderlichkeit einer Steuereinheit Verarbeitungs- und Speicherformen Feste oder variable Blocklänge Art des Zugriffs (z. B. Zylinderzugriff) Prüfungen und Datensicherungen

Generell gilt: je höher die Kapazität, umso länger die Zugriffszeit Der gebräuchlichste Randomspeicher ist der Magnetplattenspeicher. Daneben gibt es noch Trommelspeicher, Magnetkartenspeicher und Streifenspeicher. d) Drucker. Im wesentlichen handelt es sich dabei um Zeilendrucker (Schnelldrucker). Ein Blattschreiber ist meist in die Zentraleinheit integriert. Da kommerzielle Systeme durch einen hohen Anteil an Eingabe/AusgabeOperationen gekennzeichnet sind, ist die Druck-Kapazität der Anlage (gegeben durch Anzahl und Leistungsfähigkeit der Schnelldrucker) eine wichtige Determinante für die Leistung des Gesamtsystems. Charakteristika: -

Anzahl der verfugbaren Zeichen Geschwindigkeit (Zeilen/Stunde) Druckpuffer eingebaut oder anschließbar? Zeilenbreite Maximale Anzahl der Kopien Druckkontrolle

e) Lochkartengeräte-. Leser, Stanzer, Rechenstanzer, Doppler, Beschrifter, Sortiermaschinen, Mehrfunktionskarteneinheit. Neben augenfälligen Merkmalen wie Lese- oder Stanzgeschwindigkeit gibt es eine Fülle weiterer Punkte, die im Einzelfall von ausschlaggebender Bedeutung sein können (etwa, indem sie die zeitliche Belastung stark mitbestimmen). Dazu gehören z. B. Pufferung, Zahl der Ablagefächer, Stanzen in gleiche Karte, Code-Umwandlung. 32

Trotz der Wichtigkeit dieser Größe definiert nahezu jeder Hersteller den Begriff „Zugriffszeit" anders [96, S. 60].

2.2 Entwicklung der Entscheidungsalternativen

53

Es erscheint jedoch — ebensowenig wie bei den im folgenden kurz aufgeführten Gerätegruppen — nicht angebracht, explizit auf diese Details einzugehen. Sinn und Zweck dieser Ausfuhrungen ist es vielmehr, eine Vorstellung von der Zahl der zur Verfügung stehenden Hardware-Alternativen zu vermitteln.

f) Lochstreifengeräte g) Sonstige Datenerfassungseinrichtungen bzw. Ausgabegeräte: Locher, Prüfer, Lochstreifenkartengeräte, Datensichtstationen (mit Bildschirm), Fernschreiber, Bandbeschrifter bzw. allgemein Geräte, die es ermöglichen, mit externen Speichern unabhängig von der Zentraleinheit ("off-line") zu arbeiten, optische und magnetische Belegleser, Analog-Digital-Umsetzer, Geräte für graphische Eingabe (Lichtschreiber) und Ausgabe (Plotter), Mikrofilm-Ausgabe (COM). h) Kanäle (Selektor- oder Multiplexkanal, Übertragungsgeschwindigkeit) i) Steuereinheiten lich)

(insbesondere bei Externspeichern häufig zusätzlich erforder-

j) Kopplungseinrichtungen

("Interfaces")

k) Kompatibilitäts- oder Verträglichkeitselemente (Emulatoren): Sie ermöglichen die Verwendung älterer Programme, ersparen also beim Übergang auf eine größere Anlage den Aufwand der Umprogrammierung — allerdings auf Kosten der Effizienz des Maschinenprogramms! 1) Einrichtungen für Datenfernverarbeitung: Der Begriff „Datenfernverarbeitung" kann einerseits besagen, daß das zu planende System selbst die „Zentrale" darstellt und andererseits, daß die Integration in ein anderes — bereits existentes — EDV-System angestrebt wird. Der zuerst genannte Fall gehört in den Bereich „Datenerfassung" und ist somit im wesentlichen bereits behandelt. Bezüglich der noch ausstehenden Diskussion des eigentlichen Übertragungssystems sei auf die Ausfuhrungen über „Datenverarbeitung außer Haus" (2.2.2.3) verwiesen. Die dortigen Ausführungen behandeln auch den soeben erwähnten zweiten Fall. An dieser Stelle sei nur daraufhingewiesen, daß ein Großteil der bereits besprochenen Geräte als Datenstation bezüglich des „fremden" Systems in Frage k o m m t 3 3 (etwa ein Lochstreifenleser, aber auch die Zentraleinheit selbst! Im letzteren Fall sind gewisse Kontrolleinheiten zusätzlich erforderlich). Es sei noch daran erinnert, daß die geschilderten Alternativen praktisch immer unter zwei Aspekten, nämlich Anzahl und Typenwahl, gesehen werden müssen. 33

Besonders erwähnenswert erscheint die Möglichkeit, ein Kleincomputersystem als „intelligentes Terminal" zu benützen. Aufgaben, die die Kapazität der eigenen Anlage übersteigen, werden an das Großrechenzentrum „delegiert".

54

2. Das EDV-Planungsproblem

Dies gilt sogar für Zentraleinheiten, obwohl hier im allgemeinen die Frage des Fabrikats und des zu wählenden Modells dominierend im Vordergrund steht. Es sollte trotzdem nicht übersehen werden, daß die Menge der Hardware-Lösungen einerseits auch konventionelle Systeme, z.B. reine Lochkartenanlagen, ( 0 Zentraleinheiten) sowie andererseits auch Konfigurationen mit mehreren Zentraleinheiten [196]. enthält. Bei den letzteren kann man grob unterscheiden zwischen: — Multiprocessingsystemen, bei denen zwei Maschinen (Prozessoren) annähernd gleicher Größenordnung „Hand in Hand" arbeiten. Ihre Kopplung erfolgt über ein gemeinsames Betriebssystem sowie in manchen Fällen über einen gemeinsamen Hauptspeicher — — Satellitensystemen, bei denen kleinere zusätzliche Zentraleinheiten Hilfsfunktionen (vor allem Eingabe/Ausgabe) übernehmen. Der teure Hauptrechner wird damit effizienter eingesetzt — — Verbundsystemen, bei denen zwei oder mehr räumlich getrennte EDV-Systeme in relativ lockerer Weise gekoppelt sind — — Teleprocessing — (Datenfernverarbeitungs-)Systemen mit „intelligenten" Datenstationen (v.a. Kleincomputern) — — Systemen mit mehreren „freistehenden" Computern. Ein Datenaustausch ist entweder überhaupt nicht erforderlich (etwa, weil die eine Anlage für technisch-wissenschaftliche, die andere für kommerzielle Zwecke eingesetzt wird) oder kann auf manuelle Weise erfolgen. Die Zahl der Alternativen wird bei Großanwendern noch durch den Umstand erhöht, daß selbstverständlich auch Kombinationen der genannten Lösungen möglich sind. Weiter geht aus den obigen Ausführungen auch hervor, daß bei den im folgenden zugrundegelegten Hardware-Alternativen auch so wichtige Fragen wie „zentrale oder dezentrale Datenverarbeitung", „Ausstattung des Rechenzentrums mit einem großen oder mehreren kleineren Computern", „Kernspeicherausbau oder Multiprocessing" u.ä. prinzipiell mit einbezogen sind. Es soll hier jedoch keineswegs der Eindruck erweckt werden, als würde mit dem später vorgeschlagenen 0/1-Modell sozusagen eine „Patentlösung" für diese überaus komplexen Probleme angeboten werden. Die Ausfuhrungen sind vielmehr nur als Anregungen zu verstehen, den Nutzen der Modelltechnik auch an anspruchsvollsten Systemkonzeptionen zu erproben. Schon eine geringe Reduktion des Planungsaufwands oder eine signifikante Verbesserung der Lösungsqualität wäre — angesichts der finanziellen Größenordnungen der Projekte — ein beachtlicher Erfolg.

2.2 Entwicklung der Entscheidungsalternativen

55

2.2.2.2 Software Als nächstes soll der Versuch gemacht werden, auch das Gebiet der Software in groben Zügen — aber dennoch vollständig - zu umreißen. Die gleich- oder gar vorrangige Bedeutung der Software im Vergleich zu den physischen Elementen des Systems, also der Hardware, wird heute allgemein gesehen. Erst die geglückte Kombination beider Elemente gewährleistet ein befriedigendes Funktionieren des Gesamtsystems. Während jedoch die Hardware so gut wie aller Hersteller als weitgehend ausgereift bezeichnet werden kann, läßt sich dies von der angebotenen Software nicht in jedem Falle ohne Einschränkung behaupten. Die praktische Erfahrung zeigt, daß Schwachstellen in der Mehrzahl der Fälle eindeutig auf Softwaremängel zurückzuführen sind 34 . Dabei ist zwischen zwei negativen Wirkungen zu unterscheiden: Echte Softwarefehler führen zu erhöhten Anlaufschwierigkeiten, z.B. in Form von häufig auftretenden „Systemzusammenbrüchen". Direkte Umsatzeinbußen entstehen, wenn der Pröduktionsbereich betroffen wird, z.B. bei automatischer Prozeßkontrolle. Die Auswirkungen von zwar logisch richtiger, aber dennoch schlecht konzipierter Software sind demgegenüber weniger eklatant. Da sie jedoch nur selten entdeckt werden, sind die durch sie verursachten „Reibungsverluste" und Redundanzen im allgemeinen permanenter Natur. Die Anlage wird zu einem früheren Zeitpunkt als notwendig voll ausgelastet sein. Eine unnötige Neuplanung bzw. Erweiterung kann die Folge sein. Da eine allgemein akzeptierte Definition des Begriffs „Software" — wie so häufig in der Terminologie der Datenverarbeitung — nicht existiert, ist eine Präzisierung dessen, was im folgenden unter „Software-Alternativen" verstanden werden soll, erforderlich [99]. Gemeint sind hier Alternativen bezüglich Programmen, die genereller Natur sind, indem sie Steuerungs-, Verwaltungs-, Übersetzungs- und Hilfsfunktionen ausüben. Ein Sortierprogramm würde beispielsweise in diese Kategorie fallen, da der Vorgang des Sortierens immer nur als Teil größerer Programmkomplexe in Erscheinung tritt. Dagegen sollen Modularprogramme zur Lageroptimierung oder Fertigungssteuerung nicht als Software, sondern vielmehr als Anwendungsprogramme angesehen werden. Im Gegensatz dazu bezeichnen viele Praktiker sämtliche Programme, soweit sie vom Hersteller der Anlage mitgeliefert wurden, als Software. Eine solche Grenzziehung nach der Herkunft erscheint dem Verfasser nicht sehr sinnvoll. 34

Bouvard [291 schreibt hierzu: "For many users, system Software Performance has proved the greatest source of disappointment. Excessive usage complexity, heavy overhead, unavailability, unreliability, and incompleteness are among the most frequently voiced complaints".

2. Das EDV-Planungsproblem

56

Der gegebenen Definition entsprechend taucht die Frage: „Übernahme von Standardprogrammen oder Eigenerstellung?" ebenso im Zusammenhang mit der Anwendungsprogrammierung wie auch hinsichtlich der eigentlichen SoftwareAlternativen (sog. Systemprogrammierung) auf. Welch erhebliche Bedeutung ihr gerade im letzteren Bereich zukommen kann, wird aus einem Beispiel deutlich, das Klemencic angibt: 35 „ . . . ein Kunde brauchte für sein größtes Programm 35 K einschließlich des EinAusgabe-Systems. Sein Hersteller bietet zwischen 32 K und 65 K keine Zwischenstufe an. Anstatt sich für eine 65 K-Anlage zu entschließen, verzichtete er auf das vom Hersteller gelieferte Ein-Ausgabe-System und schrieb sein eigenes. Dadurch reduzierte er den Kernspeicherverbrauch auf 30 K und brauchte nur eine 32 K-Anlage zu mieten."

Es bedarf jedoch kaum besonderer Betonung, daß die Erstellung eigener oder auch nur die Modifikation fremder Software mit erheblichen Schwierigkeiten und Risiken behaftet ist, somit also nur für größere Anwender mit reicher EDVErfahrung und entsprechender personeller Kapazität in Frage kommt. Sind aber diese Voraussetzungen gegeben, so erscheint gerade diese Alternative als besonders fruchtbar. Das vorgeschlagene Modell ermöglicht auch hier eine weitgehend rationale Beurteilung, welche das Projekt nicht isoliert betrachtet, sondern seine Wechselwirkung mit der „Umgebung" (restliche Software, Anwendungsprogramme, Hardware) voll in Rechnung stellt. Neben den genannten Alternativen tritt neuerdings in zunehmendem Maße eine dritte, nämlich die auftragsgebundene Programmierung durch Software-Institute oder der Kauf (bzw. die Miete) fertiger Programme von solchen Instituten. Auch diese Möglichkeit sollte bei Systemplanungen unbedingt ins Auge gefaßt werden. Eine besondere Schwierigkeit des Wahlproblems bei der Software liegt darin, daß eine klare und erschöpfende Beschreibung kaum denkbar erscheint. Die Charakterisierung erfolgt im Gegensatz zu Hardwarekomponenten immer noch überwiegend verbal, so daß — insbesondere bei der Einschätzung neu auf den Markt kommender Produkte — Vorsicht geboten ist. Aber auch über die Vor- und Nachteile bereits bewährter Systeme gehen die Meinungen der Fachleute oft stark auseinander, da jeweils nur bestimmte, im Einzelfall vielleicht besonders wichtige Aspekte herausgegriffen und betont werden, während andere Merkmale unbeachtet bleiben. Die Diskussionen über den Wert der Assemblerprogrammierung sowie über die Vor- und Nachteile der verschiedenen problemorientierten Sprachen belegen dies augenfällig. Die Verwendung eines analytischen Planungsmodells ist nicht an eine Objektivierung der Software-Beschreibung gebunden — wenn auch Fortschritte in dieser Richtung eine wertvolle Hilfe und möglicherweise die Basis für eine automatische 35

Klemencic, B„ Geleitwort zu: [891.

2.2 Entwicklung der Entscheidungsalternativen

57

Belastungsschätzung (vgl. 4.1) darstellen könnten. Ansätze hierzu sind — wie verlautet — in den bereits erwähnten Systemen SCERT und CSS verwirklicht. Im folgenden sollen nun die wichtigsten Elemente der Software und einige Gedanken zu ihrer Beschreibung kurz angeführt werden. a) Betriebssystem (Operating System): Die Funktion des Betriebssystems besteht unter anderem darin, gewisse Aufgaben des Maschinenbedieners (Operators) zu übernehmen, wodurch die Rüstzeiten herabgesetzt, die Gefahr von Bedieitungsfehlern verringert und ein effizienterer Einsatz der Anlage gewährleistet wird. Es setzt sich zusammen aus einem Kontroll- bzw. Steuerprogramm ("Supervisor") sowie weiteren Programmen, die bei Bedarf vom Steuerprogramm aufgerufen werden, welches die entsprechenden Funktionen an sie delegiert. Die Tätigkeit des Maschinenbedieners wird je nach Komfort des gewählten Systems mehr oder weniger auf Routinearbeiten beschränkt, z.B. Auswechseln von Bändern. Er erhält vom System genaue Anweisungen über die Konsolschreibmaschine oder eine andere Ausgabeeinheit. Die Protokollierung wird automatisiert. Ist eine Arbeit undurchführbar, so wird eine entsprechende Nachricht ausgegeben. Darüber hinaus erhält der Operator oder Programmierer Hinweise für die Fehlersuche. Gleichzeitig sorgt das Betriebssystem für einen reibungslosen Übergang zum nächsten "Job". Bereits bei der einfachsten Form der elektronischen Datenverarbeitung (Einprogrammbetrieb), bei der Job für Job nacheinander abgearbeitet wird 3 6 , ergibt sich ein Reihenfolgeproblem. Die Rüst- und Wartezeiten hängen in gewissem Grade davon ab, in welcher Reihenfolge die einzelnen Arbeiten ins System eingegeben werden. (So kann man z.B. durch geschickte Wahl der Reihenfolge unter Umständen erreichen, daß die Maschine während eines Bandwechsels nicht stillsteht). Es gibt Betriebssysteme, die in der Lage sind, dem Bediener auch dieses Optimierungsproblem abzunehmen. Die Güte dieses "Scheduling", das erst recht bei der überlappten Bearbeitung mehrerer Programme, bei der sog. Multiprogrammierung (= Simultanverarbeitung), eine große Rolle spielt, drückt sich aus im Anteil der Verwaltungsarbeit

36

Anstelle des Begriffs „Einprogrammbetrieb" wird gelegentlich auch der Begriff „Schubb e t r i e b " gebraucht. Wir werden im folgenden meist von „sequentieller Verarbeitungsweise" (im gegensatz zu Simultanverarbeitung) sprechen. Der in diesem Zusammenhang häufig genannte Ausdruck „Stapelverarbeitung" (batch processing) gibt dagegen leicht zu Mißverständnissen Anlaß, da er von einigen Autoren synonym mit „Einprogrammbetrieb", von anderen dagegen als Oberbegriff für Ein- und Mehrprogrammbetrieb (bei Eingabe „gestapelter" Daten) gebraucht wird.

58

2. Das EDV-Planungsproblem

("overhead"), in den Leerzeiten bzw. Auslastungen der einzelnen Komponenten sowie eventuell in zusätzlich erforderlichem Speicherraum auf externen Speichern. Eine besondere Problematik ergibt sich hierbei daraus, daß diese Größen nicht von vornherein bekannt sind, sondern vielmehr von der erst zu bestimmenden Arbeitslast in starkem Maße mit abhängen. Die resultierende Nichtlinearität soll im folgenden durch ein iteratives Vorgehen behoben werden: Ausgehend von gewissen plausiblen Annahmen über Leerzeiten etc. wird eine Optimierung mit Hilfe des 0/1-Modells durchgeführt. Die Annahmen werden a posteriori überprüft und die Optimierung, falls erforderlich, mit revidierten Werten wiederholt, bis sich Konvergenz ergibt. Eine Beschreibung des „Scheduling-Algorithmus", die nicht auf eine bestimmte Arbeitslast Bezug nimmt, wäre befriedigender, würde aber den Rahmen eines linearen ganzzahligen Modells sicherlich sprengen. Die Komplexität der Betriebssysteme nimmt heute in einem Maße zu, daß bereits der Punkt erreicht zu sein scheint, an dem die Software-Entwicklungskosten die Kosten für die Weiterentwicklung der Hardware zu überholen beginnen. Insbesondere für kleinere EDV-Hersteller dürfte es zunehmend schwieriger werden, die notwendige personelle Kapazität aufzubringen. In vielen Fällen wird hier die Inanspruchnahme einer auf Systemprogrammierung spezialisierten Firma die optimale Lösung darstellen, wenn auch die hierfür aufzuwendenden Beträge manchem Interessenten, der gewohnt ist, Software als „kostenlosen" Service 37 zu erhalten, zunächst außerordentlich hoch erscheinen mögen. Für den rational planenden Anwender sollte es jedoch nur darum gehen, auf lange Sicht den günstigsten Kompromiß aus Kosten, Leistung und Sicherheit zu finden. Ein zu primitives System wirkt in mannigfacher Hinsicht einengend und führt darüber hinaus zu einer schlechten Auslastung der Anlage. Auf der anderen Seite besitzt ein zu anspruchsvolles System nicht nur die bereits erwähnte Fehleranfälligkeit; es verursacht auch direkt und indirekt (über die Anforderungen an die Konfiguration) Kosten, die nicht immer der zusätzlich erbrachten Leistung entsprechen. Dies gilt in besonderem Maße für Arbeitsweisen, die heute unter den

Schlagworten On-Line, Real Time, Multiprogramming, Multiprocessing, Teleprocessing, Time-Sharing usw. angeboten werden [14; 37; 298]. (Bezüglich einer genaueren Definition dieser Begriffe sei auf 4.1 verwiesen). Eng verbunden mit der eben diskutierten „Scheduling-Funktion" (= Planung und Steuerung der Verarbeitungsreihenfolge) ist die Kontrolle des Datentransports zwischen Hauptspeicher einerseits und Eingabe-/Ausgabe-Geräten bzw. Ex37

Die sog. Kern-Software wird aller Voraussicht nach auch in Zukunft nicht gesondert berechnet werden.

2.2 Entwicklung der Entscheidungsalternativen

59

ternspeichern andererseits. Wegen des hohen Anteils solcher Vorgänge bei den kommerziellen Anwendungen der EDV erscheint eine genaue Kenntnis der hierfür relevanten Eigenschaften des Operating Systems im Hinblick auf spätere Laufzeitschätzungen von großer Wichtigkeit. Im wesentlichen handelt es sich dabei um Funktionen der IOCS (= Input/Output Control System), das außer den den Datenfluß regelnden „Kanalprogrammen" noch die verschiedenen Zugriffsmethoden oder -routinen enthält, deren Bedeutung für die Systembelastung noch zu diskutieren sein wird (vgl. 4.1). Einige wenige objektiv faßbare Charakteristiken lassen sich bei allen Betriebssystemen ohne weiteres angeben. Dazu gehört vor allem der Bedarf an Kernspeicher- bzw. Externspeicherkapazität und - in unmittelbarem Zusammenhang damit stehend — die Angabe der erforderlichen Mindestkonfiguration. b) Compiler und Assembler (Programmiersprachen): Es handelt sich um Übersetzungsprogramme, die das vom Menschen in einer mehr oder weniger problemnahen Sprache abgefaßte Programm in Befehle umsetzen, die von der Maschine unmittelbar interpretiert werden können. Bei fei Maschinensprache im engeren Sinn handelt es sich bekanntlich um reine Binärbefehle. Die Programmierung bereits mäßig komplizierter Abläufe auf dieser Basis ist wegen der Unübersichtlichkeit dieser Sprache praktisch unmöglich. Aus diesem Grunde ist heute die elementarste oder „maschinennächste" Stufe der Programmierung der Assembler. Zwischen den Befehlen des „symbolischen" Programms und den Maschinenbefehlen besteht (abgesehen von „Makrobefehlen") 1 : 1-Korrespondenz. Die Syntax wird also durch den Übersetzungsprozeß nicht verändert. Zwischen der Flexibilität einer Sprache und ihrer „Einfachheit" besteht eine inverse Relation: Während es die jeweils für eine bestimmte Anlage oder Serie konzipierten Assemblersprachen erlauben, die Möglichkeiten der Maschine voll auszuschöpfen — auf Kosten der Einfachheit — sind die auf einer höheren Stufe stehenden problemorientierten oder Compilersprachen COBOL, FORTRAN, ALGOL, PL/1 bequem handzuhaben, ermöglichen aber nicht mehr ohne weiteres den vollen Zugang zum Befehlsvorrat des Computers. Wesentlich ist auch, daß ein auf automatischem Weg, d.h. über einen Compiler, erzeugtes Maschinenprogramm im allgemeinen nicht identisch ist mit einem direkt in Maschinensprache — oder, was praktisch dasselbe ist, in Assembler — geschriebenen Programm. Das letztere wird normalerweise einen höheren „Optimierungsgrad" aufweisen, d.h. die Anforderungen bezüglich Speicherkapazität und Rechenzeit werden geringer sein. Es kann jedoch keineswegs als gesichert gelten [86; 241], daß das unbestreitbar

60

2. Das EDV-Planungsproblem

höhere Potential der Assemblerprogrammierung auch in jedem Fall tatsächlich genutzt wird. Ihre immer noch weite Verbreitung geht sicher nur zu einem Teil auf echte Vorzüge zurück. Andere Faktoren scheinen das menschliche „Beharrungsvermögen" und das Fehlen einer nüchternen Abwägung von Vor- und Nachteilen zu sein. Die Assemblerprogrammierung ist die historisch ältere Form der Programmierung und wenn auch Compiler für FORTRAN (1956), COBOL (1961) und ALGOL schon relativ früh auf den Markt kamen, so waren sie doch zunächst in vielen Fällen nicht konkurrenzfähig gegenüber den „symbolischen Codes". Inzwischen hat sich jedoch das Bild stark verändert. Selbst Anwender, bei denen die Assemblerprogrammierung noch dominiert, bestreiten nicht, daß der Trend deutlich in die Richtung problemorientierter Sprachen weist. Sie scheuen sich aber, bei dieser Entwicklung eine „Pionierrolle" zu übernehmen. Dabei wird übersehen, daß jede Verzögerung dieses unbedingt notwendigen Übergangs beträchtliche Kosten verursacht, die einmal objektiv abgeschätzt werden sollten. Die erheblichen Summen, die für die Erstellung und die Pflege von Programmen aufzuwenden sind sowie die durch Testläufe, fehlerhafte Resultate etc. verursachten Kosten lassen die Alternative „Assembler oder problemorientierte Programmiersprache?" als eine durchaus strategische Alternative erscheinen. Die wichtigsten der zu beachtenden Gesichtspunkte seien deshalb im folgenden noch einmal in Kurzform zusammengefaßt 38 . Grad der Maschinenabhängigkeit: Alle Assemblersprachen sind an einen bestimmten Maschinentyp oder an eine bestimmte Serie gebunden. Meist liegt innerhalb der Serie „Aufwärtskompatibilität" vor. Ein bestimmtes Assemblerprogramm wird also auch für die größeren Anlagen der Serie verwendbar sein, wobei normalerweise jedoch die „Optimalität" des Programms verloren geht. Der Übergang auf eine Maschine außerhalb der betreffenden Serie ist zwar ebenfalls möglich, setzt aber die Existenz entsprechender TransformationsprogTamme voraus. Bezüglich der damit verbundenen Problematik sei auf S. 63 verwiesen. Grundsätzlich kann gesagt werden, daß die starke Gebundenheit an einen bestimmten Maschinentyp immer zu Schwierigkeiten beim Systemwechsel führen wird und somit eines der Hauptargumente gegen die Assemblerprogrammierung darstellt. Kernspeicherbedarf und Laufzeit des Objektprogramms: Wie schon betont wurde, ist bei Programmierung im Assemblercode (und entsprechender Qualität des Programmierstabes!) sowohl eine speicheroptimale wie auch eine zeitoptimale Programmierung möglich. (Die relative Gewichtung dieser konkurrierenden Zielsetzungen stellt ein Entscheidungsproblem für sich dar. Sie bleibt im allgemeinen dem Chefprogrammierer überlassen.) Falsch eingeschätzt werden jedoch in vielen Fällen Ausmaß und Bedeutung der mit der Assemblerprogrammierung verbun38

Diese „Kriterien" beziehen sich sowohl auf den Vergleich zwischen Assembler und Compiler allgemein wie auch auf den Vergleich verschiedener Sprachen innerhalb dieser Gruppen.

2.2 Entwicklung der Entscheidungsalternativen

61 39

denen Vorteile, sowie die starke Abhängigkeit von der Qmliflkation des Personals . Überdies wird durch die Weiterentwicklung der Compiler, die in zunehmendem Maße optimierende Elemente enthalten, die Effizienz der auf automatischem Wege erzeugten Objektcodes ständig verbessert, so daß diesbezügliche Unterschiede allmählich an Bedeutung verlieren dürften. Zahl der „unterstützten" Eingabe-¡Ausgabe-Einheiten: Während bisher bei Verwendung von COBOL oder FORTRAN nur ein Teil der Konfiguration angesprochen werden konnte, ist die neue problemorientierte Sprache PL/1 hinsichtlich der Zugänglichkeit dem Assembler praktisch ebenbürtig. Erlernbarkeit: Wegen des kleineren Vokabulars, das überdies problemnah und an die Begriffswelt des Benutzers weitgehend angepaßt ist sowie wegen der Möglichkeit, die Sprache stufenweise zu erlernen, steht das Arbeiten mit Compilersprachen einem weiten Personenkreis offen. Als besonders vorteilhaft erscheint, daß Problemanalyse, Lösungskonzeption, Programmierung und Auswertung ohne weiteres von ein und derselben Person durchgeführt werden können. Das hierdurch bedingte Wegfallen von Kommunikationsschwierigkeiten und die Verringerung der reinen EDV-Personalkosten sollten nicht unterschätzt werden! Die Programmierung in Assembler setzt demgegenüber detaillierte Maschinenkenntnisse voraus und stellt generell ungleich höhere Anforderungen an Konzentrationsvermögen und Abstraktionsfähigkeit. Zeitlicher Aufwand der Programmierung: Die Bedeutung dieses Gesichtspunktes wird je nach der durch das Programm verursachten Maschinenbelastung, nach Lebensdauer und Benutzungsfrequenz schwanken, jedoch angesichts der Knappheit an Programmierkapazität nie vernachlässigt werden dürfen. Der Zeitbedarf für die Programmerstellung und damit die Kosten der Programmierung sind bei Verwendung des Assemblers verständlicherweise wesentlich höher. Neben Gründen, die bereits angeführt wurden, ist dieser Mehraufwand auch bedingt durch die größeren Schwierigkeiten bei der Fehlersuche (Testphase). Ähnliches gilt für den Aufwand der Programm wartung. Nach Fischer [861 ist durch den Übergang zur problemorientierten Programmierung eine annähernde Verdopplung der Produktivität der Programmierungsgruppe zu erwarten! Dokumentation: Auch in dieser Hinsicht ist die Verwendung von Compilersprachen äußerst vorteilhaft. Vor allem für COBOL gilt, daß sich wegen der guten Lesbarkeit des Programms eine separate Dokumentation weitgehend erübrigt.

39

Die Schwierigkeit und Unübersichtlichkeit der Assemblersprache kann sehr wohl dazu fuhren, daß Möglichkeiten der Optimierung nicht erkannt und ausgeschöpft werden. Ein gut geschriebenes COBOL-Programm ist in den meisten Fällen besser als ein nur mäßig geschriebenes (und dabei teureres) Assemblerprogramm! Über die praktische Bedeutung der prinzipiell gegebenen unterschiedlichen Optimierungsmöglichkeiten sagt Fischer [861: „Die Praxis zeigt, daß das Mehr an Kernspeicherkapazität — ausschließlich des Kernspeicherbedarfs für das Betriebssystem - und der zeitliche Mehrbedarf für einen Programmlauf meistens im Bereich von 20% gehalten werden kann. Es brauchen nicht 100% zu sein, weil ein in einer problemorientierten Programmiersprache (außer RPG) geschriebenes Programm durch Verwendung besonderer Techniken (z.B. geschickte Wahl der Befehle und zweckmäßige Datenbeschreibung) optimalisiert werden kann . . . "

62

2. Das EDV-Planungsproblem

Nicht selten wird es günstig sein, für ein und dieselbe Anlage mehrere Compiler nebeneinander zu benutzen. Im Verlauf der Programmierung wird man vor allem auf die schnelle Auffindung von Fehlern sowie eventuell auf kurze Übersetzungszeiten Wert legen. Das endgültige, von Fehlern bereinigte Quellenprogramm wird dann mit einem zweiten Compiler, dessen Hauptmerkmal die Erzeugung besonders effizienter Objektcodes ist, nochmals übersetzt. Die Übersetzer FORTRANE und FORTRAN-H mögen als Beispiel für eine solche Kombination angeführt werden. Neben den erwähnten universell einsetzbaren Sprachen existiert noch ein umfangreiches Aigebot an SpezialSprachen, die auf eine bestimmte Artwendung (oder eine Gruppe von Anwendungen) zugeschnitten sind und somit nach unserer Definition nur noch mit Einschränkungen dem Softwarebereich zugerechnet werden können. Eine kurze und notwendigerweise etwas willkürliche Auswahl möge deshalb hier genügen: -

-

RPG war ursprünglich eine Sprache, die zur vereinfachten Erstellung von Listen (Reports) diente. Im Laufe der Zeit wurde RPG jedoch weiterentwickelt und steht heute auf der Grenze zwischen Universal- und SpezialSprachen. Neben der Einfachheit der Handhabung ist besonders der geringe Kernspeicherbedarf hervorzuheben. GPSS, SIMSCRIPT, SIAM, DYNAMO, CSMP, ANAGOL sind Simulationssprachen DETAB ist ein Übersetzer für sog. Entscheidungstabellen MATLAN ist besonders auf das Rechnen mit Matrizen zugeschnitten APL und QUICKTRAN sind Sprachen für mathematisch-technisch orientierte Dialogsysteme GIS, ANIS, GOLEM, IMS erleichtern den Aufbau von „Datenbanken"

Neben den unbestreibaren Vorteilen, welche die genannten Sprachen oder Programmiersysteme im Einzelfall zu bieten vermögen, sollte jedoch auch der globale Gesichtspunkt der Vereinheitlichung und Standardisierung starke Beachtung finden. Die Zahl der in einem Unternehmen verwendeten Programmiersprachen wird dadurch praktisch immer auf einige wenige begrenzt bleiben. Zum Abschluß dieser Ausführungen über die Auswahl von Compilern bzw. Assemblern sollen noch einige Bemerkungen über die technischen Anforderungen der Sprachen an das System selbst gemacht werden. Hierzu gehört neben der Übersetzungszeit vor allem die erforderliche Mindestkonfiguration. Insbesondere ist es der Bedarf an Kernspeicherkapazität, der häufig von vornherein zur Ablehnung einer bestimmten Sprache (oder zum Ausweichen auf eine nur „rudimentäre" Version), führt. In der vorliegenden Arbeit wird hierzu der Standpunkt vertreten, daß Vorentscheidungen über Kernspeichergröße etc. in dieser Phase einer Sichtung der Alternativen möglichst vermieden werden sollten. Es ist klar, daß es sich hierbei um eine Frage der Aufgeschlossenheit der Unternehmensleitung und ihrer Einstellung zur Systemplanung handelt. Nur wenn diese Planung als Ganzes vom Beginn der Vorüberlegungen bis zum Vertragsabschluß und darüber hinaus (Kontrollfunktion)

2.2 Entwicklung der Entscheidungsalternativen

63

in der Verantwortung des Top-Managements bleibt, anstatt an rein technisch orientierte Experten delegiert zu werden, wird die sachfremde Setzung mehr oder weniger willkürlicher Budgetrestriktionen vermieden [106]. Die optimalen Aufwendungen für die EDV müssen sich als Resultat der Planung ergeben — sie dürfen nicht als Prämisse an den Anfang des Entscheidungsprozesses gestellt werden! In dieser Sicht sind also Laufzeit, Speicherbedarf u.ä. als Parameter („technischer Input") zu betrachten, die ebenso wie der ,.monetäre Input" (z.B. Kaufpreis des Compilers) zunächst vorurteilslos in ein Entscheidungsmodell eingesetzt werden sollten. Erst im Zusammenspiel mit den übrigen Bereichen des Entscheidungsfeldes (Hardware, Anwendungsprojekte) kann sich die optimale Lösung ergeben.

c) Dienstprogramme und Programmbibliotheken: Bei den Dienstprogrammen handelt es sich um Hilfen für nicht anwendungsspezifische Aktivitäten, die im Zusammenhang mit der laufenden „Produktion" (im Gegensatz zur Übersetzung = „Compilation") auftreten können. Am wichtigsten sind vielleicht die Vorgänge Sortieren [90] und Mischen, für die heute alle Hersteller ausgereifte Programme bzw. Programmgeneratoren genau spezifizierter Leistung zur Verfugung stellen. Daneben gibt es Umsetzprogramme, die - bei minimaler Beeinträchtigung der eigentlichen Verarbeitung — Dateien duplizieren oder von einem Datenträger auf einen anderen übertragen. Programmbibliotheken enthalten sowohl anwendungsspezifische wie generell einsetzbare Unterprogramme (Subroutinen). Vor einer Überbewertung dieser Leistung des Computerherstellers muß gewarnt werden: Einerseits sind nur solche Routinen von Wert, die später wirklich gebraucht werden und deren Eigenerstellung einen merklichen Aufwand verursachen würde. Zum anderen läßt der Umfang des betreffenden Softwarekomplexes noch keinerlei Schlüsse auf dessen Qualität zu! Die angebotenen Routinen enthalten nicht selten Fehler oder sind auf der speziellen im Haus installierten Konfiguration nicht verwendbar. Bibliotheksverwaltungsprogramme erlauben es schließlich, eigene Programme in die Bibliothek aufzunehmen, andere zu löschen, die Bibliothek von Zeit zu Zeit zu komprimieren u.a.m. Auch hier treten nicht selten unerwartete Schwierigkeiten auf, so daß der Weg der Eigenprogrammierung durchaus interessant erscheint.

d) Konversionsprogramme: Im Zusammenhang mit dem Problemkreis „Assembler oder Compiler" wurde bereits daraufhingewiesen, daß trotz der in der Natur der Sache begründeten Maschinengebundenheit der Assemblerprogramme der Übergang auf eine Maschine eines anderen Typs oder Herstellers, ja sogar einer anderen Generation ohne Neuprogrammierung grundsätzlich möglich ist. Hierfür stehen sogenannte Simulato-

64

2. Das EDV-Planungsproblem

ren zur Verfügung, die wegen ihres Komforts und ihrer Sicherheit (Vermeidung von Fehlern durch Umprogrammierung) von einer großen Zahl von Anwendern gerne benutzt werden. 40 Die damit verbundene Ineffizienz des Maschineneinsatzes scheint allerdings nicht immer voll erkannt zu werden. Wenn beispielsweise Grosch über den Emulatorbetrieb in den USA feststellt, daß dabei in schlimmen Fällen nur 10% (!) der möglichen Maschinenleistung aktiviert werden [29, S. 22; 254], so ist kaum vorstellbar, daß diese Einbuße an Produktivität vom Anwender bewußt in Kauf genommen wurde. Eine Umstellung aufgrund „verbesserter Preis-Leistungs-Verhältnisse" wird unter solchen Umständen zur Farce! Die Abwägung von Vor- und Nachteilen bei der Übernahme vorhandener Maschinenprogramme darf wiederum weder intuitiv erfolgen noch von den übrigen SubEntscheidungsproblemen des Systemplanungsprozesses isoliert werden. 2.2.2.3 Datenverarbeitung außer Haus (DVaH). Kooperative Nutzung einer bereits existierenden Anlage. Gemischte Lösungen Neben den besprochenen, für eigene Systeme in Frage kommenden Hardware-/ Software-Alternativen darf nicht vergessen werden, daß durch das ständig wachsende Dienstleistungsangebot herstellerabhängiger oder unabhängiger Rechenzentren der betrieblichen Datenverarbeitung eine ganze Reihe weiterer interessanter Lösungswege erschlossen werden. Ähnliches gilt auch für die Beteiligung an einem bereits existenten Gemeinschaftsrechenzentrum41. Es muß jedoch davor gewarnt werden, die Inanspruchnahme eines Service-Rechenzentrums als eine allzu bequeme Lösung anzusehen, die dem Benutzer zwar sämtliche Vorteile der Elektronik verschafft, ihn aber diesbezüglicher Sorgen gänzlich enthebt. Eine derartige Einstellung erscheint aus den verschiedensten Gründen als gefährlich. Selbst wenn das Unternehmen gewillt wäre, die aus mangelnder Sachkenntnis resultierende starke Abhängigkeit in Kauf zu nehmen, so würden doch Kommunikationsschwierigkeiten und Betriebsfremdheit des Partners eine wirksame Nutzung des Computerpotentials auf breiter Basis kaum erwarten lassen. Wie beim Fremdbezug materieller Teil- oder Zwischenprodukte, so gilt auch hier, 40

Die entsprechenden Einrichtungen werden auch in fest verdrahteter Form, also als Hardware-Elemente, angeboten. Man spricht dann von Emulatoren oder Verträglichkeit. Gerade an dieser Stelle wird sehr deutlich, daß die scheinbar so klare Grenzziehung zwischen Hardware und Software mehr und mehr verlorengeht. - Zu den Vor- und Nachteilen dieser Elemente vgl. auch [2121.

41

Soll das Gemeinschaftsrechenzentrum erst geplant werden, so besteht in rein technischer Hinsicht kein prinzipieller Unterschied zur bereits diskutierten Planung einer eigenen Anlage.

2.2 Entwicklung der Entscheidungsalternativen

65

daß sich zwar technische Abläufe außer Haus durchfuhren lassen, eine Delegation der damit verbundenen Planungs- und Entscheidungsprozesse jedoch grundsätzlich nicht möglich ist [150; 197], Darüber hinaus sprechen eine Reihe organisatorischer Gesichtspunkte und Sicherheitsüberlegungen dafür, auch die Erfassung der Daten prinzipiell im eigenen Hause vorzunehmen. Die entsprechenden Geräte müssen also in jedem Fall gekauft oder angemietet werden. Im Falle des Anschlusses an ein Datenfernverarbeitungssystem (Teleprocessing) sind eine oder mehrere Datenstationen (Terminals) erforderlich. Sie werden in den verschiedensten Versionen angeboten — von der einfachen Schreibmaschine über Stationen mit Anschlußmöglichkeit für Lochstreifen-, Lochkarten- oder Bandgeräte und Schnelldrucker bis hin zu vollwertigen Rechenanlagen, die mit dem Rechenzentrum gekoppelt sind und als „intelligente Terminals" mit diesem Daten austauschen. Diese zuletzt genannte Lösung, bei der ein im Hause installierter (Klein-)Computer die Daten für die Verarbeitung im Zentrum aufbereitet, stellt bereits den Übergang zu den gemischten Systemen dar. Es ist an sich selbstverständlich — obwohl diese Tatsache weder in der Werbung der EDV-Industrie noch in einschlägigen Publikationen immer klar zum Ausdruck kommt — daß „Eigene Datenverarbeitung" und „Datenverarbeitung außer Haus" einander keineswegs ausschließen müssen. Beide Wege können sich vielmehr in sehr fruchtbarer Weise gegenseitig ergänzen. 42 Folgende Möglichkeiten erscheinen uns in diesem Zusammenhang besonders interessant: a) Zusätzlich zur eigenen Anlage, die allein für kommerzielle Zwecke eingesetzt wird, schließt sich die Firma an ein Time-Sharing-System an, um ihren Ingenieuren und Wissenschaftlern einen bequemen und ungestörten Zugang zur EDV zu eröffnen. (Ein Time-Sharing-System ist eine Großrechenanlage, deren Betriebssystem es einer Vielzahl von Benutzern ermöglicht, „quasigleichzeitig" mit dem System zu arbeiten). b) Selten auftretende Spezialanwendungen, die besondere technische Anforderungen stellen, z.B. lineare Programmierung, werden auf einer fremden größeren Anlage gerechnet. c) Bei Spitzenbelastung wird ein Teil der Arbeiten außer Haus abgewickelt. d) Ein erst in Planung befindliches System wird über Datenfernverarbeitung „simuliert". Ein solcher Service bedeutet eine höchst wertvolle Unterstützung 42

Hier läßt sich wieder eine Analogie zum Produktionsbereich konstruieren: Der angesprochene Problemkreis besitzt eine Struktur, die mit dem Fragenkomplex „Optimale Aufteilung der Produktion zwischen Eigenfertigung und Fremdbezug" zahlreiche Gemeinsamkeiten aufweist.

66

2. Das EDV-Planungsproblem

bei der Implementierung. Die Programme sind zum Zeitpunkt der Lieferung bereits weitgehend ausgetestet, so daß die Anlaufzeit auf ein Minimum herabgedrückt werden kann. e) Der Anschluß an das Rechenzentrum erfolgt vor allem im Hinblick auf bestimmte Spezialprogramme (z.B. programmierte Unterweisung) oder Informationsmöglichkeiten (Datenbank). 0 Obwohl bei Unternehmen der hier diskutierten Größenordnung grundsätzlich immer die Installation einer eigenen Anlage — und sei es auch nur eines Kleincomputersystems — in Frage kommt, wird es doch nicht wenige Unternehmensleitungen geben, die ein „allmähliches Hineinwachsen" in die EDV als die beste, weil sicherste Politik ansehen. Der Vielfalt dieser Zielsetzungen und Wünsche entsprechend, steht für die Zukunft ein breites Angebot an Dienstleistungen verschiedenster Rechenzentren zu erwarten. Hierbei stehen dem Kunden im wesentlichen drei Grundtypen von Alternativen zur Verfügung: Im einfachsten Fall erfolgt der Transport der (möglichst schon in eine maschinell lesbare Form gebrachten) Daten auf herkömmlichem Wege, d.h. durch Boten oder Postversand. Dies dürfte die heute noch verbreitetste Vorgehensweise sein — nicht nur wegen der sehr niedrigen Datenübermittlungskosten, sondern auch wegen der relativ geringen Anforderungen, die an das EDV-Wissen des Benutzers gestellt werden. Nachteile liegen jedoch darin, daß die Organisation derartiger Rechenzentren meist recht starr ist und zwar sowohl hinsichtlich der Terminierung wie auch hinsichtlich der Gestaltung der Ausgabelisten. Der Kunde hat sich im allgemeinen an die verfügbaren Programme anzupassen. Eine zweite Form der Kommunikation ist der sog. off-line-Anschluß. Hierbei steht der Benutzer über eine Stand- oder Wählleitung mit dem Rechenzentrum in Verbindung. Die übermittelten Daten gelangen jedoch nicht unmittelbar in den Rechner, sondern werden auf einem peripheren Speicher gesammelt und erst zu einem geeigneten, primär durch das System bestimmten Zeitpunkt zur Verarbeitung abgerufen. In manchen Fällen sind in Form von „Prioritätsindizes" gewisse Eingriffsmöglichkeiten für den Benutzer vorhanden: je höher die Prioritätsziffer gesetzt wird, desto rascher erfolgt die Bearbeitung, desto höher liegen aber naturgemäß auch die Kosten. Erwähnt sei nur, daß bei off-line-Anschluß sowohl Einwie Mehrprogrammbetrieb (Multiprogramming) in Frage kommt. Für die Wahl des Betriebssystems (auf die jedoch der Benutzer keinen Einfluß hat) ist dabei in erster Linie der Gesichtspunkt einer möglichst hohen Auslastung der Zentraleinheit maßgebend. Durch Erhöhung des Durchsatzes sollen die Kosten pro Arbeitseinheit verringert werden — eine Erwartung, die im übrigen keineswegs immer

2.2 Entwicklung der Entscheidungsalternativen

67

zutrifft, da der erhebliche maschineninterne „Verwaltungsaufwand" in ungünstigen Fällen auch zu einer effektiven Verminderung der Produktivität des Systems führen kann. Die Betriebsweise ist in jedem Fall Stapelverarbeitung. Die zugehörigen Datenstationen (Stapelstationen) sind dementsprechend auf die automatische Übermittlung größerer Datenmengen eingerichtet. Stammdaten und Programme wird man im allgemeinen im Zentrum selbst speichern. Für den Benutzer, der sich mit einem off-line-Anschluß begnügt, ist die interne Verfahrensweise der Installation weitgehend bedeutungslos. Ihn interessiert nur die tatsächliche „turn-around-Zeit", d.h. die Zeit, die von der Eingabe der Daten bis zur Bereitstellung der Ergebnisse verstreicht, sowie die für die Bearbeitung einer bestimmten Aufgabenstellung tatsächlich entstehenden Kosten, die sich aus Übertragungszeit, CPU-Zeit43, externem und internem Speicherbedarf, Kosten für Programmbenützung, „permanente Files" etc. berechnen. Während die eben beschriebene Form der Datenfernverarbeitung auf off-lineBasis in zahlreichen Fällen deutlich nachweisbare wirtschaftliche Vorteile bietet, ist die Sachlage bei der dritten und aufwendigsten Betriebsweise, dem on-lineBetrieb 44 , fast als konträr anzusehen. Bei dieser Form des Anschlusses ist die Datenstation über eine entsprechende Datenübertragungseinheit direkt mit der Datenverarbeitungsanlage verbunden. In der Zentrale wird also kein Datenträger beschrieben. Auch bei der Außenstelle können die Daten ohne Datenträger direkt eingetastet werden. Die Stationen (,.Dialogstationen") sind der menschlichen Arbeitsgeschwindigkeit und Aufnahmefähigkeit angepaßt. Die bereits bezüglich der Stapelverarbeitung mit Multiprogramming-Betrieb geäußerten Bedenken sind an dieser Stelle in erhöhtem Maße aktuell. Der bestechende Komfort neu eröffneter und geplanter Time-Sharing-Dienste, insbesondere der praktisch jederzeit mögliche Zugriff zur Zentraleinheit ohne fühlbare Störung durch die Mitbenutzer, können und dürfen nicht per se als Entscheidungsgrundlage dienen. Der „Dialog mit dem Rechner" wird zu einem teuren „Spiel mit dem Rechner", wenn nicht aufgrund einer Anwendungsanalyse feststeht, daß mit der jederzeitigen Verfügbarkeit und schnellen Reaktion des Großsystems echte ökonomische Vorteile verbunden sind! 43

CPU = central processing unit = Zentraleinheit.

44

Die Begriffe „Datenfernverarbeitung" oder „Teleprocessing" umfassen beide Anschlußaiten. Der häufig verwendete Begriff "Time-Sharing" (auch „Dialogsystem" oder „System mit Vielfachzugriff") ist dagegen im wesentlichen mit dem Begriff "on-line" identisch. Eine Präzisierung dieser termini technici würde ein sehr viel weitergehendes Eingehen auf technische Details erfordern und soll deshalb hier nicht versucht werden. Sie wäre darüber hinaus auch in keiner Weise allgemeingültig, da gerade auf diesem Gebiet eine verbindliche Terminologie noch nicht existiert.

68

2. Das EDV-Planungsproblem

Der Kunde, der sich dieser modernsten technischen Möglichkeiten bedienen will, muß sich darüber im klaren sein, daß bei der Komplexität eines EDV-Systems mit mehreren Dutzend bis mehreren Hundert angeschlossenen Terminals der Anteil an unproduktiver Verwaltungs-(overhead-)Zeit sowie die Zahl der Übertragungsoperationen zwischen Kernspeicher und Externspeicher in einem Maße zunehmen, das zwangsläufig zu einer Verteuerung gegenüber vergleichbaren Systemen mit einfacherem Betriebssystem führt [254, S. 46]. Der im Einzelfall gebotene Service (Sprachen, Antwortzeiten, maximale Programmlängen u.ä.) variiert stark und soll hier nicht ausfuhrlicher dargestellt werden. Besonders zu achten ist auf die tatsächliche Einhaltung der spezifizierten Reaktionszeiten, sowie auf die sich effektiv ergebenden Anschlußzeiten. (Vgl. 4.1.4). Schließlich darf nicht vergessen werden, daß Voraussetzung für die on-line-Kommunikation mit einem externen Rechenzentrum das Vorhandensein fest geschalteter (gemieteter) Leistungen ist. Allein hierfür können erhebliche Aufwendungen entstehen. 45 Im übrigen wird es sich bei der Diskussion des Anschlusses an ein Rechenzentrum mit on-line-Betrieb praktisch immer darum handeln, eine Ergänzung zur eigenen Datenverarbeitungsanlage zu schaffen. Hierbei interessiert vor allem der Fall, daß zwischen beiden Systemkomplexen enge Querverbindungen bestehen, mit anderen Worten, daß ein „gemischtes System" zu planen ist. Auch hier gilt — ungeachtet der angeführten Gesichtspunkte — wiederum, daß die Zuhilfenahme von Entscheidungsmodellen eine systematische Berücksichtigung und Abwägung sämtlicher die Entscheidung tangierender Fakten und Zusammenhänge wesentlich erleichtern dürfte. Zum Abschluß dieser Ausfuhrungen über Datenfernverarbeitung erscheint es angebracht, auch den bereits kurz angesprochenen Fragenkomplex der optimalen Wahl des Übertragungssystems wenigstens in groben Zügen zu umreißen. Fragen der Leitungswahl treten auch beim Entwurf größerer eigener Systeme mit geographisch gestreuter Rechenkapazität oder dezentraler Datenerfassung in weit entfernten Außenstellen auf. Während jedoch in derartigen Situationen auch die optimale Struktur des Netzes zu planen ist (eine Problematik, die in den Bereich der Graphentheorie gehört) [79], geht es bei der Datenübertragung zwischen Kunde und Rechenzentrum um eine sehr viel begrenztere Menge von Alternativen. Die verschiedenen Leitungstypen, die zur Zeit von der Bundespost für die Übertragung von Daten bereitgestellt werden, sind in Tab. 3 schematisch dargestellt.

45

Die monatliche Miete einer 4-Draht-Telefonleitung mit einer Übertragungsrate von 2400 Baud beträgt (bei Entfernungen über 75 km) beispielsweise DM 20.60/km. Die entsprechenden Kosten für eine 2-Draht-Telexleitung betragen DM 12,-/km (1970).

2.2 Entwicklung der Entscheidungsalternativen

69

Tab. 3. Übersicht über die Fernmeldewege der DBP (2511. 1 50 bit/s 50 bit/s 100 bit/s 200 bit/s 200 bit/s 200 bit/s 200 bit/s 600/ 1200 bit/s 600/ 1200 bit/s

2

3

4

5 •7 überlassene sx/hx/dx 2 . . . 20 • 10" vom Teilnehmer beigestellte Telegrafenleitungen s Endeinrichtung -6 öffentliches sx/hx 1 . ., . 1 0 • 10" vom Teilnehmer beigestellte Telexnetz s Endeinrichtung -7 überlassene sx/dx 1 . ... 10 • 10' vom Teilnehmer beigestellte Telegrafenleitungen s Endeinrichtung -7 überlassene sx/dx 1 . ., . 10 • 10' vom Teilnehmer beigestellte Telegrafenleitung s Endeinrichtung -6 öffentliches sx/dx posteigenes Fernschalt! . . .. 8 • 10' Datexnetz s gerät überlassene sx/dx 1 . .,. 1 0 • 10"-7 vom Teilnehmer beigestellter Fernsprechleitungen s Modem -6 posteigener Modem öffentliches sx/dx 2 ... . 1 0 • 10' Fernsprechwählnetz s/p -S posteigener Modem öffentliches sx/hx/dx 1 ... . 10 • 10" Fernsprechwählnetz s/p überlassene sx/hx/dx 1 ... . 10 • 10 -6 vom Teilnehmer beigestellter Fernsprechleitungen

Modem sx/hx/dx etwa 10"6

iiber 1200 bit/s

überlassene Fernsprechleitungen

iiber 4800 bit/s

überlassene sx/hx/dx etwa 10"6 Breitbandleitungen s/p

1 2 3 4 5

Übertragungsgeschwindigkeit Art des Fernmeldeweges Übertragungsverfahren Durchschnittliche Bitfehlerwahrscheinlichkeit Leitungsabschluß

vom Teilnehmer beigestellter Modem posteigener Leitungsabschluß; vom Teilnehmer beigestellte Einrichtungen Erklärung zu 3: sx: Simplex hx:Halbduplex dx: Duplex s: seriell p: parallel

2.2.2.4 Anzahl der technischen Alternativen Für die Gegenüberstellung von herkömmlichen Methoden der Systemplanung und Modelltechnik erscheint eine Aussage über die Menge der überhaupt diskutablen Alternativen als interessant. Wenn, wie von Praktikern gelegentlich geäußert wird, ein beinahe zwangsläufiger Weg von den spezifischen Anforderungen des Kunden zur optimalen Konfiguration fuhrt oder wenn die Menge der möglichen Systeme jedenfalls die Größenordnung von 10 nicht übersteigt, so wären die bisher gemachten Aussagen über die Vorteile von Entscheidungsmodellen für diesen Problemkreis weitgehend hinfällig.

70

2. Das EDV-Planungsproblem

Wegen der Bedeutung dieses Punktes sei deshalb das Wagnis einer Abschätzung der Alternativenzahl übernommen — ein Wagnis deshalb, weil dem Verfasser weder eigene diesbezügliche Erfahrungen zur Verfugung stehen, noch ihm eine Publikation bekannt ist, die explizit auf derartige Fragen eingeht. (Man darf wohl vermuten, daß zwischen dieser Tatsache und der Eigenart des Systemplanungsprozesses ein gewisser Zusammenhang besteht.) Zunächst ist die Fragestellung zu präzisieren: Die Zahl möglicher technischer Lösungen (Hard- und Software) hängt zunächst einmal beträchtlich davon ab, welcher Feinheitsgrad der Untersuchung zugrundegelegt wird und wann dementsprechend zwei Produkte als identisch anzusehen sind. Grundsätzlich sollen zwei technische Alternativen — auch wenn sie von verschiedenen Anbietern stammen — bezüglich des hier vorgeschlagenen Entscheidungsmodells dann als identisch angesehen werden, wenn sie sich weder hinsichtlich der Kosten, noch bezüglich der Leistungsparameter signifikant unterscheiden. Imponderabilien, die unter Umständen deutlich zugunsten einer bestimmten Alternative sprechen, können ex definitione durch ein Modell nicht unterschieden werden! Wann ein „signifikanter Unterschied" vorliegt, hängt einerseits vom relativen Gewicht des betreffenden Kosten- oder Leistungsfaktors, sowie andererseits von der „natürlichen Unscharfe" der betreffenden Information ab. Diese Unschärfe — bedingt zum Teil durch Prognoseschwierigkeiten, zum Teil durch inhärente Schwierigkeiten der Beschreibung — ist naturgemäß bei Produkten aus dem Softwarebereich am deutlichsten spürbar. In diesem Zusammenhang ist auch von wesentlicher Bedeutung, in welchem Planungsstadium die Anwendung des Entscheidungsmodells erfolgt. In einem sehr frühen Planungsstadium ist eine Unterscheidung beispielsweise zwischen verschiedenen Versionen eines Plattenspeichers weder sinnvoll noch notwendig. Sie wäre nicht sinnvoll, da bezüglich der noch sehr groben und unsicheren Daten die Unterschiede zwischen zwei sehr ähnlichen Versionen eines Gerätes kaum als signifikant angesehen werden können. Sie ist aber auch nicht notwendig, da weder Lieferzeiten noch sonstige Rückwirkungen auf den Planungsprozeß die Diskussion derartiger Details erfordern. Wie in Kap. 5. näher ausgeführt werden soll, ist in der vorliegenden Studie keineswegs nur an eine einmalige Anwendung des Modells gedacht. Es soll vielmehr dem Anwachsen der Information im Verlauf des Planungs- und Entscheidungsprozesses durch stufenweise Verfeinerung des Modells, verbunden mit entsprechenden Änderungen des „Alternativenrasters" Rechnung getragen werden.

2.2 Entwicklung der Entscheidungsalternativen

71

Dies bedeutet, daß die Zahl technischer Möglichkeiten (zu denen auch die Software-Alternativen zählen!) durch zwei gegenläufige zeitliche Einflüsse bestimmt und modifiziert wird: Eine Zunahme der Alternativen wird bewirkt durch Verfeinerung der Planung sowie durch das sich ständig erweiternde Angebot auf dem Hardund Softwaremarkt. Eine Reduktion wird bewirkt durch Entscheidungsakte, die aus zwingenden Gründen bereits während des Prozesses erfolgen müssen. Typisch dafür ist die Wahl des Herstellers, die nicht zuletzt wegen der bei der Zentraleinheit erheblichen Lieferzeit schon zu einem relativ frühen Zeitpunkt erfolgen muß. Weiter gilt, daß die Systemauswahl umso mehr zu einem kombinatorischen Problem wird, je anspruchsvoller die ins Auge gefaßte Konzeption ist. Obwohl, wie mehrfach betont, dieses Anspruchsniveau (insbesondere bestimmt durch den Mietwert der Zentraleinheit) nicht durch a priori-Entscheidungen fixiert werden sollte, läßt sich doch auch ohne Heranziehung der mathematischen Programmierung allein aufgrund der Betriebsgröße der Lösungsspielraum etwas einengen. Anhand der Serie /360 konkretisiert, heißt das, daß anstelle einer scharfen Budgetgrenze, die beispielsweise maximal ein Modell 40 mit 256 K zulassen würde, auch versuchsweise höhere Modelle wie 50 oder gar 65 in Verbindungen mit entsprechenden Anwendungen ins Auge gefaßt werden sollten. Falls der aus den Projekten zu erwartende Gewinn die Anschaffung dieser teuren Modelle nicht rechtfertigt, wird die Optimierung dieser Tatsache automatisch Rechnung tragen. Dessenungeachtet existiert praktisch immer eine Obergrenze (im Beispiel vielleicht Mod. 75), bei der Datenbeschaffung und Optimierungsaufwand mit Sicherheit sinnlos werden. Das zu untersuchende Hardwarespektrum würde im fraglichen Fall, sieht man von einer möglichen Verkleinerung durch Zusammenarbeit mit einem fremden Rechenzentrum ab, also die Zentraleinheiten 40, 50 und 65 umfassen. Bezüglich der Zeitabhängigkeit kann man vermuten, daß die Zahl möglicher Konfigurationen bzw. Systeme zu dem Zeitpunkt ein Maximum annimmt, zu dem man sich für einen bestimmten Hersteller zu entscheiden hat. Eine Einengung des Lösungsspielraums durch Vorentscheidungen ist bis zu diesem Zeitpunkt nicht zwingend erforderlich. Die starke Einengung, die sich dann aufgrund der Herstellerwahl ergibt, bezieht sich im übrigen auf die heute noch gegebene Marktsituation: durch zunehmende organisatorische und technische Verträglichkeit zwischen Produkten verschiedener Hersteller könnten wesentliche Veränderungen in Richtung auf eine Erhöhung der Alternativenzahl eintreten. 46 46

Ein Beispiel für eine Vergrößerung der Alternativenzahl durch Kompatibilitätsmaßnahmen innerhalb der Hardwarepalette eines Herstellers sind die neuen Systeme 3 und /370, die beide mit der Serie /360 weitgehend verträglich sind.

72

2. Das EDV-Planungsproblem

Für die im Beispiel gewählte Betriebsgröße und für den Zeitpunkt, zu dem spätestens die Festlegung auf einen einzigen Anbieter notwendig wird, existiert nach Meinung des Verfassers ein Spielraum von 20—40 Alternativen (einschließlich Software) pro Hersteller, also etwa 80—160 Alternativen insgesamt. Bedenkt man, daß zu diesem Zeitpunkt auch die Datenerfassung wenigstens in den Grundzügen zu diskutieren ist, so erscheint diese Zahl kaum als zu hoch angesetzt. 4 7 Hält man sich vor Augen, welche Schwierigkeiten in der Praxis bereits mit der Prüfung und Bewertung einiger weniger Systeme verbunden sind 4 8 , so wird klar, daß eine Ausschöpfung des Lösungsspektrums auf dem Wege der Enumeration aus Kostengründen ausscheidet. Hinzu kommt, daß die Methode einen fixen Anwendungskatalog voraussetzt, also noch keine Optimierung der Anwendungen zuläßt!

2.2.3 Organisatorische und Programmierungsalternativen Wie erinnerlich, werden die Bereiche 2.2.1 (Projektwahl) und 2.2.2 (Technische Alternativen) in der vorliegenden Arbeit nicht als gleichberechtigt nebeneinanderstehend betrachtet. Es wird vielmehr der Standpunkt vertreten, daß die Anwendungsoptimierung bei der Planung eines EDV-Systems wegen der engen Beziehung zwischen EDV-Projekten und Unternehmenszielen unbedingt im Vordergrund stehen sollte. Konfiguration, Betriebssystem, etc. spielen demgegenüber nur die Rolle von technischen Ressourcen, die jedoch nicht als fest vorgegeben angesehen werden, sondern vielmehr an das jeweilige Bündel von Anwendungen anzupassen sind. Jede in den Alternativenbereich des Entscheidungsmodells fallende Projekt- oder Anwendungskombination „erzeugt" gewissermaßen die hierfür nötige Hardware/Software-Kombination automatisch (vgl. 3.2.1.1) 49 . In diesem Sinne könnte man von einer „simultanen Kapazitäts- und Produktionsplanung für den Informationssektor der Unternehmung" sprechen. Die in 2.2.1 dargelegten Alternativen sind jedoch im allgemeinen noch zu grob, um als Basis für eine umfassende Systemplanung dienen zu können. 47

In dieser Zahl sind jedoch die Alternativen bei der Festlegung eines Anwendungskataloges noch nicht erfaßt. Interessant erscheint in diesem Zusammenhang eine Bemerkung Diebolds, in der sogar von "myriad configuration possibilities" die Rede ist [66]. Futh spricht von 3 bis 6 EDV-Systemen, die normalerweise in die engere Wahl gezogen werden [96, S. 681.

49

Zur Präzisierung sei jedoch angemerkt, daß wegen der immer vorhandenen technischen Alternativen bereits bei Vorgabe eines Aufgabenkomplexes eine Optimierung erforderlich ist.

73

2.2 Entwicklung der Entscheidungsalternativen

Um dies zu erläutern sei daran erinnert, daß das Ziel dieser Planung die Maximierung der Differenz zwischen "Output" (Wert oder Ertrag des Anwendungspakets) und "Input" (monetäre und technische Ressourcen) sein sollte. Für beide Effekte gilt nun aber, daß die bloße Information über die Komponenten des Pakets, d.h. also über die tatsächlich durchzuführenden Anwendungen, noch nicht genügen würde, um die fraglichen Terme hinreichend exakt zu definieren. Die strategischen JA/NEIN-Entscheidungen sind vielmehr im Falle der (gedanklichen) Durchführung durch eine Reihe weiterer Entscheidungen taktischen Charakters zu ergänzen. Dementsprechend enthält die Zielfunktion unseres Entscheidungsproblems neben strategischen Entscheidungsvariablen (xj) auch solche taktischer Art (u^): z = f(Xl,. .. , x n ; U ; , . . . wobei

. ..

..

... ; u ^ )

(2.3) z = Zielfunktion = Ertrag eines „Anwendungspakets" — zugehöriger Aufwand 5 0 1 wenn Anwendung j durchgeführt wird

{

0 sonst

• [ 1 wenn ju-te Subalternative der Anwendung j gewählt wird u = i " { 0 sonst j = 1 , . . . ,n; n = 1 , . . . ,mj Hierbei ist eine Elimination der Variablen xj selbstverständlich leicht möglich, erscheint aber aus Gründen der Übersichtlichkeit an dieser Stelle nicht angebracht. Im Falle fixierter Anwendungen (Basisanwendungen) sind es sogar allein die taktischen Freiheitsgrade, die Aufwand und Ertrag bestimmen. 51 Die folgende hierarchisch gegliederte Darstellung der fraglichen Alternativen soll diese Aussagen noch näher erläutern.

50

Es handelt sich selbstverständlich um den gesamten Aufwand, der bei Durchfuhrung der ausgewählten Anwendungen entsteht. Nur ein Teil dieses Aufwandes ist einzelnen Anwendungen zurechenbar.

51

Eine präzisere Fassung der Begriffe „strategisch" und „taktisch" wäre in diesem Zusammenhang zwar wünschenswert, läßt sich aber nur schwer durchführen, da ein fließender Übergang besteht. Der exakte Sachverhalt geht jedoch aus den Ausführungen über Entscheidungsvariable (sieht 3.1) hervor.

74

2. Das EDV-Planungsproblem Anwendung i

Aufspaltung nicht mehr eingezeichnet Belastungs~~

—

~~

~~ ~

alternativen

Abb. 1. Alternativenhierarchie eines Anwendungsprojekts ZU

a)

Die Ebene der Projektalternativen (JA/NEIN) wurde bereits in 2.2.1 diskutiert, zu/3) Organisatorische Alternativen: [238] Die in Phase I (siehe 2.1.1) entwickelten, rein problemorientierten Aufgabenbeschreibungen brauchen keineswegs immer zu einer einzigen Definition der betreffenden Anwendung zu fuhren. Vielmehr können, da Präjudizierungen bezüglich eines bestimmten Maschinentyps oder Verfahrens bewußt vermieden werden, mehrere Wege zur Auswahl stehen. Diese Wege werden im allgemeinen unterschiedliche Anspruchsniveaus repräsentieren. Ein Entscheidungsmodell vom vorliegenden Typ vermag allerdings nur zwischen solchen Konzeptionen eine Auswahl zu treffen, die sich (abgesehen von unterschiedlichen ,,Wert"koeffizienten) in ihren EDV-technischen52 Anforderungen unterscheiden. Organisatorische Alternativen können sich beispielsweise im Zusammenhang mit folgenden Punkten ergeben:

52

Bei größeren Unternehmen wird die Verwendung eines elektronischen Datenverarbeitungssystems (wozu auch die „mittlere Datentechnik" zu rechnen ist) im Grundsatz von vornherein klar sein. Trotzdem kann es auch hier vorkommen, daß für einzelne Anwendungen neben den elektronischen auch konventionelle Organisationskonzepte interessant sind.

2.2 Entwicklung der Entscheidungsalternativen -

75

Grad der Detaillierung, etwa bei der Betriebsabrechnung oder bei Statistiken. Grundzüge der Datenerfassung. Gestaltung des Formular- und Berichtwesens. Frequenz bestimmter Anwendungen (Abrechnungsperiode, Stapelbildung, Echtzeitverarbeitung). Organisation der Rechnungsschreibung (zentral/dezentral, Vor- oder Nachfakturierung). Buchungsverfahren und Kontoformen (z.B. Offene Posten). Art und Umfang der Verschlüsselung. Definition und Gliederung der Dateien (insbesondere Festlegung von Satzlängen). Datensicherung. Ausgestaltung von OR-Modellen (Simulations- oder analytische Modelle unterschiedlicher „Verfeinerung"). Fester oder steuerbarer Informationsfluß (MIS).

Gerade auf dieser Stufe der Entwicklung betriebsorganisatorischer Lösungskonzepte erscheint es bedeutsam, daß eine größere Anzahl interessanter Wege parallel untersucht und weiterentwickelt werden. Nach Ansicht des Verfassers ist es in diesem Stadium noch äußerst problematisch, ganze Lösungsklassen aufgrund von Vorentscheidungen ein fiir allemal aus der Betrachtung auszuschließen. Zwei Extreme sind hierbei zu vermeiden: Die Bevorzugung besonders „moderner" und „interessanter" Konzeptionen unter Vernachlässigung von Kostengesichtspunkten erscheint uns ebenso gefährlich wie eine Überbetonung des Kostenstandpunktes. (Bezüglich des letzteren Punktes sei noch einmal bemerkt, daß explizite Budgetgrenzen möglichst vermieden werden sollten. Der Optimierungsalgorithmus trägt automatisch Sorge dafür, daß die EDV-Kosten in einem akzeptablen Verhältnis zu den erwarteten Erträgen der Anwendungsprojekte stehen und die finanzielle Leistungsfähigkeit des Unternehmens somit nicht überfordert wird). Durch das vorgeschlagene „parallele" Vorgehen wird zudem gewährleistet, daß die „Technik" an den Betrieb angepaßt wird, anstatt daß umgekehrt eine bestimmte EDV-Konzeption die betrieblichen Abläufe determiniert. zui) Zu jeder der in ß) zusammengestellten Modifikationen einer bestimmten Aufgabenstellung sind nun auf der Ebene 7) alternative Grobablaufdiagramme zu entwickeln. Diese Diagramme (General Flowcharts) stellen die Grundzüge der Programmierung für die betreffende Anwendung im Hinblick auf unterschiedliche Konfigurationstypen dar. (Im wesentlichen handelt es sich um Kartensysteme, Bandsysteme, Plattensysteme und gemischte Band/Platten-Systeme). Auch die verschiedenen Möglichkeiten für die Anzahl der wichtigsten Geräte sollten auf dieser Stufe bereits berücksichtigt werden. Die Alternativen der Gruppe 7) sind demnach nicht mehr rein problemorientiert. Flußdiagramme der beschriebenen Art (für das Anwendungsbeispiel Verkaufsabrechnung), die jedoch keineswegs die einzig möglichen Konzeptionen für den jeweiligen Anlagentyp darstellen müssen, werden von Hartmann angegeben [136, S. 212 und 260].

76

2. Das EDV-Planungsproblem

Um die späteren Ausführungen bezüglich der Modellkonstruktion vorzubereiten und um die Vorstellungen des Verfassers von einem effizienteren Planungsinstrument zu konkretisieren, sei an dieser Stelle bereits angedeutet, welche Rolle die entwickelten Grobkonzeptionen im Rahmen unseres Entscheidungsmodells spielen werden. Bei nur 20 Anwendungen — einer Zahl, die bei einer größeren Anlage vielleicht nicht unrealistisch ist — können sehr leicht 40—80 Grobabläufe zur Diskussion stehen. 5 3 Jedes dieser Diagramme enthält unter anderem Informationen darüber, welche Komponenten bzw. Ausbaustufen erforderlich sind. Die entsprechenden Angaben lassen sich durch einen Vektor darstellen, dessen Elemente nur die Werte 0 oder 1 annehmen können. Ein Grundprinzip des Modells besteht nun darin, daß die betreffende Ablaufalternative über ihre spezifischen Anforderungen eine gewisse Minimalkonfiguration „erzeugt". Die bezüglich des Modells optimale Konfiguration ergibt sich dann durch logische Addition („,ODER"-Bedingung) derjenigen Systeme, die den von Null verschiedenen Werten der Entscheidungsvariablen entsprechen (vgl. 3.2.1.1). Die Frage, ob die Kapazität der Anlage zur Bewältigung der ausgewählten Aufgaben auch ausreicht, wird hiervon noch nicht berührt. Für die Überlegungen der Stufe 7) spielt im übrigen der angestrebte Integrationsgrad bereits eine bedeutsame Rolle. 5 4 Je höher die Integration, umso mehr Daten müssen sich gleichzeitig im direkten Zugriff der Zentraleinheit befinden und umso mehr Randomspeicher sind demzufolge erforderlich. Ein besonderes Problem für die Modellierung ergibt sich an dieser Stelle dadurch, daß bei einem integrierten System von einer Additivität der Maschinenbelastungen nicht mehr die Rede sein kann. Die gesamte Belastung durch zwei oder mehr Anwendungen ist im allgemeinen kleiner als die Summe der Einzelbelastungen! Diese Schwierigkeit, die scheinbar die Verwendung eines linearen Modelltyps verbietet, soll später (vgl. 3.1) durch „Herauslösen" der Dateien und Behandlung als ,,Pseudo-An Wendungen" umgangen werden.

zu 5) Die Alternativen der Stufe 5) sollen, wie schon erwähnt, alsProgrammieraltemativen bezeichnet werden. Sie stehen hinsichtlich ihres Detaillierungsgrades zwischen den Grobablaufdiagrammen und den eigentlichen Programmen, sind jedoch nicht identisch mit Feinablaufdiagrammen (Detailed Flow Charts). Während 53

Diese Zahl mag hoch erscheinen, jedoch lassen sich die erforderlichen Untersuchungen und Überlegungen auch beim heute üblichen Vorgehen nicht umgehen. Es wird nur dafür plädiert, diese Analyse zu objektivieren (Verzicht auf Intuition. Bewußtmachung und Dokumentation diesbezüglicher Denkprozesse) und vor allem den Verzicht auf die Weiterverfolgung diskutabler Wege möglichst zu vermeiden.

54

Zum Begriff „Integration" vgl. [238, S. 13-191.

2.2 Entwicklung der Entscheidungsalternativen

77

echte Programme und ebenso detaillierte Flußdiagramme vollständige Abbilder der Problemstellung darstellen müssen, sollen die hier eingeführten Programmieralternativen Programm-Modelle bedeuten, die nur das enthalten, was zu einer Belastungs- und Aufwandsschätzung bei vorgegebenen Genauigkeitsanforderungen notwendig ist. Es erscheint wichtig, zu betonen, daß durch eine Grobkonzeption — insbesondere dann, wenn die genaue Zahl der verschiedenen Geräte noch nicht spezifiziert ist — das Programm selbst noch keineswegs festgelegt ist. Während Gobablaufdiagramme, die sich auf eine bestimmte Anwendung und einen bestimmten Systemtyp beziehen, wohl immer ähnliche Gestalt haben dürften, ist andererseits aus der Praxis bekannt, daß zwischen den entsprechenden Computerprogrammen oft erhebliche Unterschiede bestehen. Ein Grund dafür ist sicher in der Tatsache zu suchen, daß die Zielsetzung bei Programmierungsprojekten selbst schon ein gewisses Problem darstellt. Es existieren mindestens drei konkurrieren-

de Ziele: -

Minimierung der Laufzeit Minimierung der Speicherbelastung 55 Minimierung der Programmierungskosten

Die heutige Systemplanungspraxis bietet unserer Ansicht nach keinerlei systematische Handhabe zur Bewältigung dieser Problematik. Im Entscheidungsmodell erscheint dies jedoch möglich, da operative Alternativen der vorliegenden Art immer in Beziehung zum Oberziel Gewinnmaximierung gesetzt werden. Der Fall mehrerer Zielfunktionen wird hierdurch auf den Fall einer einzigen Zielfunktion zurückgeführt! Es versteht sich nach diesen Feststellungen von selbst, daß nicht jeder denkbare Weg zur Programmierung einer Anwendung eine sinnvolle Entscheidungsalternative repräsentiert. Man wird vielmehr versuchen, „effiziente Programmieralternativen" zu konstruieren. Eine effiziente Alternative ist in der Terminologie der Unternehmensforschung [133, S. 10] eine Alternative, für die die Zielerreichung in einer Richtung (z.B. geringere Laufzeit) nur auf Kosten der verbleibenden Zielrichtungen (also durch größeren Speicherbedarf oder höheren Programmieraufwand) verbessert werden kann. Bedenkt man die mit der Programmiertätigkeit verbundenen Schwierigkeiten und Anforderungen und berücksichtigt man, daß gerade das Auffinden von Optimierungsmöglichkeiten schöpferische Phantasie erfordert, so leuchtet ein, daß eine vollständige Aufzählung sämtlicher effizienten Programmierungsalternativen im allgemeinen kaum vorstellbar ist, zumindest jedoch aus Kostengründen im all-

55

Wahrscheinlich ist darüber hinaus eine Differenzierung nach Arbeitsspeicher und den verschiedenen externen Speichermedien erforderlich.

78

2. Das EDV-Planungsproblem

gemeinen ausscheiden dürfte. Gleichzeitig wird es notwendig sein, den Begriff „effiziente Programmieralternative" durch den Begriff „gute" oder „interessante Programmieralternativen" zu approximieren. Es erscheint jedoch denkbar - und eigene Erfahrungen des Verfassers mit einem kommerziellen Programmierungsproblem scheinen dies zu bestätigen —, daß es in Fällen mäßiger Komplexität möglich ist, alle fraglichen Alternativen in Form von „Untermodellen" zu erfassen. Derartige Modelle könnten unabhängig von dem hier zur Diskussion stehenden Entscheidungsmodell durchgerechnet werden, wodurch sich sowohl „speicheroptimale" wie auch „zeitoptimale" Versionen automatisch generieren ließen. Bezüglich zweier der drei genannten Ziele kommt zu den oben dargestellten Schwierigkeiten noch hinzu, daß neben der Art und Weise der Programmierung, die hier mit dem Symbol 7Tj angedeutet sei, noch das „Datenprofü" di eingeht (di bezeichnet Typus und Umfang des für die zugehörige Anwendung erforderlichen Datenmaterials und ist demnach für sämtliche Programmieralternativen, die zu einer organisatorischen Alternative der Ebene ß) gehören, konstant). Symbolisiert man die jeweilige Konfiguration durch K, so gelten für die Laufzeit tj, die Speicherbelastung Si und den zeitlichen Programmieraufwand tj P der i-ten Programmieralternative die folgenden Beziehungen: ti = fi (ffi, d i( K)

(2-4)

Si = zj, i j unseres Modells unterliegen, zerfallen im wesentlichen in drei druppen M Die erste Gruppe sichert einerseits die Einhaltung der zeitlichen und der Speicherkapazität des Systems; sie stellt aber andererseits zugleich die Übertragung der auf S. 89 in der Sprache der symbolischen Logik formulierten Zusammenhänge auf den algorithmisch besser beherrschbaren 0/1-Formalismus dar. Die Restriktionen der zweiten Gruppe besagen, daß innerhalb einer Anwendungsklasse höchstens ein Modus auszuwählen ist (bei fixierten Anwendungen: genau ein Modus). Die Restriktionen der dritten Gruppe beziehen sich ebenfalls nur auf die u(bzw. v-)Variablen und repräsentieren deren inneren logischen oder organisatorischen Zusammenhang. (Es werden im folgenden zwar alle denkbaren Restriktionen formuliert, jedoch ist bei der praktischen Durchrechnung zu berücksichtigen, daß ein erheblicher Teil davon redundant ist.)

94

3. Lösungsansatz mit Hilfe eines OR-Modells (Ganzzahliges lineares Programm)

3.2.1 Kapazitätsrestriktionen und Systemgenerierung 3.2.1.1 Generierende Restriktionen und Systemelemente In 3.1 wiesen wir daraufhin, daß die dort verwendeten Beziehungen Zi = k; = k J l v k J 2 v . . . v k J L

(3.15)

und Zi = max k J .

(3.16)

M>1

0=1,...,I)

zwar den Mechanismus der Generierung von Systemelementen in mathematisch exakter Weise wiedergeben, daß sich diese Gleichungen jedoch noch nicht zum Aufbau eines operationalen, d.h. der Durchrechnung mittels Algorithmen zugänglichen, Entscheidungsmodells eignen. Eine äquivalente Formulierung, welche dieser Forderung Rechnung trägt, stellt dagegen die folgende Ungleichung dar: n

2 j=i n

2 j =1

m

j

n

m

j

2 gMJ . uMJ + 2 2 gJ . u J + '' i=i m=i " M=i (3.17)

Mj

2 7 ^ + M

2 giK zK < GjZj K=1

0 = 1 , . . . , I)

wobei J 1 gM, •=

1 wenn Systemelement i bei Durchführung der Alternative 10 (u^) erforderlich 0 sonst

-j

_ J

1 wenn Systemelement i bei Durchfuhrung der AI Alternative ( u J ) erforderlich 0 sonst

yi = J M»i |

1 wenn Systemelement i bei Durchführung der Alternative (v-") erforderlich M

0 sonst 10

Wir schreiben (u^), (ü^), (v^), (z K ), da logisch zwischen einer Belastungsalternative (Belastungsmodus) und der zugehörigen Entscheidungsvariablen zu unterscheiden ist.

3.2 Restriktionen g. ^ = J

95 1 wenn Systemelement i Voraussetzung ftir Software-Alternative (z K ) 0 sonst

G, >

maximale Zahl nicht verschwindender Terme der linken Seite (für Gj kann z.B. n + n + r gesetzt werden)

Bevor eine präzise Definition des Begriffs „Systemelement" gegeben wird, sollen zunächst einige wichtige Konsequenzen der betrachteten Beziehungen (3.15) (3.17) untersucht werden. Wir greifen zu diesem Zweck zwei Restriktionen heraus und bezeichnen sie mit i', i". Ebenso sollen zwei Belastungsalternativen ins Auge gefaßt werden, wobei der Einfachheit halber angenommen sei, daß diese zu eigentlichen Anwendungen gehören. Wir bezeichnen sie mit (u J ) ) und (u J 2 ) (Abb. 2).

.1

1

1.rr

1 j, 1 1 UM1 1 I I I I ~i . , 6g •' i Ml,< 1 — — —| I I J 1 I Jl 1 J VI" | I I

1 j2 1 UM2 I I r J. i g 2 .i M2.1 , I l_ 1 J2 g L M2/' I

1 1 I i T . tI _L 1 , I

Pro „Komponente" gibt es so viele Restriktionen für dynamische Speicherung wie echte Anwendungen betrachtet werden. Bei Betriebssystemen mit Simultanverarbeitung, die auf das „Paging-Prinzip" verzichten, bei denen also mehrere Programme in einzelnen Partitions des Kernspeichers warten, bis die CPU sie aktiviert, ist die Situation nicht grundsätzlich anders. Der Überlappungsterm Tj„ ist allerdings kleiner, da nur noch "working files" enthalten sind. Wir wollen nun noch auf die wichtige Frage eingehen, inwieweit die bisherigen Restriktionen hinsichtlich Speicherbedarf auch für Zentraleinheiten Gültigkeit besitzen. Die Belastung des Arbeitsspeichers durch ein Programm ist selbstverständlich im allgemeinen dynamischer Art, da eine permanente Speicherung aus Kostengründen von vornherein ausgeschieden werden kann. Eine Ausnahme bildet das Betriebssystem, dessen Kern sich aus technischen Gründen ständig im Arbeitsspeicher befinden muß, sowie Real-Time-Anwendungen. Zieht man diesen Anteil ab, so ergibt sich analog zu (3.21) die verfugbare Kapazität Sze des Hauptspeichers.

104

3. Lösungsansatz mit Hilfe eines OR-Modells (Ganzzahliges lineares Programm)

Die Zulässigkeit einer Lösung ist nun so lange gewährleistet, als für jede Belastungsalternative gilt (3.24)

Da alle Belastungsalternativen in dem auf S. 77 erläuterten Sinne effizient sind, ist die Feststellung richtig, daß die Laufzeit eines Programms umso kürzer sein wird, je mehr Kernspeicher diesem Programm zur Verfügung steht. Bei sequentieller Datenverarbeitung ist demnach klar, daß die Optimallösung nur solche Belastungsmodi enthält, die den vorhandenen Speicherraum Sze auch weitestgehend ausnutzen. Anders bei Simultanverarbeitung: Unabhängig von der speziellen Konzeption des verwendeten Operating Systems ergibt sich ein gegenläufiger Effekt dadurch, daß die zeitliche Gesamtbelastung umso geringer ist, je mehr Programme bzw. Programm teile sich gleichzeitig im Arbeitsspeicher befinden. Geht man also von der Belastungsalternative mit dem maximal zulässigen Speicherbedarf zu solchen mit geringeren Anforderungen über, so wird sich aufgrund des „Multiprogramming-Effekts" ein gewisser zeitlicher Vorteil ergeben, den wir bei der zugehörigen Zeitschätzung zu erfassen versuchen.

3.2.2 Anwendungsrestriktionen Im Fall des variablen „Informationsoutputs" (Bestimmung der Arbeitslast simultan mit der Konfigurationsoptimierung) ist es im allgemeinen zulässig, daß sämtliche Entscheidungsvariablen, die zu einer bestimmten Anwendung gehören, den Wert Null annehmen. Wir haben nur dafür Sorge zu tragen, daß keine Anwendung mehrfach „bearbeitet" wird. Diesem Zweck dienen Restriktionen der Form m

j

M:

(3.25) 0=1.•••>")

(Man könnte denken, daß der Optimierungsalgorithmus diese Restriktionen automatisch einhält, aber es ist eher das Gegenteil der Fall! Ohne solche Restriktionen werden sich Lösungen ergeben, in denen Projekte mit hohem Ertrag und relativ geringen technischen Anforderungen mehrfach auftreten). Wir haben jedoch schon daraufhingewiesen, daß es in zahlreichen Anwendungsfällen weder möglich noch sinnvoll sein wird, die für eine Optimierung des gesamten Aufgabenkatalogs erforderlichen Daten (insbesondere die Ertragsdaten) vollständig zu beschaffen. In gewissem Grade wird man zu Vorentscheidungen gezwungen sein, indem man etwa eine bestimmte Anwendung gar nicht erst in Be-

105

3.2 Restriktionen

tracht zieht oder - im positiven Fall - ihre Durchführung für jede zulässige Lösung durch Stellung einer entsprechenden Nebenbedingung erzwingt. Ist eine Anwendung in dieser Weise fixiert worden und steht für sie nur noch der Lösungsweg zur Debatte, so bedeutet das, daß genau eine der zugehörigen Entscheidungsvariablen ausgewählt und gleich 1 gesetzt werden muß. Die entsprechende Restriktion lautet also mj

Mj

S uj + —i M

2

Vj = 1

(3.26)

—i M

(j = Index der fixierten Anwendung)

3.2.3 Kopplungsrestriktionen Wie bereits in 3.1 diskutiert, geht es nicht ohne weiteres an, den Gesamtkomplex des Informationsbedarfs in einzelne „Anwendungen" aufzuteilen, über die unabhängige Entscheidungen zu treffen sind. Eine solche Vorgehensweise scheint dem sich immer mehr durchsetzenden Integrationsgedanken zu widersprechen; sie ist aber andererseits die logische Grundlage für die Anwendbarkeit eines kombinatorischen Modells. Betrachten wir jedoch das Prinzip der Integration genauer, so ergibt sich, daß es hauptsächlich gemeinsam benutzte Dateien sind, die Verflechtungen zwischen den Anwendungen schaffen. Solche Dateien lassen sich aber ausklammern und als Pseudoanwendungen getrennt von den eigentlichen Anwendungen (Verarbeitungsprozessen) behandeln. Dabei ist es aus rechentechnischen Gründen vielleicht günstiger, nicht die Speichermöglichkeiten für einzelne "Files" als neue Belastungsmodi einzuführen, sondern vielmehr verschiedene Möglichkeiten für die Datenorganisation als Ganzes. Aus diesem Vorgehen ergibt sich zwingend die Notwendigkeit gewisser Kopplungsrestriktionen. Es ist möglich, durch lineare Restriktionen in den u^, ü^, v j und Z\ zu berück... M MM sichtigen a) daß bestimmte Lösungswege bzw. Belastungsalternativen entweder eine ganz bestimmte Datenorganisation voraussetzen oder aber auf einer größeren Zahl von Datenorganisationen basieren können (vgl. die Restriktionen D O i , . . . , D 0 6 , D0 3 V D0 4 im Zahlenspiel des Anhangs). b) daß auch unter den eigentlichen Anwendungen irgendwelche logischen Verknüpfungen bestehen können (vgl. die Restriktionen Ki - K s im Anhang)

106

3. Lösungsansatz mit Hilfe eines OR-Modells (Ganzzahliges lineares Programm)

c) daß auch Querverbindungen zwischen Anwendungen und Betriebssystemen existieren (auf die entsprechenden Nebenbedingungen wurde bereits bei der Darstellung der generierenden Restriktionen in 3.2.1.1 hingewiesen; es handelt sich jedoch, ihrem wahren Charakter nach, eher um Kopplungsrestriktionen).

4. Modelldaten 4.1 Abschätzung der technischen Koeffizienten (Belastungen) Als eine der Hauptschwierigkeiten einer auf der Verwendung von OR-Modellen basierenden Systemplanung wird von manchen Fachleuten die Schätzung der Koeffizienten des technischen Aufwands, insbesondere die Schätzung der zeitlichen Belastungen b^, l i j bzw. ß^ angesehen [243]. Wir wollen im folgenden Abschnitt ausfuhren, daß wir diese Ansicht nicht völlig teilen, indem wir einerseits eine Zusammenstellung mehr oder weniger bekannter Methoden geben sowie andererseits aufzuzeigen versuchen, daß die Anforderungen an die Genauigkeit der zu bestimmenden Größen kaum prohibitiv für einen sinnvollen Einsatz unseres Modells sein dürften. Den von der Praxis gesetzten Akzenten entsprechend, legen wir dabei das Hauptgewicht auf die Zeitbelastung des Systems.

4.1.1 Schätzmethoden bei sequentieller Verarbeitungsweise Unter sequentieller Verarbeitung sei hier eine Verarbeitungsform verstanden, bei der sich zu einem bestimmten Zeitpunkt im Arbeitsspeicher nur jeweils ein Programm befindet. Überlappungen verschiedener Jobs sind also allenfalls hinsichtlich der „Peripherie" möglich. Die Schätzung von Programmlaufzeiten für sequentielle Verarbeitung ist insofern von grundsätzlicher Bedeutung, als die entsprechenden Gesichtspunkte natürlich auch bei allen anderen Verarbeitungsweisen ins Spiel kommen. Nur werden dort die Verhältnisse dadurch weiter kompliziert, daß einerseits die Bearbeitung eines bestimmten Jobs häufigen (durch die „Umgebung" verursachten und daher unregelmäßigen) Unterbrechungen unterliegt und daß sie andererseits wiederum parallel oder überlappt mit Vorgängen erfolgen kann, die sich auf „konkurrierende" Jobs beziehen [249].Die Verweilzeiten der Programme bei Simultanverarbeitung sind größer als bei sequentieller Verarbeitung; sie sind jedoch für die Schätzung der echten Belastung nur von geringer Bedeutung (vgl. 4.1.2). Für die Abschätzung der „ungestörten" Laufzeit eines Anwendungsprogramms kommen sowohl empirische wie deduktiv fundierte Methoden in Frage. In beiden Fällen kommt ein prognostisches Element ins Spiel, da die Arbeitsdaten (Input) des betreffenden Programms praktisch nie als genau bekannt anzusehen sind. Diese Prognose der zukünftigen Arbeitslast ist natürlich eng mit dem Pro-

108

4. Modelldaten

blem einer Vorhersage der allgemeinen Geschäftsentwicklung verbunden und sollte als eingeständiger Fragenkreis, losgelöst von den spezifisch EDV-technischen Erwägungen, gesehen werden. Im Unterschied zum eigentlichen EDV-Bereich, in dem nach Möglichkeit objektive Schätzverfahren dominieren sollten, kommen hier in starkem Maße subjektive Schätzungen in Frage. Wir werden in 4.2, im Zusammenhang mit der Bestimmung der Aufwands- und Ertragskoeffizienten, kurz auf einige Aspekte dieser Frage zurückkommen. Ein ausfuhrliches Eingehen auf die Vorhersage der zukünftigen Entwicklung der Unternehmung würde jedoch den hier gesetzten Rahmen weit überschreiten. Eine, wie uns scheint wichtige, Folgerung kann bereits hier gezogen werden: Die Genauigkeit im „programmiertechnischen" Teil der Belastungsschätzung hat in vernünftigem Einklang mit der Zuverlässigkeit des zugrundegelegten „Datenprofils" zu stehen. Verzichtet die Unternehmensleitung darauf, aktiv am EDVPlanungsprozeß teilzunehmen und beschränkt sie sich auf Finalentscheidungen, so ist zu befürchten, daß die mit steigenden Anforderungen an die Präzision überproportional anwachsenden Schwierigkeiten der Belastungsschätzung zu weitgehend sinnlosen Aufwendungen führen, die die Zuverlässigkeit der Modellaussagen in keiner Weise erhöhen. Wir wollen uns nun den empirischen Möglichkeiten für eine Belastungsschätzung bei bekanntem Datenprofil zuwenden. Unter „empirisch fundierten Schätzverfahren" seien hier sämtliche Verfahren verstanden, die in irgendeiner Weise auf realen Zeitmessungen beruhen. Es sind sogar Situationen denkbar, in denen die Schätzung der Laufzeit überhaupt durch Messung ersetzt werden kann. Im allgemeinen werden die hierfür erforderlichen Voraussetzungen — Vorhandensein der Konfiguration und des fertigen Programms1 — allerdings nicht erfüllt sein, so daß entweder empirisch gewonnene Laufzeiten durch deduktive Überlegungen zu ergänzen sind oder aber weiteren empirisch fundierten Transformationsregeln2 unterworfen werden müssen. Eine dritte Möglichkeit bietet sich durch Messungen auf äquivalenten Konfigurationen. Sie beruht auf der Tatsache, daß nur ein Bruchteil der Anwendungsprogramme eine bestimmte Konfiguration wirklich voll ausnutzt. Die Laufzeit eines fertigen Programms kann also auf jedem EDV-System gemessen werden, bei dem das relevante oder „angesprochene" Subsystem aus denselben Komponenten besteht, die im zu untersuchenden bzw. geplanten System von diesem Programm benötigt werden. 1

Bei Programmen, die von vornherein für eine Vielzahl von Benutzern konzipiert sind (Modularprogramme), kann man diese Idealbedingungen vielleicht als gegeben ansehen. Der Hersteller wird im allgemeinen in der Lage sein, auf Messungen beruhende Laufzeitschätzungen für alle in Betracht gezogenen Konfigurationen abzugeben. Auch die Zeiterfordernisse von Soitierprogrammen können als gut bekannt angesehen werden.

^

Z. B. Umrechnung im Verhältnis der Mix- oder Throughputkennzahlen.

4.1 Abschätzung der technischen Koeffizienten (Belastungen)

109

Beispiele für Zeitschätzung durch Transformation sind die bereits besprochenen (vgl. 2.1.6), häufig fälschlich als „Kriterien" bezeichneten, Mix- oder Durchsatzrelationen. Über ihre praktische Verwendbarkeit zur Laufzeitschätzung ist dem Verfasser wenig bekannt. Wie wiesen daraufhin, daß die Basis derartiger Verfahren immer ein standardisierter Bedarf ist. Einen gewissen Hinweis auf ihre Problematik gibt vielleicht schon die relativ große Zahl kommerzieller „Mixe", die sich eben in der Definition dieses Standards unterscheiden [218; 309]. Wir vermuten auch, daß die Zuverlässigkeit bei der Schätzung für einzelne Anwendungen, wie sie für die hier vorgesehene Bedarfsoptimierung notwendig ist, merklich geringer sein könnte als bei der Prognose von Gesamtlaufzeiten, da sich bei der letzteren Schwankungen bis zu einem gewissen Grade „herausmitteln". Statistische Untersuchungen über die Zeiterfordernisse von Computeranwendungen in Abhängigkeit von geeigneten Kennzahlen sowohl der Betriebe wie der verwendeten Konfigurationen könnten von größeren EDV-Herstellern ohne weiteres durchgeführt werden. Derartige Analysen könnten dann detailliertere Aussagen über anwendungsspezifische Durchsatzverhältnisse liefern. Darüber hinaus wäre es sogar denkbar, daß — eventuell unter Zuhilfenahme regressionsanalytischer Methoden — aus diesem Material direkte Schlüsse auf die zu erwartenden Laufzeiten selbst gezogen werden können. Obwohl zweifellos die bloße Bestimmung einer empirischen Transformationsfunktion und ihre Anwendung auf existierende Programme, welche die spezifischen Eigenheiten des Betriebes widerspiegeln, grundsätzlich vorzuziehen ist, könnte doch auch das eben angedeutete Verfahren zumindest für die erste Phase der Grobplanung von Interesse sein. Die Prognose von Programm-Laufzeiten allein durch Deduktion setzt praktisch immer das Vorhandensein eines Programm-Modells voraus — eine Möglichkeit, die durchaus auch für die bisher besprochenen empirischen Verfahren in Betracht kommt. Das fertige Computerprogramm ist — sofern es überhaupt schon verfügbar ist — im allgemeinen zu komplex, um für deduktiv-analytische Methoden zugänglich zu sein. Andererseits gilt auch hier wieder, daß die aus einem vergröberten Abbild (Modell) des zu untersuchenden Systems abzuleitenden Aussagen voll ausreichen können, um dieses System hinsichtlich der zu treffenden Entscheidung zu bewerten3. Nicht selten wird dabei der Fall eintreten, daß der bei Vergröberung weggelassene Teil sogar der programmiertechnisch aufwendigere ist (hinsichtlich Programmierungsaufwand und/oder Kernspeicherbedarf), dabei jedoch nur einen geringen Beitrag zur Systemzeit liefert, entweder, weil die CPU-Zeit gegenüber der Ein-/Ausgabe vernachlässigt werden kann oder weil die entsprechenden Im Gegensatz zu den auf S. 78 erwähnten Modellen, die zur Erzeugung effizienter Belastungsmodi dienen sollten (Optimierungsmodelle), handelt es sich hier um reine Bewertungsmodelle ohne freie Parameter. Es ist klar, daß die erstere Modellklasse die Möglichkeiten der zweiten impliziert.

4. Modelldaten

110

Operationen mit den „EngpaßVorgängen" überlappt ablaufen. In derartigen Situationen wird der Vorteil, den die Modelltechnik bietet, besonders augenfällig sein. Das Vorgehen bei der deduktiven Abschätzung der zeitlichen Belastungskoeffizienten kann im folgenden nur angedeutet werden, wenn eine zu weitgehende Erörterung technischer Details vermieden werden soll. Zunächst einmal ist festzustellen, daß eine Engpaßkomponente im strengen Sinne nur selten vorhanden ist, derart, daß es genügen würde, allein die zeitliche Belegung dieser einen Komponente zu berechnen. Meist sind die Verhältnisse wesentlich komplizierter und die Durchlaufzeit ergibt sich - unter Beachtung von Reihenfolgebedingungen — aus den Belastungen mehrerer Komponenten (v.a. Kanäle, Drucker, Zentraleinheit), welche ihrerseits immer nur zu einem bestimmten Prozentsatz der verfügbaren Systemzeit ausgelastet sind (vgl. hierzu Abb. 6). Kanal 1

Lesen

Kanal 1

Schreiben

Kanal 2

Lesen

Kanal 2

Schreiben

Verarbeitung (CPU)

T~ \

—

\

r

— r

\ \

\

\ \

\ \

—j

\ /

/

— r ~ \

\

\ \

\

V-

\

—j

\ /

'

\ \—

\

—-2

\ /

'

^—

\

—3-

r

Abb. 6. Überlapptes Lesen und Schreiben (aus (3261)

Da — sequentielle Verarbeitung vorausgesetzt — die on-line-Komponenten des Systems auch während der Wartezeit nicht für andere Aufgaben frei sind, muß in jeder der zugehörigen Modellrestriktionen die volle Systemzeit als Belastung eingesetzt werden! 4 Für die Bestimmung der Laufzeit ist wesentlich, daß moderne Anlagen in der Regel mit „Kanälen" oder „I/O-Prozessoren" ausgestattet sind, welche in der Lage sind, als kleine „Satellitenrechner" den Datenaustausch zwischen Internspeicher und Peripherie selbständig zu übernehmen. Darüber hinaus arbeiten die meisten Systeme „gepuffert", um der erheblichen Diskrepanz zwischen „internen" und „externen" Arbeitsgeschwindigkeiten Rechnung zu tragen. 4

Wir wollen hier davon absehen, daß auch ohne den Einsatz von Multiprogramming in gewissem Grade Überlappungen zwischen Jobs vorkommen. So kann beispielsweise der Output eines Programmlaufs zunächst auf Band erfolgen. Die eigentliche Ausgabe über den Drucker erfolgt dann parallel mit der Bearbeitung weiterer Jobs. Ähnliches gilt für die Eingabe von Karten oder Lochstreifen sowie für den Datenaustausch zwischen Externspeichern. - Auch die Überlappung von Rüstzeiten ist in diesem Zusammenhang zu erwähnen.

4.1 Abschätzung der technischen Koeffizienten (Belastungen)

111

Zur weitergehenden Illustration von Pufferung und Kanalprinzip sei auf die EDVLiteratur verwiesen [89, S. 295-310; 95], Die eigentliche Laufzeit eines Programms setzt sich bei den von uns betrachteten Anlagen aus folgenden Aktivitäten zusammen: 1. Einlesen von „Datensätzen" (Karten-, Lochstreifen-, Band- oder Platten"records") zunächst in Pufferspeicher. Sind Kanäle vorhanden, so wird die CPU durch den Einlesevorgang praktisch nicht belastet. 2. Interne Verarbeitung: Sie beginnt, sobald die zu Anfang erforderlichen Informationen in den Eingabepuffern verfügbar sind, wird unterbrochen, wenn weitere Daten benötigt werden und endet, wenn das letzte Outputrecord im Ausgabepuffer gespeichert ist. 3. Ausgabe vom Puffer auf ein externes Speichermedium bzw. direkt auf den Drucker. Bei Ein- und Ausgabe ist wesentlich, ob die Sätze „geblockt" oder „ungeblockt" übertragen werden. Wir erinnern daran, daß in unserer Konzeption unterschiedlichen Blockungsfaktoren auch unterschiedliche Programmierungs- bzw. Belastungsalternativen entsprechen sollen. In manchen Fällen wird es schließlich notwendig sein, auch das Einlesen des Programms selbst bei der Ermittlung der Laufzeit in Betracht zu ziehen. Dies gilt vor allem für Systeme mit geringer Kernspeicherkapazität, bei denen besondere Techniken (Segmentierung, overlays) Verwendung finden. Wir sind der Auffassung, daß eine befriedigende Berücksichtigung aller hier genannten und relevanten Faktoren bzw. Vorgänge im konkreten Einzelfall bei vertretbarem Aufwand „von Hand" durchgeführt werden kann und bei zahlreichen Systemplanungen (wenigstens für die wichtigsten Programme) auch tatsächlich durchgeführt wird. Beispiele für deduktive Zeitschätzungen unter relativ einfachen Verhältnissen finden sich bei Hartmann [136] und Futh [96]. Sehr viel kompliziertere Situationen, bei denen Such- und Umordnungsvorgänge im Vordergrund stehen, behandeln Wedekind [326] und Flores [90]. Insbesondere das Buch von Wedekind geht ausführlich auf die mit dem „direkten Zugriff' (random access) zu externen Speichern verbundene Problematik ein. Es scheint sogar, als sei darüber hinaus sogar eine allgemeingültige Formalisierung der notwendigen Überlegungen möglich oder zum Teil sogar verwirklicht [84; 156; 243], Damit wäre dann die Grundlage für eine in gewissem Grade automatisierte Belastungsschätzung gegeben. Obwohl unsere bisherigen Ausführungen zur deduktiven Laufzeitprognose für die meisten kommerziell orientierten Anwendungen voll ausreichen dürften, wollen wir doch der Vollständigkeit halber auch auf den Fall eingehen, daß eine

112

4. Modelldaten

genauere Betrachtung der internen Verarbeitung erforderlich ist. Eine solche Diskussion erscheint nicht nur im Hinblick auf „fortgeschrittene" Anwendungen interessant. Wir betonten bereits, daß auch die Schätzmethoden für simultane Verarbeitung auf denen für sequentielle Verarbeitung basieren. Ein wesentliches Bestreben aller Betriebssysteme mit Multiprogramming ist es aber gerade, die CPU besser auszulasten, was gleichzeitig bedeutet, daß interne Verarbeitungszeiten relativ an Gewicht gewinnen. Wir nehmen dabei zur Vereinfachung an, daß zwischen dem Lesen des Eingabe- und dem Beschreiben des Ausgabepuffers keine weiteren Daten angefordert werden. Es ist ein bekannter und charakteristischer Wesenszug von Rechnerprogrammen, daß sie bedingte Verzweigungen („Weichen") enthalten, die in Kombination mit dem Auftreten von Schleifen (loops) zu einer Unzahl theoretisch denkbarer Wege führen können. Die zeitliche Dauer eines Weges (k) durch den „Programmgraphen" kann unter unseren Voraussetzungen im Prinzip als determinierter Wert tK angegeben werden. Wird der betreffende Ablauf sehr oft wiederholt (viele Datensätze bzw. Parameterkonstellationen), so können wir als Schätzwert für die Durchlaufzeit b^ ansetM zen: b nj = s jn Ev( tuj )/ M =

"

(4.1)

' 2 tKpK K

s^ = Anzahl der in der Referenzperiode zu verarbeitenden Sätze tK = Zeitbedarf für Weg k pK = Wahrscheinlichkeit des Wegs k Wegen der Vielzahl möglicher Wege ist es allerdings notwendig, die weniger wesentlichen Wege zu vernachlässigen bzw. Wege zu aggregieren (Schätzwerte bei Schleifendurchgängen u.a.), was angesichts anderer gravierender Fehlerquellen kaum ins Gewicht fallen dürfte. Bestimmend für die Schätzgenauigkeit ist vor allem die Qualität der Prognose bezüglich des zu erwartenden Datenprofils, wobei neben dem Faktor auch der Einfluß auf die Wahrscheinlichkeiten pK zu beachten ist. Der Zusammenhang zwischen pK und Datenprofil ergibt sich in folgender Weise: Wir denken uns die Verzweigungen oder Weichen des fraglichen Programms (Programm-Modells) in irgendeiner Weise durchnumeriert. Dann gehört zu jedem Weg k eine ganz bestimmte Folge von Verzweigungsindizes v\, v 2 , • • • • (Ein bestimmter Index kann in einer solchen Folge beliebig oft auftreten). Bezeichnen

4.1 Abschätzung der technischen Koeffizienten (Belastungen)

113

wir mit q ^ die Wahrscheinlichkeit 5 der von Weiche i>j ausgehenden, zum Weg k gehörenden Teilstrecke (Abb. 7), so gilt pK = nq alte Weichen des Weges K

Abb. 7. Ausschnitt aus einem Weg K

i

Die Größen q ^ hängen ihrerseits sowohl von der qualitativen Zusammensetzung der Arbeitsdaten wie auch von Einzelheiten des Programms (Gestaltung der Abfragen) ab. Sie können, wenn diese Informationen vorliegen, mit ausreichender Genauigkeit bestimmt werden. Wir müssen dem allerdings einschränkend hinzufügen, daß der angedeutete Weg zur Abschätzung einer mittleren „internen Zeit" pro Datensatz nur solange realisierbar ist, als es sich nicht um Optimierungsalgorithmen handelt, deren „Iterationszahl" nur sehr schlecht — wenn überhaupt — prognostiziert werden kann. Die eben dargestellten deduktiv fundierten Schätzmethoden können (und sollten) selbstverständlich mit den früher besprochenen empirischen Verfahren kombiniert werden, wodurch sich nicht zuletzt eine wesentliche Erhöhung der Zuverlässigkeit von Laufzeitschätzungen ergeben dürfte. Ein Beispiel für eine solche Kombination wäre etwa die Transformation gemessener Zeiten aufgrund von Untersuchungen über den Einfluß bestimmter Systemparameter. Weiß man z.B., daß für die monatliche Laufzeit einer EDV-Anwen5

Es handelt sich genaugenommen um die bedingte Wahrscheinlichkeit unter der Voraussetzung, daß die Weichen v i , . . . , vi_i bereits passiert sind. Man könnte dies z.B. durch die Schreibweise q v(K)/

andeuten. • • • . "i-l

114

4. Modelldaten

dung zu 70% die Leistung der Bandgeräte und zu 30% die Geschwindigkeit des Druckers bestimmend ist (und kann angenommen werden, daß diese Beziehung gegenüber den ins Auge gefaßten Transformationen konstant ist), so ist eine entsprechende Umrechnung leicht durchzuführen. Man hat nur die technischen Kennzahlen der einen Konfiguration gegen die der anderen auszutauschen. Zwei weitere Möglichkeiten, die sich nicht zwanglos als empirisch oder deduktiv klassifizieren lassen, sind die direkte (subjektive) Schätzung und die Simulation. Eine subjektive Schätzung [133, S. 211—253], die sich an eigenen früheren Erfahrungen oder an den Verhältnissen in ähnlichen Betrieben orientiert, wird im ersten Planungsstadium häufig unumgänglich sein. Für gewisse Anwendungskomplexe wie etwa die Gesamtheit der kleineren technisch-wissenschaftlichen Berechnungen werden auch in den späteren Phasen alle diejenigen Methoden ausscheiden, die die Existenz konkreter Programme oder wenigstens ProgrammModelle voraussetzen. Man ist also gezwungen, pauschal eine bestimmte Stundenzahl dafür einzuplanen. (Die Unsicherheit dieses Zeitbedarfs wird kaum schwerwiegende Konsequenzen haben, da einmal der fragliche Bedarf weitgehend manipulierbar ist und andererseits im Notfall immer noch die Möglichkeit besteht, auf ein Service-Rechenzentrum auszuweichen.) Tab. 4. Simulation und Messung bei der Systemplanung. Programm vorhanden quasideterministisches Datenprofil

existierende Konfiguration

unsicheres Datenprofil Stichprobenverfahren (Monte-Carlo)

Messung technische „Risikoanalyse"

simulierte Konfiguration

6

„Messung" der Laufzeit durch Simulation des EDVSystems 6

Sensitivitätsanalyse

Anwendung wird simuliert quasideterministisches Datenprofil

unsicheres Datenprofil

Messung am Simulationsmodell des Programms

Sensitivitätsanalyse, stochastische Simulation

„deterministische" Simulation des Gesamtsystems aus Anwendung(en) und Konfiguration

Die meisten Hersteller bieten für die Simulation gängiger (meist etwas älterer) Computersysteme Simulatoren bzw. Emulatoren an, die praktisch fertige Simulationsmodelle darstellen. Im ersteren Fall handelt es sich um Übersetzungsprogramme (Software), im zweiten erfolgt die Implementierung über die Hardware. Die übliche Verwendung dieser Hilfsmittel im Dauerbetrieb (statt zu Planungszwecken wie hier vorgeschlagen) wird von manchen Fachleuten wegen der auftretenden hohen „Reibungsverluste" scharf kritisiert 1254, insbes. S. 431.

4.1 Abschätzung der technischen Koeffizienten (Belastungen)

115

Das Wesen der Simulation soll hier als bekannt vorausgesetzt werden (vgl. S. 35) Das Verfahren besitzt große Ähnlichkeit mit den experimentellen oder empirischen Methoden, sollte aber begrifflich davon unterschieden werden. Ein Simulationsmodell eines zu untersuchenden Systems steht zwar hinsichtlich seiner Komplexität der Wirklichkeit näher als ein „analytisches Modell". Daraus folgt aber nicht notwendig eine entsprechende Aussage über seine Realitätstreue; das „naive" Gleichsetzen von Komplexität und Wirklichkeitsnähe hat vielmehr in der Praxis immer wieder zu kostspieligen Mißerfolgen mit Simulationsläufen geführt. Bei genügend wirklichkeitsnahem Modell ist allerdings die Simulation einer echten Messung praktisch gleichwertig [166], Die Anwendungsmöglichkeiten des Verfahrens auf das hier diskutierte Entscheidungsproblem, insbesondere auf die Abschätzung der Systembelastung durch einzelne Anwendungen, sind recht vielgestaltig. Die wesentlichen Beziehungen und Gesichtspunkte seien deshalb der Kürze halber im Schema der Tab. 4 zusammengefaßt. Es scheint, daß Simulationsläufe in der Praxis in erster Linie dazu dienen, die Zulässigkeit (feasibility) eines komplexen Gesamtsystems festzustellen bzw. durch Abänderungen unter Beibehaltung der Grundkonzeption zu erreichen. Die Kosten hierfür sind hoch, was zur Folge hat, daß manche Systemplaner dieses Hilfsmittel entweder von vornherein außer Betracht lassen oder aber seine Verwendung auf wenige kritische Punkte beschränken. 7 Unsere Aufstellung (Tab. 4) zeigt die Breite des tatsächlich bestehenden Spielraums und die daraus folgende Fragwürdigkeit generalisierender Feststellungen über Kosten und Zweckmäßigkeit von Simulationen. Hinzu kommt noch, was im Schema nicht zum Ausdruck gebracht werden konnte, daß auch bezüglich der Ausgestaltung des Modells, der Zahl der Läufe usw. wesentliche Freiheitsgrade bestehen. Für den Aufwand einer Systemsimulation sind diese Faktoren ebenso wichtig wie die Abgrenzung des simulierten Bereichs im Großen. Während „komfortable" fertig programmierte Simulationssysteme (wie etwa SCERT) für die Prognose von Einzellaufzeiten kaum in Frage kommen dürften, stellt nach Ansicht des Verfassers die Eigenerstellung kleinerer Simulationsmodelle 8 bei geschickter Vergröberung und kluger Beschränkung durchaus einen gangbaren und diskutablen Weg dar. 7

Eine Umfrage in den USA ergab, daß nur 16% der befragten EDV-Anwender von Simulationen bei der Computerauswahl Gebrauch machen 1294].

8

Bei kleineren Problemen ist es unter Umständen vorteilhaft, eine vom eigenen Programmierstab gut beherrschte problemorientierte Computersprache zu verwenden. Die Konstruktion von Simulationsmodellen in SpezialSprachen wie SIMSCRIPT oder GPSS ist zwar einfacher, erfordert aber einen entsprechenden Compiler und erheblichen Schulungsaufwand.

116

4. Modelldaten

4.1.2 Schätzmethoden bei Stapelverarbeitung im Multiprogramming-Modus Der Begriff „Zeitbelastung" sollte bei der simultanen Verarbeitung mehrerer Programme nicht mit der Verweilzeit des Jobs im System identifiziert werden. Die letztere hängt bekanntlich unter anderem von der Priorität oder Dringlichkeit des betreffenden Programmlaufs ab. Programme niedriger Priorität werden häufiger unterbrochen als solche höherer Priorität und bleiben dementsprechend längere Zeit im System. Während der Wartezeit befindet sich das Programm in einer „Partition" des Kernspeichers oder auf einem externen Speichermedium; es stellt also keine zeitliche, sondern nur eine kapazitive Belastung des EDVSystems dar. Wartezeiten einer Komponente, die durch das Programm selbst verursacht sind, werden durch das Multiprogramming-Betriebssystem nach Möglichkeit für andere "Tasks" genutzt. (Sie müssen also nicht mehr automatisch dem Programm zugerechnet werden.) Ziel ist hierbei insbesondere eine Verbesserung der Auslastung der Zentraleinheit. Abgesehen von den dadurch bedingten Überlappungen gelten für die zeitlichen Belastungen der Einzelkomponenten dieselben Überlegungen wie bei sequentieller Verarbeitungsweise. Ein wesentlicher Unterschied liegt allerdings in der jetzt sehr viel verwickeiteren Beziehung zwischen Komponentenbelastungen und gesamter Systembelastung. Während im Fall der sequentiellen Verarbeitung Überlappungsmöglichkeiten und Reihenfolgebedingungen nur innerhalb der Anwendungsabläufe (und auch dann nur bei deduktiv orientierter Schätzung) zu beachten waren, wird bei der Multiprogrammierung die Grenzziehung zwischen diesen Anwendungen mehr und mehr problematisch. Wir wiesen bereits früher daraufhin, daß die gegenseitige Beeinflussung der Jobs, die bei sequentieller Verarbeitung für unsere Zwecke vielleicht noch vernachlässigbar ist, bei Simultanverarbeitung eine durchaus merkliche Rolle spielt. Für die Gesamtlaufzeit kommt es jetzt entscheidend auf das Scheduling (Optimierung der Bedienungsreihenfolge) des Betriebssystems sowie auf die Zusammensetzung des Anwendungspakets an. Die Effizienz wird umso höher sein, je günstiger Eingabe/Ausgabe-intensive Programme (in erster Linie die Basisanwendungen) mit rechenintensiven höheren Anwendungen (z.B. Real-Time-Anwendungen, technisch-wissenschaftliche Berechnungen) kombiniert werden. Am befriedigendsten wäre eine Zeitschätzmethode, welche die gesamte Arbeitslast als eine Einheit sieht. Jedoch wäre die Ermittlung einer Durchlaufzeit durch Simulation oder Messung nicht nur äußerst schwierig — eine derartige Betrachtungsweise stünde auch der hier als entscheidend angesehenen Optimierung der Arbeitslast absolut entgegen!

4.1 Abschätzung der technischen Koeffizienten (Belastungen)

117

Die näherungsweise Beibehaltung additiver Zeitbelastungen läßt sich auf mindestens drei verschiedene Weisen verwirklichen. Die einfachste, nicht notwendig schlechteste, Vorgehensweise besteht darin, das System weiterhin so zu behandeln, als erfolge die Verarbeitung sequentiell Die auf die Simultanverarbeitung zurückzuführenden „Erträge" (Zeitreduktion pro Arbeitseinheit) und Aufwendungen (höhere Anforderungen bezüglich Speicherkapazität sowie Kosten für Software und Systemprogrammierung) sind dann als Imponderabilien zu behandeln. Falls „Sicherheitsfaktoren" bei den Einzellaufzeiten oder bei der Systemkapazität einkalkuliert wurden, können diese dann niedriger angesetzt werden oder ganz wegfallen. Eine zweite Möglichkeit ist, die „sequentiellen Belastungen" in geeigneter Weise zu modifizieren. Dabei ist es gleichgültig, ob man die ursprünglichen Zeiten durch (verringerte) Effektivbelastungen ersetzt oder aber eine (erhöhte) Effektivkapazität des Gesamtsystems zugrundelegt. Auch nach der Modifikation wird für alle on-line-Komponenten des Systems dieselbe Zahl eingesetzt (Reihenfolgebedingungen u.a. sind also bereits berücksichtigt). Bei der dritten Methode addieren wir zu den echten Komponentenzeiten (die natürlich von Gerät zu Gerät variieren und grundsätzlich für jede Anwendung bestimmbar sind) Zusatzterme Lj, um die unvermeidlich auftretenden Leerzeiten zu berücksichtigen. Es müßte nach unserer Ansicht gelingen, auch diese Größen abzuschätzen. Unter Berücksichtigung des "overheads" oder „internen Verwaltungsaufwands" nehmen die Zeitrestriktionen dann folgende Gestalt an:

(4.2)