Over the last fifteen or so years I have consulted on, as an executive consultant, been directly responsible for, managed indirectly, or designed and architected the implementation of a number of Enterprise Resource Planning (ERP) systems from both an operational, as a COO, as well as a technology, as a CIO/CTO, view. I’ve been somewhat successful doing this type of work, so colleagues always ask me what I learned and what my secrets are to successful ERP implementations. I always tell them the secrets are all in the execution and to prove my point, I even posted a couple of blog entries on the subject over the years that detail my approach, including this most recent one https://ideasphere.com/chuckpblog/2012/01/05/so-you-want-to-diy-an-erp-project/.

The question I get most from CIO’s, CEO’s, or investors in companies considering an ERP implementation, migration, or overhaul is what are the two or three things they must do to increase their chances of a successful implementation/transition.

I am not going to repeat the info from the DIY ERP blog entry above (hopefully you read it already), but I will add a little more detail on two aspects/approaches in my toolbox that I have found to be extremely useful and I consider Critical Success Factors.

My overriding principle is that an ERP ecosystem and solution – it’s not just the ERP application – is the nervous system of a company, so extreme care must be taken to preserve its structural and functional integrity. The best way to ensure that, at the planning stages, is to create two independent views of the ERP impact, one from an IT perspective and one from the business operations perspective that will be a counter-check to each other, and merge once each is completed, to form the overall plan. The way to do that is to start two parallel programs, one with a company-wide cross-functional team that will look at the operational side of the ERP – starting with the customer and ending with cash- and one with an IT cross-functional team that will look at the systems side – also starting with CRM and ending with the Finance systems.

One of the biggest mistake ERP planners make is to assume the ERP system must be a perfect solution to all aspect of the company and support all processes. In my experience that ERP system does not exist in general; and it definitely does not exist as a single-vendor-provided application, regardless of the sales rhetoric. So the mission of the operations team is to identify, select, and map the, no more than seven to ten, core strategic processes of the company that the ERP system must make more efficient, streamline, and have the most data elements collected on and integrated in a comprehensive metrics structure. Over the years I have developed a simple process valuation approach that helps determine which process rise to the “Core” level, but most companies have at least a general idea which processes are the most critical ones. Once the processes are selected (and I have to admit it is a painful exercise to go through), the output of this mapping exercise is a cross-process interaction chart (I call it an x-chart) that shows the key elements of each sub-process an ERP system must manage, the level of details it needs to collect from those sub-processes, the users of each process and the specific ERP functionality related to that process, along with the costs/opportunities that exists from a TMR (Time, Money, Resources) perspective that an ERP system can impact. Using a SIPOC structure I have modified/expanded, this process also identifies the systems and other enablers required to make the process work. The reason for the modified SIPOC is to address the next challenge below.

Another big mistake ERP some planners make is to assume an ERP application will replace most of the existing, and many times home-grown, systems, or that it can stand alone inside an organization. So they proceed to design and plan an ERP implementation without a clear understanding of the various IT systems the company has accumulated over the years and their critical, or not, nature to the company’s operations, or the need to integrate with a core ERP platform. The result is an ERP system, rather than an ERP solution. To fix that, an IT cross-functional team, in parallel with, but independent from, the operations team must create a System Interaction Map that shows every system the company has deployed and its relationship to other systems, both from a functionality, as well as a data exchange perspective. Once that is completed, that output is bounced against the process mapping outputs to ensure all systems are accounted by both teams, gaps are identified and resolved, and hidden dependencies are discovered. Then and only then, the design, vendor selection, or upgrade team should start their work. And that’s when the real fun begins.

Of course, once the work starts, it’s still all about the execution!