BUSINESS TRANSFORMATION|PROJECT MANAGEMENT|FINANCE & DATA

Ich stieg mit der zunächst vagen Aufgabenstellung, "beim Reporting zu unterstützen", in das Projekt ein. Bereits die erste Analyse zeigte jedoch, dass systematisches Reporting praktisch nicht vorhanden war und Daten kaum genutzt wurden. Dem Controlling standen drei grundlegende SQL-Abfragen auf der ERP-Datenbank zur Verfügung, an die ein schwerfälliges Power-Query-Modell ohne schlüssige Datenlogik anschloss. Das Ergebnis beschränkte sich auf wenige Basistabellen für Kostenanalysen. Die bestehende Lösung bot keine verlässliche Grundlage für weiterführende Analysen oder den Ausbau des Reportings.

Auch die Aktualisierung dauerte mehrere Stunden. Quelldaten wurden zunächst manuell in externen Excel-Dateien aktualisiert und erst über diese Zwischenschritte in das Controlling-Modell übernommen. Da bestimmte manuelle Eingaben erhalten bleiben mussten, wäre es nicht sinnvoll gewesen, Excel vollständig aus dem Prozess zu entfernen. Ziel war daher nicht der Austausch des Werkzeugs um jeden Preis, sondern die Neugestaltung der Datenflussarchitektur und die Eliminierung unnötiger manueller Zwischenschritte.

Zunächst musste das ERP-System auf Datenbankebene verstanden werden: Dutzende Tabellen und Views einordnen, die Bedeutung ihrer Spalten, die Beziehungen zwischen den einzelnen Objekten und die Logik der Datenspeicherung nachvollziehen und die für das Controlling relevanten Quellen auswählen. Auf dieser Basis überarbeitete ich das Datenmodell so, dass Fakten- und Dimensionsdaten getrennt wurden, entfernte redundante und doppelte Elemente und ergänzte weitere Tabellen und Dimensionen, die für neue Kennzahlen benötigt wurden.

Parallel dazu änderte ich die Datenflüsse so, dass die Analysedatei die Daten direkt aus der Datenbank bezog, statt über eine Kette externer Excel-Zwischendateien. Anschließend automatisierte ich Aktualisierung und Formatierung mit Power Query und Excel-Makros für mehrere definierte Szenarien. Dadurch entfiel die routinemäßige manuelle Datenaufbereitung in einem Umfang, für den ursprünglich eine eigene Junior-Ressource vorgesehen war.

Der nächste Schritt war die Einführung von Power BI. Bis dahin arbeitete das Unternehmen bei Visualisierungen überwiegend mit Excel oder mit den Weboberflächen der eingesetzten Systeme, die nur begrenzte Anpassungsmöglichkeiten boten. Das Reporting wurde anschließend schrittweise auf weitere Bereiche ausgeweitet: Die Produktion erhielt Unterstützung für die Kapazitätsplanung, das Lager für die Bestandsüberwachung und der Einkauf für die Analyse der Bestellabwicklung. Die einzelnen Lösungen setzte ich mit Power BI Service und Power Automate so um, dass sie nach der Einführung automatisiert und ohne tägliche manuelle Betreuung liefen.

Die Umsetzung machte zugleich mehrere Schwachstellen sichtbar, die Relevanz und Erfolg eines Datenprojekts wesentlich beeinflussen können:

• Unklar definierter Zweck des Reportings. Der Anforderungssteller kann häufig nicht präzise formulieren, welche Geschäftsentscheidung das Reporting unterstützen, welches Problem es lösen oder auf welche konkrete Verbesserung es abzielen soll.
• Schwache Datendisziplin. Daten werden im ERP und in anderen Systemen ohne einheitliche Regeln, nach individuellem Ermessen der Anwender oder gar nicht erfasst.
• Fehlende übergreifende Datenstrategie. Reporting-Anforderungen entstehen ad hoc und ohne Entwicklungsplan in Richtung einer umfassenderen Datenplattform, die Daten aus mehreren Systemen zusammenführt.
• Fehlende KI-Strategie. Es gibt keinen Plan für den Einsatz künstlicher Intelligenz zur weiteren Automatisierung routinemäßiger Tätigkeiten und zur Nutzung bereits verfügbarer Daten.

Diese Erfahrungen haben gezeigt, dass ein Datenprojekt neben einer technisch funktionierenden Lösung auch einen klar definierten Business-Zweck, hochwertige und konsistente Eingangsdaten sowie ein Konzept für die weitere Entwicklung einschließlich Automatisierung und Nutzung künstlicher Intelligenz benötigt.

Für mich bedeutete das Projekt den Übergang von der Finanzanalyse zur vollwertigen BI-Entwicklung. Die theoretischen Kenntnisse aus meinem Studium der Datenanalyse an der Unicorn University konnte ich hier praktisch anwenden, indem ich das gesamte Datenprodukt eigenständig realisierte: von der Anbindung an die Quelldaten und deren Transformation über die Konzeption des Daten- und semantischen Modells bis hin zu Visualisierung, Automatisierung und Produktivsetzung.

Ich stieg in die ERP-Implementierung ein, als das Projekt bereits lief, und hatte daher keine Möglichkeit, die Anfangsphase oder die ursprüngliche Ausgestaltung zu beeinflussen. Praktisch sofort zeigten sich jedoch Probleme, deren Ursachen genau in diesen frühen Projektphasen lagen.

Die Business-Analyse war zu eng angelegt und deckte weder alle Anforderungen der zukünftigen Anwender noch die tatsächliche Arbeitsweise ab, die im neuen System vorgesehen war. Gleichzeitig war Veränderungsmanagement von Beginn an nicht systematisch etabliert. Die Anwender verfügten daher über wenig Information, hatten nur begrenzte Möglichkeiten, die zukünftigen Prozesse mitzugestalten, und entwickelten verständlicherweise Distanz zu einer Lösung, die ihren Arbeitsalltag grundlegend verändern sollte. Die Lücken in der Business-Analyse und das fehlende Veränderungsmanagement verstärkten sich gegenseitig: Ein Teil des Widerstands gegen das Projekt war nicht nur Ausdruck der Sorge vor einem neuen System, sondern eine Reaktion darauf, dass die vorgeschlagene Lösung in einzelnen Punkten die realen Anforderungen des Betriebs nicht ausreichend abbildete.

In dieser Situation ging das Projektmanagement schrittweise in Krisenmanagement über. Zunächst musste die grundlegende Projektdisziplin wiederhergestellt werden: ein verständlicher Plan, klare Verantwortlichkeiten, regelmäßige Koordination zwischen Management, Implementierungspartner, IT und zukünftigen Anwendern sowie eine strukturierte Vorbereitung von Tests und Schulungen, damit das System innerhalb des geforderten Zeitrahmens sicher in den Produktivbetrieb überführt werden konnte.

Aufgrund begrenzter Kapazitäten übernahm ich parallel auch Aufgaben außerhalb des reinen Projektmanagements: die Kalkulation von Kostensätzen, die Berechnung von Allokationsquoten für Mitarbeitende, die Konzeption der Lagerorganisation sowie Datenunterstützung bei der Vorbereitung von Lager- und weiteren Stammdaten. Dadurch hatte ich unmittelbaren Einblick nicht nur in die Projektsteuerung, sondern auch in die konkreten Prozess- und Datenauswirkungen der Implementierung.

Trotz des anspruchsvollen Projektverlaufs konnte das System zum geplanten Termin produktiv gesetzt werden. Für das Unternehmen war dies eine grundlegende technologische und prozessuale Veränderung: Das erste wirklich integrierte ERP-System ersetzte mehrere voneinander getrennte Altsysteme und in Teilen der Produktion auch papierbasierte Aufzeichnungen. Bereits die Einführung eines einheitlichen Systems erhöhte die Transparenz des Produktionsprozesses deutlich.

