Treiberbasierte Planung automatisieren mit KI

Ein treiberbasierter Plan drückt jede Ausgangsgröße als Formel über operative Eingangsgrößen aus, sodass Umsatz Headcount mal Ramp mal Quotenerfüllung ist und keine zwölf eingetippten Zahlen. Ihn zu automatisieren heißt, diese Treiber mit den Ist-Werten zu verdrahten, sobald sie gebucht werden, den Plan neu zu rechnen, wenn ein Treiber sich bewegt, und ein Modell Werte vorschlagen und erklären zu lassen, ohne dass es die Struktur erfindet. Die Tabelle hört auf, der Plan zu sein, und wird zu einer Ansicht davon.

Die meisten Planungsmodelle sind nicht wirklich treiberbasiert, egal was der Foliensatz sagt. Sie starten im ersten Tab treiberbasiert und verkommen bis zum dritten zu fest verdrahteten Werten, weil jemand vor einem Board-Meeting eine Zahl brauchte, die aufging, und nie mehr zurückkam. Genau dieser Verfall ist das eigentliche Problem. Ein Modell, in dem die Hälfte der Zellen Formeln sind und die andere Hälfte während des Quartalsendes eingetippte Overrides, kann sich nicht selbst aktualisieren, und es übersteht keinen Backtest, weil die Kausalkette in dem Moment durchtrennt wurde, in dem der Override landete. Fragt man es, warum eine Abweichung entstand, hat es nichts zu sagen.

Ein Plan ist ein Graph aus Treibern, also speichere ihn auch so

Der erste Teil der Ingenieurarbeit hat nichts mit KI zu tun. Es geht darum, den Plan als Abhängigkeitsgraphen darzustellen statt als Raster aus Zellen. Jeder Knoten ist ein Treiber oder eine Ausgangsgröße; jede Kante ist eine Formel. Headcount speist Kapazität, Kapazität und Quotenerfüllung speisen Bookings, Bookings und Vertragskonditionen speisen Billings, Billings speisen Cash. Sobald der Plan ein Graph ist, rechnet eine Änderung an einem Treiber genau die Knoten neu, die ihm nachgelagert sind, und sonst keine.

Diese Darstellung bringt mehreres, das eine Tabelle nicht geben kann:

• Lineage von jeder Ausgangsgröße zurück zu den Treibern, die sie erzeugt haben, sodass eine markierte Zahl einen nachvollziehbaren Pfad hat statt eines Nebels verschachtelter Zellbezüge
• Point-in-time-Korrektheit, weil jeder Treiber den Wert trägt, der zu einem gegebenen Datum bekannt war, und ein Backtest den Graphen so liest, wie er damals stand
• Overrides, die explizite Knoten mit Verantwortlichem und Begründung sind, keine stillen Ersetzungen einer Formel, sodass du jede Stelle siehst, an der ein Mensch die Maschine übersteuert hat, und warum

Die Overrides sind wichtiger, als sie aussehen. Jeder reale Plan hat sie, und der ehrliche Zug ist, sie als erstklassige Objekte zu modellieren, statt so zu tun, als gäbe es sie nicht. Ein Override mit einem Namen daran ist eine Entscheidung, die du im nächsten Zyklus überprüfen kannst. Ein über eine Formel getippter Override ist eine Landmine.

Verdrahte Treiber mit Ist-Werten, dann lass den Plan neu rechnen

Eine rollierende Prognose ist nur dann rollierend, wenn Ist-Werte in sie einfließen, ohne dass ein Mensch sie neu eintippt. Die Verrohrung hier ist dieselbe Disziplin wie beim Abschluss. Eine gebuchte Hauptbuchzeile muss dem Treiber zugeordnet werden, zu dem sie gehört, und diese Zuordnung ist die Stelle, an der die meiste FP&A-Automatisierung leise bricht, weil Kontenrahmen und Treiberbaum von unterschiedlichen Leuten zu unterschiedlichen Zeiten entworfen wurden.

Wir bauen die Zuordnung als gepflegtes Artefakt mit eigenen Tests, nicht als Lookup, das jemand unter Zeitdruck bearbeitet. Jeder Treiber wird im Abschlussrhythmus gegen das Hauptbuch abgestimmt, sodass Prognose und Abschluss nie zwei Versionen des Vormonats melden. Wenn eine Änderung am Kontenrahmen landet, schlagen die Zuordnungstests laut fehl, statt ein Quartal lang Umsatz in den falschen Knoten zu leiten, bevor es jemandem auffällt.

Hier fängt ein Modell an, sich seinen Platz zu verdienen. Gegeben den Treibergraphen und saubere Ist-Werte, kann es Treiberwerte für die nächste Periode aus Historie und Saisonalität vorschlagen, Treiber markieren, die von ihrer angenommenen Bahn abgedriftet sind, und den Abweichungskommentar entwerfen. Die Regel, an der wir festhalten, lautet: die Arithmetik passiert vor der Sprache. Das Modell erhält eine zerlegte Abweichung, die von der Pipeline bereits Treibern zugeordnet ist, und seine Aufgabe ist es, zu formulieren, was die Zerlegung zeigt: welcher Treiber, wie viel der Lücke er erklärt und welcher Rest ungeklärt bleibt. Es erzählt keine Ursachen, die man ihm nicht übergeben hat. Eine flüssige Erklärung mit dem falschen Treiber darin ist schlimmer als keine Erklärung, denn jemand wird danach handeln.

Szenarien sind Änderungen am Graphen, keine neuen Tabellen

Szenarioplanung fällt aus der Graphdarstellung fast von selbst heraus, und genau das ist der Sinn, sie so zu bauen. Ein Szenario ist eine Menge von Overrides auf Treiberknoten: Einstellungsstopp in Q3, Quotenerfüllung zehn Punkte niedriger, eine Preisänderung auf einer Produktlinie. Weil der Plan deterministisch aus Treibern neu rechnet, kannst du zwanzig Szenarien als zwanzig Override-Mengen gegen ein Modell halten statt als zwanzig kopierte Dateien, die in dem Moment auseinanderdriften, in dem jemand die Basis anfasst.

• Jedes Szenario benennt die Treiber, die es ändert, und erbt alles andere von der Basis, sodass ein Fix an einer Basisformel sich auf einen Schlag auf jedes Szenario fortpflanzt, statt zwanzigmal neu angewandt zu werden
• Szenarien sind diffbar, sodass du einem Board genau zeigen kannst, welche Treiber den Downside-Fall vom Plan trennen, in Zahlen, nicht in Adjektiven
• Ein Modell kann aus einem angegebenen Schock Kandidatenszenarien erzeugen und dann gegen den Graphen geprüft werden, was gerade deshalb sicher ist, weil es Treiberwerte ändert und die strukturellen Formeln darunter nicht umschreiben kann

Der Fehlermodus, auf den man achten muss, ist das Modell, das eine strukturelle Beziehung statt eines Werts vorschlägt. Vorzuschlagen, dass die Quotenerfüllung im nächsten Quartal 82 Prozent sein sollte, ist eine Wertfrage, und die ist legitim. Vorzuschlagen, dass die Quotenerfüllung nun vom Marketing-Budget abhängt, obwohl der Graph diese Kante nie verdrahtet hat, ist eine strukturelle Behauptung, und strukturelle Behauptungen von einem Modell werden einem Menschen vorgelegt, nie automatisch angewandt. Eine falsche Kante pflanzt sich stillschweigend durch jedes Szenario und jede nachgelagerte Ausgangsgröße fort, und du findest sie drei Zyklen später, wenn die Zahlen aufgehört haben, etwas zu bedeuten.

Bau zuerst den Graphen. Verdrahte die Treiber mit abgestimmten Ist-Werten. Lass das Modell an den Rändern vorschlagen und erklären, halte die Struktur unter menschlicher Kontrolle, und der Plan aktualisiert sich mit der Realität statt in der Woche, bevor das Board zusammenkommt.