Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

19.06.1987

" Selbstbedienung " führt oft in die Sackgasse

"Wer mit individueller Datenverarbeitung (IDV) eigene Systeme bastelt, wird Probleme mit der Integration haben." Dieser Meinung ist nicht nur Lothar Bredtmann, Leiter der Hauptabteilung Organisation Systeme und Abläufe der Volkswagen AG in Wolfsburg. Nachdem in den letzten Jahren vorrangig die Wünsche der einzelnen Fachabteilungen realisiert wurden und dabei Insellösungen entstanden, haben viele Unternehmen diesen Weg als Sackgasse erkannt. Das Grundverständnis änderte sich; die Systementwicklung orientiert sich wieder nach ablauforganisatorischen Belangen. Es bestehe zwischen den noch isoliert arbeitenden Bereichen ein vielfältiges Bedürfnis nach Datenintegration, so Harald Wittbecker, Leiter der Abteilung Informationsverarbeitung der Stadtwerke Essen AG.

Lothar Bredtmann, Leiter de Hauptabteilung Organisation Systeme und Abläufe, Volkswagen AG, Wolfsburg

Noch hat die Anwendungsentwicklung die Umstellung von Batch auf Dialog nicht voll bewältigt. IMS erwies sich im DB/DC-Handling als hochkomplex, selbst für fachlich triviale Funktionen. Die höheren Programmiersprachen sind nicht mitgewachsen; eine "normierte Programmierung" für Dialogprogramme ist nicht in Sicht. Da wird die Geduld auf eine harte Probe gestellt oder ein "kürzerer" Weg gesucht.

Manche dieser "kurzen" Wege haben sich als Sackgasse erwiesen, besonders solche, die den zentralen Verbund verlassen. Dezentrale und Arbeitsplatzrechner erlauben zwar zum Teil brillante Insellösungen, aber der notwendige Datentransfer hebt viele Vorteile wieder auf. Auch die Beherrschung einer völlig anderen, zweiten Systemumgebung sowie Probleme der Gesamtstabilität (Netz) und des Operating - ohne das es licht geht - haben diesen Weg bisher recht schmal gehalten.

Bewährt hat sich dagegen die "Selbstbedienung" bei Auswahl und Aufbereitung von Daten aus integrierten Systemen. Sprachen der 4. Generation sind hier mächtig und problemlos, oft direkt in der Hand des Endbenutzers. Wer mit IDV allerdings eigene Systeme "bastelt", wir Probleme mit der Integration haben. Und: Isoliert sind EDV-Lösungen nur anfangs.

Volkswagen arbeitet mit Strategien für die unterschiedlichen Hardwareebenen und die lebenswichtige Integration und Durchgängigkeit der Daten und Systeme. Auf dem CAD/CAM-Sektor sind diese Probleme etwas größer, da die Hauptsysteme dezentral begonnen wurden. Aber der Grundstein ist gelegt. BK und IDV nutzen auch dezentrale Hardware, aber ausschließlich Standardsoftware, um eine angemessene Know-how-Ausprägung zu sichern. Als zweites strategisches Datenbank-System eben IMS wird Volkswagen DB2 einsetzen - in kontrolliertem Wachstum. Wichtig für ein DB-System sind uns die Langfristigkeit und Power dahinter, das relationale Konzept, die Verträglichkeit zur übrigen Systemumgebung, die Datensicherung und die Flexibilität während er Online-Betriebszeit. Dringend erwartet wird hier allerdings ein Dictionary beziehungsweise Repository mit vollem Funktionsumfang zur Datenorganisation (auch für IMS).

So geht Volkswagen mit dem Bewußtsein in die neue Systemgeneration, daß sich die Hauptaufgaben um aktuelle und überalle verfügbare Daten ranken, mit der Möglichkeit individueller Auswahl und Darstellung vor Ort.

Wolfgang Rotmeier, DV-Leiter, Allgemeine Ortskrankenkasse München

