ERP Transformation : Why some companies make it and others don't

In the quest to embrace the digital age an ERP implementation is central for businesses to operate digitally across all departmental operations.

With a class leading business platform like Odoo ERP offering companies the breadth of functionality that used to be just the preserve of complex, expensive and overblown traditional ERP's, there has never been a better time for companies to access this level of sophistication at an affordable Total Cost of Ownership (TCO) to progress with their transformation projects.

What are the key characteristics of companies who embark on a successful transformation project to deliver most of the benefits required to their organisation?
How mature is your organisation to embark on a program of this magnitude?

1. Project management and governance

If you are not prepared to have a dedicated project manager who has at least 20% of their working hours hived off from daily activities to manage this program, you have already fallen down at the first hurdle.

Too many times companies embarking on this initiative have a loose project structure internally to dedicate the right level of time to engaging with the implementation partner. Considering the enormity of the transformation of the companies operations this is a big oversight and makes up a huge proportion of reasons companies do not achieve the desired goals of a transformation.

The client project manager must have a close relationship with all departmental stakeholders to ensure that the requirements for the systems capabilities are in-line with the future state and assist them to deliver on their tasks in the overall project.
Reporting to the board within your organisation to track all slippages, risks and get agreement on certain decisions to be made during the project is imperative.

The workload of the project manager during this transformation is often underestimated and very few companies get this right. Your project has a greater chance of being a success if this aspect is addressed.

2. Software evaluation and internal requirements

How do you know what software to choose if you do not know what you want?
All too often some companies come out to the marketplace and decide to "wing it".
Nothing is written down internally by department in terms of the key processes you want to ensure the system has the capability to do. 

For companies that have been operating for over 5 years..trying to evolve the initial engagement conversationally without having any requirements in the form of a basic Request For Proposal (RFP) when selecting a system is a strange and risky approach and shows a certain lack of maturity within the organisation's processes.

With the advent of AI, there should be no more excuses to not be able to generate a "features list" of specific functions you want to be able to do within your organisation per department, then tweak the list to cover more specific processes that are unique to you. This at least gives you a list to go to market with and gets you thinking internally about how you will evolve.

3. Business process re-engineering and scope creep

During the initiation phase, a good lid must be kept on the project objectives so the deliverables do not become an uncontrolled "wishlist" communicated ad-hoc by members of the project. 

This tends to occur when the project direction and governance is unclear as the barn door is open to requesting a list of changes required even though aspects with the chosen solution have a clear business process to achieve the desired effect.

Business process re-engineering is often ignored in implementations and only mature companies are able to conduct this aspect correctly to find the sweet spot between their processes and procedures and the capabilities of the ERP system. 

Evolving the delivery of the system in "real time" using a build it and see approach is invariably a recipe for overruns and risks derailing the project when the business process knowledge is in the hands of a few individuals in the organisation.

The work involved within an organisation to ensure their processes and procedures are clarified and aligned in relation to how they want to onboard onto an ERP platform involves all project team members to regularly review and align core requirements during the implementation to choose the best process to adopt in the ERP and modify to align to their operations.

4. Data quality 

No system can be built without data that is a true representation of the company's records.  Commonly referred to as "Master" data.
"Garbage in garbage out" is an often used phrase within ERP implementations.

This aspect needs to be taken seriously within project implementation teams to ensure that the data conversion strategy internally which covers the lifetime of the project has been agreed and confirmed with the implementation team.

In some cases implementations can range from 4months to 2 years depending on size, complexity and external factors that add to the implementation timeline.

Data ownership and control of the validity of data implemented in the system needs to be verified at each phase of the implementation to ensure you arrive at the highest quality when the system goes live.
More time should be spent verifying data by both project teams during an implementation.

5. System training and usage

Departmental users of the system need time and training to get used to the incoming system. This aspect is often overlooked and not checked internally as it's pushed to the side as a task that can be rushed due to ongoing business as usual work.

In its most effective form, users should be creating transactions over the lifetime of the implementation in a training system and hold reviews with their teams in-house to do a combination of system adoption and process engineering so when the system goes live all users are comfortable in the solution.

The fear of impending change and the degree of process and controls it puts in the daily activities of users is always a big resistance for adhering to the new system and strong project management cascaded via the departmental heads with regular checking as to the time and transactions done by the departmental users during various phases of the ERP implementation will help to track and review which employees are onboard with the implementation.

It's one thing to be resistant to change and another to actively push back against it subtly within an implementation. The number of adoption projects that fail due to employee non compliance is staggering and should not be allowed to happen by a good governance structure.

Actively addressing just these areas in an in depth manner should push your chances of success into the 70% percentile.