I still get pulled into conversations about ERP; there are plenty of businesses out there, of varying sizes, that can benefit from the structured process and transactional discipline. Reference calls on behalf of the vendor are great – I’m happy to take them, primarily because most vendors are OK with letting my team be frank. We’ll talk about the software package you are buying, in whatever detail that can fit into the allotted time, warts and all.
But more often than not, I find the conversation veers away from the software, and gets into general Lessons Learned about ERP implementations. If you knew then what you know now [about System X], how would do things differently? The classic Lessons from most projects are the same, and modern ERP packages are typically not the root cause of most problems.
My top three “things to watch out for”:
- Data Quality (with specific focus on the Item Master): If you are going to rely on the ERP for material planning, accurate costing, and/or supply chain optimization, you need accurate, consistent, and complete data. The system often takes the blame here for being “difficult”, but typically the as-is business processes are not rigorous enough, not driven by data. This should be no surprise – that’s why we’re implementing this new system! It is the culture shock of transactional discipline that is “difficult”. Best advice: start early, with the most complicated stuff, and plan for a lot of iterations. But don’t assume you’ll get 100% accuracy on go-live – especially when you are coming from a less-than-perfect source.
- Standard Work (delivered with the New System) vs. As-Is Processes: The two extremes are Customize Nothing (I’m buying a set of Best Practices), and Customize Everything (our current methods are our unique value proposition to the Customer). It’s impractical to think that you can’t customize anything – but that should not give you carte blanche to make the new system mirror the old, screen for screen. The best approach is to inventory what the organization feels are your Critical Processes, and come up with Five Critical Processes (give or take) that truly differentiate, that are required for critical customers, that will cause your sales or manufacturing process to grind to a halt if not delivered. These Critical Processes should be the extent of your customization – every thing else should be “standard product” (as delivered with the new system).
Note: Most folks already know exactly what the one or two Critical Process are for their business – you don’t really have to inventory everything. The trick is to ask your vendor exactly how these Critical Processes would be set up in the new system – and have them demonstrate on the screen how it will work! It’s a key bit of Requirements Analysis that could prevent a bad purchase decision.
- What is the Definition of Success? The answer to this simple question is more impactful then you may think. Are we going to fixate on Time and Budget (hit the target go-live date no matter what)? Will it be Requirements focused (we will not go live until all development / customization is complete)? Or, are you going to fixate on Quality – as in our customer base must not be impacted by the switch (aka there will be zero customer-facing issues). It’s quite difficult to deliver on Time, Budget, and Requirements (the old Iron Triangle) – something always has to give. Therefore, you have to define what Success Metric will “break the tie” – and define this early in the process. The project team should be able to call out the single overriding decision factor (“Rule #1 – Zero Customer Impact“) and overcommunicate that Success Metric through the life of the project.
Of course, I could also talk about managing change, communication, and project management rigor – but those are common to any major project. For ERP, I think Data Quality, Scope, and Success Metrics are the big ones.
(You know, I rarely find out if the caller makes the big purchase … hmm .. was it something I said?)
This Post Has 0 Comments