Client und Server sind Grundbegriffe mit sprechendem Namen. Als Clients bezeichnet man Rechner, die dem Gesamtsystem gegenueber aktiv als Auftraggeber auftreten. Server sind Rechner, die passiv als Auftragnehmer fungieren und den Clients auf ihre Anfrage hin Dienstleistungen erbringen. Die Kontrolle des Ablaufs liegt also bei den Clients. Alle Clients und Server sind ueber Netzwerke verbunden und kommunizieren darueber. Das bedeutet: In einem C/S- System gibt es in der Regel mehrere Server, das Netzwerk ist die zentrale Infrastruktur.

Die Faszination der Client-Server-Technologie liegt darin, dass die einzelnen Komponenten bedarfsgerecht skalier- und austauschbar sind. Das gesamte System hat eine granulare Struktur und kann iterativ erweitert oder verkleinert werden. Natuerlich denken wir auch - besonders im Bereich der Clients - an eine Teilautonomie von Komponenten gegenueber dem Gesamtsystem.

Soweit zur Theorie. Die Praxis sieht heute anders aus. Auch wenn die einzelnen Komponenten industrielle Massenware sind, ist eine Client-Server-Loesung ein hochkomplexes Gebilde; die Anforderungen an das Management solcher Architekturen werden in der Praxis noch kaum verstanden. Auch mit der "Freiheit" der einzelnen Komponenten ist es nicht weit her. Ein Client - meist ein PC - ist integraler Bestandteil des Ganzen, und lokale Aenderungen (zum Beispiel Einspielen einer Software durch den PC-Benutzer) koennen zur Destabilisierung des Gesamtsystems fuehren. Wir muessen also feststellen, dass die Zeit der grossen PC-Freiheit mit der Einbindung in ein C/S-System vorbei ist. Offenbar faellt dies in der Praxis jedoch immer noch zu spaet auf.

Kommen wir zu unserem Beispiel, dem Computer-aided Selling (CAS), ein bekanntlich aeusserst schillernder Begriff. Leider liegt die Betonung in der Praxis zu stark auf dem "C" und zu wenig auf dem "S". Diese verzerrte Sicht ist nicht nur eine Berufskrankheit der DV-Mitarbeiter, sondern grassiert auch in den Fachabteilungen, die sich oftmals lieber mit der Datenverarbeitung als mit ihren Stammaufgaben befassen.

Es hilft, den abstrakten Begriff des CAS-Systems durch eine entsprechende Klassifizierung zu verdeutlichen. Beispielsweise unterscheidet Klaus-D. Wilde1) Administrations- von Informationssystemen. Loesungen der ersten Kategorie unterstuetzen operative Vertriebsaufgaben (zum Beispiel Angebotserstellung und Auftragserteilung beim Kunden). Vertreter der zweiten Kategorie dienen der Datensammlung (Data-Warehouse), Informationsgewinnung sowie der Planungs- und Entscheidungsunterstuetzung.

Die Informationssysteme lassen sich weiter in Vertriebsinformationssysteme fuer die Verarbeitung unternehmensinterner Daten und in Marktinformationssysteme, die unternehmensexterne Daten verarbeiten, unterteilen. In der Anwendungspraxis werden meist nur die Administrationssysteme als CAS-Systeme bezeichnet.

Leider beruecksichtigen Definitionen dieser Art nur einen Teilaspekt von CAS-Architekturen. Sie beschraenken sich im wesentlichen auf das Gewinnen und Verarbeiten von (ueberwiegend strukturierten) Daten. Immer wichtiger werden jedoch die Kommunikationsfunktionen solcher Systeme. Sie muessen die Kommunikation zwischen den Mitarbeitern im Unternehmen, aber wohl noch mehr die zwischen Kunden und Unternehmen ermoeglichen.

Die Bereitstellung von Informationen fuer Kunden gewinnt zunehmend an Bedeutung. Auch Firmen, die ein physisches Produkt verkaufen, werden kuenftig zusehends produktbezogenere Dienstleistungen und Informationen anbieten muessen. Hier tun sich unter der Ueberschrift "Electronic Publishing" hochinteressante Anwendungsfelder auf.

