Automatisieren statt neu bauen: ein Rechnungslauf als Praxisfall

Ein IT-Systemhaus, ein Prozess, den jeder Dienstleister kennt: Am Monatsende werden aus geleisteten Einsätzen Rechnungen. Die Techniker tragen ihre Termine im Outlook-Kalender ein, die Abrechnung läuft über eine Liste, die Rechnungen entstehen im Faktura-System. Alles funktioniert, nur eben von Hand: Termine durchgehen, Kunden zuordnen, Positionen übertragen, Rechnung anlegen. Rund zwei Personentage, jeden Monat, seit Jahren. Der Fall ist real und anonymisiert; wir haben die erste Hälfte der Lösung gerade produktiv gesetzt, und sie läuft.

Der teuerste Satz der Branche

Wer mit so einem Prozess zu einem Software-Vertrieb geht, hört fast immer denselben Satz: Da brauchen Sie ein neues System. Ein ERP mit Servicemodul, eine Branchenlösung, ein Workflow-Tool. Der Satz ist deshalb so teuer, weil er zwei Dinge verschweigt. Erstens den wahren Preis: Lizenz ist der kleinste Posten, dahinter stehen Migration, Schulung, Datenübernahme, Doppelbetrieb und die Monate, in denen zwei Systeme parallel gepflegt werden. Zweitens das Risiko: Ein funktionierender Prozess wird durch einen unbekannten ersetzt, und das Team muss sein Verhalten ändern. Genau daran scheitern solche Projekte am häufigsten, nicht an der Software.

Die ehrliche Gegenfrage lautet: Was ist eigentlich kaputt? In diesem Fall: nichts. Kalender, Liste und Faktura-System machen ihren Job. Kaputt ist nur die Verbindung dazwischen, und die besteht aus Menschen, die Daten von A nach B übertragen. Das ist kein System-Problem. Das ist ein Brücken-Problem.

Der Brownfield-Weg: verbinden statt ersetzen

Die Lösung, die wir gebaut haben, ist bewusst unspektakulär: eine dünne Automatisierungsschicht, die die vorhandenen Werkzeuge verbindet. Der Ablauf bleibt exakt, wie das Team ihn kennt:

• Der Techniker markiert seinen Termin im Outlook-Kalender wie bisher mit einer Kategorie als abrechenbar. Das ist die einzige Handlung, und sie existierte schon vorher.
• Das Werkzeug liest die Kalender stündlich aus, berechnet die Einsatzzeit aus der Termindauer und ordnet den Kunden über den Betreff zu.
• Die Einsätze landen automatisch in der vorhandenen Abrechnungsliste, pro Kunde gruppiert, mit Datum, Tätigkeit und Einheiten.
• Am Monatsende entsteht daraus je Kunde ein Rechnungsentwurf im Faktura-System. Preise und Stundensätze bleiben dort, wo sie immer waren: im Faktura-System selbst.

Der letzte Punkt ist eine Grundsatzentscheidung, die ich jedem empfehle: Die Automatisierung dupliziert keine Geschäftslogik. Sie wählt nur aus und überträgt Menge und Text. Gäbe es Preise plötzlich an zwei Orten, hätte man sich mit der Automatisierung eine zweite Wahrheit ins Haus geholt, und zwei Wahrheiten sind der Anfang jedes Abrechnungsfehlers.

Die beste Automatisierung ist die, bei der das Team sein Verhalten nicht ändern muss. Der grüne Termin im Kalender war schon immer da. Jetzt arbeitet er mit.

Kontrolle ist kein Zusatz, sondern der Kern

Ich baue solche Werkzeuge mit der Auditor-Brille, und die stellt vor jeder Zeile Code drei Fragen: Wer entscheidet? Was passiert bei Fehlern? Und lässt sich hinterher belegen, was geschehen ist? Die Antworten stecken in vier Bausteinen, die aus einem Skript ein betriebstaugliches Werkzeug machen:

• Menschliche Freigabe: Es gibt keinen automatischen Rechnungsversand. Das Werkzeug erzeugt Entwürfe und eine Vorschau, ein Mensch prüft und gibt frei. Automatisierung beschleunigt die Vorbereitung, nicht die Verantwortung.
• Idempotenz: Jeder verarbeitete Termin wird ummarkiert. Was abgerechnet ist, kann nicht versehentlich ein zweites Mal abgerechnet werden, auch wenn der Lauf zweimal startet.
• Prüfliste statt Datenverlust: Termine, die sich keinem Kunden sicher zuordnen lassen, verschwinden nicht und werden nicht geraten. Sie landen gesammelt auf einer Prüfliste, die ein Mensch abarbeitet.
• Audit-Log und Soll-Ist-Abgleich: Jeder Lauf schreibt ein fortlaufendes, nachträglich nicht änderbares Protokoll, und die Summen aus Liste und Rechnung werden gegeneinander geprüft. Das ist gelebte GoBD, nicht Papier.

Diese vier Punkte kosten beim Bauen vielleicht ein Viertel der Zeit. Sie sind der Unterschied zwischen einem Werkzeug, dem eine Geschäftsführung ihre Fakturierung anvertrauen kann, und einem Bastelprojekt, das beim ersten Sonderfall stillsteht.

Die unsichtbaren Details, an denen es wirklich scheitert

Der Hype erzählt, solche Automatisierungen seien an einem Nachmittag zusammengeklickt. Die Wahrheit steckt in Details, die in keiner Demo vorkommen. Drei Beispiele aus genau diesem Projekt:

• Zeitzonen: Die Kalender-Schnittstelle liefert Uhrzeiten technisch korrekt, aber ohne Zeitzonen-Kennung. Die Liste interpretierte sie als Lokalzeit, und aus einem 11:30-Uhr-Einsatz wurde still ein 9:30-Uhr-Eintrag. Gefunden im Abgleich, behoben mit expliziter Normalisierung. Ohne Test wäre das monatelang falsch fakturiert worden.
• Namens-Zuordnung: Kunden heißen im Kalender-Betreff nie so sauber wie in der Stammliste. Kürzel, Zusätze, Vertragskennungen. Die Zuordnung braucht Wortgrenzen und Alias-Listen, sonst ordnet sie den falschen Kunden zu, und ein falsch zugeordneter Einsatz ist schlimmer als ein unzugeordneter.
• Ausfallsicherheit: Wenn eines von mehreren Postfächern nicht lesbar ist, darf nicht der ganze Lauf sterben. Der Fehler wird protokolliert, die übrigen Kalender laufen weiter, der fehlende wird nachgeholt.

Nichts davon ist Raketentechnik. Aber alles davon entscheidet, ob das Werkzeug am unschönen Dienstagvormittag funktioniert, wenn die Daten krumm sind. Wer Ihnen eine Automatisierung ohne solche Geschichten verkauft, hat sie noch nicht im Betrieb gesehen.

Was das kostet, und was eben nicht

Die Rechnung ist für den Mittelstand angenehm kurz. Auf der Haben-Seite: keine neuen Lizenzen, keine Migration, keine Schulung, kein Doppelbetrieb, keine Verhaltensänderung im Team. Die Automatisierungsschicht ist klein genug, um sie vollständig zu testen, und alles Fachliche liegt in einer Konfigurationsdatei statt im Code: Welches Kürzel zu welchem Artikel führt, welche Zuschlagsstufe wann gilt, all das lässt sich ändern, ohne einen Entwickler zu rufen.

Auf der Soll-Seite steht ehrliche Ingenieursarbeit: Schnittstellen einrichten, Sonderfälle verstehen, testen, dokumentieren. Das ist überschaubar gegenüber einem Systemwechsel, aber es ist nicht null. Wer die zwei Personentage pro Monat dagegen hält, rechnet die Investition in Monaten zurück, nicht in Jahren, und behält dabei die volle Hoheit über Daten, Ablauf und Werkzeug.

Wann der Neubau trotzdem richtig ist

Damit das nicht als Pauschalrezept missverstanden wird: Es gibt gute Gründe für ein neues System. Wenn der Prozess selbst kaputt ist und nicht nur die Verbindung. Wenn das Altsystem keine Schnittstellen hat und auch keine bekommen wird. Wenn zehn Prozesse gleichzeitig auf denselben veralteten Kern zeigen. Dann ist die dünne Brücke nur ein Pflaster auf einem Bruch. Die Reihenfolge der Prüfung bleibt trotzdem immer dieselbe: erst den Prozess verstehen, dann die kleinste Lösung suchen, die ihn trägt, und erst wenn die nachweislich nicht reicht, über den großen Wurf reden. Erst Prozess. Dann Werkzeug. Und ein neues System nur, wenn die Brücke nicht genügt.