Research shows a good number (some say almost 66%) of ERP transformation projects end-up as failures or do not fully meet their objectives. Obviously, there is no one known magic potion to avoid these failures however we can learn from our own and other’s experiences.
In this three-part blog series, I will try to briefly enlist some “key tips” or some points to ponder when your organization is planning or about to start an ERP transformation!
Below I will list some pillars of sort of an ERP transformation readiness framework that can help any organization plan better when it comes to their (most often) long, (sometimes) tiring endeavor of ERP transformation program(s). Most of these “framework guidance” is merely best practices or learnings coming from years of experience for implementing ERP in various industries and geographies.
So here we go:
Ownership
The question of “ownership” is the quint-essential one to ask before you embark on your ERP transformation journey. This is probably the most often “overlooked” of all the other questions listed in this blog post.
Defining ownership structure for your ERP transformation can probably be the best opportunity to make sure you get the recipe of success right which is “Teamwork” and “Team collaboration to achieve a common goal” which in this case would be successful completion of ERP implementation project to achieve specific goals for your organization. Make sure your project ownership structure is inclusive in terms of having stakeholders from various functions of your business (as appropriate) and not just a few “IT Program Managers” or “Finance Program Sponsors”.
It is your organization’s transformation towards automation of a multitude of business processes hence the ownership of the project should be reflected accordingly to maintain a good rhythm for your ERP team including subject matters experts. I know this sounds too close to a good slogan but really defining your vision by including everyone as part of the transformation is your best chance to kick-off your project with notes of determination to “complete this triumph together as a team”.
Experience shows that including multiple Executives from different business functions in your Steering committees or Project Governance structure is often useful (wherever it makes sense) no matter if their functions really have little to interface within the project.
The bottom line is “Make your ERP project ownership inclusive and not just responsibility of few individuals or some specific business functions wherever it makes sense”.
Business requirements
Time and again I have seen Business requirements getting a bad start with a big and known mistake yet it is repeated time and again i.e., “Humungous amount of un-verified assumptions”.
In order to know what exactly your business requirements are, you need systematic & detailed Requirement Discoveries and carefully planned Requirement analysis.
I have witnessed (many times) even the savviest business stakeholders who were long-time proponents of a specific ERP transformation in their organization (and yes they finally made it happen), not knowing exactly what really are business requirements for various key processes and sub-processes which are in scope.
Do not err out on not doing an exhaustive, complete, and thorough Business requirements analysis including Fit-Gap analysis. You eventually need to call out what is business-critical, required, and nice-to-have when analyzing requirements.
One last part of this analysis is also decision(s) around what business requirements make up the scope of various business releases or phases if your transformation is a phased delivery (quite common in large ERP transformation programs).
Don’t miss out on the next two parts of this multi-part blog series where we will be reviewing communication, training, and testing! If you have any questions or comments, please don’t hesitate to Contact Us and feel free to connect on LinkedIn and Twitter!