Von Rainer Doh*

Die Mannheimer Hestia Pharma GmbH wickelt ihren Reparaturablauf mit einer verteilten PC-Loesung ab. Basiselemente sind eine Gupta- Datenbank und das Reparatur- und Kundenservicesystem "Rekus".

Reservierungssysteme, Maschinensteuerung oder Ein- und Auszahlungen am Bankschalter gelten als typische unternehmenskritische Anwendungen. Bei einem Unternehmen, das unter anderem Blutdruck- und Blutzuckermessgeraete repariert, wuerde man eine Mission-critical-Client-Server-Loesung zunaechst vielleicht nicht suchen. Um nichts anderes handelt es sich aber bei der Software, mit der die Hestia Pharma GmbH in Mannheim ihr Reparaturwesen steuert.

"Fuer die Betroffenen sind solche Geraete oft genug lebenswichtig, und entsprechend unternehmenskritisch ist es fuer die Hestia, dass die Reparaturen nicht nur zuegig abgewickelt werden, sondern dass sie den besorgten Kunden auch jederzeit Auskunft ueber den Stand der Reparatur geben kann", erklaert Rolf Safferthal, technischer Leiter der Hestia.

Jaehrliche Reparatur von 70 000 Geraeten

Die Mannheimer setzen nicht bloss ein paar Messgeraete instand: Die Boehringer-Tochter hat als Marktfuehrer einige Millionen Blutdruck- und Blutzuckermessgeraete verkauft und muss ein jaehrliches Reparaturaufkommen von durchschnittlich 70000 Geraeten abwickeln. Normalerweise senden feste Kunden, Apotheken oder medizinische Fachgeschaefte die Geraete ein; insgesamt zaehlt die Hestia mehr als 27000 Stammkunden.

Pro Tag werden im Durchschnitt 280 Reparaturvorgaenge bearbeitet. In etwa einem Viertel der Faelle ist ein Kostenvoranschlag zu erstellen, was bedeutet, dass die Vorgaenge nach einer Antwort des Kunden erneut in Angriff zu nehmen sind. Fuer die Hestia ergibt sich im Reparaturbetrieb ein erhebliches Datenaufkommen, das bis Ende 1993 auf Basis des Durchschlagpapiers verwaltet wurde.

Diese umstaendliche Form der Abwicklung wirkte sich auch negativ auf die Durchlaufzeit der Reparaturen aus. Selbst bei eiligen Auftraegen konnte die Rechnung erst einige Tage nach dem Warenausgang gestellt werden.

Die Moeglichkeiten, bei Rueckfragen Auskunft ueber die im Haus befindlichen Geraete und deren Reparaturstatus zu geben, waren sehr begrenzt, was wiederum zu einer zusaetzlichen Arbeitsbelastung fuehrte: Anrufer, die die unverbindliche Auskunft "Wir koennen Ihnen noch nicht sagen, wann das Geraet fertig ist" erhalten hatten, meldeten sich garantiert ein paar Tage spaeter mit derselben Frage wieder. Haette man ihnen gleich einen praezisen Termin nennen koennen, waere dieser Anruf ueberfluessig gewesen.

Zusammen mit dem Mannheimer Systemhaus CC&T wurde deshalb die Client-Server-Loesung Rekus (Reparatur- und Kundenservicesystem) entwickelt, die den kompletten Reparaturdurchlauf abbildet. Damit faellt das Durchschlagwesen waehrend der Reparatur weg, der Durchlauf selbst wird beschleunigt, und durch das System ist jederzeit eine exakte Auskunft ueber den aktuellen Stand der Dinge zu erhalten.

Bei der Warenannahme werden nun die Geraete - hauptsaechlich Blutdruck- und Blutzuckermessgeraete verschiedener Typen - und die Begleitschreiben mit einer fortlaufenden Barcodenummer versehen, die den Vorgang bis zur Auslieferung begleitet. Mit einem Front- end-Modul fuer den Erfasser am PC wird der Vorgang einem Kunden zugeordnet.

