Richtige Zahl. Trotzdem sucht Ihr Team.

Warum der Weg von einer richtigen Zahl zu ihren Geschäften so lang ist, und welche Arbeit eine zusätzliche Datenschicht dafür ersetzt.

Ein Finance Data Store ist zuerst ein Layer mehr: eine eigene Datenschicht zwischen den Quellsystemen und den Berichten von Finance. Er kostet Geld, und er kostet im Tagesabschluss Zeit. Trotzdem baue ich gerade einen auf. Warum, zeigt ein Vormittag drei Stunden vor einer Sitzung des Verwaltungsrats.

Kurz nach elf steht Reto, der CFO, in der Tür von Karin, der Leiterin Finance-Architektur. Der Verwaltungsrat will um 14 Uhr wissen, woher das Ertragsplus eines Produkts im dritten Quartal kommt. «Accounting und Management Accounting zeigen dieselbe Zahl», sagt Reto. «Bevor ich erkläre, warum sie gestiegen ist, muss ich wissen, welche Geschäfte sie tragen.»

Auf Karins Bildschirm sind zwei Excel-Dateien offen, eine aus dem Accounting, eine aus dem Management Accounting. Beide hat sie gestern Abend angefordert, an beide Teams mit wortgleicher Bitte: das Ertragsplus bis zum Einzelgeschäft zeigen. In der Datei des Management Accountings sind zwei Drittel der Zeilen gefüllt, in der aus dem Accounting etwa die Hälfte.

Karin denkt: Die Zahl stimmt. Dann, leiser: Warum dauert es so lange, das zu zeigen? Marco, der das Management Accounting leitet, hat mit seinem Team die Nacht hindurch gesucht. Im Accounting sass ein zweites Team an derselben Frage. Marcos Leute haben eine Nacht hergegeben, für eine Zahl, die längst stimmt.

Warum ist der Weg von einer richtigen Zahl zu ihren Geschäften so lang? Darauf komme ich zurück. Zuerst zum Einwand, der an dieser Stelle zu Recht fällt.

Wozu eine Schicht, wenn das Hauptbuch reicht?

Wer einen Finance Data Store vorschlägt, hört den Einwand sofort, und er ist stark. Eine zusätzliche Schicht ist eine Kopie. Eine Kopie muss jemand betreiben, bezahlen und selbst wieder abstimmen. Sie verlängert den Tagesabschluss, weil sie lädt, bevor jemand aus ihr liest. Und es gibt bereits gemeinsame Grundlagen. SAP führt im Universal Journal Financial und Management Accounting auf derselben Buchungsgrundlage zusammen und nennt das «one source of the truth». Wer schneller werden will, so das Argument, entfernt Schichten, statt eine hinzuzufügen.

Ich teile den Einwand zur Hälfte. Der Layer kostet, und wer das verschweigt, verliert den CFO beim zweiten Absatz. Ob die andere Hälfte trägt, zeigt ein einzelnes Geschäft auf Karins Bildschirm.

Wo die Verbindung zum Geschäft verloren geht

Um 13:10 nimmt Karin das grösste Geschäft aus der Liste und verfolgt es in beiden Dateien zurück. Im Management Accounting trägt es einen Produktschlüssel und eine Kundennummer. Im Accounting trägt es eine Belegnummer aus dem Hauptbuch. Die Referenz auf die ursprüngliche Transaktion im Kernbankensystem fehlt in beiden Dateien. Beide Teams haben in der Nacht dieselbe Verbindung von Hand wiederhergestellt, über Betrag, Datum und Kunde. Es war zweimal dieselbe Arbeit, an zwei Tischen, für dieselbe Zahl.

Den Grund sieht Karin in der Struktur. Eine Transaktion gelangt über mehrere Wege in die Berichte. Nach der Tagesendverarbeitung landet sie im Journal, daneben in einem Subledger, einem Nebenbuch. Von dort ziehen Extrakte sie für Management Accounting, Legal Reporting und Risiko heraus. Die Wege übernehmen, was sie für ihre Rechnung brauchen. Die Referenz auf die Transaktion gehört nicht in allen Wegen dazu.

Für 14 Uhr schlägt Karin eine Sofortmassnahme vor: «Zeig die grössten Geschäfte, die beide Dateien schon belegen. Und sag offen, was noch fehlt und warum.» Reto zeigt dem Verwaltungsrat diese Geschäfte und benennt die Lücke. Warum das Plus entstanden ist, erklärt er in der nächsten Sitzung.

Die Zahl stimmte. Gefehlt hat die Verbindung zur Transaktion, und zwei Teams haben sie nachts neu gebaut.

Welche Nachtarbeit der Store ersetzt

Hier liegt die Antwort auf den Einwand, und sie hat eine Bedingung. Ein Store hilft nicht, weil er eine weitere Kopie ist. Er hilft, wenn er die Verbindung zwischen Transaktion, Buchung und Bericht einmal herstellt und festhält. Business Events, also die fachlichen Ereignisse hinter einer Buchung, Journal und Subledger bleiben dabei verschiedene Ursprünge. Der Store übernimmt sie mit ihren Referenzen und hält fest, welche Buchung zu welcher Transaktion gehört. Accounting, Legal Reporting und Management Accounting lesen danach aus denselben Rohdaten und derselben Zuordnung.

Die Arbeit, die er ersetzt, ist die Rekonstruktion derselben Verbindung an mehreren Tischen und die laufende Prüfung, ob die Extrakte zueinander passen. Was er neu verlangt, gehört in dieselbe Rechnung: Ladezeit im Tagesabschluss, Betrieb und eine Person, die für die Zuordnung geradesteht.

