Der Interviewpartner
Wouter Pool ist seit April 2024 Group CFO der svt Group, zu der auch Saverto gehört. Zuvor war er viele Jahre bei HILTI in Führungsfunktionen tätig, zuletzt als CFO Central Europe.
Die Fragen stellte Angelina Brehm, Senior Project Manager bei Horváth, während der Fachkonferenz Reporting & Konsolidierung 2026.
Herr Pool, Saverto ist für viele im Fachpublikum noch ein unbekannter Name. Was steckt hinter dem Unternehmen?
Pool: Der Name Saverto existiert erst seit einem Jahr, die Firma dahinter aber fast 60 Jahre. Wir sind einer der führenden Hersteller im passiven Brandschutz in Europa – mit dem breitesten Produktportfolio in diesem Segment. Unsere drei Produktbereiche decken dabei sehr unterschiedliche Anwendungsfelder ab: Construction schützt Gebäude baulich vor Feuerausbreitung, Industry fokussiert sich auf Fenster, Türen und Abschottungen in Industrieumgebungen, und Glazing verbindet Ästhetik mit Brandschutz, überall dort, wo Glas und Fassaden eine Rolle spielen. Forschung, Entwicklung und Produktion liegen dabei vollständig in Europa, in Deutschland, England, Frankreich und teilweise Norwegen. Insgesamt rund 900 Mitarbeiter, 200 Millionen Euro Umsatz. Wenn man die Dienstleistungsseite der Gruppe, svt Services, hinzunimmt, nochmals 900 Mitarbeiter und nochmals rund 200 Millionen Umsatz.
Warum war der Aufbau eines neuen Performance-Management-Systems notwendig?
Als ich vor zwei Jahren angefangen habe, wusste auf Gruppenebene niemand, wie viele FTE wir haben, wie viel Umsatz wir pro Tag generieren oder wie sich der Auftragseingang entwickelt. Lokal war vieles bekannt, aber zusammengefasst hat es niemand, und steuern kann man so schlicht nicht. Das war der unmittelbare Anlass.
Warum ist es zu einer solchen Situation gekommen?
Das hat alles mit der Private-Equity-Logik zu tun. Eine PE-Firma möchte in möglichst kurzer Zeit Enterprise Value generieren, und die typische Strategie dafür ist Buy and Build. Buy and Build heißt, so viele Firmen wie möglich, die ähnliche Dinge tun, in verschiedenen Geographien zusammenkaufen und daraus eine schlagkräftige Einheit formen. Was dabei häufig zurückbleibt, ist die operative Integration. Jede zugekaufte Firma wird zunächst laufen gelassen, weil schlicht keine Zeit für eine echte Integration da ist.
„Überall fand manuelles Reporting statt, überall waren Mitarbeiter händisch am Werk.“
Irgendwann hat man dann sehr viele Firmen, die alle eigenständig operieren. Und wir haben es wirklich hinbekommen, keine einzige zu kaufen, die dasselbe ERP-System hatte wie eine, die bereits im Portfolio war. Gleiches galt für BI-Systeme: Entweder war keins vorhanden, oder es war wieder ein anderes. Mehr als zehn ERP- und FI-Systeme, mehr als vier BI-Tools, und bei Datenstandards war schlicht nichts gesetzt. Jede Firma hatte ihren eigenen Kontenrahmen, eigene Buchungslogiken, nichts davon war vergleichbar.
Und was war die Folge dieser Vielfalt?
Überall fand manuelles Reporting statt, überall waren Mitarbeiter händisch am Werk. Und unser Closing lag 2024 beim übernächsten Monat. Heute sind wir innerhalb des Folgemonats bei Arbeitstag 15. Das ist noch nicht perfekt, aber wir sind klar auf dem richtigen Weg.
Sie haben sich bei Saverto bewusst gegen eine SAP-weite Harmonisierung entschieden. Wie haben Sie diese Entscheidung begründet, und haben Sie Alternativen ernsthaft durchgespielt?
Mein erster Impuls war – und das sage ich so offen, weil ich es aus früheren Stationen kannte – alles auf SAP zu heben, großer Integrationsprozess, einheitliche Stammdaten. Das haben wir für Saverto nicht gemacht, sondern auf eine Fabric-basierte Lösung gesetzt. Und ich sage bewusst „für Saverto", weil wir es auf der SVT-Seite unserer Gruppe gerade tun: Dort läuft aktuell eine vollständige SAP-S/4-HANA-Implementierung, der Rollout endet im Sommer.
Was uns bei Saverto davon abgehalten hat, war eine schlichte Realität: Wir wissen, dass wir nicht die letzte Firma gekauft haben. Es werden weitere dazukommen, und die werden wieder andere Systeme mitbringen. Die Komplexität, der Zeit- und Ressourcenaufwand und der Kostenpunkt einer SAP-Vollimplementierung in diesem Umfeld sind wirklich in einer anderen Dimension – das sind andere Welten.
Das Schöne an der Situation ist dabei: Wir fahren beide Strategien parallel, SAP auf der SVT-Seite, eine Fabric-basierte Lösung bei Saverto. Dann können wir in den nächsten zwei bis drei Jahren direkt vergleichen, wie sich die beiden Wege entwickeln. Das ist ein natürliches Experiment, das wir aktiv beobachten werden.
Welche Kriterien waren für die Wahl von Microsoft Fabric und Power BI ausschlaggebend?
Da spielen mehrere Faktoren zusammen, die ich in der Kombination für entscheidend halte. Erstens hatten wir Qlik Sense und Qlik View im Einsatz. Wir haben geprüft, ob wir dort skalieren können. Aber das Ergebnis war ernüchternd. Hinzu kam ein pragmatisches Argument: Für eine Firma unserer Größe ist der verfügbare Entwickler-Pool relevant. Und da bietet Power BI schlicht mehr Ressourcen als Qlik.
Zweitens ist Power BI in der Praxis bereits überall präsent. In fast jeder Firma gibt es jemanden, der damit arbeitet – manchmal auch ohne offizielle Erlaubnis. Diese niedrige Einstiegshürde hilft bei der Nutzerakzeptanz erheblich.
Der eigentlich entscheidende Ausschlag war aber Microsoft Fabric. Das Produkt kam genau dann auf den Markt, als wir evaluiert haben. Wir haben geprüft, wie zukunftsfähig es ist – und die Antwort war eindeutig: Fabric ist AI-ready, kombiniert die Vorteile eines modernen Data Lake und eines klassischen Data Warehouse in einer Architektur, und bietet ein flexibles Pay-as-you-go-Kostenmodell. Letzteres ist für eine Buy-and-Build-Strategie mit kontinuierlich neuen Akquisitionen wirklich essentiell.
Und dann gibt es den Alltagsaspekt: Wir haben zwar kein einheitliches ERP, aber wir haben alle Microsoft. Dashboards lassen sich direkt in PowerPoint einbetten und aktualisieren sich automatisch. Reports können per Outlook geplant und verschickt werden. Das klingt nach Details – macht aber in der täglichen Nutzung einen erheblichen Unterschied. Und als nächsten Schritt planen wir „Ask your data", eine chatbasierte KI-Analysemöglichkeit direkt auf unseren harmonisierten Daten. Das ist nur möglich, weil wir mit der Plattformwahl die Weichen dafür heute schon gestellt haben.
Das Herzstück ist die Medallion-Architektur in Fabric. Wie funktioniert das in Ihrem Kontext konkret?
Die Architektur folgt drei Schichten. Im Bronze Layer landen alle Rohdaten aus den Quellsystemen – unverändert, eins zu eins. Das gibt uns die Sicherheit und Nachvollziehbarkeit, dass die Basisdaten korrekt abgebildet sind. Im Silver Layer werden diese Daten bereinigt: verschiedene Währungen, unterschiedliche Produktkategorien, verschiedene Datumsformate – all das wird vereinheitlicht und in strukturierte Tabellen überführt. Aus dem Silver Layer entstehen dann die Data Marts im Gold Layer, die die Basis für die Power-BI-Dashboards bilden. Der große Vorteil dieser Logik: Man löst die unharmonisierte Quellsystemlogik frühzeitig ab und kann zentrale Ableitungsregeln konsequent anwenden.
Wie sieht das Reporting-Konzept in der Praxis aus?
Das Konzept folgt drei klar definierten Dashboard-Ebenen mit einem einheitlichen Look and Feel. Auf Ebene eins gibt es ein Cockpit auf Gruppenebene: rollenspezifischer Einstiegspunkt, die wichtigsten KPIs auf einen Blick. Von dort aus führt eine kaskadierte Navigation über Subject Dashboards, zum Beispiel Sales-KPIs mit Fokus auf Wachstumstreiber und Dimensionen, bis hin zu Detail-Dashboards auf der dritten Ebene, die bis auf transaktionale Einzelpostenebene heruntergehen. Alle Ebenen greifen dabei auf dieselbe Datenbasis zurück. Zentraler Einstiegspunkt für alle Nutzer ist eine SharePoint-Landing-Page, über die jeder sehen kann, auf welche Dashboards er Zugriff hat.
Warum haben Sie ausgerechnet beim Sales-Reporting angefangen?
Den Einstieg haben wir bewusst beim Sales-Reporting gesetzt. Im Baubereich ist Tagesaktualität keine Komfortfunktion, sondern eine Steuerungsnotwendigkeit. Der Umsatz, der heute nicht erfasst wird, ist morgen nicht mehr einholbar – und wer das nicht täglich im Blick hat, steuert im Rückblick statt im Vorausgriff.
Gab es Feedback, das Sie überrascht hat?
Ein Punkt hat mich in der Tat beim Rollout besonders überrascht: Wir hatten anfangs eine Vielzahl von Filteroptionen eingebaut – gut gemeint, viel Flexibilität für die Nutzer. Das Feedback war dann eindeutig: Zu viele Filter überfordern. Die Nutzer wussten nicht mehr, was sie sich eigentlich anschauen sollten. Wir haben die Filter deutlich reduziert und danach war die Akzeptanz unmittelbar besser. Die Optionen sind nach wie vor vorhanden, wenn man sie wirklich braucht, aber sie drängen sich nicht mehr in den Vordergrund.
Welche Learnings nehmen Sie mit und was würden Sie Controlling-Verantwortlichen in einer vergleichbaren Situation konkret empfehlen?
Ich beginne bewusst mit den Fehlern, die sind ja das Wertvollste.
Erstens: Unser Zeitplan war zu ambitioniert. Wir haben das erste Dashboard zwar geliefert, aber später als versprochen. Das Ergebnis: verlorenes Stakeholder-Vertrauen, das im Nachgang mehr Energie kostet, als der ambitionierte Plan je eingespart hat. Die Lektion: Lieber früh sichtbare Teilergebnisse für einzelne Bereiche zeigen, als auf das große Ganze warten.
Zweitens: Nordstern und Pragmatismus müssen in Balance stehen. Die klare strategische Richtung ist unverhandelbar, aber man muss akzeptieren, dass man mit Näherungslösungen startet und verfeinert. Das Auftragsbuch steht exemplarisch dafür.
Drittens: Stammdaten sind das eigentliche Fundament. Die Dashboards glänzen, doch der wahre Aufwand liegt darunter. Klassischer Eisberg.
Viertens: Externe Expertise bringt Geschwindigkeit, aber das Ziel muss von Anfang an sein, auf eigenen Beinen zu stehen. Ob uns das gelingt, zeigen die nächsten Monate. Die Richtung stimmt, und dass wir in einer PE-Umgebung arbeiten, in der man in kurzer Zeit sehr viel bewegen kann, ist dabei ein echter Vorteil.
Herzlichen Dank für die interessanten Einblicke in Ihr Projekt!
