Home > Lean, Operational Governance, Service Organizations & Operations, Software Development & IT > Use Lean to Ease the Pain of Enterprise Software Implementations

Use Lean to Ease the Pain of Enterprise Software Implementations

September 27th, 2012

Use Lean before enterprise software implementationsLarge 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 don’t know which is right for us …

  • It’s 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 …

  • We’re different. We just don’t do things in a standard way and no system seems to be able to handle our requirements. Guess we’ll 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 it’s 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). Let’s 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 you’re 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.

  1. October 24th, 2012 at 12:52 | #1

    “It’s taking much longer than we thought to do this and negatively impacting our business”

    That’s probably one of the most common complaints. When a project takes longer than expected frustrations grow, tempers flare and employees keep using the old system without bothering to learn the new. A lot of ERP initiatives fail because of the timeline.

  2. February 20th, 2013 at 22:23 | #2

    I agree. It think one of the causes is that an ERP system is often nail down processes. But the processes are unstable. As that instability is discovered, the work done up to the discovery on the ERP system is lost and the process has to be stabilized/improved. None of that was anticipated. The other solution is that the ERP system is jammed in and the process is painted over. In that case, either the people develop workarounds thus killing the hoped for productivity gains or they are forced to limp along with a process built for the system rather than the customers of the process. Anyway you look at it, you get pain and frustration.

    Systems don’t fix bad processes.

    Thanks for your comments.

    John

Comments are closed.