Auch die Reparatur selbst erfolgt bei der Hestia jetzt DV- gestuetzt: Fuer jeden Geraetetyp sind moegliche Stoerursachen und Fehlerquellen definiert, die der Techniker dem Vorgang zuordnet und die vom System auf Plausibilitaet geprueft werden. Ist ein Kostenvoranschlag zu erstellen, endet die Bearbeitung hier; der Techniker veranlasst die Ausgabe eines entsprechenden Schreibens, das Geraet wandert in ein Zwischenlager.

Spezialfaelle erfordern eine komplexe Anwendung

Soll eine Reparatur erfolgen, aktiviert der Techniker den Vorgang, setzt das Geraet instand und veranlasst schliesslich den Druck von Lieferschein und Rechnung. Was einfach klingt, ist es oft nicht: Zahlreiche Spezialfaelle machen eine komplexe Applikation notwendig. So gibt es etwa Sammelauftraege, wenn beispielsweise eine Apotheke mehrere Geraete einsendet, fuer die aber nur einmal die Versandkosten anfallen.

Durch die Zuordnung von Geraetetypen und Fehlern gewinnt die Hestia auch Informationen ueber die Fehlerhaeufigkeit: "Solche Daten sind fuer die Qualitaetssicherung und vor dem Hintergrund der Produkthaftung von besonderer Bedeutung", erklaert Safferthal. "Ohne das Rekus-System waren diese Informationen nicht im erforderlichen Umfang und mit der noetigen Aktualitaet zu erhalten. Wir erfahren aus diesen Daten etwas ueber typische Fehler von Geraeten und koennen sogar feststellen, ob Fehler in bestimmten Serien ueberdurchschnittlich oft auftreten. Das kann letztlich auch dazu fuehren, dass die Bauweise dieser Systeme geaendert werden muss."

Entscheidende Verbesserungen ergaben sich auch in puncto Kundeninformation: Die Hestia kann nun praezise Auskunft ueber die festgestellten Fehler, die zu erwartenden Kosten und die voraussichtliche Fertigstellung geben. In dringenden Faellen - insbesondere fuer Diabetiker ist die regelmaessige Blutzuckerkontrolle wichtig - koennen Austauschgeraete auch vorab verschickt werden.

In der naechsten Phase des Projekts will Hestia auch die Kundenbriefe, die die Fehlerbeschreibung enthalten und den Geraeten heute nur beigeheftet werden, elektronisch erfassen und archivieren.

Den Kern der Client-Server-Loesung bildet die Datenbank SQL Base von Gupta - eine Entscheidung, die nicht zuletzt aus Kostengruenden so ausfiel. "Unsere Datenbank muss auch hausintern wartbar sein", erklaert Safferthal. "Einen Administrator wollen wir nicht extra abstellen. Fuer das Projekt Rekus ist die Dimensionierung genau richtig, und die bisherigen Erfahrungen zeigen auch, dass alles funktioniert."

Derzeit waechst die Datenmenge des Unternehmens allein in Sachen Auftragsdaten taeglich um etwa ein Megabyte. Insgesamt sind schon ueber 200 MB erreicht.

Da sich aber rund 80 Prozent der Arbeit auf die Daten der letzten drei Wochen beziehen, ist ein Modul in Planung, das weiter zurueckliegende Daten automatisch in ein Archiv uebertraegt.

Die Front-ends, mit denen Hestia und CC&T das Projekt Rekus realisierten, sind sicher nicht alltaeglich; aus heutiger Sicht moegen sie vielleicht sogar ein wenig exotisch erscheinen. Einige Module - beispielsweise die Vorgangserfassung - wurden mit Superbase erstellt, andere mit der Makrosprache von Excel, so etwa die Zuordnung von Vorgaengen und Fehlern, deren Definitionen sich in zahlreichen Excel-Tabellen befinden.

