A comprehensive user engagement program comes next so that users fully embrace this made-to-measure solution. But (and here’s the killer) the solution is only tailored to the initial pilot, and it’s not yet tuned to the rest of the network, which means the struggle begins.
Not only that, advisory support stops because it’s only budgeted for in the initial project stages. Meanwhile, organizations are changing all the time. People leave or get promotions. New recruits arrive, with fresh ideas and all the right experience. And acquisitions take place. After that, new production lines are developed and put into operation, while business processes are redesigned to take into account new insights or in response to events. And all these things can happen even during the implementation project.
While companies change dramatically over the years, your tailored solution still operates just as it was initially designed and implemented.
Upgrading to newer versions is difficult because customized software add-ons may need to be reintegrated. So, the company is stuck with the original version until somebody sufficiently high in the hierarchy says it’s time for a solution make-over.
It’s much better to adopt a standard template and use the built-in parametrization tool to configure the solution to individual company needs. Local versions are to be avoided, let alone modifications with proprietary code. I see three fundamental reasons for this:
While companies change dramatically over the years, your tailored solution still operates just as it was initially designed and implemented.
Upgrading to newer versions is difficult because customized software add-ons may need to be reintegrated. So, the company is stuck with the original version until somebody sufficiently high in the hierarchy says it’s time for a solution make-over.
It’s much better to adopt a standard template and use the built-in parametrization tool to configure the solution to individual company needs. Local versions are to be avoided, let alone modifications with proprietary code. I see three fundamental reasons for this:
You may argue that adopting an available standard product is a rather conservative choice that doesn’t allow you to innovate. That might be a valid argument if it’s innovation that’s at stake. Innovative concepts should be developed as part of a co-creation effort, not in a customization project. But that’s a story for another time.
So, my advice is to standardize where possible and challenge stakeholder customization requests. Feel free to contact me to learn more about how we at OMP speed up implementation and rollout with smart templates and industry-specific advice.
Biography
Supporting implementation in the OMP alliance network around the world, Maarten focuses particularly on standardization, scalability, and rapid deployment in the consumer goods industry.