Daily Archives: January 18, 2017

Process Transformation: How Do You Get it Right? Part VI

Two weeks ago, we talked about how to drive technological advances, because it’s one of the critical three T’s of Supply Management success (with the other two being talent and transition to better processes). But technological advancement is not enough if your processes, to be blunt, outright suck harder than a Hoover. That’s why, as the Big C’s say, you will need to achieve some “process transformation” if you ever want to become best in class (and why each of these Big C’s claim to have the best advice [for a price] to help you along your journey).

However, as we outlined in detail in our first post last week, it’s very difficult to tell if any of the Big C’s have WHAT you need when, for example, the difference between the four-step framework promoted by one of these C’s (PwC, although SI could have picked any of them … and we do seriously mean any one of them) and four of the first eight random mission statements generated by the mission statement generator at cmorse.org (which is almost as good as the now defunct Dilbert mission statement generator) is pretty hard to discern!

Then, as outlined in our second post, we made it clear that what you really need is a simple process that starts with understanding where you are now, moves on to figuring out where you want to be, creates a plan to get there, and, finally, executes the plan. Then we began our series in earnest by outlining what is involved in understanding where you are now (which is more involved than you might think), which often doesn’t require a team of 10K-a-day consultants, continued on by specifying how you go about figuring out where you want to be (which is often more difficult than one may think), discussed how you how you put together the plan, and then, finally, in our last post focussed on execution — which is always harder than you think.

So where does this leave us? Frankly, with a focus on Adoption, Adoption, Adoption, Adoption. Just like Ballmer used to go hysterical for developers (even though anyone familiar with Brooks’ work on software engineering and The Mythical Man-Month knows that sometimes less is more, especially when you have top talent), you need to get hystical about adoption. If the software is only used by 25% of the people, and even these people aren’t using it all the time, it’s not worth whatever deal you got on it.

And adoption needs to start day one. The users who need to use it everyday need to be involved in the plan from inception through execution. From day one, the cross-functional team needs to include a representative of every user group who will make sure key processes are supported, usability is high, and concerns are met — and if necessary, ensure you sacrifice the few “power features” that only a few will use in favour of the “adoption features” that will ensure a mass roll-out. (Remember, for highly specialized needs, there’s always a point-based best-of-breed solution out there you can get for the power users. And sometimes the ROI from getting two solutions [even at twice the cost] outweighs the ROI from a single solution. Remember, ROI is only X/4 with a 25% adoption rate. With 100% adoption, it’s X, so even if you have to pay 2X for 2 solutions … you still get twice the return.)

So focus on adoption during your process transformation efforts and you will truly achieve process transformation and the results you desire. Otherwise …