Die (fiktive) Just in Time AG (JIT), ein Logistik-Unternehmen mit 210 Mitarbeitern, beliefert einen Großkunden und diverse Kleinkunden der Automobilindustrie mit Komponenten. Die LKW der JIT AG bringen sie von den Zulieferern zum Automobilwerk, sodass diesem keine Lagerkosten entstehen. Das Geschäftsmodell der JIT AG basiert auf der fristgerechten Lieferung, sie ist daher ihr höchstes Ziel. Um es zu erreichen, sind alle LKW mit intelligenten Terminals (GSM) ausgestattet, welche die Fahrer mit Informationen wie Start- und Zielort, Auftrag, Zeiten und Routen versorgen. Die Fahrer ihrerseits melden über die Terminals ihren aktuellen Datenstand zurück.
Die Lagerhalle der JIT AG beherbergt zwei Rechenzentren: RZ I mit produktiver AS/400 und 14 NT-Servern sowie RZ II als Backup mit einer zweiten AS/400 (mit synchron gespiegelten Daten) sowie 3 NT-Servern; das GSM-Gateway befindet sich separat in der Werkhalle.
Die Vorstandsvorsitzende Helenore Gieske ist sehr zufrieden mit dem Stand des Unternehmens. Vor allem lobt sie die gute Arbeit des IT-Leiters Franz Schuldten. Dieser möchte nun aber nach monatelanger harter Arbeit seinen Lebenswunsch, eine Safari im Kongo, verwirklichen. Als Vertreter wird Fritz Kugelfisch eingestellt. Die Zeit ist wie immer knapp, Kugelfisch wird nur zwei Monate lang eingearbeitet. Doch als Schuldten abfährt, ist er sicher, dass Kugelfisch alle notwendigen Informationen erhalten und verstanden hat. Es gibt zwar nahezu keine Dokumentationen oder organisatorische Anweisungen, aber das kann ja nach dem Urlaub nachgeholt werden...
Jeden Abend um 18.00 Uhr beginnt die Tagesendverarbeitung sowie die Berechnung der neuen Routen für die LKW. Sie dauert üblicherweise bis Mitternacht. An einem Mittwochabend um 19:15 Uhr durchbricht ein Gabelstapler versehentlich eine Leichtbauwand des Rechenzentrums I und zerstört die AS/400 total – mit ihr die Tagesproduktion vom Mittwoch.
Zehn Minuten später um 19.25 Uhr versucht der Operator vom Dienst, Fritz Kugelfisch zu erreichen. Da es keine Telefonliste gibt, ruft er eine Kollegin aus der Verwaltung an, die zufälligerweise noch Überstunden macht. Diese muss die Telefonnummer aus der Personalakte heraussuchen, sodass Kugelfisch erst um 20.33 Uhr alarmiert wird. 17 Minuten später trifft er in der Firma ein und macht einen fatalen Fehler: In der Hektik des Geschehens übersieht er, dass die Tagesdaten auf dem AS/400-Spiegelsystem mindestens noch bis 19.15 Uhr aktuell sind. Er geht davon aus, dass die Daten auf beiden AS/400-Systemen korrupt sind. Um 21:15 Uhr spielt er deshalb die Datensicherung des Vortages vom Band auf der Backup-AS/400 ein und startet die Tagesendverarbeitung. Die gesamte Tagesproduktion vom Mittwoch ist also dahin – für ein Just-in-Time-Unternehmen eine Katastrophe.
Donnerstagmorgen, 3.40 Uhr: Die Backup-Maschine läuft, Kugelfisch ist sehr zufrieden und Frau Gieske lobt seinen schnellen kompetenten Einsatz. Um 5.00 Uhr laden die LKW der JIT AG wie gewohnt ihre Daten in die Terminals, die nun aber auf dem Datenbestand von vorgestern beruhen. Die LKW-Fahrer bemerken diesen Fehler und versuchen, telefonisch über die Zentrale die aktuellen Routen zu erfahren. Leider liegen auch dort keine aktuellen Daten vor. Bis zum Abend des Donnerstags wird fast nichts an den Großabnehmer geliefert, am Freitag stehen dort dementsprechend die ersten Fertigungsstraßen still.
Fünf Wochen später kommt Franz Schuldten erholt aus seinem Urlaub zurück und erlebt eine böse Überraschung: Die JIT AG konnte die hohen Regressansprüche der Automobilindustrie nicht erfüllen und musste die Zahlungsunfähigkeit erklären. Aufgrund des nachlässigen Umgangs mit der organisatorischen Absicherung des Verfügbarkeitsmanagements müssen die Verantwortlichen befürchten, persönlich zur Rechenschaft gezogen zu werden.
Das Beispiel der JIT AG zeigt einen verheerenden Mangel: Es wurden zwar im Prinzip technische Vorkehrungen für einen Notfall getroffen, diese waren aber äußerst unzureichend dokumentiert und die notwendige Organisation war mehr oder weniger dem Handeln des Augenblicks überlassen.
Mag diese fiktive K-Fall-Story auch überzeichnet erscheinen. Erinnert sie nicht doch an die eine oder andere Gegebenheit im eigenen oder einem bekannten Unternehmen? Stör- und kleinere Notfälle, die möglicherweise "gerade noch einmal" glimpflich verlaufen sind, weil man Glück im Unglück hatte und der richtige Mann zur richtigen Zeit am richtigen Ort war? Notfälle, bei denen es mit etwas Pech aber auch anders hätte ausgehen können?
Hundertprozentige Sicherheit gibt es nicht – jedenfalls nicht zu vertretbaren Kosten. Ein strategisch geplantes Availability Management mit einer entsprechenden organisatorischen Basis zur Absicherung der Verfügbarkeit aller wichtigen Geschäftsprozesse ist aber – vor allem für Unternehmen mit hoher IT-Abhängigkeit – ein absolutes (und bezahlbares) Muss. Vorbereitete Notfallpläne sind eine unschätzbare Hilfe, wenn im Ernstfall alles "drunter und drüber" geht. Zudem sorgen sie oft auch schon im Vorfeld bei ihrer Entstehung dafür, dass die eine oder andere Maßnahme noch einmal kritisch überdacht und auf ihre Realisierbarkeit geprüft wird.
Bereits seit einiger Zeit gibt es am Markt unterschiedliche computerunterstützte Tools auf der Basis komplexer Datenbanken zum Management von Stör- und Notfällen. Daran sind hohe Anforderungen zu stellen. Das Tool muss alle vorhandenen und geschäftsprozesskritischen Ressourcen sowie deren Dokumentationen verwalten, Prozessabläufe abbilden können und alle drei Aspekte miteinander verknüpfen: Einer Ressource sollte ein Ereignis (z. B. ein Störfall) zugeordnet und gleichzeitig eine Prozesskette zur Störfallbeseitigung ausgelöst werden. Jeder IT-Mitarbeiter sollte plattformunabhängig von jedem PC-Client aus, zum Beispiel über einen Browser, darauf zugreifen und die ersten Schritte wie zum Beispiel die Alarmierung der richtigen Ansprechpartner ausführen können.
Im Notfall klaren Kopf bewahren und nur Dinge abwägen
müssen, die nicht schon vorher in Ruhe überlegt wurden...
Das Management kritischer Ressourcen – im Normalbetrieb
ebenso wie bei Betriebsstörungen bis hin zum K-Fall –
sollte durch entsprechende Tools unterstützt werden. Das
Werkzeug Alive-IT arbeitet beispielsweise mit einer Web-basierten
Architektur.
Wie sähe der Fall JIT AG aus, wenn ein entsprechendes Werkzeug im Einsatz gewesen wäre? In der Planungsphase werden im Tool oder seiner Datenbank die Ressourcen hinterlegt. Die Komplexität darf den Einsatz nicht behindern, das Front-End des Werkzeuges sollte entsprechend einfach aufgebaut sein. Den Ressourcen werden planbare Ausfallszenarien, im vorliegenden Beispiel "Zerstörung der produktiven AS/400 vor der Tagesendverarbeitung" zugeordnet. Zu jedem Ausfallszenario legt das Management vorgefertigte Prozesse zur Störungsbeseitigung an, bis hin zum Wiederanlauf der Ressource. Neben diesen Prozessen hinterlegt man auch Alarmketten, die eine Verknüpfung von zu alarmierenden Personen mit allen notwendigen Informationen wie Funktion, Telefon- und Handynummern, Vertretungsregeln usw. enthalten.
Zurück zum konkreten Fall. Sobald der Operator die Störung (Totalausfall AS/400 vor Abschluss der Tagesendverarbeitung) registriert, ruft er im Werkzeug das Lösungsmenü auf und wählt die Komponente AS/400. Unter dieser Komponente sind diverse Störungen abgelegt. Der Operator wählt "Totalzerstörung AS/400 vor Batch-Verarbeitung". Er löst damit bereits eine Alarm- und Prozesskette aus. Diese Auslösung kann die manuelle oder automatische Abarbeitung von Telefonaten bedeuten. Der Operator und der alarmierte Herr Kugelfisch erhalten aus dem Werkzeug konkrete Handlungsanweisungen zur Behebung der Störung: Sie nutzen korrekterweise die noch vorhandenen Mittwochdaten des AS/400-Backup-Systems und starten von diesem aus die Tagesendproduktion erneut. Es tritt kein Datenverlust auf, da sich die Tagesendverarbeitung problemlos wiederholen lässt. Einige nächtliche Überstunden fangen den Zeitverlust problemlos auf und am nächsten Tag können die LKW wie gewohnt und geplant rollen.
Dr. Hinrich Groninga arbeitet als Consultant bei der Controll-IT GmbH, Hamburg.
© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 4/2001, Seite 28