Darueber hinaus kann eine gute Kommunikationsunterstuetzung ein wesentlicher Erfolgsfaktor bei der Einfuehrung von CAS-Systemen sein. In einem konkreten Fall aus der Praxis (Aussendienst eines Fertigungsunternehmens) nahmen die betroffenen Vertriebsmitarbeiter - einschliesslich der alten "Kaempfer" - das System spontan an, weil sie mit einemmal die Moeglichkeit hatten, per E-Mail mit Kollegen und Vorgesetzten zu kommunizieren. Die vielen vergeblichen Versuche, eine firmeninterne Telefonverbindung herzustellen, entfielen nun. Das sparte eine Menge Arbeitszeit und brachte eine wesentliche Verbesserung ihrer Situation - das "neumodische" System war damit akzeptiert.

Es mag verwundern, dass die Konzeption von CS-Systemen in diesem Beitrag noch als eigenstaendiges Thema aufgegriffen wird. Dafuer spricht jedoch die Tatsache, dass sich in der Praxis die inzwischen klassische Erkenntnis, dass ein System um so besser und billiger wird, je sorgfaeltiger (nicht laenger!) man es plant, immer noch nicht durchgesetzt hat. Allerdings darf man auch nicht den Fehler machen, ein perfektes Konzept mit allen Detailfunktionen zu erarbeiten. Dann laeuft man Gefahr, dass die Realitaet nach der Fertigstellung des "Superkonzepts" schon wieder ganz anders aussieht.

Gerade bei der Planung von CAS-Systemen muss eine Doppelstrategie verfolgt werden. Zunaechst ist eine Gesamtkonzeption (oder Architektur) auf relativ hohem Niveau zu erstellen, die das Endsystem mit seinen Teilsystemen beschreibt und einen Realisierungspfad festlegt. Parallel dazu sollten erste Detailkonzepte fuer konkrete Teilsysteme erstellt werden. Diese Vorgehensweise besitzt den Vorteil, dass man ein Gesamtkonzept als Orientierungsrahmen hat und dem Benutzer relativ schnell funktionsfaehige Teilsysteme anbieten kann. Gerade im Vertriebs- und Marketing-Bereich ist im Zweifel Schnelligkeit wichtiger als Perfektion.

Klein anfangen und die Client-Population ausbauen

Hier kommt dem Anwender die CS-Technologie entgegen. Funktionsfaehige Teilsysteme koennen realisiert und dann iterativ durch Implementierung weiterer Server mit zusaetzlichen Diensten ausgebaut werden. Kostenguenstig ist es dabei, mit einer kleinen Benutzergruppe zu beginnen und schrittweise die Client-Population je nach Bedarf und Schulungskapazitaeten auszubauen.

Bei der Konzeption von CAS-Loesungen gibt es eine besondere Offenheitsforderung. Da sich die Geschaeftsumgebung dynamisch veraendert, muss das DV-System fuer Modifikationen und Erweiterungen der gefuehrten Daten und bereitgestellten Funktionen offen sein. Der realisierende DV-Experte muss sogar davon ausgehen, dass im Verlauf der Entwicklung die Spezifikationen geaendert werden. Deshalb sollte er unbedingt ein fuer Prototyping geeignetes Systemdesign durchfuehren.

Geeignete und leistungsfaehige Entwicklungssysteme sind am Markt erhaeltlich. Die Schwierigkeit liegt hier aber - wie in vielen Bereichen der DV - nicht in der Verfuegbarkeit von Produkten, sondern im Umgang mit ihnen. Ein offener Entwicklungsprozess, wie er gerade gefordert wurde, ist erheblich komplexer als die klassische phasenorientierte Projektabwicklung. Wie schwierig dieses Metier ist, zeigt das Beispiel "Vertriebsstatistik". Dieses geradezu historische DV-Thema ist in den allermeisten Faellen nach wie vor nicht befriedigend geloest.

Wie bereits erwaehnt, sollten Teilsysteme entsprechend einem Masterplan Zug um Zug in einer sinnvollen Reihenfolge realisiert und eingefuehrt werden. Hier bieten sich prozessorientierte Vorgehensweisen an, die dem Werdegang der bearbeiteten Daten folgen. Eine Vertriebsstatistik laesst sich zum Beispiel erst dann realisieren, wenn die Auftragsdaten im DV-System verfuegbar sind. Generell heisst das, dass erst die operativen (Teil-)systeme in Betrieb sein muessen, bevor Informationssysteme aufgesetzt werden koennen. Dies mag trivial erscheinen, wird in der Praxis jedoch oftmals nicht beachtet.

