Enterprise transformation projects are notoriously prone to failure. Most fail one way or another, some fail spectacularly while some projects simply do not deliver on the promised business case.
Traditional transformation projects often introduce new Enterprise Resource Planning (ERP) systems such as SAP and Oracle to solve any and all business problems. These implementations almost always end up being more painful and expensive than originally planned. Does it really have to be that way?
Back in the day I wrote my master thesis about enterprise systems implementation success and have spent most of the time since implementing SAP and transforming business processes. I do not have all the answers to how to manage a successful transformation but I have some ideas. Let’s start out with a few basic questions: Why, What and How?
Why?
The first thing to consider when attempting an enterprise transformation project, be it big or small, is to ask yourself: Why? Introducing a new piece of software does in itself not justify the expenditure. The sponsor of the project must have a crystal clear picture why initiating this project will transform the business for the better.
Empire building just for the sake of expanding an executive’s area of responsibility or to show initiative is not a compelling reason to perform open heart surgery on your company.
ROI calculations and business cases are all fine and dandy but if you are not transforming the business for the right reasons you will not succeed. The Why must also be clear for all the affected parties or the change management process will end up more painful than it should be.
What?
You now know why you want to transform your business through a massive project? Fantastic! Next question: What?
What software do you want to use? ERP Giant, Small niche or custom built in-house? The answer, of course, depends on what kind of problem you want to solve and what your core strength as a business is.
Often times buying off the shelf software can solve your problem efficiently. But sometimes it is better to build your own. There is no right way but play to your strengths. It is often quicker and easier to buy then develop in-house. Especially if you lack a strong IT organization that is used to building large applications and workflows from scratch.
I’ve worked a lot with SAP FI/CO (Finance & Controlling modules) and SAP has outstanding support for global accounting requirements. It would not make any kind of sense for most global companies to develop accounting solutions in-house. This is an edge case but a clear example where buying is preferable to building from scratch.
How?
Even if you know what and why you want to transform, the how remains.
If it is an ERP system that the C-Suite want to implement, will you use a system integrator, such as Accenture or IBM, or build the competency in-house by recruiting new talent and contractors?
Building and setting up whatever system you choose is one thing but change management is almost more important than the solution you choose. Without motivated and engaged staff and end users it does not matter if you have the best software in the world. You will fail.
One approach to strongly consider in most cases is to conduct a pilot in a segment of the organization to ensure that the system works as expected and that the training scheme is sufficient. There is nothing revolutionary about pilots but allocate sufficient time to evaluate and improve prior to ramping up roll out speed. It tends to be time well spent.
It is almost impossible to predict and remedy all issues that will emerge in production. There is a reason venture capitalists want startups to ship a minimum viable product (MVP) as early as possible. Nothing beats real life experience and feedback from end users. This is true for transformations as well. Aim for a MVP, where possible.
Management Support above all
Once you know what you want to achieve and how. One important thing remains: Management Support. For big projects, support from management is critical. Top management needs to be involved and engaged. Without their support it is close to impossible to successfully complete a large transformation project.
Top management have the explicit and implicit power to enforce a change. Small changes are hard enough but fundamental transformations of processes are very hard and without the power that comes from top management involvement it is close to impossible. The CEO, CFO or COO doesn’t need to be involved daily but must back the project when required and ensure that management on all levels of the organization understand why the transformation is happening and that it is the firm belief of the CXO that this project is fundamental to the success of the company going forward.
The change curve, some will never be in the Denial, Frustration or Depression side of the curve. Top management and the transformation project must have the same idea of the general direction that the company aims towards and clearly communicate this direction to all affected parties.
Some key stakeholders will almost certainly not be convinced that the transformation is the correct way forward and will be stuck on the low performance scale of the change curve. It is up to the management to stop these individuals or teams from directly or indirectly sabotage potential ROI of the project. Clear the path so the project can deliver.
Patrik