BUSINESS TRANSFORMATION|PROJECT MANAGEMENT|FINANCE & DATA

I joined the project with an initially vague brief to "help with reporting". The initial analysis showed that systematic reporting was virtually non-existent and the use of data was minimal. Controlling had three basic SQL queries against the ERP database, followed by a cumbersome Power Query model with no coherent data logic. The output consisted of only a few basic tables for cost analysis. The setup did not provide a reliable foundation for deeper analytics or further development of reporting.

Refreshing the data also took several hours. Source data first had to be updated manually in external Excel files before being pulled into the controlling model through these intermediaries. Because some manual inputs had to be retained, removing Excel from the process entirely would not have been practical. The objective was therefore not to replace the tool at any cost, but to redesign the data flow architecture and eliminate unnecessary manual steps.

The first step was to understand the ERP system at database level: navigate dozens of tables and views, understand the meaning of their columns, the relationships between individual objects and the logic of data storage, and select the sources relevant to controlling. On this basis, I redesigned the data model to separate fact and dimension data, removed redundant and duplicate elements, and added further tables and dimensions required for new metrics.

At the same time, I changed the data flows so that the analytical file retrieved data directly from the database instead of relying on a chain of external Excel intermediary files. This was followed by automation of refresh and formatting using Power Query and Excel macros for several defined scenarios. As a result, routine manual data preparation was eliminated to an extent for which a dedicated junior resource had originally been planned.

The next step was the introduction of Power BI. Until then, the company had worked with visualizations mainly in Excel or in the web interfaces of the systems it used, with limited customization options. Reporting then gradually expanded into other areas: production received support for capacity planning, the warehouse for inventory monitoring, and procurement for analysis of order fulfilment. I built the individual solutions using Power BI Service and Power Automate so that, once deployed, they ran automatically without daily manual intervention.

The implementation also exposed several weaknesses that can fundamentally affect the relevance and success of a data project:

• Unclear purpose of reporting. The request owner often cannot clearly articulate which business decision the reporting should support, which problem it should help solve, or which specific improvement it is intended to target.
• Weak data discipline. Data in the ERP and other systems is entered without consistent rules, based on individual user judgement, or not entered at all.
• Lack of an overall data strategy. Reporting requirements arise ad hoc, without a plan for further development towards a more comprehensive data platform that would integrate data from multiple systems.
• No AI strategy. There is no plan for using artificial intelligence to further automate routine activities or to work with data that is already available.

These experiences showed that, alongside a technically sound solution, a data project also needs a clearly defined business purpose, high-quality and consistent input data, and a concept for further development, including automation and the use of artificial intelligence.

For me, the project marked a transition from financial analysis to full-fledged BI development. I put the theoretical knowledge from my Data Analytics studies at Unicorn University into practice by independently delivering the entire data product: from connecting to source data and transforming it, through designing the data and semantic model, to visualization, automation and production deployment.

I joined the ERP implementation when the project was already underway, so I had no opportunity to influence its initial phase or original setup. The challenges rooted in those early stages became apparent almost immediately.

The Business Analysis had been carried out within too narrow a scope and did not cover all the needs of future users or the way they were actually expected to work in the new system. At the same time, Change Management had not been systematically established from the outset. Users therefore had limited information, little opportunity to influence the shape of future processes, and naturally distanced themselves from a solution that represented a major change to their day-to-day work. The gaps in Business Analysis and the absence of Change Management reinforced each other: part of the resistance to the project was not simply fear of a new system, but a response to the fact that the proposed solution did not fully reflect operational needs in several areas.

In this situation, Project Management gradually turned into crisis management. The basic project discipline had to be re-established: create a clear plan, define responsibilities, introduce regular coordination between management, the implementation partner, IT and future users, and prepare testing and training so that the system could be brought safely into production within the required timeframe.

Due to limited capacity, I also took on tasks beyond pure Project Management: calculation of cost rates, employee allocation ratios, design of warehouse organization, and data support for the preparation of warehouse and other master data. This gave me direct exposure not only to Project Management, but also to the concrete process and data implications of the implementation.

Despite the challenging course of the project, the system went live on schedule. For the company, this was a major technological and process change: its first truly integrated ERP system replaced several disconnected legacy systems and, in part of production, paper-based records. The introduction of a single system itself significantly increased transparency across the production process.

Looking back, I see two areas in which the project could have created even greater value. The first was process documentation, which did not exist in the company. The introduction of the new ERP system was a suitable opportunity to review processes systematically, optimize them where appropriate, and then formalize them in policies, work procedures and user instructions. Such a framework could have served as a binding standard for process execution and control, as a basis for onboarding new colleagues, as a benchmark for the correct procedure, and as a way to preserve company know-how.

The second unrealized opportunity was to build immediately on the ERP go-live by working systematically with the newly available data and identifying ways to use it to further improve the company's operations. The project also confirmed for me that sound Business Analysis and Change Management are not supporting activities alongside an implementation, but prerequisites for its success. If operational needs are not reflected in the solution design early and sufficiently, and if the impact of change on users is not managed systematically, the consequences will eventually surface during implementation itself.

Working in a manufacturing environment gave me long-term, hands-on experience across the key areas of controlling - from OPEX and CAPEX to manufacturing accounting.

A significant part of my controlling experience was built around investment and construction projects. CAPEX controlling in this context required a solid understanding of the specific features of construction contracts. I worked with milestone-based performance and payments, retention and other security mechanisms, as well as ad hoc international financing drawn in tranches.

At the accounting level, this also involved assessing investment expenditure for capitalization into fixed assets - including distinguishing between repairs and technical improvements and verifying whether a specific item met the criteria for capitalization.

Operating expense planning may appear routine, but this is often where weaknesses in the process become visible. Budgets were prepared predominantly using a bottom-up approach, and significant inertia gradually developed in some cost centres: estimates were based more on the previous year plus a reserve than on data, contractual commitments or actual operating assumptions.

The technical side of budgeting was complicated by the way Excel files were managed. Before more centralized sharing was introduced, it was not unusual for dozens of versions such as "v1", "v2_FINAL" or "v3_maintenance_final" to circulate across the network. This increased the risk of working with outdated versions, made consolidation more difficult and extended the overall budgeting cycle. In an environment where Excel was the main available tool, I therefore systematically looked for ways to simplify the work using advanced formulas, macros and my first data models in Power Query.

I consider manufacturing accounting and production valuation to be the most complex areas of controlling. Biological manufacturing creates particular challenges because the volume and concentration of the resulting substance vary from one production cycle to another. Setting standard costs is therefore not an isolated controlling calculation, but an interdisciplinary task at the intersection of controlling, accounting, production and process engineering. It is followed by regular analysis of variances between standard and actual costs.

A separate topic was the assessment of indirect costs and their eligibility for inclusion in the valuation of manufactured inventory. Given the impact and risks associated with incorrect assessment, we worked with a consulting firm to define these costs. The approved cost items were then reflected in inventory valuation through recurring allocation cycles in SAP.

In the same manufacturing environment, I first became involved in an SAP ECC implementation as the key user for controlling. I was responsible primarily for CAPEX topics, including PS and WBS elements, OPEX budgets and forecasts, analyses and allocation cycles. I also contributed to Business Analysis and UAT testing, which gave me first-hand experience of the implementation process from the perspective of a future system user.

I later returned to the same manufacturing environment as Change Management Lead during the transition from SAP ECC to SAP S/4HANA. This time, the focus of my work was not the technical configuration of the system, but the readiness of users and the organization for change. I prepared a Change Impact Analysis that mapped the differences between current and future ways of working and helped identify specific changes, uncertainties and user concerns. These findings then formed the basis for targeted work with users to explain the changes and progressively address the uncertainties associated with them.

The analysis was followed by information campaigns, direct work with users in operations, and ongoing escalation of situations where key users showed increased uncertainty or a risk of rejecting the change. The objective was not simply to inform users, but to involve them progressively, explain how the change would affect their work, and create the conditions for them to use the new system effectively after go-live.

The transition to SAP S/4HANA was ultimately postponed by several months, partly because of the extensive documentation updates required in a regulated manufacturing environment. The system was subsequently deployed successfully. For me, this phase completed an important professional arc: from an ERP user and controller involved in implementation to a role in which I was responsible for systematically managing the impact of change on users and the organization.