Common Mistakes in Business Process Automation. Choosing The Wrong System
Situation
A company selects a system to solve a specific class of tasks, such as automating financial planning and forecasting. The initiative is driven by the finance department, which also independently chooses the platform.
However, the finance team lacks experience in using a multi-criteria approach to evaluate systems. Their assessment focuses primarily on "functional alignment with the current methodology" and "cost." The IT department is not involved, and critical factors like scalability, performance, customization capability, integration options, and the strength of the partner ecosystem are not even considered.
As a result, the wrong platform is chosen. During implementation, serious limitations come to light – addressing them demands significant resources or proves unfeasible due to architectural constraints. For example, instead of a fast in-memory engine for recalculating complex financial model dependencies, the system uses a slow transactional approach that reads and writes data from the hard drive.
Core Issue
The core mistake lies in a lack of a structured, system-level approach to platform selection. Sometimes, it is necessary to begin not with a shortlist of systems, but with a clear definition of the platform class. A common pitfall is the attempt to use BI systems for planning and forecasting. One reason for this is the confusion between CPM and BI platforms.
This confusion is often encouraged by vendors themselves, who try to position their tools as all-in-one solutions. Marketing language full of buzzwords like "decision-making," "performance analysis," "analytics," "data exploration," and "reporting" creates a false sense of interchangeability in the minds of non-expert buyers.
While BI systems can be used for some financial planning tasks, they are not always the best choice. For a detailed comparison of system classes and their use cases, see the article "CPM and BI Platforms Insights: What’s Usually Behind The Scenes".
Consequences
High additional costs for customization: The chosen system lacks essential features for the target processes. For example, automating FP&A on a BI platform may require external modules or development of key components like data entry, audit trails, and workflows.
Performance issues: Systems not designed for large-scale real-time data recalculation may rely on slow transactional architectures. Achieving timely reporting from large financial models can become a significant challenge.
Project suspension and platform change: Sometimes the mismatch is so severe that the only solution is to restart the project on a new platform. This may occur when scalability is poor, or when system performance deteriorates at enterprise data volumes and cannot be fixed due to core architectural limits.
Case Studies
Case 1: Mistaking a BI Tool for a CPM System
A company decided to automate its financial planning and budgeting process. The CFO, impressed by the dynamic and visually appealing dashboards shown during a presentation of a popular BI solution, began to consider it as the core automation platform. The fact that some team members were already familiar with the tool and had a generally positive user experience added to the appeal. But the deciding factor was the price – significantly lower than that of specialized CPM systems.
Several demos were conducted, and the CFO, relying on the opinions of trusted deputies and swayed by the competitive pricing, was convinced that the choice was right. Licenses were purchased, a project team was formed, and implementation began.
However, it soon became clear that the system didn’t meet expectations. Manual data entry was limited, requiring integration of an alternative solution. Master data input in the interface was cumbersome, which led to a heavy reliance on external data sources. There was no robust workflow for budget approvals. The project began to stall – deadlines were pushed back, costs increased, and the system remained largely unusable.
After completing an MVP and analyzing the results, the CFO was forced to halt the project and relaunch it on a CPM platform – losing six months and a significant portion of the automation budget.
Case 2: Using an ERP Module for Planning
A large manufacturing holding had been successfully using a well-known ERP system for years – covering accounting, production, inventory, and procurement. When the need arose to automate budgeting, the company conducted little to no platform evaluation: the ERP system already included a built-in budgeting module, employees were experienced with the platform, and sufficient licenses had already been purchased.
A pilot project was launched, covering two group companies. The MVP was completed successfully: all required functional budgets were implemented, the necessary granularity was achieved, and the final reports were compiled. The company proceeded to roll out the models across the rest of the group. All entities worked in the same database – the end goal was to produce consolidated plans and forecasts for the group.
As the amount of real-time calculations increased, the financial model began to slow down. Initially, the performance issues didn’t seem critical. But by the end of the project, some full model recalculations were taking nearly 24 hours.
The root cause: although the ERP budgeting module was sufficient for small and mid-sized models, it wasn’t suitable for large-scale planning. Built on transactional logic like the rest of the ERP system, the module couldn’t load the entire model into memory for fast recalculations. It didn’t follow OLAP principles and lacked parallelization or optimization mechanisms for online computations.
Eventually, the company decided to migrate the budgeting model to a specialized CPM platform. Each shortlisted vendor was asked to deliver a prototype and perform a stress test. Having learned from experience, senior management now required solid proof that the chosen platform could handle the data volumes and computational complexity of the group model.
Problem Indicators
System requirements are not formally defined
The decision is made without examining existing business processes or developing clear functional and technical requirements for the new system. Plans for future scaling are also overlooked.
No comparative analysis of alternative solutions
The company chooses a system without conducting a thorough review of market offerings or assessing whether the platform is suited to its specific needs. Competitive tender procedures are skipped.
The main selection criterion is the system's initial cost
The decision is primarily driven by the lowest licensing cost or savings at the initial stage. Long-term expenses – such as support, enhancement, or customization to meet evolving business needs – are not considered.
No scalability plan for the system
The platform is selected to meet immediate needs, without evaluating future growth – for example, the accumulation of historical data or expansion to additional business units. Within a few years, the chosen system may no longer cope with data volumes, forcing the company to invest in a costly migration.
How to Avoid the Mistake
Thorough analysis of requirements before selecting a system
Clearly define and document your expectations for the future system. This could take the form of a detailed technical specification or, in the case of a platform selection, a checklist covering all essential evaluation criteria.
Consult with market experts
When choosing a system, it is recommended to seek advice from professionals with experience in implementing various types of platforms. They can provide an objective view of the pros and cons of each option. Reference visits to companies already using the candidate systems for similar tasks are also considered a best practice.
Compare alternative solutions
In addition to functionality and pricing, evaluate potential systems using broader criteria: performance, ease of integration, flexibility for customizations, scalability, maturity of the partner ecosystem, and the availability of specialists in the market.
Prototype key processes
Before signing a full-scale implementation contract, build a prototype with the contractor. Use a minimal viable product (MVP) to assess how well the system fits your real-world requirements.
Consider your business growth trajectory
Choose a platform that aligns with your company’s long-term plans. Make sure it can scale, support new functions, and handle increased system load over time.
Look beyond the license price — calculate Total Cost of Ownership (TCO)
When evaluating price, do not rely solely on the initial cost of licenses or a one-year subscription (especially since vendors often offer steep discounts upfront just to secure the deal). Instead, calculate the software’s total cost of ownership over 3-5 years. This should include additional licenses, version upgrades, technical support, and – for on-premise solutions – hardware costs such as servers and storage.
July 3 at 12:30 PM
Join our free webinar on "Key Considerations in Automating Financial Consolidation" to explore how to: