Bei Client-Server-Projekten muessen DV und Unternehmensprozesse zusammen optimiert werden Ein rasantes Unternehmenswachstum fuehrte bei der Blomberger Phoenix Contact GmbH zu einem immer dichteren Dschungel heterogener Systeme. 1990 machte der Hersteller von industriellen Steckverbindungen und Schnittstellen einen Schnitt und fuehrte ein Client-Server-Konzept ein, das sich vor allem durch seine Klarheit auszeichnet. So ist die DV-Infrastruktur praezise definiert und strikt von der Anwendungsseite getrennt. Ausserdem wurde dafuer gesorgt, dass Applikationen und Unternehmensablaeufe eng aufeinander abgestimmt sind. Auch die intern herkoemmlichen Techniken wie Batch-Verarbeitung und hierarchisches DV-Management haben in dieser Umgebung keinen Platz.

Wie bei anderen Unternehmen wurde auch bei Phoenix die elektronische Datenverarbeitung 1969 vor allem eingefuehrt, um eine kostenguenstige Verarbeitung der Massendaten zu ermoeglichen. Dabei setzte man jedoch nicht auf IBM-Mainframes, sondern auf Grosssysteme von Sperry/Univac (heute Unisys). Da fuer diese Maschinen aufgrund ihres geringen Marktanteils nur wenig Programme angeboten wurden, schrieb man fast alle Anwendungen mit Cobol. In dieser Zeit bestimmte die technische Systemsicht die DV-Politik des Hauses.

Diese Situation aenderte sich, als Mitte der 80er Jahre die PCs fuer technische Anwendungen und Qualitaetssicherung Eingang in das Unternehmen fanden. Gleichzeitig entstand eine zweite DV- Abteilung, die unabhaengig vom klassischen RZ-Bereich agierte.

Als dann Ende der 80er Jahre eine weitere Gruppe hinzukam, die sich um die Themen Vernetzung und CAD/CAM kuemmern sollte, hatte Phoenix es gar mit drei voneinander unabhaengigen Abteilungen zu tun. So geschah es immer wieder, dass ein Anwender sich einfach die DV-Abteilung aussuchte, die seinen Wuenschen am geneigtesten erschien, was natuerlich zu Problemen beim Support fuehrte.

"Das hatte zur Folge, dass nicht mehr nachvollziehbar war, was eigentlich alles gemacht wurde", berichtet Bernd Marner, Leiter Informatik und Organisation. Als besonders problematisch schildert er das Fehlen von Standards im PC-Bereich. So kamen mindestens drei verschiedene Textverarbeitungen zum Einsatz. Von groesserer Tragweite sei jedoch gewesen, dass auch die Entwickler eine Vielzahl von Produkten wie etwa Clipper, Pascal oder Dbase verwendeten. Kurz: "Es gab keine einheitliche DV-Strategie mehr."

Als Grund fuer diesen Wildwuchs nennt Marner das rapide Unternehmenswachstum. So ist die Mitarbeiterzahl seit den 80er Jahren bis heute von 500 auf rund 2500 hochgeschnellt.

Vor diesem Hintergrund entschied sich die Unternehmensleitung 1990, die drei DV-Abteilungen im Bereich Informatik und Organisation zusammenzufassen. Zugleich wurden die zentralen Elemente einer neuen IT-Struktur festgelegt. Deren Kern war laut Marner die Abloesung der technikorientierten DV-Perspektive durch eine an den Arbeitsprozessen und der Unternehmensorganisation orientierte Sichtweise. "Wir wollten uns nicht mehr darauf verlassen, dass der Kauf der richtigen Systeme und Software unsere Probleme loesen wuerde." Der DV wuchs dadurch eine neue Aufgabe zu: die Optimierung von Geschaeftsprozessen, anstatt isoliert einzelne Bereiche oder Abteilungen zu betrachten.

Der Grundgedanke der bei Phoenix aufgebauten Architektur ist, sie auf der Basis von Standards so durchgaengig wie moeglich zu gestalten. Laut Marner wird auf diese Weise eine Infrastruktur geschaffen, die einem Ausbau der Umgebung keine Hindernisse entgegensetzt. Im Zentrum steht dabei die Datenbank. Sie gilt im Unternehmen als die wesentliche Integrationsplattform. Zu den technischen Zielen der DV-Umgestaltung gehoerte die weitgehende Integration aller Stamm- und Bewegungsdaten. Marner: "Ziel ist, die Batch-Verarbeitung abzuschaffen und die Transaktionen ausschliesslich ueber die Datenbank abzuwickeln."

Mit der Festlegung auf ein einziges Datenbankprodukt, naemlich Oracle, erreichte man, dass unternehmensweit mit standardisierten Mechanismen auf beliebige Anwendungen vom Fertigungssystem bis zum PC-Spreadsheet zugegriffen werden kann. Fuer das Oracle-Erzeugnis sprach auch, dass der Hersteller Marktfuehrer ist und etwa 140 Plattformen unterstuetzt. Das ist fuer das Unternehmen wichtig, weil sich so die fuer die Datenbank entwickelte Software weltweit in den Phoenix-Niederlassungen einsetzen laesst.

Wesentlich umstrittener als die Datenbankentscheidung war laut Marner die fuer Unix als zweites Standbein der DV-Infrastruktur. Neben den ueblichen Argumenten wie Offenheit und Zukunftssicherheit fiel entscheidend ins Gewicht, dass es im Haus entsprechendes Know- how bereits seit 1987 gab. Besonders wichtig war vor allem die Skalierbarkeit, sprich: die Moeglichkeit, das gleiche Betriebssystem auf verschiedenen Plattformen einzusetzen, um somit modular weiterwachsen zu koennen.

Eines von Marners Zielen als Projektverantwortlicher war, die Sicherheit eines Mainframes auch in einer Unix-Umgebung zu garantieren. Darauf hat er seine Definition von Client-Server-DV abgestellt.

Marners Credo lautet: "Trennung von Datenhaltung und Anwendung sowie Reduzierung der Netzbelastung durch Verlagerung der Kommunikation dorthin, wo die Last entsteht. Wichtig ist zudem, dass das System konsistent bleibt, auch wenn ein Server ausfaellt."

Konkret sieht das folgendermassen aus: Frueher waren Daten, Anwendungen und Transaktionsverarbeitung allein Aufgaben des Mainframes. Seit Mitte 1994 dient ein Cluster mit zwei Pyramid- Systemen mit jeweils vier Mips-RISC-Prozessoren R 4400 als zentraler Datenbank-Server. Ausser dem Oracle Parallel Server laeuft dort keine Anwendung.

Abgerufen werden die Daten von unternehmensweit verteilten Applikations-Servern ueber einen ausfallsicheren FDDI- Glasfaserring, der seit dem Fruehjahr 1994 installiert ist. Auf diesen Unix-Servern des Typs HP9000/700 laeuft zum Beispiel mehrfach das PPS-System PSK 2000 von Straessle, ein Vertriebsinformationssystem inklusive Aussendienstfunktionen und das Finanz- und Rechnungswesen von Quantum.

Der FDDI-Ring dient als schneller und firmenweiter Daten-Bus. Ausserdem laufen via SQL-Net die grossen PPS- und Oracle- Anwendungen. Marner: "Unser Computer ist das Netzwerk." Die rund 2000 aktiven Anwender selbst sind durch Subnetze mit den Anwendungs-Servern verbunden. Dort findet der Dialogverkehr statt. Der Vorteil dieser Trennung liegt nun darin, dass sich zum einen der FDDI-Ring in der Regel von Dialoganwendungen freihalten laesst und zudem die Server nach reinen Auslastungskriterien aufgestellt werden koennen. Das heisst, dass die Anwendung so nah wie moeglich bei den Benutzern installiert ist. Ausserdem lassen sich bei Bedarf einfach zusaetzliche Server an den Ring anschliessen.

Da auf den Workstations keine Datenbank installiert ist, beschraenkt sich ihre Aufgabe auf den Terminal-Einsatz, womit Windows-PCs mit Terminalemulation gemeint sind. Auf diese Weise wird so viel Leistung gewonnen, dass nach Marners Messungen jeder Anwendungs-Server bis zu 100 Benutzer bedienen koennte.

Was die Arbeitsplaetze der Endanwender betrifft, so werden seit 1990 alle Endgeraete sukzessive durch vernetzte PCs beziehungsweise Macs ersetzt. Als Knoten dienen derzeit rund 20 Novell-Server. Jeder PC kann so im Rahmen der Sicherheitsgrenzen weltweit auf jeden Anwendungs-Server zugreifen.

Die eigentliche Herausforderung fuer Marner bestand jedoch weniger im Aufbau dieser Architektur als in der Schaffung einer staerker auf die strategischen und organisatorischen Anforderungen des Unternehmens ausgerichteten DV-Struktur. Er ist ueberzeugt, dass es "messbare Verbesserungen nur gibt, wenn gleichzeitig mit der DV die Unternehmensprozesse optimiert werden. Der Erfolg haengt von beiden Bereichen ab."

Aus dieser Grundeinstellung heraus hat er eine DV-Organisation aufgebaut, die es ermoeglicht, bei jedem Projekt die Prozesskette ins Kalkuel zu ziehen. Wichtig sei hierfuer eine saubere Schnittstelle zwischen Software-Entwicklung und -Organisation auf der einen und dem Betrieb der DV-Infrastruktur auf der anderen Seite. So besteht zum Beispiel der Unix- und Oracle-Support aus nur zwei Fachleuten. Hinzu kommt der PC-Support, bei dem fuenf Mitarbeiter fuer 1500 Arbeitsplaetze zustaendig sind.

Solche Werte sind nur erreichbar, wenn die Anwender die hausinternen Standards strikt einhalten. Dazu gehoert, dass sie ueber eine unternehmenseinheitliche Oberflaeche auf ihre Anwendung zugreifen, ohne wissen zu muessen, von welchem Server sie bedient werden. Auch unter Windows ist fuer Einheitlichkeit gesorgt, weil alle Win-Ini-Eintraege vom Netz geladen werden.

