Daily Archives: January 12, 2017

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

We spent last week talking about how we 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. The big C’s call this “process transformation” and each of these (including, but not limited to PwC, Accenture, Hackett [Archstone], etc.) claims to have the best advice [for a price] to help you along your best in class journey.

However, as we outlined in yesterday’s post, it’s hard 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) and four of the first eight random mission statements generated by the mission statement generator at cmorse.org is pretty hard to discern.

At the most basic level, process transformation is the process of:

  1. Understanding where you are now.
  2. Figuring out where you want to be.
  3. Creating a plan to get there.
  4. Successfully executing it.

So WHAT you need is a roadmap that takes you through each step, outlining the key interchanges, stops, and information stations along the way. And if it’s your first time driving a big rig through the route, possibly some advice on how to drive that big-rig effectively.

So let’s take this step by step.

Understanding Where You Are Now.

This is a little bit more involved than one may think. One needs to understand:

  • where the processes are efficient and inefficient,
  • where the pain-points are for the team members,
  • where a different process could unlock hidden value, and
  • where the processes are being circumvented at each and every opportunity.

One needs to understand efficiency and inefficiency because efficient processes should not be change without deep consideration and analysis (because attempts to fix what isn’t broken don’t often go well), inefficient processes cost the organization time, resources, and money. So how do you do this?

Benchmarking. While benchmarking is not the be-all and end-all, and SI has even written a paper on The Dangers of Benchmarks and Trend Analysis) (as too much emphasis on benchmarking often blinds an organization to the real opportunities that are hidden in the organization), it is the starting point for an organization that doesn’t even have a good grasp of where it is (or could be).

The organization will start by identifying standard KPIs for the processes it is evaluating and benchmarking internal performance. Then it will look to third parties that maintain industry benchmarks for that process to get a general feeling if it is worse than average, average, or better than average. Any process phase where it is noticeably worse than average is a process phase it should focus on.

Then it will identify the pain points for the team members. It will do this by, surprise, asking them! And it might find that the places they have the most issues are where the organization is average, or even a bit better than average. For example, maybe the primary pain point that the team complains about is Travel & Expense. It could be the case that the team members get their requests in, approved, and expenses submitted just as fast as the industry average for their peers, but if they find it painful and it aggravates them, it should be looked at. Maybe your peers are even more behind the eight-ball than you and your team knows of a solution that makes it so quick and easy that it could be orders of magnitude faster, freeing your team up to work on more value-generating activities.

Then it will review published case studies that relate to the processes under consideration and identify results that are leaps and bounds ahead of where the organization is act, prioritize them, and evaluate whether or not they could work for the organization. (Not all will!)

Then, and this is critical, it will identify where team members are trying to circumvent the processes at each and every opportunity. This is a sign of a broken process that definitely needs to be fixed, even if there is no obvious detriment to the team members circumventing the preferred process (because there always is, even if it’s not immediately apparent).

And, finally, it will incorporate all of this into a cohesive whole — and that is how it will understand, more or less, where it is now.

But this is just the beginning. In our next post, we’ll talk about how it goes about finding out where it needs to be.