Auf den ersten Blick wahrscheinlich nicht viel.
Der eine beschäftigt sich mit finanzieller Performance, Budgets, Forecasts und unternehmerischen Entscheidungen. Der andere entwirft Unternehmenslösungen, verbindet Systeme und trifft Technologieentscheidungen.
Doch je länger ich an der Schnittstelle von Finance, Operations und ERP-Transformation gearbeitet habe, desto stärker wurde meine Überzeugung:
Ein hervorragender Controller muss wie ein Solution Architect denken. Und ein hervorragender Solution Architect muss wie ein Controller denken.
Beide müssen die Details verstehen, ohne das große Ganze aus den Augen zu verlieren. Beide müssen Ursache und Wirkung erkennen. Beide müssen merken, wenn etwas nicht schlüssig ist. Und beide müssen immer wieder fragen: Warum?
Es gibt ein deutsches Wort, das für mich gut dazu passt: Maschinist. Beide Rollen müssen zum Maschinisten der Maschine werden. Ich erkläre, was ich damit meine.
Ich habe nicht als Solution Architect angefangen
Meine berufliche Laufbahn begann im Accounting. Danach führte mich mein Weg über Positionen als Controller, Head of Controlling, Head of Operations, Finance Director und CFO. Schließlich rückten ERP-Transformation und Solution Architecture immer stärker in den Mittelpunkt.
Auf dem Papier wirken diese Rollen sehr unterschiedlich. Rückblickend verband sie jedoch eine Sache: Ich wollte immer verstehen, wie der Prozess tatsächlich funktioniert.
Nicht nur: Wie lautet die Zahl? Sondern: Was ist im Unternehmen passiert? Welcher Prozess hat sie erzeugt? Wie unterstützt das ERP diesen Prozess? Welche Transaktion ist entstanden? Und schließlich: Welche Buchung hat das System erzeugt – und warum?
Für mich war die Zahl im Abschluss immer das Ende einer viel längeren Geschichte. Diese Geschichte wollte ich verstehen.
Ein Controller muss die Maschine hinter den Zahlen verstehen
Ein Controller erstellt nicht jeden Auftrag. Er bucht nicht jede Kreditorenrechnung. Er führt nicht jede Lagerbewegung oder jeden Produktionsauftrag aus. Und das sollte er auch nicht müssen.
Für diese Bereiche gibt es Spezialisten mit deutlich tieferem Detailwissen. Ein guter Controller muss jedoch genug verstehen, um die Zusammenhänge herzustellen.
Stellen wir uns vor, die Bruttomarge verändert sich plötzlich. Ein Controller kann berichten: „Die Bruttomarge ist um 3 % gesunken.“ Doch das ist erst der Anfang. Die entscheidende Frage lautet: Warum?
Lag es an den Preisen? Am Produktmix? An Einkaufspreisen? Produktionsabweichungen? Lagerbewertung? Stammdaten? Falschen Buchungen? Einer Integration? Einer Transformation im Reporting? Oder an etwas völlig anderem?
Der Controller muss sich rückwärts durch die Maschine bewegen können: Management Report → Daten & Reporting → Finanzergebnis → Buchung → ERP-Transaktion → Geschäftsprozess → Business Event.
Er muss nicht jede Komponente persönlich reparieren. Aber er muss genug verstehen, um zu erkennen, wo die Suche beginnen sollte.
Ein hervorragender Controller muss die Architektur hinter den Zahlen verstehen.
Der Jahresabschluss und die Blackbox
Ich erinnere mich noch gut an einen meiner ersten Jahresabschlüsse. Wir hatten Herausforderungen im Lagerbereich. Während der Prüfung wurde mir die Bestandslogik des ERP im Grunde als Blackbox beschrieben.
Transaktionen gingen hinein. Buchhalterische Ergebnisse kamen heraus. Doch genau zu verstehen, was dazwischen geschah – und warum –, war wesentlich schwieriger.
Für mich war das keine akzeptable Antwort. Wir mussten das Geschäftsjahr abschließen. Die Zahlen mussten stimmen. Und wenn ich für diese Zahlen verantwortlich war, musste ich verstehen, was das System tatsächlich getan hatte.
Also arbeitete ich mich hindurch. Tag und Nacht. Über Zeitzonen hinweg. Ich verfolgte Lagerbewegungen, verstand die Transaktionen, analysierte die ERP-Logik und folgte den Buchungen bis ins Finance. Ich verband operative Aktivitäten mit Accounting Entries. Bis wir schließlich verstanden, was geschah. Und das Jahr abschließen konnten.
Wenn ich für das Ergebnis verantwortlich bin, kann ich nicht einfach akzeptieren, dass die Maschine dahinter eine Blackbox ist.
Ich muss nicht jede Codezeile verstehen. Aber ich muss genug verstehen, um die Kette zu verbinden: Business Event → Prozess → ERP-Transaktion → Buchung → finanzielles Ergebnis. Und wenn diese Teile nicht zusammenpassen, muss ich weiterfragen, bis sie es tun.
Und ein Solution Architect muss wie ein Controller denken
Betrachten wir dieselbe Maschine aus der anderen Richtung. Ein Solution Architect beginnt vielleicht mit einem Business Need: Purchase-to-Pay neu gestalten, Inventory Management verbessern, Order-to-Cash automatisieren, ein neues Produktionsmodell einführen oder ein globales Finance-Template entwickeln.
Der Architect darf nicht bei „Technisch funktioniert es“ stehen bleiben. Er muss fragen: Welches Geschäftsergebnis wollen wir erreichen? Wie soll der Prozess funktionieren? Wer übernimmt welche Tätigkeit? Wo werden Entscheidungen getroffen? Wo sind Kontrollen erforderlich? Welches System verantwortet welchen Teil? Welche Daten entstehen? Was geschieht nachgelagert? Und im ERP-Umfeld: Welche Auswirkungen hat das auf die Buchhaltung?
Operative Prozesse haben letztlich finanzielle Konsequenzen. Einkauf erzeugt Verbindlichkeiten. Lagerbewegungen beeinflussen die Bewertung. Produktion erzeugt Kosten und Abweichungen. Vertrieb erzeugt Umsatz und Forderungen. Projekte wirken auf Kosten- und Umsatzrealisierung.
Ein Solution Architect muss weder den Accountant noch den Controller oder Finance Consultant ersetzen. Er muss jedoch genug verstehen, um zu erkennen, ob die Lösung vom Anfang bis zum Ende schlüssig ist.
Ein hervorragender Solution Architect muss das Business hinter der Architektur verstehen.
Controller ↔ Solution Architect: Zwei Perspektiven. Eine Maschine.
Der Controller beginnt vielleicht beim Ergebnis: „Warum hat sich diese Zahl verändert?“ Und arbeitet rückwärts: Power BI → Fabric → ERP → Buchung → Transaktion → Prozess → Business Event.
Der Solution Architect beginnt möglicherweise beim Business Need und arbeitet vorwärts: Business Need → Prozess → Lösung → Transaktion → Buchung → Daten → Reporting.
Der eine folgt der Maschine, um das Ergebnis zu verstehen. Der andere entwirft die Maschine, damit sie das richtige Ergebnis erzeugt. Ich glaube jedoch, dass beide sich in beide Richtungen bewegen können müssen.
Denn wenn das Ergebnis nicht plausibel ist, löst ein Architekturdiagramm allein das Problem nicht. Man muss verstehen, wie die Maschine tatsächlich läuft.
Was ich mit „Maschinist“ meine
Ich erkläre es mit einem einfachen Beispiel, das ich häufig verwende. Ich fahre Auto. Ich steige ein, starte den Motor und fahre los. Ich weiß, wie das Auto zu bedienen ist und was es tun soll. Solange alles funktioniert, muss ich nicht jedes Bauteil unter der Motorhaube verstehen.
Doch stellen wir uns vor, ich bin weit von zu Hause entfernt und plötzlich bleibt der Motor stehen. Ich sehe, dass etwas nicht stimmt. Vielleicht kann ich beschreiben, was passiert ist. Vielleicht habe ich ein ungewöhnliches Geräusch gehört oder eine Warnleuchte gesehen. Aber Autos sind nicht mein Beruf. Ich verstehe den Motor nicht wirklich. Also muss ich irgendwann jemanden rufen, der ihn versteht.
Jemanden, der die Maschine betrachtet, das Zusammenspiel ihrer Komponenten versteht, den Fehler diagnostiziert und bestimmt, was als Nächstes geschehen muss. Diese Person versteht die Maschine.
Irgendwann in meiner Laufbahn wurde mir klar: Genau diese Person wollte ich für ERP werden.
Nicht jemand, der jeden Parameter auswendig kennt. Nicht jemand, der jede Codezeile schreiben kann. Nicht der tiefste Spezialist in jedem Modul. Sondern jemand, der die Maschine gut genug versteht, um zu wissen: Wie funktioniert sie? Warum funktioniert sie so? Was geschieht, wenn wir etwas verändern? Was passiert, wenn sie nicht funktioniert? Und wo beginnen wir mit der Suche?
Das System bedienen ≠ die Maschine verstehen.
Doch die Maschine ist längst mehr als das ERP
Vor einigen Jahren hätten wir die Maschine vielleicht noch hauptsächlich als ERP-System beschrieben. Heute reicht das nicht mehr.
Ein Kundenprozess kann im CRM beginnen. Eine Freigabe oder ein Business Workflow läuft vielleicht über Power Automate. Dynamics 365 führt die Kerntransaktion aus. Eine externe Anwendung übernimmt einen weiteren Prozessschritt. Integrationen verbinden die Komponenten. Das ERP erzeugt die Buchungen. Daten fließen in Microsoft Fabric. Power BI stellt dem Management die Ergebnisse bereit. Planungslösungen nutzen diese Informationen für Forecasts und Entscheidungen. Und zunehmend analysieren AI und AI Agents Informationen, empfehlen Maßnahmen oder führen Aktivitäten entlang dieser Kette aus.
Technisch sind dies unterschiedliche Technologien, Anwendungen, Plattformen und häufig sogar unterschiedliche Teams. Aus Sicht des Business ist es jedoch eine einzige Maschine.
Das Business interessiert nicht, wo eine Anwendung endet und die nächste beginnt. Der Prozess hält nicht an, nur weil das Architekturdiagramm einen weiteren Kasten zeigt.
Der moderne Maschinist muss daher mehr als ERP verstehen. Er muss das Ökosystem darum herum begreifen – nicht jede Komponente bis in die tiefste technische Ebene, aber genug, um ihr Zusammenspiel zu verstehen.
Aus Sicht des Business ist es eine einzige Maschine.
Maschinist zu sein bedeutet nicht, alles zu wissen
Ein Solution Architect kann nicht der tiefste Experte für Finance, Supply Chain, Manufacturing, CRM, Fabric, Power BI, Integrationen, Entwicklung, Infrastruktur, Security, AI und jede weitere Technologie einer modernen Unternehmenslandschaft sein. Und ein Controller kann nicht jeden operativen Prozess besser verstehen als die Menschen, die ihn ausführen. Das sollten beide auch nicht versuchen.
Beide brauchen Spezialisten: Functional Consultants, Developer, Integration Architects, Data Engineers, Accountants, Fabric- und Power-BI-Spezialisten, Process Owner, Key User, operative Experten und AI-Spezialisten.
Einige dieser Menschen werden ihre jeweilige Komponente wesentlich besser verstehen, als es ein Controller oder Solution Architect jemals könnte. Genau so soll es sein.
Der Maschinist trägt eine andere Verantwortung: genug über die Komponenten wissen, um ihr Zusammenspiel zu verstehen; genug über das Business wissen, um zu verstehen, was die Maschine erreichen soll; und genug über das Ganze wissen, um zu erkennen, wenn etwas nicht schlüssig klingt.
Deshalb ist die Arbeit mit Menschen ein so wichtiger Teil der Solution Architecture. Man ersetzt die Spezialisten nicht. Man verbindet sie. Man hört ihnen zu. Man lernt von ihnen. Man lässt sie tief ins Detail gehen. Gleichzeitig verbindet man ihre Entscheidungen immer wieder mit dem Gesamtbild.
Du ersetzt die Spezialisten nicht. Du verbindest sie.
Denn jemand muss weiterhin fragen: Passt dieses Teil noch zur gesamten Maschine?
Anforderungen nicht nur übersetzen. Hinterfragen.
Das ist eine weitere Lektion, die ich aus dem Controlling in die Solution Architecture mitgenommen habe. Ein guter Controller akzeptiert eine Zahl nicht einfach. Er hinterfragt sie: Warum hat sie sich verändert? Ist sie plausibel? Was treibt sie?
Ein guter Solution Architect sollte mit Anforderungen genauso umgehen. „Wir brauchen diese Anpassung.“ Warum? „Wir brauchen eine weitere Integration.“ Warum? „Wir müssen diesen alten Prozess nachbauen.“ Warum?
Die Rolle des Architects besteht nicht darin, jede Anforderung einfach in Technologie zu übersetzen. Manchmal liegt der wertvollste Architekturbeitrag in der Frage: Warum tun wir das überhaupt?
Die Anforderung verstehen. Das Geschäftsproblem dahinter verstehen. Annahmen hinterfragen. Dann die Lösung entwerfen.
Auch deshalb sind die Denkweisen von Controller und Solution Architect für mich so eng miteinander verbunden. Beide brauchen Neugier. Beide brauchen gesunde Skepsis. Beide müssen Ursache und Wirkung verstehen. Und beide benötigen genug Detailverständnis, um kritisch zu hinterfragen, ohne das große Ganze aus den Augen zu verlieren.
Vielleicht habe ich deshalb Modern Finance Consulting gegründet
Ich begann im Accounting. Dann kamen Controlling, Operations, Finance Leadership, ERP-Transformation und Solution Architecture. Und schließlich gründete ich Modern Finance Consulting.
Rückblickend mögen das sehr unterschiedliche Kapitel sein. Für mich waren sie immer durch dieselbe Neugier verbunden: Was ist passiert? Warum ist es passiert? Welcher Prozess hat es erzeugt? Was hat das System getan? Was wurde gebucht? Wohin sind die Daten geflossen? Was sieht das Management am Ende? Ist das Ergebnis plausibel? Und wenn nicht: Wo beginnen wir mit der Suche?
Im Laufe der Jahre veränderte sich die Technologie. Aus der ERP-Landschaft wurde ein Ökosystem. Zum ERP kamen CRM, Power Automate, Integrationen, Microsoft Fabric, Power BI, Planungsplattformen und heute AI und Agents hinzu.
Die grundlegende Herausforderung blieb jedoch erstaunlich ähnlich: Jemand muss verstehen, wie Business, Prozesse, Zahlen und Technologie zusammenspielen.
Das ist eine der Ideen hinter Modern Finance Consulting. Nicht Finance auf der einen und Technologie auf der anderen Seite. Nicht ERP als isoliertes System. Nicht Daten und Reporting als etwas, das erst danach geschieht. Sondern eine verbundene Sicht auf Business, Finance, Prozesse, ERP, Daten, Automatisierung, AI und Menschen.
Denn aus Sicht des Business sind das keine getrennten Maschinen. Es ist eine einzige Maschine.
Der Maschinist
Ich werde vermutlich nie der Maschinist meines Autos. Wenn der Motor ausfällt, werde ich weiterhin jemanden rufen müssen. Aber ich habe schon vor langer Zeit entschieden, dass ERP für mich keine solche Blackbox sein darf.
Ich wollte den Prozess verstehen. Ich wollte das System verstehen. Ich wollte die Buchung verstehen. Und als die Technologielandschaft wuchs, wollte ich verstehen, wie ERP, Integrationen, Automatisierung, Daten und Reporting zusammenspielen. Heute gehört auch AI dazu.
Ich wollte zum Maschinisten dieser Maschine werden.
Rückblickend verbindet diese Idee einen großen Teil meines Weges – vom Accounting und Controlling über Operations, Finance Leadership und Solution Architecture bis zur Gründung von Modern Finance Consulting.
Ein hervorragender Controller muss die Architektur hinter den Zahlen verstehen. Ein hervorragender Solution Architect muss das Business hinter der Architektur verstehen. Keiner von beiden muss jede Komponente selbst bauen. Keiner kann jedes Detail kennen. Beide brauchen ausgezeichnete Spezialisten um sich. Aber beide benötigen genug Verständnis für das Ganze, um zu erkennen, wenn etwas nicht passt – und genug Neugier, um so lange nach dem Warum zu fragen, bis sie es verstehen.
Das Business verstehen. Den Prozess verstehen. Die Zahlen verstehen. Die Technologie verstehen. Die Menschen verbinden, die die Details kennen. Und dabei niemals die gesamte Maschine aus den Augen verlieren.
Denn ob man das Geschäftsjahr abschließt, Finance transformiert, ein ERP-System implementiert, eine Datenplattform aufbaut oder AI einführt:
Die Maschine muss laufen.
Lass uns das Gespräch fortsetzen
Stimmst du zu, dass Controller zunehmend Technologiearchitektur verstehen müssen – und Solution Architects zunehmend Finance und das Business?
Und in deiner Organisation: Wer ist der Maschinist der gesamten Maschine?