Two of the services we offer are, on the surface, very different: JD Edwards (JDE) implementation and support, and Lean-based Continuous Improvement programs.
Recently, though, we had occasion to apply the principles of Lean to how we were dealing with a JDE customer. This customer, to whom we provide Managed Services (aka Support) for their JDE Grower and Grower Contracts modules, is planning a fairly large JDE upgrade, getting up to date on ESUs (aka bugs and enhancements) and tools (aka infrastructure). The customer asked how Azmera should be involved in the Grower component of the upgrade.
Based on prior experience of upgrades gone badly, our consultant replied describing the various activities and deliverables that he felt were best practice in an upgrade like this. This included opportunities to leverage new functionality. He did add a note that these activities didn’t necessarily correspond to hours or cost and that he wasn’t trying to upsell. They should all be included in the upgrade plan though. The customer responded expressing surprise, perhaps doubt and certainly some resistance, at the extent of activities recommended.
We realized that what we felt were the important and valuable steps in the upgrade, weren’t necessarily what the client valued. This is when we applied our Lean know-how: one of the key principles of Lean is understanding Customer Value. Once understood, you eliminate or reduce anything that the customer doesn’t value. Apart from what the customer values, the only steps/costs/resources that should be included are those required due to regulation, safety, or to be able to fulfil the process. Those that are required but not valued should be reduced as much as possible.
We reviewed the correspondence and determined that what the client valued most was “keeping the lights on” after the upgrade. Anything beyond that, such as new functionality or process improvements, was “nice to have” and perhaps could be looked at later. Eliminating these components of the recommendation was easy, as they weren’t a required part of the upgrade.
Trickier were components that we felt were best practice and more likely to provide a more robust and risk-reduced outcome, but which may not be truly necessary to “keep the lights on”. We could insist they were best practice, but then that would be applying our values onto the client. The risk with that being a loss-loss outcome if we ended up antagonizing them; the client might decide not to engage us in the upgrade (a loss of revenue for us) and the client might end up with a failed upgrade without our expertise.
We decided the best approach was to explain why we felt these steps were important and the risk of not including them or including cut down versions of them. We would then leave it up to the client whether that changed their perception of the value of each step. So long as the client values at least the minimum to lead to a successful upgrade, the outcome is more likely to be a win-win. The client will engage us in providing services that they value (so some revenue for us) and they will have a successful upgrade.
Of course, if the client doesn’t value the bare minimum for a successful upgrade, we should consider politely declining the gig. We don’t want to be part of a process that is more likely than not to lead to failure, as we value our reputation for successful outcomes.