Wenn Produktionssysteme rund um die Uhr laufen, müssen auch die Menschen dahinter jederzeit handlungsfähig sein. Genau dafür gibt es die Rufbereitschaft. Sie ist ein wichtiger Bestandteil des Betriebs und sorgt dafür, dass kritische Systeme auch außerhalb der regulären Arbeitszeiten zuverlässig unterstützt werden können.
Die Realität hinter dem Diensttelefon
4:00 Uhr morgens, Samstagnacht. Ich schlafe nicht – nichts Neues. Seit Dienstag habe ich keine einzige Nacht durchgeschlafen, ohne aus dem Bett aufspringen zu müssen. Über das Diensttelefon spreche ich mit einem Anwender „unserer“ Produktionssysteme und versuche zu verstehen, warum ein Problem, das seit Donnerstagmorgen besteht, erst am Samstag um 4:00 Uhr morgens an unser Team eskaliert wurde – als etwas, das unter keinen Umständen warten kann.
„Darauf kann ich nicht antworten, ich weiß es nicht. Eigentlich ist es keine Priorität, es kann problemlos bis Montag warten“, behauptet mein Gesprächspartner, übrigens sehr freundlich im Ton und in seiner Ausdrucksweise.
Einstellung ist key
Manche von euch würden sich vielleicht ärgern, und vielleicht hätten sie sogar das Recht dazu. „Warum holen sie mich mitten in der Nacht aus dem Bett?“ Ich sehe das anders. Ich fühle eher Erleichterung und ein Gefühl der Erfüllung einer wichtigen Pflicht. Schließlich ist es meine Aufgabe, das Funktionieren der Systeme sicherzustellen. Außerdem helfe ich gerne in schwierigen Situationen und löse Probleme – und genau damit haben wir es hier zu tun. Manchmal besteht eine gut ausgeführte „Aktivierung“ nicht ausschließlich darin, einen Incident zu lösen, sondern darin, mit dem Betrieb die verfügbaren Optionen zu besprechen, das Problem selbst sowie seine Auswirkungen auf die Systeme zu analysieren. Oft gehört dazu auch eine gewisse verbale Unterstützung, die paradoxerweise einen großen Einfluss auf die gesamte Situation hat – aber dazu gleich mehr.
Jede Meldung, die die Rufbereitschaft erreicht, ist ein Signal dafür, dass irgendwo etwas nicht so funktioniert, wie es sollte. Manchmal kann die Rechtmäßigkeit solcher Meldungen in der Eskalationskette nicht überprüft werden, bevor nicht jemand mit entsprechender Erfahrung und dem nötigen Wissen erscheint, um die Situation objektiv zu beurteilen – das ist unsere Rolle.
Gefährdung der Produktionskontinuität
Wie wichtig die Rufbereitschaft für unser Projekt ist, ist auf den ersten Blick vielleicht nicht offensichtlich. Was kann schon passieren? Bekommt jemand die angeforderten Berechtigungen nicht? Kann sich jemand nicht in ein System einloggen? Ja – und nein. Das Thema ist viel komplexer, deshalb gehen wir kurz ins Detail.
Grundsätzlich hat jede Meldung, die außerhalb der Bürozeiten an unser Team eskaliert wird, einen direkten Einfluss auf die Kontinuität von Produktions- und Logistikprozessen des Kunden. Die gemeldeten Vorfälle können (müssen aber nicht) direkt die Stabilität industrieller Systeme gefährden – von der eigentlichen Stahlproduktion bis hin zu Logistik und Planung. Wir sind also in jeden wichtigen Prozess eingebunden, der den reibungslosen Ablauf beeinflusst.
Hinter jeder erfolgreichen Rufbereitschaft steht letztlich ein klares Ziel: die Sicherstellung stabiler Produktions- und Logistikprozesse. Für Unternehmen wie thyssenkrupp Steel bedeutet das, Produktionsausfälle zu vermeiden, Lieferketten aufrechtzuerhalten und wirtschaftliche Risiken zu minimieren.
In einem so großen Unternehmen wie thyssenkrupp Steel kann jede Verzögerung potenziell katastrophale Folgen haben, was sich natürlich auch negativ auf unser Projekt auswirken würde.
Erfahrung schlägt Handbuchwissen
Die Probleme, die uns erreichen, sind daher sehr unterschiedlich. Deshalb können wir hier im Incident Management nicht von standardisierten SOP-Lösungen sprechen. Der Schein kann trügen. Trotz des Namens MES/FLS passt die Zahl der Systeme, die wir überwachen, nicht einmal auf die Finger beider Hände – und FLS ist nur der zentrale Teil dieser Landschaft.
Manchmal erreichen uns auch Meldungen aus Systemen, die wir gar nicht betreuen. Für die meldenden Nutzer ist das meist unwichtig – „Ich kenne nur diese Telefonnummer und brauche Hilfe“. Für sie vereinfacht das die Arbeit, für uns erschwert es sie deutlich. Aber irgendetwas lässt sich immer tun: Informationen in Datenbanken suchen, Punkte in JIRA durchsehen und dem Nutzer raten, an wen er sich wenden sollte – schließlich sitzen wir alle im selben Boot.
Multiplizieren wir also die Anzahl der Systeme mit einer noch größeren Zahl möglicher Störungen und ihrer Schnittpunkte – von Servern bis hin zu spezialisierten Programmen zur Verarbeitung bestimmter Aktionen innerhalb eines Systems. Dazu kommen menschliche Fehler und Fehlalarme, und langsam offenbart sich uns ein ganzer Ozean von Möglichkeiten, in dem wir jede Nacht waten, um herauszufinden, wo etwas nicht funktioniert, wer Zugriff darauf hat und wer es nachts beheben kann (falls wir es nicht selbst sind).
Die Last der Verantwortung
Wie man sieht, ist das alles gar nicht so einfach, wie es auf den ersten Blick erscheinen mag. Deshalb sprechen wir in unserem Team von einer Einarbeitungsphase im Projekt, die mehrere Monate bis hin zu einem Jahr dauern kann. Erst danach kann eine neue Person beginnen, sogenannte „Rufbereitschaften oder RBs“ zu übernehmen und selbstständig Entscheidungen zu treffen, die direkten Einfluss auf die industriellen Prozesse des Kunden haben.
Ich muss euch wohl nicht erklären, welche psychische Belastung es bedeutet, wenn man als neuer Mitarbeiter eine ganze Woche lang (Montag 17:00 Uhr bis Montag 8:00 Uhr – außerhalb der Bürozeiten) mit dem Gedanken konfrontiert ist, dass nun der gesamte Service auf den eigenen Schultern liegt und man in jeder Situation und zu jeder Uhrzeit zurechtkommen muss. Ich erinnere mich jedoch gut daran, wie stressig meine ersten Bereitschaften waren.
Zur Klarstellung: In den meisten dieser Systeme sind wir Administratoren, sodass jede falsche Entscheidung schwerwiegende Folgen haben und große Verluste verursachen kann. Deshalb müssen wir vor allem vorsichtig und zurückhaltend handeln. Natürlich gibt es Bereiche mit klaren Prozessen und festen Abläufen – dort können wir ohne Zögern handeln. Viele Fälle sind jedoch reine Improvisation, und auch das muss man lernen.
Natürlich sind wir nicht völlig auf uns allein gestellt – es gibt weitere Eskalationswege, und der gesamte Prozess ist sehr gut aufgebaut. Doch angesichts der Vielzahl an Themen, mit denen wir konfrontiert werden, stellt sich immer wieder die Frage: „Muss ich wirklich noch eine weitere Person aus dem Bett holen und zusätzlichen Aufwand verursachen?“ oder „Ist das überhaupt die richtige Person, die mir hier helfen kann?“
Und damit kommen wir zurück zum wichtigsten Punkt – der Erfahrung. Sie ist der Grund, warum man uns so schwer ersetzen kann. Das Wissen, das wir über Jahre hinweg sammeln, ist hier ein unverzichtbares Element.
30 Minuten Reaktionszeit – jederzeit
Der Bereitschaftsdienst ist heute eine anstrengende, aber zweifellos wichtige Pflicht in unserem Projekt. Zwar ermöglicht die über Jahre gesammelte Erfahrung meist eine schnelle Identifikation des Problems und möglicher Lösungswege, dennoch bleibt eine gewisse „Bindung“ an das Diensttelefon bestehen.
Das hängt sicherlich von der Person ab, aber für mich ist es erwähnenswert, weil es nicht für jeden selbstverständlich ist. Unser SLA beträgt 30 Minuten. Das bedeutet, dass ich nach der Eskalation eines Incidents 30 Minuten Zeit habe, um zum Computer zu gelangen, mich in die Systeme einzuloggen und den Status eines Tickets in JIRA zu ändern.
Wie ihr euch sicher vorstellen könnt, schränkt das die Freiheit, seine Freizeit außerhalb der Bürozeiten zu gestalten, erheblich ein. Nicht jeder möchte schließlich überall mit einem mobilen Hotspot und einem Dienstlaptop unterwegs sein. Zum Glück dauert eine Bereitschaftsperiode nur sieben Tage – danach wechseln wir uns ab.
Wertschätzung macht einen Unterschied
Diese Arbeitsweise hat sicherlich ihre Vor- und Nachteile. Auf jeden Fall ist es keine Arbeit für jeden. Persönlich sehe ich darin jedoch eher eine Herausforderung und eine Gelegenheit, mein Wissen und meine Erfahrung einzusetzen, um jemandem zu helfen.
Vor Kurzem ist mir etwas sehr Nettes passiert. Für die Nutzer ist es meist selbstverständlich, dass irgendwo jemand sitzt und nachts bereit ist, ihre Zweifel auszuräumen oder ein System zu reparieren – schließlich ist es seine Arbeit. Und natürlich nehme ich das niemandem übel.
Bei einer der letzten „Aktivierungen“ sagte mir jedoch ein Nutzer während unseres Gesprächs, dass er die Arbeit der Menschen, die solche Bereitschaftsdienste leisten, sehr respektiert und sich sehr für die Unterstützung bedankt.
In einer idealen Welt wäre das vielleicht selbstverständlich, doch in Wirklichkeit hören wir so etwas nur selten. Umso mehr hat es mich gefreut. Es ist schön zu wissen, dass das, was wir tun, nicht nur als Selbstverständlichkeit und Pflicht gesehen wird, sondern auch als etwas, das wir von uns ausgeben.
Deshalb habe ich vorher die verbale Unterstützung erwähnt. Es ist gut, dem Nutzer zu vermitteln, dass ich nicht nur hier bin, weil ich muss, sondern weil ich helfen möchte – und das ist ein großer Unterschied. Wenn wir mit dieser Einstellung an die Sache herangehen, wird die Arbeit angenehmer und bringt bessere Ergebnisse.
Rufbereitschaft bedeutet mehr als technische Unterstützung außerhalb der Bürozeiten. Sie bedeutet Verantwortung für geschäftskritische Prozesse, schnelle Entscheidungen unter Druck und die Bereitschaft, Menschen in schwierigen Situationen zu helfen. Genau diese Kombination macht den Unterschied – für unsere Kunden und für den Erfolg ihrer Systeme.