In den Jahren vor 1979 lag der Schwerpunkt bei unserer Geschäftsstelle hauptsächlich im Beitragsbereich, daß heißt in der Kontenführung und im Beitragseinzug. Seit 1979 sind wir nun verstärkt im Leistungsbereich vertreten, zum Beispiel, um Zahlungen an Versicherte zu leisten, Krankenhausrechnungen zu bezahlen - also all das, was in Form von Leistungen unser Haus verläßt. Da diese beiden Hauptbereiche früher mit eigenen Datenbeständen gearbeitet haben, lag es an der DV-Abteilung, die Daten in eine zentrale, allgemeine Mitgliederbestandsführung zusammenzuführen. Die Systementwickler mußten sich zunächst, um dieses Projekt zu realisieren, mit der Organisation, mit dem internen Arbeitsablauf befassen. Anfangs gab es natürlich sehr viele Konflikte, sowohl die Beitrags- als auch die Leistungsseite mußten berücksichtigt werden.

Aus diesem Grund entstand 1980 eine neue Abteilung, die seither die Mitgliederbestandsführung durchführt. Wichtig war dabei, daß sich diese zentrale Stelle gegenüber den verschiedenen Bereichen neutral verhielt. Inzwischen sind acht Jahre vergangen, und mit einigen Korrekturen ist es gelungen, daß beide Bereiche mit demselben Bestand gut zurechtkommen. Allerdings ist das Grundverständnis, auch zur DV hin, derzeit leider noch zuwenig fortgeschritten. Der Sachbearbeiter sollte sich beispielsweise darüber im klaren sein, daß er bei Änderungen einer Mitgliedszeit, sich diese zwangsläufig auch auf alle anderen Bereiche auswirkt.

Im Zuge der Neuorganisation unserer Datenbestände sind wir zu der Meinung gelangt, mehr und mehr Standardsoftware zu installieren und nur so viel selbst zu entwickeln, wie am Markt nicht vorhanden ist. Aus Ersparnisgründen haben wir zum Teil in der Vergangenheit andere Wege beschnitten, doch erwiesen sich diese in der Regel als Sackgasse. Unser Ziel ist, jetzt von den Eigenentwicklungen im Bereich Datenbestandsführung loszukommen.

Klaus Staab, Leiter des Klinikrechenzentrums der Universität Heidelberg

Gesetzlichen Änderungen sowie steigenden funktionellen Anforderungen konnte die seit 1983 eingesetzte Software bereits nach wenigen Jahren nicht mehr gerecht werden. Bei der Auswahl der zweiten Generation des Patientenverwaltungssystems im Jahr 1985/86 bestand aufgrund der geringen Entwicklungskapazität nur die Möglichkeit, ein kommerzielles System einzusetzen. Aufgrund der komplexen Strukturen (zum Beispiel einzelne unabhängige Kliniken im Gegensatz zu kommunalen Krankenhausstrukturen), die es abzubilden galt, waren umfangreiche Anpassungen notwendig. Der Umstellungsaufwand für das zentrale System war sehr hoch: Etwa vier bis fünf Mann-Jahre waren für die Anpassung der Schnittstellen, Parametrierung etc. notwendig. Dabei wurden die Softwareänderungen Überwiegend von der Firma selbst übernommen. Im medizinischen Bereich steht für ein Universitätsklinikum kaum Standardsoftware zur Verfügung. Auf dem Markt angebotene Abteilungssysteme zur organisatorischen Unterstützung sind in der Regel nicht offen, im Hinblick auf die Integration in ein Gesamtsystem. Entwicklungen werden daher zur Zeit insbesondere im medizinischen Bereich durchgeführt. Mit einem umfassenden EDV-Konzept im Jahre 85/86 wurde der Grundstein für eine integrierte Software und Datenhaltung dargelegt. Dieser Weg wird in den Grundzügen zwischenzeitlich mit den anderen Universitätskliniken in Baden-Württemberg gemeinsam begangen, um Mehrfachentwicklungen zu vermeiden.