Da CAS-Systeme normalerweise in eine bestehende Anwendungslandschaft eingepasst werden muessen, sollte die Konzeption die bereits existierenden und zu nutzenden Systeme beruecksichtigen. Problematisch wird es immer dann, wenn sich aus der CAS-Konzeption Modifikationsbedarf fuer bestehende Anwendungen ergibt. Da sich so manches Altsystem praktisch nicht mehr aendern laesst, wird gegebenenfalls sogar die Realisierung der geplanten CAS-Loesung grundsaetzlich in Frage gestellt.

In diesem Zusammenhang sei auf ein weiteres Problem hingewiesen. Die Anwendungsentwicklung der letzten Jahre war beherrscht vom Integrationsparadigma. Der Erfolg der Firma SAP beispielsweise beruht auf der hochgradigen (Realtime-)Datenintegration aller Anwendungsteile. Wird diese zum obersten Gestaltungsprinzip eines CAS-Systems, duerften aehnliche Konstrukte entstehen, wie man sie bereits von bekannten Produkten her kennt.

Es entsteht ein zentraler Datenbestand, der automatisch zum Engpassfaktor des Systems wird. So laeuft man Gefahr, mit der verteilten Technologie monolithische Systeme der alten Art zu generieren.

Es muss jedoch klar sein, dass mit einer Erhoehung des Integrationsgrads die Komplexitaet und damit auch die Kosten steigen. Brauchen wir eigentlich die permanente Realtime- Integration aller Daten? Die Antwort lautet in den meisten Faellen: Nein.

Aufgabe der Konzeption ist es also, eine CS-adaequate und dezentrale Datenorganisation aufzubauen. Das ist eher ein organisatorisches als ein technisches Problem. Die Benutzerfreundlichkeit braucht darunter keineswegs zu leiden, denn der Umgang mit komplexen Datenstrukturen ist auch bei zentraler Datenhaltung nur Fachleuten (im Sinne von "expert users") zuzumuten. Und das Arbeiten mit mehreren Datenbanken ist sowieso noetig, wenn externe Datenbestaende ausgewertet werden.

Ein Betriebssystem fuer alle Rechner?

Grundsaetzlich sollte ein CAS-System auch eine Datenhaltung fuer unstrukturierte Daten (Dokumente) ermoeglichen und entsprechende Recherchefunktionen anbieten. Gerade in der Zusammenarbeit mit Kunden fallen viele "weiche" Daten an, etwa handschriftliche Notizen in der Kundenakte, die nicht im Sinne relationaler Datenbanken strukturierbar sind, in ihrer Bedeutung fuer den Markterfolg jedoch nicht unterschaetzt werden duerfen. Es gibt bereits eine Reihe konkreter Beispiele fuer Vertriebs- informationssysteme, die auf der Basis sogenannter Groupwareprodukte realisiert wurden und entsprechende Funktionalitaet bieten.

In der Konzeptionsphase muessen auch DV-technische Fragen behandelt werden. Zunaechst geht es um die "optimale" Zuordnung der Datenbestaende und Funktionen zu den Knoten des geplanten Client- Server-Systems. Aus dieser Zuordnung ergeben sich Leistungsmerkmale fuer die Rechner und deren Betriebssysteme, aber auch Parameter fuer die Konzeption des Netzwerks. Bei den Rechnern waere es im Sinne einer Minimierung der eingesetzten Technologien und Produkte ideal, wenn sich ein Betriebssystem durchgaengig fuer alle Server und Clients einsetzen liesse.

Der Traum vom wirklich offenen System

Ob beispielsweise Windows NT eine solche Plattform sein kann, bleibt abzuwarten. Befriedigender waere es, wenn Rechner und Betriebssysteme Black boxes waeren, die man im Plug-and-play- Verfahren in die Netzwerke einhaengt. Das waeren im Sinne der Austauschbarkeit von Komponenten wirklich offene Systeme. Da dies jedoch (vorerst) ein schoener Traum bleiben wird, muss eine Entscheidung bezueglich der Betriebssysteme getroffen werden.

