How a million-dollar enterprise software implementation helped us build a simpler ERP in six months.
At one point in my career, I watched a company spend more than a million dollars implementing Oracle.
The project had been running for years.
Consultants were involved. Processes were documented. Systems were configured. Employees were trained. Money was spent.
Lots of money.
The goal was perfectly reasonable: replace the company's existing accounting and management software with a comprehensive ERP system covering the entire business.
Eventually, Oracle was implemented.
There was just one problem.
Employees now had to work in both Oracle and the old system.
Instead of simplifying their jobs, we had managed to make some of them considerably more complicated.
A rather expensive achievement.
The million-dollar transformation
This happened around 2007–2010, when I was working in a large commercial tire distribution group operating across Ukraine, Belarus and Russia.
I joined the Ukrainian business during the final stages of its Oracle implementation.
The company already used 1C, a widely adopted accounting and business management platform in the post-Soviet market.
The intention was to replace it.
Oracle would handle accounting, finance, operational processes, reporting and the rest of the business.
One company.
One system.
One source of information.
In theory, excellent.
In practice, rather less elegant.
The project required extensive work from external integrators. Eventually, the company even hired several employees from the integration team directly, partly to reduce ongoing costs and retain the necessary expertise internally.
But external consulting expenses continued.
And 1C didn't disappear.
Some processes still required it.
So employees ended up working across two systems.
Oracle had delivered useful functionality, but the original ambition of replacing the existing environment with one comprehensive platform hadn't been achieved.
Further development continued, naturally.
With Oracle, however, almost every additional improvement seemed to require considerable time, money and coordination.
Then I moved to Belarus
Later, I became involved in crisis management and business development across different parts of the holding.
One of my assignments took me to Belarus.
The Belarusian company was smaller than the Ukrainian operation, but its underlying business was very similar.
The same industry.
Similar commercial processes.
Similar operational logic.
Some functions were absent simply because the business was smaller.
And I noticed something useful.
The Belarusian company already had 1C:Enterprise 8 and an internal 1C developer.
Meanwhile, in Ukraine, we had spent years and substantial money analysing and documenting the very business processes an ERP system needed to support.
So I proposed doing the opposite of what we had done in Kyiv.
Instead of replacing 1C with Oracle, why not turn 1C into the ERP we actually needed?
The most valuable thing Oracle left us
I took the process documentation developed during the Ukrainian Oracle implementation.
And I still consider that documentation one of the most valuable results of the entire project.
The consultants had studied how the company operated.
Processes had been described.
Workflows had been analysed.
Requirements had been formalised.
Problems and dependencies had been identified.
That was enormously useful work.
But none of it was inherently dependent on Oracle.
A business process doesn't belong to the software used to implement it.
So we took those descriptions and adapted them to the smaller Belarusian operation.
I worked on the business logic, processes and requirements.
Our internal 1C programmer implemented the functionality.
We used the capabilities of 1C:Enterprise 8 to extend what had previously been primarily an accounting and management system into something considerably broader.
Sales.
Operational workflows.
Management processes.
Internal controls.
The functionality our business actually needed.
We spent approximately six months on it.
Six months later
We had a working ERP system inside 1C.
Not a second platform sitting beside the accounting system.
Not another expensive environment requiring employees to switch between applications.
One system that covered the accounting functions and the broader operational processes required by the Belarusian business.
For that company, it was a more practical solution than attempting to reproduce the Ukrainian Oracle implementation.
It was also far less expensive to develop.
Now, I should make one distinction.
This wasn't a perfectly controlled comparison between Oracle and 1C.
The Belarusian business was smaller and less complex.
And we benefited enormously from the process documentation that had already been developed at substantial expense in Ukraine.
We weren't starting from zero.
In fact, that was the entire point.
We reused the most valuable part of the previous investment without repeating the entire technological approach.
I wouldn't claim that 1C was universally better than Oracle.
For our specific situation, however, extending the existing system turned out to be the more efficient way to solve the problem.
The mistake wasn't necessarily Oracle
Looking back, I don't think the main lesson is that Oracle was too expensive or that 1C was a better product.
Enterprise software projects are rarely that simple.
The interesting question is what the company was actually trying to achieve.
We wanted better processes.
Better control.
Less duplicated work.
More reliable information.
A unified operating environment.
Those were business goals.
Oracle was one possible way to achieve them.
But somewhere along the implementation journey, the software itself had become the project.
We were spending enormous effort implementing a platform that was supposed to simplify our business, while some employees were still working in two systems.
In Belarus, we approached the problem from the other direction.
We already had an existing platform.
We already understood the processes.
We had a developer capable of extending the system.
So we built the required functionality around what the business actually needed.
No technological revolution.
Just a much more economical implementation.
What I would do differently today
If I were approaching the same problem from scratch, I would separate two tasks much more clearly.
First, understand and optimise the business processes.
Then decide which technology should support them.
Perhaps that would still be Oracle.
Perhaps another commercial ERP.
Perhaps a heavily customised existing platform.
Or perhaps a relatively small system built specifically around the company's workflows.
The correct answer depends on scale, complexity, integration requirements and long-term maintenance costs.
But I would never assume that purchasing a more sophisticated platform automatically produces a more sophisticated business.
Software doesn't solve organisational problems merely by being expensive.
And a company can spend millions digitising inefficient processes without making those processes any better.
That was the lesson I took from this experience.
We originally paid for a major ERP implementation.
The most valuable thing we got from it was a detailed understanding of how the business worked.
Once we had that, building the software we actually needed became considerably easier.
Sometimes the best part of an expensive digital transformation is the knowledge you can reuse without the expensive technology.