Use Lean to Ease the Pain of Enterprise Software Implementations
Large scale enterprise software implementations … ERP, CRM, BI, BPM, Ware house management, transportation management, talent management, learning management ….. What do they all typically have in common?
I routinely speak with managers who have been tasked with implementing or supporting the implementation of large-scale enterprise software solutions. All raise a similar set of frustrations:
There are a LOT of options, all very different. I just dont know which is right for us
Its taking much longer than we thought to do this and negatively impacting our business
Integration and customization costs are out of control and way over budget
We have the system installed and up, but can’t get people to use it …
Were different. We just dont do things in a standard way and no system seems to be able to handle our requirements. Guess well have to build internally
Coincidence that I keep hearing the same comments? I think not. From my experience, this is absolutely the rule, not the exception. Now, the question is why does this consistently happen?
I think its simply a matter of putting the cart before the horse. So often, technology is looked at as a silver bullet to solve business problems when, in reality, the problem is one of process and not product (i.e. technology solution). Lets put this into perspective technology solutions should sit on top of good business processes and ideally enable those processes to function better, faster, and cheaper. But,what happens when you try to overlay an ill-defined or just plain bad business process with a technology solution? You guessed it experiences like those outlined above.
I think some very focused process characterization and Lean work on the front-end of system decisions and implementations could alleviate a lot of the frustration, if people would just take the time to do it. Some things to think about .
Start with top level enterprise metrics and a high level value-stream. Identify the key value adding processes, their associated owners, and the metrics those owners manage to. This will help identify critical stakeholders and to crystallize the reporting that is really required
Start breaking down those top-level processes and characterizing across all operations. Are all operations doing things the same way, measuring the same things, etc? Most likely, they are not. Where differences exist, work collaboratively to identify best practices and consolidate to a best-of-breed process.
Look for unnecessary complexity, waste and defect-producing aspects of processes. Run focused improvement teams to correct. Remove the fat and make processes as LEAN as possible BEFORE trying to systemize. Waste and complexity in processes equals increased cost for system integration and customization, GUARANTEED.
Payoff. From steps 1-3 above, a well-defined and actionable set of requirements will be derived AND prioritized. This helps with product selection AND with system integration, customization and testing. Get it right the first time … what a concept, right?
Of course these actions will take some time on the front-end, but my contention is that the time and expense of doing this process work in front of a system implementation will almost always pay for itself many times over. Sometimes we seem to for get that it’s the business processes that serve customers and produce revenue, not the technology youre trying to implement to supposedly improve those processes.
A little preparation and risk prevention now, or a lot of pain and suffering down the road? You make the call .
Feel free to contact me if you’d like to discuss. I’d love to hear your insights and ideas.