Die Druckausgabe wurde mit C++ realisiert

Die aufwendige Druckausgabe wiederum - Rechnung und Zahlungsanweisung werden parallel nebeneinander gedruckt, mit verschiedenen Schriftarten und Zeilenabstaenden - hat CC&T mit C++ realisiert. Hestias technischer Leiter Safferthal erklaert:

"Dass wir gerade diese Systeme verwenden, hat in erster Linie historische Gruende. Wir verfuegten recht frueh ueber gutes Know-how in Excel und Superbase und wollten das auch fuer unsere wichtigsten Applikationen einsetzen, zumal es vor drei oder vier Jahren noch nicht so viele Front-ends fuer SQL-Datenbanken unter Windows gab."

Gehoerte Superbase zu den Windows-Datenbanken der ersten Stunde, so mussten sich seine Anwender in der Folgezeit haeufig Sorgen um den Fortbestand dieses Tools machen. Den Erfolg des Projekts sah Hestia-DV-Koordinator Thilo Killmaier damit dennoch zu keinem Zeitpunkt gefaehrdet: "Heute wuerden wir vermutlich andere Tools, etwa SQL-Windows, einsetzen. Durch die Modularisierung der Anwendungen und die konsequente Trennung von Back- und Front-end sind wir aber von einzelnen Tools nur wenig abhaengig. Wenn es notwendig sein sollte, koennten wir Modul fuer Modul erneuern, ohne dass wir die Datenbasis aendern muessten."

Da die Hestia von Anfang an konsequent auf Client-Server gesetzt hatte, entwickelte sich aus den Altlasten der Projektentwicklung keine Zeitbombe. "Wesentlich war fuer uns, dass wir mit der Wahl der Datenbank eine wichtige, zukunftssichere Entscheidung getroffen haben."

Um die Leistungsfaehigkeit der Gupta-Datenbank auch mit Superbase und Excel voll nutzen zu koennen, wird die Verbindung zwischen Back- und Front-ends nicht mit ODBC (Open Database Connectivity) realisiert, sondern ueber eine spezielle Connectivity-Software. "Unsere eigenen Versuche mit ODBC haben ergeben, dass fuer eine derartige Applikation die Performance bei weitem nicht ausreichend waere", erlaeutert Markus Gasser, Geschaeftsfuehrer des Mannheimer Systemhauses CC&T, das Rekus bei Hestia betreut.

Desktop-Systeme stossen an ihre Grenzen

Wichtig war fuer den Anwender immer die Offenheit des Systems. Gasser unterstreicht: "Wir haben bei anderen Applikationen gesehen, dass der Einsatz von Desktop-Systemen wie Access gerade im Bereich von unternehmenskritischen Anwendungen an Grenzen stoesst. Bei der Hestia haben wir von Anfang an auf eine solide SQL- Grundlage gesetzt und sind daher von den Eigenheiten der Front- end-Systeme nicht abhaengig."

Genauso wichtig wie Systemoffenheit sind fuer Hestia Stabilitaet und permanente Verfuegbarkeit. Nachdem der komplette Ablauf der Reparaturen und die Kundeninformation einmal auf eine DV-Loesung umgestellt sind, haengt der Reparaturbetrieb von der Verfuegbarkeit der Datenbank ab; schon ein einziger Tag Systemausfall waere fuer die Hestia nicht akzeptabel.

Systemkonfiguration:

Ein 60-Megahertz-Pentium-PC mit 64 MB RAM dient als Datenbank- Server. Beim Plattenspeicher handelt es sich um ein Raid-5-System mit dreimal 1 GB Speicherkapazitaet. Derzeit sind bei der BoehringerTochter etwa 30 Arbeitsplaetze mit der Applikation "Rekus" ausgestattet.

* Dr. Rainer Doh ist freier Journalist in Muenchen.