In der Praxis sollte man maximal zwei Betriebssysteme zulassen, zum Beispiel je ein Client- und ein Server-Betriebssystem. Abweichungen davon sind eventuell erforderlich, sollten aber begruendbar sein. Schliesslich unterliegt der Anwender in verschiedener Hinsicht den "Economies of scale" - hinsichtlich der Beschaffung und des Vorhaltens von Skills fuer die nachfolgende Betriebsphase. Hier ist auch zu beruecksichtigen, dass in der Regel bereits umfangreiche Client-Systeme (PCs am Arbeitsplatz) vorhanden sind - meist auch Server und Netzwerke. Sofern nichts eindeutig dagegen spricht, sollte man bei den im Unternehmen etablierten Standardprodukten bleiben und das CAS-Projekt nicht zusaetzlich durch die Auswahl neuer Betriebssysteme belasten.

Diese Aussagen gelten fuer die Datenkommunikation ebenso. Die Minimierung der eingesetzten Produkte oder Technologien ist auch hier ein Mittel, die Komplexitaet in einem ertraeglichen Rahmen zu halten und wirtschaftlich zu arbeiten. Bei der Nutzung externer Netze etwa fuer die standortuebergreifende Datenkommunikation spielen die Kosten der abgenommenen Uebertragungsleistungen eine erhebliche, wenn nicht sogar die wichtigste Rolle.

Zwar ist ISDN inzwischen zu einer Default-Technologie geworden, ob es aber stets die wirtschaftlichste Loesung darstellt, ist im konkreten Fall sorgfaeltig zu pruefen. Gerade bei einem extremen Bandbreitenbedarf sollte man nicht einfach nur auf eine leistungsfaehige Technologie zurueckgreifen, sondern noch einmal genaustens hinterfragen, ob man diese hohe Uebertragungsleistung auch tatsaechlich benoetigt.

In Unternehmen mit mehreren Standorten spielt die unternehmensinterne Datenkommunikation per WAN eine zunehmend wichtigere Rolle. Da dies nicht nur fuer CAS-Systeme, sondern fuer alle Anwendungen gilt, sollte man moeglichst auf ein Corporate Network zurueckgreifen koennen. Wenn fuer das CAS-System ein eigenes Netzwerk geschaffen werden muss, blaeht dies das Projekt erheblich auf, macht es komplexer und schwieriger. Falls bereits ein Corporate Network existiert, darf keinesfalls ein zweites anwendungsspezifisches Netzwerk errichtet werden - leider ist jedoch genau das in vielen Unternehmen der Fall.

Nach Ansicht von Experten wird Telekommunikation, das heisst die Uebertragung beliebiger Daten (inklusive Sprache), das zentrale Infrastrukturthema der DV in den kommenden Jahren werden. Die traditionelle Aufteilung dieser Thematik in den Unternehmen - Datenkommunikation zur DV und Telefonie zur Organisationsabteilung - ist aufgrund der technischen Moeglichkeiten und der Deregulierung im oeffentlichen TK-Bereich obsolet geworden. Es handelt sich ausserdem um ein Beschaffungsthema. Da sollte man den Bedarf buendeln und die Einkaufsmacht des Unternehmens erhoehen. Diese Erkenntnis konnte sich in den Unternehmen jedoch noch nicht ueberall ausreichend durchsetzen.

Ein wichtiger Bestandteil eines CAS-Systems sind die intelligente Benutzerverwaltung und -steuerung in Verbindung mit leistungsfaehigen Hilfsfunktionen. Die Performance solcher Systeme, die ja in der Endausbaustufe umfangreiche Daten- und Funktionsbestaende anbieten, wird entscheidend davon abhaengen, wie gut sich ein Benutzer im System auskennt und die Daten und Funktionen findet, die er fuer seine Arbeit benoetigt. Im Sinne der Komplexitaetsreduktion ist es oftmals sogar angebracht, nicht nur Datenbestaende, sondern auch Funktionen entsprechend den verschiedenen Benutzergruppen zu entkoppeln, so dass man also kein einheitliches, sondern vielleicht "nur" ein Konglomerat verschiedener "spezifischer" CAS-Systeme erhaelt.

