The ERP migration was supposed to reduce operational costs, unify data, and connect processes. Instead of a simple transition, a year-and-a-half-long project full of customizations, surprises, and costs that no one had estimated beforehand emerged. Read about the experience from the perspective of someone who was involved in both the ERP migration and the e-shop, and later dealt with its impacts in daily operations.
Why we went for the ERP migration
The idea of consolidation itself was not wrong. The company wanted to reduce operational costs, unify data among the various divisions, and connect processes that had previously operated separately. The problem was that the differences between the various parts of the business were underestimated when selecting the ERP system. Although all three divisions sold similar goods, one focused on retail in brick-and-mortar stores, the second on e-commerce, and the third on B2B.
One company, but three different business models
The e-shop had the highest demands. It requires a high degree of automation: fast order processing, reliable communication with the warehouse, proper management of product availability, products and their components, and coordination with shipping. The newly selected system had a strong accounting background, but our business and e-commerce processes were not covered in the necessary breadth without further adjustments.
This does not mean that any ERP is generally good or bad. Each system has a different focus. The problem arises when its strengths do not align with the processes that are critical for a specific company, and the difference starts to be addressed only during the ERP implementation.
The selection was decided by the finance department
The decision on the new ERP was made by the finance department without thorough consultation with sales and other teams. From an accounting perspective, the choice might have been logical. However, the salespeople, e-commerce team, warehouses, and those responsible for purchasing had different requirements that were included in the specifications late or not at all.
This is where the source of many later surprises arose. We considered some functions to be an obvious part of the system, but in real use, it turned out that they were missing or required customization. Instead of verifying critical scenarios before signing the contract, we discovered their limits on the go.
The biggest mistake was not the migration itself. It was the belief that we would resolve the differences between the system and our processes later during the implementation.
Where gaps began to appear
One of the first examples was product boxes, that is, products composed of several stock items. We needed the system to automatically create available products after the components were stocked. If an order was canceled or changed, it should automatically cancel or disassemble the production requirement. In our setup, both steps had to be done manually, which increased labor intensity and the risk of error.
Another weak point was forecasting for the purchase of goods. The basic sales overviews were not sufficient for our needs, and some outputs were only available in PDF. Therefore, we addressed forecasting with an add-on. However, it was unable to combine all the customized data, such as product color or country of origin, so we ultimately paid for a separate report in Power BI. We obtained the information, but at the cost of another supplier, another budget, and another dependency.
Similarly complicated was covering the specifics of import and excise tax. As a large importer, we needed to work with processes related to the tax warehouse and additional acquisition costs. The new method of calculating the weighted stock price included transportation, but not all other costs, such as storage fees, labeling, or excise tax. Therefore, we continued to conduct actual item calculations in Excel.
The biggest risk: migrating ERP and the e-shop simultaneously
I was primarily involved in the part for the e-shop. At the same time, we were changing not only the ERP but also the entire webshop. There was discussion in the company about whether to launch the new system first and then the new e-shop. In the end, we implemented both simultaneously.
In hindsight, it was an extraordinarily challenging step. When a problem arose after the launch, it was not always easy to determine whether it originated in the e-shop, ERP, integration, warehouse, or in the newly established process. At the same time, it was necessary to clean and transfer items, stock levels, movements, invoices, and delivery notes. From the first analysis to the live launch, the implementation took approximately a year and a half.
Launching the implementation does not mean the end of anything.
After a year and a half, we reached a functionality that could be worked with. However, only in real operation did further significant gaps become apparent. For example, we assumed that after stocking the missing components, the system would automatically mark the pending order for picking. This seemingly small step was not part of the process and had to be addressed.
The story of batch and vintage tracking was also instructive. During the implementation, we received information that tracking could be enabled either for all warehouses or for none. Therefore, we backed away from it, even though the warehouse managed it and it was important for the e-shop. About a year later, we discovered that the settings could be different for individual warehouses. One inaccurate piece of information thus affected the process for a long time.
Such situations illustrate why a general presentation of functions is not enough. Before implementation, it is necessary to go through specific scenarios from start to finish, including exceptions: missing goods, order changes, cancellations, returns, production, product breakdown, or different warehouse settings.
The highest cost may not be the licenses, but the people
A significant item was the training of employees. It was not just a few hours of physical training. People had to adopt new processes, different logins, security measures, and work habits. After the launch, the company fell into operational paralysis, and productivity, in my estimation, dropped for two to three months.
Some employees could not withstand the pressure of change and left. We then trained new colleagues in a system that still had shortcomings and that we ourselves did not yet fully know. This type of cost often does not fit into the implementation budget, yet it can be more significant for the company than the licenses themselves.
No one has calculated the total costs of migrating the ERP: analysis, customization, integration, reports, training, productivity loss, or lost profit. Salespeople spent long months on migration instead of selling. Therefore, the project did not only cost what was on the suppliers' invoices, but also the time and opportunities that the company could not utilize elsewhere.
What I would do differently when selecting and implementing ERP
Today, I would start with a detailed process map and a list of situations without which the company cannot function. I would involve finance, sales, purchasing, production, warehouses, distribution, e-commerce, and IT in the selection of the ERP system from day one. Each department sees different risks and uses different parts of the data. Primarily, I would try to find a way to connect the existing systems in the individual divisions so that they communicate appropriately with each other and it would not be necessary to switch to one system that ultimately does not perfectly suit either side.
A realistic overall budget should also be part of the decision. In addition to licenses and implementation, it is necessary to account for data migration, integration, customization, testing, training, the work of internal people, temporary performance decline, and future maintenance. Only then can it be compared whether a complete ERP replacement is truly worthwhile.
Why consider optimizing the existing ERP first
My experience has taught me that further migration should be the last resort. If the core of the current system is stable, it is usually faster and less risky to adjust only what is truly hindering the company. This could involve workflow, reporting, user interface, automating routine tasks, or integration with other applications.
Optimizing the existing ERP preserves the familiar environment, work habits, and know-how that the company has already built. Changes can be implemented gradually, and their benefits can be measured continuously: by time savings, lower error rates, faster order processing, or reduced need for manual administration.
The existing ERP can continue to function as a stable core, and new capabilities can be added through an extension, integration, or standalone application. The company does not need to transfer all historical data again or rebuild every process from scratch. At the same time, it can maintain better control over the budget and can proceed in smaller steps with faster returns.
Conclusion: first the suitable system, then customization
From our ERP migration, I take away a simple lesson: Before a company starts another major migration, it should ask itself a more practical question: do we really need a new ERP, or do we need to make better use of the current one? If the system still reliably holds finances, data, and basic operations, targeted optimization may be a safer, cheaper, and ultimately more effective path.