Für Banken gibt es dazu einen regulatorischen Rahmen. BCBS 239 sind die Grundsätze des Basler Ausschusses für Bankenaufsicht zu Risikodaten. Grundsatz 3 verlangt seit 2013: «Risk data should be reconciled with bank’s sources, including accounting data where appropriate, to ensure that the risk data is accurate.» Eine Architektur schreibt der Grundsatz nicht vor. Meine Schlussfolgerung daraus: Ein Abgleich mit der Quelle gelingt leichter, wenn die Verbindung zur Quelle unterwegs erhalten bleibt.

Wer die Verbindung zum Geschäft einmal festhält, sucht sie nicht Nacht für Nacht neu.

Mein Feld heisst Decision-to-Execution: die Strecke vom Entscheid zur Wirkung. Retos wichtigerer Entscheid kommt nach der Sitzung. Er muss festlegen, ob das Produkt im nächsten Jahr mehr Vertrieb und mehr Budget bekommt. Diesen Entscheid kann er erst fundiert treffen, wenn er weiss, welche Geschäfte das Plus tragen und warum.

Drei Wirkungen, die ich erwarte, nicht verspreche

Ich arbeite gerade an einem Finance Data Store. Deshalb nenne ich drei weitere Wirkungen als Erwartung, nicht als Ergebnis.

Erstens kommt das Neue an. Wer heute ein neues Kernbankensystem einführt, sollte es nicht in die alten Strukturen mappen. Es ist mehr als das Bisherige in neuer Technologie und liefert Ereignisse und Merkmale, die das alte Raster nicht kannte. Wer sie dort hineinzwängt, bekommt neue Technik mit den alten Grenzen. Im Store kommen sie als Business Events an, und die Fachbereiche entscheiden, was sie daraus machen.

Zweitens schützt der Store die Domänen ringsum. Finance ist nicht mehr so statisch wie vor dreissig Jahren. Produkte, Regeln und Systeme ändern sich laufend. Ohne eine Stelle in der Mitte trifft eine Änderung im Kernbankensystem auf direktem Weg die Berichte im Accounting, im Legal Reporting und im Management Accounting. Mit dem Store landet sie zuerst dort. Er ist eine von mehreren Stellen, die schützen, und eine, die ein Haus bewusst bauen kann.

Drittens gewinnt Finance Zeit am Tag. Bisher lief die Verarbeitung überwiegend am Tagesende, und mit ihr die Abstimmung und die Fehlersuche. Manche Daten lassen sich erst nach der Tagesendverarbeitung verwenden. Andere liegen schon über den Tag vor. Liegen sie an einem Ort, können die Fachbereiche früh prüfen, etwa ob die Transaktionen des Vormittags vollständig angekommen sind. Ein Fehler, der am Nachmittag auffällt, wartet nicht bis zum Morgen danach.

Ohne Zielbild wird der Store zur Kopie

Naheliegend wäre ein Gegenfall: Ein Haus, in dem die Referenz auf die Transaktion bis in die Berichte erhalten bleibt und die Abstimmung zwischen all den Extrakten zuverlässig läuft, brauche keinen Store. Das teile ich nicht. Auch dort muss jemand laufend sicherstellen, dass die verschiedenen Extrakte zueinander konsistent sind. Intuitiv hält man das für gegeben. Selbstverständlich ist es nicht, und die Arbeit dafür wächst mit der Zahl der Extrakte.

Ein Store kommt nicht im Big Bang. Die alten Wege laufen eine Zeit lang neben ihm weiter, und das ist richtig so. Entscheidend ist, dass das Zielbild klar ist und sich die Wege in diese Richtung entwickeln, Bericht für Bericht, bis die alten Extrakte nicht mehr gebraucht werden. Der Store lohnt sich nicht, wenn dieses Zielbild fehlt. Dann bleiben die alten Wege auf Dauer, zu ihnen kommt ein weiterer, und Rekonstruktion und Konsistenzprüfung bleiben ebenfalls. Er lohnt sich auch nicht, wenn niemand für die Zuordnung geradesteht. Dann ist er tatsächlich eine Kopie mehr. Die Frage für den Entscheid lautet: Welche wiederkehrende Arbeit entfällt, welcher Betrieb kommt hinzu, und wann endet welcher alte Weg?

Im nächsten Teil der Serie auf databricks.now zeige ich, wie der Store selbst prüft: welche Prüfung nach fester Regel läuft, wo ein Agent erklärt und wo ein Mensch freigibt.

Die Zeile, die Karin um halb vier schreibt

Um halb vier sitzt Karin wieder vor den beiden Dateien. Sie schliesst sie und öffnet die Liste der Anforderungen für den Store. Oben ergänzt sie eine Zeile: Die Referenz auf die Transaktion bleibt bis in die Berichte erhalten. Dann schreibt sie Marco, sein Team solle heute früher gehen. Ob die Zeile trägt, zeigt das nächste Quartal.

Lassen Sie sich fünf Geschäfte zeigen

Nehmen Sie eine Kennzahl, die in zwei Berichten Ihres Hauses vorkommt. Bitten Sie beide Teams, die fünf grössten Geschäfte dahinter zu zeigen, und notieren Sie, wie lange das dauert. Fragen Sie, an welcher Stelle jemand eine Zuordnung von Hand herstellt. Schreiben Sie mir diese Stelle.

Wenn Sie diese Lücke an einer konkreten Kennzahl Ihres Hauses klären möchten, starten Sie mit dem Clarity Audit. Wir schauen gemeinsam auf die Frage, die Datenbasis und die Verantwortung für den nächsten Schritt.