Das Jahr 2000 in der EDV: Bewältigung des Jahr-2000-Problems in Ihrem Unternehmen 9783486797282, 9783486247374

Citation preview

Das Jahr 2000 in der EDV Bewältigung des Jahr-2000-Problems in Ihrem Unternehmen von Peter Haase

R. Oldenbourg Verlag München Wien 1998

Peter Haase (geb. 1956, Dipl.-Phys.) war von 1981 bis 1983 wissenschaftlicher Mitarbeiter bei mbp (heute: EDS) in Dortmund, von 1983 bis 1985 Systemanalytiker bei Rasselstein Hoesch in Andernach, von 1985 bis 1989 freier Mitarbeiter in EDV-Projekten, von 1989 bis 1993 Systemanalytiker und Schulungsberater bei M. Roßbach (heute: ACI) in Wiesbaden und von 1992 bis 1996 Sprecher der Tandem Computers Nutzergruppe für Österreich, Schweiz und Deutschland (GTUG). Seit 1985 ist er Inhaber von Peter Haase Consulting - Training - Marketing, einem Allianz Partner von Tandem Computers. Alle Informationen dieses Werkes stammen aus Quellen, die Autor und Verlag für vertrauenswürdig halten. Autor und Verlag garantieren nicht die Korrektheit, Vollständigkeit oder Angemessenheit dieser Informationen. Autor und Verlag haften nicht für Fehler, Auslassungen oder Unangemessenheit dieser Informationen und auch nicht für mögliche Interpretationen dieser Informationen. Der Leser übernimmt die alleinige Verantwortlichkeit für jegliche Auswahl aus den Informationen dieses Werkes und für davon abgeleitete Entscheidungen. Der Autor bittet darum, die Behandlung der Bereiche Vertragsrecht, Haftung, Versicherung und Handelsbilanz nicht als Beitrag für die interne fachliche Diskussion anzusehen, sondern als Aufforderung an die zustandigen Fachleute, selbst die Zusammenhänge ihres Faches mit dem Jahr 2000 Problem deutlicher herauszustellen. Mögliche technische Angaben zu einzelnen Produkten sollten immer beim Hersteller dieser Produkte verifiziert werden. Die Erwähnung von Namen für Hardware- und Software-Produkte geschieht immer unter Anerkennung aller Rechte der Warenzeicheninhaber.

Die Deutsche Bibliothek - CIP-Einheitsaufnahme Haase, Peter: Das Jahr 2000 in der EDV : Bewältigung des Jahr-2000-Problems in Ihrem Unternehmen / von Peter Haase. - München : Oldenbourg, 1998 ISBN 3-486-24737-9

© 1998 R. Oldenbourg Verlag Rosenheimer Straße 145, D-81671 München Telefon: (089) 45051-0, Internet: http://www.oldenbourg.de Das Werk einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Bearbeitung in elektronischen Systemen.

Lektorat: Margarete Metzger Layout: Wulf Berschin Herstellung: Rainer Hartl Umschlagkonzeption: Kraxenberger Kommunikationshaus, München Umschlagbild: O. M. Kaptein, Hennef Gedruckt auf säure- und chlorfreiem Papier Gesamtherstellung: R. Oldenbourg Graphische Betriebe GmbH

Inhalt Vorwort

7

Danksagung

10

Überblick

11

1

Einleitung

15

1.1 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5

Das Jahrhundertereignis in der EDV Presseschau Virenbefall Wortwahl Globale Kosten Was folgt daraus?

15 15 17 18 19 20

1.2 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.2.6

Jahrhundertprobleme Fehlendes Jahrhundert Magische Zahlen Zeitliche Operationen Unglücklicher Erfolg Verschüttetes Wissen Was folgt daraus?

21 21 23 24 25 26 27

1.3 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5

Kalendergeschichten Sonne, Mond und Sterne Ägypter, Römer und Christen Astronomen, Techniker und Programmierer Sonnenuhr, Rechneruhr und Funkuhr Was folgt daraus?

28 28 29 31 32 34

1.4 1.4.1 1.4.2 1.4.3 1.4.4

Das Problem in Deutschland Bestandsaufnahme Kosten für einzelne Unternehmen Auswege Was folgt daraus?

34 35 37 38 40

2

Die EDV vor dem Jahr 2000 - Gefahren

41

2.1

Komplexitätsfallen

41

4

Inhalt

2.1.1 2.1.2 2.1.3 2.1.4 2.1.5

Die Mitarbeiter im Jahr 2000 Projekt Die Programmiersprachen Die Programmtexte Die Komplexität der Programme Was folgt daraus?

41 43 44 45 46

2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5

Bilanzielle Bewertung Das Vermögen eines Unternehmens Die Bewertung beim Anwender von Software Die Bewertung beim Hersteller von Software Die Berichtspflichten Was folgt daraus?

47 47 49 50 51 53

3 3.1 3.1.1 3.1.2 3.1.3 3.1.4

Die EDV vor dem Jahr 2000 - Chancen Proj ektmanagement Der Zeitplan für Jahr 2000 Projekte Die Einrichtung des Jahr 2000 Projektrahmens Das Management des Jahr 2000 Projektrahmens Was folgt daraus?

55 55 57 59 63 65

3.2 3.2.1 3.2.2 3.2.3 3.2.4

Bestandsaufnahme und Analyse der EDV-Anwendungen EDV-Anwendungen finden EDV-Anwendungen erfassen EDV-Anwendungen beurteilen Was folgt daraus?

65 67 69 70 71

3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.4 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6 3.4.7 3.4.8

Bestandsaufnahme und Analyse der EDV-Systeme Der Umfang der Bestandsaufnahme Die Ablaufumgebung eines Programms Die Entwicklungsumgebung eines Programms Die Analyse eines Programmtextes Was folgt daraus? Lösungsalternativen Verschönern Erneuern Nichtstun Abreißen Umbauen Anbauen Zeitreise Was folgt daraus?

71 73 74 78 79 83 83 85 85 86 87 87 93 93 95

3.5 3.5.1 3.5.2

Testverfahren Die Testumgebung Die Jahr 2000 Testvarianten

96 98 99

Inhalt

5

3.5.3 3.5.4 3.5.5

Die Prüfung der Jahr 2000 Fähigkeit Die Effizienz der Tests Was folgt daraus?

106 107 108

3.6 3.6.1 3.6.2 3.6.3 3.6.4 3.6.5

Lösungsanbieter Die Auswahl eines Lösungsanbieters Die Lösungsanbieter in Projekten Die Werkzeuge der Lösungsanbieter Die Lösungsanbieter im Markt Was folgt daraus?

108 110 112 115 118 118

3.7 3.7.1 3.7.2 3.7.3

Die Jahr 2000 Fähigkeit der EDV- und Elektronik-Hersteller Definitionen Jahr 2000 fähige Produkte Was folgt daraus?

119 121 123 125

3.8 3.8.1 3.8.2 3.8.3 3.8.4

Die Jahr 2000 Initiativen der EDV- und Elektronik-Hersteller Das Jahr 2000 Problem beim Hersteller Unterstützung der Kunden Unterstützung der Lösungspartner Was folgt daraus?

125 127 127 130 131

3.9 3.9.1 3.9.2 3.9.3 3.9.4 3.9.5 3.9.6 3.9.7 3.9.8

Die vertragliche Haftung der EDV-und Elektronik-Hersteller Der Kaufvertrag Der Werkvertrag Der Dauerschu ldvertrag Der Mietvertrag Der Leasingvertrag Der Pachtvertrag Der Rechtsanwalt im Jahr 2000 Projekt Was folgt daraus?

131 132 136 138 139 140 140 141 142

3.10 3.10.1 3.10.2 3.10.3 3.10.4 3.10.5

Kunden und Lieferanten Bestandsaufnahme aller Außenbeziehungen Phasen eines Jahr 2000 Projektes zwischen Unternehmen Kooperation mit dem Wettbewerber Anwendervereinigungen Was folgt daraus?

142 144 145 146 147 148

4

Die EDV im Jahr 2000 - Gefahren

149

4.1 4.2 4.3 4.4

Die Kalenderkatastrophen Der Katastrophenkalender Der Jahrhundertübergang Was folgt daraus?

149 152 153 153

6

Inhalt

5

Die EDV im Jahr 2000 - Chancen

155

5.1 5.1.1 5.1.2 5.1.3 5.1.4

Management des EDV-Betriebes Notwendigkeit und Ziele Systematik der Aufgaben Optimierung der Aufgabenerledigung Was folgt daraus?

155 157 158 161 164

5.2 5.2.1 5.2.2 5.2.3 5.2.4

Versicherungen Das verdoppelte Jahr 2000 Problem Versicherungsarten Millennium-Versicherung Was folgt daraus?

165 165 166 170 171

6

Die EDV nach dem Jahr 2000 - Gefahren

173

6.1 6.1.1 6.1.2 6.1.3 6.1.4 6.1.5

Haftung aus Verschulden und Gefährdung Schuldhaftes Verhalten Haftung aus Verschulden Haftung im Innenverhältnis Haftung aus Gefährdung Was folgt daraus?

173 174 175 178 180 180

6.2 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5

Veränderungen im Softwaremarkt Management von Software Vermarktung von Software Pflege von Software Berufsrecht und Berufsethik Was folgt daraus?

181 181 182 183 184 186

7

Die EDV nach dem Jahr 2000 - Die Chance

187

7.1 7.1.1

Das Ende der Softwarekrise Schlußfolgerungen und Ausblick

187 190

8

Quellen

191

9 9.1 9.2

Glossar EDV-Begriffe Hierarchie von EDV-Begriffen

195 195 201

10

WWW-Adressen zum Jahr 2000 Problem

203

10.1 10.2 10.3 10.4

Deutschsprachige Informationen Europa USA und Kanada Andere Länder

203 204 205 206

11

Index

209

Für meine Tochter Magdalena (8 Jahre alt), die das Problem so erkannt hat: „neunzehnhundertsiebenundneunzig, „neunzehnhundertachtundneunzig, „neunzehnhundertneunundneunzig, „neunzehnhundertzehnundneunzig."

Vorwort „Nun, wo das Jahrtausend sich dem Ende zuneigt, erreichen auch die Datumswerte in unseren Computern ein Maximum, was wir schon zahllosen Berichten entnommen haben. Die Experten sind besorgt, daß viele unserer Informationssysteme nicht zwischen einem Datum aus dem 20. und dem 21. Jahrhundert unterscheiden werden. Ich möchte den Amerikanern versichern, daß die Bundesregierung, im Zusammenwirken mit der zentralen und lokalen Verwaltung und der Privatwirtschaft, dabei ist, Schritte zu unternehmen, um jegliche Unterbrechung von Regierungsfunktionen abzuwenden, die auf das korrekte Funktionieren der Computersysteme des Bundes angewiesen sind. Wir möchten nicht, daß die Amerikaner auf eine neues Jahrhundert und ein neues Jahrtausend blicken, wobei ihre Computer - das Symbol der Moderne und der Neuzeit - sie (in diesem Jahrhundert) zurückhalten; und wir werden ganz bestimmt sehen, daß das nicht passiert." US Präsident Bill Clinton am 15.August 1997 (102) bei der Vorstellung seines Millennium Projektes (Übersetzung des Autors, englisches Original am Schluß des Vorwortes) An den Wechsel der Jahre gewöhnt man sich; doch den Wechsel eines Jahrhunderts oder gar eines Jahrtausend miterleben zu dürfen, ist etwas Besonderes. Die einen sehen in dem Wechsel etwas Gutes und Aufmunterndes und verkünden gleich ihr Programm für die Beglückung des kommenden Jahrtausends. Die anderen sehen in dem Wechsel etwas Böses und Niederschmetterndes und verkünden den nun diesmal wirklich endgültigen Weltuntergang. Der Computer, ein Ergebnis der Technologie dieses Jahrhunderts, hat im Geschäftsleben - und im Leben einer Regierung - fast alle Funktionen erst unterstützt und dann nach und nach übernommen. Nun wird er gerade in dem Moment Probleme erzeugen, wo alle Fortschrittsgläubigen ihre große Stunde haben, nämlich zum Jahrhundertwechsel. Die technische Entwicklung hat uns nämlich in den letzten vierzig Jahren Systeme beschert, die in kleiner Zahl schon heute und demnächst fast alle, und zwar weit-

8

Vorwort

weit, bei der Verarbeitung, Berechnung und Ordnung von Datumswerten mit dem alltäglichen Kalender in Widerspruch stehen. Das Thema dieses Buches ist, wie diese drohende Katastrophe abgewendet werden kann. Der amerikanische Präsident glaubt, daß er das für die Bundesbehörden in den USA erreichen kann. Dieses Werk möchte den Leser dabei unterstützen, daß er die gleiche Zuversicht auch für sein Unternehmen oder seine Verwaltung entwickeln kann. Das Thema dieses Buches ist auch, welche Lektionen aus der Geschichte der Entstehung, Entdeckung und Bewältigung des Jahr 2000 Problems zu lernen sind. Dabei will es aktuell, verständlich und neuartig sein. Es werden zeitnah deutsche und auch internationale Quellen ausgewertet. Die Kapitel beginnen mit Stichworten und einem Überblick und enden mit Schlußfolgerungen. Jedes Kapitel enthält neue, in der öffentlichen Diskussion bisher nicht erwähnte Aspekte. Der Autor versucht, die Sicht eines EDV-Anwenders in einem mittleren oder großen Unternehmen einzunehmen und alle Themenbereiche zum Jahr 2000 Problem und seiner Lösung anzusprechen, die unabhängig von speziellen Produkten und speziellen Projekten bestehen. Er hofft, sowohl dem kaufmännischen und dem technischen Management solcher Unternehmen als auch den Mitarbeitern in Jahr 2000 Projekten wichtige Anregungen für Ihre Arbeit geben zu können und dabei gleichzeitig über die verschiedenen Aspekte des Jahr 2000 Problems das gegenseitige Verständnis zwischen Leitenden und Ausführenden zu fördern. Manchmal weisen erst nur einzelne Mitarbeiter eines Unternehmens auf die Jahr 2000 Probleme hin; sie werden in diesem Buch wichtige Argumente für ihre Überzeugungsarbeit finden. Meistens begnügt man sich dann damit, die Jahr 2000 Probleme nur in seinem eigenen Unternehmen anzugehen; dieser Ansatz wird jedoch der gesamtwirtschaftlichen Dimension des Jahr 2000 Problems nicht gerecht. Die mit dem Jahr 2000 Problem verbundenen Chancen und Gefahren werden entsprechend dem Zeitablauf beschrieben, also für die Jahre vor dem Jahr 2000, für das Jahr 2000 und für ein paar Jahre nach dem Jahr 2000. Der Blick in die Zukunft wird ermöglicht durch den speziellen Charakter des Jahr 2000 Problems. Da der fortschreitende Kalender die Probleme auslöst, kann man durch die Untersuchung heute existierender Programme über ein künftiges Ereignis Bescheid wissen, das nicht nur möglich oder wahrscheinlich sondern sicher ist. Man kann sogar, wenn man nur will, das genaue Datum seines Eintritts voraussagen. Ein weiteres Thema wird daher auch sein, die wirtschaftlichen und rechtlichen Konsequenzen dieser besonderen Fügung zu untersuchen.

Vorwort

9

Das Jahr 2000 Problem hat noch eine weitere, besondere Eigenart: es geht eigentlich um die Programmierung der Computer, es geht um Software. Wenn man vor einem laufenden Computer steht, ist sie allerdings unsichtbar; wenn man sich eine Unternehmensbilanz anschaut, ist sie auch dort entweder nicht sichtbar oder immateriell. Nicht einmal der ausführende Computer bekommt Programmtexte zu lesen. Durch das Jahr 2000 Problem wird Software, der Stoff, der die Computer belebt und den man so leicht übersehen kann, erstmals der erstaunten Öffentlichkeit und manchem überraschten Manager vorgeführt. Die Programmierer rechneten in der Vergangenheit mit vernunftbegabten Wesen, die Datumswerte auch in der Zukunft sicher interpretieren können. Doch die Computer sind nicht von dieser Art. Es ist leichter, künstliche Dummheit als künstliche Intelligenz zu schaffen. Das ist auch ein Trost. Ihr Peter Haase

„Now, as the millennium turns, as we have all seen from countless reports, so do the dates on our computers. Experts are concerned that many of our information systems will not differentiate between dates in the 20th and the 21 st century. I want to assure the American people that the federal government, in cooperation with state and local government and the private sector, is taking steps to prevent any interruption in government services that rely on the proper functioning of federal computer systems. We can't have the American people looking to a new century and a new millennium with their computers - the very symbol of modernity and the modern age - holding them back, and we're determined to see that it doesn't happen." (102)

Danksagung Ich danke Frau Metzger vom Oldenbourg Verlag für ihre wertvollen Korrekturhinweise. Ich danke Herrn Rechtsanwalt Resing von der Firma Dehnen & Partner GbR, Düsseldorf, für die kritische Durchsicht der beiden Kapitel „Vertragliche Haftung" und „Haftung aus Verschulden und Gefährdung". Ich danke Herrn Steuerberater Klein, Bullay, für seine zahlreichen Anmerkungen zum Kapitel „Bilanzielle Bewertung". Ich danke Herrn Schmidt, unabhängige Versicherungsagentur, Boppard, und Herrn Heuze von der Firma AIG Europe, Frankfurt, für die kritische Durchsicht des Kapitels „Versicherungen". Ich danke Herrn Jacobsen-Rey von der Firma Reasoning, Frankfurt, für seine zahlreichen Anmerkungen zum Kapitel „Projektmanagement".

• •

Uberblick Die EDV: fit für das Jahr 2000? Heute sind wesentliche Prozesse in Staat, Wirtschaft und Gesellschaft vom korrekten Funktionieren der sie unterstützenden Computer abhängig. Computer werden von Programmen gesteuert, die in vielen Fällen und über die nächsten Jahre in zunehmenden Maße nicht in der Lage sein werden, Datumswerte fehlerfrei zu verarbeiten. Das ist das Jahr 2000 Problem. Alle elektronischen Systeme, ob groß oder klein, und alle Programme, ob alt oder neu, können betroffen sein. Für alle Organisationen, die EDV einsetzen, besteht ein großes Risiko. Selbst, wenn eine Organisation das Risiko im eigenen Bereich als minimal ansieht, kann sie durch Probleme bei Kunden und Lieferanten, im Konzern und in der öffentlichen Verwaltung, gefährdet sein. Alle haben die Aufgabe, das Jahr 2000 Problem zu lösen, und zwar rechtzeitig. Es gibt aber leider keine einfachen und alles umfassenden Lösungen. Die einfachen Lösungen sind nicht allgemein anwendbar und die allgemeinen Lösungen sind nicht einfach. Weder geniale Programmierer noch mächtige Programmierwerkzeuge helfen allein: Planung und Organisation, Engagement und Kontrolle sind vom Management gefordert. Jede Organisation sollte einen Projektrahmen für die technischen Jahr 2000 Projekte einrichten mit dem Ziel, die Jahr 2000 Fähigkeit für alle bedeutenden EDVAnwendungen zu erreichen. Dieses Ziel sollte die erste Priorität unter aller EDVAktivitäten in den nächsten zwei Jahren haben. Die Projektleitung benötigt Autorität und ausreichende finanzielle und personelle Unterstützung. Der Schlüssel zum Erfolg eines Jahr 2000 Projektes liegt in der Effektivität der Projektorganisation und der Produktivität der Projektmitarbeiter oder bei der Vergabe nach Außen auch in der Kompetenz der Lösungsanbieter und der wohl organisierten Zusammenarbeit mit ihnen. Der Startpunkt eines solchen Projektes ist immer die Analyse, welche fachlichen Anwendungen vorhanden sind und wie diese Anwendungen als Programme und Daten auf den Computersystemen eingerichtet sind. Tests sind erforderlich, um Anwendungsprogramme mit Jahr 2000 Problemen zu entdecken.

12

Überblick

Dementsprechende Abwertungen von Software und Systemen wird man schon heute in der Handelsbilanz vornehmen, und zwar bei Hersteller und Anwender gleichermaßen. Für verschiedene Anwendungen mit einem Jahr 2000 Problem sind sehr unterschiedliche Lösungen möglich. Tests sind auch erforderlich, um selbst umgestellte oder von Lösungsanbietern umgestellte Anwendungen zu prüfen, ob sie die Jahr 2000 Fähigkeit besitzen und ob alle bisherigen Funktionen auch nach allen Änderungen noch korrekt ablaufen. Tests sind ebenfalls erforderlich, um die von EDV-Herstellern versprochene Jahr 2000 Fähigkeit tatsächlich nachzuweisen. Neben der Bestandsaufnahme der EDV-Anwendungen und EDV-Systeme ist auch eine Bestandsaufnahme der EDV-Verträge und der Versicherungsverträge durchzuführen. Nur so lassen sich Haftungslücken beim Kunden oder Haftungsrisiken beim Lieferanten oder auch die Möglichkeiten bei bestehenden Versicherungen entdecken. Eine weitere Bestandsaufnahme erstreckt sich auf die Aufgaben der EDVVerwaltung und die jeweilige Qualität ihrer Erledigung. Nur durch ein systematisches Vorgehen kann hier das Management optimiert und der EDV-Betrieb auf die künftigen Anforderungen eingestellt werden, die das Jahr 2000 Problem und seine Bewältigung mit sich bringt. Noch im Jahr 1998 muß auch sichergestellt werden, daß alle wesentlichen Marktpartner dem Jahr 2000 Problem die gleiche Aufmerksamkeit schenken. Die eigenen und die Projektfortschritte der Partner müssen dabei ständig überprüft werden. Im Jahr 2000 werden alle Beteiligten noch genügend damit zu tun haben, die Abfolge von kleinen und großen Katastrophen zu überstehen. In den Jahren danach wird man dann die Zeit finden, sich die von anderen verschuldeten Schäden oder durch Produkte verursachten Schäden ersetzen zu lassen. Langfristig können die durch Jahr 2000 Projekte verbesserte Pflege von Software und verbesserte Verwaltung von EDV-Systemen einen positiven Effekt haben. Entwicklungszeiten werden verkürzt, Softwarekosten werden gesenkt und die Qualität der Dienstleistungen wird gesteigert. Nur so kann dann das durch die Jahr 2000 Probleme stark beschädigt Image der gesamten Branche wieder verbessert werden.

Überblick

Abbildung I: Der Verlauf eines Jahr 2000 Projektes

13

1

Einleitung

Die Überschriften der vier Kapitel der Einleitung sind bewußt doppeldeutig gehalten. Denn die Doppeldeutigkeit ist das Problem: für viele Computer bedeutet z.B. die Jahresangabe „ 10" nur 1910, für uns Menschen kann „ 10 " das Jahr 10, das Jahr 1910 oder das Jahr 2010 bedeuten.

1.1

Das Jahrhundertereignis in der EDV

•

Presseschau

•

Virenbefall

•

Wortwahl

•

Globale Kosten

•

Was folgt daraus?

Es ereignet sich der Jahrhundertwechsel, und zwar erstmalig in der Geschichte der EDV. Und das Ereignis des Jahrhunderts steht bevor: weltweit und fast gleichzeitig erzeugen alle Arten von Computern alle Arten von Problemen. 1.1.1

Presseschau

Ich möchte Ihnen als Einstig in unser Thema einige Titelüberschriften vorstellen und kommentieren. Ich habe sie meinen Quellen entnommen und gegebenenfalls selbst übersetzt. „Information Technology Meets the Year 2000: Preparing for the Inevitable" (G01) - Die Informationstechnologie trifft auf das Jahr 2000: Vorbereitung auf das Unvermeidliche Die Informationstechnologie als Ganzes und in allen ihren Ausprägungen ist betroffen. Das Alter oder die Größe der Computer spielt keine Rolle. Ebenso ist es

16

1

Einleitung

unwichtig, ob man einem Gerät gleich sein elektronisches Innenleben von Außen ansieht. Es ist notwendig, sich auf den Datumswechsel 2000 vorzubereiten. Denn das Kommen des Jahres 2000 kann nicht verhindert werden - so meint das Zitat in bezug auf das Kalenderjahr; ich werde Ihnen später zeigen, daß der Computerkalender zuweilen anders organisiert werden kann, allerdings muß auch diese Umstellung vor dem Jahr 2000 abgeschlossen sein. Der für eine Umstellung verfügbare Zeitraum läßt sich nicht verlängern, er verkürzt sich vielmehr von Tag zu Tag. „Preparing for 2000: on the first day of the next decade, millions of COBOL programs may be wrong" (X01) - Vorbereitung auf 2000: am ersten Tag der nächsten Dekade können Millionen von COBOL Programmen falsch sein Der kritische Frage ist, wie die elektronischen Geräte programmiert sind. Dabei spielt es keine Rolle, in welcher Sprache programmiert wurde. Es gibt natürlich einen gewaltigen Bestand von Programmtexten in der Sprache COBOL und es wird auch heute noch in dieser Sprache mehr programmiert, als die meisten Universitäten und ihre Absolventen wahr haben wollen. „Year 2000 carries potential Time Bomb for DP" (H02) - Das Jahr 2000 trägt mit sich eine mögliche Zeitbombe für die Datenverarbeitung In der Tat, die Verarbeitung von Datumswerten kann die EDV erschüttern. Eingestellt wurden elektronische Zeitbomben immer wieder in den letzten 40 Jahren; der EDV-Betrieb hat diese Zeitbomben nicht entschärft und sie werden mehr als einmal in den nächsten Jahren explodieren. Wir wollen hoffen, daß militärische Sprengsätze keinen oder wenigstens einen korrekt funktionierenden Zeitzünder haben. Wir sollten verlangen, daß die dafür Verantwortlichen diese Gefahren zuerst abstellen. „Das Jahr 2000 Problem: Medien-Spektakel oder Gefährdung der Funktionsfähigkeit des Wirtschaftssystems" (K02) In Deutschland ist das Jahr 2000 Problem nur selten und wenig spektakulär in den Medien vertreten. Möglicherweise ist gerade deswegen die Funktionsfähigkeit unseres Wirtschaftssystems besonders gefährdet. Noch nehmen das Problem erst wenige ernst und noch weniger machen sich daran, das Problem zu lösen. „Teure Jahrtausendwende" (S01) „2000. The Millennium Bomb. ACostly Problem" (M02) - 2000. Die Jahrtausendbombe. Ein kostspieliges Problem Die Entschärfung der Jahrtausendbombe ist das Problem. Es entstehen große Kosten, wenn man versucht, das Problem zu lösen. Noch sehr viel größere Kosten werden entstehen, wenn man nichts unternimmt.

1.1 Das Jahrhundertereignis in der EDV

17

„Computer in Crisis: How to avoid the Coming Worldwide Computer Systems Collapse" (M03) - Computerkrise: Wie der kommende, weltweite Kollaps der Computersysteme zu vermeiden ist Alle Computer sind in eine Krise geraten, zumindest in eine der Glaubwürdigkeit. Denn bevor man den Computern für die nächsten Jahre trauen kann, muß man alle Programme, die damit ausgeführt werden, auf Korrektheit untersuchen. Das ist der erste Schritt, den Kollaps zu vermeiden. Diesen und alle weiteren Schritte möchte ich Ihnen in den kommenden Kapiteln vorstellen. The global economic Impact of the Year 2000 Software Problem (J02) Der globale wirtschaftliche Einfluß des Jahr 2000 Softwareproblems Da weltweit Organisationen sich dieses Problem annehmen oder es demnächst bearbeiten werden, hat allein die Beschäftigung mit dem Problem schon globale wirtschaftliche Auswirkungen. Die Versuche, das Problem zu lösen, werden nicht zwangsläufig zum Erfolg führen. Und auch das häufige Scheitern wird weltwirtschaftliche Auswirkungen haben.

1.1.2

Virenbefall

Sie kennen sicher Computerviren aus der Presse, vielleicht auch aus eigener Erfahrung. Ein Computervirus ist typischerweise ein kleines Programm, das sich selbst auf andere Computer kopiert und die normalen Operationen dieser Computer unterbricht. Ein Computervirus hängt sich normalerweise an eine Datei an. Es wird über Disketten, Netzwerke und Online-Dienste verteilt. Obgleich manche Viren harmlos sind, können andere Daten löschen oder verfälschen oder Fehlfunktionen im Betriebssystem oder bei anderen Prozessen verursachen. (nach The Concise Columbia Encyclopedia) Computerviren sind zuweilen amüsant, manchmal lästig, oft ärgerlich. Man kann sich dabei auf vielfältige Art anstecken: Disketten und Netzwerke können sie übertragen. Um sie wieder loszuwerden, gibt es Programme, die nach ihnen suchen und sie dann meistens vollständig entfernen. Computerviren werden programmiert von Hackern, das sind Menschen, die meinen, ihre Geschick und ihr Eifer im Umgang mit Computern würde nur anerkannt, wenn ihre Viren möglichst vielen anderen Menschen auf die Nerven gehen. Hacker Jemand, der sich gut mit der Nutzung und Programmierung von Computern auskennt. Jemand, der sich illegal Zugang zu elektronische Systemen oder

18

1

Einleitung

geheimer Information verschafft. Jemand, der mit Begeisterung ein Spiel oder eine Sportart betreibt, (nach The American Heritage Dictionary of the English Language) Wenn ein Hacker sich einen Virus erträumt, so wird dieser Supervirus sicher alle Eigenschaften des Jahr 2000 Problems haben: Solch ein Virus ist in fast allen Programmen zu finden, er tritt in vielfältiger Gestalt auf und ist deshalb schwer zu entdecken und schwer zu beseitigen. Er stört nicht nur den Ablauf von Programmen sondern verfälscht auch Daten. Er kann sogar über verfälschte Daten andere Programme infizieren. Und er kann ganze Unternehmen lahmlegen. Um das Jahr 2000 Problem zu erzeugen brauchte es jedoch nicht einmal böswilliger Hacker. Normale Programmierer reichten dafür aus, die für ihre Kunden oder Anwender möglichst schnell, möglichst viele, möglichst nützliche Programme schaffen wollten. Neuerdings scheinen sich auch einige Hacker mit der Ausnutzung des Jahr 2000 Problems für ihre Zwecke zu beschäftigen. Es gibt schon Ankündigungen, Viren zu entwickeln, deren störende Funktion darin besteht, die Rechneruhr auf den 1.1.2000 vorzustellen.

1.1.3

Wortwahl

Im weiteren Verlauf soll von „EDV" gesprochen werden und nicht von „Informatik". Denn es geht in der Tat um elektronische Datenverarbeitung. Die irgendwie programmierte Elektronik hat möglicherweise ein Problem, egal ob die Software nun leicht als solche erkennbar ist oder sich in „Hardware" verbirgt. Manche Daten repräsentieren ein Kalenderdatum, das möglicherweise von einigen Programmen falsch gedeutet wird. Erst die Verarbeitung läßt dann diese Fehldeutung auftreten; ein reiner Zeitstempel ist unproblematisch. Dieses Mißverständnis ist kein Problem für die Informatik als Wissenschaft im allgemeinen. Natürlich ist es aber ein wirtschaftliches und auch ein technisches Problem für die EDV-Abteilungen, die sich in immer mehr Unternehmen neuerdings „Informatik" nennen - wobei nach der Umbenennung die Wissenschaftsferne oft noch zunimmt. Das Auftreten des Jahr 2000 Problems in so vielen Computern und bei so vielen Organisationen sollte eigentlich ein Problem für die Wirtschaftsinformatik sein und sei es, als Lehrstück für Manager: Das Jahr 200-Problem führt in drastischer Weise vor Augen, welche Folgekosten entstehen können, wenn Anforderungen an Software-Qualität wegen Ressourcenknappheit nicht ausreichend berücksichtigt werden. In diesem Sinn kann das J2P dazu beitragen, in den Geschäftsleitungen Verständnis dafür zu wecken, daß eine methodisch sauberer Vorgehensweise bei der IS-

1.1

Das Jahrhundertereignis

in der ED V

19

Entwicklung kein Luxus, sondern Voraussetzung für deren mittel- und langfristige Beherrschbarkeit ist. (K02) Das Jahr 2000 Problem ist entgegen dem Wortlaut kein Jahrtausendproblem. Nicht der Wechsel des Jahrtausends, sondern der Wechsel des Jahrhunderts erzeugt die Probleme. Falls man im Jahr 1899 schon elektronische Datenverarbeitung mit ähnlich anfälligen Programmen gehabt hätte, so hätte auch das Jahr 1900 ein Jahr 1900 Problem hervorgebracht. Insofern entspringt die Bezeichnung des Jahr 2000 Problems als Jahrhundertereignis nicht der Bescheidenheit des Verfassers sondern seiner Bemühung, das Problem möglichst richtig wahrzunehmen. Die Entwicklung der EDV begann 1941 mit dem ersten programmgesteuerten Rechenautomat des deutschen Ingenieurs K. Zuse oder 1944 mit der Entwicklung von M A R X I des amerikanischen Mathematikers H. Aiken. Der Einzug des Computers in alle wirtschaftlichen Bereiche begann 1977 mit dem Bau des ersten Personal Computers, womit durch Hardware zu immer geringeren Kosten und durch Absatz einer immer größeren Anzahl ein sich selbst verstärkender Prozeß ausgelöst wurde. Für die EDV kann man nach etwas mehr als fünfzig Jahren Entwicklung auch nur ein Jahrhundertereignis feststellen; wer weiß schon, was die nächsten 950 Jahre hervorbringen werden. Das Jahrhundertereignis findet allerdings in der EDV statt, denn es ist ein besonderes EDV-Problem, das von den Mitarbeitern der EDV irgendwann selbst gemacht und seitdem mit der Pflege von EDV-Programmen in die heutige Zeit übernommen wurde. Im deutschen Sprachraum findet sich für „Jahr 2000 Problem" manchmal die Abkürzung „J2P". Diese Abkürzung möchte ich nicht benutzen. Für das Deutsche ist eine solche Abkürzung als Mischung aus Buchstaben und Zahlen ungewöhnlich. Für den englischen Sprachraum widerspricht ihre Bildung solchen dort durchaus anzutreffende Abkürzungen wie zum Beispiel „I18N", wo im Wort „Internationalization" 18 Buchstaben zwischen „I" und „N" ausgelassen wurden. Das „Jahr 2000" wird im englischen Sprachraum gerne als „y2k" abgekürzt. Auch diese Abkürzung möchte ich nicht verwenden, „y" steht zwar für „year", „2" steht für „2 mal" und „k" bedeutet normalerweise „kilo", also „Tausend". Doch in der EDV bedeutet „K" üblicherweise „2 hoch 10" also 1024. Es sind gerade die kleinen Mehrdeutigkeiten, die das Jahr 2000 zum Problem in der EDV gemacht haben.

1.1.4

Globale Kosten

Das Jahr 2000 Problem ist auch kein einzelnes Problem, sondern ein Komplex von Problemen, die zum Wechsel auf das Jahr 2000 massiv auftreten. Um die Probleme zu lösen oder mindestens für die eigene EDV abzumildern, sind weltweit 400 bis 600 Milliarden US$ (B03,M02) aufzuwenden:

20

1

Einleitung

„By the end of 1998, due to the size, scope, and environment diversities of the year 2000, over $400 billion will be spent on staffing alternatives for year 2000 projects (0.7 probability)." (G01) - Bis Ende 1998 werden über 400 Milliarden US$ fur die Ausstattung von Jahr 2000 Projektalternativen ausgegeben werden, auf Grund des Umfangs, des Ausmaßes und der verschiedenen Ausprägungen des Jahr 2000 (Problems) (70% Wahrscheinlichkeit)Die weltweit benötigte Anzahl von mitarbeitenden Personen kann man sich wie folgt ausrechnen: „Do the math. Take the estimate of $600,000,000,000 and spread it over 3 years, that's $200,000,000,000 per year. Assume that a programmer makes $100,000 per year, (they don't today, but soon they will!) that means we need 2,000,000 programmers working on this, each year for the next three years." (J01) - Machen Sie die Berechnung. Nehmen Sie die Schätzung von 600 000 000 000 US$ und verteilen Sie diesen Betrag auf drei Jahre; das ergibt 200 000 000 000 US$ pro Jahr. Nehmen Sie an, daß ein Programmierer 100 000 US$ verdient, (das verdienen sie heute nicht, aber bald werden sie das verdienen !) das bedeutet, wir brauchen 2 000 000 Programmierer, die daran arbeiten, in jedem Jahr für die drei kommenden Jahre. Weltweit arbeiten Unternehmen und Institutionen an eben diesem Projekt. Sie haben ähnliche Probleme und fragen folglich ähnlich qualifiziertes Personal nach. Möglicherweise wird die Bewältigung des Jahr 2000 Problems auch deswegen das teuerste technische Projekt, das sich die Menschheit jemals vorgenommen hat. Diese Arbeiten stellen sicherlich das größte Software-Projekt dar, das es in den meisten Unternehmen jemals gegeben hat. Und trotzdem - die Zyniker sagen: deswegen - ist es höchst unsicher, ob die nötigen Umstellungen in allen betroffenen Organisationen korrekt und rechtzeitig durchgeführt werden können. Denn mit der Projektgröße erhöht sich die Wahrscheinlichkeit, das ein Projekt fehlschlägt.

1.1.5

Was folgt daraus?

=> Ein einfaches Problem - wie ein vergessener Jahrhundertzähler - sollte auch eine einfache Lösung haben; doch diesmal ist es anders. Es ist nicht nur mit einem Jahrhundertereignis innerhalb der EDV sondern mit einer Krise zu rechnen, die von der EDV auf die betroffenen Unternehmen übergreift. => Handeln Sie jetzt in Ihrem Unternehmen und bauen Sie dabei auf den weltweiten Erfahrungen anderer auf. Man kann leider nicht sagen, daß Sie, falls Sie

1.2

Jahrhundertprobleme

21

jetzt - nach der Lektüre dieses Kapitels - beginnen, frühzeitig beginnen; möglicherweise beginnen Sie gerade noch rechtzeitig.

1.2

Jahrhundertprobleme

•

Fehlendes Jahrhundert

•

Magische Zahlen

•

Zeitliche Operationen

•

Unglücklicher Erfolg

•

Verschüttetes Wissen

•

Was folgt daraus?

Die EDV hat vielfältige technische Probleme mit dem Jahrhundertwechsel, da sie Jahreszahlen ohne Jahrhundertangabe nutzt. Die starke Durchdringung von Wirtschaft und Verwaltung mit EDV führt dadurch zu großen wirtschaftlichen und gesellschaftlichen Problemen am Ende dieses Jahrhunderts.

1.2.1

Fehlendes Jahrhundert

Das erste und bekannteste EDV-Problem mit dem Jahrhundert ist das Fehlen der Jahrhundertangabe. Für die fehlende Jahrhundertangabe wird natürlich eine „19" angenommen, entweder durch ausdrückliche Ergänzung zweistelliger Eingaben oder stillschweigend. In den Jahren von 1960 bis 1969 hat man sogar manchmal die Angabe des Jahrzehnts weggelassen. Diese Auslassung fiel natürlich am 1.1.1970 auf. Genauso wird die Auslassung des Jahrhunderts spätestens am 1.1.2000 allen auffallen. Einige Beispiele mögen Ihnen zeigen, welche technischen Auswirkungen zu erwarten sind. Die Beispiele sind systematisch ausgewählt. Zuerst soll ein bestimmter Zeitraum ermittelt werden: Wie viele Jahre wird der Autor dieses Werkes an seinem Geburtstag im Jahre 2000 feiern dürfen? Der Autor ist 1956 geboren. Sein Alter bestimmt sich mit vierstelliger Jahreszahl zu: 2000 - 1956 = 44, also 44 Jahre. Sein Alter bestimmt sich mit zweistelliger Jahreszahl zu: 00 - 56 = - 56, im Rechner wird das je nach Definition des Feldes, in dem das Ergebnis abgelegt wird, als -56, als Fehler (Überlauf) oder als 56 dargestellt; offensichtlich sind alle Ergebnisse unbefriedigend. Wer den Autor nicht kennt, mag aber auch ein Alter von 56 Jahren für korrekt halten. Das kann natürlich in ähnlicher Weis bei der Ermittlung von Tagesdifferenzen schiefgehen. Die Differenz zwischen, dem 1.1.1999 und dem 31.12.1998 ist genau

22

1

Einleitung

ein Tag. Die Differenz zwischen, dem 1.1 2000 und dem 31.12 1999 ist ebenfalls genau ein Tag, doch der Rechner mißversteht den 01.01.00 als 1.1.1900 und bestimmt die Tagesdifferenz entweder nicht (Fehler) oder zu -36525 oder 36525 bzw. zu 525 oder 365, falls man nur ein dreistelliges Feld für die Aufnahme des Ergebnisses vorgesehen hat. Als nächstes ermitteln wir einen Zeitpunkt in der Zukunft: Ein Zahlung sei drei Wochen nach Rechnungsstellung fällig. Die Rechnung wird am 17.12.1997 gestellt. Der 17.12.1997 ist der 351. Tag des Jahres 1997, in der siebenstelligen EDVDarstellung: 1997351. Alle Zahlungen, die im Laufe der nächsten 21 Tage eingehen, sind fristgerecht geleistet. Alle Zahlungen, die ab dem 22. Tag eingehen, sind verspätet, in der siebenstelligen EDV-Darstellung: 1997351 + 22 = 1998008, das entspricht dem 8.1.1998. Nun die analoge Rechnung für den Jahreswechsel 2000 und zweistellige Jahreszahlen. Die Rechnung wird am 17.12.1999 gestellt. Der 17.12.1999 ist der 351. Tag des Jahres 1999, in der fünfstelligen EDV-Darstellung: 99351. Alle Zahlungen, die im Laufe der nächsten 21 Tage eingehen, sind fristgerecht geleistet. Alle Zahlungen, die ab dem 22.Tag eingehen sind verspätet, in der fünfstelligen EDV-Darstellung: 99351 + 22 = (1)00008, das entspricht dem 8.1.2000 oder aber Fehler (Überlauf), da kein Platz für die Hunderterstelle vorgesehen ist. Nun wollen einen Vergleich von zwei Datumswerten durchführen: Wenn der letzte Gültigkeitsmonat einer Kreditkarte der Juni 1998 ist, so ist auf ihr notiert „98/06". Jetzt mögen wir den März 1998 haben; wir vergleichen: 98/03 < 98/06; also können wir die Kreditkarte noch einsetzen. Wenn der letzte Gültigkeitsmonat einer Kreditkarte aber der Juni 2000 ist, so ist auf ihr notiert „00/06". Jetzt mögen wir den März 1998 haben; wir vergleichen: 9803 < 0006; das stimmt nicht, also wird man uns den Einsatz der Kreditkarte versagen. Mit genau diesem Problem kämpfen zur Zeit mehrere große Kartengesellschaften in den USA. Als letztes Beispiel zu dieser Art von Problemen, wollen wir einen Rechner bestimmen lassen, ob wir am 7.1.2000 arbeiten müssen. Wenn er tatsächlich für 2000 nachschaut, findet er einen Freitag. Wenn er für „00", also 1900, nachschaut, findet er einen Sonntag. Kalenderprobleme werden ausfuhrlich im nächsten Kapitel besprochen.

1.2

Jahrhundertprobleme

1.2.2

23

Magische Zahlen

Das zweite und wahrscheinlich genauso brisante EDV-Problem mit dem Jahrhundert ist die besondere Bedeutung bestimmter Jahreszahlen. Wenn eine Jahreszahl immer vierstellig angegeben worden wäre, so wäre auch niemand auf die Idee gekommen „99", „00" oder vielleicht sogar „98" eine besondere Aussage zuzuschreiben. So aber hat zuweilen der Programmierer das so vorgesehen; zuweilen haben Anwender das so unter sich vereinbart. Die Probleme beginnen schon damit, daß die Eingabe von „00" für das Jahr 2000 nicht erkannt wird. Entweder wird sie im Programm als ungültig abgelehnt oder sie wird als Auslassung, also keine Eingabe, interpretiert. Demgegenüber kann „00" auch als Standardbelegung gewählt worden sein. Die besonderen Bedeutungen sind natürlich nicht einheitlich, sondern von Programm zu Programm, von Anwendung zu Anwendung verschieden. Mögliche Bedeutungen von „99" sind - die Aufzählung ist natürlich nicht vollständig: •

Ende der Datei

•

Ende der Verarbeitung

•

Fehler

•

unbegrenzte Wiederholung

•

unbegrenzte Speicherung

Mögliche Bedeutungen von „00" sind - die Aufzählung ist wieder nicht vollständig: •

unbekannter Wert

•

Satz ohne Werte

•

Satz mit Musterwerten

Um ein maximales Datum auszudrücken, werden oft folgende Ziffernfolgen verwendet: •

99

•

99365

•

99999

•

991231

•

990909

•

999999

24

1

Einleitung

Eine Anwendung aus dem Versicherungswesen kann ich als ein Beispiel geben (M05). Zu jeder Versicherung ist neben dem Datum des Versicherungsabschlusses auch vorgesehen, daß ein Stornojahr, zweistellig, eingegeben werden kann. Wenn sie tatsächlich storniert sein soll, wird für das Stornojahr eine Zahl zwischen, aber ungleich, 0 und 99 eingegeben. Wenn nichts eingegeben wird, enthält dieses Feld als Vorbesetzung „00". Wir sollten es dann mit einem aktiven Vertrag zu tun und nicht mit einem, der im Jahr 2000 storniert wurde. Wenn der Vertrag beitragsfrei ruhen soll, wird „99" eingetragen. Man kann also im Jahr 1999 nicht mehr zwischen ruhenden und dann stornierten Verträgen unterscheiden. Im Jahr 1999 werden also alle stornierten Verträge als beitragsfrei ruhend bzw. alle ruhenden Verträge als storniert angesehen und im Jahr 2000 alle aktiven Verträge als storniert.

1.2.3

Zeitliche Operationen

Die arithmetischen Operationen sind Addition (+), Subtraktion (-), Multiplikation (*) und Division (/). Diese Operationen sind auch für Größen vom Typ Datum, Uhrzeit oder eine Kombination von beiden sowie Zeitintervalle definiert. Die Zeitintervalle haben keinen bestimmten Anfang und kein bestimmtes Ende auf dem Zeitstrahl. Die folgenden Operationen sind erlaubt: Tabelle 1: Operationen mit zeitartigen Größen Operand-1

Operator

Operand-2

Ergebnistyp

Datum-Uhrzeit

+

Zeitintervall

Datum-Uhrzeit

Zeitintervall

+

Datum-Uhrzeit

Datum-Uhrzeit

Zeitintervall

+

Zeitintervall

unbestimmtes Zeitintervall

Datum-Uhrzeit

-

Zeitintervall

Datum-Uhrzeit

Datum-Uhrzeit

-

Datum-Uhrzeit

bestimmbares Zeitintervall

Zeitintervall

-

Zeitintervall

unbestimmtes Zeitintervall

Zeitintervall

*

Zahl

unbestimmtes Zeitintervall

Zahl

*

Zeitintervall

unbestimmtes Zeitintervall

Zeitintervall

/

Zahl

unbestimmtes Zeitintervall

Die Addition von zeitartigen Größen ist im Rechner der gleichen Gefahr ausgesetzt wie alle Additionen; es kann ein Überlauf des Feldes entstehen, das das Ergebnis aufnehmen soll. Zwei Datumswerte zusammenzuzählen ist nicht sinnvoll. Die Subtraktion von zeitartigen Größen ist im Rechner der gleichen Gefahr ausgesetzt wie alle Subtraktionen; es kann ein Unterlauf des Feldes entstehen, wenn das

1.2

Jahrhundertprobleme

25

Ergebnisfeld kein Vorzeichen annehmen kann. Einen Datumswert von einem Intervall abzuziehen ist nicht sinnvoll. Die Multiplikation einer Zahl mit einem Zeitintervall ist im Rechner der gleichen Gefahr ausgesetzt wie alle Multiplikationen; es kann ein Überlauf des Feldes entstehen, das das Ergebnis aufnehmen soll. Die Division eines Zeitintervalls durch eine Zahl ist im Rechner der gleichen Gefahr ausgesetzt wie alle Divisionen; der Divisor sollte ungleich Null sein und die Genauigkeit des Ergebnisses hängt vom Rechner, der Programmiersprache und vom Geschick des Programmierers ab. Die Beispiele zum fehlenden Jahrhundert zeigen also die üblichen Probleme der Arithmetik auf dem Rechner. Statt eines Überlaufs oder Unterlaufs kann es bei unkritischen Rechnern, die Prüfungen zur Laufzeit vernachlässigen, bzw. bei unkritischen Kompilierern, die Prüfungen zur Zeit der Übersetzung vernachlässigen, auch zur Verfälschung des Ergebnisses kommen. Manchmal lassen sich diese Prüfungen auch abschalten. Die genannten Beispiele haben auch gezeigt, daß Vergleiche von Jahren vor dem Jahr 2000 mit dem Jahr 2000 und den Jahren danach, dazu fuhren können, daß „wahr" mit „falsch" vertauscht wird. Eine unangenehme, doch meistens noch erträgliche Konsequenz daraus ist, daß aufsteigende wie absteigende Sortierungen, die Jahr 1997, 1998, 1999, 2000 auseinander bringen: • •

aufsteigend - 00, 97, 98, 99 absteigend - 99, 98, 97, 00

Eine weniger angenehme, meistens unerträgliche Konsequenz ist, daß bestimmte Vorgänge, die auf einem Datumsvergleich beruhen, entweder nicht oder zu früh oder zu spät oder zu oft ausgeführt werden. Da schon heutige Datumswerte mit solchen aus dem Jahre 2000 oder danach verglichen werden, kann es schon zu technischen oder betrieblichen Fehlentscheidungen gekommen sein, die bisher unbemerkt geblieben sind.

1.2.4

Unglücklicher Erfolg

Wie konnte es soweit kommen? „Viele Programmierer und EDV-Leiter erklären, alle Softwarekunst stamme von der Lochkarte ab und sei in Zeiten teueren Speichers geboren. Auf der Lochkarte mit ihren 80 Stellen sei kein Platz für die Anzahl der Jahrhunderte gewesen und die Abspeicherung von zwei extra Ziffern bei jeder Datumsangabe sei zu kostspielig gewesen. Danach sei es notwendig gewesen, zu den so programmierten Altsystemen kompatible Neusysteme zu entwickeln." (H01)

1 Einleitung

26

Korrekt daran ist sicher, daß Programme in der Vergangenheit mit knappem Arbeitsspeicher auskommen mußten. Doch bei allen kaufmännischen Anwendungen war der externe Speicher, nämlich die Abspeicherung auf Magnetband, weder knapp noch teuer. Nur technische Anwendungen, die in sehr kurzer Zeit reagieren sollten, konnten keine langsamen, externen Speicher nutzen und mußten in der Vergangenheit mit teuerem Arbeitsspeicher umgehen. Bei kaufmännischen Anwendungen, die eine zweistellige Jahreszahl nutzen, ist eher ein Designfehler zu vermuten. Man unterschied nicht sauber zwischen Eingabe und Darstellung von Datumsfeldern für die Benutzer und deren Abspeicherung. Zwei Bytes für die Aufnahme einer zweistelligen Jahreszahl haben seit den Ursprüngen der Datenverarbeitung 16 Bit und damit Platz für 65 536 verschiedene Werte. Man hat damals die Eingabemöglichkeiten der Tastatur mit den Speichermöglichkeiten des Rechners verwechselt Zudem ist die Nutzung von alphanumerischen oder numerischen, aber nicht binären, Datentypen der Länge zwei für die jeweilige Abspeicherung der Datumsbestandteile sowieso eine große Verschwendung: •

Die Tageszahl kann maximal 31 sein und nutzt damit 0,05 % der Kapazität von zwei Bytes.

•

Die Monatszahl kann maximal 12 sein und nutzt damit 0,02 % der Kapazität von zwei Bytes.

•

Die Jahreszahl kann maximal 99 sein und nutzt damit 0,15 % der Kapazität von zwei Bytes.

Nach dem Sündenfall stellte sich die so entwickelte Software als nützlich und nahezu unersetzlich heraus. Es gab keinen Grund dafür und man hatte auch vor lauter Neuentwicklungen keine Zeit oder einfach keine Lust, sie zu ersetzen. Die Erfindung der Betriebssysteme und der Compiler verhalf den auf ihnen aufbauenden Programmen zur weitgehenden Unabhängigkeit von der eingesetzten Hardware. Die Programmtexte wurden von dem ausfuhrenden Prozessor abgeschirmt. Man konnte nun zu immer leistungsfähigen Systemen übergehen, ohne die Software anpassen zu müssen. Da man auf diese Weise große Mengen vor langer Zeit entwickelter Software besaß, bestimmte diese Software die Tradition der Programmierung, eben als die Erbsünde: zwei Stellen für die Jahreszahl waren üblich! Sind auch heute noch zwei Stellen für die Jahreszahl üblich?

1.2.5

Verschüttetes Wissen

Seit wann weiß man darüber Bescheid? Das erste Projekt des Autors als Systemanalytiker war die Einführung einer Betriebsdatenerfassung in einem Walzwerk im Jahre 1981. Programme mit zweistelligen Jahreszahlen waren zu dieser Zeit üblich

1.2

Jahrhundertprobleme

27

und eine kritische Diskussion mit Kollegen erbrachte oft genug die Aussage: „1999 fahren wir alle in Urlaub und 2000 kommen wir noch nicht zurück.", in der Erwartung, daß dann alle Welt die Programmierer verantwortlich machen wird. Soweit zu den persönlichen Eindrücken. Eher objektive Kriterien, ab wann bestimmte Kreise über das Thema Bescheid wissen sollten, kann man der folgenden Tabelle entnehmen, die einige markante Ereignisse auflistet. Tabelle 2: Jahre besonderer

Informationsereignisse

1970

Überlauf des Zeitzählers bei der IBM 360

1984

Buch zum Jahr 2000 Problem erscheint in den USA (M03)

1986

IBM Kunden in den USA werden informiert (001)

1990

Banken und Versicherungen schließen zehnjährige Verträge ab

1990

EDV-Manager in den USA werden informiert (X01,S03)

1991

Versicherungen in den USA werden informiert (H02)

1996

Deutsche Telekom: 1.1.1996 wird nicht als Feiertag erkannt (G02)

Die Zeitzählung im Kalender, in technischen Systemen und im Rechner wird im nächsten Kapitel behandelt. Die gedruckte Information hat die Verantwortlichen in den U S A deutlich eher erreicht als in Deutschland. Doch auch hier haben Banken und Versicherungen schon frühzeitig auf das Jahr 2000 reagieren müssen, aber oft nur f ü r die gerade betroffene Anwendung und wahrscheinlich im Rahmen der normalen Programmwartung. So wurde das Thema nicht umfassend als das Jahr 2000 Problem erkannt. Die letzte Zeile der Tabelle soll auch darauf hinweisen, daß Datumsprobleme mit erheblichen Folgekosten verbunden sein können. Die Deutsche Telekom mußte für die Korrektur aller Abrechnungsdaten und die Information der Kunden einen zweistelligen Millionenbetrag aufwenden.

1.2.6

Was folgt daraus?

=> Die Datumsarithmetik und das Design von Anwendungen sind die kritischen Elemente bei der Verarbeitung von Datumswerten. => Jeder sollte sich eine Sammlung von Routinen für Berechnungen und insbesondere Datumsberechnungen zulegen und nur diese in allen seinen Programmen benutzen. => Wir wollen hoffen, daß das Jahr 2000 Problem das einzige Jahrhundertproblem der E D V im ersten Jahrhundert der E D V bleibt.

1 Einleitung

28

1.3

Kalendergeschichten

•

Sonne, Mond und Sterne

•

Ägypter, Römer und Christen

•

Astronomen, Techniker und Programmierer

•

Sonnenuhr, Rechneruhr und Funkuhr

•

Was folgt daraus?

Die Zeitmessung, der Kalendergebrauch und auch der christliche Kalender, den wir heutzutage auf dem Computer nutzen, haben eine Geschichte. Die Genauigkeit der Uhren und die komplizierte Abbildung verschiedener Zeitmeßverfahren aufeinander sorgen für zahlreiche Kalendergeschichten.

1.3.1

Sonne, Mond und Sterne

Bisher wurde über das Jahr 2000 Problem gesprochen, um dessen vielfältigen Probleme darzustellen. Nun soll von Datum und Uhrzeit und dem Jahr 2000 die Rede sein, natürlich mit Bezug auf die EDV. Jede Bewegung erinnert uns an den Zeitablauf. Um die Zeit zählbar und meßbar zu machen, nutzen wir Bewegungen, die sich regelmäßig wiederholen. Man findet mehrere natürliche und technische Bewegungen mit dieser Eigenschaft. Welche das sind, wie sie aufeinander abzubilden und wie regelmäßig sie sind, ist das Thema dieses Kapitels. Beginnen wir mit Tageslänge, der Dauer des Wechsels von Tag und Nacht. Man kann die Zeitdauer der Erdumdrehung auf den Sonnenstand beziehen. Die Dauer dieses wahren Sonnentages ist von der Jahreszeit abhängig, da die Erde auf ihrer elliptischen Bahn um die Sonne in Sonnennähe schneller und in Sonnenferne langsamer läuft. Also nimmt man ein Mittel und setzt diesen mittleren Sonnentag zu 24 Stunden oder 1440 Minuten oder 86 400 Sekunden an. Die Erde rotiert jedoch nicht gleichmäßig. Die Gezeitenreibung verlangsamt die Erddrehung und verlängert damit den Sterntag um 0,0016 Sekunden pro Jahrhundert. Die Verlagerung von Gesteinsmassen im Erdinnern kann den Tag im Laufe von Jahrzehnten um 0,005 Sekunden verlängern, aber auch um 0,002 Sekunden verkürzen. Die jahreszeitliche Verlagerung von Luftmassen verkürzt oder verlängert die Tage im Laufe eines Jahres um bis zu 0,0011 Sekunden.

/. 3

Kalendergeschichten

29

Nun kommen wir zur Jahreslänge. Man kann sich an den Mondphasen orientieren und bezeichnet die zwölfte Wiederkehr einer Mondphase als Mondjahr. Ein so definiertes Mondjahr dauert dann 354,3671 Tage. Mann kann sich auch am Sonnenstand orientieren und bezeichnet die Wiederkehr des höchsten oder niedrigsten Sonnenstandes als Sonnenjahr. Ein so definiertes Sonnenjahr dauert dann 365,2422 Tage.

1.3.2

Ägypter, Römer und Christen

Die Mondphasen sind leicht zu beobachten. Viele älteren Kalender bauen daher auf dem Mondjahr auf. Sie bemühen sich, das Mondjahr mit dem um etwa 11 Tage längeren Sonnenjahr in Übereinstimmung zu halten. Die neueren Kalender bauen auf dem Sonnenjahr auf. Sie übernehmen die zwölf Monate des Mondjahres und bemühen sich, den Bruchteil eines Tages, um den die Umlaufdauer der Erde um die Sonne länger als ein Jahr mit 365 Tagen ist, in den Kalender einzuarbeiten. Übrigens sorgte erst Kaiser Augustus dafür, daß der Julianische Kalender ab 8 v.Chr. korrekt gehandhabt wurde. Nach dem Tod von Julius Cäsar (44 v.Chr.) hatte man jedes dritte Jahr zum Schaltjahr gemacht (A01). Als Verbesserung für den Gregorianischen Kalender wird überlegt, den Fehler von einem Tag auf 3323 Jahre durch den künftigen Ausfall eines Schalttages zu korrigieren. Wie man der Tabelle entnimmt, haben wir es Julius Cäsar zu verdanken, daß das Jahr 2000 ein Schaltjahr wird, und Papst Gregor XIII., daß das Jahr 1900 kein Schaltjahr war. Die christliche Zeitrechnung zählt die Jahre ab Christi Geburt, beginnt also mit dem Jahr Eins. Diese Zählweise wurde erst im Jahre 532 von Dionysius Exiguus eingeführt. Vorher bediente man sich der römischen Zählung ab der Gründung Roms (753 v.Chr.). Jeweils umgerechnet auf die christliche Zählweise beginnt die Jahreszählung bei den Juden mit dem Jahr 3761 v.Chr., die buddhistische mit dem Todesjahr Buddhas 483 v.Chr., die islamische mit der Hedschra 622 n.Chr. Das heißt, bis zum Jahre 2000 nach christlicher Rechnung haben diese anderen Zeitrechnungen keinen Jahrhundertwechsel.

1

30 Tabelle 3: Kalender der Völker (aus: Bertelsmann Universallexikon

Einleitung

1995)

Kalender der

Urheber/ Geltungsdauer

Kalenderberechnung

Schaltverfahren

Ägypter

seit dem 4. Jahrtausend v. Chr.

reines Sonneniahr zu 365 Tagen; 12 Monate zu je 30 Tagen + 5 Zusatztage reines Sonneniahr zu 365% Tagen Mondjahr zu 10, seit dem König Numa (715 v. Chr.) zu 12 Monaten reines Sonneniahr zu 365'/4 Tagen

keine Schalttage; Jahresanfang durchläuft in 1461 ägyptischen Jahren das ganze Jahr vermutlich in jedem 4. Jahr 1 Schalttag unregelmäßig

238 v. Chr. Römer

Moslems

8. u. 7. Jh. v. Chr. und auch später Julius Cäsar (46 v. Chr.) Julianischer Kalender seit 16. Juli 622 (Hedschra)

Juden

bis Beginn unserer Zeitrechnung Reform (vielleicht Rabbi Samuel 338)

Neuzeit

Papst Gregor XIII. Gregorianischer Kalender: in den katholischen Ländern seit 15. Okt. 1582, im protestantischen Deutschland nach 18.2 auf 1. März 1700, England 1752, Schweden 1753, Japan 1873, Bulgarien, Türkei 1916, UdSSR 1918, Rumänien 1919, Griechenland 1923, China 1949

reines Mondjahr

jedes 4. Jahr ein Schalttag

30jähriger Zyklus, in dem 1 lmal je ein Tag eingeschaltet wird; unabhängig davon 7tägige Woche; Tage beginnen mit Sonnenuntergang

bei Bedarf ein ganzer Monat eingeschaltet Monate abwechselnd 29 u. 30 Tage 19jähriger Zyklus; Jahreslängen Mond-Sonneniahr mit 353, 354 oder 355 Tagen; Schaltjahre mit 383, 384 oder 385 Tagen; Schaltjahre sind die Jahre 3,6, 8, 11, 14, 17, 19 des Zyklus reines Sonneniahr zu 365 bei Ersteinführung folgte auf den 4. Okt. 1582 des seitherigen Tagen Julianischen Kalenders sofort der 15. Oktober 1582. Der Frühlingsanfang wurde auf den 21. März gelegt; jedes 4. Jahr zu 366 Tagen, mit Ausnahme der durch 400 nicht teilbaren Jahrhunderte.

1.3

1.3.3

Kalendergeschichten

31

Astronomen, Techniker und Programmierer

Da Astronomen die Tage und Jahre über große Zeiträume verfolgen, möchten sie sich unabhängig vom jeweiligen Kalendergebrauch über Tag und Uhrzeit verständigen. Sie benutzen daher eine sogenannte Julianische" Tageszählung. Die Zählung erfolgt ab 12 Uhr mittags (GMT) des 1. Januar 4713 v.Chr. Der 1. Januar 2000 wird ab 12 Uhr der julianische Tag mit der Nummer 2451545 sein. Uhrzeitangaben erfolgen in Bruchteilen eines Tages mit einer Präzision von 0,0001 (8,64 Sekunden). (A01) Der christliche Kalender kennt kein Jahr Null, anders als der astronomische. Das astronomisches Jahr - 6 , übrigens das tatsächlich wahrscheinlichste Jahr der Geburt Christi, entspricht also dem historischen Jahr 7 v.Chr. Daher wird nach christlicher Zählung das Jahr 2000 das letzte Jahr des zweiten Jahrtausends sein, nach astronomischer Zählung wird es das erste Jahr des dritten Jahrtausends sein. Man kann natürlich noch weitergehen als die Astronomen und den Speicherbereich von 6 Byte oder 48 Bit, in dem heute das Datum als Jahr (zweistellig), Monat, Tag gespeichert ist, für eine neuartige Tageszählung nutzen. Das erste Bit enthält die Kennung für die neue Zählung, in den restlichen 47 Bit hat man dann Platz um jedem Tag aus einem Zeitraum von 352 Milliarden Jahren eine Nummer zu geben. Das sollte ausreichend sein, wenn man bedenkt, daß das Alter des Universums derzeit auf kleiner als 20 Milliarden Jahre angesetzt wird. Neben den offiziellen Kalender gibt es in einigen Unternehmen sogenannte Betriebskalender. Diese lassen zum Beispiel den nächsten Tag am Anfang (z.B. 22 Uhr) oder am Ende (z.B. 6 Uhr) der Nachtschicht beginnen. Zuweilen werden auch extra Tage, die es im christlichen Kalender nicht gibt, für Inventurzwecke erfunden. Vielleicht hilft es nicht Jahr 2000 fähigen Anwendungen auch, als vorübergehende Notlösung für das Jahr 1999 einen 13. Monat einzuführen, um über die nächste Zeit noch Buchungen für das Jahr 2000 annehmen zu können. Betriebskalender könnte man auch nutzen, um eine eigene Jahreszählung einzuführen. Wenn man gegenüber dem christlichen Kalender um 28 Jahre (7 Tage pro Woche und jedes 4. Jahr ein Schaltjahr) zurückbleibt, erhält man die gleichen Wochentage und 28 Jahre extra Zeit, sich um das Jahr 2000 Problem zu kümmern. Von der Definition eines Kalenders ist die Kalendernutzung zu unterscheiden. Für die Darstellung von Datumswerten auf Geräten und Listen gibt es verschiedene Standards. Sie empfehlen eine vierstellige Darstellung des Jahres, erlauben aber auch eine zweistellige. Datumswerte sind mit Tageszahl im Monat (TT), Monatszahl (MM) und Jahreszahl (JJ) oder (JJJJ) „gregorianisch" darzustellen als JJJJMMTT oder JJMMTT sowie mit Tageszahl im laufenden Jahr ,julianisch" als JJJJTTT oder JJTTT.

32

1

Einleitung

Allerdings sagen sie auch, daß der Datenfeldname für das Jahr bei zweistelliger Jahresangabe „Year of Century" sein soll (D01). Dem Autor ist kein Programmtext bekannt, der dieser Empfehlung folgt. Interessant ist auch, daß der Standard ein extra Feld für das Jahr vorsieht, wie es sich für eine „normalisierte" Abspeicherung auch gehört. Ein Datum setzt sich aus Jahr, Monat, Tag zusammen und ist daher kein elementarer Datentyp. Standards für die Datumsdarstellung: •

ANSI X3.30 - 1985 / FIPS 4-1 Representation for Clendar Date and Ordinal Date for Information Interchange

•

ISO 8601 - 1988-06-15 Data elements and interchange formats / Information interchange / Representation of dates and times

Bei der Eingabe oder Ausgabe von Jahreszahlen mag man zur Vereinfachung auf die Angabe des Jahrhunderts verzichten. Hauptsache man geht mit korrekt gespeicherten Jahreszahlen korrekt um. Die Darstellung eines Datums kann technisch gehalten sein (JJMMTT) oder nationale Besonderheiten berücksichtigen: MM/TT/JJ (USA) oder TT.MM.JJ (Kanada und Europa). Zudem kann die Stellung des Jahreswertes im Datum bei Jahreszahlen größer als 40 frei gewählt werden, also statt MM/TT/JJ auch JJ/MM/TT. Ab dem Jahr 2000 besteht sicher die Tendenz, vierstellige Jahresangaben vorzuziehen, um die Interpretation von z.B. 2.1.0 oder 1.1.1 (europäische Darstellung) zu erleichtern und gegen Ordnungsnumern abzuheben. Rechtliche und finanzielle Dokumente erhalten erst mit der Angabe von JJJJMMTT einen eindeutigen Datumsstempel.

1.3.4

Sonnenuhr, Rechneruhr und Funkuhr

Die Sonnenuhr bildet die wahre Sonnenzeit direkt ab. Quarzuhren zählen die Sekunden. Als Basiseinheit ist die Sekunde das 9 192 631 770fache der Periodendauer der dem Übergang zwischen den beiden Hyperfeinstrukturniveaus des Grundzustands von Cäsium (133) entsprechenden Strahlung. Seit 1955 berechnet das Internationale Büro für die Zeit in Paris unter Berücksichtigung der Anzeigen verschiedener Cäsiumuhren die Internationale Atomzeit (Temps atomique international, TAI). Da die astronomische Zeit nicht genau mit dieser Definitionen der Zeit übereinstimmen, wurde es erforderlich, eine Richtzeit zu vereinbaren, die sich immer wieder an die astronomische Zeit anpaßt. Durch das gelegentliche Einfügen einer zusätzlichen Schaltsekunde weicht die Koordinierte Weltzeit (Universal Time Coordinated, UTC) nie mehr als 0,9 s von der TAI ab. Diese UTC wird auch per Funk als gesetzliches Zeitnormal abgestrahlt.

1.3

Kalendergeschichten

33

Rechneruhren zählen die Tausendstel oder Millionstel Teile einer Sekunde ab einem Startzeitpunkt. Wie bei allen Additionen in Rechnern wird die Abspeicherung des Zählerwertes irgendwann - hoffentlich bei allen heute eingesetzten Computern erst in ferner Zukunft - zu einem Überlauf fuhren. Für die Rechneruhren als Zeitzähler gibt es keinen Standard; sie sind über Hardware oder Software realisiert. Diese Zähler sind nicht, obwohl sie so kleine Teile einer Sekunde zählen, f ü r große Präzision konstruiert. Der Zählerstand soll vielmehr o f t nur als eindeutige N u m m e r dienen, die z.B. alle Datenänderungen einer bestimmten Transaktion genau kennzeichnet. Bei durchaus üblichen mehr als 1000 Transaktionen pro Sekunde reicht die Zählung der Tausendstel-Sekunden dafür nicht aus. Die Uhrzeit kann manuell korrigiert werden und oft auch automatisch durch Vergleich mit der Zeitvorgabe anderer Rechner oder einer Funkuhr. Auf Grund der Erddrehung ist die wahre Ortszeit um 4 Minuten pro Längengrad verschoben. Um nicht allzu oft bei einer Reise die Uhren umzustellen und um die Ortszeiten vergleichbar zu haben, einigte man sich auf 24 Zeitzonen mit einheitlicher Zeit und jeweils einer Stunde Verschiebung. Die Zeitzonen sollten entlang eines Längengradkreises verlaufen, aus politischen Gründen ist das nicht immer der Fall. Auf die Zeitzone bezieht man sich mit der amtlichen Bezeichnung (wie z.B. M E Z , Mitteleuropäische Zeit) oder durch die Angabe des Unterschieds zur Greenwich Mean Time (GMT). Um das wirtschaftliche Leben besser dem Tageslicht anzupassen, wird in den Sommermonaten die Uhr um eine oder zwei Stunden gegenüber der Zeitzonenzeit vorgestellt. Die Umschaltung und auch die Zurückschaltung geschieht in verschiedenen Ländern an unterschiedlichen Kalendertagen. Die per Funk verteilte Uhrzeit berücksichtigt diese Sommerzeit. Sensible Produktionen fährt man j e d o c h besser über einen Zeitzähler. Mit der automatischen Umstellung auf Sommerzeit wird sonst eine Stunde zu kurz oder eine Stunde zu lange produziert. Die Datenabspeicherung sollte f ü r Zeitstempel eine Kennung vorsehen, um doppelte Uhrzeitangaben bei der Zurückschaltung der Sommerzeit auseinanderzuhalten. Echtzeitsysteme sollten auch wegen der Schaltsekunden nicht der Funkuhr vertrauen. Alle genannten Besonderheiten des Kalenders und der Uhrzeit sollte die Zeitdarstellung im Rechner berücksichtigen. Datum und Uhrzeit wird vom Betriebssystem durch die Umrechnung des rechnerinternen Zeitzählerstandes auf eine kalendarische Zeit bereitgestellt. Programme können sowohl den Zählerstand als auch zu das davon abgeleiteten Datum bzw. die davon abgeleitete Uhrzeit auslesen. Die Art und Weise des verwendeten Ausleseverfahren unterscheidet sich nach Rechner und Programmiersprache. Es gibt Computer und Programmiersprachen, die die Jahreszahl im generierten Datum nur unvollständig, nämlich zweistellig anbieten.

34

1

Einleitung

Wenn man als Programmierer vergangene Zeiten errechnet, sollte man vorsichtig bei der Angabe von Jahren, Tagen, Stunden und Sekunden sein. Das Jahr Null gibt es im christlichen Kalender nicht. Das Tagesdatum war vor der Einführung des gregorianischen Kalenders fehlerhaft und bei der Einführung fielen je nach Land und Jahr zehn oder mehr Tage aus. Die Stunde muß die Sommerzeit berücksichtigen und mit ausgefallenen und doppelten Stunden beim Ein- und Ausschalten der Sommerzeit zurecht kommen. Die Einfügung von Schaltsekunden erfolgt unregelmäßig.

1.3.5

Was folgt daraus?

Das Jahr 2000 Problem hat für sein Auftreten vier notwendige Voraussetzungen: => Die Erde muß sich regelmäßig um die Sonne bewegen, damit so etwas wie ein Jahr überhaupt definiert werden konnte. => Die Jahreszählung erfolgt im Zehnersystem. Im 60er- oder 16er-System gibt es demnächst kein Jahr 2000 Problem. => Auf dem Computer ist eine christliche Zeitrechnung in Gebrauch. Das Jahr Eins liegt bei anderen Kalendern auf ganz anderen Jahren und damit gibt es dann dort auch kein Jahr 2000 Problem. => Ein Computer bemüht sich, leider unzureichend, den christlichen Kalender abzubilden. Bei einer korrekten Abbildung gibt es natürlich kein Jahr 2000 Problem.

1.4

Das Problem in Deutschland

•

Bestandsaufnahme

•

Kosten für einzelne Unternehmen

•

Auswege

•

Was folgt daraus?

Das Jahr 2000 Problem betrifft weltweit alle Computer, also auch die Systeme, die in Deutschland stehen. In Deutschland kommt verschärfend hinzu, daß es sowohl an der nötigen Aufmerksamkeit für das Jahr 2000 Problem als auch an der nötigen Bereitschaft fehlt, sich dieses Problems ernsthaft anzunehmen.

1.4 Das Problem in Deutschland

1.4.1

35

Bestandsaufnahme

Beginnen wir mit drei kürzlich durchgeführten Umfragen, eine weltweit, eine in Europa und eine nur in Deutschland. Die M E T A Group sagt zu den Ergebnissen ihrer U m f r a g e vom Frühjahr 1997: „Eine kürzlich durchgeführte META-Umfrage bei 1200 weltweit agierenden Unternehmen (Mainframe-User) ergab, daß 56% bereits einen Jahr-2000Aktionsplan entwickelt haben und sich in der Umsetzungsphase befinden. 2 0 % haben sich für eine Überprüfung entschieden und entwickeln derzeit einen Projektplan. Weitere 2 0 % haben noch keine Entscheidung getroffen und 4 % sehen kein Datumsproblem." (P01) Man hat nur große Unternehmen gefragt, die weltweit tätig sind und sich einen Mainframe, also einen Zentralrechner für sehr viele gleichzeitige Nutzer, leisten können. Solche Unternehmen entwickeln selbst in großem U m f a n g Software für ihre eigenen Zwecke und sollten somit das Problem abschätzen können. Der Mittelstand setzt zwar auch sehr viele Programme auf sehr vielen Rechnern ein, hat aber relativ dazu nur eine kleine Entwicklungs- und Wartungsmannschaft. Die 4 % der Unternehmen, die kein Datumsproblem sehen, haben entweder ihre Systeme immer schon richtig entwickelt oder sie sind blind oder sie sind kurzsichtig, da sie ihre Software bei einem „Outsourcing"-Dienstleister nicht mehr sehen können. Erstaunlich ist, daß von diesen großen Unternehmen 4 4 % noch keinen Plan für ein Jahr 2000 Projekt haben. In Deutschland wird dieser Anteil eher höher sein als der weltweite Durchschnitt. Diese Ansicht wird - zahlenmäßig erstaunlich übereinstimmend - gestützt von der europaweiten U m f r a g e von N e a m a n Bond Associates, die von softlab, einem deutschen Softwarehaus, gefördert wurde. Im Oktober 1996 wurden 840 Unternehmen befragt, im März 1997 noch einmal 697 Unternehmen, so daß eine gewisse Entwicklung abgeleitet werden kann. „Im Oktober 1996 sahen lediglich die Hälfte unserer Befragten das Problem als wirklich ernsthaft an. In der jetzigen Studie teilen immerhin 56% diese Ansicht. Der Rest betrachtet die Jahr 2000-Umstellung als geringfügig bzw. als überhaupt nicht problematisch, besonders häufig war diese Ansicht in Deutschland vertreten." (N01) Wieder finden sich 4 4 % der Unternehmen, die das Problem nicht ernsthaft angehen wollen. „75% der Befragten gaben an, daß sie über eine Strategie verfügen, aber nur 2 5 % wissen, wieviel Programmcode betroffen ist, noch größere Unsicherheit herrscht in Bezug auf Desktop- und verteilte Systeme" „65% der Befragten

36

1

Einleitung

gaben an, daß ihr Vorstand die Auswirkungen der Euro- und Jahr 2000Problematik versteht, aber nur 34% haben ein Budget zur Implementierung ihrer Strategie ausgewiesen." (N01) Eine Strategie zu haben, kann natürlich bedeuten, daß man das Problem untersucht hat, es dem Vorstand vorgestellt hat und man es für so geringfügig erachtet, daß man es im Rahmen der normalen Wartung wird lösen können. Verwunderlich ist wieder, daß mehr als ein Drittel der Unternehmen, die das Problem als wirklich ernsthaft ansehen, noch kein Budget haben und weniger als die Hälfte davon sich noch nicht wirklich mit den betroffenen Programmen bzw. mit allen vorhandenen Systemen in ihrem Unternehmen auseinandergesetzt haben. In Deutschland wurde im Juni 1997 von der Kölnische Rück Research, dem Institut einer Rückversicherung, eine Umfrage bei 204 Unternehmen, beschränkt auf die Branchen Banken, Chemie, Maschinenbau durchgeführt. (Q02) Der Kölnische Rück wir man wohl kaum kommerzielle Interessen im Softwaremarkt nachsagen können, trotzdem antworteten nur 124 Unternehmen. Davon befassen sich 83% mit dem Problem. Umgekehrt heißt das, etwa die Hälfte der deutschen Unternehmen in den genannten Branchen, in denen sogar noch eine Dominanz großer Unternehmen gegeben ist, erkennt die Bedeutung des Jahr 2000 Problems nicht. Von den Unternehmen, die sich mit dem Problem befassen, haben nur knapp die Hälfte ein zentrales, abteilungsübergreifendes Projektmanagement und nur in knapp einem Drittel ist es gelungen, Geschäftsführung oder Vorstand in irgend einer Form einzubinden. Der Stellenwert des Problems wächst mit der Unternehmensgröße und ist bei Banken am höchsten von den drei befragten Branchen. Allerdings hat das Jahr 2000 Problem nirgendwo die höchste Priorität. „Die Banken sind mit ihren Projekten im Regelfall weiter als die Industrie, mit Projekten, die teilweise schon Ende der 80er Jahre begonnen haben. Dies ist erklärlich, wenn man beispielsweise an 10-jahres Hypotheken denkt. Weniger erklärlich ist, daß trotzdem einige Banken erst relativ am Anfang stehen." (Q01) Die problematischen Anwendungsbereiche, die mit Ausnahme der Anlagensteuerung etwa gleich häufig von allen Unternehmen genannt werden, sind die folgenden: Buchführung, Fakturierung, Fertigungs- und Auftragssteuerung sowie Logistik. Für die Chemiebranche wird sowohl ein mangelndes Problembewußtsein angeführt als auch besonders großer wirtschaftlicher Schaden bei Untätigkeit befürchtetet.

1.4 Das Problem in Deutschland

37

Nur 40% der Unternehmen mit Jahr 2000 Projektvorhaben beziehen Schnittstellen mit Partnern, Lieferanten oder Kunden in das Projekt ein, nur 25% verlangen bisher eine Bestätigung der Jahr 2000 Fähigkeit von ihren Lieferanten. Immerhin schon mehr als 10% der Unternehmen erklären ihr Jahr 2000 Projekt für abgeschlossen oder sagen, daß ihre abschließenden Systemtest gerade durchgeführt werden. Andererseits haben 10% der Unternehmen, die etwas tun wollen, noch nicht einmal mit der Planung begonnen, die anderen 80% der engagierten Unternehmen realisieren, analysieren oder projektieren.

1.4.2

Kosten für einzelne Unternehmen

„Von der (für Deutschland) geschätzten Gesamtsumme, zwischen 70 und 150 Milliarden Mark, entfallen auf den deutschen Staat, seine Länder und Kommunen - Bundeswehr, Finanzämter, Krankenkassen, Verkehrsbetriebe und viele andere - mindestens 10 bis 15 Milliarden Mark an Umstellungskosten." (1997,S05) Vor zwei Jahren wurden noch Gesamtkosten zwischen 40 und 60 Milliarden DM angegeben (1995,S01). Je mehr Unternehmen sich mit dem Jahr 2000 Problem auseinandersetzen, desto höher werden die gesamten Kosten in Deutschland noch steigen. Einzelne Unternehmen haben folgende Budgets bekannt gegeben (nach S04); für den Mittelstand liegen nur Schätzungen vor. Tabelle 4: Budgets einzelner

Unternehmen.

Allianz

14 Millionen DM

Commerzbank

48 Millionen DM

Deutsche Bank

95 Millionen DM

Bayerische Hypotheken und Wechselbank

abgeschlossen

VW

fast abgeschlossen

Siemens Mittelständische

> 100 Millionen DM 119 Millionen DM 158 Millionen DM

Unternehmen

lt. Gärtner Group (nach M07)

4 Millionen US$

lt. Kalkulation des Autors (s. Kap. Projektmanagement)

6 Millionen DM

Neben den wirtschaftlichen tätigen Unternehmen sollte man den Staat und seine Institutionen nicht vergessen. Für den öffentlichen Dienst in Deutschland ist mit extra Kosten von 10 bis 15 Milliarden DM zu rechnen. In Großbritannien werden

38

1

Einleitung

die dafür erwarteten Kosten in einer ähnlichen Größenordnung angegeben, nämlich zu 2 bis 4 Milliarden Pfund (H04). Immerhin wurde sogar auf der letzten Wirtschafts- und Handelskonferenz wichtiger Industrieländer in Denver (G-7) beschlossen, im Jahr 1998 eine Tagung zum Thema „Jahr 2000 Softwareumstellung" durchzuführen und dann allen beteiligten Regierungsstellen zu helfen, mit dem Problem fertig zu werden (103). Es stellt sich natürlich die Frage, wann diese Initiative in Deutschland aufgenommen und unterstützt wird.

1.4.3

Auswege

Einige suchen einen Ausweg, indem sie dem Problem aus dem Wege gehen oder das Problem verschweigen. Diese Ansicht wird bestätigt von einer Umfrage, die die Initiative 2000, ein Zusammenschluß von Lösungsanbietern zum Jahr 2000 Problem, kürzlich mit ca. 500 Unternehmensleitern in Deutschland durchgeführt hat (104): „Wurden Sie von Ihren IT-Verantwortlichen über das Jahr-2000-Problem informiert? JA: 28 % - NEIN: 62 %". In den 80er Jahren (dieses Jahrhunderts) hat der Verfasser zu diesem Problem von den Verantwortlichen gehört, „es ist noch lange Zeit bis zum Jahr 2000", „dafür bin ich nicht zuständig", „dann bin ich sowieso in Rente". Viele Programmierer stellten sich dem Problem - allerdings mit der Aussage, „nach uns die Sintflut". Heutzutage hört man dazu, „wir haben kein Geld", „wir haben keine Zeit", „wir haben keinen Auftrag" oder „bei uns gibt es Richtlinien zur Entwicklung von Softwaresystemen". Mittlerweile ist es höchste Zeit, das Problem in Angriff" zu nehmen, auch da wo es Richtlinien gibt. Wer hat denn wie genau die korrekte Umsetzung der Richtlinien in die Programme kontrolliert? Ein Projektkoordinator wird Budgets und Verantwortlichkeiten verteilen. Die heutigen Programmierer werden die Situation wohl selber bewältigen müssen und nur der Vorruhestand wird die heutigen DV-Leiter vor dem betrieblichen Jahr 2000 Problem bewahren. Die kommende EURO-Einführung hätte ein Motiv für einen frühen Beginn eines Jahr 2000 Projektes sein sollen. Dann hätte man nämlich beide Wartungsprozesse noch kombinieren können. So wird man nur eines nach dem anderen erledigen können. Ab dem 1.1.1999 darf die EURO-Währung für Geschäftsabwicklungen benutzt werden, wenn beide beteiligten Geschäftspartner damit einverstanden sind. Diese Gelegenheit ist nun vorbei. Im Jahr 1998 und 1999 wird man sich wohl oder übel mit einem Jahr 2000 Projekt beschäftigen müssen. Das Projekt durch zusätzliche Anforderungen zu verzögern, wird sich niemand erlauben. Der EURO wird allge-

1.4 Das Problem in Deutschland

39

mein verbindlich, als Bargeld und auch f ü r Abrechnung mit Behörden, ab dem 1.1.2002. Mindestens bis Mitte 2000 wird man mit den Auswirkungen der Jahr 2000 Krise beschäftigt sein; direkt danach und bis Ende 2001 muß man sich dann um das EURO-Projekt kümmern. Einige suchen einen Ausweg, indem sie das Jahr 2000 Problem gemeinsam entschärfen. Man kann natürlich von dem Vorsprung der USA profitieren, indem man die dortigen Erfahrungen auswertet und die Werkzeuge nutzt, die sich dort bewährt haben. Diese Auswertung ist sicher auch ein Ziel des vorliegenden Buches. Man kann auch ein wenig über die Nachbargrenze schauen: „Die Mitglieder (des Club Informatique des Grandes Entreprises Françaises - CIGREF), die durch hochgesetztes Tagesdatum in ihrer Großrechnerumgebung den Übergang simulierten, registrierten ausnahmslos Systemabstürze, mitunter in weniger als einer Minute. In einigen Fällen kam es zu Fehlzuordnungen und Datenverlusten in den Datenbanken. Bereits der Jahreswechsel 1998/1999 kann zu Chaos führen; es stellte sich nämlich heraus, daß in älteren Anwendungssystemen die Zahlen „00" und „99" im Feld der Jahreszahl als Fehlercodes definiert waren." (G03) Die französischen Erfahrungen unterstreichen noch einmal die Bedeutung des Problems und seine verschiedenartigen Ausprägungen. Wurden solche Tests auch schon in Deutschland angestellt und gemeinschaftlich ausgewertet? Gibt es auch einen Computerclub des Bundes der deutschen Industrie? In Großbritannien wurde die „Taskforce 2000" eingerichtet, eine Organisation, die durch die finanzielle Unterstützung der britischen Regierung ermöglicht wurde und gemeinsam von der C S S A - Computer Software and Services Association und der CBI - Confédération of British Industry getragen wird. Diese Organisation veranstaltet nationale Tagungen, gibt die Zeitschrift „Millennium Watch" heraus und kooperiert mit Anwendervereinigungen zum Jahr 2000 Problem, von denen es in Großbritannien drei gibt. Immerhin: „In Großbritannien hat sich die Anzahl der Unternehmen mit einem Jahr2000-Budget von 18% auf 34% nahezu verdoppelt." (N01), und zwar im Laufe von einem halben Jahr. Kürzlich wurde in den Niederlanden eine ähnliche Initiative ergriffen: „Vor einem Monat beschloß das niederländische Parlament zusammen mit der Wirtschaft eine Aufklärungskampagne zur Datumsumstellung zu starten. Mit dem Ex-Philips-Mann Jan Timmer wurde nun ein sehr bekannter Topmanager zum Vorsitzenden ernannt. In Deutschland ist das Problem der Datumsumstellung mittlerweile bei den großen Unternehmen bekannt, jedoch fehlt noch eine ähnliche Unterstützung vom Staat, um auch den Mittelstand wachzurütteln." (104)

40

1

Einleitung

Eine solche Organisationsform kann ein Modell für Deutschland sein. Allerdings müßte dann die Bundesregierung eine offizielle Stellungnahme zur Bedeutung des Jahr 2000 Problems abgeben, was sie bisher nicht getan hat. Und prominente Institutionen wie BDI, BDU und DIHT müßten öffentlich ihre Unterstützung zusagen. Unter der Adresse http://www.ispo.cec.be/y2keuro/year2000.htm finden sich Informationen der EU über die eigenen und über die Jahr 2000 Aktivitäten der Mitgliedsländer, die Regierungsunterstützung erhalten. Also finden sich dort bisher keine Informationen über Deutschland.

1.4.4

Was folgt daraus?

=> Handeln Sie jetzt in Ihrem Unternehmen und bauen Sie dabei auf den Erfahrungen anderer auf. Sei es, daß diese ihnen aus USA, aus Europa oder auch aus Deutschland berichten. => Werden Sie zum Multiplikator für die Bearbeitung des Jahr 2000 Problems, indem sie die Jahr-2000-Thematik mit Ihren Kunden und Lieferanten erörtern und mit Ihrem Wirtschafts- oder Arbeitgeberverband darüber sprechen.

2

Die EDV vor dem Jahr 2000 Gefahren

2.1

Komplexitätsfallen

•

Die Mitarbeiter im Jahr 2000 Projekt

•

Die Programmiersprachen

•

Die Programmtexte

•

Die Komplexität der Programme

•

Was folgt daraus?

Die Hauptgefahr besteht heute immer noch für mehr als die Hälfte der Unternehmen und Institutionen darin, daß sie immer noch kein Jahr 2000 Projekt begonnen haben. Falls es doch gelingt, ein Projekt aufzusetzen, so finden sich - aufgebaut von der Komplexität des Projektes und der Technik - auf dem Projektweg zahlreiche Fallen. Tappt man nur in eine der Fallen, so ist der Projekterfolg in Frage gestellt. Manche der Fallen sind so gut getarnt, daß man erst am 1.1.2000 bemerken wird, daß man sich schon eine ganze Weile darin befindet.

2.1.1

Die Mitarbeiter im Jahr 2000 Projekt

Vielleicht meinen Sie, wenn das Jahr 2000 Problem derart schwierige Projekte nach sich zieht, sollte man es möglicherweise doch noch eine Weile unbearbeitet liegen lassen. Andere Probleme mögen Sie ignorieren oder bewußt auf einen späteren Termin legen. Doch passen Sie auf, das Jahr 2000 Problem hat im Gegensatz zu anderen Problemen eine eingebaute Wiedervorlage - und wenn es dann auftritt, ist es zu spät, um mit der Problemlösung zu beginnen. Der eingebaute Termin muß nicht erst der 1.1.2000 sein, er kann auch weit vor diesem Datum liegen, falls Programme sich „magischer Zahlen", wie „99", bedienen oder auf ein Datum in der nächsten Zukunft vorgreifen.

42

2 Die ED V vor dem Jahr 2000 - Gefahren

Also müssen sie sich wohl oder übel mit dem Gedanken an ein Jahr 2000 Projekt anfreunden. Bevor Sie nun beginnen, sollten Sie sich mit den Risiken eines solchen Projekts auseinandersetzen. Nur so können Sie die Wahrscheinlichkeit erhöhen, daß ihr Projekt erfolgreich verläuft. In der Umfrage von Neaman Bond (N01) wird unter „Stolpersteinen und Problemen" am häufigsten „Komplexität" genannt. Das wird verständlich, wenn wir die Hauptaktivität eines Jahr 2000 Projektes betrachten: Pflege von Software. Damit ist ein solches Projekt mit allen Risiken eines normales Software-Projektes belastet; hinzu kommt, daß man in Ihrem Unternehmen sicher schon viele Projekte zur Neuentwicklung von Software gestartet hat, aber wahrscheinlich nur wenige zur Pflege von Software. Pflege von Software war bisher Routineaufgabe der meisten Mitarbeiter in den DVAbteilungen. Nun sollen diese, womöglich unter der argwöhnischen Aufsicht eines Vorstandsmitglieds, an einem großen und riskanten Projekt teilnehmen. Sie sehen, eine erste Voraussetzung, Ihr Jahr 2000 Projekt weniger riskant zu gestalten, besteht darin, alles zu unternehmen, Ihre Mitarbeiter zu motivieren und alles zu unterlassen, was sie frustrieren könnte. Vorwürfe wegen alter Fehler zu machen, die möglicherweise zu einigen der Datumsproblemen in der Software geführt haben, führt jetzt nicht weiter. Was Sie nämlich nicht haben, ist eine große Auswahl möglicher Mitarbeiter. Sie werden mit denen leben und arbeiten müssen, die heute bei Ihnen unter Vertrag stehen. Denn der Arbeitsmarkt ist leer gefegt und wird es wohl die nächsten vier Jahre auch bleiben - heute eben wegen den zahlreichen Jahr 2000 Projekten und morgen wegen den genauso zahlreichen EURO-Projekten. Sehen Sie also zu, daß Sie Ihre Mitarbeiter behalten und sorgen Sie dafür, daß diese keinen Grund zur Klage finden, weder bei Gehalt und Arbeitsumgebung noch bei Programmierung und Entwicklungsrechner. Noch stärker als bei anderen Projekten, muß es beim Jahr 2000 Projekt die vornehmste Aufgabe des Projektleiters sein, von seinen Mitarbeitern alle Störungen und Ärgernisse vorausschauend fernzuhalten. Das ist auch die beste Methode, die Produktivität ihrer Mitarbeiter zu erhöhen. Wie schon gesagt, Sie werden keine neuen, zusätzlichen Mitarbeiter mehr finden. Nur mit getreuen, fleißigen und einfallsreichen Mitarbeitern haben Sie überhaupt eine Chance, ein Projekt dieser Größenordnung und Komplexität termingerecht abzuschließen.

2.1

43

Komplexitätsfallen

2.1.2

Die Programmiersprachen

So weit zur Pflege von Software, nun kommen wir zur Software selbst. Was man von Software sehen kann, ist eine Menge von Texten in verschiedenen Programmiersprachen. Jede der etwa 500 Programmiersprachen (J02) definiert eine Menge von zulässigen Ausdrücken und Zusammensetzungen. Als Namen für Ausdrücke einer Programmiersprache werden Wörter aus dem Englischen genommen. Einer von etwa 2400 Kompilierern (H04) ist erforderlich, um die Texte, geschrieben in einer bestimmten Programmiersprache, so zu übersetzen, daß ein bestimmter Computer sie verstehen kann. Nur was übersetzt werden kann, macht den wirksamen Umfang einer Sprache aus. Neben den eigentlichen Programmiersprachen, die von eingesetzten Hardware weitgehend unabhängig sind, gibt es noch von der Hardware abhängige, sog. Assemblersprachen, und zwar ebenso viele wie es verschiedene Zentralprozessortypen gibt. Es folgen einige Beispiele für Namen von relativ populären Programmiersprachen. •

Ada

•

Java

•

BASIC

•

MUMPS

•

C und C++

•

Natural

•

Dbase und Clipper

•

Pascal

•

COBOL

•

PL/1

•

Delphi

•

Rexx

•

Fortran

•

Smalltalk

•

Focus

•

Visual Basic

Es gibt natürlich auch mehrsprachige Programmtexte mit Abschnitten in unterschiedlichen Sprachen. Besonders beliebt ist neuerdings die Mischung von COBOL mit SQL oder von C mit SQL. Für jede Sprache, die in einem Unternehmen eingesetzt wird oder wurde, braucht man in einem Jahr 2000 Projekt Programmierer und Werkzeugprogramme, die diese Sprache verstehen. Leider gibt es für höchstens 20 Sprachen Werkzeuge und ausgereifte Werkzeuge wohl nur für fünf Sprachen. Für COBOL werden etwa so viele Werkzeuge angeboten wie für alle anderen Sprachen zusammen. Große Probleme werden Ihnen also auch viele andere Sprachen machen, da Sie dafür nur wenige, geeignete Analyse- und Konvertierungswerkzeuge und nur wenige, qualifizierte Programmierer finden. Möglicherweise werden Sie eigene Programmierer ausbilden oder eigene Werkzeuge entwickeln müssen.

44

2 Die ED V vor dem Jahr 2000 - Gefahren

2.1.3

Die Programmtexte

In allen Programmiersprachen ist es möglich, verständliche und damit pflegeleichte Texte zu verfassen. Aber gerade in der Programmierung ist auch das genaue Gegenteil möglich und oft für den Programmierer einfacher zu erreichen. Da ein Programm aus Texten besteht, kann es leicht geändert werden; es wurde folglich auch häufig geändert und es kann sein, daß es deswegen heute nur noch schwer zu ändern ist, wenn man keine Fehlfunktionen des ablaufenden Programms riskieren will. Manchmal wurden nicht nur die von den Nutzern gewünschten Funktionen programmiert, sondern das erstellte Programm war gleichzeitig Teil eines „Kündigungsschutzprogrammes". Der Programmierer erzeugte möglichst unverständliche und natürlich nicht dokumentierte Programme, um den eigenen Arbeitsplatz zu sichern. Heute braucht man auch diese Programmierer noch, um wenigstens Anhaltspunkte für das Funktionieren ihrer Programmen zu erhalten. Denn leider gibt es nur wenige Spezialprogramme, die diese verqueren Texte so übersetzen, daß ein anderer Mensch sie verstehen kann. In den wie immer gearteten Programmtexten gilt es, die problematischen Datumsstellen zu finden. Dann kommt der schwierigere Teil, nämlich im Einzelnen zu verstehen, was gefunden wurde. Manchmal muß man die Eigenarten von Programmiersprachen und Programmierern erst verstehen, um überhaupt etwas zu finden. Diese Probleme können die Wartung gewaltig erschweren und sie können bis zur Hälfte des Aufwandes eines Jahr 2000 Projektes ausmachen. Diese Probleme hat man natürlich nicht bei Neuentwicklungen. Im nächsten Schritt muß man die gefundenen und verstandenen Stellen im Programm korrigieren. Korrekturen gibt es auch bei neu erstellter Software; allerdings wird dann jeder Programmierer nur von ihm selbst erstellte Texte korrigieren müssen. Dann wird die Korrektur getestet und auch über weitere Tests sichergestellt, daß die übrigen Programmfunktionen von der Änderung nicht betroffen sind. Denn im Mittel erzeugen hundert Korrekturen etwa sieben neue Fehler. Der Aufwand für die einzelnen Schritte teilt sich etwa folgendermaßen auf: •

Finden: 10-50%

•

Korrigieren: 15-30%

•

Test der Korrektur: 10-30%

•

Test der Funktionen: 20-50%

Wie man sieht, schwankt der Aufwand je nach Entwicklungsumgebung stark. Möglicherweise ist es überraschend festzustellen, daß das Auffinden betroffener

2.1

45

Komplexitätsfallen

Stellen in den Programmen die Hälfte oder das Testen geänderter Programme mehr als drei Viertel des Aufwandes ausmachen kann. Man kann ein Jahr 2000 Projekt selbst als einen Test ansehen für die Güte des gegenwärtigen Software Management Prozesses in einem Unternehmen oder auch als einen Test für die Werkzeugunterstützung dieses Prozesses, also für die Nutzung von Werkzeugen für Analyse, Korrektur und Programmtest.

2.1.4

Die Komplexität der Programme

Für die Komplexität von Programmen kann eine Größe unabhängig von der Programmiersprache definiert werden, nämlich der sogenannte Function Point (FP). Die Komplexität von 1 FP wird von unterschiedlichen Programmiersprachen mit einer verschiedenen Anzahl Befehlssätzen erreicht. Tabelle 5: Ein Function Point in verschiedenen

c BASIC FORTRAN COBOL PASCAL PL/I C++ Visual Basic SQL

Programmiersprachen

128 128 107 107 91 80 53 32 12

Das Software-Inventar eines mittleren Unternehmens beläuft sich in den USA auf etwa 500 000 FP (J02). Im dortigen Durchschnitt wird auf jeweils 1000 FP vorhandener Software eine EDV-Fachkraft beschäftigt. Wenn 10% der Programmtexte eine Datumsverarbeitung erhalten, so hat jeder in der EDV Beschäftigte in seinem gesamten Bestand von 1000 FP zu suchen, dann 100 FP zu verstehen, zu korrigieren, zu testen und dann die gesamten 1000 FP Software zu testen. Dafür wird er nach der bisherigen Erfahrung etwa sechs bis zehn Monate brauchen. Er sollte allerdings auch bis Ende 1998 mit seiner Arbeit fertig sein, damit man Zeit für die Tests des gesamten Systems hat. Um 1000 FP ganz neu zu entwickeln, sind 27 Monate anzusetzen. Alle Aufwandszahlen sind nur gültig, wenn alle Fachleute als Programmierer arbeiten und wenn ein Programmierer in diesem Zeitraum keine anderen Arbeiten unternimmt und seine Zeit nur für das Jahr 2000 Projekt aufwendet und sie erhalten natürlich keinen allgemeinen Projektaufwand für Einrichtung und Verwaltung des Projektes.

46

2 Die ED V vor dem Jahr 2000 - Gefahren

Mit Erscheinen dieses Buches sind also komplette Neuentwicklungen nicht mehr möglich; es gilt, sich auf die mögliche Neuentwicklung von einzelnen Modulen zu beschränken. Auch die Erweiterung von Programmfunktionen um die Behandlung der EURO-Währung oder eine umfangreiche Modernisierung der Software erhöhen die Komplexität, die in der verbleibenden Zeit zu bewältigen ist. Im Rahmen eines Jahr 2000 Projektes sollten solche Erweiterungen unterbleiben, um die Fertigstellung zu dem nicht verschiebbaren Endtermin eines solchen Projektes nicht zu gefährden. Wenn 10% der Programmtexte eine Datumsverarbeitung enthalten, dann liegt die gesamte Komplexität eines für mittelständische Unternehmen typischen Jahr 2000 Projektes entsprechend den oben genannten Zahlen im Bereich von 10% von 500 000 FP, also bei 50 000 FP. Ein Projekt mit einem solchen Wert ist kritisch und läuft auf Grund seiner schieren Größe sowieso Gefahr, sich zu verspäten oder sein Budget gewaltig zu überziehen, und zwar mit einer Wahrscheinlichkeit von mehr als 72 %. Tabelle 6: Abbruchraten

und Verspätungen nach Größe der Entwicklungsprojekte

Function Points

(nach G02, S.10)

Fertigstellung früher als geplant

termingerecht

verspätet

abgebrochen

10

11%

81%

6%

100

6%

75%

12%

7%

1000

1%

61%

18%

20%

0,1%

28%

24%

48%

0%

14%

21%

65%

10000 100000

2.1.5

2%

Was folgt daraus?

=> Die Software-Krise, erkennbar an ihren Symptomen Projektverspätung und Projektabbruch, kann direkt in die Jahr 2000 Katastrophe fuhren.

2.2

Bilanzielle Bewertung

2.2

47

Bilanzielle Bewertung

•

Das Vermögen eines Unternehmens

•

Die Bewertung beim Anwender von Software

•

Die Bewertung beim Hersteller von Software

•

Die Berichtspflichten

•

Was folgt daraus?

Schon heute besteht die Verpflichtung, sich mit den Auswirkungen der Jahr 2000 Probleme in den elektronischen Systemen eines Unternehmens auf die bilanzielle Bewertung eben dieses Unternehmens zu befassen. Also ist die Frage zu klären: Wie wird Software selbständig und als Teil von Systemen bewertet und wie ist sie möglicherweise bei Jahr 2000 Problemen abzuwerten? Die Gefahr besteht zum einen darin, daß die Aussagekraft einer Handelsbilanz abnimmt, wenn sie heute keine Angaben zur Jahr 2000 Fähigkeit der EDV-Systeme eines Unternehmens enthält. Die Gefahr besteht zum anderen darin, daß der Wert eines Unternehmens und auch der Gewinn abnimmt, wenn Angaben zu Jahr 2000 Problemen zu Abwertungen in der Handelsbilanz fuhren.

2.2.1

Das Vermögen eines Unternehmens

Software im Unternehmen ist Teil des Unternehmensvermögens. Die Vermögensverhältnisse und die Schulden eines Unternehmens sind jährlich am Schluß eines Geschäftsjahres als Handelsbilanz aufzustellen. §242 HGB - Handelsbilanz (1) Der K a u f m a n n hat zu Beginn seines Handelsgewerbes und für den Schluß eines jeden Geschäftsjahrs einen das Verhältnis seines Vermögens und seiner Schulden darstellenden Abschluß (Eröffnungsbilanz, Bilanz) aufzustellen. Auf die Eröffnungsbilanz sind die für den Jahresabschluß geltenden Vorschriften entsprechend anzuwenden, soweit sie sich auf die Bilanz beziehen. (2) Er hat für den Schluß eines jeden Geschäftsjahrs eine Gegenüberstellung der Aufwendungen und Erträge des Geschäftsjahrs (Gewinn- und Verlustrechnung) aufzustellen. (3) Die Bilanz und die Gewinn- und Verlustrechnung bilden den Jahresabschluß.

Der Autor ist kein Steuerberater. Die folgenden Ausführungen geben ausschließlich seine persönliche Meinung wieder. Hinweise auf mögliche Fehler und Auslassungen sind willkommen. Die folgende Darstellung soll nicht als Beratung in steuerlicher oder rechtlicher Hinsicht interpretiert werden. Alle Leser werden gebeten, ihre besondere Lage mit ihrem Berater für alle im folgenden genannten Problemkreise durchzusprechen.

48

2 Die ED V vor dem Jahr 2000 - Gefahren

Der Jahresabschluß soll ein realistisches Bild der Vermögenslage, der Finanzlage und der Ertragslage eines Unternehmens vermitteln; er muß daher vollständig sein: §246 HGB - vollständiger Ansatz (1) Der Jahresabschluß hat sämtliche Vermögensgegenstände, Schulden, Rechnungsabgrenzungsposten, Aufwendungen und Erträge zu enthalten, soweit gesetzlich nichts anderes bestimmt ist.

Das Vermögen gliedert sich in das gesetzlich definierte Anlagevermögen und das Umlaufvermögen, das alle die Vermögensgegenstände umfaßt, die nicht zum Anlagevermögen gehören. §247 HGB - Anlagevermögen (2) Beim Anlagevermögen sind nur die Gegenstände auszuweisen, die bestimmt sind, dauernd dem Geschäftsbetrieb zu dienen.

Bei beiden Vermögensarten werden sowohl körperliche als auch unkörperliche Gegenstände wie z.B. Finanzanlagen oder Forderungen aufgeführt. Zu den unkörperlichen Gegenständen gehören auch die immateriellen Wirtschaftsgüter, also solche Güter, die nicht unmittelbar angeschaut werden können: §266 HGB - immaterielle Vermögensgegenstände (2) Aktivseite A. Anlagevermögen: 1. Immaterielle Vermögensgegenstände: Konzessionen, gewerbliche Schutzrechte und ähnliche Rechte und Werte sowie Lizenzen an solchen Rechten und Werten;

So Software mit einer technischen Erfindung oder einer geistigen Schöpfung vergleichbar ist, fällt sie oder eine Lizenz an ihr ebenso wie Urheberrechte unter die immateriellen Vermögensgegenstände. Andererseits bedürfen die immateriellen Wirtschaftsgüter vielfach körperlicher Träger. So ist das körperliche Manuskript eines Autors Bestandteil des immateriellen Wirtschaftsguts Urheberrecht. Bei der Software entspricht dem die physikalische Codierung eines Programmes auf einem Datenträger. Nur die entgeltlich erworbenen, also nicht die gemieteten oder selbst erstellten, immateriellen Vermögensgegenstände dürfen in das Anlagevermögen aufgenommen werden. Gemietete Gegenstände gehören nicht zum Eigentum eines Unternehmens; die komplizierten Fälle des Leasing werden hier nicht besprochen. §248 HGB - Aktivierungsverbot (2) Für immaterielle Vermögensgegenstände des Anlagevermögens, die nicht entgeltlich erworben wurden, darf ein Aktivposten nicht angesetzt werden.

2.2

Bilanzielle

Bewertung

49

Vom Unternehmen selbst erstellte immaterielle Güter dienen oft auf sehr individuelle Weise dem Geschäftsbetrieb und sie haben oft auch noch keine Wertschätzung am Markt gefunden. Sie dürfen nicht als Vermögensposten in der Handelsbilanz geführt werden. Der Aufwand für die Erstellung findet sich daher nur in den Posten der Gewinn- und Verlustrechnung. Entgeltlich erworbene, also gekaufte Software können Systemprogramme oder auch allgemeine oder betriebsindividuelle Pakete von Anwendungsprogrammen sein. Falls Software unselbständig als Teil eines Gerätes oder Teil eines Produktionssystems auftritt, so ist sie im Wert des körperlichen Gegenstandes enthalten und wird meistens nicht gesondert ausgewiesen. Die gleichen Überlegungen, die zum Ansatz in einer Handelsbilanz oder zur Buchung als Aufwand fuhren, gelten auch fur selbst erstellte versus gekaufte Datenbestände und Informationssammlungen.

2.2.2

Die Bewertung beim Anwender von Software

Auch immaterielle Wirtschaftsgüter können sich abnutzen, natürlich nicht tatsächlich sondern entsprechend dem Zeitraum, in dem sie wirtschaftlichen Nutzen erbracht haben. § 253 HGB - Wertansätze der Vermögensgegenstände (2) Bei Vermögensgegenständen des Anlagevermögens, deren Nutzung zeitlich begrenzt ist, sind die Anschaffungs- oder Herstellungskosten um planmäßige Abschreibungen zu vermindern. Der Plan muß die Anschaffungs- oder Herstellungskosten auf die Geschäftsjahre verteilen, in denen der Vermögensgegenstand voraussichtlich genutzt werden kann. Ohne Rücksicht darauf, ob ihre Nutzung zeitlich begrenzt ist, können bei Vermögensgegenständen des Anlagevermögens außerplanmäßige Abschreibungen vorgenommen werden, um die Vermögensgegenstände mit dem niedrigeren Wert anzusetzen, der ihnen am Abschlußstichtag beizulegen ist, sie sind vorzunehmen bei einer voraussichtlich dauernden Wertminderung.

Entgeltlich erworbene Software ist beim Anwender also von den Anschaffungskosten ausgehend über die voraussichtliche Nutzungsdauer planmäßig abzuschreiben. Bei Software mit Datumsproblemen, die im Jahr 2000 auftreten oder auch schon in den Jahren davor, ist eine dauernde Wertminderung vorauszusehen. Es besteht also der gesetzliche Zwang, den Wert einer solchen Software neu zu bestimmen. Der neue Wert kann sich über die verringerte zeitliche Nutzungsmöglichkeit ergeben oder in einem bestimmten Verhältnis zu dem Anschaffungspreis dieser Software oder dem einer neuen Version am Abschlußstichtag stehen. In dieser Weise fuhrt das Jahr 2000 Problem in der erworbenen und betrieblich genutzten Software also schon heute zu einer Wertminderung im Anlagevermögen. Der Wert des betroffenen Unternehmens nimmt daher ab, ebenso verringert sich das Jahresergebnis dieses Unternehmens.

2 Die ED V vor dem Jahr 2000 -

50

Gefahren

Wenn Software in Systeme integriert ist, seien es Geräte oder Produktionsanlagen, wird sie zusammen mit diesen über deren Nutzungsdauer abgeschrieben. Wenn diese Art von Software mit Datumsproblemen behaftet ist, so wird man eine Untersuchung anstellen, ob die Software repariert werden kann. § 249 HGB - Rückstellungen (1) Rückstellungen sind für ungewisse Verbindlichkeiten und für drohende Verluste aus schwebenden Geschäften zu bilden. Ferner sind Rückstellungen zu bilden für 1. im Geschäftsjahr unterlassene Aufwendungen für Instandhaltung, die im folgenden Geschäftsjahr innerhalb von drei Monaten, oder für Abraumbeseitigung, die im folgenden Geschäftsjahr nachgeholt werden, Rückstellungen dürfen für unterlassene Aufwendungen für Instandhaltung auch gebildet werden, wenn die Instandhaltung nach Ablauf der Frist nach Satz 2 Nr. 1 innerhalb des Geschäftsjahrs nachgeholt wird.

Falls eine Reparatur der Software und damit des Systems möglich ist, wird man dafür Rückstellungen bilden müssen. Falls eine Reparatur nicht möglich sein sollte, so ist eine dauernde Wertminderung des gesamten Systems vorauszusehen. Als Folge davon ist bei dem betreffenden System eine außerplanmäßige Abschreibung vorzunehmen. Solch eine neue Wertbestimmung für integrierte Systeme wird dann viel deutlicher ausfallen als ein geringerer Wertansatz nur für die Software allein. Auch hier führen sowohl Rückstellungen als auch Wertminderungen zu einem verringerten Jahresergebnis.

2.2.3

Die Bewertung beim Hersteller von Software

Auch beim Hersteller von Software ist diese zu bewerten und bei Datumsproblemen neu zu bewerten. Doch hier ist Software ein immaterieller Gegenstand des Umlaufvermögens, das alle zum Verkauf oder zum baldigen Verbrauch bestimmten Gegenstände umfaßt. Neubewertung bedeutet hier eine Abwertung der selbst entwickelten, fertigen oder unfertigen, zum Verkauf bestimmten Softwareprodukte oder eine Abwertung der Handelsware, der zum Wiederverkauf eingekauften Softwareprodukte.

2.2

Bilanzielle

Bewertung

51

§ 253 HGB - Wertansätze der Vermögensgegenstände (1) Vermögensgegenstände sind höchstens mit den Anschaffungs- oder Herstellungskosten, vermindert um Abschreibungen nach den Absätzen 2 und 3 anzusetzen. (3) Bei Vermögensgegenständen des Umlaufvermögens sind Abschreibungen vorzunehmen, um diese mit einem niedrigeren Wert anzusetzen, der sich aus einem Börsen- oder Marktpreis am Abschlußstichtag ergibt. Ist ein Börsen- oder Marktpreis nicht festzustellen und übersteigen die Anschaffungs- oder Herstellungskosten den Wert, der den Vermögensgegenständen am Abschlußstichtag beizulegen ist, so ist auf diesen Wert abzuschreiben. Außerdem dürfen Abschreibungen vorgenommen werden, soweit diese nach vernünftiger kaufmännischer Beurteilung notwendig sind, um zu verhindern, daß in der nächsten Zukunft der Wertansatz dieser Vermögensgegenstände auf Grund von Wertschwankungen geändert werden muß.

Wenn Software selbst erstellt wurde, sind die Verhältnisse des Absatzmarktes maßgeblich; bei Software als Ware zum Wiederverkauf kann zwischen den Verhältnissen des Absatz- oder des Beschaffungsmarktes gewählt werden (K03). Wenn die Datumsprobleme eines Softwareproduktes bekannt sind, wird der Vertrieb unmöglich sein; wenn sie am Absatzmarkt noch nicht bekannt sind, so ist der Vertrieb unerlaubt. In dieser Weise führt das Jahr 2000 Problem also schon heute zu einer Wertminderung im Umlaufvermögen. Der Wert eines hauptsächlich Software erstellenden Unternehmens kann damit deutlich abnehmen, ebenso wie das Jahresergebnis dieses Unternehmens. Zu einer weiteren Minderung des Ergebnisses fuhrt die Pflicht, Rückstellungen für Gewährleistungen zu bilden, die ohne direkte rechtliche Verpflichtung wahrscheinlich erbracht werden müssen. § 249 HGB - Rückstellungen (1) Rückstellungen sind für ungewisse Verbindlichkeiten und für drohende Verluste aus schwebenden Geschäften zu bilden. Ferner sind Rückstellungen zu bilden für 2. Gewährleistungen, die ohne rechtliche Verpflichtung erbracht werden.

Für solche Gewährleistungen mag es faktische Verpflichtungen geben, um die Position eines Unternehmens bei der Kundschaft oder im Markt aufrecht zu erhalten oder um das allgemeine Haftungsrisiko zu mindern.

2.2.4

Die Berichtspflichten

U.a. um die Stetigkeit und Vergleichbarkeit der Bilanzangaben über mehrere Geschäftsjahre zu sichern, ist es vorgeschrieben, Abweichungen von bisherigen Bilanzierungsmethoden in dem Anhang zum Jahresabschluß darzustellen.

52

2 Die ED V vor dem Jahr 2000 - Gefahren

§ 284 HGB - Erläuterung der Bilanz und der Gewinn- und Verlustrechnung (2) Im Anhang müssen die auf die Posten der Bilanz und der Gewinn- und Verlustrechnung angewandten Bilanzierungsund Bewertungsmethoden angegeben werden; Abweichungen von Bilanzierungs- und Bewertungsmethoden angegeben und begründet werden; deren Einfluß auf die Vermögens-, Finanz- und Ertragslage ist gesondert darzustellen;

Jede Neubewertung ist aber eine Abweichung von den bisherigen Bewertungsmethoden und daher mit dem Hinweis auf die betroffenen Güter, der Angabe der neuen Methode und den Gründen für diese Wahl zu erläutern (K03). Um weitere Anhaltspunkte für die Unternehmensbewertung zu geben, soll im Lagebericht einer Kapitalgesellschaft auch auf zu erwartende künftige Ereignisse von besonderer Bedeutung eingegangen werden. § 289 HGB - Lagebericht (1) Im Lagebericht sind zumindest der Geschäftsverlauf und die Lage der Kapitalgesellschaft so darzustellen, daß ein den tatsächlichen Verhältnissen entsprechendes Bild vermittelt wird. (2) Der Lagebericht soll auch eingehen auf: 1. Vorgänge von besonderer Bedeutung, die nach dem Schluß des Geschäftsjahrs eingetreten sind; 2. die voraussichtliche Entwicklung der Kapitalgesellschaft;

Ein Vorgang von besonderer Bedeutung kann die Erkenntnis sein, in welcher Weise das bilanzierende Unternehmen vom Jahr 2000 Problem betroffen ist und wie sich deswegen die voraussichtliche Entwicklung verändern wird. Falls man diese Erkenntnis nicht besitzt, so ist zumindest in den USA zur Vermeidung einer Irreführung anzugeben, daß eine bestimmte Unsicherheit über die Lage des Unternehmens besteht und daß das der Geschäftsleitung bekannt ist (S09). Üblicherweise werden in einem Lagebericht Hinweise auf die Entwicklung in den kommenden zwei Jahren erwartet. Die Lageberichte aller Kapitalgesellschaften für das Geschäftsjahr 1997 und die folgenden Jahre sollten daher einen Hinweis enthalten, ob mit dem Jahr 2000 ein Unternehmen Probleme auf sich zukommen sieht. Bei einem Konzern müssen Anhang und Lagebericht auch Angaben über die mit dem Konzern verbundenen Unternehmen enthalten. Der Gesetzgeber verpflichtet die Vertreter einer Kapitalgesellschaft und die Vertreter ihrer Eigentümer zu richtigen Angaben:

2.2 Bilanzielle Bewertung

53

§ 3 3 1 HGB - Unrichtige Darstellung Mit Freiheitsstrafe bis zu drei Jahren oder mit Geldstrafe wird bestraft, wer 1. als Mitglied des vertretungsberechtigten Organs oder des Aufsichtsrats einer Kapitalgesellschaft die Verhältnisse der Kapitalgesellschaft in der Eröffnungsbilanz, im Jahresabschluß, im Lagebericht oder im Zwischenabschluß nach § 340a Abs. 3 unrichtig wiedergibt oder verschleiert, 2. als Mitglied des vertretungsberechtigten Organs oder des Aufsichtsrats einer Kapitalgesellschaft die Verhältnisse des Konzerns im Konzernabschluß, im Konzernlagebericht oder im Konzernzwischenabschluß nach § 340i Abs. 4 unrichtig wiedergibt oder verschleiert,

Unternehmen ab einer bestimmten Größe sind verpflichtet, gegenüber einem unabhängigen Abschlußprüfer die Richtigkeit ihrer Angaben nachzuweisen. Dieser hat wiederum die Pflicht, sich von der Richtigkeit zu überzeugen und darüber hinaus in seinem Prüfungsbericht alle Tatsachen anzugeben, die die Unternehmensentwicklung beeinträchtigen können. § 321 HGB - Prüfungsbericht (2) Stellt der Abschlußprüfer bei Wahrnehmung seiner Aufgaben Tatsachen fest, die den Bestand eines geprüften Unternehmens gefährden oder seine Entwicklung wesentlich beeinträchtigen können oder die schwerwiegende Verstöße der gesetzlichen Vertreter gegen Gesetz, Gesellschaftsvertrag oder Satzung erkennen lassen, so hat er auch darüber zu berichten.

Eine solche Gefahr kann das Jahr 2000 Problem sein; zu einer Tatsache, von der Gefahr für ein bestimmtes Unternehmen ausgeht, wird es jedoch erst nach gründlicher Untersuchung. Möglicherweise muß man diese Untersuchung auch deshalb anstellen, um diese Gefahr mit Sicherheit auszuschließen.

2.2.5

Was folgt daraus?

=> Die Abwertung von Software mit Jahr 2000 Problemen ist schon heute in der Handelsbilanz vorzunehmen, und zwar bei Hersteller und Anwender gleichermaßen. => Falls Software abgewertet wird, so ist dies im Anhang zum Jahresabschluß zu erläutern. => Man darauf gespannt sein, in welcher Weise die Lageberichte der Kapitalgesellschaften ab dem Geschäftsjahr 1997 auf das Jahr 2000 Problem eingehen.

3

Die EDV vor dem Jahr 2000 Chancen

3.1

Proj ektmanagement

•

Der Zeitplan für Jahr 2000 Projekte

•

Die Einrichtung des Jahr 2000 Projektrahmens

•

Das Management des Jahr 2000 Projektrahmens

•

Was folgt daraus?

Die große Chance, mit dem Jahr 2000 Problem zurecht zu kommen, liegt natürlich darin, ein Jahr 2000 Projekt durchzuführen und es erfolgreich abzuschließen. Dieses Kapitel geht auf die Besonderheiten von Jahr 2000 Projekten ein und auf die besonderen Aufgaben im Rahmen der Einrichtung von Jahr 2000 Projekten.

56

3 Die ED V vor dem Jahr 2000 -

Analyse der EDVAnwendungen

Inventar der Anwendungen

SystemManagement

iL. Inventar der EDV-Systeme ,

Analyse der EDV-Systeme

korrekt

fehlerhaft

Umsetzung der Lösung

E D V - und ElektronikHersteller

_

Chancen

3.1 Projektmanagement

3.1.1

57

Der Zeitplan für Jahr 2000 Projekte

Projekte sind immer dann üblich, wenn besondere Arbeiten und nicht Routinetätigkeiten ausgeführt werden sollen. Das Jahr 2000 Problem ist sicher etwas Besonderes und nicht Routine. Das Besondere am Jahr 2000 Problem ist gerade, daß es nicht routinemäßige EDV-Praxis war, den Jahrhundertwechsel zu berücksichtigen. Ein Projekt hat einen definierten Anfang und sollte auch ein Ende haben. Es gibt allerdings etliche EDV-Projekte, die nur einen schlecht definierten Anfang haben und kein Ende kennen. Der Anfang eines Jahr 2000 Projektes muß spätestens in diesem Jahr, also im Jahre 1998, liegen, insbesondere deswegen, weil alle Arbeiten an kritischen Anwendungen spätestens zum Ende dieses Jahres, also zum 31.12.1998, und alle anderen Arbeiten zum Ende des nächsten Jahres, also zum 31.12.1999, abgeschlossen sein sollten. Der Dezember 1998 als Abschlußtermin wird sogar von der New Yorker Börse für ihre Mitgliedern vorgegeben (NYSE nach S08). Auch wenn Sie diese Termine einhalten können, werden Sie sehr wahrscheinlich in den folgenden Jahren in einige der im Kapitel „Katastrophenkalender" beschriebenen großen und kleinen EDV-Unglücke verwickelt werden, sei es als Betroffener oder als Beteiligter, als Zeuge oder als Sachverständiger, als Richter oder als Ankläger oder schlicht als Staatsbürger. Außer den inneren gibt es immer auch noch äußere Probleme. Die Problemfreiheit für ein Unternehmen ist unerreichbar und sollte daher auch nicht als Projektziel definiert werden. Die amerikanische Börsenaufsicht hält sogar die Behauptung eines Unternehmens für unglaubwürdig, man habe die Jahr 2000 Fähigkeit für alle interne Systeme erreicht (S08). Nur die Beschränkung auf die Umstellung bestimmter, kritischer EDV-Systeme und die Entscheidung, unkritische nicht oder später umzustellen, ist heute eine realistische Haltung.

Welche Arbeiten müssen bis zum 31.12.1998 erledigt sein? Bis zu diesem Datum sind alle Anwendungen anzupassen oder umzustellen, bei denen „99" im Jahresfeld nicht die Bedeutung einer (verkürzten) Jahreszahl sondern eine andere Bedeutung als sogenannte „magische Zahl" hat, die eine besondere Verarbeitungslogik auslöst. Bis zu diesem Datum sind auch die Anwendungen umzustellen, die ins nächste Jahr vorausgreifen und deswegen ab dem 1.1.1999 oder im Jahr 1999 Probleme mit dem Jahr 2000 haben werden. Es empfiehlt sich auch, dungen umzustellen, da Schalttages) tatsächlich aus dem Kapitel zu den

bis zu diesem Datum alle großen oder wichtigen Anwennur so ein vollständiger Jahresablauf (mit Ausnahme eines für ein komplettes System getestet werden kann. Wie Sie „Komplexitätsfallen" wissen, haben Sie auch keine Garan-

58

3 Die EDV vor dem Jahr 2000 - Chancen

tie dafür, daß ihr Projekt pünktlich fertig wird; daher ist es gut, das Jahr 1999 als zeitlichen Puffer zu haben. Welche Arbeiten hätten bis zum 31.12.1997 erledigt sein müssen? Das sind genau die Anwendungsumstellungen, wo die ersten beiden Bedingungen des vorigen Abschnitts zusammenkommen: „99" hat nicht die Bedeutung einer Jahreszahl und es wird ein Jahr in die Zukunft voraus gegriffen und deswegen gibt es ab dem 1.1.1998 Probleme mit dem „Jahr 99". Bis zu diesem Datum sind natürlich auch die Anwendungen umzustellen, die zwei Jahre in die Zukunft voraus greifen. Schon hier können Sie feststellen, daß das Jahr 2000 „Projekt" in Wirklichkeit die Koordination unterschiedlicher Umstellungsprojekte zu ganz verschiedenen Terminen bedeutet und deswegen soll im Folgenden nur noch vom „Jahr 2000 Projektrahmen" die Rede sein, wenn eben diese Koordination und nicht ein einzelnes Arbeitspaket, eben ein richtiges Projekt, gemeint ist. Innerhalb des Jahr 2000 Projektrahmens fallen die umfangreichsten Arbeiten im Jahr 1998 an, wenn Sie sich an die oben gegebenen Empfehlungen halten möchten. Zuerst wird man sich, falls das noch nicht geschehen sein sollte, um eine sorgfältige Einrichtung des Projektrahmens - dazu gleich mehr - und um die Suche und Korrektur der Anwendungen kümmern, die im Laufe des Jahres 1998 problematisch werden. Für die maximale Dauer aller einzelnen Umstellungsaufgaben im Jahr 2000 Projektrahmen kann man also grob 12 Monate ansetzen. Der Programieraufwand beläuft sich für ein Unternehmen mittlerer Größe auf mindestens 50 mal 1000 Function Points, also auf mindestens 300 Personen-Monate, d.h. bei Einrechnung von Krankheits- und Urlaubszeiten auf 360 Personen-Monate. Die benötigte Anzahl Mitarbeiter für die Programmierung ergibt sich so als Quotient aus Aufwand und Dauer zu 30 Personen, und zwar als Mindestzahl. Das entspricht Kosten von etwa 6 Millionen DM, das Mitarbeiterjahr zu 200 000 DM gerechnet. Die Gartner Group rechnet für mittelgroße Unternehmen mit Kosten von 4 Millionen US$ (nach M07). Glauben Sie nicht, daß es Programmierwerkzeuge gibt, die Ihnen diesen Personaleinsatz ersparen können. Das folgende Zitat nimmt ein Ergebnis der Kapitel zu den „Lösungsanbietern" vorweg: „Automated tools, how useful, can be applied to only some aspects of the task, creating a requirement for a temporarily large manual workforce and, above all, brilliant project managers. Project management has rarely been a strength of IT and now is needed, in quantity and quality, as never before." (H03) „Automatische Werkzeuge, wie nützlich auch immer, können nur auf einige Aspekte der Aufgabe angewandt werden; so wird zeitweise Nachfrage nach

3.1

Projektmanagement

59

umfangreicher, manueller Arbeit erzeugt und, vor allem, nach ausgezeichneten Projektleitern. Projektmanagement war bisher kaum eine Stärke der EDV und nun wird es in Quantität und Qualität benötigt wie niemals zuvor." Wenn Sie Werkzeuge nutzen wollen, gilt es für Ihre Umgebung geeignete zu finden und dann ihre Güte zu beurteilen: „Der Stand der Kunst der Methoden und Werkzeuge für die Softwareentwicklung läßt zu wünschen übrig, und was es an Gutem gibt, ist zu wenig bekannt, verstanden, verbreitet." (D02) Allerdings werden die Jahr 2000 Projekte erstmals in großem Umfang Investitionen der Hersteller und Anwender in Werkzeuge für die Softwarewartung und ihre Verbesserung und Verbreitung anregen. Das Projekt mit der ersten Priorität sollte heute das Jahr 2000 Projekt sein. Dieses Projekt richtig zu machen, dabei sollen Ihnen die folgenden Ausführungen zur Projekteinrichtung helfen. Die vielen Einzelprojekte in diesem Rahmen richtig zu machen, gibt Stoff für die Themen der nächsten Kapitel.

3.1.2

Die Einrichtung des Jahr 2000 Projektrahmens

Die wichtigste Person im Jahr 2000 Projektrahmen ist der Eigentümer dieses Prozesses, der Jahr 2000 Projektkoordinator. Diese Stelle sollten Sie mit ihrem besten Projektmanager besetzen, und nicht mit dem Manager, der gerade Zeit hat oder sich auf diese Stelle drängt. Wenn die Stelle besetzt ist, sollte die Koordination der Jahr 2000 Projekte die einzige Aufgabe des Stelleninhabers sein. Mit dieser Stelle sollte die nötige Autorität verbunden sein, Informationen über alle EDV-Anwendungen zu sammeln, eine Methode für Jahr 2000 Einzelprojekte festzulegen und dafür einen Zeitplan zu definieren und zu kontrollieren. Mit dieser Stelle sollte auch die Autorität verbunden sein, sich geeignete Mitarbeiter für Jahr 2000 Aufgaben, insbesondere für die Leitung einzelner, parallel ablaufender Umstellungsprojekte, aus den verschiedenen Abteilungen eines Unternehmens auszuwählen. Die nächste Person, der Sie sich nun zuwenden sollten, ist ein externer Berater zur Unterstützung Ihres Projektkoordinators. Er kann in Ihrem Konzern oder im Markt gefunden werden kann. Als Qualifikation sollten sie Erfahrungen aus dem Management eines Unternehmens oder mit großen Projekten, am besten natürlich mit Jahr 2000 Projekten fordern. Allerdings sind bisher weltweit nur wenige Jahr 2000 Projekte abgeschlossen worden. Wie für alle Experten von außen ist seine ständige Aufgabe, gegen Betriebsblindheit anzugehen, indem er Erfahrungen aus anderen Projekten und anderen Unternehmen einbringt. Verpflichten Sie diesen Experten auf vollen zeitlichen Einsatz; selbst wenn ihr Unternehmen ihn gerade nicht braucht, sollten Sie sich die Option offenhalten, ihn an Ihre Kunden und Lieferanten auszuleihen. Experten werden sehr knapp werden und was hilft es Ihnen, wenn

60

3 Die EDV vor dem Jahr 2000 - Chancen

Ihre Systeme Jahr 2000 fähig sind, aber Ihre Marktpartner interne Schwierigkeiten haben oder Schwierigkeiten haben, mit Ihnen Geschäfte zu machen. Eine erste Aufgabe für Ihren Experten besteht natürlich darin, die Unternehmensleitung zu überzeugen, daß sie dem Jahr 2000 Problem bei allen Stellen im Unternehmen die nötige Aufmerksamkeit verschaffen sollte. Die zweite Aufgabe besteht dann darin, das Projekt auf bedeutende, aber realistische Ziele zu orientieren. Da der oben genannte Berater in den normalen Gang des Projektes mit eingebunden ist, empfiehlt sich die zeitweise Einschaltung eines weiteren externen Beraters, der Vorgehensmodelle und Ergebnisse der verschiedenen Projektphasen jeweils einem Review unterzieht und Ihre gesamte Jahr 2000 Organisation periodisch überprüft. Insbesondere, wenn beide Berater unabhängig voneinander zu den gleichen Schlüssen kommen, kann dieses Vorgehen für Ihr Unternehmen oder seine Vorstände rechtliche Auseinandersetzungen sehr erleichtern. Manchmal läßt sich auch nur so, eine Versicherung zur Zahlung bewegen bzw. ein weitergehende Versicherung abschließen. Nachdem Sie nun in dieser Weise zwei bis drei neue Stellen mit Befugnissen quer zu Ihrer bisherigen Organisation geschaffen haben, geht es nun darum, der bestehenden Hierarchie wieder zu einem gewissen Ausgleich zu verhelfen. Richten Sie ein Jahr 2000 Komitee aus EDV- und betrieblichen Managern ein, siedeln Sie es direkt unter dem Unternehmensvorstand an und lassen Sie dessen Aufgaben darin bestehen, mit den Jahr 2000 Projekten verbundene betriebliche Konflikte zu entschärfen und technische Probleme einer Lösung zuzuführen. Welche betrieblichen Konflikte werden im Laufe des Managements des Jahr 2000 Projektrahmens auftreten? Fachabteilungen werden sich womöglich generell gegen ein großes Jahr 2000 Budget aussprechen, insbesondere falls die entstehenden Jahr 2000 Projektkosten auf ihre Etats umgelegt werden und sie die Entwicklung der nun problematischen Anwendungen schon einmal bezahlt haben. Möglicherweise lassen sich trotzdem Verbündete unter Anwendern finden, wenn die Jahr 2000 Kosten entsprechend den bisherigen Wartungskosten der Abteilungen aufgeschlüsselt werden. Absehbar sind auch Kämpfe um EDV-Budgets für neue Entwicklungen, die wegen der Jahr 2000 Aufgaben möglicherweise gekürzt werden müssen. Aktuelle Neuentwicklungen sind z.B. Aufbaus einer Intranets, Nutzung der Möglichkeiten des Handels über das Internet oder die Umstellung auf den EURO. Dann gilt es den Konflikt um die erste Priorität für Jahr 2000 Aufgaben zu lösen. Normalerweise kann man dabei nicht wie die US Armee nach dem Prinzip von Befehl und Gehorsam verfahren: „Therefore, effective immediately, all nonessential sustainment requerirements and enhancements will be postponed until systems have been analy-

3.1

Projektmanagement

zed, fixed, tested, and certified Y2k compliant using existing resources." (W01) „Deswegen, und zwar mit sofortiger Wirkung, werden alle nicht wesentlichen Erhaltungs- und Erweiterungswünsche verschoben bis alle Systeme untersucht, korrigiert, getestet und Jahr 2000 fähig befunden worden sind unter Nutzung bestehender Ressourcen."

61

62

3 Die EDV vor dem Jahr 2000 - Chancen

Verschärfend mag hinzu kommen, daß bisher über die Reihenfolge von Projekten in der einzelnen DV-Abteilung entschieden wurde, nun soll das abteilungsübergreifend geschehen. Ein weiteres, großes Konfliktfeld ist die Reihenfolge, in der betroffene Anwendungen Jahr 2000 fähig gemacht werden sollen - natürlich zuerst die Anwendungen, an die der Unternehmenserfolg geknüpft ist. Über diesen Grundsatz werden alle einig sein, doch jeder wird seine Anwendung für besonders wichtig halten: Keiner will etwas abgeben, keiner will etwas ändern, aber jeder möchte seine Anwendung zuerst zukunftssicher sehen. Welche technischen Probleme werden im Laufe des Managements des Jahr 2000 Projektrahmens auftreten? •

Es mag Methodenkonflikte geben, weil nun für Programmierung und Projektführung Vorschläge kommen, wie man jetzt alles auf einmal richtig machen kann.

•

Es gilt, sich zu entscheiden, welche Anwendung umgestellt, ausgetauscht oder ausgemustert werden soll.

•

Es gilt, aus der Fülle der Werkzeuge für Analyse, Konvertierung und Tests die passenden auszuwählen.

•

Es gilt auch, sich für einen oder zwei Lösungsanbieter mit Personal oder Dienstleistungen zu entscheiden.

Die wichtigste Aufgabe des Komitees ist es aber, einen Krisenplan zu entwickeln und ab dem Jahr 1998 bereit zu halten. Der Inhalt eines solchen Krisenplans wird im Kapitel „Management des EDV-Betriebes" im Detail beschrieben. Spätestens ab dem Ende des Jahres 1998 ist mit dem Auftreten massiver Probleme in nicht umgestellten Anwendungen zu rechnen. Die Aufgabe des Krisenplans ist es, solche Probleme schnell zu entdecken und in ihren Auswirkungen weitestgehend zu begrenzen. Von dem Jahr 2000 Projektkoordinator sind eine Reihe von speziellen Fragen zu entscheiden. Er benötigt dafür bedarfsweise einen Stab von Spezialisten. Jeder dieser Spezialisten sollte seinen Arbeitsplan erhalten und dem Projektkoordinator berichten. Die Fragen für die Spezialisten sind etwa: •

Wie überwacht man Lösungsanbieter?

•

Wie behandelt man EDV- und Elektronik-Lieferanten?

•

Wie geht man mit Lieferanten anderer Waren und Leistungen und deren Jahr 2000 Problemen um?

•

Welches Haftungspotential ist mit den Jahr 2000 Problemen verbunden?

•

Welche betrieblichen Versicherungen werden also benötigt?

3.1

Projektmanagement

63

Ausfuhrliche Informationen finden sich in den entsprechenden Kapiteln. Oder die eher firmenpolitischen Fragen: •

In welcher Weise sind die Mitarbeiter des Unternehmens zu informieren?

•

Wie beantwortet man selber als Lieferant die Anfragen seiner Kunden? Wahrscheinlich ist es besser, seine Kunden aus eigener Initiative zu informieren; man erspart sich so vielleicht die zeitaufwendige und zuweilen schwierige Beantwortung von Fragebögen.

•

Wie sind interner und externer Vertrieb zu orientieren?

•

Wie agiert man im Konzern gegenüber Tochter- und Mutterunternehmen?

•

Welche Folgekosten entstehen für problematische Anwendungen, die man bis Ende 1999 nicht umstellen kann oder will?

•

Sind mit bestimmten Anwendungen auch ganze Unternehmensteile auszumustern?

•

Welche Korrekturen sind dafür an Bilanz und Geschäftsbericht vorzunehmen?

Wenn man sich diese Fragen ernsthaft stellt, wird klar, daß dem Stab zeitweise und je nach Bedarf Rechtsanwälte, Versicherungsfachleute, Buchhalter, Steuerberater und Wirtschaftsprüfer angehören sollten. Ein Funktion wird leicht übersehen, sie sollte aber nicht vergessen werden: Alle Sitzungen und Entscheidungen sollten protokolliert und alle Kosten und Projektergebnisse dokumentiert werden. Für rechtliche Auseinandersetzungen mit anderen Parteien und Versicherungen benötigen Sie Dokumente, die diesem Standard genügen. Daher sollten Sie die Dokumentation einem Rechtsanwalt oder einem Steuerberater überlassen. Sollten dann noch Probleme mit der Güte oder Vollständigkeit der Dokumentation auftreten, können Sie auf deren Berufshaftpflichtversicherung zurückgreifen. Außerdem sind solche Berater zur Verschwiegenheit verpflichtet, falls Dritte versuchen sollten, die Herausgabe bestimmter Dokumente zu fordern.

3.1.3

Das Management des Jahr 2000 Projektrahmens

Auch hier wird nur auf die besonderen Aufgaben eingegangen, die der Jahr 2000 Projektrahmen mit sich bringt. Ein Schätzung der Dauer dieser Aktivität ist nicht nötig; es ist vielmehr nach Schätzung des Aufwandes jeder Einzelmaßnahme vom 31.12.1998 an zurück zu rechnen, ab wann diese Maßnahme mit wieviel Personal spätestens zu beginnen hat. Dabei definiert allerdings erst die Analysephase den Aufwand für die Konvertierungsphase und erst nach Entscheidung für verschiedene technische Alternativen ist der Aufwand für Renovierungen abzuschätzen. Man kann nun von Phase zu Phase ein Budget entwickeln oder man fuhrt erst ein typi-

64

3 Die ED V vor dem Jahr 2000 - Chancen

sches Pilotprojekt mittleren Schwierigkeitsgrades durch und rechnet dessen Ergebnisse auf andere Umstellungen hoch. Entsprechend rechtlichen Verpflichtungen und wirtschaftlicher Bedeutung ist eine Reihenfolge betroffener Anwendungsgruppe für Umstellungen zu bilden. Für kleinere, vorläufige Korrekturen können Anwendungen von geringerer Bedeutung vorgezogen werden, falls diese Probleme mit magischen Zahlen oder schon heute Probleme mit dem Jahr 2000 haben. Innerhalb jeder Anwendungsgruppe wird man eine Reihenfolge nach vorhandenen Qualifikationen der Programmierern und nach vorhandener Kapazität vornehmen. Die technische Reihenfolge der verschiedenen Teilprojekte und deren phasenweiser Ablauf ist zu koordinieren. Zuweilen müssen Umstellungen oder neue Installationen Daten über gemeinsame Schnittstellen mit Altbeständen austauschen oder bestimmte Umstellungen sollen gemeinsam getestet werden. Neben den Jahr 2000 Umstellungen werden noch einige normale Wartungsarbeiten durchgeführt werden. Solche Änderungen sind mit Änderungen zur Beseitigung der Jahr 2000 Probleme zu synchronisieren. Die benötigte Anzahl von Projektmitarbeitern zu finden oder freizustellen, kann zum Hauptproblem der Jahr 2000 Projekte werden. Man findet heute schon solche pessimistischen Aussagen wie: „If God or Bill Gates wrote out a check for the füll amount, nothing much would change. The year 2000 problem is a people- and time-resource issue, not just a financial one. You can't buy the time at any price." (K01) „Wenn Gott oder Bill Gates einen Scheck über die vollen Kosten ausschreiben würde, es würde sich nicht viel ändern. Das Jahr 2000 Problem ist eine Sache von verfugbaren Leuten und verfugbarer Zeit, und nicht nur eine der Finanzen. Man kann die Zeit zu keinem Preis kaufen." Jetzt rächt es sich, daß man in den vergangenen Jahren mit dem möglicherweise berechtigten „Lean Management" auch ein „Downsizing" vorgenommen hat. Man glaubte, man würde immer mehr vernetzte Rechner mit immer weniger Systembetreuern und Wartungsprogrammierern betreiben können. Mit den Jahr 2000 Projekten in fast allen Unternehmen wird die Nachfrage nach qualifiziertem Personal zunehmen und die Betriebstreue der vorhandenen Mitarbeiter abnehmen. Die ersten Jahr 2000 Projektleiter haben schon den Arbeitgeber gewechselt. Meine Empfehlung ist: Beraten Sie mit Ihrem Personalchef, wie die Mitarbeiterbindung zu erhöhen ist, und beraten Sie mit ihren qualifizierten Mitarbeitern, welche Schwierigkeiten Sie ihnen abnehmen und welche berechtigten Wünsche sie ihnen erfüllen können. Sie benötigen Mitarbeiter mit einem breiten Wissen über Programmiersprachen und Betriebssystemplattformen, die auch mit Anwendungen und Anwendern pro-

3.2 Bestandsaufnahme und Analyse der EDV-Anwendungen

65

duktiv umgehen können. Vergessen Sie nicht, Ihre für Jahr 2000 Projekte ausgewählten Mitarbeiter und die, die vielleicht ein Lösungsanbieter zusätzlich mitbringt, ausreichend auszubilden und auf ihre Jahr 2000 Aufgaben vorzubereiten. Insbesondere das Training auf neue Wartungs-, Verwaltungs- und Testumgebungen und damit auch für neue Werkzeuge sollte nicht vernachlässigt werden.

3.1.4

Was folgt daraus?

=> Die Jahr 2000 Probleme entstehen entlang dem Zeitstrahl, das macht diffizile Zeitplanungen fur Projektarbeiten nötig. Der Aufwand der Jahr 2000 Projekte läßt sich nur phasenweise festlegen. => Da Sie - auch bei Einsatz von Werkzeugen - niemals genug EDV-Personal für alle Jahr 2000 Projekte haben werden, liegt die Entscheidung über Erfolg oder Mißerfolg Ihres Jahr 2000 Projektes bei der Effektivität Ihrer Projektorganisation und der Produktivität ihrer Projektmitarbeiter.

3.2

Bestandsaufnahme und Analyse der EDVAnwendungen

•

EDV-Anwendungen finden

•

EDV-Anwendungen erfassen

•

EDV-Anwendungen beurteilen

•

Was folgt daraus?

Der Startpunkt für Jahr 2000 Projekte ist die Analyse, also die Untersuchung, welche fachlichen Anwendungen Sie haben und wie diese Anwendungen als Programme und Daten auf Ihren EDV-Systemen eingerichtet sind. Ohne Analyse können Sie den Umfang Ihrer Jahr 2000 Projekte nicht beurteilen und alle Änderungen im Rahmen der normalen Wartung bleiben Stückwerk oder Fortsetzung der bisherigen Flickschusterei. Machen Sie aus der Not eine Tugend. Die Not liegt im Umfang der Analyse und der Mühe, die vielen einzelnen Anwendungen zu finden, zu erfassen und zu beurteilen. Die Tugend entwickelt sich aus der aufgewandten Mühe und stellt sich dar als Verzeichnis aller Anwendungen.

3 Die ED V vor dem Jahr 2000 - Chancen

66

Einrichtung des Jahr 2000 Projektrahmens

Einrichtung eines Jahr 2000 Projektes

SystemManagement

Inventar der EDV-Systeme /

Analyse der EDV-Systeme

?

korrekt

fehlerhaft

Umsetzung der Lösung

E D V - und ElektronikHersteller

3.2 Bestandsaufnahme und Analyse der ED V-Anwendungen 3.2.1

67

E D V-Anwendungen finden

Warum soll es überhaupt schwer sein, alle EDV-Anwendungen eines Unternehmens oder einer Verwaltung zu finden? Es gibt keine gesetzliche Verpflichtung, softwaregestützte Systeme zu registrieren. Es gibt sogar das gesetzliche Verbot, selbst erstellte Software zu bilanzieren. Zahlreiche Programme haben einen niedrigen Verkaufspreis und werden als geringwertige Programme nicht bilanziert. Trotzdem können für das Unternehmen bedeutende A n w e n d u n g e n mit dieser Software verarbeitet werden. Software versteckt sich oft in Hardware oder Geräten. Diese werden verkauft; Software als davon getrenntes Produkt tritt nicht in Erscheinung. Sie benötigen also verschiedene Suchmethoden, um EDV-Anwendungen zu finden. Diese Methoden sollten alle der Reihe nach angewendet werden, um möglichst keine A n w e n d u n g zu übersehen.

1. Die erste Methode orientiert sich an Nutzergruppen: Es gibt EDV-Nutzer in den Fachabteilungen und im Betrieb, Kaufleute, Techniker, Ingenieure. Dementsprechend gibt es auch betriebswirtschaftliche und technische Anwendungen. Dann gibt es Programmierer und deren Werkzeuge, also entwicklungsunterstützende Anwendungen; es gibt Operatoren und deren Hilfsprogramme und es gibt Systemmanager und deren Verwaltungsprogramme für Hardware und Software und Daten.

2. Die zweite Methode orientiert sich an Anwendungsfunktionen: Es gibt Programme, die nur Lesen, andere führen auch Änderungen durch. Das Lesen wie das Ändern kann nun in einer Zeitspanne erfolgen, die ein Nutzer zu warten bereit ist, oder es erfolgt als Hintergrundverarbeitung auf Anforderung oder periodisch. Tabelle 7: Typisierung von

Anwendungsfunktionen

zeitnah

verzögert

Lesen

Abfragen

Berichte

Ändern

Transaktionsverarbeitung

Massenbuchungen

Für jeden dieser Anwendungstypen kann es wiederum Verwaltungsprogramme geben. Für zeitnahe Operationen sind das Transaktionsmonitore, für verzögerte sind das Batch Monitore.

3. Die dritte Methode orientiert sich an der Art der Verwaltung: Die Verwaltung von Anwendungen m a g zentral sein, lokal in einer Abteilung oder beim einzelnen Benutzer liegen oder sich gar nicht im Unternehmen befinden, son-

68

3 Die ED V vor dem Jahr 2000 - Chancen

dem beim Lieferanten oder beim Dienstleister. Natürlich wird es auch in einer Zentrale Anwendungen geben, die von einem einzelnen Benutzer verwaltet werden. 4. Die vierte Methode orientiert sich an der Sichtbarkeit von Hardware und Software: Sowohl Hardware als auch Software mögen sichtbar sein, wie z.B. in einem Rechenzentrum, die Software mag unsichtbar sein, wie z.B. in einem Spezialrechner oder auch beide können sich in einem Gerät oder in einer Produktionsanlage verbergen. Gerade in jüngster Zeit findet der letztere Fall besondere Aufmerksamkeit: „Will the century date change become one huge wrench in the works of U.S. manufacturers? Quite possibly. Industrial plants and factories are often pakked to the rafters with highly automated, very sophisticated, thoroughly integrated, and very date intensive information systems. Systems which monitor and control production operations. Track inventory. Schedule maintenance. Communicate with suppliers and customers." (105) „Wird der Jahrhundert-Datumswechsel zu einer gigantischen Verwirrung in der Arbeit der U.S. Produzenten führen? Durchaus möglich. Industrielle Anlagen und Fabriken sind oft bis zum Dach vollgepackt mit hoch automatischen, sehr trickreichen, völlig integrierten und sehr datenintensiven Informationssystemen. Systeme, die die Produktion überwachen und steuern. Lagerverwaltung. Ablaufplanung. Kommunikation mit Lieferanten und Kunden. Oft werden Chips, die nicht mehr in PCs verkauft werden können, wie z.B. der „286-Prozessor", für Aufgaben der Prozeßsteuerungen eingesetzt. Die meisten Modelle diese Chips sind nicht Jahr 2000 fähig (H05). Übrigens war es nur in der Prozeßtechnik normal, daß Speicher knapp und teuer war. Zudem wurden prozeßnahe Systeme häufig von einzelnen Tüftlern programmiert. Aus diesen beiden Gründen sind diese Anwendungen besonders skeptisch zu betrachten. 5. Die fünfte Methode orientiert sich am Bezug der EDV zu einer betrieblichen Funktion: Dieser Bezug mag direkt sein, wie bei der Nutzung von Terminals oder von PC, oder mag indirekt sein und dann gehört die EDV-Funktion zur allgemeinen oder technischen Infrastruktur. Zur allgemeinen Infrastruktur gehören z.B. Gebäudetechnik und Zutrittssicherheit, zur technischen Infrastruktur z.B. Kommunikationsund Netzwerktechnik.

3.2 Bestandsaufnahme und Analyse der ED V-Anwendungen

69

Die Ergebnisse aller Suchmethoden werden zusammengetragen. Manche Anwendungen werden natürlich mehrfach entdeckt, sollten aber nur einmal registriert werden. Für jede gefundene Anwendungen werden alle Anwendungsteile oder Anwendungsfunktionen aufgelistet.

3.2.2

ED V-Anwendungen erfassen

Falls Ihre fachlichen Anwendungen von Menschen genutzt werden, so können Sie diese Anwender an der nun folgenden Untersuchung beteiligen. Falls Ihre fachlichen Computeranwendungen wiederum nur von Computern genutzt werden, sind Sie alleine auf EDV-Lieferanten, Programmierer und Systemverwalter angewiesen. Bei Geräten mag es wieder anders sein: nur Ihre Ingenieure können Ihnen helfen; den Programmierern fehlt der Programmtext, die Systemverwalter waren noch nie für diese Geräte zuständig und Ihr Lieferant hat bisher keinen entsprechenden Test vorgesehen. Zu jedem gefunden Anwendungsteil bzw. zu jeder darunter gefundenen Anwendungsfunktion werden Eigenschaften notiert, die für das Jahr 2000 Problem von Bedeutung sind. Diese Empfehlung orientiert sich übrigens am Vorgehen der Bayer AG (T02). Die Eigenschaften ergeben sich durch die Beantwortung folgender Fragen: •

Werden Datumswerte bzw. Termine eingegeben oder ausgegeben?

•

Wenn zutreffend, sind anzugeben Feldname, Darstellungsformat und Ein- und Ausgabe-Verhalten: nur Eingabe, nur Ausgabe oder sowohl Eingabe als auch Ausgabe.

•

Werden Werte mit spezieller Bedeutung („magische Zahlen") in Datums- oder Jahresfelder eingegeben?

•

Erzeugt die Anwendung selbständig Uhrzeit oder Datum?

•

Werden Datumswerte sortiert oder wird mit ihnen sortiert?

•

Verhält die Anwendung sich an verschiedenen Wochentagen unterschiedlich?

•

Werden Datumswerte an andere Anwendungen versandt oder von anderen Anwendungen empfangen?

•

Werden Datumswerte mit Kunden oder mit Lieferanten ausgetauscht?

•

Wird auf Datenbestände, die einen Datumswert enthalten, zugegriffen?

•

Wird die Anwendung ein Datumsproblem haben?

Abbildung 3 zeigt einige Anwendungsarten und für deren Teile und Funktionen die möglichen Beurteilungen, die das nächste Kapitel vornehmen wird.

70

3 Die EDV vor dem Jahr 2000 - Chancen

systemverwaltende

betriebswirtschaftliche

i i

l

j ;

entwicklungsunterstützende

1 I

II—J

Anwendungen

I I

Anwendungsteile

Anwendungsfunktionen

problematische

Abbildung

3.2.3

3: Überblick

unverdächtige

über

umgestellte

EDV-Anwendungen

EDV-Anwendungen beurteilen

Wenn alle Fragen des letzten Abschnittes mit Nein beantwortet wurden, so ist die Anwendung unverdächtig. Wenn nur eine der Fragen mit Ja beantwortet wird, so kann die Anwendung ein Datumsproblem enthalten. Sie kann dann auch korrekt sein, doch trauen Sie einem „Nein" als Antwort auf die letzte Frage nicht: „Egal, was die Programmierer anfangs behaupteten, bei Daimler Benz erwies sich zunächst kein einziges Programm als Jahr-2000-gängig", berichtet Josef Kisting von der Beraterfirma Debis." (nach W03) Für jede problematische Anwendung und für Anwendungen, für die Korrektheit behauptet wird, ist also ein Test durchzuführen. Auf einem separaten Rechner nähert man sich mit simulierter Zeit dem Jahr 2000 und prüft auch Datumswerte danach. Was im einzelnen geprüft werden kann und was bei einem Test zu beachten ist, findet sich in den Kapiteln „Jahr 2000 Fähigkeit" und „Test". Das Ziel dieses ersten Tests ist es nicht, möglichst umfassend zu testen, um Problemfreiheit wahrscheinlich zu machen, das Ziel ist vielmehr, mindestens ein Problem zu finden. Zu den Eigenschaften des ersten Abschnittes können Sie nun zusätzlich notieren, ob eine Anwendung von einem Jahr 2000 Problem betroffen ist oder nicht. Mögli-

3.3 Bestandsaufnahme und Analyse der ED V-Systeme

71

cherweise wurde eine Anwendung, die ihre Tests nun besteht, irgendwann in der Vergangenheit schon auf die Jahr 2000 Fähigkeit umgestellt, notieren Sie auch das. Vielleicht können bestimmte Lehren daraus sich noch als nützlich erweisen. Bei den betroffenen Anwendungen ist zu erfragen, welche Datumswerte immer nur Zeitpunkte darstellen und welche Datumswerte in Berechnungen oder Sortierungen eingehen. Es ist auch zu klären, was die maximale Länge von Zeitintervallen in einer Anwendung sein kann und wie viele Jahre in die Zukunft voraus gerechnet werden kann. Eine - auch zu notierende - geplante Abschaltung oder Ablösung dieser Anwendung sollte also vor einem Zugriff auf das Jahr „99" mit spezieller Bedeutung oder das Jahr 2000 erfolgen. Anwendungen, mit denen rechtliche Verpflichtungen erfüllt werden oder die eine besondere wirtschaftliche Bedeutung haben, können natürlich nicht abgeschaltet sondern bestenfalls abgelöst werden. Nun ist nur noch festzuhalten, ob eine betroffene Anwendung selbst erstellt oder fremd bezogen wurde.

3.2.4

Was folgt daraus?

=> Durch die hier dargestellte Bestandsaufnahme werden die meisten Unternehmen erstmalig alle ihre EDV-Anwendungen überblicken.

3.3

Bestandsaufnahme und Analyse der EDV-Systeme

•

Der Umfang der Bestandsaufnahme

•

Die Ablaufumgebung eines Programms

•

Die Entwicklungsumgebung eines Programms

•

Die Analyse eines Programmtextes

•

Was folgt daraus?

Ohne Analyse der EDV-Systeme können Sie den Umfang Ihrer Jahr 2000 Projekte nicht beurteilen und alle Änderungen im Rahmen der normalen Wartung bleiben Stückwerk. Auch diesmal können Sie aus der Not eine Tugend machen. Die Not liegt wiederum im Umfang der Analyse und der Mühe, die Programme und ihre Umgebung zu finden, zu erfassen und zu beurteilen und sie den Anwendungen zuzuordnen. Die Tugend entwickelt sich aus der aufgewandten Mühe und stellt sich dar als Verzeichnis aller Komponenten Ihrer EDV-Systeme.

3 Die ED V vor dem Jahr 2000 - Chancen

72

Einrichtung des Jahr 2000 Projektrahmens

Einrichtung eines Jahr 2000 Projektes

Analyse der EDVAnwendungen

Inventar der Anwendungen,

System Management

korrekt

fehlerhaft

Umsetzung der Lösung

E D V - und ElektronikHersteller

3.3 Bestandsaufnahme und Analyse der ED V-Systeme

3.3.1

73

Der Umfang der Bestandsaufnahme

Die ganze Komplexität der Analyse will dieses Kapitel aufzeigen. Und weil dieser Teil der Analyse in der Regel nicht auf eine leicht verständliche und korrekte Dokumentation zurückgreifen kann, sind die folgenden Ausfuhrungen systematisch angelegt, um Ihnen dabei zu helfen, nach und nach die Komplexität zu reduzieren. Der Umfang der Bestandsaufnahme ist bestimmt durch die Anzahl der Rechner, Programme und Dateien und durch die komplexen Zusammenhänge in einer Programmumgebung. Das Ziel der Untersuchung ist, zu allen wahrscheinlich betroffenen Anwendungen die zugehörigen Systeme in Hardware und Software zu entdekken und ihre Jahr 2000 Fähigkeit oder Unfähigkeit im Einzelnen nachzuweisen. In jedem mittleren oder großen Unternehmen finden sich Hunderte von Anwendungen, die über Tausende von Programmen und Dateien realisiert sind. Jeder einzelne Programmtext kann wiederum viele tausend Programmzeilen enthalten. Tabelle 8: Größe einzelner Programmsysteme bei ausgewählten Anwendern in LOC (Lines of Code - Anzahl Programmtextzeilen) lt. SEEC (S06) Bank of N e w York

40 Mio. LOC

Harris Bank

10 Mio. LOC

Wells Fargo

20 Mio. LOC

Foremost Insurance

6 Mio. LOC

Anthem Insurance

60 Mio. LOC

Wheeling Pittsburgh Steel

10 Mio. LOC

Mack Trucks Alcoa

6 Mio. LOC 25 Mio. LOC

Mit der Umgebung eines Programms werden sie sich auseinandersetzen müssen, wenn Sie zu einer betroffenen Anwendung die zugehörigen Programme finden möchten. Eigentlich gibt es das nicht, „das Programm" auf einem Rechner. Den Ausdruck „Programm" kann man sowohl beschreiben als Folge von Befehlen in einer Programmiersprache als auch als Folge von Instruktionen für eine CPU. Dem entspricht auf der einen Seite die Ablaufumgebung eines Programms, in der es ausgeführt wird, und auf der anderen Seite die Entwicklungsumgebung, in der es erzeugt wird. Zur Ablaufumgebung gehören die Ausdrücke „Prozeß" und „Programmobjekt", zur Entwicklungsumgebung „Programmtext" und „Kompilierer". Wenn Sie mit der Terminologie der EDV nicht sehr vertraut sind, empfiehlt es sich, vor der Lektüre der nächsten Abschnitte das Glossar und die darauf folgende Hierarchie der EDV-Begriffe durchzusehen.

74

3 Die ED V vor dem Jahr 2000 - Chancen

3.3.2

Die Ablaufumgebung eines Programms

Es geht im Folgenden um die prinzipiell möglichen Zusammenhänge eines Programms mit seiner Ablaufumgebung, das heißt nicht, daß alle Zusammenhänge auf jedem Rechner zu finden sind. Beachten Sie auch, daß die einzelnen Komponenten der Umgebung eines Programms durchaus von EDV-Herstellern oder anderen Autoren anders und auch wieder untereinander unterschiedlich benannt sein können. Daher finden Sie zur hier benutzten Wortwahl die Erklärungen im Glossar. Zu einer problematischen Anwendungsfunktion aus der Analyse des letzten Kapitels muß man im nächsten Schritt deren Implementierung als Programm finden. Falls sich durch die Anwendungsanalyse ergeben haben sollte, daß ein großer Teil Ihrer Anwendungen möglicherweise vom Jahr 2000 Problem betroffen ist, so lohnt es sich, alle Programme zu registrieren. Falls Sie als Realisierung Ihrer Anwendung nur ein Stück Elektronik oder ein Gerät in der Hand haben, so endet die Analyse hier. Sie können es vielleicht testen, zur Behebung eines Fehlers oder für eine Erklärung der Fehlerfreiheit müssen Sie sich an den Hersteller wenden. Um die bei der Analyse anfallenden Arbeiten parallel und mit der nötigen Expertise durchfuhren zu können, sollten diese aufgeteilt werden, und zwar je nach Art der Anwendungen, die Host-zentriert oder Server- oder Netzwerk-zentriert oder PCzentriert sein mag. Die zunehmende Verbreitung von auf mehrere Plattformen verteilten Anwendungen macht diese Aufteilung nicht leichter. Oft gehören also zu einer Anwendung oder auch zu einer einzelnen Anwendungsfunktion nicht nur ein Programm, sondern eine Menge von Programmen, ein Programmsystem. Innerhalb eines Programmsystems werden dann auf unterschiedliche Art und Weise Daten ausgetauscht, zum Teil über Netzwerke hinweg. Jedes Programm kann über einen oder auch mehrere Prozesse ausgeführt werden. Diese Prozeßkopien unterscheiden sich nicht in der Programmlogik sondern nur in der Art und Menge der ihnen vom Betriebssystem zur Verfügung gestellten Betriebsmittel. Daher kann die Beobachtung des Betriebes auf einem Rechner über einen gewissen Zeitraum folgende Ergebnisse liefern: •

die Prozesse zu einem Programmsystem einer Anwendungsfunktion

•

die Prozesse des Betriebssystems

•

viele Prozesse zu wenigen Programmobjekten

•

keine Prozesse zu einer Anwendungsfunktion

•

Prozesse ohne Anwendung

3.3 Bestandsaufnahme und Analyse der ED V-Systeme

75

Die ersten beiden Fälle liefern das Gewünschte; im dritten Fall muß die Information auf das Wesentliche, nämlich die Programmobjekte, reduziert werden. Falls, wie im vierten Fall, keine Prozesse zu einer Anwendungsfunktion gefunden werden können, so wurde die Funktion im Beobachtungszeitraum nicht ausgeführt. Manche Funktionen werden eben nur einmal monatlich oder einmal jährlich oder bei Bedarf ausgeführt. Wenn wie im letzten Fall Prozesse zu sehen sind, zu denen keine Anwendungsfunktion gefunden werden kann, so gehören die Prozesse entweder zum Betriebssystem oder zu einer Anwendung, die bei der bisherigen Analyse übersehen wurde. Die laufenden Prozesse tauschen untereinander Daten aus oder greifen auf Dateien und Datenbanken zu. Wo eben möglich sollte man die Prozeßbeobachtung darauf ausdehnen. Denn diese programmexternen Daten können sowohl durch Jahr 2000 Probleme eines Programms verfälscht werden, als auch bei zweistelliger Abspeicherung der Jahreszahl zur Problemursache werden. Die laufenden Prozesse greifen auch auf Betriebssystemfunktionen zu und aktivieren damit verschiedene Softwareschichten und Hardwarekomponenten, die alle ein Jahr 2000 Problem haben können. So haben fast alle älteren PCs und viele neuere PCs ein Jahr 2000 Problem im Zusammenspiel von BIOS als Firmware, DOS als Betriebssystem und der RTC (Real Time Clock - Realzeituhr) als einer Hardwarekomponente (S07). Die RTC ist eine Uhr mit Batterie, die Datum und Uhrzeit bei ausgeschaltetem PC fuhrt, allerdings mit zweistelliger Jahreszahl. Im BIOS gibt es einen Zähler, dessen Startwert beim Einschalten des PC über die Angabe des RTC gesetzt wird und der dann weiter zählt. DOS verwandelt den Zählerstand des BIOS in die Anzeige von Datum und Uhrzeit. Falls die Batterie des RTC leer ist und daher der Zähler im BIOS nicht besetzt wird, setzt DOS als Datumswert den 1.1.1980. Wenn der RTC im simulierten oder wirklichen Jahr 2000 als Jahreszahl „00" liefert, dann versucht das BIOS einen Zählerstand ab 1900 zu finden, das fuhrt zu einem Überlauf und der Fehlercode des Überlaufs findet sich in der DOSDatumsangabe als 1.4.1980. Das Problem liegt also nicht alleine im BIOS und das BIOS hat auch kein Jahr 2000 Problem, sondern es hat eher ein Problem mit dem Jahr 1900. Probleme der hier beschriebenen Art sind auch in anderen Rechnern oder in elektronischen Geräten möglich. Auch hier müssen Sie sich zur Klärung an Ihren Lieferanten wenden. Die laufenden Prozesse nutzen oft Betriebssystemfunktionen nicht direkt, sondern nur indirekt vermittels Programmbibliotheken, die in ein Objekt eingebunden sein können oder zur Laufzeit zur Verfugung stehen. Bibliotheken findet man häufig für Funktionen der Middleware, also für Datenbankzugriff, Datenaustausch und Trans-

76

3 Die ED V vor dem Jahr 2000-

Chancen

aktionsverarbeitung, aber auch für Routinen zur Berechnung von Datumswerten. Diese Bibliotheken können nun auch wieder selbst erstellt oder geliefert sein. Von den Prozessen des Betriebssystems einmal abgesehen haben wir nun zu den Prozessen die zugehörigen Programmobjekte gefunden. Beim Betriebssystem ist wieder der jeweilige Hersteller in der Pflicht. Man kann nun auch wieder direkt auf dem Rechner nach Programmobjekten suchen; diese Suche kann folgende Ergebnisse liefern: •

die Objekte zu den Anwendungsprozessen

•

die Objekte zu Prozessen des Betriebssystems

•

die Objekte zu den Programmbibliotheken

•

keine Objekte zu einer Anwendungsfunktion

•

Objekte ohne Anwendung

Die ersten drei Fälle liefern das Gewünschte. Falls wie im vierten Fall keine spezifischen Objekte zu einer Anwendungsfunktion gefunden werden können, so wird die Funktion über einen Interpreter ausgeführt. Wenn, wie im letzten Fall, Objekte ohne Anwendungsfunktion gefunden werden können, so sind die Objekte entweder historisch oder sie gehören zu einer Anwendung, die bei der bisherigen Analyse übersehen wurde. Im Gegensatz zu der Situation bei den Prozessen können und sollen Programmobjekte zu der gleichen Funktion in verschiedenen Versionen auftreten. Auf einem produktiv genutzten Rechnersystem befindet sich eine aktuelle Version zur Ausführung, ein Objekt in Vörgängerversion für den Fall, daß die aktuelle Version Probleme hat, und möglicherweise ein Objekt in Nachfolgerversion, das gerade neu entwickelt worden ist. Falls sich weitere Versionen finden, so sind diese als historisch anzusehen und auszurangieren. Viele Unternehmen haben ein Ausweichrechenzentrum, um möglichen Katastrophen vorzubeugen. Bei der möglichen Jahr 2000 Katastrophe wird diese Sicherheitsplanung aber keinen Nutzen bringen, da im Ausweichrechenzentrum die gleichen problematischen Programme ausgeführt werden. Um sich eine doppelte Analyse zu ersparen, kann der ganze Programmbestand des produktiven Rechenzentrums nach Bereinigung in das Ausweichrechenzentrum übernommen werden. Es ist auch immer daran zu denken, die zahlreichen Programmumstellungen, die sich im Zuge der Jahr 2000 Projekte ergeben, im Ausweichrechenzentrum nachzuvollziehen. Nun verlassen wir die Programmobjekte und wenden uns den Programmtexten zu. Die Objekte sind für die CPU immer gleich jung, während manche Programmtexte doch ziemlich alt aussehen:

3.3

Bestandsaufnahme

und Analyse der EDV-Systeme

77

Host

Server

problematische Anwendungsfunktion

Firmware Hardware

J

Dokum entationen

Abbildung 4: Überblick über Ablauf- und Entwicklungsumgebung eines Programms

„Ein Phänomen der EDV kommt verschärfend hinzu: die Gleichzeitigkeit des Ungleichzeitigen. Das bedeutet, daß heute gleichzeitig Programme ausgeführt werden oder zur Ausfuhrung bereitstehen, die zu ganz unterschiedlichen Zeiten in der Vergangenheit entwickelt wurden." (H01)

78

3 Die ED V vor dem Jahr 2000 -

3.3.3

Chancen

Die Entwicklungsumgebung eines Programms

Ein Programmtext kann zur Laufzeit eines Prozesses in Instruktionen umgesetzt werden, dann wird er interpretiert und wir haben das Programmobjekt des Interpreters gefunden. Das Kommando für den Aufruf des Interpreters liefert uns dann den Namen der Datei mit dem Programmtext. Jahr 2000 Probleme können natürlich sowohl im Interpreter als auch im zu interpretierenden Programmtext gefunden werden. Oder ein Programmtext wird zur Entwicklungszeit eines Programmes in Instruktionen umgesetzt, die in einem Programmobjekt abgelegt werden. Dann sind zu einem oder mehreren Programmobjekten die zugehörigen Programmtexte zu suchen. Dieser Fall ist der schwieriger zu bearbeiten als der Fall des Interpreters. Denn ein Prozeß kann eine Programmobjekt und mehrere Bibliotheken nutzen. Ein Objekt im Programm oder in einer Bibliothek kann sich aus mehreren Unterprogrammen zusammensetzen. Alle diese Objekte gibt es in mindestens zwei gültigen Versionen. Nun gilt es, zu einem Programmobjekt den passenden Programmtext zu finden. Zu einem Objekt gehört ein primärer Text, der dem Kompilierer zur Übersetzung gegeben wird und viele sekundäre Textstücke, die in die Kompilierung einbezogen werden. Die Texte verschiedener Objekte können sich durchaus in einer Datei befinden. Wenn kein Text gefunden werden kann, so ist das Objekt im günstigsten Fall gekauft, im ungünstigsten Fall selbst entwickelt und der Text ging verloren. Ein anderer Fall kann sich so darstellen: Ein Text wird gefunden, doch man ist unsicher, ob er in der richtigen Version vorliegt. Ein Text ist nur dann gültig, wenn aus ihm ein Objekt exakt reproduziert werden kann. Dafür sind fünf Voraussetzungen nötig: •

die primären und sekundären Programmtexte haben die richtige Version,

•

die einzubindenden Unterprogramme haben die richtige Version,

•

der Kompilierer liegt in der richtigen Version vor und ist ausführbar,

•

die Regeln für die Kompilierung sind vorhanden und korrekt,

•

es erfolgten keine Änderungen direkt im Objekt.

Man sieht hier auch, daß es nicht ausreichend ist, nur den Programmtext an sicherer Stelle zu hinterlegen, um sich gegen Wartungsausfälle der Software-Lieferanten zu wappnen. Auch Standardsoftware kann speziell entwickelte Programmteile über unterschiedliche Mechanismen enthalten, um den „Standard" an besondere betriebliche Bedürfnisse anzupassen.

3.3 Bestandsaufnahme und Analyse der ED V-Systeme

79

Enttäuschender ist es sicher, wenn es gelingt, den korrekten Text zu finden, dieser aber in einer nicht mehr gebräuchlichen Programmiersprache verfaßt ist, oder man versteht durchaus j e d e s einzelne Wort der Sprache, aber den Sinn kann man nicht mehr erfassen. Das gleiche kann man mit dem Text einer Dokumentation erleben. Es gibt zwar Werkzeuge, die aus einem Objekt den verloren gegangenen Programmtext wieder erzeugen können. Doch ein beliebiger Kompilierer, der dieses Objekt erzeugte, machte und macht natürlich auch heute selbst aus einem wohl strukturierter Programmtext viele Sprunganweisungen im Objekt. Daher ist ein solcher von einem Werkzeug generierter Programmtext nur Spezialisten verständlich. Es gibt auch Werkzeuge mit dem ehrgeizigen Ziel, aus einem unverständlichen Programmtext eine verständliche Dokumentation zu erzeugen. Wie Objekte ohne Text oder ohne Dokumentation trotzdem in die Jahr 2000 Umstellung einbezogen werden können, wird im Kapitel „Lösungsalternativen" beschrieben.

3.3.4

Die Analyse eines Programmtextes

Es sei endlich ein korrekter und hoffentlich verständlicher Programmtext gefunden. Irgendwo in diesem Text mit seinen vielen Tausend Befehlszeilen und seinen vielen Hundert Definitionen von Datenfeldern liegt nun das Jahr 2000 Problem in vielfältiger Gestalt versteckt. Ein Datenfeld wird definiert über die Angabe von N a m e n und Datentyp für eine Folge von Zeichen. Ein Datenfeld kann Teil eines Datensatzes sein, muß es aber nicht. Beginnen wir unsere Suche beim Namen f ü r ein Datenfeld. Ein N a m e ist eine beliebige Folge von Zeichen aus einem j e nach Programmiersprache unterschiedlichen Zeichenvorrat, wobei in vielen Programmiersprachen nicht zwischen Kleinund Großbuchstaben unterschieden wird, in anderen aber doch. Im günstigsten Fall ist ein Datenfeld, das eine Jahreszahl enthält, daran zu erkennen, das sich im N a m e n des Datenfeldes die folgenden (Teil-)Worte oder Abkürzungen finden: „Jahr" oder , j j " oder ,jjjj" oder die englischsprachigen Entsprechungen „year" oder „yy" oder „yyyy". Üblicherweise ist eine Jahreszahl aber Teil eines Datums, so daß dann entsprechend nach „ D a t u m " oder „date" oder passenden oder vielfach auch weniger passenden Abkürzungen zu suchen ist. N u n ist ein Datum wiederum Teil einer Zeitangabe, so daß dann entsprechend nach „Zeit" oder „time" oder Abkürzungen davon zu suchen ist. Ein Datum und damit eine Jahreszahl wird sich auch in vielen anwendungsspezifischen N a m e n finden, in denen „Jahr", „Datum", „Zeit" gerade nicht vorkommt, wie z.B. Geburtstag, Lieferwoche, Vertragsbeginn. Insbesondere hat wohl niemand die Empfehlung ISO-Standards befolgt und deswegen ein Feld, das eine zweistelli-

80

3 Die EDV vor dem Jahr 2000 - Chancen

ge Jahreszahl enthält, mit „year-of-century" bezeichnet. Jeder Programmierer konnte bisher in jeder Programmiersprache die Namen für Datenfelder in „seinem" Programm frei wählen. Er kann auch Feldern der externen Datenbank neue Namen geben oder externe Felder neu zusammenfassen oder in mehrere Felder auftrennen. In einigen Unternehmen gibt es Richtlinien für die Namensvergabe; diese umfassen meistens nur die Dateinamen und die Namen für Felder in Datensätzen. Selbst wenn sich Richtlinien auf interne Namen in einem Programmtext beziehen, gibt es keine automatische Kontrolle, ob sich auch alle Programmierer aller Abteilungen und aller zuliefernden Softwarehäuser daran gehalten haben. Wenn es also Richtlinien dafür gibt, muß nun überprüft werden, welche weiteren Feldnamen im Lauf der Jahre dazu gekommen sind oder welche Namen vor Verabschiedung der Richtlinien in alter Software benutzt werden. Schon jetzt kann erkannt werden, daß sich jede Analyse, die nur auf Feldnamen aufsetzt, gleichgültig, ob sie manuell oder werkzeuggestützt verläuft, mit zwei Problemem konfrontiert sieht: entweder werden zu viele Datenfelder gefunden dann lohnt sich die Analyse nicht, oder es werden zu wenige Datenfelder gefunden - dann wird das Jahr 2000 Problem nicht korrigiert. Also beginnen wir unsere Suche erneut beim Datentyp für ein Datenfeld. Datenfelder gleicher Bedeutung sollten den gleichen Datentyp haben, haben aber möglicherweise ganz unterschiedliche Datenfeldnamen. Ein Datentyp ist eine Name für einen zulässigen Wertebereich für ein Datenfeld. Solche Namen sind entweder in nur geringer Zahl fest von der jeweiligen Programmiersprache vorgegeben - somit werden wieder zu viele Datenfelder gefunden - oder sie können frei gewählt werden - dann ergeben sich die gleichen Suchprobleme wie bei Datenfeldnamen. Jeder Programmierer konnte bisher in jeder Programmiersprache die Datentypen für Datenfelder in „seinem" Programm frei wählen. Er kann auch Datentypen der externen Datenbank neue Datentypen geben, zuweilen muß er das sogar, weil in der von ihm genutzten Programmiersprache kein passender Datentyp gegeben ist. Das ist ein übliches Problem, wenn man Zugriffe auf SQL Datenbanken in COBOL oder C einbetten möchte. SQL hat die korrekten Datumstypen mit vierstelliger Jahreszahl, nämlich DATE, TIMESTAMP und INTERVAL. Interessanterweise sind es aber gerade diese, die keine Entsprechung in den genannten Programmiersprachen finden. Und auch in einer SQL-Datenbank hatte und hat man die Freiheit, die erst seit 1992 standardmäßig vorgegebenen korrekten Datentypen für Datenfeldern zu nutzen oder eben auch nicht. In einigen Unternehmen gibt es Verzeichnisse der Datentypen und der Datenfelder, die diese Typen nutzen; diese umfassen leider meistens nur die Typen für Felder in Datensätzen und in Nachrichten zwischen Programmen und damit auch nur die dort befindlichen Datenfelder. Selbst wenn sich Richtlinien auf interne Datentypen

3.3 Bestandsaufnahme und Analyse der ED V-Systeme

81

in einem Programmtext beziehen, gibt es keine automatische Kontrolle, ob sich auch alle Programmierer aller Abteilungen und aller zuliefernden Softwarehäuser daran gehalten haben. Wenn es also Richtlinien dafür gibt, muß nun überprüft werden, welche weiteren Datentypen im Lauf der Jahre dazu gekommen sind oder welche Datentypen vor Verabschiedung der Richtlinien in alter Software benutzt werden. Also kann eine erfolgreiche Analyse weder auf Datenfeldnamen noch auf Datenfeldtyp aufsetzen. Es gibt eine weitere Schwierigkeit mit N a m e n und Typen, nämlich die stillschweigende Vereinbarung. Der N a m e einer Konstante wie „19", „1900", „20", „2000" oder der N a m e für magischer Zahlen ist nur dem Kompilierer bekannt, der ihn nach der Kompilierung wieder vergißt. Der Typ eines Literais wie „Schaltjahrtest" (Name für Konstante „4") ist wiederum nur implizit gegeben. Selbst wenn alle Felder mit Jahreszahlen gefunden sind, so ist nicht j e d e zweistellige Jahreszahl problematisch - es kann sich auch um eine bloße Zeitangabe ohne Verarbeitung handeln - und nicht j e d e vierstellige Jahreszahl ist unproblematisch es kann auch in der ersten Hälfte die Konstante „19" enthalten sein. Also beginnen wir unsere Suche wieder neu mit Datenfeldern, die bei der Bestandsaufnahme der Anwendungen als kritisch bezeichnet wurden. Die Werte in diesen Datenfeldern werden auf andere Felder kopiert oder entnehmen ihren Wert anderen Feldern oder werden mit anderen Feldern verrechnet. Es beginnt also entweder eine Spurensuche im Programmtext von Feld zu Feld oder die logische Adresse, unter der die Wertablage zur Kompilierzeit simuliert wird, wird überwacht. Entsprechend gibt es Werkzeuge, die entweder den einen Teil eines Kompilierers für eine Programmiersprache nachbauen, nämlich die syntaktische Analyse eines Programms, zwecks Spurensuche, oder die einen anderen Teil nachbauen, nämlich die semantische Analyse, zwecks Speicherüberwachung. Bei beiden Arten von Werkzeugeinsätzen kann man die Erfolgschance erhöhen, indem man mit Jahreszahlenwerten belegte Datenfelder der Datenbank, wie z.B. „95", „96", „97", oder gut dokumentierte Datenfelder aus Nachrichten zwischen Programmen als weitere Ausgangspunkte nennt. Ausgangspunkte für die Analyse sind auch die Übernahme des aktuellen Datums aus dem Betriebssystem oder über eine Funktion der Datenbank. M a n kann selbstverständlich auch zum Erfolg beitragen, wenn man korrekt ermittelte Datenfelder aus der Auswertung von Datenfeldnamen und Datenfeldtypen hinzuzieht. Die Analyse der Datenwerte kann einem auch Hinweise geben auf die Existenz magischer Zahlen; denn diese Werte in Jahreszahlen, wie etwa „ 9 9 " oder „00", finden sich nicht nur in Programmen sondern auch in Datenbanken, w o sie durch Benutzereingaben entstehen. Im Jahr 1997 ließen sie sich noch einfach an der Lükke zur Folge „95", „96", „97" erkennen, jedoch ab dem Jahr 1998 entfällt dieses einfache Muster, da dann auch „98" als Datenwert auftritt.

82

3 Die ED V vor dem Jahr 2000 - Chancen

Die Spurensuche scheitert meist an Pointern, also speziellen Datenfeldern, die allerdings nicht in allen Programmen benutzt werden. Der Name eines Datenfeldes ist eigentlich der Name für eine Adresse, die auf den Beginn einen Speicherbereichs verweist, in dem sich der Wert des Datenfeldes befindet, und zwar in einer Länge und Codierung, die der Typ des Datenfeldes angibt. Dagegen ist der Name eines Pointer-Datenfeldes der Name für eine Adresse, die auf den Beginn einen Speicherbereichs verweist, in dem sich eine Adresse befindet, und zwar in Länge und Codierung, die der Typ des Pointers angibt. Diese letztere Adresse kann auf irgendeinen Speicherbereich zeigen und sie kann wie andere Werte verarbeitet werden. Manchmal kann man auch den Namen eines Feldes als Pointer gebrauchen, z.B. kann die Angabe in einem Programm ,,next(4) for 2" die zweistellige Jahreszahl meinen ab einem Offset von 4 Byte, also ab der fünften Stelle des nächsten Datumsfeldes. Die Werkzeuge, die Speicheradressen überwachen, können oft auch die Werte der Pointer überwachen, allerdings nur wenn sie wie im Beispiel durch den Programmtext vorgegeben sind. Im Programm kann aber auch stehen „next(offset) for length". Hier müssen auch die Überwachungswerkzeuge resignieren - wie auch bei allen anderen dynamischen, nämlich zur Laufzeit vor sich gehenden Datenfeld bezogenen Verarbeitungen, der Erzeugung von einzelnen Datenfeldern und Gruppen von Datenfeldern nur zur Laufzeit oder der Erzeugung von temporären Dateien und Datenbanken. Solche Vorgänge sind glücklicherweise noch selten. Doch über neue Progammiersprachen und neue Datenbanken werden solche Fälle bald zunehmen. Hier helfen nur noch Testverfahren und Debugger weiter. Ein Debugger wurde, wie der Name „de bug er" als „Wanzen-Entferner" angibt, ursprünglich zur Entdeckung und manchmal zur Korrektur von Fehlern genutzt, die nur zur Laufzeit eines Programms auftreten. Er hat aber oft auch vielfache Möglichkeiten, Speicherbereiche zur Laufzeit eines Programms zu überwachen sowie Programmaktionen mitzuschreiben. Die Werkzeuge zur Spurensuche sind also oft erfolgreich, die Werkzeuge zur Speicherüberwachung fast immer. Allerdings gibt es solche Werkzeuge nur für einen kleinen Teil der Programmiersprachen. Mittlerweile gibt es aber auch Baukästen, um solche Werkzeuge für weitere Sprachen zu entwickeln. Alles ist „nur" eine Zeitfrage. Man kann leider nicht alles, was man jetzt nicht hat, nämlich Namensverzeichnisse, Abkürzungsverzeichnisse, Datentyp- und Datenfeldverzeichnisse, Versionsverwaltung von Programmtexten und Programmobjekten, in der verbleibenden Zeit bis Ende 1998 aufbauen - möglicherweise kann man mit einem Teil der Verzeichnisse einen Anfang machen. Wobei zugegebenermaßen die Empfehlung von Namensverzeichnissen nur eine Marotte des Autors in den letzten zehn Jahren war, während alle EDV-Hersteller

3.4

Lösungsalternativen

83

schon immer Versionsverwaltung und Anlage von Datenverzeichnissen empfohlen haben.

3.3.5

Was folgt daraus?

=> Durch die hier dargestellte Bestandsaufnahme werden die meisten Unternehmen erstmalig ihre EDV-Systeme überblicken und damit auch ihre Software und ihre Datenbestände. => Dadurch sind sie nicht nur für die Jahr 2000 Projekte gerüstet, sondern sie haben auch die Voraussetzungen geschaffen, um künftige Wartungs- und Testaufgaben effektiv abzuwickeln. => Mit den Kenntnissen dieses Kapitels können sie die Offerten der Lösungsanbieter besser beurteilen oder auch die Jahr 2000 Hausaufgaben der EDVHersteller abschätzen.

3.4

Lösungsalternativen

•

Verschönern

•

Erneuern

•

Nichts tun

•

Abreißen

•

Umbauen

•

Anbauen

•

Zeitreise

•

Was folgt daraus?

Durch die Analyse Ihrer Anwendungen und Ihrer EDV haben Sie nun Hunderte von möglicherweise problematischen Systemen entdeckt: Geräte, Elektronikbausteine, Hardware, Firmware, Betriebssysteme, Programmbibliotheken. Außerdem haben Sie Hunderttausende von problematischen Textstellen gefunden und einige selbst entwickelte Programmobjekte ohne passenden Text. Was soll damit nun geschehen? Stellen Sie sich nun folgenden Vergleich vor: Sie besitzen mehrere Häuser und sind mit dem Zustand einiger dieser Häuser unzufrieden. Die Mängelberichte mögen dabei auch Hunderte von Problemstellen aufzählen.

84

3 Die ED V vor dem Jahr 2000 - Chancen

Sie haben dann die folgenden Möglichkeiten mit dieser Situation umzugehen: Verschönern, Erneuern, Nichts tun, Abreißen, Umbauen, Anbauen oder eine Zeitreise unternehmen.

3.4

3.4.1

Lösungsalternativen

85

Verschönern

Sie lassen neu tapezieren und neu anstreichen. Für einige Anwendungen mag es völlig ausreichend sein, wenn Sie vom Hersteller der Software eine neue Version beziehen und diese einspielen. Sie fuhren ein „Update" durch, um wieder up-to-date zu sein. Falls dieses Update mit größerer Mühe verbunden ist, so nennen die Hersteller den Vorgang „Upgrade". Die Mühe kann in einer besonders umständlichen Installation bestehen oder darin, daß die neue Software unbedingt eine weitere Software zum Funktionieren benötigt, die Sie gerade nicht besitzen. Oder die neue Software braucht unbedingt neue Hardwarekomponenten, die sich in Ihrem gerade zwei Jahre „alten" System nicht befinden. Natürlich sind Ihre bisherigen Daten nicht mehr lesbar und die Konvertierung kann nur über ein weiteres Programm geschehen usw. Solche Vorgänge können sich über mehrere Monate hinziehen, also beginnen Sie rechtzeitig.

3.4.2

Erneuern

Sie lassen alles bis auf die tragenden Teile Ihres Hauses erneuern. Man mag daran denken, einige Anwendungen neu zu entwickeln durch eigenen Kräfte oder im Auftrag. Es soll doch auch Programmierwerkzeuge geben, die eine besonders schnelle Entwicklung gewährleisten, sogenannte „Rapid Application Development (RAD)" Tools. Es stellt sich die Frage, warum Anwendungen erst jetzt neu entwickelt werden können und warum bisher solche Werkzeuge nicht eingesetzt wurden. Wenn es auf diese Fragen zufrieden stellende Anworten gibt, so kann man es versuchen. Allerdings wird man nur einen Teil der Anwendungen rechtzeitig neu entwickeln können und auch nur solche Anwendungen, die nicht zu komplex sind. Daher ist zu empfehlen, eigene Entwicklungsanstrengungen auf die Programme zu konzentrieren, wo der vorhandene Programmtext stark fehlerhaft oder unverständlich oder nicht vorhanden ist. Außerdem sind für die Umsetzung anderer Taktiken spezielle Programme, sogenannte Brückenprogramme, zu entwickeln, damit ein neues Programm in alter Umgebung oder eine altes Programm in neuer Umgebung zurecht kommen kann. Man kann auch daran denken, ein passendes Programm aus einem Katalog auszuwählen und es als Ablösung für eine oder auch mehrere alte Anwendungen einzusetzen. Mit solch einem eingekauften Programmpaket kann man dann nicht nur die Jahr 2000 Probleme der ersetzten Anwendungen lösen, sondern auch noch die Umstellung auf die EURO-Währung durchfuhren. Wenn ein solches Programm tatsächlich gefunden werden kann, so ist das eine gute Taktik. Manche gehen noch weiter und verallgemeinern diese Taktik:

86

3 Die ED V vor dem Jahr 2000 - Chancen

„Don't even try to solve the year 2000 problem. You can't fix it, and the cost of trying will put your firm's infrastructure at risk. Accept defeat. Dump your old infrastructure, and get one that's year 2000-safe, even if it isn 't perfect." (KOI) „Versuchen Sie nicht einmal, das Jahr 2000 Problem zu lösen. Sie können es nicht schaffen und die Kosten des Versuchs werden die ganze (Software-) Infrastruktur Ihres Unternehmens einem Risiko aussetzen. Nehmen Sie die Niederlage hin. Werfen Sie Ihre alte Infrastruktur weg und erwerben Sie eine, die Jahr 2000 sicher ist, sogar, wenn Sie nicht perfekt ist." Auch hier ist allerdings zu fragen, warum es plötzlich möglich sein soll, die betriebliche Organisation an gekaufte Programme anzupassen, während man über Jahrzehnte hinweg auf diese Organisation zugeschnittene, individuelle Programme entwickelt hat, weil eben nichts anderes möglich schien. Auch die Einführung eines neuen Programmpakets braucht Zeit für Installation, Einrichtung der Systemverwaltung, Anpassung von programmatischen Schnittstellen, Schulung der Nutzer und Umbau der betrieblichen Organisation. Alle diese Tätigkeiten zur Ablösung der bisherigen Anwendung müssen abgeschlossen sein vor einem Zugriff auf das „Jahr 99" oder das Jahr 2000 durch die alte Anwendung. Es bleibt als nicht die Zeit für einen langen Parallelbetrieb. Es ist auch zu entscheiden, was mit den durch die alte Anwendung bisher erzeugten Daten geschehen soll. Im Zeitalter des „data mining" vermutet man in allen Daten noch „goldene" Informationen. Möglicherweise bestehen auch rechtliche Verpflichtungen, diese Daten noch lesbar zu erhalten. Also sind die Daten zu konvertieren oder zu archivieren. Doch wie sind Daten und ihre Struktur zu archivieren, wo sich doch gerade durch die Jahr 2000 Umstellungen neue Strukturen ergeben? Diese Änderungen sind bei anderen Taktiken nicht so groß wie bei der Ablösung der alten Anwendung, doch für einen programmatischen Zugriff sind auch kleine Änderungen bedeutsam. Wie kann also aus Archiven wieder gelesen werden: mit der alten Anwendung oder mit einem speziellen Archivsystem?

3.4.3

Nichtstun

Sie ändern Ihre häusliche Umgebung nicht und werfen die Mängelberichte weg. Vor dieser Taktik wird überall gewarnt, doch für einzelne Anwendungen oder Anwendungsfunktionen mag diese Taktik durchaus angemessen erscheinen. Wenn es Anwendungen gibt, die keine externen Datumsbezüge und keine interne Datumsverarbeitung haben, so ist das Vorgehen korrekt. Möglicherweise greift eine Anwendung nur wenige Tage in die Zukunft und nur wenige Tage in die Vergan-

3.4

Lösungsalternativen

87

genheit. Mit einer solchen Anwendung hat man keine Probleme, falls die künftigen Betriebsferien passend über den Jahr 2000 Datumswechsel hinweg gelegt werden. Oder man nimmt einige Tage Probleme in Kauf, die man sich um so eher leisten kann, wie die Mitarbeiter informiert und die Datenverarbeitung sich völlig auf Papierbelege stützt. Notfalls fährt man nach einer Woche einen Korrekturlauf.

3.4.4

Abreißen

Sie reißen ein Haus ab. Möglicherweise hat die Analyse bestätigt, was schon immer vermutet wurde: Einige Anwendung oder Anwendungsteile sind in Zukunft unwichtig oder sie werden schon heute nicht mehr genutzt. Diese Anwendungen werden abgeschaltet. Für die Daten der stillgelegten Anwendungen kann man die gleichen Überlegungen anstellen wie bei der Taktik Erneuerung.

3.4.5

Umbauen

Sie bauen einzelne Räume oder Etagen um. Für Umbauten gibt es drei generelle Vorgehensweisen, zwei sind mit Änderungen der Daten und der Programme verbunden, eine betrifft nur die Programmlogik. Also ist auch für den Fall, daß ein Programm im Rahmen der üblichen Pflege umgestellt werden soll, eine Entscheidung zu treffen. Die Umbauten betreffen nur die Abspeicherung der Daten oder die Programmlogik. Die EDV-Nutzer können durchaus weiterhin zweistellige Jahreszahlen eingeben, wenn eine eindeutige Bestimmung der Jahrhundertzahl für die Programme möglich ist. Auch die ISO-Norm gestattet für die Darstellung zweistellige Jahreszahlen. Vierstellige Speicherung Diese Taktik besteht aus zwei Teilen: •

Alle Datenfelder in allen Datensätze erhalten eine vierstellige Jahreszahl.

•

Alle Datenfelder aller Programme erhalten eine vierstellige Jahreszahl.

In der Theorie ist diese Taktik die beste. Sie wird deswegen oft empfohlen. Sie ist sicherlich immer für Neuentwicklungen zu benutzen. In der Praxis kann sie jedoch scheitern. Sie kann scheitern, weil mit ihr ein immenser Aufwand bei Daten und Programmen verbunden sein kann. Immer vorausgesetzt, tatsächlich alle Datenfelder mit einer zweistelligen Jahreszahl seien in der Datenbank gefunden, so sind alle betroffenen Datensätze zu erweitern und die passende Jahrhundertzahl ist einzusetzen. Die Erweiterung kann nur selten im laufenden Betrieb geschehen und die Änderung auf das Jahrhundert erfordert spezielle Programme. Die magischen Zahlen sind zuerst zu bereinigen,

88

3 Die ED V vor dem Jahr 2000 - Chancen

sonst werden womöglich auch die „99" mit spezieller Bedeutung auf „ 1999" und die „00" auf „2000" umgesetzt. Immer vorausgesetzt, tatsächlich alle Datenfelder mit einer zweistelligen Jahreszahl seien in den Programmen gefunden, so sind alle betroffenen Datenfelder und Datengruppen zu erweitern und alle Programme neu zu kompilieren; man benötigt also den korrekten Programmtext. Die mit den magischen Zahlen in den Programmen verbundenen Logik ist zuerst zu bereinigen; eine Abfrage auf „0099" (nach Erweiterung) macht wenig Sinn. In der Tabelle „Eigenschaften von Konvertierungsarten" wird diese Methode in der ersten Spalte kommentiert. Jahreszahlen in einer Datenbank kann man natürlich immer vierstellig abspeichern. Alle Datenfelder eines Programms umzustellen, kann zu viel Aufwand bedeuten. Wenn nicht alle Felder in einem Programm umgestellt werden, ist es um interne Routinen zu ergänzen, die Datenwerte von der einen Feldart auf die andere konvertieren. Durch die Verlängerung eines Feldes verschieben sich die Adressen aller im Programmtext folgenden Datenfelder. Wenn im Programm mit Pointern gearbeitet wird, so kann das unabsehbare Folgen nach sich ziehen. Also wird man lieber mit der alten Länge für die Jahreszahl weitermachen und eine andere Vorgehensweise wählen. Die Datentypen der Felder, die Jahreszahlen enthalten, sind anzupassen, weil die Länge sich von zwei auf vier ändert. Die Datenwerte sind anzupassen, weil die neuen zwei Stellen, den passenden Jahrhundertwert erhalten müssen. Die Verlängerung der Datenfelder verlängert die Satzlänge und vergrößert damit manchmal die Datei. Oft enthält eine Datei sowieso Reserveplatz für neue Sätze. Die eigentlichen Platzverschwender in einer Datei sind übrigens ungünstig codierte Textfelder von mehr als 20 Byte Länge. Alle Programme sind zu ändern. Weil die Datenwerte nach der Umstellung korrekt sind, sind Sortierungen problemlos möglich. Der CPU-Verbrauch bleibt etwa gleich. Einige extra Bytes im Arbeitsspeicher zu bewegen belastet die CPU nicht. Der eigentliche CPU-Zeit Verschwender fiir diese Funktion der Textverschiebung sind übrigens ungünstig abgespeicherte Datenfelder, die gemeinsam von Programmen benutzt werden. Die Programme sind nach der Änderung gleich gut oder gleich schlecht zu pflegen, eben wie bisher. Umgestellte Programme verschiedener Anwendungen sind nur dann problemlos zu kombinieren, wenn sie ebenfalls vierstellige Jahreszahlen nutzen.

3.4

Lösungsalternativen

89

Der Lösungshorizont beschreibt, bis zu welchem Jahr die umgestellte Anwendung genutzt werden kann. Im Falle der vierstelligen Jahreszahl ist es klar, daß erst das Jahr 10 000 nicht überstanden wird. Gepackte Speicherung Diese Taktik besteht wieder aus zwei Teilen: •

Alle Datenfelder in allen Datensätze erhalten eine Jahreszahl, die korrekt ist, aber mit zwei Byte Speicherplatz auskommt.

•

Alle Datenfelder aller Programme erhalten eine dem entsprechende Jahreszahl.

In der Theorie ist diese Taktik nicht die beste. Sie wird deswegen selten empfohlen. In der Praxis kann sie jedoch nützlich sein. Immer vorausgesetzt tatsächlich alle Datenfelder mit einer zweistelligen Jahreszahl seien in der Datenbank gefunden, so sind alle betroffenen Datensätze umzustellen und die passende Jahrhundertzahl ist einzubauen. Die Erweiterung kann eventuell im laufenden Betrieb geschehen, erfordert aber spezielle Programme. Die magischen Zahlen sind zuerst zu bereinigen, sonst werden womöglich auch die „99" mit spezieller Bedeutung auf „1999" und die „00" auf „2000", jeweils in gepackter Speicherung, umgesetzt. Immer vorausgesetzt tatsächlich alle Datenfelder mit einer zweistelligen Jahreszahl seien in den Programmen gefunden, so sind alle betroffenen Datenfelder und Datengruppen umzustellen und alle Programme neu zu kompilieren; man benötigt also den korrekten Programmtext. Die mit den magischen Zahlen in den Programmen verbundenen Logik ist zuerst zu bereinigen; eine Abfrage auf „0099" in gepackter Speicherung macht wenig Sinn. In der Tabelle „Eigenschaften von Konvertierungsarten" wird diese Methode in der zweiten Spalte kommentiert. Jahreszahlen in einer Datenbank kann man natürlich immer gepackt abspeichern. Die Packung kann in einer Codierung auf irgend ein binäres Format in der Länge von 16 Bit = 2 Byte geschehen oder man nutzt ab sofort oder ab dem Jahr 2000 ein Zahlensystem zu einer Basis größer als 10. Zum Beispiel sieht die Jahreszählung im 16er System, die ab dem Jahr 2000 (Fettschrift) aktiv wird, so aus: 97, 98, 99, 9A,..., 9F usw. Statt eines Maximums von „99" wird „FF" oder „ZZ" gesetzt. Die "19" bleibt der gültige Standardwert für die Anzahl der "Jahrhunderte". Bei der Ausgabe mit vier Stellen wird bis „99" die Zahl 1900 addiert, danach werden die zweistelligen Jahreszahlen vom 16er ins 10er System umgewandelt und es wird 1846 addiert.

90

3 Die ED V vor dem Jahr 2000 - Chancen

Alle Datenfelder eines Programms umzustellen, kann zu viel Aufwand bedeuten und mindestens die Datenwerte, die auf Bildschirm oder Liste dargestellt werden sollen, benötigen einen anderen Feldtyp. Da oft nicht alle Felder in einem Programm umgestellt werden können, ist es um interne Routinen zu ergänzen, die Datenwerte von der einen Feldart auf die andere konvertieren. Diese Methode hat keine Probleme mit Pointern. Die Datentypen der Felder, die Jahreszahlen enthalten, sind anzupassen, weil sich die Art der Codierung ändert. Die Datenwerte sind nur anzupassen, wenn sie schon heute Werte enthalten, die neu codiert werden müssen. Oft sind also keine Werte zu ändern. In beiden Fällen bleibt der Speicherbedarf gleich. Alle Programme sind zu ändern. Weil die Datenwerte nach der Umstellung korrekt sind, sind Sortierungen problemlos möglich. Der CPU-Verbrauch erhöht sich geringfügig durch Codierung und Decodierung. Die Programme sind nach der Änderung möglicherweise etwas schlecht zu pflegen, da die internen Konvertierungsroutinen Verwirrung stiften können. Programme verschiedener Anwendungen, die mit dieser Methode umgestellt wurden, sind nur dann problemlos zu kombinieren, wenn sie die gleiche Codierung nutzen. Je nach Art der Packung ist diese Lösung für die nächsten hundert Jahre oder auch mehr gut. Nun folgt ein kleiner Exkurs zu Brückenprogrammen, der sich an der folgenden Abbildung orientiert.

Client-

Server-

Programm

Programm

Nutzer-

Datenbank

Oberfläche

B

B

ProzessKommunikation

Client-

Server-

Betriebssystem

Betriebssystem

Abbildung 5: Brückenprogramme

3.4 Lösungsalternativen

91

Brückenprogramme sind immer dann einzusetzen, wenn ein Programm oder einen Teil eines Programms Daten erreichen können, die nicht dem programminternen Datenformat entsprechen. Im Rahmen der Bearbeitung des Jahr 2000 Problems sind das Jahreszahlen in unpassender Länge oder in unpassender Codierung. Die Grafik zeigt die Verhältnisse für die Kommunikation in einem einfachen Client-Server-Modell. Wenn es keine Programmkommunikation gibt, fallen ClientProgramm und Server-Programm sowie Client-Betriebssystem und ServerBetriebssystem in ein Programm und ein Betriebssystem zusammen. Nicht zum Programm passende Daten können an der Nutzeroberfläche eingegeben oder müssen dort ausgegeben werden. Sie können auch aus einer Datenbank oder dem Betriebssystem stammen. Auch die Prozeßkommunikation kann bedeuten, daß sich zwei Prozesse auf gleicher oder auf verschiedener Plattform mit unterschiedlichen Datenformaten verständigen müssen. Im Rahmen eines Jahr 2000 Projektes lassen sich nicht alle Programme und Datenbanken gleichzeitig umstellen und die jeweiligen Nutzer werden auf ihrem Datumsformat bestehen. Also sind Brückenprogramme (großes „B" in der Abbildung 5) schon wegen unterschiedlicher Länge der Jahreszahl nötig und unverzichtbar. Wenn z.B. in COBOL zweistellige Jahreswerte auf vierstellige alphanumerische Felder ohne Brückenprogramm kopiert werden, steht die Jahreszahl im Bereich der Jahrhundertzahl oder umgekehrt bei vierstellig auf zweistellig alphanumerisch kommt die Jahrhundertzahl im Bereich der Jahreszahl zu stehen. Ein Gruppe von Feldern gleich welchen Datentyps, also z.B. ein Datum, wird in COBOL bei einem Kopiervorgang immer als ein alphanumerisches Feld behandelt. Die Zahl solcher Brückenprogramme läßt sich minimieren, wenn Programmsysteme gleicher Länge oder gleicher Codierung der Jahreszahl zusammen gefaßt werden können (K04). Spezielle Programmlogik Hier wird die Brückenprogrammierung zur Taktik. Das Programm wird dank interner Interpretationslogik so schlau gemacht, daß es die Bedeutung zweistelliger Jahreszahlen im bisherigen Format erschließen kann. Also sind keine externen Brücken zu alten Formaten nötig. Und die Datenwerte in den Datenbanken können so bleiben wie sie sind. Es sind aber wieder alle Datenfelder aller Programme auf vier Stellen zu erweitern oder es ist eine passende Codierung zu finden, jeweils mit den weiter oben schon beschriebenen Problemen. Daher werden wohl auch hier die schon beschriebenen internen Konvertierungsroutinen zum Einsatz kommen. In der Theorie ist diese Taktik nicht das Optimum. Doch in der Praxis ist sie optimal, was die Behandlung der Datenwerte angeht. Daher wird sie oft empfohlen.

92

3 Die ED V vor dem Jahr 2000 -

Chancen

Die Interpretation der Jahreszahlen kann in zwei Varianten geschehen: statische Zeitfenster oder dynamische Zeitfenster. Bei der statischen Variante wird eine Jahreszahl jj festgelegt und als 19jj interpretiert. Alle Jahreszahlen nn, für die gilt nn > jj, werden als 19 nn interpretiert. Alle Jahreszahlen nn, für die gilt nn < jj, werden als 20 nn interpretiert. Bei der dynamischen Variante wird die vierstellige Jahreszahl von einer korrekten Uhr im Betriebssystem übernommen. Von dieser Jahreszahl wird ein Wert a subtrahiert, man findet ein Jahr w j j in der Vergangenheit, und es wird eine Wert b addiert, man findet ein Jahr zzyy in der Zukunft. Die Werte a und b ergeben zusammen einhundert. Alle Jahreszahlen nn, für die gilt nn > jj, werden als vv nn interpretiert. Alle Jahreszahlen nn, für die gilt nn < yy, werden als zz nn interpretiert. Tabelle 9: Eigenschaften von Konvertierungsarten

(nach K02)

Vierstellige Speicherung

Gepackte Speicherung

Spezielle Programmlogik

Zeitreise

Anwendbarkeit auf Daten

immer

immer

1901 bis 2099

Anwendbarkeit auf Programme Anpassung der Datentypen Anpassung der Datenwerte Speichervolumen Brückenprogramme zu nicht umgestellten Anwendungen programminterne Konvertierung Anpassung der Programme Anpassung der Sortierungen CPU-Zeit Verbrauch (ohne Brückenprogramme) Wartbarkeit der Programme Kombinierbarkeit umgestellter Anwendungen Lösungshorizont

zu prüfen

zu prüfen

Jahreszahlen aus Intervall kleiner als hundert Jahre immer

zu prüfen

ja

ja

nein

nein

ja

nein

nein

etwas mehr

je nach Datenwerten gleich

gleich

ja

ja

gleich nein

ja

zu prüfen

ja

zu prüfen

nein

ja

ja

ja

nein

nein

nein

ja

nein

etwa gleich

etwas mehr

etwas mehr

gleich

wie bisher

etwas schlechter

etwas schlechter

wie bisher

Prüfung auf gleiche Methode

Prüfung auf gleiche Pakkungsart mittelfristig

Prüfung auf gleiche Logik

Prüfung auf gleiche Zeitreduzierung maximal bis 2083

bis 9999

kurzfristig oder bis ultimo

3.4

Lösungsaltemativen

93

Die Methode ist also nur für Jahreszahlen aus einem Zeitraum von maximal einhundert Jahren anwendbar. Der tatsächliche genutzte Zeitraum sollte kleiner sein, da man die Werte aus der Datenbank entfernen muß, bevor sie falsch interpretiert werden. Der Vorteil der dynamischen Variante liegt in ihrem unbegrenzten Zeithorizont und darin, daß man die Jahre a in der Vergangenheit und die Jahre b in der Zukunft passend für eine Anwendung wählen kann, ohne, wie in der statischen Methode, verschiedene Bezugsjahre einzuführen. Da die Datenwerte nicht umgestellt werden, müssen Sortierprogramme mit einer der gewählten Methode entsprechenden Logik ausgestattet werden. Auch die Primär* und Sekundärschlüssel einer Datei sind sortiert. Programme, die sich auf die dort gegebene Sortierung verlassen, müssen umprogrammiert werden. Auch das Lesen der Datensätze ab einer Schlüsselposition, die auf einem Vergleich von Datenwerten beruht, muß neu programmiert werden. Der CPU-Verbrauch erhöht sich geringfügig durch Ausführung der oben definierten Logik. Die Programme sind nach der Änderung möglicherweise etwas schlechter zu pflegen, da die internen Konvertierungsroutinen und die besondere Interpretationslogik Verwirrung stiften können. Programme verschiedener Anwendungen, die mit dieser Methode umgestellt wurden, sind nur dann problemlos zu kombinieren, wenn sie exakt die gleiche Variante benutzen. In einem Programm zur Realisierung einer Anwendungsfunktion sollte nur mit einer bestimmten Variante gearbeitet werden.

3.4.6

Anbauen

Sie bauen einen Erker an. Es gibt Zusatzprogramme, die wie Brückenprogramme wirken, und fehlerhafte Hardware, Firmware und Betriebssystemfunktionen vor den Anwenderprogrammen verbergen. Die gleiche programmatische Hilfe ist nicht nur für PCs sondern auch für zahlreiche andere Systeme und Geräte möglich.

3.4.7

Zeitreise

Sie schauen sich alte Fotos aus der Zeit an, in der das Haus noch schön war. Mehr ist in der Wirklichkeit nicht möglich, doch ein Programm hat seine „virtuelle" Welt. Alle Methoden des Umbaus verlangen, daß Tausende von Programmen an Hunderten von Stellen geändert werden. Alle diese Stellen zu finden, ist nahezu unmöglich. Alle gefundenen Stellen automatisch umzustellen ist unmöglich. Also ist nach einer Methode zu suchen, die Programmänderungen vermeidet.

94

3 Die ED V vor dem Jahr 2000 - Chancen

Auch hier wird die Brückenprogrammierung zur Taktik. Das Programm wird dank externer Brückenprogramme so dumm gehalten, daß es die Bedeutung zweistelligen Jahreszahlen im bisherigen Format nicht zu erschließen braucht. Es sind keine weiteren externen Brücken nötig. Die Brückenprogramme wirken zusammen wie Anbauten, die hier das tatsächliche Kalenderjahr vor den Anwendungsprogrammen verbergen. Die Zahl solcher Brückenprogramme kann minimiert werden, wenn Programmsysteme gemeinsam im Unklaren über die tatsächliche Jahreszahl gelassen werden können. Und die Datenwerte in den Datenbanken können so bleiben wie sie sind. Und das Anwendungsprogramm kann so bleiben wie es ist. In der Theorie ist diese Taktik sicher nicht optimal. In der Praxis kann sie das durchaus sein; denn weder Programme noch Datenwerte sind zu ändern. Sie wird bisher nur vereinzelt empfohlen. Der Trick besteht darin, über externe Brückenprogramme alle Jahreszahlen, die ein Programm erreichen können, in dem vom Programm erwarteten Format zu belassen, aber ihren Wert um 28 Jahre oder ein Vielfaches davon zu vermindern. Damit weicht man dem Jahr 2000 mindestens für die nächsten 28 Jahre aus. Denn der Jahreskalender mit der Abfolge von Wochen und Wochentagen bleibt der Gleiche, wenn man 28 Jahre zurückgeht; denn es gibt 7 Wochentage und alle 4 Jahre ist ein Schaltjahr, wenigstens im Zeitraum von 1901 bis 2099. Man muß nur darauf achten, daß die verminderten Jahreszahlen nicht vor 1901 liegen. Man kann auch froh sein, daß die EDV nicht schon vor 1900 entwickelt wurde, dann hätte man diese Methode nicht anwenden können; 1900 ist bekanntlich kein Schaltjahr. Diese Methode ist besser, als auf einen nicht christlichen Kalender auszuweichen. Alle anderen Kalender haben bis 2099 einen Jahrhundertwechsel. Diese Methode lehnt sich in der Idee an Betriebskalender an, die schon heute für ein Unternehmen einen privaten Kalender vorsehen. Natürlich müssen hier die beweglichen Feiertage vor 28 Jahren über einem zusätzlichen Betriebskalender durch die heutigen ersetzt werden. Man kann auch 2 mal 28 Jahre in der Zeit zurück gehen. Dann würde das allgemeine Jahr 2000 auf das private Jahr 1944 fallen - in etwa das Geburtsjahr der EDV. Möglicherweise setzen sich in den nächsten Jahren die Puristen durch und alle Anwendungen haben dann eine vierstellige Jahreszahl zu nutzen. Ein Problem mit einer Zeitrückstellung um 56 Jahre gibt es erst nach deutlich 30 Jahren; danach wird nicht mehr aus Verschulden gehaftet. Man kann auch 3 mal 28 Jahre, aber nicht mehr, zurück gehen. Doch eine solche Wahl könnte als Ausdruck vollständiger Resignation vor dem Jahr 2000 Problem interpretiert werden.

3.4

Lösungsalternativen

95

Die Brückenprogramme für diese Taktik können nur realisiert werden, wenn in das Betriebssystem eingegriffen werden kann oder Funktionen des Betriebssystems überlagert werden können. Dazu bedarf es der technischen Möglichkeit, der ausreichenden Dokumentation und der entsprechend versierten Systemprogrammierer, allerdings nur in geringer Zahl. Da die Datenwerte nicht umgestellt werden, müssen Sortierprogramme in entsprechender Weise mit Brückenprogrammen versehen werden. Die Brückenprogramme müssen auch durch entsprechend wiederholte Positionierung auf den Schlüsseln einer Datei die korrekte Folge von Werten liefern können. Die Entwicklung von Brückenprogrammen ist erstens interessanter und zweitens weniger komplex als Änderungen in Anwendungsprogrammen. Auch diese Gründe verbessern die Erfolgsaussichten eines solchen Vorgehens. Die Brückenprogramme können recht allgemein gehalten werden und sind für viele Programme gleichartig. Eventuell können auch mehrere Installationen eines EDVHerstellers von den gleichen Brückenprogrammen profitieren. Es gibt auch schon Werkzeuge für den Test von umgestellten Programmtexten. Diese gaukeln dem laufenden Programm schon heute das Jahr 2000 vor; warum sollte das gleiche Werkzeug, als Laufzeitsystem gehandhabt, nicht auch das Jahr 1970 (=1998 - 28) simulieren können. Diese Taktik wird man immer dann anwenden, wenn zu wichtigen Programmobjekten kein oder kein passender Text gefunden werden kann. Sie ist sicher von Vorteil, wenn die Programmtexte umfangreich und komplex sind, aber das Programmsystem nur wenig Schnittstellen zur Außenwelt hat.

3.4.8

Was folgt daraus?

=> Für verschiedene Anwendungen mit einem Jahr 2000 Problem sind verschiedene Lösungen möglich; doch niemand nimmt Ihnen die Qual der Wahl ab. => So ist die beste Strategie, möglichst viel über Ihre Anwendungen und EDVSysteme in Erfahrung zu bringen, alle Lösungsalternativen zu kennen und jeweils für eine Anwendung oder einen Teil einer Anwendung im Jahr 2000 Projektteam nach einem Optimum zu suchen.

96

3 Die ED V vor dem Jahr 2000 - Chancen

3.5

Testverfahren

•

Die Testumgebung

•

Die Jahr 2000 Testvarianten

•

Die Prüfung der Jahr 2000 Fähigkeit

•

Die Effizienz der Tests

•

Was folgt daraus?

Tests sind erforderlich, um Anwendungsprogramme mit Jahr 2000 Problemen zu entdecken. Tests sind auch erforderlich, um umgestellte Anwendungen zu prüfen, ob sie die Jahr 2000 Fähigkeit und Fertigkeit besitzen und ob alle bisherigen Funktionen auch nach allen Änderungen noch korrekt ablaufen. Tests sind ebenfalls erforderlich, um die von EDV-Herstellern versprochene Jahr 2000 Fähigkeit tatsächlich nachzuweisen.

3.5 Testverfahren

97

3 Die ED V vor dem Jahr 2000 - Chancen

98 3.5.1

Die Testumgebung

Die Abbildung zeigt schematisch die Testumgebung, die jeder Anwender faktisch heute schon hat.

Abbildung 6: Testumgebung

Ein Programm wird getestet vom Programmierer, der es geschrieben hat, von einer speziellen Testgruppe oder vom Anwender, der ein Programm nutzen soll. Ein Programm reagiert auf Eingaben eines Nutzers oder auf Eingaben aus einer Datei, es greift möglicherweise auf Daten in einer wie immer gearteten Datenbank zu und es produziert Ausgaben, die aus einer Bildschirmanzeige, einer Meldung oder auch einer Liste bestehen können. Wenn das Programm online oder im BatchBetrieb Transaktionen bearbeitet, so ändert es auch Daten in einer Datenbank. Die Ein- und Ausgaben werden Testfälle, die Daten und ihre möglicherweise erfolgten Änderungen werden Testdaten genannt. Ein Programm läuft für eine bestimmte Zeit oder sein Lauf wird für eine bestimmte Zeit beobachtet und es verarbeitet in diesem Testlauf einen oder mehrere Testfälle. Die Testfälle werden oft immer neu eingegeben, besser ist es aber, wenn sie aus realistischen Eingaben mitgeschrieben werden und in einer Datei zu wiederholten Testläufen zur Verfugung stehen. Die Testdaten sollten einen kleinen, aber in sich

3.5

Testverfahren

99

und zu den Eingaben konsistenten Auszug aus den Daten des Echtbetriebes darstellen. Damit für wiederholte Testläufe auch sie immer gleich zur Verfugung stehen, werden sie gesichert und für jeden erneuten Testlauf neu aufgebaut. Die Entscheidung, ob ein Test erfolgreich war oder ein Fehlschlag, wird über den Vergleich der Daten nach dem Test mit den Soll-Datenwerten und durch den Vergleich der Ausgaben mit den Soll-Ausgaben festgestellt. Dieser Vergleich erfolgt oft manuell, er sollte aber im Interesse der Geschwindigkeit und der Genauigkeit durch ein spezielles Programm durchgeführt werden. Falls beim Vergleich der vom Testlauf erzeugten Daten oder Ausgaben mit den Sollwerten Unterschiede festgestellt werden, so ist der Test fehlgeschlagen und das Programm enthält einen oder mehrere Fehler. Wenn die Fehler nicht aus der Flüchtigkeit des Programmierers herrühren, so verweisen sie möglicherweise auf einen allgemeinen Irrtum im Design, von dem durchaus mehrere Programme betroffen sein können. Falls noch keine automatisierte Testumgebung zur Verfügung steht, sollte sie frühzeitig für die effiziente Abwicklung von Tests in einem Jahr 2000 Projekt geschaffen werden. Dazu ist es nötig Programme zu schreiben, die Testdaten aufbereiten, Vergleiche durchfuhren und die Abläufe in der Testumgebung organisieren. Das automatisches Mitschreiben von Anwendereingaben oder Eingabedateien oder sonstiger Eingaben, die das zu testende Programm erreichen, liefert Testfälle. Dann ist die Testumgebung selbst mit Anwendungsprogrammen zu testen, die sich schon jahrelang durch wenig Fehler ausgezeichnet haben. Ein Testlauf mit fehlerfreien Anwendungsprogrammen ergibt auch Sollwerte für weitere Tests.

3.5.2

Die Jahr 2000 Testvarianten

Bei systematischem Vorgehen lassen sich insgesamt acht Varianten unterscheiden, die sich aus der Kombination der folgenden Fälle ergeben: •

altes, ungeändertes Programm vs. neues, geändertes Programm,

•

Testfälle aus der Gegenwart vs. Testfälle aus der Zukunft,

•

aktuelle Zeit vs. simulierte Zeit.

Das Ziel besteht darin, die Testvarianten so zu gestalten, daß sich die Jahr 2000 Fertigkeit eines Programms nachweisen oder zumindest sehr wahrscheinlich machen läßt. Welche Ergebnisse jeweils zu erwarten sind und welche Tests durchgeführt werden sollten, wird im Folgenden dargestellt.

100

3 Die ED V vor dem Jahr 2000 -

Chancen

Abbildung 7: Jahr 2000 Test- Variante 1: aktuelle Zeit - Testfälle aus der Gegenwart - altes Programm

Variante 1 (Abbildung 7): Zuerst wird das ungeänderte Programm in seiner normalen Testumgebung mit speziellen Testfällen versorgt. Die speziellen Testfälle ergeben sich aus der Variation von Datumswerten in den auch sonst üblichen Testfallen. Daher sind auch entsprechende datumsbezogene Sollwerte zu erzeugen. Die Datumswerte werden nur insoweit variiert, daß sie auf die nahe Gegenwart und die nahe Zukunft Bezug nehmen. Es werden auch ungültige Datumswert eingegeben, die vom Programm mit einer entsprechenden Meldung abgewiesen werden sollten. Man wird erwarten, daß alle alten Programme in dieser Umgebung die Tests bestehen, wenn nicht alte Fehler in Funktionen oder Datumsberechnungen durch die hier vorgeschlagenen systematischen Tests entdeckt werden. Variante 2 (Abbildung 8): Dann wird das ungeänderte Programm in seiner normalen Testumgebung mit speziellen Testfallen versorgt. Die speziellen Testfälle ergeben sich aus der Variation von Datumswerten in den auch sonst üblichen Testfällen. Die Datumswerte werden jetzt so variiert, daß sie auf die Zukunft kurz vor und kurz nach dem Jahr 2000 Bezug nehmen. Daher sind auch entsprechende datumsbezogene Sollwerte zu erzeugen. Man wird erwarten, daß viele alte Programme in dieser Umgebung die Tests nicht bestehen, möglicherweise nicht einmal den Testlauf.

3.5

Testverfahren

101

Abbildung 8: Jahr 2000 Test-Variante 2: aktuelle Zeit - Testfälle aus der Zukunft - altes Programm

Abbildung 9: Jahr 2000 Test-Variante 3: simulierte Zeit - Testfälle aus der Zukunft - altes Programm

102

3 Die ED V vor dem Jahr 2000 -

Chancen

Testfälle

Abbildung 10: Jahr 2000 Test- Variante 4: simulierte Zeit - Testfälle aus der Gegenwart - altes Programm

Variante 3 (Abbildung 9): Dann wird das ungeänderte Programm mit den gleichen Testfällen wie im vorigen Fall versorgt, allerdings läuft das Programm jetzt in einer speziellen Systemumgebung, die ihm verschiedene Systemzeiten kurz vor und kurz nach dem Jahr 2000 simuliert. Die Testdaten sind dafür vorher so umzusetzen, daß die in ihnen enthaltenen Datumswerte in sich konsistent sind und zu der simulierten Zeit passen. Man wird wieder erwarten, daß viele alte Programme in dieser Umgebung die Tests nicht bestehen. Variante 4 (Abbildung 10): Dann wird das ungeänderte Programm mit den gleichen Testfallen wie im ersten Fall versorgt, allerdings läuft das Programm jetzt in einer speziellen Systemumgebung, die ihm verschiedene Systemzeiten kurz vor und kurz nach dem Jahr 2000 simuliert. Auch die Testdaten sind die gleichen wie im ersten Fall. Man kann hier feststellen, ob ein ungeändertes Programm künftig in der Lage sein wird, archivierte Daten auszulesen und zu bearbeiten. Man wird erwarten, daß die meisten alten Programme in dieser Umgebung die Tests bestehen. Variante 5 (Abbildung 11): Nun folgen die Testvarianten für das geänderte Programm. Zuerst wird das geänderte Programm in der normalen Testumgebung mit datumsbezogenen Testfällen aus der Gegenwart versorgt. Die speziellen Testfälle sind die gleichen wie beim alten Programm in dieser Umgebung, falls das neue Programm nicht vierstellige oder gepackte Jahreswerte erwartet. Die Testdaten sind

3.5

Testverfahren

103

Abbildung 11: Jahr 2000 Test-Variante 5: aktuelle Zeit - Testfälle aus der Gegenwart - neues Programm

bei geänderter Abspeicherung der Jahreszahlen entsprechend umzustellen. Man wird erwarten, daß die neuen Programme diesen Regressionstest bestehen, falls nicht einige Änderungen neue Fehler in die Programme eingebracht oder spezielle, bisher schlummernde Logik aktiviert haben. Variante 6 (Abbildung 12): Dann wird das geänderte Programm in der normalen Testumgebung mit zukünftigen Testfällen wie vorher das alte Programm versorgt. Die Testdaten sind die gleichen wie im letzten Fall. Die Sollwerte sind an die zukünftigen Eingaben anzupassen. Man wird erwarten, daß die meisten neuen Programme in dieser Umgebung die Tests bestehen, eben deswegen wurden sie ja geändert. Variante 7 (Abbildungl3): Dann wird das geänderte Programm mit den gleichen Testfällen wie im vorigen Fall versorgt, allerdings läuft das Programm jetzt in einer speziellen Systemumgebung, die ihm verschiedene Systemzeiten kurz vor und kurz nach dem Jahr 2000 simuliert. Die Testdaten sind dafür vorher so umzusetzen, daß die in ihnen enthaltenen Datumswerte in sich konsistent sind und zu der simulierten Zeit passen. Man wird wieder erwarten, daß die meisten neue Programme in dieser Umgebung die Tests bestehen.

104

3 Die ED V vor dem Jahr 2000 - Chancen

Abbildung 12: Jahr 2000 Test- Variante 6: aktuelle Zeit - Testfälle aus der Zukunft - neues Programm

Abbildung 13: Jahr 2000 Test- Variante 7: simulierte Zeit - Testfälle aus der Zukunft - neues Programm

3.5

Testverfahren

105

Abbildung 14: Jahr 2000 Test-Variante 8: simulierte Zeit - Testfälle aus der Gegenwart - neues Programm

Variante 8 (Abbildung 14): Dann wird das geänderte Programm mit den gleichen Testfallen wie im ersten Fall versorgt, allerdings läuft das Programm jetzt in einer speziellen Systemumgebung, die ihm verschiedene Systemzeiten kurz vor und kurz nach dem Jahr 2000 simuliert. Auch die Testdaten sind die gleichen wie im ersten Fall. Man kann hier feststellen, ob ein geändertes Programm künftig in der Lage sein wird, archivierte, aber möglicherweise umgestellte Daten auszulesen und zu bearbeiten. Man wird erwarten, daß die meisten neuen Programme in dieser Umgebung die Tests bestehen.

106

3 Die ED V vor dem Jahr 2000 - Chancen

3.5.3

Die Prüfung der Jahr 2000 Fähigkeit

Wurden bisher nur einzelne Programme auf ihre Jahr 2000 Fertigkeit getestet, so verlangt die Jahr 2000 Fähigkeit den Test des Zusammenspiels mehrerer Anwendungsprogramme oder von Anwendungsprogrammen mit dem EDV-System als Ganzem. Durch eine entsprechende Umgestaltung der Testfälle und der Soll-Testdaten lassen sich auch umgestellte Programmsysteme oder Programme zusammen mit ihren Brückenprogrammen anstatt nur eines Programms in einer definierten Testumgebung überprüfen. Falls eine Anwendung in Client-Server-Technik realisiert ist, wird man erst Client und Server getrennt und dann in ihrem Zusammenspiel testen. Um ein EDV-System in seinen Teilen Hardware, Firmware, Betriebssystem und Middleware zu testen, muß die Systemuhr auf die Zeit kurz vor und kurz nach dem Jahr 2000 verstellt werden. Daher ist eine separater Rechner erforderlich, denn weder im Entwicklungs- noch im Produktionsrechner kann man es sich erlauben, durch Verstellen der Systemuhr den normalen Betrieb zu gefährden. Diesen speziellen Testrechner wird man mit all den Produkten ausstatten, für die der Hersteller die Jahr 2000 Fähigkeit erklärt hat. •

Ein erster Test besteht dann darin, mit umgestellter Systemzeit und entsprechend umgestellter Konfiguration die Betriebsbereitschaft darzustellen.

•

Ein zweiter Test ist die Nutzung betriebssystemnaher Werkzeuge.

•

Als dritten Test wird man die oben definierte Umgebung „Jahr 2000 Test: simulierte Zeit - Testfälle aus der Zukunft - neues Programm" ohne Simulation installieren und ausprobieren.

•

Danach können dann Tests für weitere Programme und Programmsysteme gefahren werden.

•

Daran wird sich dann ein Integrationstest anschließen, der die tatsächliche Abfolge von Online-Verarbeitung und Batch-Abläufen vor, nach und während den Online-Zeiten genau nachstellt.

Bei der simulierten Zeit und auch bei der verstellten Systemzeit wird natürlich immer vorausgesetzt, daß man sich mit dem Hersteller der zu testenden Programme auf eine entsprechende Nutzungsberechtigung für den Testzeitraum geeinigt hat.

3.5

Testverfahren

3.5.4

107

Die Effizienz der Tests

Die Testphase wird in jedem Jahr 2000 Projekt einen großen Aufwand verursachen. Daher ist in dieser Phase die Automatisierung besonders lohnend. Insofern verstehen sich die vorstehenden Ausführungen auch als Ideen zur Konfiguration entsprechender Testwerkzeuge. Die Testphase wird oft als letzte Phase eines Jahr 2000 Projektes geplant. Besser ist es zum einen parallel durchzuführende Umstellungsarbeiten vorzusehen, die jeweils mit einer Testphase abschließen, und zum anderen die Versorgung der Testumgebung mit Testfällen und Testdaten sehr viel früher anzugehen. Werkzeuge mögen zwar Hinweise geben können auf die Konstruktion eines Testfalls, die sich aus einer Änderung an einer bestimmten Stelle im Programm ergibt. Werkzeuge erzeugen aber keine kompletten Testfälle und können schon gar nicht Sollwerte bereitstellen gegen die Ausgaben eines Programms und von diesem Programm geänderte Daten zu prüfen sind. Hier bleibt viel manuelle Arbeit zu tun, die aber auch mit Unterstützung der Fachabteilungen erledigt werden kann. Also schließt sich die Überlegung an, wie die Anzahl der Testfälle reduziert werden kann. Ebenso wie bei den Umstellungen insgesamt wird man sich auch beim Testen vorrangig auf die unternehmenskritischen Anwendungen konzentrieren. Dabei gilt es dann nicht alle Funktionen zu testen sondern nur diejenigen, die eine Verarbeitung von Datumswerten mit sich bringen. Und dann kann man sich noch einmal weitgehend auf die Funktionen beschränken, die von den tatsächlichen Nutzern im wirklichen Betrieb am häufigsten ausgeführt werden. Programme, die über die Methode der Zeitfenster umgestellt werden, enthalten häufig deutlich weniger geänderte Stellen als Programme, die über die Methoden der vierstelligen oder der gepackten Jahreszahl umgestellt werden. Daher sind dann auch für Programme mit Zeitfenster weniger Testfälle bereit zu stellen. Da sich Sammlungen von Testfällen oder auch Testdaten direkt oder mit wenig Änderungen für die verschiedenen Tests und die verschiedenen Testvarianten wieder verwenden lassen, sollten alle benutzten Testumgebungen mit allen ihren Komponenten einer Versionsverwaltung unterstellt werden. Damit ist es dann auch einfach möglich, zu Demonstrationszwecken gegenüber inneren oder auch äußeren Kontrollinstanzen die Jahr 2000 Fertigkeit oder Fähigkeit durch wiederholte Testläufe nachzuweisen. Eine Versionsverwaltung kann auch dazu beitragen, eine zur Jahr 2000 Umstellung parallel laufenden Programmpflege in eine neue Programmversion zu integrieren bzw. sie kann helfen, daß über künftige Programmänderungen die Jahr 2000 Fertigkeiten nicht wieder verloren gehen. Neben der Effizienz der Tests sollte auch daran gedacht werden, die Effizienz der umgestellten Programme und der evtl. nötigen Brückenprogramme zu testen. Per-

108

3 Die ED V vor dem Jahr 2000-

Chancen

formanzverluste können bei den Umstellungsmethoden gepackte Speicherung und Zeitfenster und in den internen und externen Brückenprogrammen auftreten. Was hilft es den Anwendern, wenn die umgestellten Programme zwar korrekt funktionieren, aber auf die Programmergebnisse zu lange gewartet werden muß. Bei zu hohem CPU-Verbrauch kann ein Rechner mit höherer Leistung beschafft werden oder die Konvertierungs- und Brückenprogramme müssen effizienter programmiert werden.

3.5.5

Was folgt daraus?

=> Die Jahr 2000 Fähigkeit kann im Einzelnen für Anwendungsprogramme getestet werden. Die Einrichtung einer Testumgebung und die Beschaffung von Testwerkzeugen ist eine Investition, die langfristig die Effizienz und die Qualität der Softwarepflege erhöht. => Die Jahr 2000 Fähigkeit für ganze EDV-Systeme kann nur in Zusammenarbeit mit dem jeweiligen EDV-Hersteller auf einer separaten Maschine getestet werden. Auch die Beschaffung eines solchen Rechners ist wiederum eine Investition, die langfristig die Effizienz und die Qualität des Systembetriebes erhöht

3.6

Lösungsanbieter

•

Die Auswahl eines Lösungsanbieters

•

Die Lösungsanbieter in Projekten

•

Die Werkzeuge der Lösungsanbieter

•

Die Lösungsanbieter im Markt

•

Was folgt daraus?

Die große Chance, mit dem Jahr 2000 Problem zurecht zu kommen, kann natürlich auch darin liegen, ein Jahr 2000 Projekt ganz oder in Teilen durchfuhren zu lassen und es so erfolgreich abzuschließen. Dann müssen sich ein oder mehrere Lösungsanbieter im Auftrag eines EDV-Anwenders mit Projektmanagement, Analyse und Bestandsaufnahme, Auswahl von Lösungen oder Tests beschäftigen. Welches sind die Besonderheiten dieser Vorgehensweise?

3.6

Lösungsanbieter

109

Einrichtung des Jahr 2000 Projektrahmens

Einrichtung eines Jahr 2000 Projektes

Analyse der EDVAnwendungen

System Management

110

3.6.1

3 Die ED V vor dem Jahr 2000 - Chancen

Die Auswahl eines Lösungsanbieters

In einer Marktuntersuchung (106) im Mai 1997 konnten in Deutschland immerhin mehr als 250 Firmen ausgemacht werden, die ihre Produkte und Dienstleistungen auch für Jahr 2000 Projekte anbieten. Etwa drei Viertel von ihnen beschäftigt weniger als 20 Mitarbeiter. Das Wissen dieser Anbieter über Anwendungsprogramme stammt meistens aus dem Bereich von SAP R/2 und Erweiterungen zu SAP R/3 oder generell von kaufmännischen Anwendungen und Branchenlösungen. Warenwirtschaft, Produktionsplanung und -Steuerung ist dabei seltener vertreten. Angeboten werden besonders häufig Beratung, Projektmanagement und SoftwareWerkzeuge. Einige Anbieter fuhren auch Schulungen, meist zu ihren Werkzeugen, durch. Einige andere wollen durch die Abwicklung von Pilotumstellungen auch beim Start und der Aufwandsschätzung eines Jahr 2000 Projektes helfen. Der Schwerpunkt der angebotenen Leistungen liegt bei der Einrichtung und bei der Werkzeug gestützte Durchführung von Projekten. Bei den von den Werkzeugen unterstützten Programmiersprachen dominiert COBOL. Aber es sind auch zahlreiche Werkzeuge für C, C++, PL/1 und Assembler vorhanden. Sowohl für RPQ Pascal und Fortran gibt es Werkzeuge als auch - unerwartet häufig - für Visual Basic und Delphi. Der Anwender wird sich im Zusammenhang mit Lösungsanbietern zum Jahr 2000 Problem möglicherweise drei Fragen stellen: „How to get them in? ... How to keep them out? ... How to get them out afterwards?" (B02) „Wie sie hinein bekommen? ... Wie sie draußen halten? ... Wie sie danach wieder loswerden?" Die erste Frage impliziert, daß beim Anwender eine Bedarf für eine Zusammenarbeit besteht. Dann ist der passende Anbieter auszuwählen und zu verpflichten. Auf Grund der großen Zahl möglicher Kandidaten ist der Auswahlprozeß nicht einfach. Spätestens ab Mitte 1998 wird es aber noch schwieriger werden, jemanden so zu verpflichten, daß die Interessen des Anwenders als Kunde gewahrt bleiben. Die Kürze der verbleibenden Zeit bis zum Jahr 2000 wird als ein entscheidendes Kriterium die Zahl und die Güte der Referenzen eines Lösungsanbieter herausbilden. Wenn ein Anbieter noch keine Referenzen aus Jahr 2000 Projekten nachweisen kann, dann sollte er an Wartungsprojekten oder mindestens an großen Projekten beteiligt gewesen sein. Um sicher zu sein, daß die Anbieter eine genügend große Zahl qualifizierter Mitarbeitern bereit stellen und über die nächsten zwei Jahre im Projekt halten kann, ist auf seine finanzielle Basis, seine mögliche Einbindung in einen Konzern und auf

3.6

Lösungsanbieter

111

die Erfahrung seines Managements zu achten. Möglicherweise ist er dadurch auch für eine langfristige Zusammenarbeit nach dem Jahr 2000 geeignet und man will ihn gar nicht wieder loswerden. Der dritte Bereich erster Auswahlkriterien ergibt sich aus dem Wissen des Anbieters um Wartungsmethode und -technik, Computer-Plattform und Programmiersprache sowie um die Anwendungen bei seinem möglichen Kunden. Mindestens sollte er diese Punkte durch eine entsprechende Dokumentation seiner bisherigen Projekte oder der Fähigkeiten seiner Werkzeuge und durch entsprechende, von ihm angebotene Kurse nachweisen. Die nun noch verbleibenden Anbieter kann man nach dem Preis für ihre Leistungen fragen. Die seriösen unter ihnen werden dann allerdings nur Preise für die ersten Projektphasen oder einen Preis für ein klar umrissenes Pilotprojekt nennen wollen. Der Anwender tut gut daran, das Pilotprojekt dann so anzulegen, daß es typische Anwendungsteile und Programme umfaßt, um den zu erwartenden Aufwand realistisch hoch rechnen zu können. Im Pilotprojekt zeigt sich gleichzeitig, wie die Mitarbeiter des Anwenders mit den Externen zurecht kommen und wie souverän der Anbieter Projektmanagement und Werkzeugeinsatz beherrscht. Zum Schluß des Auswahlprozessen kann man die noch verbliebenen Anbieter fragen, wie weit sie dem Anwender bei Preisgestaltung und Vertragspflichten entgegen kommen wollen. Es geht dabei einmal um Differenzierung auf der späteren Leistungsrechnung zwischen den Preisen für den zeitlichen Aufwand der Mitarbeiter des Anbieters je nach Qualifikation und den Preisen je nach Projektphase für den Werkzeuggebrauch. Anzustreben sind auch extra ausgewiesene Gesamtpreise für Dokumentation und Datensammlung, die so in das Eigentum des Kunden übergehen. Dann kann es die Möglichkeit geben, diese Kosten über die Nutzungsdauer der Anwendungen oder der Werkzeuge abzuschreiben. In den nächsten beiden Jahren ist damit zu rechnen, daß die Nachfrage nach den Leistungen der Jahr 2000 Lösungsanbieter stark ansteigen wird. Manche unter ihnen werden sich dann lieber neuen, besser zahlenden Kunden zuwenden oder starke Preiserhöhungen bei ihren bisherigen Kunden durchsetzen wollen. Daher sollte der Vertrag vorab mögliche Preiserhöhungen nennen, ansonsten aber dem Anbieter einen möglichst rigiden Zeitplan vorgeben, der bei wiederholter Überschreitung auch mit Konventionalstrafen bewehrt ist. Der Anbieter wird im Laufe eines Projektes mit fast allen Anwendungen und Programmen seines Kunden bekannt werden; daher ist strikte Vertraulichkeit bei allen Einzelheiten vorzusehen. Auch ist eine Klausel aufzunehmen, daß alle Programmänderungen, seien sie auch noch so umfangreich, keine geänderte Urheberschaft begründen bzw. das bei Anfertigung neuer Programme alle Rechte an den Kunden abgetreten werden.

112

3 Die ED V vor dem Jahr 2000 - Chancen

Der Kunde selbst sollte Sorge tragen, daß er dadurch, daß fremde Programmtextes durch Lösungsanbieter gepflegt werden, keine Rechte anderer verletzt, in dem er sie Dritten offenbart oder sie an Dritte weitergibt oder diese die Texte ändern. Die Lösungsanbieter sollten sich von allen derartigen Rechtsverletzungen durch ihren Kunden frei stellen lassen. Auch ist zu klären, ob Programme auf einer weiteren EDV-Anlage zu Testzwecken ausgeführt werden dürfen und ob Änderungen an Programmtexten den Verlust der bisherigen Verpflichtungen Dritter zur Programmpflege nach sich ziehen. Ein heikles Thema zwischen Anbieter und Kunden ist sicherlich, inwieweit der Lösungsanbieter für die Qualität seiner Lösung einsteht. Einerseits braucht der Kunde angesichts der möglichen Jahr 2000 Probleme verläßliche Zusicherungen; andererseits, wenn sich die Nachfrage erwartungsgemäß entwickelt, braucht der Lösungsanbieter sie ihm nicht zu geben. Der Anbieter haftet zwar aus Werkvertrag oder Dienstvertrag, er wird aber durch einzelne, vertragliche Bestimmungen seine Haftung stark einschränken wollen. Hier rächt sich natürlich der späte Beginn der meisten Jahr 2000 Projekte. Vor zehn Jahren hätte sicher jedes Softwarehaus für einen umsatzstarken Pflegevertrag weitgehende Verpflichtungen übernommen. Hier hilft also im Allgemeinen nur eine gewissenhafte Fortschrittskontrolle im Verlaufe des Projektes, die Einbindung eigener Mitarbeiter in die Wartungsmannschaft des Anbieters sowie strenge und rechtzeitige Tests der umgestellten Programmen. Die zweite Frage, „Wie sie draußen halten?", impliziert, daß beim Anwender kein Bedarf für eine Zusammenarbeit besteht. Das mag daran liegen, daß er schon einen für ihn passenden Lösungsanbieter gefunden hat oder daß er die Jahr 2000 Umstellungen in eigener Regie abwickeln möchte. Auch hier ist der Bericht über die bisher erzielten Projektfortschritte von Bedeutung, der, in geeigneter Form veröffentlicht, anderen Lösungsanbietern signalisiert, daß die Datumsprobleme erkannt und demnächst bewältigt werden. Die dritte Frage. „Wie sie danach wieder loswerden?", impliziert, daß beim Anwender kein Bedarf mehr für eine Zusammenarbeit besteht. Das sollte eigentlich nur dann eintreten, wenn im Laufe eines Jahr 2000 Projektes die Wartungsumgebung so weit optimiert werden konnte, daß der Anwender zuversichtlich alle künftigen Projekte selbst erledigen können wird. Denn eigentlich sollte man sich seinen Lösungsanbieter für eine langfristig angelegte Zusammenarbeit aussuchen, natürlich im wechselndem Umfang.

3.6.2

Die Lösungsanbieter in Projekten

In Großbritannien haben sich die Lösungsanbieter einen Verhaltenskodex (C01) gegeben. Er verpflichtet sie, ihre Dienstleistungen klar zu beschreiben, Projekte in Phasen anzugehen und auch anzugeben, welche Dienstleistung der Kunden in wel-

3.6

Lösungsanbieter

113

eher Projektphase erwarten kann. Sie wollen den Dienstleistungen in den Projekten bestimmtes qualifiziertes Personal zuordnen und auf Abwerbung von Personal bei ihren Kunden in jeder Form verzichten. Ein Jahr 2000 Projekt ist planungsintensiv und trotzdem voller Überraschungen. Daher sind Methoden und Werkzeuge in kleinem Umfang aber in typischer Umgebung in einem Pilotprojekt zu validieren. Deswegen muß man leider auch damit rechnen, daß von der Auftragsvergabe an einen Lösungsanbieter bis zu seiner umfassenden Bearbeitung der Datumsumstellung in parallel ablaufenden Projekten drei bis sechs Monate vergehen. Nach Untersuchungen in den USA (J02) trennen sich Anbieter von externer Programmpflege und deren Kunden in 15% der Fälle im Laufe von 24 Monate wieder, falls die Komplexität der zu pflegenden Programme über 250 000 Function-Points (eine realistische Zahl schon für mittlere Unternehmen) liegt. Aus den bisher durchgeführten Jahr 2000 Projekten wird dagegen berichtet, daß die ServiceAnbieter mit doppelter Produktivität und mit der halben Zahl noch verbliebener Datumsfehlern arbeiten - verglichen mit dem durchschnittlichen Entwicklungserfolg beim Anwenders. Durch die Änderungen in den Programmtexten werden möglicherweise nicht nur Datumsprobleme gelöst, sondern auch neue Probleme geschaffen. Anwender und Anbieter tragen hier ein gemeinsames Risiko. Durch intensive Programmanalyse und ebenso intensive Tests wird man auch manches andere Problem ohne Datumsbezug entdecken, dem Lösungsanbieter sollte dann ein Finderlohn zustehen. Oder man entdeckt Probleme mit Bezug auf Zeit- oder Datumsberechnung, aber ohne die Problematik des Jahrhundertwechsels, dann sollte der Lösungsanbieter für die Beseitigung dieser Probleme bezahlt werden. Möglicherweise hat man sich schon vor einiger Zeit für Programmpflege im Outsourcing entschieden, und zwar dann eben für eine Firma mit Referenzen, Firmenhintergrund und Know-how. Möglicherweise ist diese nun auch als Lösungsanbieter für Jahr 2000 Probleme geeignet. Vielleicht ist sie sogar schon zur vorbeugenden, erfolgreichen Fehlerbeseitigung auf Dauer verpflichtet. Wahrscheinlicher ist aber, daß sie nur das Bemühen um die Beseitigung schon aufgetretener Fehler schuldet und dann auch nur für die Dauer des Vertrages, die durch Kündigung stark verkürzt werden kann. In diesem Fall sollte man sie wie andere Lösungsanbieter für einen speziellen Jahr 2000 Projektvertrag in die engere Wahl ziehen. Umgekehrt besteht die Lösung einzelner Anbieter gerade darin, die Beseitigung von Jahr 2000 Problemen in einer speziellen, externen Wartungsumgebung, einer sog. „Software factory" vorzunehmen. Diese „Fabrik" integriert die notwendigen, verschiedenen Bearbeitungsschritte zu einem sich immer wiederholenden, kontrollierten und gekoppelten Prozeß:

3 Die ED V vor dem Jahr 2000 - Chancen

114

•

Programmanlieferung

•

Registrierung

•

vorläufige Analyse

•

Ablaufsteuerung

•

gründliche Analyse

•

Korrekturen

•

Umstellung

•

Testfallentwicklung

•

Test

•

Programmauslieferung

Dabei ist es günstig, den Anwender als Kunden der Fabrik nicht nur bei der Programm-Anlieferung und -Auslieferung einzubeziehen, sondern auch im Prozeß Punkte für Vorgaben von Kundenseite vorzusehen (U01): •

Analysemethoden

•

Umstellungsoptionen

•

Testverfahren

So ergibt sich eine geteilte Verantwortung für die Qualität der Ergebnisse und eine für die Kundenbedürfnisse optimierte Verarbeitung der Software-Fabrik. Wenn man schon Software nach draußen gibt, so wird man auch daran denken, die Umstellung in sogenannten „Billig-Lohn-Ländern" bearbeiten zu lassen. Man sollte allerdings bedenken, daß zahlreiche manuelle Eingriffe in einen Programmtext und seien sie auch preiswert, viele neue Probleme bedeuten können. Besser erscheint es, die Programmierung in fernen Ländern mit dem auch dort vorhandenen Know-how über einen Fabrikansatz zu kombinieren, der einen verstärkten Werkzeugeinsatz bedeutet und mehr Kontrolle über die Änderungen mit sich bringt. Am besten hat man dann noch einen einheimischen Generalunternehmer, der die Programm-Anlieferung und Auslieferung organisiert und den Fabrikprozeß optimiert. Das erleichtert die Kommunikation, bürgt für die nötige Stabilität des Anbieters und verbessert die Haftungslage für den Kunden bei Qualitätsproblemen sowie bei Verletzung der Schutzrechte an seinen Programmen.

3.6

3.6.3

Lösungsanbieier

115

Die Werkzeuge der Lösungsanbieter

Dem Autor sind vier Marktübersichten bekannt, die solche Werkzeuge vorstellen oder sich vorstellen lassen. Zur ersten Art gehören die Studien von Bloor Research mit 18 Vorstellungen (H03) und von CSC Ploenzke mit 23 Vorstellungen (C02), beide aus dem Jahr 1996. CSC Ploenzke gibt an, man habe einen Fragebogen an etwa 100 Firmen geschickt. Zur zweiten Art gehören die Firmenprofilierungen von Nomina aus dem Jahre 1997, eine mit 26 textlichen (107) und eine mit über 300 strukturierten Selbstdarstellungen (108). Lösungsanbieter können leicht international agieren, da das Jahr 2000 Problem keine nationalen Besonderheiten kennt. Insofern müßte man eigentlich den Markt weltweit untersuchen. Außerdem kommen wöchentlich neue Firmen und Produkte dazu. Die vorhandenen Produkte werden ständig weiterentwickelt. Für den Beginn neuer Projekte ist noch maximal ein Jahr Zeit, so daß auch mit verstärkten Kooperationen und Übernahmen unter den Lösungsanbietern zu rechnen ist. Deswegen leiden alle Studien dieser Art unter dem Mangel, unvollständig zu sein, und mit ihrem Erscheinen sind ihre Vorstellungen nicht mehr aktuell. Daher beschränken sich die folgenden Ausfuhrungen auf grundsätzliche Erwägungen. Mittlerweile haben alle am Markt nachgefragten Produkte schon eine Entwicklung hinter sich, die sich in den letzten Jahren durch die Anforderungen aus den Projekten stark beschleunigt hat. Ihre Funktionalität wird erweitert, ihre Benutzung vereinfacht, ihre Zuverlässigkeit und Geschwindigkeit erhöht. Daneben drängen Produkte in den Jahr 2000 Werkzeug-Markt, die sich schon lange Zeit in komplexen Wartungs- und Reverse-Engineering-Projekten bewährt haben. Aber auch das beste Software-Werkzeug kann Fehler haben und auch das Produkt mit der schönsten Oberfläche kann noch effektiver genutzt werden. Daher ist auch zu fragen, wie sieht die Unterstützung für den Einsatz der Werkzeuge aus: Spezialisten, Dokumentation, Training, Fehlerbeseitigung, falls man es selbst einsetzen möchte und nicht den Einsatz durch die Mitarbeiter eines Lösungsanbieters vorzieht. Falls man die in Jahr 2000 Projekten eingesetzten Werkzeuge langfristig nutzen will, sollte der Anwender auch eigene Mitarbeiter zu Werkzeugspezialisten ausbilden und darauf achten, daß ein Werkzeug so angelegt ist, daß es sich in die vorhandene Entwicklungs- und Wartungsumgebung einfach einbauen läßt. Das Jahr 2000 Projekt ist zum einen ein großes Projekt, das in den meisten Unternehmen den Einsatz von Werkzeugen für das Projektmanagement erfordert. Dann ist es ein Software-Wartungsprojekt, so daß der Einsatz von Werkzeugen für das Management der Konfiguration von Softwarekomponenten, der Version aller konfigurierten Komponenten und der Release-Pakete aller Komponenten passender Version erforderlich ist. Während eines solchen umfassenden und langwierigen Projektes und auch unabhängig davon werden zahlreiche Komponenten geändert,

116

3 Die ED V vor dem Jahr 2000 - Chancen

so daß beim Management der Softwarekomponenten auch die Verwaltung aller Änderungen zu besorgen ist. Dann ist es ein Projekt, das sich speziell der Verarbeitung bestimmter Programmvariablen vom Typ Datum und dann auch dem Datum selbst annimmt. Je nach eingesetzten Entwicklungs- und Ablaufumgebungen sowie nach Phasen im Projekt Analyse, Umstellung, Test - gibt es verschiedene Werkzeuge für unterschiedliche Zwecke. „Das" Werkzeug gibt es nicht. Man ist also gezwungen mehrere Werkzeuge einzusetzen und diese methodisch und technisch integriert zu nutzen. Diesem Zwang sollte man möglichst bald nachgeben und sich einen Werkzeugkoffer zulegen. Denn auch die Preise für Werkzeuge werden im Laufe des Jahres 1998 stark ansteigen. Bei der Analyse und Bestandsaufnahme der Anwendungen können Werkzeuge helfen, die etwa •

die Anwendungen und ihre Teile und Funktionen beschreiben,

•

die Verantwortlichen dafür in den verschiedenen Organisationseinheiten eines Unternehmens benennen,

•

eine Klassifizierung der Anwendungen nach ihrer geschäftlichen Bedeutung vornehmen und

•

die Fortschritte bei der Annäherung an die Jahr 2000 Fähigkeit verzeichnen.

Die Analyse der EDV-Systeme zielt ab auf das Verständnis und die umfassende Registrierung von Programmen in ihrer Ablauf- und in ihrer Entwicklungsumgebung. Es gibt zahlreiche Monitore in der Ablaufumgebung, die Programmabläufe überwachen und die Ergebnisse systematisch darstellen. Manchmal fehlt dann zu einem gefundenen Programmobjekt der (richtige) Programmtext. Es gibt auch Werkzeuge, die diesen Text wieder herstellen können. Wenn der Programmtext also vorliegt, dann kann er durch komfortable Editoren oder syntax-sensitive Browser betrachtet werden. Andere Werkzeuge können mit Unterstützung der Programmierer Datenfelder finden und zählen. Wieder andere Werkzeuge analysieren die Befehls- und Datenstrukturen im Programm und legen sie und ihre Bezüge in einer Datenbank ab. Zusammen mit einem Maß für die Komplexität und einer Bezugsgröße für den Aufwand einer einzelnen Korrektur, kann dann der Umstellungsaufwand für ein Programmsystem oder eine Anwendung geschätzt werden. Einem Werkzeug zum Auffinden von Programmstellen mit Datumsproblemen kann man zwei Trefferrate zuordnen, eine für den Anteil der Stellen mit tatsächlichen Datumsproblemen an den insgesamt gefundenen Programmstellen („false positives"), eine andere für den Anteil an gefundenen Stellen mit Datumsproblem an den tatsächlich im Programm vorhandenen und in einem Test noch zu entdeckenden

3.6

Lösungsanbieier

117

Stellen mit Problemen („false negatives"). Beide Raten sollten hoch sein, möglich ist durchaus 99% für die erste und 95% für die zweite Rate. Werkzeuge, die nur auf Datenfeldnamen oder auf Datenfeldtyp aufsetzen, erreichen geringere TrefTerraten als Werkzeuge, die nach dem sog. „slicing"-Verfahren Spurensuche betrieben, also zu einer Variable und Programmstelle, die Befehle und Bedingungen finden, die die Variable ändern können und die auf einem Pfad zur Stelle im Programm liegen. Genau so gute TrefTerraten erreichen Werkzeuge, die Teile eines Kompilierers neu erfinden und seinen Syntaxbaum und seine Speicherbelegung nachempfinden können. Beide Werkzeugklassen sind von der eingesetzten Programmiersprache abhängig und nur für wenige Programmiersprachen fertig zu erhalten. Mittlerweile gibt es aber auch schon Baukästen, um derartige Werkzeuge für weitere Sprachen effektiv zu entwickeln. Es ist auch an die Beschaffung eines Debuggers zu denken, der vielfache Möglichkeiten hat, Speicherbereiche zur Laufzeit eines Programms zu überwachen oder Programmaktionen mitzuschreiben und der damit nicht nur für spezielle Analysen sondern auch für Tests nützlich sein kann. Die Umstellung auf die Jahr 2000 Fertigkeit eines Programms geschieht in einem ersten Schritt durch die Bereinigung bekannter, alter Probleme und die Ersetzung magischer Zahlen und der mit ihnen implizit verbundenen Logik durch eine explizite Logik, die den Mißbrauch von Jahreszahlen für andere Zwecke vermeidet. Um die verschiedenen Datums- und Zeitformat einfach ineinander umzuwandeln und korrekte Datumsberechnungen oder -interpretationen anstellen zu können, sollten Bibliotheken mit Datumsroutinen eingerichtet werden, daran anschließend wird man sie je nach Lösungsverfahren in die Programmtexte einbauen. Für maschinelle Änderungen im Text ist das Verfahren der Zeitfenster komplizierter und erfordert mehr manuelle Eingriffe. Allerdings gibt es auch Werkzeuge, die auf den Ergebnissen der Analysephase aufsetzen und aus der abstrakten Beschreibung des Programmtextes und der abstrakten Beschreibungen der gewünschten Änderungen einen neuen, korrekten Text automatisch erzeugen können. Dann sind alle Lösungsverfahren, auch die Umstellung auf vier Stellen oder die Codierung in zwei Stellen, mit einem vergleichbaren Aufwand verbunden. Die zahlreichen Änderungen an den Programmtexten werden nun systematisch in verschiedenen Testverfahren überprüft. Die Verfahren der Zeitfenster sind dabei mit weniger geänderten Stellen und damit auch mit weniger Testfällen als die anderen Umstellungsverfahren verbunden. Falls man jedoch über Werkzeuge die Anzahl der zu testenden Programmpfade minimiert, zu den geänderten Programmstellen Testfälle erzeugt und die gesamte Teststeuerung automatisiert, relativiert sich dieser Vorteil wieder. Dabei verlangt die Erzeugung der Testfälle die umfangreichste Vorbereitung und auch großen manuellen Aufwand. Den Aufwand reduzieren hier Werkzeuge zum

3 Die ED V vor dem Jahr 2000 - Chancen

118

Mitschreiben von Eingaben der Benutzer und zur automatischen Wiederholung dieser Eingaben in der Testumgebung. Dann ist an flexible Werkzeuge zur Alterung von Testdaten, zum Dateivergleich und zur Erstellung und Auswertung von Prüfprotokollen zu denken. Es ist meistens nicht möglich, die Uhr des Entwicklungsrechners, an dem viele Programmierer arbeiten, zu verstellen, daher wird auch ein Werkzeug benötigt, daß für einzelne Programme den Ablauf der Rechnerzeit in der Zukunft simuliert.

3.6.4

Die Lösungsanbieter im Markt

Das mittlerweile bekannteste Marketingprojekt stellt die „Initiative 2000" dar, ein Zusammenschluß von etwa 20 namhaften EDV-Unternehmen dar. Sie ist unter http://www.initiative2000.de zu erreichen. Ihre Ziele sind die Aufklärung von Unternehmen über die Datumsproblematik, die Schaffen von Aufmerksamkeit unter Entscheidern durch Befragungen und Checklisten zum Thema und die Vermittlung von Kontakten zu Lösungsanbietern. Ein neues Projekt stellt die „ISIS Jahr-2000 Kampagne" der Nomina dar, das von etwa 30 Lösungsanbietern unterstützt wird und unter http://www.Jahr-2000.de zu erreichen ist Nomina fuhrt damit zum einen ihr traditionelles Geschäft mit der Selbstdarstellung von Softwarehäusern fort, zum anderen spricht sie auf EDVMessen zusammen mit Verbänden wie dem Bundesverband Informations- und Kommunikations-Systeme (BVB) oder dem Verband der Softwareindustrie Deutschlands (VSI) das Thema an.

3.6.5

Was folgt daraus?

=> Die Jahr 2000 Probleme entstehen entlang dem Zeitstrahl, das macht diffizile Zeitplanungen für Projektarbeiten nötig; das gilt auch für die Zusammenarbeit mit Lösungsanbietern. Der Aufwand der Jahr 2000 Projekte läßt sich nur phasenweise oder über Pilotstudien festlegen; das sollte man auch bei der Prüfung der Angebote von Dienstleistungsunternehmen berücksichtigen. => Der Einsatz von Werkzeugen ist hilfreich, vereinfacht aber nur die Lösung von Teilproblemen in einem Jahr 2000 Projekt. Der Schlüssel zum Erfolg besteht in der Kompetenz der Lösungsanbieter und der wohl organisierten Zusammenarbeit mit ihnen.

3.7 Die Jahr 2000 Fähigkeit der ED V- und Elektronik-Hersteller

3.7

119

Die Jahr 2000 Fähigkeit der EDV- und Elektronik-Hersteller

•

Definitionen

•

Jahr 2000 fähige Produkte

•

Was folgt daraus?

Es gibt natürlich EDV- und Elektronik-Firmen, die schon immer Hardware, Systemsoftware, Anwendungssoftware oder ganze EDV-Systeme ohne Jahr 2000 Probleme geliefert haben. Es gibt andere, die glauben nur, sie würden das tun, oder wieder andere, die wissen schon, daß sie es nicht tun. Gegenüber diesen beiden gilt es auf der Jahr 2000 Fähigkeit ihrer Produkte zu bestehen bzw. einen Verhandlungs- und Entwicklungsprozeß aufzubauen, um die Jahr 2000 Fähigkeit herzustellen. Auf die Jahr 2000 Fähigkeit sind übrigens auch die in eigener Regie oder die von Lösungsanbietern umgestellten Anwendungen zu prüfen.

120

3 Die ED V vor dem Jahr 2000-

Einrichtung des Jahr 2000 Projektrahmens

Einrichtung eines Jahr 2000 Projektes

Analyse der EDVAnwendungen

Inventar der Anwendungen

System Management — — J — — Inventar der EDV-Systeme,

m

Analyse der EDV-Systeme

korrekt

fehlerhaft

Chancen

3.7

Die Jahr 2000 Fähigkeit der EDV- und

3.7.1

Elektronik-Hersteller

121

Definitionen

Die Computer-Abteilung von IEEE hat einen Entwurf für einen Standard der Jahr 2000 Terminologie vorgelegt. Daraus sind einige Ausdrücke ins Glossar übernommen. Dort wird auch die Jahr 2000 Fähigkeit definiert: „Year 2000 compliant: information technology, when used in accordance with its associated documentation, is capable upon installation of accurately processing, providing, and/or receiving date data from, into, and between the twentieth and twenty-first centuries, inlucing leap year calculations, provided that all other technology used in combination with said technology properly exchanges date data with it." (101) „Jahr 2000 fähig: Informationstechnik, wenn in Übereinstimmung mit ihrer zugehörigen Dokumentation benutzt, ist fähig nach Installation, Datumswerte aus dem, in dem und zwischen dem 20. und 21. Jahrhundert korrekt zu verarbeiten, weiterzuleiten und/oder zu empfangen, einschließlich Schaltjahrberechnungen, vorausgesetzt, daß alle andere Technik, die in Kombination mit der hier besprochenen Technik benutzt wird, in geeigneter Weise mit ihr Datumswerte austauscht." Informationstechnik soll sich hier auf alle Arten von Technik beziehen, die Datumswerte verarbeitet, nicht nur auf EDV-Systeme sondern auch auf elektronische Geräte. Diese Definition schließt nicht aus, das man einzelne Produkte auch entgegen ihrer Dokumentation oder in einer veränderten Installation nutzen kann. Dabei kann dann die ansonsten gegebene Jahr 2000 Fähigkeit verloren gehen. Zur Jahr 2000 Fähigkeit eines Systems oder einer Anwendung gehört auch, daß der Austausch von Datumswerten innerhalb einer Anwendung unter ihren Bestandteilen und in Kombination mit weiteren Systemen entsprechend der Dokumentation korrekt abläuft. Selbstverständlich darf kein Wert des Datums Unterbrechungen oder Störungen der Verarbeitung verursachen. Als nächstes ist zu definieren, wie in den einzelnen Anwendungsteilen im Detail eine korrekte Verarbeitung von Datumswerten aussieht. „Year 2000 ready: a singular application is capable of accurately processing date data from, into, and between the twentieth an twenty-first centuries, inlucing leap year calculations." (101) „Jahr 2000 fertig: eine einzelne Anwendung ist fähig, Datumswerte aus dem, in dem und zwischen dem 20. und 21. Jahrhundert korrekt zu verarbeiten, einschließlich Schaltjahrberechnungen." Der Ausdruck Fertigkeit kann sowohl bedeuten, daß eine Anwendung entsprechend dem englischen Ausdruck fertig gestellt ist, als auch, daß eine Anwendung das Vermögen besitzt, mit dem Jahr 2000 umzugehen.

122

3 Die ED V vor dem Jahr 2000 - Chancen

Man beachte, daß jetzt nicht mehr vom Austausch von Datumswerten die Rede ist. Auch ist nicht mehr gefordert, daß eine einzelne Anwendung ab Installation die Jahr 2000 Fertigkeit besitzt. Eventuell sind also bestimmte Einstellungen vorzunehmen, um einer Anwendung die Jahr 2000 Fertigkeit mitzugeben. Die allgemeine Definition der Jahr 2000 Fertigkeit wird von der US Air Force auf zu erfüllende Anforderungen für die Verarbeitung von Datumswerten konkretisiert und damit auch für Testzwecke nutzbar gemacht: „From now until 1 January 2000, each Automated Information System (AIS) must correctly process data containing dates before 1 January 2000. From now until 1 January 2000, each AIS must correctly process data containing dates after 31 December 1999. From 1 January 2000 forward, each AIS must correctly process data containing dates before 1 January 2000. From 1 January 2000 forward, each AIS must correctly process data containing dates after 31 December 1999. Each AIS must be able to handle the date 2001/01/01 (1 January 2001) and all succeeding dates correctly. Display, print, input, and store dates unambigously in the context of the systems which use them. Each AIS must recognize correctly that 2000 is a leap year. Each AIS must ensure: 29 February 2000 is recognized as a valid date. Julian date 2000060 is recognized as 29 February 2000. Julian date 2000366 is recognized as 31 December 2000. Arithmetic operations performed recognize that year 2000 has 366 days." (S02) „Von jetzt bis zum 1. Januar 2000 muß jedes Automatisierte Informationssystem (AIS) korrekt Daten verarbeiten, die Datumswerte vor dem 1. Januar 2000 enthalten. Von jetzt bis zum 1. Januar 2000 muß jedes AIS korrekt Daten verarbeiten, die Datumswerte nach dem 31. Dezember 1999 enthalten. Vom 1. Januar 2000 an muß jedes AIS korrekt Daten verarbeiten, die Datumswerte vor dem 1. Januar 2000 enthalten. Vom 1. Januar 2000 an muß jedes AIS korrekt Daten verarbeiten, die Datumswerte nach dem 31. Dezember 1999 enthalten. Jedes AIS muß fähig sein, das Datum 2001/01/01 (1. Januar 2001) und alle folgenden Datumswerte korrekt zu handhaben. Anzeigen, drucken, eingeben und speichern von Datumswerten muß ohne Mehrdeutigkeit möglich sein im Kontext des Systems, das sie nutzt. Jedes AIS muß korrekt erkennen, daß das Jahr 2000 ein Schaltjahr ist. Jedes AIS muß sicherstellen: Der 29. Februar 2000 ist ein gültiges Datum. Das julianische Datum 2000060 ist als 29. Februar 2000 zu erkennen. Das julianische Datum 2000366 ist als 31. Dezember 2000 zu erkennen. Durchzuführende arithmetische Operationen erkennen, daß das Jahr 2000 hat 366 Tage." Deutlich kürzer ausgedrückt wird der gleiche Sachverhalt von N. Zvegintzov, einem Experten für Softwarepflege: „Year 2000 Correctness: The application can process time and date information unambigously and correctly for all time and date data that are within its

3.7

Die Jahr 2000 Fähigkeit der ED V- und

Elektronik-Hersteller

123

required operating conditions while executing at all times and dates that are within its required operating conditions." (Z01) „Jahr 2000 Korrektheit: Die Anwendung kann Zeit- und Datumsinformation eindeutig und korrekt verarbeiten für alle Zeit- und Datumswerte, die innerhalb der von ihr geforderten Betriebsbedingungen sind, während sie zu allen Zeiten und Tagen ausgeführt wird, die innerhalb der von ihr geforderten Betriebsbedingungen sind." Ein elektronisches Produkt mag die Jahr 2000 Fertigkeit im Einzelnen oder auch die Jahr 2000 Fähigkeit insgesamt vermissen lassen, es sollte aber mindestens die Jahr 2000 Sicherheit besitzen. „Year 2000 safe is a new concept arising out of societal concerns for citizen/organizational safety. A consensus is developing over the need to ensure that Computer applications do NOT cause direct or indirect personal injury or physical property damage when handling year 2000 processes." (101) „Jahr 2000 sicher ist ein neues Konzept, das aus gesellschaftlichen Sorgen um die Sicherheit von einzelnen Bürgern oder Gruppen von Bürgern stammt. Es entwickelt sich die übereinstimmende Meinung, daß es Bedarf gibt, sicher zu stellen, daß Computer-Anwendungen keinen direkten oder indirekten Personenschaden und auch keinen Sachschaden verursachen können, wenn sie mit Jahr 2000 Verarbeitungen umgehen."

3.7.2

Jahr 2000 fähige Produkte

Von einem EDV- und Elektronik-Hersteller ist also seitens der Anwender die Jahr 2000 Fertigkeit jeder einzelnen Komponente seines Produktes und die Jahr 2000 Fähigkeit des ganzen Produktes einschließlich der Angabe zu fordern, wie sein Produkt mit anderen beim Anwender im Einsatz befindlichen Produkten korrekt zusammenarbeiten kann. Hersteller, die die Jahr 2000 Fähigkeit ihrer Produkte behaupten, haben auch die Pflicht, wo Fehleinstellungen ihrer Produkte möglich sind, vor Mißbrauch zu warnen und ihre Systeme mit Jahr 2000 Fähigkeit neu zu installieren oder bereits entsprechend konfiguriert anzuliefern. Mit den rechtlichen Argumenten aus dem Kapitel „Haftung aus Vertrag" ist so auf die Hersteller einzuwirken, daß sie die Jahr 2000 Fähigkeit entweder sofort für die verschiedenen, schon abgeschlossenen Verträge zusichern oder sie für einen bestimmten Zeitpunkt in naher Zukunft zusichern. Oft ist es nötig, vorher gemeinsam mit dem Hersteller zu bestimmen, welche seiner Produkte in welcher Version auf welcher Plattform im Einsatz sind. Die Zusicherung sollte entsprechend der Jahr 2000 Fertigkeit formuliert sein, so daß die Erfüllung der Zusicherung über einen Test geprüft werden kann. Ein künf-

124

3 Die ED V vor dem Jahr 2000 - Chancen

tiger Zeitpunkt für die Erfüllung der Zusicherung sollte noch im Jahr 1998 liegen, auf jeden Fall aber vor einem ersten Auftreten eines möglichen Jahr 2000 Problems. Auch bei neuen Verträgen über EDV- und Elektronik-Lieferungen ist an eine entsprechende Zusicherung zu denken. Bei Nichterfüllung der Zusicherung zum versprochenen Zeitpunkt kann eine Nachfrist nur in der Länge zugelassen werden, daß noch genug Zeit verbleibt, bei erneutem Fehlschlagen der Tests den Lieferanten zu wechseln. Der Anwender sollte darauf achten, daß es auch eine Zusatzbestimmung gibt, die ihm erlaubt, noch im Jahr 2001 seine Rechte gegenüber den Lieferanten aus Jahr 2000 Mängeln wahrzunehmen. „By the end of 1998, 20 percent of all vendors will not be year 2000 compliant; ... (0.7 probability)." „Bis zum Ende des Jahres 1998 werden 20 Prozent aller Hersteller nicht Jahr 2000 fähig sein; ... (0,7 Wahrscheinlichkeit)" (G01) Um die Gefahr klein zu halten, einen Lieferanten zu haben, der bis Ende 1998 nicht Jahr 2000 fähig ist, sind vom Lieferanten regelmäßige Berichte über seinen bisherigen Fortschritt in Richtung Jahr 2000 Fähigkeit zu verlangen. Darin ist auch mit der erforderlichen geschäftlichen Sorgfalt über aufgetretene und hoffentlich überwundene Schwierigkeiten und erfolgte oder geplante Änderungen bei Personal und Budget zu sprechen. Möglicherweise stellt sich auch heraus, daß eine neue Produktversion Änderungen in den Schnittstellen, bei der Datenhaltung oder auch bei der Konfiguration mit sich bringen wird. Ein kundenfreunlicher Lieferant wird natürlich von sich aus die rechtzeitige Lieferung einer Jahr 2000 fähigen Version im Rahmen der normalen Wartung ohne zusätzliche Kosten und ohne zusätzlichen Aufwand für den Kunden ankündigen. „Wir haben unsere Produkte ausfuhrlichen Tests unterworfen und freuen uns, berichten zu können, daß sämtliche Versionen der nachstehend aufgeführten Produkte Datum-Felder richtig verarbeiten und von Problemen, die mit dem Jahrhundertwechsel zusammenhängen, nicht betroffen sind. ... Wir haben außerdem unsere Qualitätssicherungs-Verfahren auf Erfüllung der Anforderungen „Verträglichkeit 2000" geprüft und werden auch künftig Prüfungen durchführen, um zu gewährleisten, daß unsere Produkte für den Übergang in das kommende Jahrhundert erfolgreich gerüstet sind." (W05) Aber selbst dann sollte man dieses Versprechen auf einem speziellen Testrechner mit verstellter Systemzeit und der einschlägigen Testumgebung überprüfen und vom Lieferanten verlangen, daß er für den Testzeitraum eine Nutzung auf dem Testrechner gestattet. Insbesondere sind die Produkte zu überprüfen, wo nur eine formularmäßige Angabe zur Jahr 2000 Fähigkeit aus einem Katalog bestimmter Softwareprodukte vorliegt. Andrerseits wäre es sicher eine große Hilfe für Nutzer

3.8

Die Jahr 2000 Initiativen der ED V- und

Elektronik-Hersteller

125

von Elektronik-Produkten, wenn eine offizielle Prüfstelle die Jahr 2000 Fähigkeit oder zumindest die Jahr 2000 Sicherheit feststellen würde. Falls ein Software-Produkt nicht rechtzeitig in Jahr 2000 fähiger Version vorliegt, ist auch zu prüfen, ob ein Anwender dieses Produkt durch eigene Leistungen umstellen will. Er kann es nur, wenn ihm Programmtext und Entwicklungsdokumentation vorliegen. Er darf es nur, wenn darüber eine Vereinbarung mit seinem Lieferanten existiert, die auch beschreiben sollte, welcher Personenkreis unter welchen Bedingungen an der Umstellung mitwirken darf. Er wird es nur wollen, wenn er dadurch nicht jeglichen Anspruch auf weitere Programmpflege durch den Lieferanten verliert.

3.7.3

Was folgt daraus?

=> Anzustreben ist die Jahr 2000 Fähigkeit aller eingesetzten Produkte. Dann kann man die Produkte der EDV- und Elektronik-Hersteller an dieser Anforderung messen. Die Zusicherungen der Jahr 2000 Fähigkeit sollten so gegeben werden, daß sie getestet werden können. => Die Lieferung und die Abnahme Jahr 2000 fähiger Produkte sollten im Jahr 1998 abgeschlossen werden.

3.8

Die Jahr 2000 Initiativen der EDV- und Elektronik-Hersteller

•

Das Jahr 2000 Problem beim Hersteller

•

Unterstützung der Kunden

•

Unterstützung der Lösungspartner

•

Was folgt daraus?

Die Jahren 2000 Initiativen der EDV- und Elektronik-Hersteller haben das Ziel, gemeinsam mit ihrer Kundschaft die Jahr 2000 Fähigkeit der Anwendungssysteme bei ihrer Kundschaft sicherzustellen. Dieses Kapitel beschreibt, was Hersteller dabei unternehmen können und auch sollten. Es beschreibt auch, wie ein Kunde diese Angebote zu seinem eigenen Vorteil nutzen kann. Ein partnerschaftliches Konzept hat hier Vorrang vor einer kritischen rechtlichen Beurteilung der vertraglichen Aspekte, wie sie das nächste Kapitel vornimmt; denn Hersteller und Anwender werden gemeinsam zumindest unter schlechter Presse leiden, wenn sie die Jahr 2000 Fähigkeit nicht rechtzeitig erreichen können.

126

3 Die EDV vor dem Jahr 2000 - Chancen

Einrichtung des Jahr 2000 Projektrahmens V Einrichtung eines Jahr 2000 Projektes

Analyse der EDVAnwendungen

SystemManagement

E D V - Vi-": ElektronikHersteller

Lösungsanbieter

3.8

Die Jahr 2000 Initiativen der ED V- und

3.8.1

Elektronik-Hersteller

127

Das Jahr 2000 Problem beim Hersteller

Alle EDV- und Elektronik-Hersteller setzen in ihrem eigenen Unternehmen zahlreiche und verschiedene und nicht nur die von ihnen selbst produzierten Computer ein. Sie haben also sehr wahrscheinlich alle ein internes Jahr 2000 Problem. Der Autor hat allerdings bisher keinen Hersteller gefunden, der über den Stand seines internen Jahr 2000 Projektes Auskunft gegeben hätte. Eine positive Auskunft würde die von den Herstellern erstrebte Kundenbindung verstärken; denn die Kundschaft macht sich möglicherweise Sorgen um die Fähigkeit eines Herstellers, sie über das Jahr 2000 hinaus mit Produkten und Ersatzteilen beliefern zu können. Da kaum ein Hardware-Hersteller alle Teile seiner Produkte selbst fertigt, müßte die Auskunft auch die Information enthalten, ob die Lieferanten der Hersteller schon ihre eigene Jahr 2000 Fähigkeit bzw. die Jahr 2000 Fertigkeit ihrer Produkte erreicht haben. Die Hauptgefahr, die alle EDV-Hersteller sehen, ist, daß ihre Kunden, so sie eine Anwendung ohne Jahr 2000 Fähigkeit entdecken, mit dem Wechsel zu einer anderen Anwendung auch den Hersteller ihres EDV-Systems wechseln. Daher warnen die Hersteller vor einem Systemwechsel mit den folgenden Argumenten: •

Sie werden die Jahr 2000 Fähigkeit ihres Systems und ihrer Produkte baldmöglichst erreichen.

•

Bei einem Wechsel zu einem anderen Hersteller ist es nicht sicher, ob dessen Systeme über die Jahr 2000 Fähigkeit verfügen.

•

Wenn eine neue Anwendung und ein neues System eingeführt werden soll, so bedarf es dafür immer organisatorischer Umstellungen, die Zeit kosten.

Je näher das Jahr 2000 rückt, desto mehr sticht natürlich das letzte Argument, doch um so nachdrücklicher ist von den Herstellern ein Terminplan zu fordern, an dem zu erkennen ist, wie sie Schritt für Schritt ihre eigene Jahr 2000 Fähigkeit und die ihrer Produkte erreichen.

3.8.2

Unterstützung der Kunden

Die Unterstützung der Kundschaft beginnt mit ihrer Information. Die großen EDVHersteller haben damit begonnen, alle ihre Kunden anzuschreiben, um sie auf das Jahr 2000 Problem im Allgemeinen hinzuweisen und um ihre besonderen Initiativen darzustellen. Allein damit leisten sie sicher einen bedeutenden Beitrag, um die Aufmerksamkeit für das Jahr 2000 Problem zu erhöhen. Die Hersteller sehen im verbesserten Kontakt mit der Kundschaft natürlich eine auch langfristig wirksame Marketingchance. Daher gibt es auch besondere Kom-

128

3 Die ED V vor dem Jahr 2000 - Chancen

munikationswege über Telefon, Telefax und E-Mail, wo die Kundschaft ihre Fragen zu den Jahr 2000 Aktivitäten des Herstellers stellen kann. Erst mit dem World-Wide-Web-Boom im Internet konnte das Jahr 2000 Problem in das allgemeine Bewußtsein dringen. Einzelne Personen haben schon seit mehr als zehn Jahren vergeblich in anderen Medien gewarnt. Dementsprechend haben alle großen EDV-Hersteller auch Jahr 2000 Informationen in ihren Internet-Auftritt integriert, sei es als Liste Jahr 2000 fertiger Produkte, sei es als Ratschläge zu ihren Produkten oder zu den Möglichkeiten, Jahr 2000 Projekte abzuwickeln, sei es auch als Frage-und-Antwort-Liste oder als Link-Liste. Manche Hersteller geben auch Empfehlungen, welche Werkzeuge auf ihre spezielle Programmiersprachen oder Programmierdialekte abgestimmt sind. Programmierdialekte bezeichnen hier Hersteller spezifische Erweiterungen von üblichen oder ansonsten standardisierten Programmiersprachen. Spezielle Programmiersprachen bezeichnen Sprachen, die ein Hersteller nur für seine Systeme entwickelt hat. Insbesondere gehören dazu CPU-spezifische Assemblersprachen. Nützlich sind auch Empfehlungen, wie Wartungsumgebungen für HostAnwendungen auf einem PC aufgebaut werden können, in denen dann die Werkzeuge zur Softwarepflege zum Einsatz kommen. Der nächste Schritt in der Kundenunterstützung besteht darin, gemeinsam mit der Kundschaft festzustellen, welche Produkte zur Zeit eingesetzt werden oder demnächst eingesetzt werden sollen. Wenn es sich um Hardware handelt läßt sich diese Feststellung sicher recht schnell treffen, da für Hardware gewöhnlich ein Wartungsvertrag besteht, der auch schon zu regelmäßigen Inspektionen in der Vergangenheit geführt hat. Die Bestandsaufnahme der Software-Produkte wird dann schon eher zu Überraschungen Anlaß geben und sie verlangt vom Hersteller ein gewisses Fingerspitzengefühl beim Umgang mit dem Kunden. In der Vergangenheit haben Herstellern oft Software verschenkt oder ihren inoffiziellen Einsatz stillschweigend gebilligt oder viele verschiedene Programme als ein Paket lizensiert. Daher kann es sein, daß ein Kunde Software einsetzt, die nicht lizensiert ist, oder er hat Software lizensiert, die er nicht einsetzt. Diese Situation sollte zum gegenseitigen Vorteil bereinigt werden. Wenn beide Seiten im Einzelnen wissen, welche Hardware und Software eingesetzt wird, dann kann der Hersteller daran gehen, für jedes Produkt zu erklären, wie er die Jahr 2000 Fertigkeit erreichen möchte. Bei der Hardware kann diese Erklärung dann auch besagen, daß er ganze Modellreihen ausmustern will. Bei anderen Modellreihen wird er nur für die Kombination von Hardware und Betriebssystem ab einer bestimmten, heute vorhandenen oder demnächst kommenden Version die Jahr 2000 Fähigkeit erklären wollen. Oft sind auch zu einer Betriebssystemversion ein oder mehrere Pakete von programmatischen Fehlerbeseitigungen zu installieren.

3.8

Die Jahr 2000 Initiativen der ED V- und Elektronik-Hersteller

129

Es ist interessant zu sehen, daß einzelne Betriebssystemversionen gerade zum 31.12.1999 aus der Wartung genommen werden sollen. Umgekehrt ist es natürlich erfreulich, wenn andre, schon heute erhältliche Versionen bis Ende 2002 gepflegt werden. Wenn für bestimmte Modelle oder bestimmte Versionen nicht die Jahr 2000 Fähigkeit erklärt wird, so bedeutet das nicht, daß diese Produkte Probleme bekommen werden. Das Risiko liegt aber dann beim Kunden, der Hersteller ist aus der Pflicht - vorbehaltlich einer rechtlichen Prüfung - und er wird bei Datumsproblemen keine Unterstützung mehr leisten. PC-Hersteller haben normalerweise keine Probleme mit Hardware oder Betriebssystem sondern nur mit der Firmware, dem sogenannten BIOS. Daher informieren sie über BIOS-Versionen, über Testmöglichkeiten und wie ein problematisches BIOS in ihren Produkte korrigiert werden kann. Neben zahlreichen Hardware-Modellen und Betriebssystemversionen haben große Hersteller im Laufe der letzten Jahrzehnte auch Hunderte von Werkzeugen für Systemverwaltung und Programmentwicklung sowie zahlreiche MiddlewareProdukte verkauft. Viele dieser Produkte oder ihre alten Versionen sollen jetzt ausgemustert werden, indem erklärt wird, man wolle sie nicht auf Jahr 2000 Fertigkeit testen. Auch hier bedeutet das nicht, daß diese Produkte Probleme bekommen werden. Manche Hersteller erklären sich daher auch bereit, auf Kundenwunsch eine bestimmtes Produkt gesondert zu testen. Sowohl die Erklärungen der Hersteller zu Hardware und Betriebssystem als auch die zu ihren sonstigen Produkten werden eine Welle der Migration zu neuen Systemen auslösen und werden den Herstellern helfen, ihre Kosten für Wartungsaufgaben deutlich zu senken. Daher bieten sie oft den Übergang von einer Systemkonfiguration zu einer anderen mit Jahr 2000 Fähigkeit zu einem besonders günstigen Preis an. Als Kunde sollte man den Jahr 2000 Versprechungen der Hersteller nur bedingt glauben. Die Bedingung ist, daß der Hersteller ein Testsystem mit den bei einem Kunden im Einsatz befindlichen Hardware- und Software-Komponenten installiert, für die er die Jahr 2000 Fähigkeit erklärt hat. Dann wird man darauf die im Kapitel „Testverfahren" beschriebenen System- und Anwendungstests durchfuhren. Es gibt Installationen, wo genau das getan wurde mit dem Ergebnis, daß eine Vielzahl von Datumsfehlern gefunden wurde. Ab dem Zeitpunkt, wo der Test gelingt, sollte der Kunde entscheiden können, diese Anlage für die Dauer der weiteren Anwendungstests zu mieten oder sie zu einem günstigen Preis zu kaufen, um generell neue Produktversionen testen oder neue Konfigurationen ausprobieren zu können. Das würde langfristig die Effizienz und die Qualität des Systembetriebes beim Kunden und damit auch die Kundenzufriedenheit mit dem Hersteller erhöhen.

130

3 Die ED V vor dem Jahr 2000 - Chancen

Manche Hersteller wollen auch direkt als Lösungsanbieter für Jahr 2000 Probleme auftreten. Da sie ihre Systeme gut kennen und die dort eingesetzte Software oft schon seit Jahrzehnten mit Werkzeugunterstützung pflegen, sollten sie dieser Aufgabe gewachsen sein. Oft lassen Hersteller schon seit langer Zeit ihre Software in Übersee entwickeln und haben daher gute Beziehungen zu den dort ansässigen, preisgünstigen Softwarehäusern.

3.8.3

Unterstützung der Lösungspartner

Da die Hersteller nur selten auch die Anwendungen für ihre Systeme produzieren, werden sie darüber hinaus auf ihre Lösungspartner einwirken, daß diese ihre Anwendungen Jahr 2000 fähig machen oder daß zumindest zu jeder Anwendung eine gleichwertige Jahr 2000 fähige Anwendung auf ihren jeweiligen Systemen existiert. Wenn das in der Vergangenheit noch nicht zwecks Verkaufsförderung geschehen sein sollte, so wird jetzt ein Lösungskatalog aufgestellt, in dem jeder Lösungspartner Angaben zu seiner Anwendung und auf das Jahr 2000 Problem bezogene Angaben macht: •

Ist die Anwendung schon Jahr 2000 fähig?

•

Durch welche Methode wurde das erreicht?

•

Ab welcher Version wird das zugesichert?

•

In welcher Systemumgebung trifft das zu?

•

Ist die Anwendung noch nicht Jahr 2000 fähig?

•

Soll sie ausrangiert oder ersetzt werden?

•

Bis wann erscheint eine umgestellte Version?

•

Wie kann das getestet werden?

•

Kann eine Anwendung für Testzwecke und auch mit vorgestellter Systemzeit lizensiert werden?

•

Sind mit der neuen Version geänderte Schnittstellen oder Datenstrukturen verbunden?

•

Wie soll dem Kunden geholfen werden, seine Programme und Daten auf die neue Version umzustellen?

Ein weitsichtiger Hersteller wird seine Lösungspartner beim Bestreben, die Jahr 2000 Fähigkeit zu erreichen, in gleicher Weise wie seine Kundschaft mit Informationen und Testmöglichkeiten unterstützen. Denn eine große Chance, die jeder EDV-Hersteller sieht, ist, daß Kunden seiner Konkurrenz, so sie eine Anwendung ohne Jahr 2000 Fähigkeit entdecken, mit dem Wechsel zu einer anderen Anwen-

3.9 Die vertragliche Haftung der ED V- und Elektronik-Hersteller

131

dung auch den Hersteller ihres EDV-Systems wechseln und daher auch zu ihm kommen können. Ein Lösungskatalog, der Jahr 2000 fähige Anwendungen für einen Hersteller beschreibt, kann für den Wechsel zu ihm eine große Hilfe sein. Wenn der Hersteller sich auch als Lösungsanbieter profilieren will, so wird er auch seine Partner in dieses Geschäft einbeziehen. Er wird sie als Subunternehmer einsetzen und sie dann auch mit seiner Lösungsmethode vertraut machen oder er wird ihnen nur die Methode nahe legen und dann mit ihnen gemeinsam den Markt für Jahr 2000 Werkzeuge und Dienstleistungen erschließen. Bei der absehbaren Personalknappheit auf dem EDV-Arbeitsmarkt tut jeder Hersteller gut daran, wenn er über seine Partner Personal an sich und damit an seine Kunden bindet.

3.8.4

Was folgt daraus?

=> EDV-Hersteller können nützliche Partner bei Bestandsaufnahme der EDVSysteme, bei der Umsetzung von Jahr 2000 Lösungen und beim System- und Anwendungstest sein. => EDV-Hersteller wollen Partner ihrer Kunden sein, um sie nicht in den nächsten Jahren zu verlieren und um bis weit in das nächste Jahrzehnt - nach gemeinsam überstandenen Jahr 2000 Problemen - effektiver mit ihnen zusammenzuarbeiten.

3.9

Die vertragliche Haftung der EDV- und Elektronik-Hersteller

•

Der Kaufvertrag

•

Der Werkvertrag

•

Der Dauerschuldvertrag

•

Der Mietvertrag

•

Der Leasingvertrag

•

Der Pachtvertrag

•

Der Rechtsanwalt im Jahr 2000 Projekt

•

Was folgt daraus?

Wenn hier über Chancen gesprochen wird, so natürlich erst einmal aus Anwendersicht. Ein Anwender hat die Chance, über die Haftung seiner EDV- und ElektronikLieferanten kostenfreie Leistungen und Schadensersatz zu erhalten.

132

3 Die ED V vor dem Jahr 2000 - Chancen

Andererseits haben die Lieferanten die Chance, über heutige Leistungen den künftigen Schaden klein zu halten und damit auch ihr Haftungspotential zu begrenzen. Lieferanten können auch Lösungsanbieter in einem Jahr 2000 Projekt sein. Durch die Risiken eines solchen Projektes setzen sie sich besonderen Haftungsrisiken aus. Hier liegen die Chancen für den Lieferanten nur in einer vertraglich im Einzelnen zu vereinbarenden Haftungsbegrenzung. 3.9.1

Der Kaufvertrag

Bei dem Erwerb sogenannter Standardsoftware, d.h. Software, die im Wesentlichen gleichartig bei verschiedenen Kunden des Verkäufers der Software im Einsatz ist, wird man normalerweise auf einen Kaufvertrag erkennen. Das gilt auch für ein Softwarehaus, das Teile seiner Software von einem anderen Softwarelieferanten bezieht. § 433 BGB - Grundpflichten (1) Durch den Kaufvertrag wird der Verkäufer einer Sache verpflichtet, dem Käufer die Sache zu übergeben und das Eigentum an der Sache zu verschaffen. Der Verkäufer eines Rechtes ist verpflichtet, dem Käufer das Recht zu verschaffen und, wenn das Recht zum Besitz einer Sache berechtigt, die Sache zu übergeben. (2) Der Käufer ist verpflichtet, dem Verkäufer den vereinbarten Kaufpreis zu zahlen und die gekaufte Sache abzunehmen.

Der Verkäufer haftet für Fehler an der verkauften Software, wobei ein Fehler immer dann vorliegt, wenn sie sich nicht so verhält, wie es sachverständige Verkehrskreise erwarten oder wie es dem Stand der Technik entspricht. Künftige, aber schon absehbare Probleme, also gerade Jahr 2000 Probleme, fuhren zu einer verringerten Nutzungsdauer der Software, vermindern also schon heute den Wert der Software und sind daher auch als Fehler anzusehen. Darüber hinaus muß Software alle die in ihrer Dokumentation beschriebenen, also zugesicherten Eigenschaften haben. Ein Mangel ist es auch, wenn die Prüfung auf plausible Eingaben unterbleibt und daher Nutzer ohne Rückmeldung durch das Programm magische Zahlen wie „99" oder „00" für die Jahreszahl eingeben können. Die Anschauung der im Softwaremarkt als Käufer oder Verkäufer agierenden Personen ist auch maßgeblich, wenn es um die Dauer der Funktionstüchtigkeit der Software geht. Diese bei Vertragsabschluß vorausgesetzte Dauer wird man nicht auf die Dauer der Gewährleistung (6 Monate) sondern eher auf die voraussichtliche wirtschaftliche Nutzungsdauer beziehen. Software von wesentlichem Wert mit

Der Autor ist kein Rechtsanwalt. Die folgenden Ausführungen geben ausschließlich seine persönliche Meinung wieder. Hinweise auf mögliche Fehler und Auslassungen sind willkommen. Die folgende Darstellung soll nicht als Beratung in rechtlicher Hinsicht interpretiert werden.Alle Leser werden gebeten, ihre besondere Lage mit ihrem Anwalt für alle im folgenden genannten Problemkreise durchzusprechen.

3.9

Die vertragliche

Haftung der EDV- und

Elektronik-Hersteller

133

einem Jahr 2000 Problem, die nach dem 1.1.1995 verkauft wurde, ist also bestimmt als fehlerhaft anzusehen (B04). Der Verkäufer von Software kann also auch nicht aus eigenem Ermessen, das Ende der Nutzungsdauer willkürlich auf den 31.12.1999 setzen können, um nicht mehr für Fehler zu haften, die ab dem 1.1.2000 auftreten werden. Allerdings kann bei einem kombinierten Bezug der Hard- und Software von einem Verkäufer die Nutzungsdauer der Software auch an die Nutzungsdauer der Hardware gekoppelt sein. § 459 BGB - Haftung für Sachmängel (1) Der Verkäufer einer Sache haftet dem Käufer dafür, daß sie zu der Zeit, zu weicher die Gefahr auf den Käufer übergeht, nicht mit Fehlern behaftet ist, die den Wert oder die Tauglichkeit zu dem gewöhnlichen oder dem nach dem Vertrage vorausgesetzten Gebrauch aufheben oder mindern. Eine unerhebliche Minderung des Wertes oder der Tauglichkeit kommt nicht in Betracht. (2) Der Verkäufer haftet auch dafür, daß die Sache zur Zeit des Überganges der Gefahr die zugesicherten Eigenschaften hat.

Streiten wird man sich sicher um die Anwendbarkeit des folgenden Paragraphen; denn spätestens seit dem 1.1.1997 kann man wohl davon ausgehen, daß jeder Käufer eine ausreichende Kenntnis der möglichen Jahr 2000 Probleme hat und daher, so er nicht fahrlässig handeln will, nach der Abwesenheit des Jahr 2000 Problems in der Kaufsache gefragt haben sollte. Umgekehrt begründet natürlich jegliche Zusicherung einer wie auch immer gearteten Jahr 2000 Fähigkeit durch den Verkäufer eine Haftung für eben das Fehlen dieser Eigenschaft. § 460 BGB - Kenntnis des Käufers Der Verkäufer hat einen Mangel der verkauften Sache nicht zu vertreten, wenn der Käufer den Mangel bei dem Abschlüsse des Kaufes kennt. Ist dem Käufer ein Mangel der im § 459 Abs. 1 bezeichneten Art infolge grober Fahrlässigkeit unbekannt geblieben, so haftet der Verkäufer, sofern er nicht die Abwesenheit des Fehlers zugesichert hat, nur, wenn er den Fehler arglistig verschwiegen hat.

Falls die Kaufsache fehlerhaft ist, so kann der Käufer vom Vertrag zurücktreten und sich auch die ihm im Zusammenhang mit dem Vertragsabschluß entstandenen Kosten sowie die Kosten des Ein- und Ausbaus der Software ersetzen lassen. Falls die Software mit der Hardware eine Einheit bildet, sie also nicht ohne Nachteil von der Hardware trennbar ist, kann das gesamte EDV-System zurückgegeben werden und auch die Wandlungskosten für die Hardware verlangt werden. Der Nachteil in der Trennung kann darin bestehen, daß zur Hardware kompatible Software nicht oder nur schwer zu beschaffen ist. Oder beide Parteien vereinbaren die Neulieferung einer verbesserten Version oder hatten die mögliche Nachbesserung gleich bei Vertragsabschluß vorgesehen, dann hat der Verkäufer die zum Zwecke der Nachbesserung erforderlichen Aufwendungen, insbesondere Transport-, Arbeits- und Materialkosten, zu tragen. Oder der

3 Die ED V vor dem Jahr 2000 - Chancen

134

Käufer kann den Kaufpreis soweit herabsetzen, wie die Nutzungsdauer durch ein Datumsproblem im Jahr 2000 oder auch schon in den Jahren vorher verkürzt worden ist. § 462 BGB - Wandelung; Minderung Wegen eines Mangels, den der Verkäufer nach den Vorschriften der §§ 459, 460 zu vertreten hat, kann der Käufer Rückgängigmachung des Kaufes (Wandelung) oder Herabsetzung des Kaufpreises (Minderung) verlangen.

Für zugesicherte Eigenschaften, die die Software nicht erfüllt, kann der Käufer Schadensersatz verlangen. Da Software immer mit Dokumentation zu liefern ist, gibt es zahlreiche und durch die Dokumentation zugesicherte Eigenschaften. Da außerdem Software gerne mit den Worten „zukunftssicher", „fortschrittlich" oder „investitionssicher" angepriesen wird, können auch daraus Schlüsse auf die Zusicherung einer Funktionsdauer über das Jahr 2000 hinaus gezogen werden. Es kann auch sein, daß im Zuge der Vertragsverhandlungen und des Vertragsabschlusses Zusicherungen durch den Verkäufer stillschweigend gegeben worden sind; insbesondere ist das dann zu vermuten, wenn der Käufer im Einzelfall eines besonderen Schutzes bedarf. Das wird immer dann der Fall sein, wenn der Käufer hauptsächlich am Nutzen eines Gerätes interessiert ist und nicht in erster Linie Elektronik oder Software erwerben möchte. § 463 BGB - Schadensersatz wegen Nichterfüllung Fehlt der verkauften Sache zur Zeit des Kaufes eine zugesicherte Eigenschaft, so kann der Käufer statt der Wandelung oder der Minderung Schadensersatz wegen Nichterfüllung verlangen. Das gleiche gilt, wenn der Verkäufer einen Fehler arglistig verschwiegen hat.

Dieser Schadensersatz bezieht sich dann auf die folgenden Kostenarten: •

Vertragskosten für den nun aufzulösenden Vertrag

•

Finanzierungskosten der fehlgeschlagenen Beschaffung

•

Ersatz für Aufwendungen (Einbau, Ausbau, Korrekturen)

•

Mehrkosten der Ersatzbeschaffung

Der Schadensersatz kann allerdings nur geltend gemacht werden, wenn die gekaufte Software alsbald zurückgegeben und eine weitere Nutzung der Software ausgeschlossen wird. Ein gleich umfänglicher Schadensersatz ist zu leisten, wenn der Käufer arglistig getäuscht worden ist. Arglist ist schon dann zu vermuten, wenn dem Verkäufer ein schwerer Mangel an einem wichtigen Bestandteil der Software hätte auffallen müssen. Spätestens seit dem 1.1.1997 (B04) sollte jeder Verkäufer wissen, daß Software mit zahlreichen

3.9

Die vertragliche

Haftung der EDV- und

Elektronik-Hersteller

135

oder für das Funktionieren wesentlichen Datumsberechnungen und Jahr 2000 Problemen mit einen schweren Mangel behaftet ist. Über den oben beschriebenen Schadensersatz hinaus wird gehaftet, wenn durch eine sogenannte „Positive Vertragsverletzung" ein Schaden beim Käufer durch den Verkäufer verschuldet wird. Eine Vertragsverletzung durch den Verkäufer kann wieder in Produktmängeln aber auch in versäumten Nebenpflichten wie Beratung oder Untersuchung und Warnung bestehen. Dabei haftet ein Unternehmen auch für die Versäumnisse seiner Mitarbeiter. Solche weiteren Folgeschäden können z.B. sein: •

Personenschäden

•

Beschädigungen anderer Sachen

•

berechtigte Ansprüche Dritter an den Käufer

•

entgangener Gewinn

•

Kosten der Reparaturversuche

Der Umfang der Beratungspflichten bestimmt sich nach dem Wissensgefälle zwischen Verkäufer und Käufer. Darüber hinaus haben durch das Institut der „Positiven Vertragsverletzung" alle Software-Lieferanten die Pflicht, ihre Software auf Jahr 2000 Probleme zu untersuchen und betroffene Kunden zu warnen. Der Verkäufer kann sich bei Software nicht immer erfolgreich auf den Ablauf der Gewährleistungsfrist für die oben beschriebenen Haftungsfälle berufen. Im allgemeinen beginnt diese sechsmonatige Frist ab Übergabe der Ware an den Käufer, doch bei Software erst nach einem störungsfreien Probelauf beim Kunden. Störungen und Mängel sind vom Käufer nach der Entdeckung unverzüglich dem Verkäufer zu melden. Bei Eigenschaften, die nicht sofort geprüft werden können, kann auch eine stillschweigende über sechs Monate hinausgehende Garantie vorliegen oder die Berufung auf die Verjährung durch den Verkäufer kann als rechtsmißbräuchlich gewertet werden. Wenn Käufer und Verkäufer unterschiedlichen Staaten angehören so kann der Käufer innerhalb von zwei Jahren Mängel anzeigen, erst danach beginnt die Gewährleistung. Die Haftung aus den Nebenpflichten der Beratung und Warnung verjährt erst nach 30 Jahren. In allen wesentlichen Punkten helfen Allgemeine Geschäftsbedingungen nicht. Denn das AGB-Gesetz verschafft Treu und Glauben Geltung wider alle diesem kaufmännischen Grundsatz nicht entsprechenden Klauseln. Es können nur einzelvertragliche Regelungen das Risiko des Verkäufers mindern.

136

3.9.2

3

Die ED V vor dem Jahr 2000 -

Chancen

Der Werkvertrag

Bei dem Erwerb sogenannter Individualsoftware, d.h. Software, die in wesentlichen Teilen speziell für einzelne Kunden des erstellenden Unternehmers entwickelt wird, ist normalerweise ein Werkvertrag anzunehmen. Das gilt auch für eine kundenindividuelle Einrichtung, Anpassung und Ergänzung von Standardsoftware. Wenn Verträge über die Umstellung eines Softwaresystems auf Jahr 2000 Fertigkeit geschlossen werden, so stellen diese meistens eine Mischung aus verschiedenen Vertragsformen für die eingesetzten Produkte, die zu erbringenden Programmier- und die Beratungsleistungen dar, einerlei ob ein Vertrag geschlossen wird oder mehrere und auch unabhängig von der Bezeichnung der Verträge. Die Programmierleistungen und die produktbezogenen Leistungen sind nach Werkvertragsrecht zu beurteilen. § 631 BGB - Begriff (1) Durch den Werkvertrag wird der Unternehmer zur Herstellung des versprochenen Werkes, der Besteller zur Entrichtung der vereinbarten Vergütung verpflichtet. (2) Gegenstand des Werkvertrags kann sowohl die Herstellung oder Veränderung einer Sache als ein anderer durch Arbeit oder Dienstleistung herbeizuführender Erfolg sein.

Da der Werkvertrag eine individuelle Leistung vorsieht, werden deren Eigenschaften nur über Zusicherungen festgelegt. Der Fehlerbegriff ist der gleiche wie beim Kaufvertrag. Der Unternehmer hat eine - in bisherigen Softwareprojekten meistens mehrere - Chancen für Nachbesserungen. Wenn sein Aufwand für die Nachbesserung unverhältnismäßig ist, also über einer sog. Opfergrenze liegt, kann er die Nachbesserung verweigern. Diese Opfergrenze setzt die Rechtsprechung allerdings meistens auf das Mehrfache der Vertragssumme. Zu berücksichtigen ist auch, daß der Besteller alle die Kosten der Nachbesserung tragen muß, die sowieso für eine korrekte Erstellung des Werkes angefallen wären. § 633 BGB - Nachbesserung; Mängelbeseitigung (1) Der Unternehmer ist verpflichtet, das Werk so herzustellen, daß es die zugesicherten Eigenschaften hat und nicht mit Fehlern behaftet ist, die den Wert oder die Tauglichkeit zu dem gewöhnlichen oder dem nach dem Vertrage vorausgesetzten Gebrauch aufheben oder mindern. (2) Ist das Werk nicht von dieser Beschaffenheit, so kann der Besteller die Beseitigung des Mangels verlangen. § 476a gilt entsprechend. Der Unternehmer ist berechtigt, die Beseitigung zu verweigern, wenn sie einen unverhältnismäßigen Aufwand erfordert. (3) Ist der Unternehmer mit der Beseitigung des Mangels im Verzuge, so kann der Besteller den Mangel selbst beseitigen und Ersatz der erforderlichen Anwendungen verlangen.

Streiten wird man sich hier um die Angemessenheit der Frist, bis zu der ein Mangel zu beseitigen ist. Ist die Frist erst einmal überschritten und ist der Unternehmer damit im Verzug, so kann der Besteller den Mangel selbst beseitigen lassen auf

3.9

Die vertragliche

Haftung der ED V- und

Elektronik-Hersteller

137

Kosten des Unternehmers. Da auch schon vor Ablieferung Mängel erkennbar sein können, können für die Beseitigung dieser Mängel Fristen gesetzt werden, die knapp hinter dem Ablieferungszeitpunkt liegen. Da Jahr 2000 Projekte, die jetzt erst begonnen werden, unter einem starken Zeitdruck stehen, ist also eine laufende Projektüberwachung nötig, um Mängel unverzüglich zu melden und den Werkunternehmern dann ausreichend knappe Fristen setzen zu können. § 634 BGB - Wandelung; Minderung (1) Z u r Beseitigung eines Mangels der im § 6 3 3 bezeichneten Art kann der Besteller dem Unternehmer eine angemessene Frist mit der Erklärung bestimmen, daß er die Beseitigung des Mangels nach dem Ablaufe der Frist ablehne. Zeigt sich schon vor der Ablieferung des Werkes ein Mangel, so kann der Besteller die Frist sofort bestimmen; die Frist muß so bemessen werden, daß sie nicht vor der für die Ablieferung bestimmten Frist abläuft. Nach dem Ablaufe der Frist kann der Besteller Rückgängigmachung des Vertrags (Wandelung) oder Herabsetzung der Vergütung (Minderung) verlangen, wenn nicht der Mangel rechtzeitig beseitigt worden ist; der Anspruch auf Beseitigung des Mangels ist ausgeschlossen. (2) Der Bestimmung einer Frist bedarf es nicht, wenn die Beseitigung des Mangels unmöglich ist oder von dem Unternehmer verweigert wird oder wenn die sofortige Geltendmachung des Anspruchs auf Wandelung oder auf Minderung durch ein besonderes Interesse des Bestellers gerechtfertigt wird. (3) Die Wandelung ist ausgeschlossen, wenn der Mangel den Wert oder die Tauglichkeit des Werkes nur unerheblich mindert. (4) A u f die Wandelung und die Minderung finden die für den Kauf geltenden Vorschriften der §§ 465 bis 467, 469 bis 475 entsprechende Anwendung.

Für Wandelung und Minderung beim Werkvertrag gelten die entsprechenden Ausführungen zum Kaufvertrag, einschließlich Schadensersatz für Zusicherungen oder bei Arglist und aus positiver Vertragsverletzung. Diese Haftungsfolgen können schon eintreten, wenn eine der Nachbesserungsfristen abgelaufen ist und der Unternehmer den Mangel und seinen Fortbestand zu vertreten hat. Dabei ist die Frage des Verschuldens nicht erheblich sondern nur die Frage nach dem Ursprung des Fehlers. Auch bei einem Werkvertrag kann sich der Verkäufer nicht immer erfolgreich auf den Ablauf der sechsmonatigen Gewährleistungsfrist für die oben beschriebenen Haftungsfälle berufen. Im allgemeinen beginnt diese Frist ab Abnahme des Werkes vom Besteller. Doch die Abnahme wird erst nach Ablauf der Zeit erfolgen, die zusätzlich zur Beseitigung aller Mängel benötigt wird. Durch die Zusammenarbeit zwischen Unternehmer und Besteller, die bei der Werkerstellung enger ist als bei einer Kaufabwicklung, wird die Rechtsprechung bei verdeckten Mängeln eher Arglist vermuten und damit die Haftung wieder aufleben lassen. Es gibt kein internationales Werkvertragsrecht, so daß, wenn Käufer und Verkäufer unterschiedlichen Staaten angehören, das jeweils vereinbarte nationale Recht anzuwenden ist.

138

3 Die ED V vor dem Jahr 2000 - Chancen

Die Haftung aus allen Arten der positiven Vertragsverletzung - im Unterschied zum Kaufvertrag - verjährt erst nach 30 Jahren. In allen wesentlichen Punkten helfen dem Unternehmer Allgemeine Geschäftsbedingungen wieder nicht.

3.9.3

Der Dauerschuldvertrag

Serviceverträge für Hardware und Pflegeverträge für Software begründen eine Leistungsschuld beim Lieferanten, die über den vereinbarten Zeitraum dauernd abzutragen ist. Oft sind mit der Lieferung eines EDV-Systems Service und Pflegeverträge verbunden oder die Lieferung eines Softwareproduktes erfolgt mit einem Pflegevertrag oder Service und Pflege erfolgen über Dritte. Auch hier sind wieder die verschiedenen Vertragsformen zu trennen, falls nur ein Vertragstext vorliegt. Bei Service- und Pflegeverträgen werden als Leistungen oft genannt: •

Instandsetzung nach Auftreten von Fehlern

•

die Lieferung von Ersatzteilen oder neuer Versionen

•

die Bereitstellung von Kommunikationswegen für Mängelanzeige und Beratung

Bei der Hardware-Wartung sind zusätzlich über DIN 31051 Inspektion und vorbeugende Wartung vorgeschrieben. Für die genannten Leistungsarten sind die Anforderungen im Einzelnen zu bestimmen und auch Leistungsstörungen jeweilig im Einzelnen anzumahnen. Falls die Fehlerbeseitigung vereinbart ist, so schuldet der Lieferant auch Systeme, Hardware oder Software ohne Jahr 2000 Problem. Allerdings ist genau zu prüfen, ob er nur das Bemühen um Fehlerfreiheit schuldet oder auch den Erfolg seiner Bemühungen. Wenn eine neue Version eines Programms oder eine Ersatzteil geliefert wird, so beginnt damit eine neue Gewährleistung nach dem Recht des Kaufvertrages oder des Werkvertrages, und zwar je nach den Bestimmungen im Vertrag für das ganze System oder nur für das ausgetauschte Teil oder Programm. Eine Beratung in wesentlichen Fragen schließt auch die damit verbundene Haftung ein.

3.9 Die vertragliche Haftung der ED V- und Elektronik-Hersteller

139

§ 286 BGB - Verzugsschaden (1) Der Schuldner hat dem Gläubiger den durch den Verzug entstehenden Schaden zu ersetzen. (2) Hat die Leistung infolge des Verzugs für den Gläubiger kein Interesse, so kann dieser unter Ablehnung der Leistung Schadensersatz wegen Nichterfüllung verlangen. Die für das vertragsmäßige Rücktrittsrecht geltenden Vorschriften der §§ 346 bis 356 finden entsprechende Anwendung.

Wenn nach Leistungsstörung und Mahnung ein Lieferant in Verzug gerät, so kann der Kunde Schadensersatz wegen Verzug oder nach dem Ablauf einer weiteren Frist auch Schadensersatz wegen Nichterfüllung verlangen. Für den Kunden sind also Pflege- und Serviceverträge mit zahlreichen Rechten verbunden, wenn er sie nur wahrzunehmen weiß. Für den Lieferanten bedeuten diese Verträge, je näher das Jahr 2000 rückt, ein desto höheres rechtliches Risiko. Daher ist für den Lieferanten zu überlegen, ob er nicht durch eine fristgerechte und auch rechtzeitig vor ersten Datumsproblemen liegende Kündigung, möglicherweise auch in der moderaten Form einer Änderungskündigung, sein Risiko deutlich reduzieren kann. In allen wesentlichen Punkten helfen dem Lieferanten Allgemeine Geschäftsbedingungen wiederum nicht, da die Einzelleistungen der Dauerschuld entsprechend Werkvertrag gewertet werden.

3.9.4

Der Mietvertrag

Auch hier ist erst zu prüfen, ob ein mit „Kaufvertrag" überschriebener Text nicht tatsächlich als Mietvertrag zu werten ist. Insbesondere wenn laufende Zahlungen zu leisten sind oder die Summe der Zahlungen für die sogenannte „Wartung" schon nach einem Jahr über dem sogenannten „Kaufpreis" liegt oder die Softwarenutzung an eine beschränkte Nutzungsdauer der Hardware gekoppelt ist, wird man Miete zu vermuten. Gemietet werden kann wieder Hardware, Software oder eine Kombination beider in einem EDV-System. Falls auf einen Mietvertrag erkannt wird, so hat der Mieter alle Rechte aus einem Dauerschuldvertrag, da der Vermieter ihm die dauernde Gebrauchstauglichkeit schuldet, und darüber hinausgehende Rechte wie etwa Mietminderung und Selbsthilfe, die er auch noch miteinander kombinieren darf.

3 Die ED V vor dem Jahr 2000 -

140

Chancen

§ 538 BGB - Schadensersatzpflicht des Vermieters (1) Ist ein Mangel der im § 537 bezeichneten Art bei dem Abschluß des Vertrages vorhanden oder entsteht ein solcher Mangel später infolge eines Umstandes, den der Vermieter zu vertreten hat, oder kommt der Vermieter mit der Beseitigung eines Mangels in Verzug, so kann der Mieter unbeschadet der im § 537 bestimmten Rechte Schadensersatz wegen Nichterfüllung verlangen. (2) Im Falle des Verzugs des Vermieters kann der Mieter den Mangel selbst beseitigen und Ersatz der erforderlichen Aufwendungen verlangen.

Wenn sich der Vermieter der Haftung für Mängel entziehen will, hat er außer der rechtzeitigen Mangelbeseitigung zwei Chancen. Seine Opfergrenze bei einem Mietvertrag liegt nur beim Zeitwert der Mietsache zuzüglich an ihn geleisteten Ersatz durch Vorlieferanten und Versicherungen. Die andere Chance liegt wieder in einer fristgerechten und auch rechtzeitig vor ersten Datumsproblemen liegenden Kündigung. Hier helfen dem Vermieter die Allgemeine Geschäftsbedingungen nur insoweit, als er seine Haftung auf eigenes Verschulden begrenzen kann. Allerdings haftet er in allen wesentlichen Punkten auch für leichte Fahrlässigkeit.

3.9.5

Der Leasingvertrag

Ein Leasingvertrag kann als Kaufvertrag oder als Mietvertrag ausgestaltet sein. Der Leasinggeber überträgt darin alle oder einen Teil seiner Rechte aus seinem Kauf von einem Dritten auf den Leasingnehmer gegen laufende Zahlung. Daher kann der Leasingvertrag zusätzlich auch ein Mietverhältnis zwischen Leasingnehmer und Leasinggeber begründen. Ansprüche auf Mängelbeseitigung müssen alleine vom Leasingnehmer oder im Zusammenwirken mit dem Leasinggeber gegen dessen Verkäufer durchgesetzt werden. Gerade bei diesem Vertragstyp ist also eine genauere rechtliche Prüfung erforderlich.

3.9.6

Der Pachtvertrag

Auch hier ist erst zu prüfen, ob ein mit „Werkvertrag" überschriebener Text nicht tatsächlich als Pachtvertrag zu werten ist. Das wird insbesondere dann angenommen, wenn es um individuell erstellte Programmen für die Steuerung von Produktionsvorgängen geht und die Erstellung der Programme eine besondere geistige Leistung darstellt. Die Steuerungsprogramme sind dann mit einer Erfindung zu vergleichen, die zur Ausnutzung in der Produktion überlassen wird und der Vertrag ist damit eigentlich ein Know-how-Vertrag, der nach den Regeln der Pacht abgewickelt wird. Der Autor des Programms haftet dann über die gesamte Nutzungszeit und auch noch sechs Monate nach Ende der Nutzung für die Erfüllung zugesicherter Eigenschaften.

3.9

Die vertragliche

Haftung der EDV- und

Elektronik-Hersteller

141

§ 581 BGB - Grundpflichten (1) Durch den Pachtvertrag wird der Verpächter verpflichtet, dem Pächter den Gebrauch des verpachteten Gegenstandes und den Genuß der Früchte, soweit sie nach den Regeln einer ordnungsgemäßen Wirtschaft als Ertrag anzusehen sind, während der Pachtzeit zu gewähren. Der Pächter ist verpflichtet, dem Verpächter den vereinbarten Pachtzins zu entrichten. (2) A u f die Pacht mit Ausnahme der Landpacht sind, soweit sich nicht aus den § § 5 8 2 bis 584b etwas anderes ergibt, die Vorschriften über die Miete entsprechend anzuwenden.

3.9.7

Der Rechtsanwalt im Jahr 2000 Projekt

Beim Anwender beginnt die Auseinandersetzung mit Haftungsfragen bei der Bestandsaufnahme der EDV-Systeme. Dabei wird man selbst entwickelte Software von der erworbenen unterscheiden. Software kann auch im Zusammenhang mit EDV-Systemen und Geräten erworben werden. Dann ist für die nicht selbst entwickelte Software eine Bestandsaufnahme der EDV-Verträge durchzuführen. Es ist jedesmal zu prüfen, welcher Vertragstyp vorliegt. Dabei ist nicht die Überschrift über den Vertragswerk maßgeblich, sondern der Inhalt des Vertragswerkes und die tatsächliche Abwicklung des Vertrages. Oft kann erst eine ins Einzelne gehende Prüfung durch einen Rechtsanwalt über den Vertragstyp entscheiden. Unter diesem Vorbehalt stehen alle oben gemachten Ausführungen zu den einzelnen Vertragstypen. In entsprechender Weise sind von einem Rechtsanwalt alle laufenden und schon abgeschlossenen Verträge über EDV-Produkte und EDV-Leistungen bei Hersteller und Händler zu untersuchen. Selbst wenn keine Programme mit Jahr 2000 Problemen vertraglich erwähnt sind, ist zu überlegen, wie gegenüber Kundenanfragen die Problemfreiheit belegt werden kann, und es ist auch zu überlegen, ob und in welcher Weise eine Zusicherung darüber gegeben werden kann. Von beiden Seiten eines Vertrages kann dann versucht werden, rechtliche Verbesserungen zu erreichen, durch einvernehmliche Vertragsänderungen oder durch Änderungskündigungen oder durch das Einlegen von Rechtsmitteln. Insbesondere die rechtzeitige und korrekte Rüge von Mängeln ist auf Kundenseite zu beachten. Auf Lieferantenseite wird man die Kündigungsrechte und die Kündigungsfristen genauer untersuchen lassen. Nach der Vertragsanalyse und dem Aufzeigen von Vertragsverbesserungen kann sich der Rechtsanwalt um die korrekte Vertragsdurchführung kümmern. Dabei sind insbesondere die Kommunikationswege innerhalb eines Unternehmens und gegenüber Dritten so zu ordnen, das allen Beteiligten klar ist, wer zu welcher Frage rechtsverbindliche Erklärungen abgeben darf.

142

3 Die ED V vor dem Jahr 2000 - Chancen

3.9.8

Was folgt daraus?

=> Durch die Bestandsaufnahme der EDV-Verträge lassen sich Haftungslücken beim Kunden oder Haftungsrisiken beim Lieferanten aufspüren. => Insbesondere Service- und Pflegeverträge sowie Miet- und Pachtverträge können große Risiken für EDV-Lieferanten bergen. => Doch selbst wenn ein Haftungsfall eintritt, kann der Anwender nicht sicher sein, daß er sich rechtlich durchsetzt, daß alle Kosten belegbar sind und daß alle Folgekosten anerkannt werden. => Dann wird es auch noch höchst unsicher sein, ob sein Lieferant über die nötige Finanzkraft für einen vollen Schadenersatz verfügt, insbesondere wenn dieser von mehr als einer Seite in Anspruch genommen wird.

3.10

Kunden und Lieferanten

•

Bestandsaufnahme aller Außenbeziehungen

•

Phasen eines Jahr 2000 Projektes zwischen Unternehmen

•

Kooperation mir dem Wettbewerb

•

Anwendervereinigungen

•

Was folgt daraus?

Der Zweck eines Unternehmens erschöpft sich sicherlich nicht darin, EDV und Elektronik einzusetzen. Was hilft es einem Unternehmen also, wenn es für den eigenen EDV-Einsatz die Jahr 2000 Fähigkeit herstellt, aber der Warenverkehr oder der Zahlungsverkehr von und zu Lieferanten und Kunden durch deren Jahr 2000 Probleme ins Stocken gerät. Daher sollten auch die Kunden und Lieferanten eines Unternehmens in die Herstellung der Jahr 2000 Fähigkeit einbezogen werden.

3.10

Kunden und Lieferanten

Einrichtung des Jahr 2000 Projektrahmens

Cüf cter> und Lieferanten!

/ System Management

143

144

3.10.1

3 Die ED V vor dem Jahr 2000 - Chancen

Bestandsaufnahme aller Außenbeziehungen

Ebenso wie Anwendungen und EDV-Systeme sowie Verträge mit EDV- und Elektronik-Herstellern zu erfassen und bewerten sind, gilt es auch die ständigen, betrieblichen Kontakte zu Kunden, Lieferanten und öffentlichen Einrichtungen unter dem Aspekt der Jahr 2000 Fähigkeit zu betrachten. Manche meinen, es würde ausreichen, sich um die Außenkontakte mit elektronischer Schnittstelle zu kümmern. Diese Herangehensweise vernachlässigt die wirtschaftlichen und finanziellen Beziehungen, die zwar über das beschriebene Papier abgewickelt werden, aber trotzdem von entscheidender Bedeutung sein können. Manche meinen darüber hinaus, wenn man sich bei elektronischen Kontakten auf die Interpretation einer zweistelligen Jahreszahl (Fenstertechnik) geeinigt hat, wäre die Jahr 2000 Fähigkeit der Kommunikation über diese Schnittstelle erreicht. Sie vergessen dabei, daß die Jahr 2000 Probleme auch zu einer Verfälschung von durchaus richtig formatierten Jahreszahlen und auch zu einer Verfälschung von weiteren Daten führen kann, die sich aus einer Datumsberechnung ergeben. Man kommt also nicht umhin, alle Außenbeziehungen aufzunehmen, die von wirtschaftlicher Bedeutung sind. Insbesondere sollte ein Fertigungsunternehmen die gesamte logistische Kette von seinen Vormateriallieferanten über den Großhandel bis zum Einzelhandel unter die Lupe nehmen. Wenn es gelingt, über die gesamte Kette die Jahr 2000 Fähigkeit herzustellen, ergibt sich daraus in den nächsten Jahren ein möglicherweise bedeutsamer wirtschaftlicher Vorteil gegenüber der Konkurrenz. Ein bescheideneres Ziel kann für große Unternehmen darin liegen, ihre direkten Lieferanten dazu zu befähigen wenigstens bei der elektronischen Kommunikation mit ihnen keine Datumsfehler zu machen. Heute wird man den Lieferanten möglicherweise noch dabei helfen, morgen schon kann darin ein entscheidendes Kriterium für die Auswahl eines Lieferanten liegen. Ähnlich kann sich eine großes Unternehmen gegenüber seinen direkten Kunden verhalten, wenn diese als Wiederverkäufer oder Franchise-Partner von ihm abhängig sind. Über die Beziehungen zu Kunden und Lieferanten gewinnt das Jahr 2000 Thema für alle Import oder Export treibenden Unternehmen eine internationale Dimension. Daher kann es einem solchen Unternehmen nicht egal sein, wie das Jahr 2000 Thema im Ausland behandelt wird. Umgekehrt kommen auch schon Abgesandte aus dem Ausland, um bei hiesigen Unternehmen den Stand des Jahr 2000 Projektes zu überprüfen. Aber es mag auch erfreuliche Nachrichten, zumindest aus dem fernen Ausland, geben. Falls dort für kommerzielle und technische Vorgänge kein christlicher Kalender genutzt wird, haben diese Handelspartner in den nächsten drei Jahren keinen Jahrhundertwechsel und damit auch kein internes Datumsproblem.

3.10 Kunden und Lieferanten

145

3.10.2 Phasen eines Jahr 2000 Projektes zwischen Unternehmen Wenn ein Unternehmen als Teil einer logistischen Kette oder zusammen mit Lieferanten oder Kunden die beiderseits bestehenden Jahr 2000 Probleme bearbeiten möchte, so empfiehlt es sich, ebenso wie bei internen Projekten, Schritt für Schritt vorzugehen. In der ersten Phase geht es darum, durch Gespräche und Vorträge die Aufmerksamkeit der Marktpartner auf das Jahr 2000 Problem im Allgemeinen zu lenken. Wenn dann ein interner Jahr 2000 Prozeß angestoßen ist, sollten die jeweiligen Jahr 2000 Projektverantwortlichen ihre Erwartungen austauschen und zu Vereinbarungen über die weitere Vorgehensweise gelangen. In der zweiten Phase wird man die Beziehungen im Warenverkehr und im Zahlungsverkehr mit den damit zusammenhängenden vertragsrechtlichen und versicherungsrechtlichen Aspekten aufnehmen. Man wird sich auch über den Umfang der gegenseitigen Hilfe verständigen, ob sie nur über Informationen oder auch über Dienstleistungen erfolgt und ob sie sich nur auf die gemeinsamen, wirtschaftlichen Schnittstellen bezieht oder auch auf die internen Prozesse. In der dritten Phase wird man die Ergebnisse der Analyse der EDV-Systeme austauschen und harmonisieren. Dann geht es darum, sich unter den Lösungsalternativen zu entscheiden und diese Entscheidungen und die darauf aufbauenden Projektpläne untereinander abzustimmen. In der vierten Phase sollten Statusberichten über den Fortgang der Arbeiten ausgetauscht werden. Falls auf beiden Seiten einer Schnittstelle die entsprechenden EDV-Systeme umgestellt und jeweils für sich getestet sind, kann man daran gehen, gemeinsame Tests durchzufuhren. In der fünften Phase kann ein wechselseitiger Review der umgestellten Systeme vereinbart werden. Auf jeden Fall sollte eine gemeinsame Planung für den Notfall durchgeführt werden, also für Datumsfehler, die in umgestellten Systemen doch noch auftreten, und für Systeme, deren Umstellung sich verzögert, und für die Systeme, die bewußt zurückgestellt wurden. Spezielle Kundenbeziehungen haben Banken und Versicherungen zu bearbeiten. Jede Investition in ein Unternehmen oder auch jede Kreditvergabe an ein Unternehmen ist mit einem Risiko verbunden. Das gleiche gilt für Versicherungen auf die Existenz eines Unternehmens, z.B. Pensionssicherung, oder seine Zahlungsfähigkeit, z.B. Kreditsicherung. Daher liegt es auch im eigenen Interesse einer Bank oder Versicherung, mit ihren Versicherungsnehmern oder ihren wichtigen Kreditkunden ein gemeinsames Jahr 2000 Projekt mit einem analogen Phasenverlauf abzuwickeln:

146

3 Die ED V vor dem Jahr 2000 - Chancen

•

Aufmerksamkeit schaffen

•

Beziehungen klären

•

Lösungen planen

•

Projekt verfolgen

•

Sicherungen einbauen

In ähnlicher Weise könnten auch Zentralbanken mit ihren Bankinstituten und Rückversicherer mit ihren Versicherungskunden umgehen. Eventuell werden auch Aufsichtsgremien für Banken und Versicherungen ein entsprechendes Modell entwickeln.

3.10.3

Kooperation mit dem Wettbewerber

In bestimmten Branchen kann es notwendig werden, in der Jahr 2000 Frage auch mit Unternehmen zusammenzuarbeiten, die mit dem eigenen Unternehmen im Wettbewerb stehen. Zum Beispiel haben sich Kreditkartenorganisationen weltweit untereinander und mit den Herstellern von Geldausgabeautomaten darauf verständigt, wie Kreditkarten mit einer zweistelligen Jahreszahl zu autorisieren sind. Ebenso wie es ein gemeinsames Interesse gegenüber Automatenhersteller geben kann, gibt es schon lange gemeinsame Interessen von Kunden eines EDVHerstellers, die sich in der Existenz sogenannten Nutzergruppen ausdrücken. Daher sollten alle EDV-Nutzergruppen auch das Jahr 2000 Thema aufnehmen, um ihren Hersteller zu besonderen Anstrengungen in dieser Hinsicht zu bewegen. In allen Bereichen, wo der elektronische Austausch unter Wettbewerbern umfangreich und von großer wirtschaftlicher Bedeutung ist, wie bei Finanzdienstleistungen oder Transport und Verkehr, bietet es sich an, auch für die Bewältigung der Jahr 2000 Probleme in geeigneter Weise zu kooperieren. Ein besondere Art der Kooperation unter Wettbewerbern liegt vor, wenn ein Unternehmensteil verkauft werden soll, weil die Umstellung auf die Jahr 2000 Fähigkeit nicht mehr rechtzeitig durchgeführt werden kann. Wenn Unternehmen fusionieren oder ein Unternehmen gekauft wird, sollte also auch daran gedacht werden, wie die Jahr 2000 Fähigkeit des neu zu schaffenden, gemeinsamen Unternehmens hergestellt werden kann. In den USA wird auch schon diskutiert, ob sich nicht einzelne Unternehmen ohne Jahr 2000 Fähigkeit dazu entschließen werden, ein anderes gleichartiges Unternehmen mit Jahr 2000 Fähigkeit „freundlich" oder auch „feindlich", d.h. ohne Zustimmung des Managements, zu übernehmen.

3.10

Kunden und Lieferanten

3.10.4

147

Anwendervereinigungen

Die Lösungsanbieter zum Jahr 2000 Problem haben sich schon in verschiedenster Form zusammengeschlossen, um gemeinsam Projekte abzuwickeln oder gemeinsame Marketingaktionen durchzuführen. Auf Anwenderseite gibt es zur Zeit keine entsprechende Aktivität. Dabei würde der organisierte Informationsaustausch unter Anwendern helfen, die laufenden Jahr 2000 Projekte effektiver durchzuführen, und der Zusammenschluß von Anwendern würde den EDV- und Elektronik-Herstellern signalisieren, daß die rechtzeitige Lieferung von Jahr 2000 fähigen Systemen eine besondere Bedeutung für ihre Kundschaft besitzt. In Deutschland existiert zudem keine Organisation wie die Taskforce 2000 in Großbritannien, die mit politischer Unterstützung das Jahr 2000 Problem als ein Problem ansprechen will, von dem die ganze Gesellschaft betroffen ist. Immerhin gibt es in der Schweiz eine sehr aktive Gruppe von Anwendern, die sich unter der Leitung von Herrn Prof. Dr. Gerhard Knolmayer, Direktor des Institutes für Wirtschaftsinformatik der Universität Bern, intensiv über Fragen der Technik und des Managements innerhalb von Jahr 2000 Projekten austauscht. Die Gruppe nennt sich „CHIG2000 - Swiss Interest Group in Solving the Year 2000 Problem", Schweizer Interessengruppe zur Lösung des Jahr 2000 Problems. Die Ziele der CHIG2000 sind: •

Das Bewußtsein um das Jahr 2000-Problem in der Gesellschaft im allgemeinen, im Management und im Informatikbereich von Unternehmen im speziellen zu fordern,

•

Bestimmen und Anwenden von bestmöglichen Lösungen für das Jahr 2000Problem,

•

Erleichtern des Austausches von Informationen zwischen Jahr 2000 Projektmanagern im allgemeinen und speziell von intern entwickelten Verfahren, Dokumenten und Werkzeugen,

•

Verbreiten von Informationen, die von Anwendern, User Groups und Anbietern von Jahr 2000 Lösungen zur Verfügung gestellt werden,

•

Beratung von kleinen und mittleren Unternehmen im Hinblick auf die Lösung des Jahr 2000 Problems.

Die Themen ihrer bisherigen, insgesamt fünf Treffen im Laufe eines Jahres waren: •

Das Internet als Informationsquelle

•

Projektmanagement Infrastruktur

•

Auswahlkriterien für Jahr 2000-Werkzeuge und Anbieter

•

Erfahrungen mit der Evaluation von Werkzeugen für Jahr 2000-Projekte

148

3 Die ED V vor dem Jahr 2000 - Chancen

•

Testen der Jahr 2000-Fähigkeit von Informationssystemen

•

Vorgehensweisen beim Test von Jahr 2000-Lösungen

Detaillierte Informationen kann man finden unter /y ear2000.html.

http://www.ie.iwi.unibe.ch/zobis

Inspiriert von diesen Aktivitäten in der Schweiz versucht der Autor eine ähnliche in Gruppe in Deutschland aufzubauen. Bei einem ersten Treffen hat man sich den Namen „Aktion 2000 - Die deutsche Anwendervereinigung zum Jahr 2000 Problem in der EDV" gegeben sowie auf die folgenden Ziele geeinigt: •

Entwicklung von öffentlicher Aufmerksamkeit für das Jahr 2000 Problem

•

Ansprache von Entscheidungsträgern in Verwaltung, Wirtschaft und Betrieben

•

Information über alle Aspekte des Jahr 2000 Problems

•

Darstellung vorbildlicher Lösungen des Problems

•

Austausch von Erfahrungen und Vorgehensmodellen insbesondere unter den Jahr 2000 Projektleitern

•

Organisation von geeigneten Unterstützungsmaßnahmen

•

Kritische Würdigung der Angebote von Jahr 2000 Dienstleistungsfirmen

•

Austausch mit Jahr 2000 Vereinigungen in anderen Ländern

Die Themen des ersten Treffens waren: •

Die Jahr 2000-Studie von softlab

•

Initiative 2000 der Lösungsanbieter

•

Software-Bewertung bei Hersteller und Anwender

•

Wer haftet für Software-Fehler?

Detaillierte Informationen kann man unter http://www.jahr2000.com

3.10.5

finden.

Was folgt daraus?

=> Anzustreben ist die Jahr 2000 Fähigkeit aller wichtigen Marktpartner eines Unternehmens. => Die Entwicklung der Jahr 2000 Fähigkeit sollten so organisiert werden, daß sie gemeinsam überprüft werden kann. => Dieser Prozeß sollte möglichst bis zum Ende des Jahres 1998 abgeschlossen werden.

4

Die EDV im Jahr 2000 Gefahren

•

Die Kalenderkatastrophen

•

Der Katastrophenkalender

•

Der Jahrhundertübergang

•

Was folgt daraus?

Die große Gefahr im Jahr 2000 und teilweise schon davor besteht natürlich darin, daß die kleinen und großen Katastrophen eintreten werden, die schon häufig vorausgesagt wurden. Wenn sie eintreten, werden sie sehr viele Unternehmen und Institutionen gleichzeitig heimsuchen und sich zudem noch in mehreren Varianten über mehr als ein Jahr wiederholen. Schon heute kann vorausgesagt werden, wie sich die Lage in New York und London in den letzten Wochen des Jahres 1999 und in den ersten Wochen des Jahres 2000 entwickeln wird.

4.1

Die Kalenderkatastrophen

Die Datumsänderungen entsprechend dem Kalender werden Softwareprobleme auslösen, die so deutlich wie selten das zentrale Gesetz von Murphy über komplexe technische Systeme belegen werden: „If anything can possibly go wrong, it will, at the worst possible time." „Wenn irgend etwas möglicherweise schief gehen kann, dann wird es das tun, und zwar zum ungünstigsten von allen möglichen Zeitpunkten." Auch die Gärtner Group erwartet Ähnliches: „Without corrective measures, 90 percent of applications and systems will fail by 1999 (0.9 probability)." (G01) „Ohne Korrekturmaßnahmen werden 90 Prozent aller Anwendungen und Systeme bis Ende 1999 Fehler produzieren (0,9 Wahrscheinlichkeit)."

150

4 Die ED V im Jahr 2000 - Gefahren

Alle Jahr 2000 Projekte zielen natürlich darauf ab, diese Ausfalle zu verhindern oder wenigstens in Anzahl und Auswirkungen zu beschränken. Doch oft ersetzt die Planung nur den Zufall durch den Irrtum. Auch diese Meinung wird von der Gärtner Group bestätigt: „By the end of 1999, less than 70 percent of IS organizations will be year 2000 compliant in mission-critical customer-focused, external applications (0.7 probability)." (G01) „Bis Ende 1999 werden weniger als 70 Prozent aller IS Organisationen die Jahr 2000 Fähigkeit erreichen für unternehmenskritische, kundenzentrierte, externe Anwendungen (0,7 Wahrscheinlichkeit). Zu den glücklichen Unternehmen mit Jahr 2000 Fähigkeit werden vor allem große Unternehmen gehören. Doch gerade dort gibt es auch eine Fülle von weniger kritischen, Mitarbeiter oder Lieferanten orientierten oder internen Anwendungen für die mit hoher Wahrscheinlichkeit dieser Prozentsatz mit Jahr 2000 Fähigkeit nicht erreicht werden wird. Außerdem sind die meisten großen Unternehmen bis Ende 1998 voll beschäftigt mit ihren Host basierten Anwendungen. PC und Netzwerke, elektronische Geräte, Prozeßsteuerungen, Gebäude- und Kommunikationstechnik werden erst danach umfassend untersucht werden. Nur eine Minderheit von Unternehmen organisiert heute die Jahr 2000 Fähigkeit über alle logistischen Ketten hinweg, in die sie eingebettet sind. Kaum einer kümmert sich um Schnittstellen zu Behörden und Partnern. Noch weniger denken daran, wie sie nach Erreichen ihrer Jahr 2000 Fähigkeit mit der Fülle der zusätzlichen Aufträge zurecht kommen können, die sie durch Ausfall ihrer Konkurrenten erhalten werden. Die Ausfalle, die zu erwarten sind, können offensichtlich sein, wie das abnormale Ende eines Programms oder das Ende der Funktionsfahigkeit eines EDV-Systems. Daraus können in der Produktion oder beim Transport Abschaltungen und Alarme resultieren. Viele Alarme werden auch falsch sein und die Unterscheidung zwischen echten und falschen Alarmen behindern. Oder die Ausfälle sind weniger offensichtlich, erzeugen aber dafür lang andauernde Auswirkungen, indem Daten ungültig werden oder noch schlimmer, indem Daten verfälscht werden. Solange es nur um Ausfälle geht, mag sich mancher Anwender damit beruhigen, daß er seine beleg-gestützte Anwendung im Batch und nicht online und nicht papierlos fährt. Beendete Programme können dann wieder gestartet und für erneuerte EDV-Systeme können Daten von den Belegen abgelesen und nachgetragen werden. Doch was ist mit Datenbeständen, die gerade durch Batch-Programme mit ihren vielen Datenänderungen massiv verfälscht werden können?

4.1 Die Kalenderkatastrophen

151

Die Qualität der gespeicherten Daten und der Zugriff auf sie, muß gewährleistet sein: „Nach einer Untersuchung der deutschen Versicherungswirtschaft beträgt die Überlebensdauer eines sehr stark DV-basierten Unternehmens, das nicht auf seine gespeicherten Daten zugreifen kann, maximal 20 Tage. Dann treten irreparable Schäden auf." (S05) Für verschiedene Unternehmensgrößen werden geschäftlichen Ausfälle von unterschiedlichem Umfang erwartet. Große Unternehmen besitzen viele EDV-Systeme aber auch genügend Mittel, das Jahr 2000 Problem zu beherrschen, daher ist hier eine Ausfallrate für die Fortune 500 von 1% (nach J02) zu erwarten. Kleine Unternehmen operieren meistens wenig DV-basiert und nutzen dann auch Standardprogramme, andererseits kümmern sie sich besonders wenig um Jahr 2000 Probleme, also wird eine Ausfallrate von 3% (nach J02) erwartet, die allerdings nur schwer dargestellt werden kann. Der Anteil der durch die üblichen Probleme verursachten Geschäftsaufgaben kleiner Unternehmen liegt in den ersten drei Jahren weit darüber. Die mittleren Unternehmen stellen das größte volkswirtschaftliche Problem dar: „Mid-sized corporations with from about 1,000 to 10,000 total employees have historically shown a distressing tendency to utilize quite a lot of software, but to be only marginally competent in how they build and maintain this software. ... I place the failure probability of mid-sized U.S. corporations at about 5% to 7%. There are about 30,000 companies in the „mid sized" range in the United States, and a 5% to 7% business failure rate would mean that from 1500 to perhaps 2100 companies might close or file for bankruptcy as a result of the year 2000 problem." (J02) „Mittelgroße Unternehmen mit etwa 1000 bis 10000 insgesamt Beschäftigten haben in der Vergangenheit eine selbstzerstörerische Tendenz gezeigt, ziemlich viel Software einzusetzen, aber nur wenig befähigt zu sein, diese Software zu entwickeln und zu warten. ... Ich setze die Ausfallwahrscheinlichkeit für mittelgroße US Unternehmen auf etwa 5% bis 7%. Es gibt ungefähr 30 000 Unternehmen dieser Größenordnung in den Vereinigten Staaten und ein geschäftlicher Fehlschlag für 5% bis 7% würde bedeuten, daß 1500 bis vielleicht 2100 Unternehmen schließen oder Bankrott gehen würden als ein Ergebnis des Jahr 2000 Problems."

4 Die ED V im Jahr 2000-

152

4.2

Gefahren

Der Katastrophenkalender

Die möglichen Katastrophen sind am Kalenderverlauf entlang zu erwarten, da sie durch den Fortschritt der kalendarischen Zeit ausgelöst werden. Das Jahr 2000 ist ein Schaltjahr. Die Nichterkennung des letzten Schaltjahres, nämlich 1996, hat bei einigen Unternehmen aus allen Teilen der Erde schon Schäden in Höhe von Millionen D M verursacht. Forschungsinstitute für Computerviren warnen schon jetzt vor besonders bösartigen Viren zum Jahrhundertwechsel. Außerdem ist auch damit zu rechnen, daß bisher harmlose oder schon ruhende Viren wieder aktiv werden, da sie eine ebenso fehlerhafte Datumsverarbeitung besitzen können wie normale Anwendungsprogramme. Tabelle 10: Der Katastrophenkalender vor 1998 und danach ab 1.1.1998

Anwendungen, die Datumswerte künftiger Jahre fehlerhaft verarbeiten Anwendungen, die die Jahreszahl „98" mit anderer Bedeutung nutzen

ab 1.1.1999

Anwendungen, die die Jahreszahl „99" mit anderer Bedeutung nutzen

am 21.8.1999

Überlauf des Zeitzählers in Global Positioning Systemen (GPS) älterer Bauart

ab 9.9.1999

Anwendungen, die das Datum „9999" mit anderer Bedeutung nutzen

ab 31.12.1999

Anwendungen, die das Datum „991231" oder „99365" mit anderer Bedeutung nutzen Beginn des letzten Jahres des 20. Jahrhunderts und des 2. Jahrtausends: Virengefahr

am 1.1.2000 am 1.1.2000

Überlauf des Zeitzählers in bestimmten Geräten

am 1.1.2000

Anwendungen, die den Samstag für den Montag des Jahres 1900 halten

ab 1.1.2000

Anwendungen, die die Jahreszahl „00" mit anderer Bedeutung nutzen

ab 1.1.2000

Anwendungen, die Datumswerte fehlerhaft verarbeiten

am 2.1.2000

Anwendungen, die den Sonntag für den Dienstag des Jahres 1900 halten

am 6.1.2000

Anwendungen, die den Donnerstag für den Samstag des Jahres 1900 halten

am 7.1.2000

Anwendungen, die den Freitag für den Sonntag des Jahres 1900 halten usw.

am 29.2.2000

Anwendungen, die den Schalttag nicht erkennen

am 31.12.2000 am 1.1.2001

Anwendungen, die diesen Tag nicht als den 366. des Jahres 2000 erkennen Beginn des ersten Jahres des 21. Jahrhunderts und des 3. Jahrtausends: Virengefahr Überlauf des Zeitzählers in bestimmten Geräten

am 1.1.2001

4.3 Der Jahrhundertübergang

4.3

153

Der Jahrhundertübergang

Die in Großbritannien beheimatete Firma Corporation 2000 hat für New York die Probleme zum Jahr 2000 vorausgesagt (W06). Es wurden von ihr die wichtigsten städtischen Infrastrukturen analysiert und auch untersucht, mit welchen EDVSystemen diese arbeiten. Dann wurde bezogen auf diese Systeme der Stand der Jahr 2000 Projekte untersucht. Schließlich gelangte man zu folgenden Ergebnissen: Tabelle 11: Der Jahrhundertwechsel

in New York

Elektrizitätsversorgung

50% Verfügbarkeit

vom 1. bis zum 10. Januar 2000

Krankenhäuser

nur Notfalle

für 30 Tage

Börsen und Banken

geschlossen

für 8 Tage

Brief- und Paketpost

Störungen

für 10 Tage

Transporte (Flug/Bahn/Bus)

Störungen

für 30 Tage

Telekommunikation

50% Verfügbarkeit

vom 1. bis zum 10. Januar 2000

Mit der gleichen Methode hat dieselbe Firma auch die Verhältnisse in London untersucht (M06). Die Ergebnisse sind ähnlich wie in New York, doch sind für London schwerer wiegende Auswirkungen zu befürchten. In London habe man später und unkoordiniert mit den Jahr 2000 Projekten begonnen, so die Firma Corporation 2000. Tabelle 12: Der Jahrhundertwechsel

in London

Elektrizitätsversorgung

75% Verfügbarkeit

im Dezember 1999

Elektrizitätsversorgung

50% Verfügbarkeit

im Januar 2000

Krankenhäuser

nur Notfälle

für 30 Tage

Banken

geschlossen

vom 1.12.1999 bis zum 24.1.2000

Börsen

geschlossen

vom 20.12.1999 bis zum 24.1.2000

Brief- und Paketpost

Störungen

für 10 Tage

Transporte (Flug/Bahn/Bus)

Störungen

für 30 Tage

Telekommunikation

75% Verfügbarkeit

vom 1. bis zum 20. Januar 2000

4.4

Was folgt daraus?

=> Die Jahr 2000 Gefahren sind wirklich vorhanden und werden in vielfältiger Gestalt und über lange Zeiträume hinweg auftreten. => Es ist zu hoffen, daß angesichts solcher durchaus möglicher Konsequenzen private Unternehmen und öffentliche Institutionen ihre Anstrengungen verstärken, die drohenden Gefahren abzuwenden oder zumindest klein zu halten.

5

Die EDV im Jahr 2000 Chancen

5.1

Management des EDV-Betriebes

•

Notwendigkeit und Ziele

•

Systematik der Aufgaben

•

Optimierung der Aufgabenerledigung

•

Was folgt daraus?

Jedes Jahr 2000 Projekt hat das Ziel, die Wahrscheinlichkeit von EDV-Problemen verursacht durch den Datumswechsel klein zu halten. Wenn dann doch Probleme auftreten, •

so sollten sie schnell entdeckt,

•

ihre Auswirkungen sollten begrenzt und

•

ihre Untersuchung und Behandlung sollte unterstützt werden.

Um diesen Anforderungen gerecht zu werden, sind die Aufgaben des EDVManagements zu systematisieren und ihre Ausfuhrung zu optimieren.

5 Die ED V im Jahr 2000 - Chancen

156

Einrichtung des Jahr 2000 Projektrahmens

Einrichtung eines Jahr 2000 Projektes Kunden und Lieferanten s

_

Inventar der Anwendungen

Analyse der EDVAnwendungen

Inventar der EDV-Systeme

Analyse der EDV-Systeme

System-

korrekt

fehlerhaft

Umsetzung der Lösung

E D V - und ElektronikHersteller

5.1 Management des ED V-Betriebes

5.1.1

157

Notwendigkeit und Ziele

Mit dem Anwachsen der betrieblichen Aufgaben, die über die EDV oder mit Unterstützung der EDV erledigt werden, wächst in den meisten Unternehmen die Anzahl der EDV-Systeme, die Anzahl der Programme, der Umfang der Datenbestände und auch die Verschiedenartigkeit der eingesetzten Rechner. Mit anderen Worten: die Komplexität wird ständig größer. Um die Komplexität wenn nicht zu verringern, so doch um sie zu beherrschen, ist der EDV-Einsatz zu verwalten und zu optimieren. „Technischer Fortschritt bringt immer komplexere Systeme, die uns immer mehr Wachsamkeit und Vorausschau abverlangen." (TOI) Mit den verbesserten technischen Möglichkeiten in Computernetzen ergeben sich auch neue Möglichkeiten, auf Datenbanken zuzugreifen, Anwendungen auf verschiedene Rechner zu verteilen und auch Anwendungen über kommunizierende Programme zu realisieren. Doch damit ist das Management des EDV-Betriebes erst recht gefordert, wie die Kursankündigungen eines zur Gesellschaft für Informatik gehörenden Instituts belegen: „Datenbanken und verteilte Anwendungen in Rechnernetzen: Vorprogrammiertes Chaos oder beherrschbare Technologie?" „Management von Client/Server-Systemen - das Chaos verhindern" (D03) Die Ziele des Managements sollten sich ergeben aus den Anforderungen des Unternehmens und aus Vereinbarungen zwischen den Verantwortlichen für den EDVBetrieb und den Nutzern der EDV über die Qualität der EDV-Dienstleistungen, den sog. „Service-Level Agreements". Oft sind solche Vereinbarungen nicht explizit sondern ergeben sich aus den Anforderungen der täglichen Praxis. Sie können Qualitätskriterien für die folgenden Bereiche formulieren: •

Verfügbarkeit von EDV-Systemen (räumlich und zeitlich)

•

Reaktionszeiten bei auftretenden Problemen

•

Antwortzeiten und Durchsatz je nach EDV-Funktion

•

Zugriffsschutz für bestimmte Daten

Die betriebliche Anforderungen stehen den Interessen des EDV-Verwaltung oft entgegen: •

7 Tage und 24 Stunden - Betrieb

•

Unterstützung aller Niederlassungen - weltweit

•

Kostenreduzierung bei Hardware, Software und Support

•

verstärkte Automatisierung von Routinetätigkeiten

158

5 Die ED V im Jahr 2000 -

Chancen

Üblicherweise beschränkt man dabei aber den EDV-Betrieb auf den produktiven Einsatz, läßt also den Betrieb der Entwicklungs- und Wartungsumgebung außer Acht. Ein Teil der Schwierigkeiten bei der Analyse der EDV-Systeme, der Umstellung auf Jahr 2000 Fähigkeit und den dazu gehörenden Tests ergibt sich aus dieser Sichtweise. Entsprechend beschränkt man die Nutzer der EDV auf die Mitarbeiter der Fachabteilungen und läßt also Programmierung, Operating und Systemtechnik außer Acht. Wiederum ergibt sich ein Teil der Schwierigkeiten, die Produktivität der Programmierer und die Reaktionsgeschwindigkeit der Operateure zu steigern aus eben dieser Sichtweise. Die mit dem Jahr 2000 verbundenen Datumsprobleme können schon aufgetreten sein - bei Anwendungen, die künftige Datumswerte fehlerhaft verarbeiten, - dann sollten die bisherigen EDV-Betriebserfahrungen ausgewertet werden. Oder sie werden bald entsprechend dem Verlauf des im letzten Kapitel beschriebenen Katastrophenkalenders auftreten. Selbst, wenn man meint, daß Umstellung oder Ersetzung alle Datumsprobleme beseitigen werden, können sich Renovierungen verzögern oder Konvertierungen Anwendungen oder Programme übersehen. Mit unternehmenskritischen Anwendungen wird man sinnvollerweise bei der Beseitigung von Datumsproblemen beginnen. Gerade dieses Vorgehen wird es dann nicht mehr erlauben, sich in gleicher, gründlicher Weise mit weniger kritischen Anwendungen zu beschäftigen. Auch die besten Werkzeuge machen Fehler, sie entdecken nicht alle Datumsverarbeitungen und sie stellen auch nicht alle erkannten fehlerhaften Verabeitungen um oder gerade die Umstellung programmiert eine neue, wieder fehlerhafte Programmlogik. Was für die EDV im Allgemeinen und die überall auftretenden Jahr 2000 Probleme gilt, gilt auch für die Euphorie nach einem offiziell abgeschlossenen Jahr 2000 Projekt und die immer vorhandenen Restprobleme: „Je naiver unser Technik-Optimismus, desto sicherer der Rückschlag." (T01)

5.1.2

Systematik der Aufgaben

Die Aufgaben beim EDV-Betrieb lassen sich in sechs Bereiche aufteilen (nach T03): •

Steuerung der Abläufe

•

Behandlung von Problemen

•

Verwaltung von Änderungen

5.1 Management des ED V-Betriebes

•

Einrichtung der Betriebsmittel

•

Optimierung der Betriebsmittelnutzung

•

Verwaltung von Nutzern und deren Rechten

159

Die Hardware eines EDV-Systems wird aufgebaut, die Software wird aufgespielt, die Datenbank wird vorbereitet. Dann werden die Anwendungen gestartet und alle EDV-Funktionen werden überwacht. Auftretende Probleme werden so entdeckt und die Nutzung der Betriebsmittel, d.h. der Funktionen des Betriebssystems und der Hardware, wird so gemessen. Die Beseitigung von Problemen und die Optimierung der Systemnutzung kann zu Änderungen an allen Bestandteilen eines EDVSystems oder zu ihrer geänderten Einrichtung fuhren. Das funktionsfähige System wird Nutzern, Menschen und anderen EDV-Systemen, mit unterschiedlichen Rechten zur Verfügung gestellt. Steuerung der Abläufe Diese Aufgabe wird täglich vom Operating ausgeführt. Sie umfaßt: •

Start und Stop der Hardware und Software

•

Überwachung aller Teile des EDV-Systems

•

Registrierung von Ereignissen und Alarmen

•

Messung der Betriebsmittelnutzung

•

Durchfuhrung von Medienwechseln (Band, Platte, CD)

•

Planung der Abläufe von Batch-Programmen

•

Pflege der Dokumentation des EDV-Betriebes

•

Unterstützung der EDV-Nutzer

Behandlung von Problemen Diese Aufgabe wird bei Bedarf vom Operating, von der Programmierung oder von der Systemtechnik ausgeführt. Sie umfaßt: •

Vorbeugung von Problemen

•

Problementdeckung

•

Problemdiagnose

•

Problembehebung oder -delegation

Verwaltung von Änderungen Diese Aufgabe wird bei Bedarf vom Operating oder von der Systemtechnik ausgeführt. Sie umfaßt: •

Planung von Änderungen

160

5 Die ED V im Jahr 2000-

•

Kontrolle von Änderungen

•

Durchfuhrung von Installation und Deinstallation

•

Änderung einer Betriebsmitteleinrichtung

Chancen

Einrichtung der Betriebsmittel Diese Aufgabe wird bei Bedarf von der Systemtechnik ausgeführt. Sie umfaßt: •

Pflege der Dokumentation der Betriebsmittelparameter

•

Vergabe von Namen für Betriebsmittel

•

Pflege der Betriebsmittelparameter

•

Verwaltung von Programmen und ihren Versionen: Texte, Objekte, Pakete

•

Verwaltung von Daten und ihren Versionen: Strukturen, Dateien, Datenbanken

•

Überprüfung der Datenqualität

Optimierung der Betriebsmittelnutzung Diese Aufgabe wird bei Bedarf von der Systemtechnik ausgeführt. Sie umfaßt: •

Auswertung der Messungen

•

Organisation der Nutzungsabrechnung

•

Planung von Optimierungen bei der Systemnutzung

•

Änderung einer Betriebsmitteleinrichtung

•

Kontrolle von durchgeführten Änderungen

•

Planung der Systemkapazität

Verwaltung von Nutzern und deren Rechten Diese Aufgabe wird täglich vom Operating ausgeführt. Sie umfaßt: •

Pflege der Dokumentation der Nutzerrechte

•

Vergabe von Namen für Nutzer

•

Vergabe von Rechten

•

Pflege der Sicherheitsparameter

•

Überwachung der Rechtenutzung

•

Sicherung der Vertraulichkeit

J. 1 Management des ED V-Betriebes

5.1.3

161

Optimierung der Aufgabenerledigung

Diese Optimierung beim EDV-Betrieb ist eine ständige Aufgabe für die EDVBetriebsleitung. Doch die nächsten Jahre werden zusätzlich verstärkte Wartungsaktivitäten aus Jahr 2000 Projekten und gleichzeitig eine vergrößerte Wahrscheinlichkeit für das Auftreten von Datumsproblemen mit sich bringen. Daher sollten ab heute sowohl alle bisherigen Möglichkeiten für eine Optimierung ausgeschöpft werden als auch für die kommenden Fragen passende Antworten gefunden werden. Oft wird nur die Optimierung des bisherigen Betriebs bei allen Beteiligten die zeitlichen Spielräume schaffen, damit sie sich auf die kommenden Herausforderungen vorbereiten und sie, wenn sie dann tatsächlich eintreten, effektiv bewältigen können. Die Optimierung hat bei allen Aufgaben einen organisatorischen und einen personellen Teil. Die Aufgaben des Systembetriebes sind über Richtlinien zu beschreiben und durch Prüflisten sowie Werkzeuge zu unterstützen. Wo eben möglich sollten dann gut verstandene und oft auszuführende Prozeduren automatisiert werden. Auf Grundlage der genannten Richtlinien kann ein Training für Operating und Systemtechnik entwickelt werden. Für alle Aufgaben im EDV-Betrieb sollten Experten herangebildet werden. Die schon heute bekannten Ärgernisse und Probleme bei der EDVVerwaltung sollten schnellstmöglich beseitigt werden. Unter den Aspekten Wartungsprogrammierung in Jahr 2000 Projekten, Programmierung für verbesserte Verwaltbarkeit und optimierte Verwaltung des heutigen sowie des künftigen EDV-Betriebes werden die dazu gehörenden Aufgaben noch einmal besprochen. Steuerung der Abläufe Es sind nun auch die Abläufe auf zwei weiteren Rechnerarten zu steuern. Zum einen die Entwicklungsrechner, den Zahl zunehmen dürfte und deren Einsatz für die große Anzahl der Wartungsprogrammierer optimiert werden muß. Auf ihnen befinden sich auch immer häufiger Datenbank gestützte Werkzeuge für Programmanalyse, Umstellung und Test. Zum anderen die Testrechner, die von den Herstellern mit Jahr 2000 fähiger Hardware und Betriebssystem ausgestattet werden, worauf eben diese Fähigkeit mit tatsächlich verstellter, künftiger Zeit getestet werden kann. Die ersten Tests darauf sollten für die Verwaltungswerkzeuge ausgeführt werden. Programmierung für Verwaltbarkeit bedeutet hier, daß alle Programme über ein zentral geführtes Logbuch Ereignisse und Fehleralarme melden und auch differenziert über ihre Betriebsmittelnutzung Auskunft geben können.

162

5 Die ED V im Jahr 2000 -

Chancen

Schon heute ist es technisch möglich, den Betriebszustand aller EDV-Systeme zentral zu überwachen - gleichgültig, ob es sich dabei um Host-Rechner, ServerRechner, Netzwerke oder PCs oder ob es sich dabei jeweils um Hardware, Software oder Daten handelt. Ergänzend dazu sollten alle EDV-Uhren und Zeitzähler registriert und überwacht werden. Alle beschreibbaren Medien sollten nicht nur mit einer Namenskennung sondern auch mit einem acht stelligen Datum versehen werden, um durch Datumsprobleme bei den Medien-Verwaltungswerkzeugen ausgelöstes, fehlerhaftes Überschreiben unwahrscheinlich zu machen. Die Dokumentation sollte gesichert und online zugreifbar sein und möglichst automatisch aktualisiert werden. Als Vorbereitung auf künftige Datumsprobleme in Programmen empfiehlt es sich, das System zur Registrierung von Ereignissen und Alarmen so effektiv wie möglich einzurichten und Filter für Ereignisse vorzusehen, damit diese an die für sie zuständigen Bearbeiter automatisch weitergeleitet werden können. Darüber hinaus kann schon jetzt ein „Help Desk", ein Büro für Beratung und Betreuung der von Datumsproblemen betroffenen EDV-Nutzer eingerichtet werden. Behandlung von Problemen Programmierung für Verwaltbarkeit bedeutet hier, daß alle Programme Detailinformationen zu Ereignissen und Fehleralarmen liefern und auch über ihre Konkurrenz mit anderen Programmen bei der Betriebsmittelnutzung Auskunft geben können, um die Problemdiagnose zu erleichtern. Alle bisher bekannten Probleme, wie instabile Hardware, noch nicht installierte Verbesserungen im Betriebssystem oder auch fehlerträchtige Anwendungen sollten so schnell wie möglich korrigiert werden, um sich bei der Behandlung von Problemen auf die kommenden Datumsprobleme konzentrieren zu können. Der Zeitraum zwischen Problementdeckung und Problembehebung muß verkürzt werden durch Dokumentation erfolgreicher Problemlösungen, durch Training und durch definierte Weiterleitung von Problembeschreibungen an die jeweiligen Experten. Problemmeldungen sollten auch eine Kennung enthalten, ob sie von unternehmenskritischen Anwendungen kommen. Nur so kann die Fülle der künftigen Probleme in der richtigen Reihenfolge und dann auch schnell bewältigt werden. Verwaltung von Änderungen Die Wartungsprogrammierung, der Einbau von Brückenprogrammen, Umstellungen von Datenstrukturen und auch die Einführung neuer Anwendungspakete, die alte Anwendungen ersetzten sollen, wird ein Fülle von Änderungen an Hardware, Software und Daten mit sich bringen. Daher sind alle Prozeduren, die der Durchfuhrung von Installationen und Deinstallationen dienen, zu sichten und zu optimieren, um sie schneller und besser überwacht ausführen zu können.

5.1 Management des EDV-Betriebes

163

Einrichtung der Betriebsmittel Die Probleme, die sich bei der Wartungsprogrammierung für Jahr 2000 Umstellungen stellen, sind die Pflege der richtigen Version, die Z u s a m m e n f u h r u n g mit den Textänderungen der normalen Wartung, der Einsatz des richtigen Objekts im richtigen Programmpaket zum richtigen Zeitpunkt. Für die Lösung dieser Probleme und für die Lösung ähnlicher Probleme bei Datenversionen gibt es schon seit vielen Jahren Werkzeuge, die aber bisher kaum eingesetzt werden. Auch damit sollte, und zwar heute noch, begonnen werden, da nur die Umstellung auf eine Versionsverwaltung manchmal schon ein Jahr oder länger dauern kann. Programme sind sicher dann besser verwaltbar, wenn alle ihre Betriebsmittel über programmexterne Festlegungen zugewiesen werden können. Wo das noch nicht der Fall ist, sollte es schleunigst korrigiert werden, da sie nur so in einfacher Weise vom Entwicklungs-, auf den Test- und dann auf den Produktionsrechner übernommen werden können. Eine der wesentlichen Aktivitäten der heutigen Verwaltung sollte die Überprüfung der Datenqualität aller Datensätze, Dateien und Datenbanken sein, die Datumswerte oder davon abgeleitete Werte enthalten. Damit können jetzt und in Zukunft fehlerhafte Datumswerte gefunden werden, die nicht zu einer Programmeldung und damit auch nicht zu der üblichen Problembehandlung geführt haben. Außerdem können so Jahreszahlen mit spezieller Bedeutung entdeckt werden, deren Erzeugung möglichst schnell abgestellt werden muß. In letzter Konsequenz werden die Jahr 2000 Probleme aller Programme in Datenverfälschungen kumulieren. Diese fehlerhaften Datenwerte gilt es zu entdecken und zu korrigieren. Alle wirtschaftlichen Schäden, die langfristig zu erwarten sind, also die, die nicht aus einer Systemunterbrechung oder einem Programmabbruch resultieren, werden ihren Ausgangspunkt in Datenverfälschungen haben. Damit diese Art der Verursachung f ü r Versicherungen und für rechtliche Auseinandersetzungen dokumentiert werden kann, sollte auch die heutige, hoffentlich gute Qualität der Datenbestände dargestellt werden. Eine Spezialfrage ergibt sich beim Betriebsmittel Systemuhr. Der Datumswechsel auf möglicherweise problematische Tage, siehe Katastrophenkalender, soll vielleicht besonders genau und bei allen Rechnern gleichzeitig ausgeführt werden, dann ist die Präzision der Uhren und ihre unternehmensinterne Synchronisierung zu überprüfen. Die Zentraluhr, von der die anderen Uhren oder Zeitzähler, ihre Zeit oder ihre Zeitkorrektur beziehen, sollte durch die Katastrophen geneigten Tage nicht gestört sein. Oder der Datumswechsel soll für ein Unternehmen nacheinander auf verschiedenen Rechnern ausgeführt werden, dann helfen die Zeitunterschiede in den Weltzeitzonen oder eine bewußte Zeitverstellung um wenige Stunden.

164

5 Die ED V im Jahr 2000 - Chancen

Optimierung der Betriebsmittelnutzung Es ist damit zu rechnen, daß zahlreiche umgestellte Programme und auch die benötigten Brückenprogramme mehr Rechnerleistung benötigen, als die bisherigen Programme der gleichen Anwendung. Daher ist entweder die künftige Rechnerkapazität zu erweitern oder eben die bisherige Betriebsmittelnutzung zu verringern. Verwaltung von Nutzern und deren Rechten Auch in Werkzeugen, die Nutzerrechte verwalten, sind zahlreiche Datumswerte enthalten: Nutzernamen und Zugangsschlüssel können zeitlich beschränkt werden, bestimmte Rechte dürfen nur in einem bestimmten Zeitraum ausgeübt werden oder bestimmte Geräte dürfen nur in einem bestimmten Zeitraum genutzt werden. Daher können solche Systeme auch Datumsprobleme haben. Besonders ist hier auch an die unterschiedliche Verteilung der Werktage und Wochenenden im Jahr 1900 und im Jahr 2000 zu denken. Daher sollten hier für die Systemverwaltung und für die Sicherheitsverwaltung vorsorglich zusätzliche Rechte eingerichtet werden, die nach problematischen Tagen oder auch im Jahr 1900 wirksam werden. Eine besondere Gefahr geht von neuen oder fehlerhaft programmierten, alten Viren aus. Daher sollten die besten Virenbekämpfungswerkzeuge angeschafft und auf allen Rechnern auch als allgemeine Schutzmaßnahme installiert werden. Alle heute erkannten Viren, auch die, die als harmlos beschrieben werden, sollten sofort beseitigt werden.

5.1.4

Was folgt daraus?

=> Die heutigen Aufgaben der EDV-Verwaltung und die jeweilige Qualität ihrer Erledigung sind zu verzeichnen. => Dann kann hier das Management optimiert und der EDV-Betrieb auf die künftigen Anforderungen eingestellt werden, die das Jahr 2000 Problem und seine Bewältigung mit sich bringt.

5.2

Versicherungen

5.2

165

Versicherungen

•

Das verdoppelte Jahr 2000 Problem

•

Versicherungsarten

•

Millennium Versicherung

•

Was folgt daraus?

Die großen und kleinen Katastrophen im Jahr 2000 lassen sich möglicherweise durch gutes EDV-Management in ihren Auswirkungen begrenzen. Doch Schäden und Schadenersatz werden sich nicht ganz vermeiden lassen. Hier hat der Versicherungsnehmer die Chance, durch eine Versicherung mit angemessener Versicherungssumme einen gewissen Ausgleich zu erhalten. Doch die Versicherungen werden sich zunehmend dieses besonderen Risikos bewußt und werden durch verschiedene Maßnahmen versuchen, ihre Zahlungsverpflichtungen klein zu halten. Oder sie werden das Jahr 2000 Risiko direkt angehen und gegen entsprechende Prämie Schäden verursacht durch Jahr 2000 Probleme versichern."

5.2.1

Das verdoppelte Jahr 2000 Problem

Für Banken und Versicherungen stellt sich das Jahr 2000 Problem in doppelter Gestalt dar. Neben den Problemen innerhalb der Unternehmen dieser Branchen und den auch für andere Branchen üblichen Problemen mit der Jahr 2000 Fähigkeit der Kunden und Lieferanten gibt es hier noch besondere äußere Umstände. Bei den Banken geht es um die Sicherheit ihrer Kredite und Beteiligungen, bei den Versicherungen geht es darum, ob sich aus bestehenden Versicherungsverträgen eine Leistungspflicht für Schäden verursacht durch Jahr 2000 Probleme ergibt. „Uns als Versicherer und Rückversicherer interessieren vielmehr ganz andere Fragen: können die Folgekosten einer mißglückten Umstellung ganz oder teilweise unter Versicherungspolicen geltend gemacht werden? Und, noch wichtiger, wieviele Unternehmen werden überhaupt in der Lage sein, die Umstellung rechtzeitig zu schaffen, und wieviele werden es nicht schaffen und durch Ausfalle der Datenverarbeitung oder Prozeßsteuerung Personen-, Sach- oder Vermögensschäden verursachen, die möglicherweise in letzter

Der Autor ist kein Versicherungsexperte. Die folgenden Ausfuhrungen geben ausschließlich seine persönliche Meinung wieder. Hinweise auf mögliche Fehler und Auslassungen sind willkommen. Die folgende Darstellung soll nicht als Beratung in versicherungsfachlicher oder rechtlicher Hinsicht interpretiert werden. Alle Leser werden gebeten, ihre besondere Lage mit ihrem Experten für alle im folgenden genannten Problemkreise durchzusprechen.

166

5 Die ED V im Jahr 2000 - Chancen

Konsequenz bei den Versicherern als Schaden geltend gemacht werden?

(QOi) Versicherer werden ihr Risiko bewerten: •

Wie hoch ist die Wahrscheinlichkeit für das Auftreten einer bestimmten Art von Schäden?

•

Wie groß ist der wahrscheinliche Schadensumfang je Schadensereignis?

•

Durch welche faktischen oder rechtlichen Maßnahmen läßt sich die Leistungspflicht aus bestehenden Verträgen begrenzen?

•

Welche Klauseln verringern das Risiko der Versicherers bei neuen Verträgen?

Das allgemeine Risiko für das Auftreten von Jahr 2000 Problemen und damit auch für daraus folgende Schäden würde sicher reduziert, wenn Versicherungen ihre Kundschaft über das Jahr 2000 Problem aufklären und sie auf die nötigen Maßnahmen zur Gefahrenabwehr hinweisen würden. Die Sachversicherer haben das immer schon praktiziert, wenn es um wertvolle, von ihnen zu versichernde Sachen gingEine weitere faktische Maßnahme wäre es auch, wenn es auf Drängen der Versicherer gelingen würde, Geräte, die in der Prozeßsteuerung eingesetzt werden, Jahr 2000 sicher zu machen, um so das Risiko von Personen- und Sachschäden klein zu halten. Bei rechtlichen Maßnahmen werden Versicherer wahrscheinlich darüber nachdenken, wie sie durch Gutachten, geänderte Versicherungsbedingungen und neue Ausschlußklauseln ihr Leistungsrisiko verringern. Daher sollten alle Versicherungsnehmer schon heute ihre Vertragsposition gegenüber den Versicherern beurteilen und die möglicherweise kommenden Änderungen der Versicherungsbedingungen genau überprüfen, bevor sie akzeptieren. Interessenten an Versicherungen, insbesondere im Bereich der Vermögensschadenshaftpflicht, sollten sich beeilen, Verträge abzuschließen, solange Versicherer das Risiko noch tragen wollen bzw. solange spezifische Jahr 2000 Risiken nicht von den Versicherern explizit ausgeschlossen werden.

5.2.2

Versicherungsarten

Das Jahr 2000 Problem kann zu zahlreichen Arten von Schäden führen; diese Schäden begründen dann möglicherweise eine Leistungspflicht für ebenso verschiedene Versicherungssparten: I.

Personenversicherungen A. Leben B. Krankheit

5.2

II.

III.

IV.

Versicherungen

167

c. Unfall Sachversicherungen A. Transport B. Gebäude C. Technik D. Betriebsunterbrechung Unternehmensversicherungen A. Kreditsicherung B. Pensionssicherung Haftpflichtversicherungen A. Betrieb B. Produkt Beruf C. D. Organ E. Umwelt

Das Risiko für Personenschäden ist gering, da die Wahrscheinlichkeit, daß Personen durch EDV-gesteuerte Anlagen zu Schaden kommen, klein ist. Denn entweder gelingt es Produktionsanlagen, Verkehrsleitsysteme und medizinische Versorgungssysteme explizit Jahr 2000 sicher zu machen oder sie werden in den letzten Tagen des Jahres 1999 und den ersten Wochen des Jahres 2000 nur unter besondere Aufsicht betrieben oder besonders riskante Anlagen werden eben nicht betrieben, da keine Versicherung das entsprechende Risiko übernehmen wird. Jahr 2000 Sicherheit, besondere Aufsicht, manueller Betrieb oder Abschalten werden sich auch für EDV-gesteuerte Anlagen empfehlen, die Schäden beim Transport oder an Gebäuden oder an technischen Geräten oder auch an der Umwelt verursachen können. Auch normale Betriebsunterbrechungsversicherungen bergen für Versicherer kein besonderes Risiko, da die Betriebsunterbrechung durch einen ihr voraus gegangenen Sachschaden verursacht sein muß, der durch ein zufälliges Ereignis ausgelöst wird. Der Wechsel der Jahreszahlen geschieht jedoch nicht zufällig und, wie gesagt, Sachschäden werden eher selten sein. Es gibt allerdings in diesem Bereich besondere Versicherungen, die einzelne Folgeschäden einer wie auch immer ausgelösten Betriebsunterbrechung in das Risiko einbeziehen und dort besteht dann Leistungspflicht. Falls einzelne Firmen von ihren eigenen Jahr 2000 Problemen oder denen ihrer Kunden und Lieferanten so massiv getroffen werden, daß sie in Zahlungsschwierigkeiten oder in Konkurs geraten, so tragen Versicherer über zwei Arten von Versicherungen dieses Risiko mit. Die Kreditsicherung sichert die Forderungen von Lieferanten gegen Ausfälle oder verspätete Zahlungen. Die Pensionssicherung sichert die Pensionszusagen an leitende Mitarbeiter gegen Ausfall der Prämienzahlungen an die jeweilige Lebensversicherung.

168

5 Die ED V im Jahr 2000 - Chancen

Der große Risikobereich für Versicherer und damit der große Leistungsbereich an Versicherungsnehmer sind die verschiedenen Arten der Haftpflichtversicherung. In welcher Weise sich Haftpflichten entwickeln, wird in den Kapitel „Haftung aus Vertrag" und „Haftung aus Verschulden und Gefährdung" dargestellt. Dabei deckt die betriebliche Haftpflichtversicherung hauptsächlich Personen- und Sachschäden bei Dritten, die aus Lieferungen oder Leistungen eines Unternehmens herrühren. Die Produkthaftpflichtversicherung tritt auch in substantiellem Umfang für Folgeschäden eines Mangels ein, wie z.B. Gewinnausfall und überflüssige Aufwendungen. Sie tritt auch ein für das Produkt technische Software, das bei Dritten Maschinen steuert oder kontrolliert. Sie tritt möglicherweise nicht ein für Vermögensschäden, die von Softwareprodukten für andere als technische Einsatzgebiete verursacht werden, wenn der Versicherungsnehmer es unterlassen hat, seiner Beobachtungs-, Warn- und seiner evtl. auch erforderlichen Reparaturpflicht nachzukommen. Die berufliche Haftpflicht deckt Vermögensschäden bei Dritten, die durch Fehlberatung oder Nichtberatung entstehen, daher heißt sie im Englischen auch „Errors & Omissions"-Versicherung. Die versicherten Personenkreise sind hier Rechtsanwälte, Steuerberater, Wirtschaftsprüfer, Unternehmens- und EDV-Berater. Einige dieser Berater sind sogar verpflichtet, eine entsprechende Versicherung abzuschließen; vorgeschrieben ist dann aber nur eine Mindesthöhe der Versicherungssumme. Eingeschlossen ist regelmäßig auch die Versicherung von Hilfspersonen dieser Berater. Oft gliedert sich eine solche Versicherung in eine allgemeine Grundversicherung, wie z.B. für Betriebsberatung, Personalberatung oder EDV-Beratung, die dann mit einer SpezialVersicherungen für einzelne Projekte ergänzt werden kann. EDV-Berater haben schon Jahr 2000 Risiken, wenn sie Software empfehlen oder deren Qualität beurteilen sollen. Sie sind natürlich besonders betroffen, wenn sie EDV-Systeme gestalten oder programmieren sollen. Die anderen Berater können besonderen Risiken ausgesetzt sein, wenn sie Unternehmen für Beteiligungen oder Verkauf ohne Berücksichtigung der möglichen Jahr 2000 Probleme bewertet haben und diese Unternehmens sich dann in nächster Zukunft mit besonderen Schwierigkeiten dieser Art konfrontiert sehen. Interne und externe Mitarbeiter in Jahr 2000 Projekten haben ein großes Risiko, bestimmte Aspekte zu übersehen oder bestimmte Aufgaben fehlerhaft zu erledigen. Daher empfiehlt es sich für ein Unternehmen, daß es für alle an seinem Jahr 2000 Projekt beteiligten Planer, Leiter und Berater eine spezielle Berufshaftpflichtversicherung abschließt. Durch die Bedeutung und die Sichtbarkeit eines solchen Projektes nach innen und außen tragen diese Projektbeteiligten ein ähnlich hohes Risiko wie die Unternehmensleitung. Es ist zu hoffen, daß sich heute noch Versicherer finden, die dieses Jahr 2000 Projektrisiko mit tragen möchten. Die „Directors & Officers"-Versicherung deckt Vermögensschäden, die durch Fehlleistungen oder Nichtleistungen von Mitgliedern eines Unternehmensorgans

5.2

Versicherungen

169

bei Dritten aber auch beim selben Unternehmen entstehen. Satzungsmäßige Organe eines Unternehmens sind z.B. Aufsichtsrat, Vorstand oder Geschäftsführung. Die Haftung natürlicher Personen kann im Gegensatz zu der von juristischen Personen nicht beschränkt werden. Organmitglieder haften nicht nur schon bei leichter Fahrlässigkeit mit ihrem gesamten Privatvermögen sondern auch noch gesamtschuldnerisch für die Fehler anderer Mitglieder des gleichen Organs. Das Unternehmen hat oft ein Interesse daran, eine derartige Versicherung abzuschließen, denn die Versicherung ist ein Teil der Antwort auf die Frage: Wie lassen sich Unternehmen vor ihren Managern schützen? Für das Unternehmen bedeutet eine Versicherung eine deutlich erhöhte Zugriffsmasse im Schadensfall und auch einen Schutz vor schlechter Presse, da es mit Hilfe der Versicherung meistens gelingt, Streitigkeiten mit leitenden Mitarbeitern über außergerichtliche Vergleiche beizulegen. Der andere Teil der Antwort auf die bewußte Frage liegt in einer Vertrauensschadensversicherung bzw. einer Vermögensschutzversicherung (A02), die das Unternehmen gegen vorsätzliche unerlaubte Handlung von Vertrauenspersonen bzw. Mitarbeitern und Dritten schützt. Der leitende Mitarbeiter hat selbstverständlich ein Interesse daran, eine „Directors & Officers"-Versicherung abzuschließen, denn die Versicherung ist die Antwort auf die Frage: Wie lassen sich Manager vor ihren Unternehmen schützen? Für den Mitarbeiter bedeutet diese Versicherung eine wünschenswerte Absicherung gegen seine durchaus möglichen Fehlleistungen einschließlich Fehlinvestitionen und Unterlassungen. Der Schutz der Versicherung gilt auch für die Zeit nach seinem Ausscheiden aus dem Unternehmensorgan. Nach seiner aktiven Zeit kann sein Risiko durchaus durch Wechsel im Vorstand oder bei den Eigentümern wachsen während seine Möglichkeiten, sich zu verteidigen, wegen fehlendem Aktenzugriff abgenommen haben. Eine solche Versicherung deckt auch seine Risiken, wenn er - möglicherweise auch erst nach der Lektüre dieser Zeilen - aktiv ein Jahr 2000 Projekt betreibt und es fehlschlagen sollte. Wenn eine Firma allerdings von Jahr 2000 Problemen betroffen sein sollte und die leitenden Mitarbeiter keine Schritte unternommen haben, der Gefahr zu begegnen, so wird die Versicherung argumentieren, daß die leitenden Mitarbeiter den Schaden verschuldet haben aus wissentlichen Pflichtverletzung oder aus Eventualvorsatz, sie sich also mit einem Schaden abgefunden hat, der möglicherweise eintritt. Damit befreit sich der Versicherer von seiner Leistungspflicht. Möglicherweise muß er oder ein andere Versicherer dann doch noch leisten, wenn für das Unternehmen eine Vertrauensschadensversicherung oder eine Vermögensschutzversicherung besteht.

170

5 Die ED V im Jahr 2000 -

5.2.3

Chancen

Millennium-Versicherung

Ein Millennium-Versicherung versichert das Jahr 2000 Risiko eines Unternehmens direkt (A03), allerdings nur, falls das Unternehmen in qualifizierter Weise ein Jahr 2000 Projekt betreibt. Die Qualifizierung wird nachgewiesen durch eine einmalige Untersuchung vor Abschluß des Versicherungsvertrages und danach durch wiederholte Untersuchungen zum bisherigen Verlauf und zum Stand des Jahr 2000 Projektes. Die Untersuchung beurteilt sowohl die Anstrengungen, Jahr 2000 Probleme zu bewältigen, als auch das geschäftliche Risiko für den Fall, daß die Anstrengungen nicht zum Erfolg fuhren. Die Versicherung deckt über die Versicherungssumme Schäden und Aufwände, die beim Versicherungsnehmer bis zum Ende des Jahres 2000 entstehen durch mißglückte Umstellung auf Jahr 2000 Fähigkeit bei ihm selbst (direkte Geschäftsunterbrechung) oder mißglückte Umstellung bei Dritten (indirekte Geschäftsunterbrechung). Die Schäden beim Versicherungsnehmer können dann wieder eigene Schäden oder Schäden bei Dritten sein, für die der Versicherungsnehmer oder seine leitenden Mitarbeiter haften müssen. Die Risikominderung beim Versicherer erfolgt über Prämienzahlungen des Versicherungsnehmers, die je nach Stand des Jahr 2000 Projektes zwei Drittel oder mehr als drei Viertel der Versicherungssumme ausmachen können. Im Schadensfall erfolgt eine volle Deckung. Der Versicherungsnehmer hat den Vorteil, daß ein Teil des Schadens tatsächlich von der Versicherung getragen wird, während ein anderer Teil tatsächlich von ihm selbst, aber über mehrere Jahre verteilt, bezahlt wurde. Falls nur kleine Schäden auftreten, werden die Prämien zuzüglich Zinsen und abzüglich einem Risikobeitrag zurück erstattet. Doch eine Versicherung ist nicht alles: „Although some insurance companies are beginning to insure against year 2000 losses, don't rely on insurance. The head of a Fortune 100 Company's disaster recovery planning department told me, "Remember, insurance is the worst solution when there is a business interruption." What she meant was that insurance is usually late with payments and the money is often less than it takes to get going again, especially if there is inadequate documentation of what the business was doing before the loss. Documenting what each business unit does is also part of the plan. Insurance is necessary, but no substitute for a well thought out disaster recovery plan, which can minimize losses in profit and jobs far more than a check from the insurance company." (105) „Obwohl einige Versicherungsunternehmen jetzt beginnen, gegen Jahr 2000 Verluste zu versichern, vertrauen Sie nicht auf eine Versicherung. Das erzählte mir die Leiterin eines Krisenstabes in einem Fortune 100 Unternehmen. „Denken Sie daran, eine Versicherung ist die schlechteste Lösung, wenn es eine Geschäftsunterbrechung gibt." Was sie meinte war, daß eine

5.2

Versicherungen

171

Versicherung normalerweise erst nach einer Weile zahlt und das gezahlte Geld ist oft weniger als nötig, um wieder ans Laufen zu kommen, insbesondere, wenn es nur eine unzureichende Dokumentation darüber gibt, was das geschäftliche Geschehen vor dem Verlust war. Beschreiben, was jede Geschäftseinheit tut, ist auch Teil des (Krisen-)Plans. Versicherung ist notwendig aber kein Ersatz für einem gut durchdachten Krisenplan, der weit mehr als ein Scheck vom Versicherungsunternehmen Gewinnausfälle und Arbeitsplatzverluste klein halten kann."

5.2.4

Was folgt daraus?

=> Neben der Bestandsaufnahme der EDV-Verträge ist auch eine Bestandsaufnahme der Versicherungsverträge und der darin vereinbarten Versicherungssummen durchzuführen. Nur so lassen sich Versicherungslücken oder Versicherungsvorteile aufspüren. => Doch selbst wenn ein Versicherungsfall eintritt, kann der Versicherungsnehmer nicht immer davon ausgehen, daß er sich versicherungsrechtlich durchsetzt, daß alle Kosten belegbar sind, daß alle Folgekosten anerkannt werden und daß die Versicherungssumme ausreicht. => Je nach Umfang der Jahr 2000 Katastrophen ist auch zu hoffen, daß die Versicherer über die nötige Finanzkraft für einen vollen Schutz verfügen, insbesondere wenn sie von sehr vielen Seiten in Anspruch genommen werden.

6

Die EDV nach dem Jahr 2000 Gefahren

6.1

Haftung aus Verschulden und Gefährdung

•

Schuldhaftes Verhalten

•

Haftung aus Verschulden

•

Haftung im Innenverhältnis

•

Haftung aus Gefährdung

•

Was folgt daraus?

Das Thema dieses Kapitel ist sicher in seinen Konsequenzen das unerfreulichste des Themenkomplexes. Konnte man bei der Haftung aus Vertrag auch von Chancen für Kunden und Lieferanten sprechen, so lauern hier nur Gefahren für alle Seiten, und zwar sowohl für Unternehmen wie für deren Mitarbeiter. Menschliches Verhalten auch im Umfeld der EDV kann und wird nach verschiedenen Kriterien bewertet werden: •

moralisch - dazu wird sich einiges im Kapitel „Veränderungen im Softwaremarkt" finden,

•

strafrechtlich - den Übergang zivilen Fehlverhaltens in einen Tatbestand deutet die folgenden Frage an: „Kann arglistiges Verbergen von Jahr 2000 Problemen als Betrug gewertet werden?",

•

zivilrechtlich - zur Klärung dieses Aspektes will das vorliegende Kapitel beitragen.

Im Jahr 2000 werden alle Beteiligten noch genügend damit zu tun haben, die Abfolge von kleinen und großen Katastrophen zu überstehen. In den Jahren danach

174

6 Die ED V nach dem Jahr 2000 -

Gefahren

wird man dann die Zeit finden, sich die von anderen verschuldeten Schäden oder durch gefährliche Produkte verursachten Schäden ersetzen zu lassen.

6.1.1

Schuldhaftes Verhalten

Eine unerlaubte Handlung kann über die Verjährungszeit unentdeckt bleiben, dann ist sie ohne Konsequenzen. Sie kann entdeckt werden und folgenlos bleiben, dann kann sie strafrechtlich als Versuch gewertet werden. Oder sie hat einen Schaden zur Folge und begründet damit auch zivilrechtlich ein Verschulden, wobei das Verschulden analog zur strafrechtlichen Schuld differenziert wird. Für den Schaden ist zu haften, daher spricht man auch von „deliktischer Haftung". Eine Handlung kann ein aktives Tun oder auch ein Unterlassen sein, sowohl das eine wie das andere kann mit Vorsatz oder fahrlässig ausgeführt werden. Der Vorsatz wird begründet durch Wissen und Wollen der objektiven Tatbestandsmerkmale. Er kann als Absicht auftreten, die den Handlungserfolg zielgerichtet herbeiführen will, oder als direkter Vorsatz, der den Erfolg will und die dabei vorhersehbaren Folgen akzeptiert, oder als Eventualvorsatz, der den Erfolg für möglich hält und sich mit dem Risiko der Verwirklichung abfindet (nach W04). Hier mögen sich alle diejenigen, die die Jahr 2000 Probleme nicht ernst nehmen oder ihrer Informationspflicht nicht nachkommen oder die notwendigen Maßnahmen zur Abwendung der Gefahr unterlassen, fragen, ob man ihnen in naher Zukunft nicht Eventualvorsatz unterstellen wird. Dagegen wird Fahrlässigkeit begründet durch die ungewollte Verwirklichung des gesetzlichen Tatbestandes, und zwar durch pflichtwidrige Vernachlässigung der im Verkehr erforderlichen Sorgfalt. Wenn die gebotene Sorgfalt in ungewöhnlich hohem Maß verletzt wird, spricht man von grober sonst von leichter Fahrlässigkeit. Ob das mit Wissen um den objektiven Tatbestand geschieht oder unbewußt ist für die Begründung der Fahrlässigkeit unerheblich. Diese Frage stellt sich dagegen im Strafrecht bei der Zumessung der Strafe (nach W04). Bei der Versicherung der Vermögensschaden-Haftpflicht für Geschäftsleiter stellt wissentliche Fahrlässigkeit oft einen Ausschlußgrund dar. Auch hier sollte man sich fragen, ob man nicht verpflichtet ist, die möglichen Jahr 2000 Problemen sorgfältig zu bearbeiten. Wer erst 1998 oder danach mit der Bearbeitung beginnt, dem kann grobe oder wissentliche Fahrlässigkeit unterstellt wer-

Der Autor ist kein Rechtsanwalt. Die folgenden Ausfuhrungen geben ausschließlich seine persönliche Meinung wieder. Hinweise auf mögliche Fehler und Auslassungen sind willkommen. Die folgende Darstellung soll nicht als Beratung in rechtlicher Hinsicht interpretiert werden. Alle Leser werden gebeten, ihre besondere Lage mit ihrem Anwalt für alle im folgenden genannten Problemkreise durchzusprechen.

6.1 Haftung aus Verschulden und Gefährdung

175

den. Es helfen ihm dann im Schadensfall weder Allgemeine Geschäftsbedingungen noch Versicherungen. Denn in Allgemeinen Geschäftsbedingungen kann die deliktische Haftung nur auf Vorsatz und grobe Fahrlässigkeit beschränkt werden. Umgekehrt wird man in den Geschäftsbedingungen von Versicherungen regelmäßig finden, daß gerade dann nicht geleistet wird.

6.1.2

Haftung aus Verschulden

Die vertragliche Haftung ist von dem Ziel bestimmt, daß der geschäftliche Austausch entweder nicht oder gleichwertig erfolgt. Daher wird vom Verkäufer gehaftet auch ohne Schaden beim Käufer und es ist nicht erheblich, ob der Verkäufer den Mangel verursacht oder verschuldet hat. Erst die sogenannte „positive Vertragsverletzung" fuhrt das Verschulden in den Streit ein, wobei dann das Verhalten des Verkäufers vorsätzlich oder fahrlässig zu einer Abweichung von den vertraglichen Vereinbarungen beitragen muß. Die Haftung aus Verschulden zieht aber weitere Kreise, weil auch nach Ablauf vertraglicher Gewährleistungsfristen und trotz allgemein gehaltener Haftungsausschlußklauseln und auch gegenüber Personen und Unternehmen zu haften ist, mit denen gar kein Vertrag abgeschlossen wurde, die aber über einen Wiederverkäufer beliefert wurden. § 823 BGB - Schadensersatzpflicht (1) Wer vorsätzlich oder fahrlässig das Leben, den Körper, die Gesundheit, die Freiheit, das Eigentum oder ein sonstiges Recht eines anderen widerrechtlich verletzt, ist dem anderen zum Ersätze des daraus entstehenden Schadens verpflichtet. (2) Die gleiche Verpflichtung trifft denjenigen, welcher gegen ein den Schutz eines anderen bezweckendes Gesetz verstößt. Ist nach dem Inhalte des Gesetzes ein Verstoß gegen dieses auch ohne Verschulden möglich, so tritt die Ersatzpflicht nur im Falle des Verschuldens ein.

Die erste Kategorie der Schäden umfaßt Personenschäden: Tod, Ausfall körperlicher Funktionen, Beeinträchtigung der körperlichen oder seelischen Gesundheit und der persönliche Freiheit. Im Zusammenhang mit Jahr 2000 Problemen sind derartige Personenschäden möglich in gestörten Produktionssystemen, Verkehrsleitsystemen oder medizinischen Systemen. Verletzungen des Eigentums sind Sachschäden, wobei zuweilen in der Rechtsprechung auch schon eine erhebliche Störung des Funktionszusammenhangs von EDV-Systemen oder auch von einzelnen Programmen als Sachschaden angesehen wird. Die Existenz magischer Zahlen in Programmen oder der regelmäßige Abbruch eines Programmes oder eines Betriebssystems kann in dieser Weise gewertet werden. Auch der Besitz korrekter Datenbestände ist ein Eigentumsrecht, in das

176

6 Die EDV nach dem Jahr 2000 - Gefahren

durch Programme mit Jahr 2000 Problemen durch Verfälschung von Daten eingegriffen werden kann. Ein sonstiges Recht ist z.B. das Recht auf einen eingerichteten und ausgeübten Gewerbebetrieb, in das durch Programme, die für diesen Betrieb geschrieben wurden, eingegriffen wird, wenn diese nun mit zahlreichen Jahr 2000 Problemen behaftet sind. Es wird übrigens nicht nur für den direkten Schaden sondern auch für alle Folgen, die mit einem Schaden verbunden sind, gehaftet. Allerdings wird für Folgeschäden, die mit einem verschuldeten Mangel verbunden sind, nur bei einer vertraglichen Beziehung gehaftet. Andererseits wird auch für Mangelfolgen gehaftet, wenn gegen ein Schutzgesetz verstoßen wurde. Es gibt unmittelbar wirksame Schutzgesetze, wie z.B. das Arzneimittelgesetz oder das Datenschutzgesetz, das übrigens auch die Verfälschung persönlicher Daten sanktioniert. Und es gibt mittelbare - nur über den genannten Paragraphen - mit Haftungsfolgen ausgestattete Gesetze und Verordnungen, etwa die Reichsversicherungsordnung, die in dieser Weise den Arbeitgeber für die pünktliche und korrekte Abführung von Beiträgen der Arbeitnehmer gegenüber der Sozialversicherung haften läßt oder das Aktiengesetz, das auf diese Weise die Haftung für unrichtige Angaben über das Gesellschaftsvermögen begründet: § 400 AktG - Unrichtige Darstellung (1) Mit Freiheitsstrafe bis zu drei Jahren oder mit Geldstrafe wird bestraft, wer als Mitglied des Vorstands oder des Aufsichtsrats oder als Abwickler 1. die Verhältnisse der Gesellschaft einschließlich ihrer Beziehungen zu verbundenen Unternehmen in Darstellungen oder Übersichten über den Vermögensstand, in Vorträgen oder Auskünften in der Hauptversammlung unrichtig wiedergibt oder verschleiert

Generell wird über den Paragraphen §823 BGB auch für alle Straftaten gehaftet, insbesondere aber auch für die Veränderung elektronisch gespeicherter oder übermittelter Daten: § 303a StGB - Datenveränderung. (1) Wer rechtswidrig Daten löscht, unterdrückt, unbrauchbar macht oder verändert, wird mit Freiheitsstrafe bis zu zwei Jahren oder mit Geldstrafe bestraft. (2) Der Versuch ist strafbar.

Es haftet jeweils der Hersteller oder auch der Händler, wenn er keinen Hersteller namhaft machen kann. Es wird nicht nur für industriell hergestellte Produkte, sondern auch für Handwerksarbeiten, Gutachten und Dienstleistungen gehaftet. Dabei haftet ein Unternehmen auch für die Versäumnisse seiner Mitarbeiter.

6.1 Haftung aus Verschulden und Gefährdung

177

Es ist darüber hinaus ein Durchgriff des Geschädigten auf einzelne Arbeitnehmer oder leitende Angestellte möglich, wenn sie den Schaden persönlich verschuldet haben oder der Schaden aus ihrem persönlichen Verantwortungsbereich erwächst und wenn sie namentlich angegeben werden können. Der Geschädigte muß - so die Entwicklung der Rechtsprechung - heute nur noch seinen Schaden und den kausalen Zusammenhang mit einem Produktfehler beweisen, um seine Haftungsforderung zu begründen. Der Hersteller hat bezogen auf seine äußeren Verhältnisse die Beweispflicht, daß er den Anwender korrekt beraten, die Anwendungsumgebung gründlich untersucht und sowohl einen der Produktbestimmung gemäßen Gebrauch als auch einen vorhersehbarer Fehlgebrauch genügend beobachtet und vor Mißständen frühzeitig und ausreichend gewarnt hat. Also ist vom Hersteller zu erkennen, wenn Software bis zum Jahr 2000 und danach benutzt werden soll und es ist sowohl vor einer mangelnden Jahr 2000 Fähigkeit der Software als auch vor einer möglichen Eingabe von „magischen Zahlen" zu warnen. Eine Warnung, die erst im Jahr 1998 erfolgt, ist sicherlich verspätet und wirkt - hoffentlich - begrenzend für den Schaden aber nicht in der Weise, daß sie die Haftung für den Schaden ausschließt. Der Hersteller hat bezogen auf seine inneren Verhältnisse die Beweispflicht, daß er Konstruktion, Fabrikation, Instruktion seiner Mitarbeiter auf eine Risikominimierung für die Anwender seiner Produkte abgestellt hat. Gelingen ihm die Beweisführungen für seine äußeren und inneren Verhältnisse, so ist er von der Haftung entlastet. Die Jahr 2000 Probleme werden sicher eher durch Konstruktion, also Entwurf, einer Software in diese eingebracht als durch versehentliche Eingabe zweistelliger Datenfelder bei der Fabrikation, also Programmierung. Die Abbildung von Logik durch „magische Zahlen" ist sicher ein Fehler bei der Instruktion der Programmierer. Für die Konstruktion wird allgemein verlangt, das sich diese am Stand von Wissenschaft und Technik orientiert; also sind auch Produkte mit Jahr 2000 Problemen, die weit vor dem 1.1.1995 entstanden sind (B04), vorwerfbar fehlerhaft entworfen worden. § 852 BGB - Verjährung (1) Der Anspruch auf Ersatz des aus einer unerlaubten Handlung entstandenen Schadens verjährt in drei Jahren von dem Zeitpunkt an, in welchem der Verletzte von dem Schaden und der Person des Ersatzpflichtigen Kenntnis erlangt, ohne Rücksicht auf diese Kenntnis in dreißig Jahren von der Begehung der Handlung an.

Man sieht, kein Hersteller kann auf Verjährung hoffen, außer er bleibt unbekannt. Wenn ein Schaden im Laufe des Jahres 2000 oder auch davor auftritt, bleiben dem

178

6 Die ED V nach dem Jahr 2000 - Gefahren

Geschädigten 30 Jahre, den Hersteller zu ermitteln. Danach hat er drei Jahre Zeit, seine Forderung geltend zu machen.

6.1.3

Haftung im Innenverhältnis

Entsprechend dem BGB werden die Mitarbeiter eines Unternehmens über einen Dienstleistungsvertrag beschäftigt, der natürlich auch arbeitsrechtlich und tarifvertraglich ausgestaltet ist. Unselbständig Beschäftigte haften gegenüber ihrem Arbeitgeber bei Vorsatz und grober Fahrlässigkeit. Sie haften nicht für leichte Fahrlässigkeit bei gefahrengeneigter Arbeit. Bei anderen Arbeiten haften sie auch für leichte Fahrlässigkeit, wenn ihr Verschulden im Einzelfall das allgemeine Betriebsrisiko überwiegt. Ihre Haftung ist allerdings immer auf drei Monatsgehälter beschränkt. Bei einer entsprechend übermäßigen Haftungsbelastung durch Dritte hat ihr Arbeitgeber sie freizuhalten. Ein Mitarbeiter kann sich relativ leicht dadurch entlasten, daß er für den Umgang mit möglichen Jahr 2000 Problemen in seinem Bereich die Meinung seiner Vorgesetzten schriftlich einholt. Diese Haftungsbeschränkungen nach innen und außen gelten nicht für leitende Mitarbeiter, freie Mitarbeiter oder selbständige Berater des Unternehmens. Es hilft also Lösungsanbietern für Jahr 2000 Probleme nichts, wenn sie statt einen Werkvertrag einen Dienstleistungsvertrag anbieten, von dem sie annehmen, daß er für sie weniger riskant sei. Die Haftung aus einem Dienstleistungsvertrag ist scharf und verjährt erst nach 30 Jahren. Auch ein DV-Leiter sollte sich nicht mit einer angeblich für Arbeitnehmer nicht vorhandenen oder begrenzten Haftung beruhigen, wenn er seiner Informationspflicht über mögliche Jahr 2000 Probleme gegenüber dem höheren Management nicht nachkommen will. Externe Berater haften entweder über Werkvertrag aus positiver Vertragsverletzung oder direkt über Dienstleistungsvertrag für Schlechtberatung oder Nichtberatung. Ein EDV-Berater haftet, falls er dazu laut Vertrag Aussagen machen soll, sowohl für die Auswahl von Software und Systemen als auch für deren Qualität. Er hat auch eine nachvertragliche Warnpflicht. Er kann allerdings den Verjährungszeitraum beschränken. Wirtschaftsprüfer und Steuerberater werden mit haftungsrelevanten Jahr 2000 Problemen bei Jahresabschluß, Unternehmensbewertung und Krisenberatung konfrontiert. Sie haften auch für die Ergebnisse, die ihre EDV-Arbeitsmittel für ihre Mandanten erzeugen. Sie haften spätestens ab dem 1.1.1997 (B04). Die Haftung verjährt bei Wirtschaftsprüfern in fünf Jahren und bei Steuerberatern in drei Jahren. Falls sie bei ihren Mandanten nachträglich Probleme feststellen, haben sie vor diesen zu warnen, sonst beginnt die Verjährung nach Ablauf der ersten Frist erneut.

6.1 Haftung aus Verschulden und Gefährdung

179

Ein analoges Risiko haben Rechtsanwälte, die mit Vertragsgestaltung, Krisenberatung oder Prozeßführung befaßt sind. Die Geschäftsleitung eines Unternehmens haftet immer für vorhersehbare Gefahren für das Unternehmen, falls sie diesen Gefahren nicht mit der nötigen Sorgfalt entgegengetreten ist. Die Geschäftsleitung hat sich selbst zu entlasten; das wird ihr insbesondere dann nicht gelingen, wenn es sich um ein öffentlich bekanntes Problem handelt und Leitungsorgane in vergleichbaren Unternehmen ihrer Verantwortung gerecht geworden sind. § 93 AktG - Sorgfaltspflicht und Verantwortlichkeit der Vorstandsmitglieder (1) Die Vorstandsmitglieder haben bei ihrer Geschäftsführung die Sorgfalt eines ordentlichen und gewissenhaften Geschäftsleiters anzuwenden. Über vertrauliche Angaben und Geheimnisse der Gesellschaft, namentlich Betriebs- oder Geschäftsgeheimnisse, die ihnen durch ihre Tätigkeit im Vorstand bekanntgeworden sind, haben sie Stillschweigen zu bewahren. (2) Vorstandsmitglieder, die ihre Pflichten verletzen, sind der Gesellschaft zum Ersatz des daraus entstehenden Schadens als Gesamtschuldner verpflichtet. Ist streitig, ob sie die Sorgfalt eines ordentlichen und gewissenhaften Geschäftsleiters angewandt haben, so trifft sie die Beweislast. (6) Die Ansprüche aus diesen Vorschriften verjähren in fünf Jahren.

Es ist daran zu denken, daß sich diese Paragraphen sowohl auf Anwender als auch auf EDV und Elektronik-Hersteller in Form einer Aktiengesellschaft oder auch in Form einer Gesellschaft mit beschränkter Haftung beziehen: § 43 GmbHG - Haftung des Geschäftsführer (1) Die Geschäftsführer haben in den Angelegenheiten der Gesellschaft die Sorgfalt eines ordentlichen Geschäftsmannes anzuwenden. (2) Geschäftsführer, welche ihre Obliegenheiten verletzen, haften der Gesellschaft solidarisch für den entstandenen Schaden. (4) Die Ansprüche auf Grund der vorstehenden Bestimmungen verjähren in fünf Jahren.

Die Gesellschafter einer Personengesellschaft, einer Kommanditgesellschaft oder einer offenen Handelsgesellschaft sollten nach persönlicher Integrität ausgesucht werden, sonst verwirken die Mitgesellschafter ihren Haftungsanspruch: § 708 BGB - Sorgfaltspflicht des Gesellschafters Ein Gesellschafter hat bei der Erfüllung der ihm obliegenden Verpflichtungen nur für diejenige Sorgfalt einzustehen, welche er in eigenen Angelegenheiten anzuwenden pflegt.

180

6.1.4

6

Die ED V nach dem Jahr 2000 -

Gefahren

Haftung aus Gefährdung

Neben der und ergänzend zur allgemeinen, deliktischen Produkthaftung steht die Haftung aus dem Produkthaftungsgesetz. Es wird auch ohne Verschulden für Produkte mit Gefährdungspotential gehaftet, die einen Personenschaden oder einen Schaden an privat genutzten Sachen verursachen können. Es haftet neben dem Hersteller auch jeder Händler der Handelskette bis zum Verbraucher gesamtschuldnerisch. Der Geschädigte kann also im Bereich der Europäischen Union ein beteiligtes Unternehmen für seinen Schaden nach deutschem oder fremdem Recht in Anspruch nehmen. Jeder Verbraucher muß allerdings einen Sachschaden bis 1125 DM selbst tragen. Der Betrag liegt immerhin unter dem Preis für einen PC. Im Interesse des Verbraucherschutzes haben Hersteller und Händler eine Warnpflicht und - das ist strittig - eine Rückruf- und Reparaturpflicht. Falls sie keine Warnung vor Gefahren im Umgang mit ihren Produkten herausgeben oder ihre Warnungen nicht ausreichend dokumentieren und ein Personenschaden auftritt, können sie möglicherweise über Eventualvorsatz auch strafrechtlich belangt werden. Als weitere Ergänzung zur bisher beschriebenen Produkthaftung steht die Haftung aus dem Produktsicherungsgesetz vom 23.8.1997. Es wird darin wiederum auch ohne Verschulden für Produkte mit Gefährdungspotential gehaftet, die einen Personenschaden verursachen können. Warn und Rückrufaktionen eines Unternehmens können hierin durch nationale oder europäische Behörden angeordnet werden.

6.1.5

Was folgt daraus?

=> Alle Produkte eines Unternehmens sind auf Jahr 2000 Risiken zu überprüfen. => Auch alle Dienstleistungen von leitenden Angestellten und Beratern sind auf entsprechende Risiken zu überprüfen. Sowohl ein aktives Tun als auch ein Unterlassen können riskant sein. => Falls Personen oder Sachen gefährdet werden können, sind alle Anwender vor der möglichen Gefahr zu warnen und es ist, wenn möglich, durch eine neue Produktversion oder durch Austausch eines im Sinne der Jahr 2000 Probleme defekten Teils die Gefahr abzuwenden. => Im Haftungsfall kann der Anwender sich nicht sicher sein, daß er sich rechtlich durchsetzt, daß alle Kosten belegbar sind und daß alle Folgekosten anerkannt werden. => Es wird immer höchst unsicher sein, ob ein Lieferant, Hersteller oder Mitarbeiter über die nötige Finanzkraft für einen vollen Schadenersatz verfügt, insbesondere wenn dieser von mehr als einer Seite in Anspruch genommen wird.

6.2

Veränderungen im Softwaremarkt

6.2

181

Veränderungen im Softwaremarkt

•

Management von Software

•

Vermarktung von Software

•

Pflege von Software

•

Berufsrecht und Berufsethik

•

Was folgt daraus?

Durch die Jahr 2000 Probleme und durch die Versuche ihrer Bewältigung ergeben sich Veränderungen im Software-Markt, bei der Entwicklung und der Vermarktung von Software. Zu einer Gefahr für Unternehmen und ihre Mitarbeiter werden die Veränderungen allerdings nur, wenn man sie nicht zur Kenntnis nimmt oder sich nicht auf sie einstellt. Mancher mag als Gefahr für Freiheit und Kreativität der Programmierer alle die Bestrebungen ansehen, die berufliche Softwareentwicklung rechtlichen und ethischen Regeln unterwerfen wollen

6.2.1

Management von Software

Spätestens im Jahr 2000 wird keine Unternehmensleitung und kein Controller und wahrscheinlich auch keine Rechtsabteilung die wirtschaftliche Bedeutung von Software mehr übersehen können, sowohl ihre Bedeutung für das Funktionieren wirtschaftlicher Prozesse als auch die Bedeutung des Kapitals, das an sie gebunden ist. Daher wird man die Entwicklung von Software, die Pflege von Software und den Einsatz von Software verstärkt kontrollieren wollen. Ihren Einsatz wird man auch schon deswegen mißtrauisch überwachen, weil bis weit in das Jahr 2001 damit zu rechnen ist, daß durch die verbleibenden Jahr 2000 Probleme Fehlfunktionen und Datenverfälschungen in kritischen Bereichen wie Finanzwesen, Verkaufsabwicklung oder Rechnungswesen auftreten werden. Management von Software wird das Thema in den ersten Jahren des neuen Jahrhunderts sein. Das wird dazu fuhren, daß sich mehr EDV-Sachverstand in Unternehmensleitungen finden wird. Wenn nicht schon wegen der Jahr 2000 Probleme dann wegen dieser neuen Orientierung ist ein Generationswechsel bei EDV-Leitern zu erwarten, der die Manager abtreten läßt, die bei EDV hauptsächlich an Hardware gedacht haben. Das Management von Software-Projekten mußte sich schon immer der Herausforderung stellen, die Komplexität des Projektes zu beherrschen, ohne die Kreativität

182

6 Die ED V nach dem Jahr 2000 - Gefahren

der Entwickler zu blockieren. Deren Kreativität wird man nach dem Jahr 2000 allerdings eher gering schätzen oder sogar fürchten, also ist mit einer Stärkung der Verwaltung im Projekt zu rechnen. Der Wille, zu kontrollieren, wird da sein und auch die Fähigkeit, effektiv zu kontrollieren, wird sich schnell entwickeln, und zwar durch den mit den Jahr 2000 Projekten verbundenen Werkzeugeinsatz zur Analyse, Pflege und Test und durch den damit erreichten Informationsgewinn für die Projektleiter. Softwareentwicklung und -pflege ist nicht nur teuer und zeitraubend, sondern auch mit zahlreichen Risiken verbunden - wie gerade die Jahr 2000 Probleme zeigen. Zudem wächst die Wahrscheinlichkeit mit fortschreitendem EDV-Einsatz in einem Unternehmen auf riskante Projekte zu stoßen: „All the low-risk, high-benefit projects were done in the '70s. Today, all projects have inherent risks. If you overcome them, there may be real benefits." „Alle die Projekte mit kleinem Risiko und hohem Ertrag wurden in den 70er (Jahren) durchgeführt. Heute bringen alle Projekte Risiken mit sich. Wenn Sie damit zurecht kommen, dann sind wirkliche Erträge möglich." (L01) Andererseits werden sich durch die Integration von Risikobetrachtungen in Softwareprojekte einige Projektaktivitäten stärker an bürokratischen Modellen orientieren. Insbesondere wird sich das in den Bereichen Design, Qualitätssicherung sowie Abnahme von Software und bei der Verwaltung des EDV-Betriebes auswirken.

6.2.2

Vermarktung von S oftware

Um Jahr 2000 Probleme zu vermeiden, werden alte EDV-Systeme und Anwendungen, ob selbst erstellt oder fremd bezogen, wo eben möglich durch Anwendungspakete, sogenannte Standardsoftware, ersetzt. Ein Anwendungspaket wird man danach auswählen, in welchem Umfang es die bisherigen Programme überflüssig macht; je mehr bisherige Funktionen es abdecken kann desto besser. EDV-Hersteller werden schmerzlich erfahren müssen, daß man mit dem Wechsel der Anwendungssoftware auch die Hardwareplattform wechselt, einerlei ob diese die Jahr 2000 Fähigkeit besitzt oder nicht. Entscheidungen über Hardware werden von der bevorzugten Software abhängig gemacht. Softwarehäuser ohne Jahr 2000 fähige Produkte werden vom Markt verschwinden; einige nicht Jahr 2000 fähige Produkte eines Softwarehauses werden auch den Marktchancen der übrigen Produkte des gleichen Hauses negativ beeinflussen. Softwarehäuser mit EDV-Dienstleistungen werden an diejenigen Lösungsanbieter Kunden verlieren, die erfolgreich einen großen Teil der Software eines Anwenders umgestellt haben. Softwarehäuser, die schon heute bei einem Kunden gut einge-

6.2

Veränderungen im Softwaremarkt

183

fuhrt sind, werden mit erfolgreichen Jahr 2000 Projekten auch die Chance erhalten, ihren Kunden einen kompletten Softwareservice, ein Outsourcing für Rechnerbetrieb und Programmpflege anzubieten. Viele Unternehmensleitung werden sich nicht nur von bisherigen EDVAnwendungen verabschieden wollen, sondern gleich von der ganzen EDVAbteilung. Enttäuschung über nicht behobene Jahr 2000 Probleme, verringerte Wartungsaufgaben durch verstärkten Einsatz von Anwendungspaketen, die erwiesene Fähigkeit von Lösungsanbietern, Jahr 2000 Projekte zu durchzuführen, werden dem Outsourcing einen Boom bescheren. Insbesondere die Lösungsanbieter, die sich als lokale Vertretung preisgünstiger Programmierbüros aus Osteuropa oder Asien etablieren können, werden Softwarepflege erfolgreich als externe Dienstleistung anbieten können. Es wird also eine Marktbereinigung stattfinden, die großen Software- und Servicehäuser werden weiter wachsen und die Lösungsanbieter werden den Softwaremarkt in Deutschland umgestalten. Um auch großen Anwendern eine Komplettservice bieten zu können, sind verstärkt Software- und Service-Lieferketten und Unternehmensfusionen zu erwarten.

6.2.3

Pflege von Software

Die Umstellung auf Jahr 2000 Fähigkeit bei selbst erstellten Programmen führt zu den größten Pflegeprojekten, die die betroffenen Firmen bisher durchgeführt haben. Die Umstellung unternehmenskritischer Anwendungen wird man hoffentlich bis Ende 1999 durchfuhren; danach gilt es aber, noch die weniger kritischen Anwendungen umzustellen - und bis zum Ende des Jahres 2001 ist auch die EUROWährung zu unterstützen. Diese Pflegeaktivitäten führen faktisch zu großen Investitionen in bisherige EDVSysteme und in der bisher weit überwiegenden Zahl in Host-Systeme. PC-Systeme und Anwendungen im PC-Netz erhalten nicht die gleiche Aufmerksamkeit, daher werden sie tendenziell mindestens genau so viele Jahr 2000 Probleme produzieren wie nicht umgestellte Anwendungen auf Host-Systemen, zumal die Umstellung aller - auch der vom PC-Nutzer selbst programmierten Anwendungen - nur schwer zu koordinieren ist. Beide Gründe, Host-Investition und PC-Probleme, werden zu einer Renaissance zentraler Rechner und damit auch generell einer Zentralisierung der EDV führen. Daten und Programme wird man zentral halten und nur Kopien ins Netz geben: dezentrale Anwendungen bei zentralem Management. Man wird auch überlegen, warum an einem spezialisierten Arbeitsplatz das Universal Werkzeug PC stehen muß. Alle Arten von Netzwerk-Computer werden eine neue Chance erhalten.

184

6 Die ED V nach dem Jahr 2000 - Gefahren

Die Pflege bestehender Systeme wird man nur durchfuhren können, wenn genügend Werkzeuge und Programmierer zur Verfugung stehen. Die meisten Werkzeuge unterstützen und die meisten Programmierer in den Unternehmen kennen COBOL. Durch Neueinstellung von COBOL-Programmierer für Jahr 2000 Projekte wird sich auch ihr relatives Gewicht in den Unternehmen weiter verstärken. Die Jahr 2000 Projekte werden zu einer COBOL-Renaissance fuhren und diese Programmierer werden dann auch daran erinnern, daß Anwendungen für ClientServer und auch Anwendungen für das World Wide Web ebenso gut in COBOL wie in anderen Sprachen programmiert werden können. Für einige Jahre wird sich in der EDV die Haltung durchsetzen: keine Experimente. Die Konsolidierung von Anwendungen, die ein Unternehmen noch selbst pflegen will, wird Vorrang haben vor der Beschaffung von EDV-Systemen und der Einführung von Programmiermethoden, die gerade modern sind. Schon heute werden in vielen Unternehmen die EDV-Budgets durch Jahr 2000 Projekte derart beansprucht, daß kein Geld für eine Modernisierung verbleibt.

6.2.4

Berufsrecht und Berufsethik

In der breiten Öffentlichkeit, besonders im Fernsehen, werden Softwareentwickler meist als Hacker dargestellt, die mit besonderer Macht aber ohne besondere Moral ausgestattet sind. Dieses negative Image wird sich noch deutlich verstärken und sich auf alles ausdehnen, was mit Computer und Programmen zu tun hat, wenn Jahr 2000 Probleme der gesamten Gesellschaft das wirtschaftliche Leben schwer machen. Es ist anzunehmen, daß der Staat daher und wegen seiner eigenen Jahr 2000 Probleme eine kontrollierte Berufsausübung für Softwareentwickler fordern wird. Er wird auch darauf hinweisen, daß der gern gebrauchte Ausdruck „Software Engineering" eine Professionalisierung andeutet und diese in einer Form anstrebt, wie sie bei den Ingenieuren schon erreicht ist. Um einer gesetzlichen Regelung des Berufsrechts und einer durchaus möglichen Verkammerung von Softwareentwicklern zuvor zu kommen, sollten sich diese selbst möglichst bald eine strikte, aber realistische Berufsethik geben. Einen ersten Schritt in die Richtung einer strikten, aber leider unrealistischen Ethik hat die Gesellschaft für Informatik (Gl) schon getan. Ihre „Ethischen Leitlinien" für die Mitglieder der Gesellschaft sollen hier auszugsweise wiedergegeben und kommentiert werden. „Art. 1 Fachkompetenz Vom Mitglied wird erwartet, daß es seine Fachkompetenz nach dem Stand von Wissenschaft und Technik ständig verbessert.

6.2

Veränderungen im Softwaremarkt

185

Art. 2 Sachkompetenz Vom Mitglied wird erwartet, daß es sich über die Fachkompetenz hinaus in die seinen Aufgabenbereich betreffenden Anwendungen von Informatiksystemen soweit einarbeitet, daß es die Zusammenhänge versteht. Art.3 Juristische Kompetenz Vom Mitglied wird erwartet, daß es die einschlägigen rechtlichen Regelungen kennt, einhält und an ihrer Fortschreibung mitwirkt. Art.5 Arbeitsbedingungen Vom Mitglied in einer Führungsposition wird zusätzlich erwartet, daß es für Arbeitsbedingungen Sorge trägt, die es Informatikerinnnen und Informatikern erlauben, ihre Aufgaben am Stand der Technik kritisch zu überprüfen." (G04) In den Erläuterungen zu den Richtlinien wird der „Stand von Wissenschaft und Technik" dahingehend beschrieben, daß „geboten ist, was nach neusten wissenschaftlichen Erkenntnissen für erforderlich gehalten wird.", und mit dem „Stand der Technik" wird „das Gebotene an die Front der technischen Entwicklung verlagert, für die allgemeine Anerkennung und die praktische Bewährung alleine nicht ausreicht." Beide Begriffe werden von den „allgemein anerkannten Regeln der Technik" als der „Durchschnittsmeinung der Praktiker" abgegrenzt. Eigentlich müßten nun alle Mitglieder der Gesellschaft für Informatik verschämt aus dieser austreten. Denn die erste offizielle Stellungnahme der Gl zum Jahr 2000 Problem stammt vom September 1997. Die ethischen Leitlinien wurden übrigens am 13.1.1994 verabschiedet. Die Wissenschaft kann Jahr 2000 Probleme wohl kaum wissenschaftlich ernst nehmen. Die Technik war sicher schon 1940 auf dem Stand zu erklären, daß eine Jahreszahl aus vier Ziffern bestehen sollte und auch in 2 Bytes (16 Bit) abgespeichert werden kann. Eigentlich sollte es auch kein Unternehmen mit einem GI-Mitglied in Führungsposition mehr geben, in dem nicht über ein Jahr 2000 Projekt die bisherige Arbeit am Stand der Technik gemessen wird. Eine mögliche staatliche Einmischung in die Softwareentwicklung wird für diejenigen EDV-Fachkräfte, die Informatiksysteme entwerfen und deren Entwicklung überwachen, also nicht für die eigentlichen Programmierer, besondere Ausbildungsgänge und Prüfungen sowie Bestellungen vorsehen. Man wird sich anfangs dabei auf die Systeme beschränken, die als Werkzeuge für Ärzte und Ingenieure dienen oder bei Behörden oder in untemehmenskritischen Bereichen, die noch zu definieren sind, eingesetzt werden sollen. Im übrigen nehmen die GI-Leitlinien vorweg, was in diesem Fall in der Ausbildung zu erwarten ist: Technik, Anwendung, Recht, ethische Grundsätze als besondere Berufspflichten. Andererseits ermöglichen erst bestimmte berufliche Prozeduren und die Kontrolle ihrer Einhaltung die Versicherbarkeit des beruflichen Haftpflichtrisikos für Vermögensschäden.

186

6 Die ED V nach dem Jahr 2000-

Gefahren

Ein Andeutung dieser möglichen Entwicklung ist die Diskussion, ob PC-Systeme nur in Meisterbetrieben zusammengebaut und repariert werden dürfen. Das würde für Tausende von PC-Händlern eine spezielle Ausbildung und Prüfung und eine Pflichtmitgliedschaft in der Handwerkskammer bedeuten.

6.2.5

Was folgt daraus?

=> Nachdem schon heute alle technischen Möglichkeiten, Methoden und Werkzeuge, zur Entwicklung und Verwaltung von Software, in großer Zahl am Markt vorhanden sind, gilt es in der Zukunft, so unter diesen Möglichkeiten auszuwählen, daß das durch die Jahr 2000 Probleme stark beschädigt Image der gesamten EDV-Branche wieder verbessert werden kann.

7

Die EDV nach dem Jahr 2000 Die Chance

7.1

Das Ende der Softwarekrise

Die Entschärfung der Jahr 2000 Zeitbombe fuhrt auch aus der Softwarekrise. Wenn Sie zur Verwirklichung dieser, meiner Vision beitragen wollen, legen Sie Ihr Jahr 2000 Projekt so an, daß gleichzeitig die allgemeine Softwareentwicklung bei Ihnen optimiert wird. Immerhin werden die Ergebnisse von Jahr 2000 Projekten auf jeden Fall in erneuerter Hardware, Betriebssystemen, Anwendungen und in einer Investition in Methoden und Werkzeuge bestehen. Schon vor 30 Jahren wurde die „Softwarekrise" festgestellt, als Krise der Softwareentwicklungsprojekte. Bis jetzt hat sich daran nichts geändert, denn auch heute kann in den allermeisten Fällen Software in annehmbarer Qualität nur erstellt werden, wenn die Zeitdauer eines Projektes oder der Kostenrahmen eines Projektes überschritten wird. Oft genug wird nur eines dieser drei Kriterien erfüllt: Kosten, Termine, Qualität - und die beiden anderen eben nicht. Das ideale Projekt gibt es nur sehr selten. Deswegen sind Jahr 2000 Projekte so kritisch zu betrachten, da der Termin, 31.12.1999, für die Umstellung unternehmenskritischer Anwendungen unbedingt eingehalten werden muß und das Qualitätskriterium, die Beseitigung von Datumsproblemen bei diesen Anwendungen, vollständig erfüllt sein muß. Wahrscheinlich werden daher die Jahr 2000 Projektkosten besonders hoch sein.

188

7 Die ED V nach dem Jahr 2000 - Die Chance

Abbildung ¡5: Ideales Projekt, reales Projekt und Jahr 2000 Projekt

Also sollten Sie die wahrscheinlich zwangsläufig - entsprechend dem Stand der Kunst der heutigen Software-Wartung - entstehenden großen Ausgaben so investieren, daß ein langfristig wirksamer Nutzen entsteht. Ein Teil eines jeden Jahr 2000 Projektes besteht in der Erneuerung von EDVSystemen und Anwendungen. Ob Sie es wollen oder nicht, die Kürze der bis zum Jahr 2000 verbleibenden Zeit und die Unmöglichkeit Anwendungen umzustellen, die niemand mehr versteht, werden Sie zwingen, neue Hardware, neue Betriebssysteme und neue Anwendungen des gleichen oder eines anderen EDV-Herstellers einzusetzen. Insbesondere wird man Anwendungen oder Anwendungsteile dann aussondern oder ersetzen, wenn keine Fachabteilung bereit ist, das Budget für Umstellungen mit zutragen. Wenn Sie sich doch zu Umstellungen entschließen, wird es ohne methodisches Vorgehen und ohne Werkzeugeinsatz nicht gehen. Die dafür nötige Analyse von Anwendungen und EDV-Systemen führt dann auch zur Beseitigung von unnützen

7.1 Das Ende der Softwarekrise

189

Programmen, Bibliotheken und Programmtexten oder der Neuprogrammierung einzelner, wartungsintensiver Programme. Die intensive Nutzung von Werkzeugen in Jahr 2000 Projekten wird zu drei Effekten fuhren: •

Einmal werden die Werkzeuge mehr oder minder stumpfsinnige Routinetätigkeiten für die Wartungsprogrammierer erledigen. Die Programmierer werden schon deswegen nicht mehr zum alten Arbeitsstil zurück wollen.

•

Zum Zweiten definiert die durchgängige Werkzeugnutzung - in vielen Unternehmen erstmals - eine Wartungsumgebung für Analyse, Änderung und Test, die in künftigen Wartungsprojekten weiter genutzt werden kann. Diese definierte Wartungsumgebung wird immer wieder Effektivität und Qualität erhöhen können.

•

Drittens erzeugen Werkzeuge zur Analyse eine Datenbank mit Informationen über Anwendungen und EDV-Systeme, die nicht nur für Wartung und Betrieb der EDV-Systeme, sondern auch für Neuentwicklungen nützlich ist. Je mehr Anwendungen schon vorhanden sind, auf desto mehr Schnittstellen muß bei neuen Entwicklungen Rücksicht genommen werden.

Sowohl die Beseitigung von Altlasten als auch die Rationalisierung des Wartungsprozesses werden zur Einsparung von Wartungszeit ab dem Jahr 2002 beitragen; denn bis Ende des Jahres 2001 wird die vorhandene Programmierkapazität noch für Nachbesserungen in Jahr 2000 Projekten und die Umstellung auf die EUROWährung blockiert. Heute beschäftigen sich etwa 80% der Programmierer eines Unternehmens mit Programmwartung. Wenn nur die Hälfte des bisherigen Aufwandes für die Wartung nicht mehr benötigt wird, so wird sich das Zeitpotential für Neuentwicklungen auf 60% erhöhen, also verdreifachen lassen. Damit wird sich schon bald der Änderungsstau vor den EDV-Abteilungen beseitigen lassen. Wenn es Ihnen tatsächlich gelingt, durch ein Jahr 2000 Projekt alle wesentlichen Datumsprobleme in Ihrer Software zu vermeiden, so haben Sie damit auch die Vorteile guten Managements bewiesen und können der romantischen Einstellung vieler Programmierer entgegentreten, die da besagt: drei Softwaregenies in einem von Ihnen selbst organisierten Prozeß erreichen das Gleiche wie ganze Abteilungen von Programmierern. Also dürfen sich Ihre Jahr 2000 Projektleiter nicht als Projektverwalter verhalten, sondern sie sollten es verstehen, Ihre Mitarbeiter durch Zielvorgabe, durch gemeinsame Überwindung von Schwierigkeiten und durch Orientierung auf die nächsten Schritte im Projekt, zum Erfolg zu führen. Erfolgreiche Jahr 2000 Projekte werden auch dazu führen, daß Sie die Autorität über alle EDV-Aktivitäten in Ihrem Unternehmen wiedergewinnen. Der Softwareund Datenbestand wird neben dem Hardwareinventar dargestellt. Die Wartung von

190

7 Die ED V nach dem Jahr 2000 - Die Chance

Programmen bekommt den Wert offiziell beigemessen, den sie kostenrechnerisch schon immer hatte. Wartung und Entwicklung kann durch die neu gewonnenen Informationen realistisch an Kosten und Nutzen orientiert werden. Die Zuständigkeit für Wartungsaufgaben wird umfassend geklärt. Die Motivation der Wartungsprogrammierer - und das sind heute die Mehrzahl der Programmierer - wird gesteigert. Die Kooperation mit den EDV-Nutzern entwickelt sich auf einer neuen Basis.

7.1.1

Schlußfolgerungen und Ausblick

=> Mit dem Abschied von vielen alten Anwendungen ist auch der Abschied von zahlreichen Programmiersprachen und Programmtexten verbunden. Vielleicht sollten diese als historisches Zeugnis in einem Softwaremuseum für die Nachwelt erhalten werden. => Die Jahr 2000 Gefahren für die Wirtschaft beweisen die Abhängigkeit von Software und EDV. Diese, auch nach dem Jahr 2000 noch wachsende, Abhängigkeit wird sich nur ertragen lassen, wenn die EDV-Systeme ausfallsicher und fehlertolerant angelegt sind. Für Hardware, Betriebssystemfunktionen, Netzwerke und Datenbanken ist dieses Problem schon technisch gelöst; der umfassende Einsatz der entsprechenden Technologie steht noch aus. => Die immerwährende Verfügbarkeit von Anwendungsprogrammen wird aber das Problem für die ersten Jahrzehnte des neuen Jahrhunderts bleiben. Seine Lösung wäre dann das nächste Jahrhundertereignis in der EDV.

8

Quellen

AOl

Am. Assoc.: Variable www.aavso.org/jd.html

A02

Sicherung Ihrer Aktiva gegen Folgen krimineller Handlungen. Frankfurt 1996, Prospekt, AIG Europe VK-96

A03

Millennium Insurance. Frankfurt 1997, Prospekt, AIG Europe Risk Management Division

B01

GT Becker: RighTime. Dallas -gtbecker/

Star

Observers.

Cambridge

1995, Artikel-Internet

1997,

Artikel-Internet,

rampages.onramp.net/

B02

Serge Bouwens: Year 2000 Issues List. 1995, Artikel-Internet, [email protected]

B03

D. Bartholomew: Time's Running Out. 1996, Artikel-Zeitschrift, Information Week 565 30 ff.

B04

Michael Bartsch: Software und das Jahr 2000 - Rechtsgutachten für die Kölnische RückVersicherungsgesellschaft AG. Köln 1997, Vortrag, Bartsch und Partner Tagung am 3.7.1997

B05

Richard Bergeon: Zum positiven Umgang mit dem Jahr-2000-Problem. 1996, Artikel-Zeitschrift, Data Dimensions Millennium Journal April 1996

C01

Code of Practice London. 1997, Artikel-Internet, CSSA, www.cssa.co.uk/cssa/

C02

Arnd Pählig: Marktübersicht 2000. 1996, Buch Markus Kuklovsky, CSC Ploenzke

D01

Richard Bergeon: 2-Digit or 4-Digit Years? 1996, Artikel-Internet, Data Dimensions The Millennium Journal Vol. III.III, August 1996

D02

Ernst Denert: Software-Engineering. Berlin 1991, Buch J. Siedersieben, SpringerVerlag 4-5

D03

Veranstaltungsplan 1997. Prospekt, Deutsche Informatik Akademie

G01

Information Technology Meets the Year 2000: Preparing for the Inevitable Stamford 1996, Buch, Gartner Group, SPR #5309

G02

Volker Gruhn: Das Jahr-2000-Problem. Bonn 1997, Buch, Subhash Chavan, Addison-Wesley

G03

Hans Gliss: Risiko Jahrtausendwechsel - rechtzeitig vorbeugen. Frechen 1997, Artikel-Zeitschrift Datakontext-Fachverlag, Lohn + Gehalt 2/97 27

G04

Ethische Leitlinien der Gesellschaft für Informatik. Bonn 1994, Prospekt, Gl, [email protected]

192

8

Quellen

HOI

Peter Haase: Y2K alias J2P. Bonn 1997, Artikel-Zeitschrift, Blätter Verlagsgesellschaft Blätter für dt. u. internat. Politik 8-97, 922 bis 924

H02

R.L. Hitchens: Year 2000 carries potential Time Bomb for DP. 1991, ArtikelZeitschrift, National Underwriter... 95, 7, 11 und 31

HO3

Andrew Hamme«: Year 2000 - A Guide to Software Tools. 1996, Buch, Bloor Research 3

H04

Ian Hugo: Languages / Laugh or Cry? Reading 1996, Artikel-Zeitschrift, Taskforce 2000 Millennium Watch Vol. 1 Nr. 1, 7 bis 8

H05

John Huntress: The Year 2000 and Embedded Systems: For Most Businesses, This Does Not Have to be a Major Problem. 1997, Artikel-Internet, Year 2000 Information Center: [email protected]

101

Draft Standard for Year 2000 Terminology. www .computer, org/standard

102

Bob Cohen: ITAA's Year 2000 Outlook. Arlington 1997, Artikel-Internet, The Information Technology Association of America, www.itaa.org, Vol. 2, 31

103

Bob Cohen: ITAA's Year 2000 Outlook: G-7 to Conduct Y2K Conference. Arlington 1997, Artikel-Internet, The Information Technology Association of America, www.itaa.org Vol. 2, 23

104

Umfrage und Pressemeldung vom 15.8.1997. Frankfurt 1997, Artikel-Internet www.initiative2000.de

105

Bob Cohen: ITAA's Year 2000 Outlook: Manufacturers May Grind Gears over Y2K Dates. Arlington 1997, Artikel-Internet, The Information Technology Association of America, www.itaa.org Vol. 2, 25

106

ISIS Jahr-2000 Studie. München 1997, Prospekt, Nomina

107

ISIS Special Report. Jahr-2000-Umstellung. München 1997, Buch, Nomina

108

ISIS Studie. Jahr-2000-Anbieter. München 1997, Buch und Datenbank, Nomina

J01

Peter de Jager: You've www.year2000.com

J02

Capers Jones: The global economic Impact of the Year 2000 Software Problem. Burlington 1997, Artikel-Internet, Software Productivity Research, Inc. www.spr.com, 42

K01

Peter G.W. Keen: Year 2000: Give up, move on - now 1997 Artikel-Internet Computerworld

K02

Gerhard Knolmayer: Das Jahr 2000 Problem: Medien-Spektakel oder Gefährdung der Funktionsfähigkeit des Wirtschaftssystems. 1997, Artikel-Zeitschrift, Verlag Vieweg, Wirtschaftsinformatik, Heft 1, 39. Jahrgang, 7 bis 18

K03

Heinz-Dieter Klein: Software-Bewertung in der Handelsbilanz bei Herstellern und Anwendern. Heidelberg 1997, Vortrag, Aktion 2000 - 1.Tagung 24.6.1997

got

to

be

1997, Artikel-Internet,

Kidding!

1997,

IEEE,

Artikel-Internet,

8 Quellen

193

K04

Gerhard Knolmayer: Determining work units in Year 2000 maintenance projects. Bern 1997, Artikel-Zeitschrift, Dieter Spahni Institut fur Wirtschaftsinformatik, Arbeitsbericht 100

K05

Daniel Keller: Jahr-2000-Klauseln. [email protected]

L01

Tim Lister: Right Place, Right Time. 1997, Artikel-Zeitschrift, IEEE Computer IEEE Software, März/April 1997, 134

M01

Miro Medek: Are there best practices specific to Year 2000? 1996, E-Mail, [email protected]

M02

N. Moran 2000. The Millennium Bomb. A Costly Problem Zeitschrift Chemical Week 158, 32 33 bis 34

M03

J.T. Murray: Computer in Crisis: How to avoid the Coming Worldwide Computer Systems Collapse. New York 1984, Buch, M.J. Murray, PBI

M04

Steve McCormack: Computer staff set to cash in on Year 2000 destruction bug. 1996, Artikel-Zeitschrift, Daily Mail, 19.9.1996

M05

H. Müller: Problem mit dem 1.1.2000? - Vorgehen bei der R+V. Frankfurt 1997, Vortrag, it Verlag Tagung am 26.2.1997

M06

Ian Mitchell: Call for plan to save London. 1997, Artikel-Internet Computer Weekly, 18.9.1997

M07

Robert Lemos: Legal tangle for Year 2000 bug. Artikel-Internet, MSNBC 15.1.1998

N01

Business-Systeme, das Jahr 2000 und die europäische Einheitswährung. Kent 1997, Buch, Neaman Bond Associates

001

B.G. Ohms: Computer processing of dates outside the twentieth century. 1986, Artikel-Zeitschrift, IBM Systems Journal 25, 2, 244 bis 251

P01

Andreas Pestinger: Das Jahr 2000 ist nicht das Ende der Welt. München 1997, Buch, Nomina ISIS: Jahr-2000-Umstellung

Q01

A. Quack-Grobecker Das Jahr 2000 - ein Problem für die Versicherungswirtschaft? Köln 1997 Vortrag Die Kölnische Rück Tagung am 3.7.1997

Q02

A. Quack-Grobecker: Firmenbefragung zur Jahr 2000 Problematik Köln 1997, Vortrag, Kölnische Rück, Research. Tagung am 3.7.1997

501

Teure Jahrtausendwende. 1995, Artikel-Zeitschrift, Süddeutsche Zeitung 295, 20

502

Guide. 1996, Artikel-Internet, Headquarters Standard Systems Group (US Air Force), lgm.ssc.af.mil/y2k/dochtml/guidel .htm

503

N. Sienko: Countdown to 2000. 1990, Artikel-Zeitschrift, Information Week 288, 64

504

Christoph H. Schultze: Das Jahr-2000-Problem - Ein Überblick. Köln 1997, Vortrag, Andersen Consulting Tagung am 3.7.1997

Bern

1997,

E-Mail,

1996 Artikel-

194

8

Quellen

505

Reihold Scheu: Datumsumstellung: Händler müssen Problembewußtsein schaffen. München 1997, Artikel-Zeitschrift, Computerwoche Verlag, ComputerPartner 12, 74

506

Der Smart Change Factory-Prozeß von SEEC. 1997, Artikel-Zeitschrift, it Verlag it management, Jahr 2000 Spezial -4-

507

D o BlOSes fail? 1997, Artikel-Internet, Solace Consultancy Services Ltd., www.solace.co.uk

508

SEC Report to the Congress: Readiness of the United States Securities Industry and Public Companies to Meet the Information Processing Challenges of the Year 2000. Juni 1997, Artikel-Internet, www.sec.gov/news/studies/yr2000.htm

509

SEC Staff Legal Bulletin No.5 www.sec.gov/rules/ohern/slbcf5.htm

T01

Edward Tenner: Die Tücken der Technik. 1997, Buch, S. Fischer, Buchanzeige JF Lehmanns

T02

Lothar von Trepka: Datum 2000 - Präventives Riskmanagement am Beispiel der Bayer AG. Köln 1997, Vortrag, Kölnische Rück Research Tagung am 3.7.1997

T03

Introduction of NonStop Operations Management. 1996, Buch, Tandem Computers Handbuch Nr. 114333

U01

Sicherheit und Performance für Ihre Millenium-Migration. UNISYS

W01

Togo D. West: Year 2000 Fixes - Top Priority. Washington 1997, ArtikelInternet, [email protected]

W02

Joachim Weidenbörner: Unternehmen 2000: Der Countdown läuft. 1996, ArtikelZeitschrift, it Verlag, it management, Jahr 2000 Spezial -1- 25 bis 31

W03

Thomas Worm: "Computer ohne "Zeitgefühl"". 1997, Artikel-Zeitschrift, Süddeutsche Zeitung, 27.3.1997

W04

Johannes Wessels: Strafrecht - Allgemeiner Teil. Karlsruhe 1972, Buch, C.F. Müller, 23 ff. u. 105 ff

W05

Peter Watkins: Jahrtausend ohne Tränen. Germering 1997, Prospekt, McAfee Focus 4

W06

Liam White: N Y IT blues. 1997, Artikel-Internet, Computer Weekly 11.9.1997

X01

J. Xenakis: Preparing for 2000: on the first day of the next decade, millions of COBOL programs may be wrong. 1990, Artikel-Zeitschrift, Information Week 259, 19

Z01

Nicholas Zvegintzov: Testing for Year 2000. Bern 1997, Vortrag, CHIG 2000 Tagung am 6.10.1997

(CF/IM),

12.1.1998,

Artikel-Internet,

1997,

Prospekt

9

Glossar

9.1

EDV-Begriffe

Hier finden Sie die Begriffe, die bei der Diskussion des Jahr 2000 Problems benutzt werden. Unterstrichen sind die Übersetzungen der Begriffe des „Draft Standard for Year 2000 Terminology" (101). Absolute Adresse Verweis auf einen durch die Angabe einer Zahl bestimmten Platz auf einem Speichermedium Adresse Verweis auf einen - absolut oder relativ - bestimmten Platz auf einem Speichermedium Alphabetische Daten Daten, deren Wert aus Elementen des Alphabets besteht Alphanumerische Daten Daten, deren Wert aus Elementen des Alphabets oder Ziffern oder beliebigen Sonderzeichen besteht Anwender Mitarbeiter eines Betriebes oder einer Verwaltung, die EDV zur Unterstützung ihrer Aufgaben einsetzen Anwendungsprogramm Programm zur Unterstützung fachlicher Aufgaben Anwendungsprogrammierer EDV-Fachkraft für die Entwicklung von Anwendungsprogrammen Arbeitsspeicher Speichermedium, aus dem der Zentralprozessor direkt Daten entnimmt und in das er direkt geänderte Daten ablegt ASCII American Standard Code for Information Interchange

196

9

Glossar

Ausgabedaten Daten, die von einem Programm auf ein Ausgabegerät gegeben oder an eine programmexteme Adresse übertragen werden Batch-Betrieb Organisation und Abfolge einer Anzahl von Jobs Befehl kleinste Einheit einer Anweisung in einer Programmiersprache Betriebssystem Gesamtheit der Systemprogramme eines Rechnersystems Binäre Daten Numerische Daten, deren Wert aus einem oder mehreren Bit besteht Bit der Wert 0 oder der Wert 1 Binder Systemprogramm, das aus Programmobjekten ein neues Objekt aufbaut Block Menge von Daten, die bei der Ein- oder Ausgabe als Einheit behandelt werden Byte Einheit von 8 Bit Client-Server EDV-Leistung, die sich durch die Ausführung mehrerer Prozesse ergibt, die untereinander Daten Code austauschen Vorschrift für die Zuordnung von Zeichen zweier Zeichenmengen Compiler Kompilierer Computersvstem eine Kombination von Hardware, Software und Firmware mit einem oder mehreren laufenden Prozessen CPU Central Processing Unit; Zentralprozessor Datei Menge von Datensätzen Dateiorganisation formale Ordnung von Datensätzen Datumsaustausch Übertragung von Datumsdaten zwischen zwei oder mehr Computer Systemen Datenbank Menge von Dateien mit Systemprogrammen zur Verwaltung der Dateien

9

Glossar

197

Datenfeld Name und Datentyp für eine Folge von Zeichen Datensatz Menge von Datenfeldern Datentyp Name für zulässigen Wertebereich Datenverarbeitung Eingabe, Ausgabe, Speicherung, Übertragung und Umformung von Daten Datumsdaten Datenfelder vom Datentyp Datum Datumsformat übliches Format für die Eingabe oder Ausgabe von Datumsdaten Datumsverarbeitung Die Datenverarbeitung von Datumsdaten auf einem Computer System Defaultwert Standardwert, wenn keine Belegung durch Programm oder Benutzer erfolgt ist Dezimale Daten Numerische Daten, deren Wert aus den Ziffern 0 bis 9 und bestimmten Sonderzeichen besteht DFÜ Datenfernübertragung Dialog-Betrieb Organisation und Abfolge einer Anzahl von Eingaben durch einen Benutzer EBCDIC Extended Binary Coded Decimal Interchange Code EDV Elektronische Datenverarbeitung Eingabedaten Daten, die von einem Programm mit einem Eingabegerät aufgenommen oder an einer programmexternen ausgelesen werden EDV-Komponenten durch ein Programm Nachbildung Emulation vonAdresse Eigenschaften bestimmter Externer Speicher Speicher, der nicht Arbeitsspeicher ist Firmware Systemprogramm im ROM Formatierte Daten Datenwerte in Datenfeldern GB Gigabyte, 2 hoch 30 Bytes = 1 073 741 824 Bytes

198

9

Glossar

Gepacktes Format Speicherung von zwei Dezimalziffern in einem Byte Hardware Sammelbegriff für EDV-Geräte Hexadezimale Daten Numerische Daten, deren Wert aus den Ziffern 0 bis 9, den Buchstaben A bis F und bestimmten Sonderzeichen besteht Host zentraler Rechner in einem Netz von Geräten und Rechnern IDV individuelle EDV, die vom einzelnen Benutzer bestimmt wird Informatik Wissenschaft von der EDV Instruktion kleinster Verarbeitungsschritt im Zentralprozessor Interpreter Systemprogramm, das Programmtexte direkt, ohne ein Programmobjekt zu erstellen, ausführt Job Auftrag an ein EDV-System, der zum Ablauf keine Benutzereingaben erfordert kB Kilobyte, 2 hoch 10 Bytes = 1 024 Bytes Kompilierer Systemprogramm, das aus Programmtexten ein neues Programmobjekt aufbaut Konstante Datenfeld, dessen Wert nicht geändert wird Literal Name für eine Konstante Lochkarte Speichermedium aus Pappe, auf dem Daten durch ein Lochmuster codiert sind Makro Folge von Befehlen Magische Zahlen Jahreszahlen mit irgendeiner, speziellen Bedeutung für ein Programm oder eine Anwendung - Insbesondere geben diese Werte in einem Feld vom Typ Datum oder Jahr eben nicht ein Datum oder =ein1 bestimmtes Jahr an. Megabyte, MBbestimmtes 2 hoch 20 Bytes 048 576 Bytes

9

Glossar

199

Middleware Sammelbegriff für Systemprogramme, die den Datenbankzugriff, den Datenaustausch und die Transaktionsverarbeitung erleichtern sollen Numerische Daten Daten, deren Wert eine Zahl in einer bestimmten Codierung ist Pointer Zeiger Primärschlüssel Menge von Datenfeldern, die einen Datensatz eindeutig kennzeichnen Programm eine Folge von Befehlen oder eine Folge von Instruktionen Programmbibliothek Sammlung von Programmobjekten Programmobjekt Folge von Instruktionen für den Zentralprozessor Programmtext Liste von Datenfeldern und Folge von Befehlen, die sich auf diese Felder beziehen Prozeß Programmobjekt, auf das durch den Zentralprozessor ausgeführt werden kann Quellprogramm Programmtext RAM Random Access Memory; Arbeitsspeicher, der geändert werden kann Rechner Computersystem Relative Adresse Verweis auf einen bestimmten Platz auf einem Speichermedium durch die Angabe einer Zahl und einer vereinbarten, aber meist nicht genannten, absoluten Adresse ROM Read Only Memory; Arbeitsspeicher, der nur ausgelesen werden kann Sekundärschliissel Menge von Datenfeldern, die einen Datensatz - nicht notwendigerweise eindeutig - kennzeichnen Server Servicerechner in einem Netz von Geräten und Rechnern Software Sammelbegriff für EDV-Programme Systemdatum das aktuelle Datum, wie es vom Betriebssystem ausgegeben wird

200

9 Glossar

Systemprogramm Programm zur Unterstützung von Verwaltungsaufgaben für ein Rechnersystem Systemprogrammierer EDV-Fachkraft für die Entwicklung von Systemprogrammen Transaktion Dialog, der zu einer Datenbankänderung führt Variable Datenfeld, dessen Wert geändert werden kann Zeiger Datenfeld, dessen Wert als Adresse benutzt wird Zentralprozessor Gerät zur Ausführung von Instruktionen durch Umsetzung in elektrische Verarbeitungssignale

9 Glossar

9.2

201

Hierarchie von EDV-Begriffen

Datenverarbeitung EDV Hardware Host Server Software Client-Server DFÜ Dialog-Betrieb Transaktion Batch-Betrieb Job Informatik Arbeitsspeicher RAM ROM Eingabedaten Ausgabedaten Block Externer Speicher Lochkarte Adresse absolute Adresse relative Adresse Datenbank Datei Dateiorganisation Datensatz Primärschlüssel Sekundärschlüssel Datenfeld formatierte Daten Konstante Variable Datentyp Alphanumerische Daten Code ASCII EBCDIC Alphabetische Daten Numerische Daten Dezimale Daten gepacktes Format Hexadezimale Daten Binäre Daten Byte Bit Defaultwert Zeiger

10 WWW-Adressen zum Jahr 2000 Problem A u s z u g aus der Liste des Bundesministeriums für Bildung, Wissenschaft, Fors c h u n g und Technologie ( h t t p : / / w w w . i i d . d e / j a h r 2 0 0 0 / )

10.1

Deutschsprachige Informationen

http://www.ie.iwi.unibe.ch/zobis/jahr2000/ Prof. G. K n o l m a y e r v o m Institut f ü r Wirtschaftsinformatik, Abteilung Information Engineering, der Universität Bern, hat eine deutschsprachige Einstiegsseite für das Jahr 2 0 0 0 - P r o b l e m . http://www.bsi.bund.de/aufgaben/projekte/2000/jahr2000.htm Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat einen Projektbericht mit dem Titel "Das Jahr-2000-Problem (J2K) in der Bürokommunikation" veröffentlicht. http://www.wiwi.uni-marburg.de/wi/archiv/971inh.htm In der Zeitschrift Wirtschaftsinformatik erschien Heft 1/97 mit dem Schwerpunktthema "Das Jahr-2000-Problem und andere Aspekte zeitorientierter IS". http://www.data-dimensions.com/html/miljnIvw.htm Das Millennium Journal bietet einige deutschsprachige Artikel. http://www.sni.de/public/sys/break_de/dur_de27.htm Mitteilung der Siemens Nixdorf Informationssysteme AG. http://www.cscploenzke.de/200996.html Pressemitteilung vom 20.09.1996 der CSC Ploenzke. http://www.fhg.de/german/presse/pi/pil997/pi397-d.htm Pressemitteilung v o m 27.02.1997 der Fraunhofer-Gesellschaft. http://www.magnamedia.de/m&t/aktuell/jahr2000.htm Artikel "Computer am Rande eines Nervenzusammenbruchs" aus der Zeitschrift Markt & Technik, Ausgabe 26/97 vom 27.06.1997. http://www.initiative2000.de/ In der "Initiative 2000" haben sich einige namhafte deutsche IT-Anbieter zusammengeschlossen, um über das Problem der Datums-Umstellung zu informieren.

10 WWW-Adressen zum Jahr 2000 Problem

204

http ://www.j ah r-2000.de/ Die "Spezial-Seite zum Jahr-2000-Problem" stellt eine "Plattform für IT-Unternehmen mit Spezialkompetenz zum Jahr-2000-Problem" dar. http://www.jahr2000.com/ Der "IT Verlag für innovative Technologien" bietet einen Server mit "Jahr 2000 Information" an. http://ourworld.compuservc.com/homepages/jahr2000/ Dr. Marc Otto hat ein "Jahr 2000 Informationszentrum" zum Thema "Jahr 2000 Datenkonversion im deutschsprachigen Raum" erstellt. http://members.aol.com/chrishoff7crash.htm Artikel von Christoph Hoffmann "Probleme im Jahr 2000 - Die Bombe tickt" aus PC Magazin 9/97. http://www.tuv.com/iseb/jahr2000.htm Das Institut für Software, Elektronik, Bahntechnik (ISEB) beim TÜV Rheinland bietet seine Hilfe bei der Lösung der Frage "Ist Ihre EDV 2000-fest?" an. http ://www.sni. at/yea r2000/ Siemens Nixdorf Informationssysteme (SNI) in Österreich informiert darüber, auf welche Weise SNI schnell und sicher die Weichen für das neue Jahrtausend stellen will.

10.2

Europa

http://www.bcs.org.uk/millen.htm Informationen der British Computer Society. http://www.ccta.gov.uk/mill/mbhome.htm Informationen der Central Computer & Telecommunications Agency (CCTA) in Großbritannien. http://www.iee.org.uk/2000risk/ Informationssammlung der Institution of Electrical Engineers (IEE) zum Millenium Problem in Embedded Systems. http://www.compinfo.co.uk/y2k/manufpos.htm Das "Year 2000 Date Problem - Support Centre" stellt die Frage "Is Your Hardware & Software Year 2000 Compliant?" http://www.implement.co.uk/ Die Implement Ltd ist spezialisiert auf "Implementation Management, Millennium Times Europe and Year 2000 Problems". http://www.taskforce2000.co.uk/ Informationen der Taskforce 2000 mit dem Ziel "ensuring business continuity at the millenium".

10 WWW-Adressen zum Jahr 2000 Problem

10.3

205

USA und Kanada

http://www.year2000.com/ Mit seiner zentralen Informationsstelle "The Year 2000 Information Center" hat der "International Spokesman for the Year 2000 Problem", Peter de Jager, das Jahr-2000-Problem einer breiten Öffentlichkeit nähergebracht. Zahlreiche Veröffentlichungen und ausgewählte Links bieten von Einführungen bis hin zu Lösungsstrategien viele nützliche Informationen. http://www.gao.gov/ Das United States General Accounting Office (GAO) bietet ein 35-seitiges Handbuch Year 2000 Computing Crises: An Assessment Guide (Februar 1997) im PDF-Format an. http://www.itpolicy.gsa.gov/mks/yr2000/y2khome.htm Auf dem Server des "Office of Information Technology of the Office of Governmentwide Policy in the General Services Administration" finden sich ein Year 2000 Information Directory des "CIO Council Subcommittee on Year 2000" sowie ein Year 2000 International Information Directory des G7-GOL-Projekts. http://www.nist.gov/y2k/index.htm Informationen des National Institute of Standards and Technology (NIST). http://www.is.ufl.edu/bawb015h.htm Das Year 2000 Information Center der Universität von Florida. http://www.comlinks.com/mmenu.htm Das E-Zine Com.Links hat eine Fülle von Artikeln zum Jahr-2000-Problem. http://web.idirect.com/~mbsprog/ Das Year2000 Information Network. http://www.itaa.org/year2000.htm Die Information Technology Association of America (ITAA) bietet neben allgemeinen Infos auch einen EMail-Service, den Year 2000 Outlook, an. http://www.ttuhsc.edu/pages/year2000/y2k_bib.htm Eine umfangreiche Literatursammlung bietet Larry Towner vom Texas Tech University Health Sciences Center an. http://www.cpsr.org/dox/issues/miIlen.html Seite der Computer Professionals for Social Responsibility (CPSR) zum Millenium Problem, wo auch ein Listserver zu diesem Thema ([email protected]) existiert. http://www.techweb.com/ Der TechWeb-Server bietet eine Reihe von Artikeln zum Thema. Nach Eingabe eines Stichwortes (z.B. 2000) in die TechWeb-Suchmaschine erhält man eine Liste relevanter Beiträge. http://www.ssa.gov/year2000/y2klist.htm Die USA Social Security Administration gibt Informationen zum Thema "Year-2000 Compliance Status for Various Vendor Products". http://www.y2k.com/ Ein Server mit "Legal & Management Information on the Year 2000 Computer Problem".

10 WWW-A dressen zum Jahr 2000 Problem

206 http://www.dfwdama.org/y2000.html Die "Dallas Year 2000 Prep Site".

http://www.wa.gov/dis/2000/y2000.htm Das "Washington State Department of Information Services (DIS)" unterhält ein "Year 2000 Project Information Resource Center". Hierzu wurden unter anderem Umfragen bei Hard- und Software-Herstellern durchgeführt. http://www.state.mn.us/ebranch/admin/ipo/2000/2000.html A u f der "Minnesota Year 2000 Web Site" findet sich unter anderem ein Year mit Informationen zum Jahr 2000-Problem. http://www.ustreas.gov/treasury/t01munoz.html Erklärung von Goerge Munoz, Mitarbeiter im U.S. Departement of the Treasury, zur "Year 2000 Date Transition". http://strategis.ic.gc.ca/year2000 Auf dem Server STRATEGIS bietet "Industry Canada" auf ihren Seiten zum "CHALLENGE 2000" im Rahmen der "Task Force Year 2000" einen "Executive Guide to Year 2000 Computing Solutions". http://www.cnet.com/Content/Features/Dlife/Millbug/ Artikel "8 myths about the millennium bug" von Matt Rosoff. http://www.nstl.com/html/ymark_2000.html Die "National Software Testing Laboratories (NSTL)" haben unter "YEAR 2000 Testing Programs" Informationen zu ihren Testprogrammen auf Jahr 2000-Verträglichkeit. http://www.software.ibm.com/year2000/ IBM bietet ein "Year 2000 Technical Support Center". http://www.digital.com/year2000/ Digital Equipment Corporation bietet ein "DIGITAL Year 2000 Program". http://www.hp.com/gsy/year2000/ Auch Hewlett Packard (HP) informiert zum "Year 2000 Problem," und bietet mit "HP's Cure2000 Solution" eine Problemlösung. http://www.compaq.com/year2000/ Unter dem Titel "Compaq Helps You Prepare for the Year 2000" informiert die Firma Compaq über die Ergebnisse ihrer Produkte beim " Y M A R K 2 0 0 0 PC hardw a r e Year 2000 readiness test". http://www.microsoft.com/msoffice/officenews/960916/year2000.htm Microsoft bezieht Stellung zum Thema "Using Microsoft Office Through the Year 2000".

10.4

Andere Länder

http://www.y2k.gov.au/ Die "Year 2000 Home Page" der australischen Regierung.

10 WWW-Adressen zum Jahr 2000 Problem

207

http : //www.ogit.gov.au/activities/year2000.html Die "Year 2000 Activités" des "Australian Office of Government Information Technology". http://www.ogit.gov.au/committees/yr2000.html Das "Year 2000 Committee" des "Australian Office of Government Information Technology". http://www.dpc.vic.gov.au/ocmpol/219a.htm Die "Year-2000 Policy" des "Department of State Development, Government of Victoria, Australia". http://www.cinderella.co.za/ Das "Y2K Cinderella Project" und die "Y2000 Special Interest Group" der "Computer Society of South Africa, Project Management Institute".

11 Index A Ablaufumgebung 74 AGB 135, 175 Aiken, H. 19 Aktion 2000 148 Anwendungen 69 kaufmännische 26 technische 26 Aufwand 44 Augustus 29 Ausweichrechenzentrum 76

B Berater 59, 168, 178 Berichtspflichten 51 Bewertung bilanzielle 47 Anwender 49 Softwarehersteller 50 Brückenprogramm 85, 90, 93 Budget 63

c C 43 Cäsar 29 CBI 39 CHIG2000 147 CIGREF 39 COBOL 16,43,91, 110, 184 Computerviren 17 CSSA 39

D Data Mining 86 Datenfeld Datentyp 80 Namen 79 Datenqualität 163 Datenschutzgesetz 176 Datumsdarstellung Standards 32 Dauerschuldvertrag 138 Debugger 82 Deutschland 34 Dienstleistungsvertrag 178 Directors & Officers 168 Downsizing 64

E EDV 18 EDV-Betriebsmanagement 155 EDV-Systeme 71 Entwicklungsumgebung 78 Errors & Omissions 168 EU 40 EURO 38, 46, 85 Exiguus, Dionysius 29

F Fahrlässigkeit 174 Function Point 45 Funkuhr 33

210

11 Index

G G-7 38 Gesellschaft für Informatik 184 Gregor XIII. 29 Größen, zeitartige 24

H Hacker 17, 184 Handelsbilanz 47 Help Desk 162 I Informatik 18 Initiative 2000 38, 118 ISIS Jahr-2000 Kampagne 118

J J2P 19 Jahr 2000 Fähigkeit 106, 121 Fertigkeit 99, 122 Komitee 60 Projekt 41 Projektkoordinator 59, 62 Projektrahmen 58 Sicherheit 123 Testvarianten 99 Jahresabschluß, Anhang 51 Jahreslänge 29 Jahreszählung 29 Jahrhundertangabe 21 Jahrhundertereignis 19,20,190 Jahrhundertwechsel 15

K Kalender 29,31 Betriebskalender 31 Kaufvertrag 132 Kölnische Rück Research 36 Komplexität 42, 45, 157 Konflikte,betriebliche 60 Kosten 19,37,58

Krise 17 Krisenplan 62

L Lagebericht 52 Lean Management 64 Leasingvertrag 140 London 153 Lösungsalternativen 83 Lösungsanbieter 108 Lösungskatalog 130

M META Group 35 Mietvertrag 139 Millennium Watch 39 Mitarbeiter 42, 64 Mondjahr 29

N Neaman Bond Associates 35 Netzwerk-Computer 183 Nutzergruppen 146 O Operationen, zeitliche 24 Outsourcing 113, 183

P Pachtvertrag 140 PC 75 Pflege von Software 42 Pilotprojekt 111 Pointer 82 Preisgestaltung 111 Probleme, technische 62 Produkthaftungsgesetz 180 Produktsicherungsgesetz 180 Programm 73 Programmanalyse semantische 81 syntaktische 81

11 Index Programmiersprachen 43 Programmierwerkzeuge 58 Programmobjekte 76 Programmtext 76, 78, 79 Projekt 46 Projektmanagement 55 Prozesse 74 Prozeßtechnik 68 Prüfungsbericht 53

Q Qualität 112

R RAD 85 Rechneruhren 33 Rückstellungen 50

S Schaltsekunde 32 Sekunde 32 Service-Level Agreement 157 Slicing-Verfahren 117 Software Inventar 45 Management 181 Pflege 43 Software Factory 113 Software Management 45 Softwaremuseum 190 Sommerzeit 33 Sonnenjahr 29 Speicherung gepackte 89 vierstellige 87 SQL 43, 80

T Tageslänge 28 Tageszählung, julianische 31 TAI 32 Taskforce 2000 39, 147 Test 70

211 Testrechner 106 Testsystem 129 Testumgebung 98

u Update 85 UTC 32

V Verhaltenskodex 112 Vermögen Anlagevermögen 48 Unternehmensvermögen 47

Version 78 Versionsverwaltung 83 Vertragsverletzung, positive 135, 175, 178 Viren 18, 152, 164 Vorsatz 174

w Werkvertrag 136 Werkzeuge 115 Wirtschaftsgüter, immaterielle 48 Wirtschaftsinformatik 18

Y y2k 19

z Zahlen, magische 23,81 Zeit 28 Zeitbombe 16, 187 Zeitfenster 92, 117 Zeitplan 57 Zeitreise 93 Zeitzonen 33 Zentralisierung 183 Zuse, K. 19 Zusicherung 123, 133, 136