Grundlage für zukünftige Entwicklungen in Heidelberg ist das Datenbanksystem Adabas als Basis für eine integrierte Datenhaltung mit Natural als Sprache der 4. Generation. Damit ist eine wesentlich kürzere Entwicklungszeit sowie eine frühzeitige Einbeziehung des Anwenders bei der Programmentwicklung möglich. Die Entwicklung erfolgt mit den zur Verfügung stehenden Tools, überwiegend nach dem Prozeßkonzept und nicht mehr nach dem Phasenkonzept. Mit Hilfe von Prototyping können frühzeitige Korrekturen durch den Anwender erfolgen, um damit eine Entwicklung "an dem Nutzer vorbei" zu vermeiden. Dies wird stark durch eine standardisierte Benutzeroberfläche und der selbstentwickelten Tools unterstützt.

Wulf Upmeier, Hauptabteilungsleiter Org./DV, B.A.T. Cigarettenfabriken GmbH, Hamburg

Bei der B.A.T. mußte sich zunächst einmal das Grundverständnis verändern. In der Vergangenheit realisierte die Systementwicklung ausschließlich die stark bereichsgeprägten Wünsche der Fachabteilung. Seit Einführung von Standardsoftware hat sich das Grundverständnis gewandelt: Der Schwerpunkt liegt jetzt bei dem Einsatz integrierter Standardsysteme und den daraus resultierenden ablauforganisatorischen Belangen. Diese müssen nach betriebswirtschaftlichen und bereichsübergreifenden Gesichtspunkten ausgerichtet werden. Erst dann kann auf spezifische Probleme der jeweiligen Abteilungen eingegangen werden.

Eine wesentliche Aufgabe der Systementwickler während der Einführungsphase liegt darin, in Projektarbeit zusammen mit den Fachabteilungen das gesamte Umfeld zu betrachten, die Funktionen der Softwarepakete zu lernen, am Anforderungsprofil der Fachabteilungen zu messen und notwendige ablauforganisatorische beziehungsweise DV-technische Veränderungen zu konkretisieren, vorzuschlagen und zu realisieren. In Form von Prototyping werden dann gemeinsam mit den zukünftigen Benutzern die Systeme eingeführt. Gegenüber früher konnte der Pflege- und Wartungsaufwand des Bereiches Systementwicklung drastisch gesenkt werden. Dadurch haben jetzt die Mitarbeiter mehr Möglichkeiten, auf die Wünsche der Anwender nach Daten für individuelle Auswertung zur Unterstützung dispositiver Aufgaben einzugehen. Zusätzliche Kapazität für Neuprojekte wurde freigesetzt.

Harald Wittbecker, Leiter der Abteilung Informationsverarbeitung, Stadtwerke Essen AG

Die Diskussion um ganzheitliche DV-Lösungen, insbesondere angeregt durch die CIM-Konzepte, hat auch in unserem Hause zu Überlegungen geführt, die gewachsenen DV-Verfahren nach und nach durch ganzheitliche Software abzulösen. Die vorhandenen Lösungen wurden aus den Vorgaben der Fachabteilungen entwickelt; Datenintegration gab es nur, von wenigen Ausnahmen abgesehen, innerhalb eines Anwendungsbereiches. Wir stellten immer häufiger fest, daß zwischen den derzeit noch isoliert arbeitenden Bereichen ein vielfältiges Bedürfnis nach Datenintegration bestand. Angeregt durch ein wirklich benutzerfreundliches Query- und Reporting-System wollen inzwischen viele Abteilungen auf Datenbestände aus verschiedenen Anwendungen zurückgreifen, auch auf solche, die sie selbst nicht verwalten. Ferner haben wir erkannt, daß Datenbestände oft in gegenseitiger Abhängigkeit stehen, daß eine Änderung in einem Bestand zwangsläufig auch Auswirkungen auf andere Anwendungen hat. So sind zum Beispiel die kaufmännischen Bereiche wie Marketing, Verbrauchsabrechnung, Rechnungswesen und die technischen Bereiche wie Planung, Bau und Betrieb der Rohrnetze und der Hausanschlüsse übergreifend zu bearbeiten. Mit den vorhandenen DV-Verfahren ist allerdings keine vollständige Durchgängigkeit zu erreichen.

