Da war ich also, von Charlie zu Boden gedrückt ...
Lassen Sie mich von vorne anfangen. In einem früheren Leben war ich als SAP-Administrator für ein bekanntes Werkzeugunternehmen tätig. Ich erinnere mich, dass ich gegen 21 Uhr einen Anruf von einer Benutzerin erhielt, die ein Ticket aufgegeben hatte, weil sie ihre Lieferscheine nicht ausdrucken konnte. Ich wusste, dass das ein schwerwiegendes Problem war, welches das Unternehmen eine Menge Geld kosten könnte. Uns allen ist bewusst, wie wichtig Lieferscheine sind. Keine Sendung, keine Bezahlung. Zudem könnten Strafen für die Nichteinhaltung unserer SLAs anfallen.
Der Support-Techniker, der für diesen Standort zuständig war, war bereits nach Hause gegangen. Ihn zurückzupfeifen hätte noch mehr Zeit und Geld gekostet. Als ich mich mit der Benutzerin in Verbindung setzte, gab sie an, dass das Problem sowohl auf ihrem Computer als auch auf dem Computer ihres Kollegen auftrat und sie derzeit die Lieferscheine von Hand ausfüllten. Die Lösung des Problems war letztendlich ein Neustart des Windows-Druckservers, den das Engineering-Team ca. eine Stunde später durchführte. Besonders frustrierend: Die Verzögerung wurde dadurch verschlimmert, dass es einige Zeit in Anspruch nimmt, den Weg der Ausgabe nachzuvollziehen. Und als besonderes Salz in der Wunde ließ sich nicht ermitteln, wie viele Aufträge in der Druckerqueue bei diesem Vorgang gelöscht wurden.
Später, beim Support mobiler Mitarbeiter (Servicetechniker), traten Probleme beim Faxversand auf. Die mobile Belegschaft nutzte mehrere Kanäle, um Aufgaben an die Techniker vor Ort zu senden (wo sie hin müssen, was zu reparieren ist usw.). Eine beliebte Methode waren Faxnachrichten, eine andere stellte der Versand von Pager-Nachrichten (ja, alte Pager aus den 1990er-Jahren) dar. Faxnachrichten schlugen manchmal aufgrund von Problemen mit dem Faxserver fehl und mussten neu gesendet werden. Das offensichtliche Problem beim Faxen besteht darin, dass die Person, die den Auftrag sendet, selten mit Sicherheit weiß, ob das Fax auch tatsächlich beim Empfänger eingetroffen ist. Die Bestätigung der Zustellung war zeitaufwändig und nervenaufreibend. Rückblickend hätte dies ganz einfach über einen grundlegenden LRS-Dokumentenspeicher und Aufbewahrungssoftware automatisiert werden können.
Ich habe unzählige dieser „Kriegsgeschichten“ zu fehlgeschlagenen Druckvorgängen auf Lager, aber die schlimmsten davon haben mit dem Neudruck von Bestellungen zu tun. Neudrucke sind in jedem Lager bzw. in jeder SAP-Umgebung im Allgemeinen sehr gefährlich. Warum? Weil sie das Risiko bergen, dass Bestellungen mehrfach versendet werden. So summieren sich die Kosten für den Neudruck, die überflüssigen Versandkosten, die Kosten für den doppelt versendeten Gegenstand und die Kosten für den Rückversand des Gegenstands vom Kundenstandort auf (natürlich nur, wenn er den Gegenstand nicht einfach behält). Hinzu kommt, dass man vor dem Kunden oder Partnerunternehmen wie ein kompletter Trottel dasteht.
Normalerweise meiden Administratoren Neudrucke wie die Pest, aber sie sind ein notwendiges Übel. Wenn man Benutzern die Verantwortung für ihre eigenen Neudrucke überträgt, verringert sich das Risiko doppelter Sendungen. Auch hier hätten Dokumentenspeicher und Aufbewahrungssystem von LRS Abhilfe geschaffen.
Kurz gesagt: Drucken kann in Umgebungen, in denen Waren versendet oder Dienstaufträge als Dokumente gesendet werden, ein echter Albtraum sein. Eine robuste Output Lösung kann Frontline-Mitarbeitern und den Support-Teams, die sie unterstützen, viel Geld, Zeit und Stress ersparen. Dank meiner Zeit im IT Serviceteam dieses Werkzeugunternehmens weiß ich die LRS-Software, die ich heute empfehle, erst richtig zu schätzen.