Just Doing It

Recently we were running a segment of our design workshops for generating and managing Supply Chain Center of Excellence (COE) organizations for a large European company, and in defining their standard COE processes, we discussed with one sub-team what were their deployment strategies for projects. I was met with a kind of blank look, “deployment strategy?” OK, I dislike that kind of language as much as the next guy (making mental note to adjust the workshop, and framework wording), so I rephrased it, “how do you usually approach getting defined projects going to use the new processes you’ve designed?” They had no usual approaches, and the idea was somewhat strange to them. “Don’t we just hand the specifications to the project teams, and they launch?” Well, that’s a kind of deployment strategy. I’d like to spend this article on looking at a handful of process deployment strategies, and their merits and drawbacks.

Hit and Run: you usually see this type with large, expensive consulting companies – they define new Supply Chain processes, and then the client company drops them and allows their own business teams to create projects and deploy; I’ve heard it called cost-saving. Of course, the business teams are not terribly happy having consultants tell them what to do, so you may or may not have any projects, and deployment result. Symptoms of this approach are anger at consultants (and the traditional jokes – what’s a consultant? Someone who takes your watch out of your pocket, tells you the time, and keeps the watch in payment), dissatisfaction with whatever the approach was – BPR, SCOR, Lean, Six-Sigma, you name it – and failure to change process. Process teams who seek to be internal consulting organizations can easily take a ‘hit and run’ attitude. It certainly frees teams up to do more projects quickly. However, they don’t last long as organizations. Avoid this approach. I can’t tell you how many ‘hit and run’ projects we’ve seen.

Pilot and Steer: personal favorite. For processes and projects which can be split over individual products, plants, customer segments, product lifecycles, materials, or other types of entities, you can pilot the process change with a small, non-lethal area, with the process team actively engaged in project definition, material, work and information flow deployment, and carefully monitoring the Supply Chain performance against requirements. At the right time, the process scales up across organizations, and the COE team works to steer the rollout successfully. Business process owners feel in control to a high degree, and there’s a fair amount of ‘skin in the game’ for the process team. There’s no feeling that the process team ‘runs away’. I suggest this approach where you can actually do pilots – but this is not always possible.

Test and Control: tricky to execute. Imagine the COE team has created a program which substantially redesigns processes which affect materials and procurement which is shared among many global process consumers, or shared sales processes affecting a large global customer base, or perhaps processes controlling global statutory requirements (import/export licenses) which have effectivity dates. In practice, it can be very difficult to pilot and steer. However, with a small process team, it can be physically impossible for them to participate in a global rollout (imagine a team of 5 affecting a key process in 139 countries). You could look at this as a ‘hit and run’ type situation, since they can only hand off to local project teams. They can, however, oversee global testing – they may not be able to work with each individual team, but they can control the results of testing to ensure that the processes being turned on work: test the processes before rollout, test the processes with the users after rollout, and certify they work before switching off the replaced processes. They have substantial skin in the game, so you reduce perception/acceptance problems, but mostly at the central level. Local teams will still grumble.

Extended COE Team: Best accepted, but heavier investment. For process programs which do not need to be centrally directed (COE programs not focused on shared process resources) I’ve preferred to train a local team in COE standards and methodology relating to their problem, and allocate a single supply chain resource to coach and manage the extended team for deployment. The drawback is that the overall program is moderately slower. The benefit is that you now can have networks of parallel process teams working to re-engineer local processes, but can also coordinate and work with global resources on global programs in a defined, modular way – a sort of hub-and-spoke. Standard process reference frameworks like SCOR are a must.

The Borg: Heaviest investment of all, a must for risky programs where you’re not worried about friends. To quote the wiki1 on Borg (short for Cyborg – however in several European languages it means ‘fortress’)

They are known both within and beyond Star Trek fandom for their relentless pursuit of that which they wish to assimilate or acquire, their rapid adaptability to almost any defense, and their ability to continue functionally after what may seem a devastating or even fatal blow as if nothing at all had happened, and as such have become a powerful symbol in popular culture for any seemingly unstoppable force against which “resistance is futile”.

With a huge supply chain change, you temporarily create a very large rollout team which is coordinated in the fan-out globally to introduce new processes. It requires enough people to handle each change event at the local level, and substantial communication with each other. Once this group is mobilized by the process team, the change can happen very fast, but obviously for such a large resource base, funding demands can be significant. Other terms we used to use for this was “Deathstar”, or the sarcastic “We’re from corporate, and we’re here to help you.”

Shelf Deployment: Lethal. Your team does a large supply chain program, the sponsor, stakeholders, and steering committee like the result, which is put ‘on the shelf’. I use this term which is in reference to software which is purchased in companies for marketing purposes – ‘shelfware’ – and not actually deployed or used. In some cases a supply chain program sponsor may support a program for the purpose of activating a lot of work in a subject which they have no intention of using; they only want to ensure that there is visible activity (‘marketing’). In one situation, my team found that they were one of eighteen different teams working on the same problem. I can understand it if you’re working to see what the best result was. But eighteen different teams? My teams have tried and tried to profile this before a program gets launched, but they are difficult to forecast. This deployment is lethal because the supply chain team is the face of the sponsor to the larger internal world, and everyone is aware of all the work and meetings attended with no result. The supply chain team here kills their own metrics – numbers of processes examined or modified versus benefit, the numbers of supply chain people working vs numbers of major processes changed, and so on.

So, in summary, this is a sampler of deployment strategies. The strategies which are valuable have key features which we use to select them, whether the deployment can be split into pieces, if it must be done globally and quickly, and so on. Certain deployments which have low interaction and ‘skin in the game’ should be consistently avoided – ‘hit and run’ or ‘shelf deployment’ because they provide poor value to the process owner and will reflect badly on the central COE team. I would love to hear other examples from readers of their deployment strategies.