Zur Senkung der Fehlerrate traegt bei, dass alle Anwender fuer ihre Windows-Anwendung geschult werden. Ausnahmen gibt es hier nur fuer Entwickler. Treten trotzdem Probleme auf, lassen sich diese leicht ueber eine zentrale Datenbank lokalisieren, auf der alle Aktivitaeten festgehalten werden.

Insgesamt besteht die DV-Mannschaft aus etwa 40 Mitarbeitern, die jeweils zur Haelfte im Rechenzentrum und in Supportzentren sitzen, mit denen die Struktur des Unternehmens abgebildet wird. So gibt es Softwarespezialisten fuer den Vertrieb, Materialwirtschaft, die Produktion und CAD/CAM. Diese Leute muessen sich sehr genau mit den betrieblichen Ablaeufen auskennen. Das Berufsbild des klassischen Programmierers erweitert sich bei dieser Aufgabenstellung natuerlich um eine Reihe zusaetzlicher Funktionen.

Hier liegt der eigentliche Wandel, der sich bei Phoenix durch Client-Server und Prozessorientierung im Softwarebereich ergeben hat. Die Mitarbeiter kooperieren in Projektrunden mit den Anwendern und sind regelmaessig vor Ort im Einsatz. Schliesslich sollen sie wissen, was dort vor sich geht. Nur dann koennen sie die Bedeutung von Anwenderwuenschen fuer den Arbeitsablauf einschaetzen.

Da Marner, wie er es ausdrueckt, keinen Elfenbeinturm wuenscht, muessen die Mitarbeiter neben ihrer methodischen Arbeit immer auch in ein Projekt mit Anwenderkontakt eingebunden sein.

"Nichts waere schlimmer", so der DV-Verantwortliche, "als eine DV- Abteilung, die nicht mehr weiss, fuer wen sie arbeitet." Nach seiner Erfahrung ist Kundennaehe auch fuer interne Dienstleister eine Schluesselqualifikation.

Von seinen Mitarbeitern erwartet Marner daher neben fachlicher Qualifikation eine hohe persoenliche Kompetenz im Umgang mit dem Anwender. Fuer Software-Hochtechnologie seien die Anbieter von Standardsoftware zustaendig. Seine Leute sollen sich um die wirklich wichtigen Dinge kuemmern, sprich: die Funktionalitaet der Standardsoftware fuer das Unternehmen und den Anwender nutzbar zu machen sowie den Usern vertiefte Kenntnisse zu vermitteln. "Es geht darum", so Marner, "die Verbindung zwischen betriebswirtschaftlichen Prozessen und Software zu intensivieren."

Auch auf Anwenderseite hat sich die Situation veraendert. Im Phoenix-Management traeumt niemand von der menschenleeren CIM- Fabrik. Durch die Client-Server-Umgebung ist dort die Verantwortung jedes einzelnen Mitarbeiters gewachsen. Wer in den Werkstaetten arbeitet, muss das Steuerungsgefuege, in dem er taetig ist, verstehen und beeinflussen koennen. Das setzt die Durchschaubarkeit sowohl der Ablaeufe als auch der DV-Hilfsmittel voraus. Dafuer sorgen unter anderem die strengen hausinternen DV- Standards.

Die DV-Grundregeln bei Phoenix

- Erst Restrukturierung der Arbeitsablaeufe,

- dann Restrukturierung der Datenverarbeitung,

- Individualsoftware und Portierung nur in Notfaellen,

- konsequente Nutzung von Standardsoftware sowie

- anwendungs- und prozessorientierte Pflichtenhefte mit eindeutigen Vorgaben fuer eine einheitliche DV-Infrastruktur. Das Standard- Betriebssystem ist Unix, die Datenbank und die Entwicklungsumgebung kommen von Oracle.

Phoenix Contact

Die Phoenix Contact GmbH & Co., Blomberg, stellt Reihenklemmen, industrielle Steckverbinder, Interface- und Feldbus-Systeme fuer die Industrie her.

Verteilung ist bei der Phoenix Contact GmbH & Co. nicht nur ein internes DV-Konzept, sondern wird auch in die eigenen Produkte fuer die industrielle Steuerung eingebaut. Wenn zum Beispiel ein Fliessband mit zehn Motoren angetrieben wird, erwartet man zu Recht, dass alle gleichzeitig anlaufen und dieselbe Geschwindigkeit erreichen. Heute sorgt dafuer der "Interbus", der sich als eine Art echtzeitfaehiges Ethernet beschreiben liesse. Natuerlich werden hier keine Ethernet-Techniken verwendet, sondern Protokolle der Prozessindustrie. Ausserdem leistet Ethernet keine Echtzeitverbindungen. Eingesetzt wird diese Technik zum Beispiel bei der Karosseriefertigung des neuen VW-Golf und der Mercedes-C- Klasse. Ausgeliefert wurden bisher rund 350000 Knoten, sprich Geraete.