Rückblickend sehe ich zwei Bereiche, in denen das Projekt noch mehr Wert hätte schaffen können. Der erste war die Prozessdokumentation, die im Unternehmen nicht existierte. Die Einführung des neuen ERP-Systems bot eine geeignete Gelegenheit, Prozesse systematisch zu überprüfen, sie dort zu optimieren, wo es sinnvoll war, und sie anschließend in Richtlinien, Arbeitsanweisungen und Benutzerinstruktionen zu verankern. Ein solcher Rahmen hätte als verbindlicher Standard für Prozessausführung und -kontrolle dienen können, als Grundlage für das Onboarding neuer Mitarbeitender, als Benchmark für den korrekten Ablauf und als Instrument zur Sicherung des Unternehmens-Know-hows.

Die zweite ungenutzte Chance bestand darin, unmittelbar nach dem ERP-Go-live systematisch mit den neu verfügbaren Daten weiterzuarbeiten und Möglichkeiten zu identifizieren, sie für eine weitere Verbesserung der Unternehmensabläufe zu nutzen. Das Projekt hat mir zugleich bestätigt, dass eine fundierte Business-Analyse und Veränderungsmanagement keine unterstützenden Aktivitäten neben einer Implementierung sind, sondern Voraussetzungen für deren Erfolg. Wenn betriebliche Anforderungen nicht frühzeitig und ausreichend in die Lösungsarchitektur einfließen und die Auswirkungen der Veränderung auf die Anwender nicht systematisch bearbeitet werden, zeigen sich die Folgen früher oder später in der Umsetzung selbst.

Die Arbeit im Produktionsumfeld gab mir langjährige praktische Erfahrung in den zentralen Bereichen des Controllings - von OPEX und CAPEX bis zur Herstellkostenrechnung.

Ein wesentlicher Teil meiner Controlling-Praxis entfiel auf Investitions- und Bauprojekte. CAPEX-Controlling erforderte hier insbesondere ein Verständnis für die Besonderheiten von Bauverträgen. Ich arbeitete mit meilensteinbasierter Leistungserbringung und entsprechenden Zahlungen, Einbehalten und weiteren Sicherungsmechanismen sowie mit ad hoc strukturierten internationalen Finanzierungen, die in Tranchen abgerufen wurden.

Auf Ebene der Buchhaltung gehörte dazu auch die korrekte Beurteilung von Investitionsausgaben im Hinblick auf ihre Aktivierung im Anlagevermögen - einschließlich der Abgrenzung zwischen Reparatur bzw. Instandhaltung und aktivierungspflichtigen nachträglichen Anschaffungs- oder Herstellungskosten sowie der Prüfung, ob eine konkrete Position die Voraussetzungen für eine Aktivierung erfüllt.

Die Planung operativer Kosten kann wie eine Routinedisziplin wirken, doch gerade hier werden Schwächen im Prozess häufig sichtbar. Budgets wurden überwiegend nach dem Bottom-up-Prinzip erstellt, wodurch sich in einzelnen Kostenstellen eine erhebliche Trägheit entwickelte: Schätzungen orientierten sich eher am Vorjahr zuzüglich einer Reserve als an Daten, vertraglichen Verpflichtungen oder tatsächlichen betrieblichen Annahmen.

Die technische Seite der Budgetierung wurde zusätzlich durch den Umgang mit Excel-Dateien erschwert. Vor der Einführung zentralerer Freigabe- und Austauschmöglichkeiten war es keine Ausnahme, dass Dutzende Dateiversionen wie "v1", "v2_FINAL" oder "v3_Wartung_final" im Netzwerk kursierten. Das erhöhte das Risiko, mit veralteten Versionen zu arbeiten, erschwerte die Konsolidierung und verlängerte den gesamten Budgetzyklus. In einem Umfeld, in dem Excel das wichtigste verfügbare Werkzeug war, suchte ich daher systematisch nach Möglichkeiten, die Arbeit mit fortgeschrittenen Formeln, Makros und ersten Datenmodellen in Power Query zu vereinfachen.

