Nach einem Support-Anruf ist die Dokumentation das, was am ehesten liegen bleibt. Die Notizen landen auf einem Zettel, der Zettel unter der Tastatur, und am Abend weiß niemand mehr, wie lange das Gespräch gedauert hat und was genau die Ursache war. Beim nächsten Mal fängt der Nächste wieder bei null an und prüft dieselben Punkte, von denen die Hälfte schon ausgeschlossen war.
Die übliche Antwort darauf heißt Ticketsystem. Für kleine Teams ist das oft zu viel: Es kostet Geld, will gepflegt werden, verlangt eine Anmeldung und liegt meistens in der Cloud. Für zwei oder drei Leute, die nebenbei Support machen, steht der Aufwand in keinem Verhältnis.
Es geht auch anders. Dieser Artikel beschreibt einen Ablauf in vier Stationen, der ohne Server, ohne Datenbank und ohne Konto auskommt. Alles, was dabei entsteht, sind Dateien in Ordnern, die dir gehören.
Die Unterlagen
Projektordner übernehmen, für alle anderen gesperrt, aktueller Stand liegt lokal.
Die Fehlersuche
Prüfablauf Schritt für Schritt abarbeiten, jede Antwort mit Uhrzeit festgehalten.
Was übrig bleibt
Kein weiterer Schritt, sondern das Ergebnis: eine belegbare Zeit und ein dokumentierter Prüfweg.
Was am Ende herauskommen soll
Bevor es um Werkzeuge geht, lohnt die Frage, was eine gute Dokumentation überhaupt leisten muss. Drei Dinge:
- Eine belegbare Zeit. Wie lange hat der Vorgang gedauert, und ist er verrechenbar? Geschätzte Zeiten am Monatsende sind immer zu niedrig.
- Einen nachvollziehbaren Prüfweg. Was wurde geprüft, in welcher Reihenfolge, mit welchem Ergebnis? Das ist die Information, die dem Nächsten die halbe Arbeit spart.
- Wiederverwendbares Wissen. Wenn dieselbe Störung in einem halben Jahr wiederkommt, soll niemand von vorne anfangen müssen.
Der Punkt ist: Diese drei Dinge entstehen nicht hinterher. Sie entstehen während des Vorgangs oder gar nicht.
Station 1: Der Anruf
Der Timer startet mit dem Gespräch, nicht danach. Genau dafür ist MCall gebaut: Du legst einen Eintrag an, wählst die Anlage, und die Zeit läuft mit. Ein kleines Fenster bleibt im Vordergrund, damit du die laufende Zeit auch siehst, während du in einem anderen Programm arbeitest.
Der zweite Teil ist wichtiger und wird meistens vergessen: Besonderheiten des Kunden gehören an die Anlage, nicht in den Kopf. Zu jeder Anlage lässt sich ein Hinweis hinterlegen, der beim Auswählen sofort oben im Fenster erscheint. Etwa die Ticketnummer, die dieser Kunde für die Verrechnung verlangt, ein bekanntes Problem der Steuerung oder die Regel, dass der Zutritt nur mit Voranmeldung geht. Das ist genau das Wissen, das sonst nur eine Person hat und das im Urlaub fehlt.
Während das Gespräch läuft, füllst du Problemart, Beschreibung und Ursache aus. Die Felder sind vorgegeben, deshalb sehen alle Einträge gleich aus, egal wer sie geschrieben hat. Das klingt nach einer Kleinigkeit, entscheidet aber später darüber, ob man die Sammlung auswerten kann.
Station 2: Die gemeinsamen Unterlagen
Sobald mehr als eine Person an denselben Unterlagen arbeitet, entsteht ein zweites Problem: Zwei Leute öffnen denselben Ordner, beide ändern etwas, und eine der beiden Änderungen ist danach weg. Auf einem Netzlaufwerk merkt das oft tagelang niemand.
Der WorkspaceManager löst das mit einem einfachen Prinzip: Wer arbeitet, sperrt. Du übernimmst den Projektordner, arbeitest lokal auf deinem Rechner damit, und für alle anderen ist er in dieser Zeit gesperrt. Sie sehen, wer ihn bearbeitet, seit wann und von welchem Rechner aus. Am Ende gibst du ihn wieder frei, und deine Änderungen landen als neue Version im gemeinsamen Ordner.
Der Verlauf zeigt jede Übertragung mit Datum, Benutzer und Versionsnummer. Damit ist auch nachträglich klar, wer wann welchen Stand abgelegt hat. Was in diesem Ordner liegt, ist dir überlassen. Bei einer Fehlersuche sind es die Prüfabläufe, die Vorfälle und die Unterlagen, die dazugehören.
Station 3: Die Fehlersuche
Jetzt geht es an die eigentliche Arbeit, und hier trennt sich brauchbare Dokumentation von der anderen Sorte. Wer frei tippt, schreibt beim dritten Anruf weniger als beim ersten. Wer einem Ablauf folgt, dokumentiert automatisch mit.
Im MOV_Manager zeichnest du deinen Prüfweg einmal als Ablauf auf: Kästchen für die Prüfschritte, Linien für die Antworten. Bei einer Störung arbeitest du diesen Ablauf ab. Das Programm stellt die Frage, du wählst die Antwort, und es bringt dich zum nächsten sinnvollen Punkt. Du überspringst nichts und prüfst nichts doppelt. Jede Entscheidung wird mit Uhrzeit festgehalten, dazu deine Kommentare.
Drei Dinge machen den Unterschied im Alltag:
Wissen hängt am Schritt, nicht in einem Ordner. An einen Prüfschritt gehören eine Notiz, ein Foto vom Normalzustand der Baugruppe oder ein Verweis auf die passende Handbuchseite. Beim Anklicken öffnet sich die Datei direkt an der richtigen Stelle. Wer prüft, vergleicht mit dem Bild, statt aus der Erinnerung zu urteilen.
Der Ablauf wächst im Einsatz. Tritt ein Fall auf, den der Ablauf noch nicht kennt, ergänzt du ihn mitten in der Sitzung. Danach entscheidest du, ob die neue Antwort nur zu diesem Vorfall gehört oder ab sofort für alle gilt. Beides wird protokolliert. So verwässert ein Sonderfall den Standard nicht, und der Standard verliert trotzdem keine Erfahrung.
Der verwendete Stand bleibt erhalten. Zu jedem Vorfall wird der Ablauf mitgespeichert, mit dem tatsächlich gearbeitet wurde. Änderst du die Vorlage später, bleibt der alte Vorfall so, wie er abgearbeitet wurde. Genau das braucht ein Nachweis.
Station 4: Abschluss
Am Ende gibst du den Ordner wieder frei und trägst im Anrufprotokoll Ursache und Lösung nach. Die Zeit stoppt, die tatsächliche Dauer steht im Eintrag.
Was jetzt auf der Platte liegt, ist mehr als eine Notiz:
- eine Zeile im Telefonprotokoll mit Anlage, Dauer, Kategorie und der Angabe, ob der Vorgang verrechenbar ist
- ein Bericht zum Vorfall mit jedem geprüften Schritt, der Antwort, der Uhrzeit und dem Bearbeiter
- ein Prüfablauf, der um das erweitert wurde, was dieser Fall neu gebracht hat
Das Telefonprotokoll ist eine CSV-Datei, die du in Excel öffnest, filterst und auswertest. Die Berichte sind Textdateien, die sich mit jedem Editor lesen und im Volltext durchsuchen lassen. Kein Export nötig, kein Format, das an ein Programm gebunden ist.
Wann ein Ticketsystem trotzdem die bessere Wahl ist
Damit das nicht einseitig wird: Dieser Ablauf hat Grenzen.
Wenn Kunden selbst Tickets anlegen und deren Status sehen sollen, brauchst du ein Portal. Wenn Vorgänge automatisch eskalieren, Fristen überwachen oder an Rufbereitschaften verteilt werden müssen, brauchst du dafür Regeln, die ein Dateiordner nicht kennt. Und wenn zwanzig Leute gleichzeitig arbeiten, stößt eine Ordnersperre irgendwann an ihre Grenzen.
Für zwei bis fünf Leute, die Störungen aufnehmen, eingrenzen und belegen müssen, ist der Aufwand eines Ticketsystems in aller Regel höher als sein Nutzen.
Was du dafür brauchst
Windows, einen Ordner für die Daten, und wenn mehrere darauf zugreifen sollen, ein Netzlaufwerk. Keinen Server, keine Datenbank, keine Administratorrechte. Die Programme laufen lokal, deine Daten bleiben in deinen eigenen Ordnern.
Alle drei sind kostenlos und lassen sich einzeln benutzen. Wenn du nur die Zeiten belegen willst, reicht das erste. Wenn dich nur die Fehlersuche interessiert, reicht das dritte. Zusammen ergeben sie den Ablauf, den dieser Artikel beschreibt.
Weiterlesen: MCall für die Zeiterfassung am Telefon, WorkspaceManager für gemeinsame Ordner ohne Konflikte, MOV_Manager für die geführte Fehlersuche.