Die Realisierung von DV-Systemen ist sicherlich das in der Praxis traurigste Kapitel. Das liegt zum einen an der Differenz zwischen dem, was der Benutzer eigentlich braucht, was er bestellt, was die DV-Experten verstehen und was sie letztlich realisieren. Zum anderen liegt es daran, dass einfachste Regeln des Projekt- Managements in der Praxis immer noch nicht ausreichend beachtet werden. Dabei kennen die DV-Experten das Handwerkszeug in der Regel recht gut. Die Arbeitskultur in unseren Unternehmen ist jedoch trotz anderslautender Absichtserklaerungen haeufig nicht projektfaehig. Wenn man Projekte nur als unliebsame Ergaenzungen des Tagesgeschaefts ansieht und - besonders in den Fachabteilungen - nicht in der Lage ist, die geeigneten Mitarbeiter dafuer freizustellen, dann darf man sich ueber armselige Resultate nicht wundern.

Realisierung: Mitarbeit der Fachbereiche entscheidet

Eigentlich ist die Realitaet noch banaler: Der Fachbereich als Auftraggeber laesst ein Projekt anlaufen, kuemmert sich aber anschliessend gar nicht oder nur noch halbherzig darum. Wieviel Energie muss in der taeglichen Unternehmenspraxis aufgewandt werden, um den Auftraggeber dazu zu bewegen, seine Pflichten im Projekt wahrzunehmen ... Das betrifft zwar auch, aber nicht nur die Realisierung von CAS-Systemen.

Es wurde bereits angedeutet, dass es eine umfassende CAS-Loesung aus einem Guss nicht geben kann. Bei der Realisierung und Einfuehrung der Teilsysteme kommt ein weiterer Aspekt hinzu: Die Realisierungszeiten von DV-Systemen sind zu lang, die "Time to usage" muss signifikant reduziert werden. Dazu muss man sich von der herkoemmlichen linearen und perfektionistischen Vorgehensweise loesen und zu Realisierungstechnologien uebergehen, die bei hoher Qualitaet in kurzer Zeit zu funktionsfaehigen (Teil-)systemen fuehren. Gerade im dynamischen Vertriebs- und Marketing-Bereich stellen daher Datenbank- und Entwicklungssysteme, die auf Prototyping-Methoden basieren, wirksame Realisierungsinstrumente dar.

Auch hier gilt der Rat, Vorhandenes zu nutzen: Wenn im Unternehmen bereits solche Plattformen verfuegbar sind, sollte man aus den genannten Gruenden fuer die Realisierung des CAS-Systems moeglichst auf die vorhandene Infrastruktur zurueckgreifen.

Auch hier stellt sich die Frage, ob man CAS-Systeme komplett individuell realisieren muss oder ob sich solche Loesungen in Form von fertiger oder vorkonfektionierter Software erwerben lassen.

Sicher sollte man, soweit verfuegbar, auf fertige Produkte zurueckgreifen. Allerdings ist gerade im Vertriebs- und Marketing- Bereich zu pruefen, in welchem Masse Standardsoftware die indviduelle Situation des Unternehmens darstellen kann. Wenn sich per DV Wettbewerbsvorteile erzielen lassen, dann gewiss in diesem Bereich. Eine Standardsoftware wird zunaechst nur Standardfunktionalitaet bieten.

Insofern kommt der Einsatz solcher Programme zwar in Frage, die fuer das Unternehmen wirklich interessanten Teile, mit denen sich auch Wettbewerbsvorteile generieren lassen, muessen aber wahrscheinlich individuell gefertigt werden. Hier empfiehlt sich ein Loesungsansatz, der von einer durchgaengigen Datenbank- und Entwicklungsumgebung ausgeht, fuer die Anwendungen und Module am Markt verfuegbar sind.

Bei parallelem Einsatz unterschiedlicher Produkte (zum Beispiel einer Standardsoftware und eines separaten Datenbanksystems fuer individuelle Anwendungsteile) ergeben sich zum Teil Schwierigkeiten im Bereich der (technischen) Schnittstellen. Dahinter stehen jedoch in der Regel komplexe organisatorische Probleme. Zum Beispiel muss bei redundanter Datenhaltung der Aspekt der Datenfuehrerschaft zwar auch technisch, vor allem aber organisatorisch geklaert werden.

