Digitale Arbeitsberichte für einen Elektrobetrieb statt Papier

FUR Dorian ist ein Elektrobetrieb mit mehreren Teams im Außendienst – Service, Installationen und Betreuung in den Objekten der Kunden. Die Monteure fahren mit mehreren Servicewagen zu den Aufträgen, und jeder Einsatz endet mit einem Arbeitsbericht.

Der Arbeitsbericht war ein Formular auf Papier. Nach getaner Arbeit füllte ihn jemand aus dem Team mit dem Kugelschreiber aus: zu wem sie gefahren sind, mit welchem Wagen, wer dabei war, wann sie angefangen und aufgehört haben, was verbraucht wurde. Zwei dieser Felder waren eigentlich keine Felder, sondern Listen – die Besetzung und die Materialaufstellung konnten jeweils eine halbe Seite füllen.

Die Zettel kamen ins Büro, wann sie eben kamen. Manchmal nach einer Tour, manchmal am Monatsende, als ganzer Stapel. Erst dann tippte jemand sie in die Systeme ab, mit denen der Betrieb Arbeitszeit und Material abrechnet. Das Problem war nicht das Papier selbst, sondern dass das Büro in der Zwischenzeit nicht wusste, was bei den Aufträgen passiert war.

Womit wir angefangen haben

Mit dem Formular, nicht mit Bildschirmen. Wir sind den Arbeitsbericht Feld für Feld durchgegangen und haben bei jedem gefragt, wer diese Information liest und was er danach damit macht.

Zwei Dinge kamen dabei heraus, die nicht in der Auftragsbeschreibung standen:

• Die meisten Felder sind einfache Daten, die man auswählen statt eintippen kann – Kunde, Fahrzeug, Datum. Die ganze Arbeit steckte in den zwei Listenfeldern: der Besetzung und der Materialaufstellung. Sie entschieden, ob der Bericht vor Ort entsteht oder „später ergänzt wird“.
• Das Büro brauchte kein weiteres Abrechnungssystem. Es brauchte die Daten aus dem Bericht so, dass sie sich in die Systeme übernehmen lassen, die der Betrieb schon hat.

Die zweite Beobachtung hat über den Umfang entschieden – und zwar in die entgegengesetzte Richtung, in die solche Projekte sonst gehen.

Was wir gebaut haben

Eine Oberfläche im Browser, ohne App zum Installieren. Nach dem Auftrag meldet sich der Mitarbeiter am Handy an und füllt den Bericht vor Ort aus, bevor er wieder ins Auto steigt. Der Administrator sieht ihn im selben Moment – und kann ihn freigeben, korrigieren oder mit einer Rückfrage zurückschicken.

Die Zugriffe sind über Rollen geregelt: Ein Mitarbeiter arbeitet mit seinen eigenen Berichten, der Administrator sieht den ganzen Betrieb und verwaltet Benutzer, Fahrzeuge und die Kundendatenbank. Die Anmeldung schützt ein zweiter Faktor – ein Code aus einer Authenticator-App. Es ist eine Oberfläche mit Geschäftsdaten von Kunden, die von jedem Browser auf jedem Handy aus geöffnet wird, also reichte ein Passwort allein nicht.

Kunde von Hand eingetragen oder aus der Datenbank gewählt

Das größte Risiko eines solchen Formulars ist banal: Der Mitarbeiter steht im Objekt, der Kunde ist nicht in der Datenbank, und das Formular lässt ihn nicht weiter. Dann landet der Bericht „für später“ – also am selben Ort wie früher das Papier.

Das Kundenfeld funktioniert deshalb zweigleisig. Ist die Firma schon in der Datenbank, genügen die ersten Buchstaben des Namens, um sie aus den Vorschlägen zu wählen – der Auftrag wird mit ihrem Profil verknüpft und erscheint in ihrer Historie. Ist sie es nicht, tippt der Mitarbeiter den Namen von Hand ein und fährt weiter, und das Büro legt das Profil später an. Das Formular ist nie der Grund, einen Bericht nicht auszufüllen.

CSV-Export statt Integration

Der Kunde wollte die Oberfläche nicht direkt an seine Systeme anbinden und hatte einen Grund dafür: Eine Integration kostet beide Seiten Geld und bindet für Jahre an eine bestimmte Konstellation. Man einigte sich auf einen Kompromiss – das Büro gibt die Berichte in der Oberfläche frei und exportiert sie als CSV-Datei, die genauso in die Systeme des Betriebs geht wie jeder andere Import.

Niemand hat das als Endlösung verkauft. Es ist günstiger, war sofort fertig und verbaut nichts: Entscheidet sich der Betrieb irgendwann für eine direkte Verbindung, liegen die Daten schon an einem Ort und in einem Format.

Wie die Einführung lief

Die erste funktionierende Version stand nach einer Woche, und der Kunde konnte sie sich ansehen, bevor er irgendetwas bezahlt hatte. Einen Bildschirm beurteilt man leichter als einen in Sätzen beschriebenen Umfang, besonders im Gespräch mit jemandem, der noch nie Software in Auftrag gegeben hat.

Die folgenden zwei Wochen gingen in das Zusammenführen des Ganzen und Tests an echten Aufträgen. Nach knapp drei Wochen füllten die Teams ihre Berichte in der Oberfläche aus, und das Papierformular blieb im Ordner.

Was sich nach dem Start geändert hat

Ehrlich zur Messung: Der Betrieb hat vor der Einführung keine Statistiken geführt. Einen Vergleich der Art „früher dauerte das so lange, jetzt so lange“ haben wir also nicht, und die Zahlen unter diesem Text beschreiben den Stand nach dem Start, nicht eine aus den Daten des Kunden berechnete Ersparnis.

Die Änderung, die sich nicht in einer Zahl ausdrücken lässt, ist diese: Der Arbeitsbericht ist kein Dokument mehr, das mit Verspätung ins Büro kommt. Das Büro sieht ihn noch am selben Tag und kann nach einem Detail fragen, solange sich jemand an den Auftrag erinnert – nicht drei Wochen später über einem Stapel Zettel.

Der Umfang ist unterwegs gewachsen. Als die Oberfläche live ging, stellte sich heraus, dass der Administrator darin auch Benutzer und Fahrzeuge verwalten muss – das stand nicht in den Absprachen, weil es so etwas auf einem Papierformular schlicht nicht gibt. Wir haben es ohne Aufpreis ergänzt, weil eine Oberfläche ohne eigene Verwaltung ohnehin beim ersten Wechsel im Team wieder bei uns gelandet wäre.

Die Lehre für die Zukunft: Ein Formular zeigt, was ein Mitarbeiter aufschreibt, sagt aber nichts darüber, wer das alles verwaltet. Stammdaten, Rollen und Zugriffsrechte gehören vom ersten Tag an in den Umfang, auch wenn niemand davon spricht.