When considering automation, employees and management don't always consider the state of their current processes. Everything seems under control: data exists, reports are compiled, and approvals – though manual – are being completed. Excel files are sent around, metrics are discussed on calls, and managers personally verify calculations. Everyone is used to it, perceiving it as a normal workflow.
Even when employees notice discrepancies in reports or inconsistent methodology interpretations, it doesn't raise concerns. There’s a common belief that once a system is in place, things will fall into place – simply transferring the current logic to a platform will make everything easier.
The uncomfortable truth that processes are far from streamlined, data is fragmented, and calculation rules are undocumented often goes unspoken. Neither within the team nor in discussions with contractors. The project launches essentially in a state of uncertainty, although on the surface everything appears organized: teams are formed, a project plan is developed, and a kickoff meeting has been held.
Yet there's no shared understanding of how the process should actually work. There's no comprehensive picture or established rules – just different versions of the truth in reports and hope that the system will fix everything.
Implementing a financial system doesn't solve process and data problems if these issues aren't resolved before the automation project begins. If a company lacks order, clear rules, and unified calculation approaches, the system doesn't simplify work – it scales existing chaos.
When processes aren't documented and data is fragmented, automation becomes not a tool for simplifying work but a means to rapidly propagate errors across reports, data sets, and departments. Instead of saving time and resources, the company ends up with even more manual work: constantly reconciling data, building endless mappings, and requesting one custom fix after another — just to keep the new system barely running.
Automation cannot create order where none exists. For a system to work and benefit the business, you must first establish processes, align on rules, and standardize data. Only then can these clear, manageable processes be automated.
The company was an international food products manufacturer. As a large organization with complex processes, the budget was compiled in Excel every year. This was the primary reason for initiating an implementation project. An ambitious plan was set: to automate not only finance but other key departments as well – production, marketing, and sales. The expectation was that all stakeholders would approve the budget in a unified system, eliminating endless Excel files and calls. Additionally, they wanted to not only automate annual budget collection but also configure forecasting and plan execution monitoring.
However, during the project, it became clear that within the company, there was no common understanding of what data they were actually working with. The finance department entered the project with one version of the sales plan, which they received at the start of the budgeting campaign. Meanwhile, production department employees immediately stated that their sales plan was completely different and constantly changing. These changes often didn't align with what finance recorded. The sales department had its own plan version as well. Ultimately, it turned out that each department had its own version of the same metrics.
When the discussion shifted to having all departments work within a single system, employees began openly resisting. Each was convinced their data was correct, and saw no point in reconciling it in some system. Moreover, everyone found it convenient to continue working according to familiar patterns: maintaining their own files, resolving issues by phone, and not wasting time analyzing others' figures.
The company's IT department wasn't involved in the process at all – they considered it a finance matter and didn't want to delve into data reconciliation issues between departments.
In the end, the system was implemented, but only for the finance department. They automated budget processes for internal financial use, but the overall annual budget collection process for the company remained fragmented. The sales plan continued to exist in different versions – each team had its own. Automatic reconciliation between participants wasn't achieved, nor was transparent forecasting or execution control.
Although the system partially simplified the process for financial staff, the project's main goal – reducing the labor intensity of the entire budget process and accelerating approvals – wasn't achieved. The problem that initiated everything remained unsolved.
For automation to truly work rather than create new problems, several steps must be taken before the project starts:
Record who does what, in what order, in which system, and why. If a process doesn't work on paper, automation won't help.
Standardize metrics, align methodology and reports, determine a "single source of truth" for data. Without this, automation merely transfers chaos from Excel to the system.
All departments must have identical approaches to calculating financial metrics.
Each business process and dataset must have a designated responsible party who monitors its quality, comparability, and relevance.
