Gastbeitrag: Tools lösen keine Probleme

Ich freue mich, mit dem Beitrag von Jürgen Sapara einen weiteren Gastbeitrag begrüßen zu dürfen. In seinem Beitrag betont er zu Recht, dass vor einer Investition immer erst die Prozesse zu analysieren sind. Dann klappt es auch mit dem Tool.

Sapara

Jürgen Sapara

Dipl.-Ing. Jürgen Sapara (44) ist seit 2005 in der Technischen Dokumentation tätig. Zuvor hat er nach seinem Studium der Energietechnik erst in der Industrie gearbeitet, dann mehrere Jahre als Fachjournalist (später als Chefredakteur). Seit 2007 leitet er die Abteilung Technical Documentation (inkl. des Translation Management) eines globalen Technologie-Unternehmens.

Tools lösen keine Probleme

Eigentlich weiß man das ja. Aber warum nur ist die Realität dann noch anders? Die Toolgläubigkeit in Unternehmen – auch in Technischen Redaktionen – ist weiterhin ungebrochen. Schnell wird ein ROI (Return of Invest) gerechnet, das Management ist von den Zahlen beeindruckt und stimmt der Anschaffung zu. An Beratern, welches Tool denn das Bessere sei, mangelt es auch nicht. Und schon ist das Tool im Haus.

Überraschung nach der Anschaffung
Dann beginnt die Anpassung: „Out of the box“ geht selten. Da sind die bestehenden Software- und IT-Landschaften, in die die neue Lösung eingebunden werden muss. Bei der ROI-Berechnung wird der Anpassungs-Aufwand meist nicht detailliert betrachtet. Und das, obwohl es nicht selten Mannwochen oder gar Mannmonate Aufwand sind.
Der meines Erachtens weitaus größere Faktor sind die Mitarbeiter, die immer wieder vom Nutzen des neuen Tools überzeugt werden müssen, da sie ja bei der Auswahl nicht eingebunden waren. Nicht, dass man diejenigen, die damit arbeiten sollen, gefragt hätte, wie denn das optimale Tool aussähe. Und wenn man schon mit den Mitarbeitern reden würde, wäre das eine gute Gelegenheit gewesen, sich den (Arbeits-)Prozess anzuschauen und direkt zu erfahren wie es läuft – und zwar von denen, die täglich in diesem Ablauf arbeiten!

Wie es sein könnte …
Gerade auch, weil mitunter neue Tools einen – zum Teil – anderen Prozess erfordern, schauen sich Mitarbeiter und Führungskräfte den Ist-Zustand des Arbeitsablaufs gemeinsam an und machen zusammen ausfindig, wo Schwachstellen und damit mögliche bzw. typische Optimierungspotentiale vorhanden sind:

  • unklare Schnittstellen / Zuständigkeiten
  • (unnötige) Tool-und System-Übergänge
  • Liege- und Warte-Zeiten
  • Engpässe im Projektablauf (unklare bzw. unzureichende Kommunikation)

Diese Zeit vor der Toolauswahl zu investieren hat gleich mehrere Vorteile:

  • Man verschafft sich Klarheit über Abläufe und kann außerdem einfache Optimierungen direkt umsetzen, erntet neudeutsch „low hanging fruits“.
  • Der zweitwichtigste Punkt: Man führt sich gemeinsam vor Augen, was man wann wie tut – eine Grund-Voraussetzung, den gewünschten Arbeitsablauf im Tool abbilden und effektiv sowie effizient in diesem Tool arbeiten zu können.
  • Und der aus meiner Sicht wichtigste Punkt: Man hat die Mitarbeiter in den Change eingebunden. Sie wurden gehört, haben mitgewirkt und (hoffentlich) auch verstanden, warum manche Dinge sich nicht umsetzen lassen (Aufwand vs. Nutzen).

Fazit
Eine Tooleinführung dauert immer eine Zeit „X“. Man kann entweder schnell einführen und dann lange für die Anpassung brauchen oder man investiert die Zeit vorher und profitiert dann von einer kürzeren Anpassung nach der Tooleinführung. Der Zielzeitpunkt der produktiven Nutzung bleibt ungefähr gleich. Was aber bei der Variante „Mitarbeiter einbinden, Prozess prüfen“ von Vorteil ist, sind die zufriedeneren Nutzer bzw. Mitarbeiter. Und hier liegt meines Erachtens der (nicht nur bzgl. ROI-Zahlen) große, aber versteckte Nutzen.

Schreibe einen Kommentar