Es gibt eine Version dieser Geschichte in fast jeder Finanzfunktion, die wir betreten haben. Es ist nie ein technisches Versagen. Es ist ein Übersetzungsversagen, und es passiert an einer vorhersehbaren Stelle.
Die Controllerin kennt die Regel. Fragen Sie sie, warum die Einkaufspreistoleranz bei 2 % liegt, und sie wird Ihnen sagen, dass der Stahllieferant in Tonnen fakturiert und die Baustelle in Kilo bestellt, sodass es immer eine Rundungsdifferenz gibt und 5 % echte Fehler durchgelassen haben. Sie weiß das seit vier Jahren. Es steht nirgends geschrieben.
Der Entwickler kann alles bauen. Geben Sie ihm eine Spezifikation, und er liefert pünktlich. Was er nicht wissen kann: dass eine Buchung auf das falsche Sammelkonto die Intercompany-Eliminierung im März zerstört, weil ihm nie jemand erklärt hat, was eine Eliminierung ist, und niemand auf die Idee käme, es zu erwähnen.
Also wird das Projekt abgegrenzt. Die Finanzabteilung schreibt Anforderungen in der Sprache der Buchhaltung. Die IT liest sie als Datenbewegung. Beide Seiten glauben, sich geeinigt zu haben. Sechs Wochen später gibt es eine Demo, und die Controllerin sagt den Satz, der die meisten Automatisierungsprojekte beendet:
„Das ist nicht ganz das, was ich meinte.“
Die Spezifikation ist nicht das Problem
Die übliche Reaktion ist, eine bessere Spezifikation zu schreiben. Mehr Details, mehr Freigaben, mehr Workshops. Das funktioniert selten, denn das fehlende Wissen gehört nicht zu der Art, die es übersteht, von der Person, die es hat, für die Person, die es nicht hat, aufgeschrieben zu werden.
Probieren Sie es selbst. Schreiben Sie die Regel auf, welche Lieferantenrechnungen eine Bestellung brauchen und welche nicht. Sie werden drei Zeilen schreiben. Dann fragt jemand nach den Versorgern, der jährlichen Versicherung, dem Anwalt, der nach Aktenzeichen statt nach Bestellung abrechnet, und dem einen Lieferanten, der statt einer Rechnung einen Kontoauszug schickt, weil er das seit 2011 so macht. Aus Ihren drei Zeilen werden zwei Seiten, und sie sind immer noch unvollständig, denn die eigentliche Regel steckt in einem Urteil, das die Controllerin fällt, ohne zu merken, dass sie es fällt.
Dieses Urteil ist der wertvolle Teil. Es ist auch der Teil, den eine Spezifikation nicht transportieren kann.
Was wirklich übertragen wird
Drei Dinge übertragen dieses Wissen zuverlässig, und keines davon ist ein Dokument.
Die Arbeit beobachten. Setzen Sie sich einen Vormittag neben die Person, die sie erledigt. Kein Workshop — die tatsächliche Arbeit, mit den tatsächlichen Ausnahmen. Jedes Mal, wenn sie zögert, fragen Sie warum. Das Zögern sind die Regeln.
Von der Historie ausgehen statt von der Absicht. Fragen Sie nicht, wie Rechnungen kontiert werden sollten. Sehen Sie sich an, wie die letzten zwölf dieses Lieferanten kontiert wurden. Das Hauptbuch ist ein weit ehrlicheres Protokoll der Regel als jede Beschreibung davon, auch die der Controllerin.
Parallel laufen, bevor irgendetwas Befugnisse hat. Lassen Sie die Automatisierung die Arbeit neben dem Team erledigen, auf Live-Daten, ohne etwas zu buchen. Jede Abweichung zwischen ihrem Ergebnis und dem des Teams ist eine Regel, die Sie falsch verstanden haben, aufgedeckt, solange es noch billig ist. Das ist das Wertvollste, was Sie tun können, und die meisten Projekte lassen es aus, weil es sich anfühlt, als würde man die Arbeit doppelt machen. Man macht die Arbeit doppelt. Genau darum geht es.
Die strukturelle Lösung
Alle drei sind einfacher, wenn die Person, die die Automatisierung schreibt, eine Saldenliste lesen kann. Nicht weil Chartered Accountants bessere Entwickler sind — das sind sie meist nicht —, sondern weil der Übersetzungsschritt entfällt. Es gibt kein Übergabedokument, weil es keine Übergabe gibt.
Das ist nicht die Behauptung, dass jedes Automatisierungsteam einen Chartered Accountant braucht. Es ist eine Aussage darüber, wo die Nahtstelle liegen sollte. Wenn es zwei Personen sein müssen, legen Sie die Nahtstelle dorthin, wo ein Fehler billig ist — etwa in die Integrationsschicht, nicht zwischen „wofür die Kontrolle da ist“ und „was der Code tut“.
Legen Sie die Nahtstelle an die falsche Stelle, und Sie bekommen die Demo, den Satz und die sechs Wochen.