Um zum Ziel einer einheitlichen Anwendungssoftware zu kommen, sind meines Erachtens folgende Voraussetzungen zu erfüllen: Ganzheitliche Konzeption der Anwendungen, Software-Produktionsumgebung, die eine hohe Transparenz der Verarbeitungslogik, der Verknüpfungen und Abhängigkeiten ermöglicht, einheitliche Benutzeroberfläche, Data-Dictionary-gesteuerter Datenzugriff, Neuentwicklung der gesamten Anwendungssoftware nach diesem Konzept. Dieses Ziel können wir aus eigener Kraft nicht erreichen. Aus diesem Grund haben wir uns dazu entschlossen, Standard-Software eines Softwarehauses einzusetzen. Diese ist nach einem einheitlichen Konzept entwickelt und um faßt sowohl den kaufmännischen Bereich als auch große Teile des technischen Sektors.

Die vorhandene Anwendungssoftware soll jetzt schrittweise nach einem mehrjährigen Stufenplan abgelöst werden. Die noch anfallenden Anpassungen und Schnittstellen werden in unserem Hause realisiert. Nicht abgedeckte Anwendungsbereiche werden wir aus eigener Kraft oder im Verbund mit anderen Versorgungsunternehmen nach der gleichen Konzeption mit den gleichen Methoden einer Lösung zuführen.

Wir sind der Ansicht, mit diesem Konzept den richtigen Weg zur Datenintegration gefunden zu haben. Es wurde in der Vergangenheit schon oft eine Integration versucht, doch entstehen damit auch integrierte Fehler und Probleme, da die damalige Methodik der Softwareentwicklung nicht genügend Transparenz und Flexibilität zuließ.

Eine europäische Dependance errichtete die amerikanische Innovative Software Inc. aus Lenexa/Kansas jetzt in England. Über den britischen Markt hinaus will die Programmschmiede ihre Mikro-Software auch an Kunden in anderen europäischen Ländern ausliefern.

Ein OEM-Abkommen haben die kalifornische Relational Technology Inc. (RT), Alameda, und Celerity, San Diego, unterzeichnet. Laut Vertrag wird Celerity das relationale Datenbank-Managementsystem "Ingres" von RT für seine Unix-Superminis vertreiben.

Ihre Unix-Module der Serie "Dataflex" hat die amerikanische Data Access Corp. jetzt freigegeben. Damit sind die Module für PC/MS-DOS, OS/2, CP/M 86, Single- und Multi-User, LANs sowie für Xenix und UnixV als auch für VMS von DEC lieferbar. Aus dem Produktkatalog gestrichen werden ab 1. August dieses Jahres sämtliche 8-Bit-Versionen. Deutscher Distributor ist die RDE Software Vertriebs GmbH, Wiesbaden.

Einen weiteren Kooperationsvertrag mit dem X/Open-Mitglied ICL hat die englische Sphinx Ltd. aus Maidenhead, Berkshire, geschlossen. Demnach wird die Unix-Schmiede jetzt ihre Produkte nicht nur für die "Clan"-Familie, sondern auch für die DRS-300-Reihe des Hardwareproduzenten entwickeln. Vertrieb und Support für die Software erfolgen durch das von Sphinx geleitete Distributionsunternehmen International Consortium for Unix Software (Icus). Zusätzlich übernimmt Icus den Europavertrieb von Unix- und Xenix-Produkten einer Reihe von amerikanischen Softwareherstellern. Dazu gehört unter anderem die kalifornische Interactive Systems Corp., Santa Monica, die neben dem jetzt unterzeichneten Kooperationsvertrag mit Sphinx auch ein Abkommen mit Microsoft zur Weiterentwicklung des hardwareunabhängigen Betriebssystems unterhält. Darüber hinaus wurden in das Icus-Konsortium fünf neue Partner aufgenommen, darunter die Westberliner ConPlan GmbH und die Gulf Data International (GDI) aus Abu Dhabi.