Herstellkostenrechnung und Produktionsbewertung gehören für mich zu den komplexesten Bereichen des Controllings. Besondere Anforderungen stellt die biologische Produktion, in der sich Volumen und Konzentration der erzeugten Substanz von Produktionszyklus zu Produktionszyklus verändern. Die Festlegung von Standardkosten ist daher keine isolierte Controlling-Berechnung, sondern eine interdisziplinäre Aufgabe an der Schnittstelle von Controlling, Rechnungswesen, Produktion und Verfahrenstechnik. Daran schließt sich die regelmäßige Analyse der Abweichungen zwischen Standard- und Istkosten an.

Ein eigenes Thema war die Beurteilung indirekter Kosten und ihrer Eignung für die Einbeziehung in die Bewertung selbst hergestellter Vorräte. Aufgrund der Auswirkungen und Risiken einer fehlerhaften Beurteilung arbeiteten wir bei der Abgrenzung dieser Kosten mit einer Beratungsgesellschaft zusammen. Die freigegebenen Kostenpositionen wurden anschließend über regelmäßige Allokationszyklen in SAP in die Bestandsbewertung einbezogen.

Im selben Produktionsumfeld war ich erstmals auch an einer SAP-ECC-Implementierung beteiligt, damals als Key User für das Controlling. Meine Verantwortung lag insbesondere bei CAPEX-Themen einschließlich PS- und WBS-Elementen, OPEX-Budgets und Forecasts, Analysen und Allokationszyklen. Darüber hinaus wirkte ich an der Business-Analyse und an UAT-Tests mit und lernte so den Implementierungsprozess aus der Perspektive einer zukünftigen Systemanwenderin kennen.

Später kehrte ich in dasselbe Produktionsumfeld als Change Management Lead beim Übergang von SAP ECC auf SAP S/4HANA zurück. Diesmal lag der Schwerpunkt meiner Arbeit nicht auf der technischen Konfiguration des Systems, sondern auf der Vorbereitung der Anwender und der Organisation auf die Veränderung. Ich erstellte eine Change Impact Analysis, die die Unterschiede zwischen der bisherigen und der zukünftigen Arbeitsweise abbildete und half, konkrete Veränderungen, Unsicherheiten und Bedenken der Anwender zu identifizieren. Auf diesen Erkenntnissen baute anschließend die gezielte Arbeit mit den Anwendern auf, um die Veränderungen zu erklären und die damit verbundenen Unsicherheiten schrittweise abzubauen.

Auf die Analyse folgten Informationskampagnen, direkte Arbeit mit Anwendern im Betrieb sowie die laufende Eskalation von Situationen, in denen bei Schlüsselanwendern erhöhte Unsicherheit oder das Risiko einer Ablehnung der Veränderung erkennbar wurde. Ziel war es nicht, die Anwender lediglich zu informieren, sondern sie schrittweise einzubinden, die Auswirkungen der Veränderung auf ihre Arbeit zu erläutern und die Voraussetzungen dafür zu schaffen, dass sie das neue System nach dem Go-live tatsächlich nutzen konnten.

Der Übergang auf SAP S/4HANA wurde schließlich um mehrere Monate verschoben, unter anderem aufgrund der umfangreichen Anforderungen an die Aktualisierung der Dokumentation, die in einem regulierten Produktionsumfeld unverzichtbar ist. Das System wurde anschließend erfolgreich eingeführt. Für mich schloss diese Phase einen wichtigen beruflichen Bogen: von der ERP-Anwenderin und Controllerin, die an einer Implementierung mitwirkte, bis zu einer Rolle, in der ich für die systematische Bearbeitung der Auswirkungen der Veränderung auf Anwender und Organisation verantwortlich war.