Jedes DV-System realisiert seinen Nutzen erst im taeglichen Betrieb. Es wird beim Anwender nur dann Akzeptanz finden, wenn es die von ihm erwartete Verfuegbarkeit, Betriebssicherheit und Funktionalitaet aufweist. Diese drei Punkte koennen nur als Einheit gesehen werden.

Der Betrieb von DV-Systemen ist wie der herkoemmlicher Produktionsanlagen zu planen und zu steuern. Dabei muessen alle Fragen des klassischen Produktions-Managements beantwortet werden. Die Belange des spaeteren produktiven Betriebs sollten bereits bei der Konzeption beachtet werden. Nicht nur die Fachabteilung, auch die DV-Betriebsorganisation (Rechenzentrum) zaehlt zu den Benutzern von DV-Systemen. Leider wird diese Tatsache in der Praxis kaum beachtet.

Eine Zukunft ohne RZ ist unwahrscheinlich

Selbst professionelle Softwareproduzenten liefern ihren Kunden Systeme, die erst vor Ort und vom Kunden "produktionsfaehig" gemacht werden muessen. Diese Probleme sind RZ-Leitern aus der Mainframe-Umgebung hinlaenglich bekannt, und in der Client-Server- Welt ist es leider nicht anders. Bislang geht man in der Nicht- Mainframe-DV mit solchen Fragen noch recht leichtsinnig um. Sicherheit und Katastrophenvorsorge werden vernachlaessigt; der zentrale Auftragsdatenbestand auf dem Server neben dem Schreibtisch ist keine Seltenheit.

Es herrschen unterschwellig die Vorstellung und der Wunsch, im Client-Server-Umfeld ohne das ungeliebte Rechenzentrum auszukommen. Doch werden wir in den kommenden Jahren dessen Renaissance erleben - weil man fuer den Betrieb komplexer Client- Server-Systeme professionelle DV-Betriebsorganisationen ganz einfach benoetigt. Vielleicht heissen diese neuen Organisationen nicht mehr Rechenzentrum, sondern Server-Zentrum oder Server- Leitstand.

Methoden und Produkte richtig einsetzen

Zusammenfassend laesst sich sagen, dass die Probleme und Anforderungen bei Entwicklung und Betrieb von Client-Server- Systemen nicht grundsaetzlich neu sind. Wie im traditionellen Zentralrechnerumfeld gibt es auch hier kein Patentrezept mit Erfolgsgarantie. Obgleich es sich um eine relativ neue Technologie handelt, haben wir auch hier keinen Mangel an Methoden oder Produkten, sondern leiden an Defiziten im Umgang mit ihnen. Grundsaetzlich naemlich gilt auch im Client-Server-Umfeld:

-In der Konzeptionsphase braucht man gute Ideen und saubere gedankliche Vorarbeit.

-In der Realisierungs- und Einfuehrungsphase braucht man sorgfaeltige Planung und ein professionelles Projekt-Management.

-In der Nutzungsphase braucht man eine professionell organisierte Betriebs- und Produktionsinfrastruktur.

* Dr. Martin Kuetz ist Berater bei Arthur D. Little in Wiesbaden.

Kurz & buendig

Bei Konzeption, Realisierung und Betrieb einer Client-Server- Umgebung - in diesem Fall einer Computer-aided-Selling-(CAS- )Umgebung - gilt es wichtige Grundregeln zu beachten. So sollte bei der Planung des Systems eine Doppelstrategie verfolgt werden: Neben einem Gesamtkonzept auf hohem Niveau sind eine Reihe von Teilkonzepten fuer Detailaufgaben anzufertigen - und zwar in moeglichst kurzer Zeit. Der gelungene Betrieb haengt massgeblich davon ab, dass eine professionell organisierte Betriebs- und Produktionsinfrastruktur aufgebaut wird, in der die Verantwortlichkeiten klar definiert sind - dabei ist das Rechenzentrum sinnvoll einzubinden.

Literatur:

1) Klaus-D. Wilde: EDV-Anwendungen in Marketing und Vertrieb: Stand und Entwicklungstendenzen. In: EDV-Anwendungen im Unternehmen, hrsg. von B. Huch und P. Stahlknecht, Frankfurt 1987, S. 105 ff.)