Confused by the term Supply Chain “Process Management”? It’s been a constant, low-level struggle for us in communicating about our work, something like a lowgrade cold you can never seem to shake off. There are at least two different problems with the name, and unfortunately, they get mutually reinforced.
Supply Chain process management, for us, has basically four flavors of ‘how’ – Assessment (ISO-9000, Sarbanes-404), Modeling (Process Modeling, Metrics Models), Optimizing (Re-engineering, Mergers), and Implementation (Governance, Software, Workflow). Likewise, it has four flavors of ‘what’ – Strategic, Network, Process, and Resource.
Our favorite technique for describing this to our Grandmothers is “we describe businesses, try to understand them, and make them work better” (step 1: describe; step 2: understand; step 3: improve). OK, this all makes a certain kind of sense, but then the onion begins to peel, and our noses get stuffy with the low-grade cold.
First off is the ‘how’ or technology problem. We view supply chain technology as a business issue, not a technology issue. However, a lot of supply chain process technology that’s floating around focuses heavily on the IT part of the equation – the improvements you get through automation (Step #3 above). Not only that, but a ‘supply chain process’ seems to equate to an application, rather than a activity. It’s difficult to imagine what the management application is for processes that are 80% manual activity (phone, email, walking around a warehouse, visiting customers). This is the first step to a full-blown “flu” from the light cold. Business people definitely don’t mentally equate supply chain process to an IT solution. (Let me come clean for a moment: my background is IT – ERP, Logistics, Order management, full-blown supply chain. I know exactly how IT thinks). For IT people who don’t equate process to an application, there is the fallback of process workflow, orchestration, or in lastditch cases, metrics reporting solutions—as though reporting certain process outcomes is tantamount to managing them.
My advice: avoid any hint of a technology discussion with business people when you discuss supply chain process management. Technology has its place, but at the ‘implementation’ phase, not before. I was involved in a BPM program a few years back, which IT had gotten a hold on, that was about which EDI transactions to put into place, and about the difficulty in getting them done, to create a supplier-owned inventory process. My team modeled the ‘as-is’ situation, and it was stark. Warehouse 1 fed warehouse 2 fed warehouse 3 fed the bins of a manufacturing line. We immediately asked what the point of EDI transactions on inventory in/out of each warehouse would be. Weakly, the business stated that it was a question of telling the supplier/warehouse managers how to balance with the visibility of supply they had. Then, of course, we put the “Moose on the Table” – everyone who looked at the model wondered why we couldn’t feed inventory from the supplier-managed warehouse direct to the manufacturing input, and avoid the EDI signals altogether to “manage” the warehouses and inventory.
Thankfully, the business agreed, and, through some fairly simple contract restructuring – with no IT involvement whatsoever, achieved 80% of the intended program benefits in inventory (and cash cycle time) within roughly a month. We also pointed out that next they might need IT involvement to push inventory ownership to manufacturing back flush, or even further – perhaps shipping, or even receiving transactions on the side of the customer. That’s IT involvement – changing the transaction flows in SAP. But you get the point. Supply Chain process mannagement isn’t SAP; it isn’t EDI, or reporting systems; it’s managing how business gets done.
Second is the “what” or framework problem. If you’re an IT person, there is a tremendous feeling of angst around which side of the BPEL, BPML, or other “business process” languages you are on. When I get in those conversations, I ask a simple question, “What side is the business on?” Of course, to the business, they aren’t interested in detail-level technological discussions of syntax and semantics around process languages; they are interested in discussions around “Order Consolidation” (SCOR Deliver), or “Verify Material” (SCOR source). We are continually redrafting even these types of language with the business to keep them relevant, generic, and sensible. We find that many key business problems are solved in level-1 and level-2 discussions, i.e., “Plan Build-to-Order.” Technical IT type discussions aren’t level-1 or level-2, and they aren’t Level-3 or Level-4—i.e., “Gather Build-to-Stock Demand” or “Build and Test,” but they exist somewhere on Levels 5/6/7. (I am reminded of Bertrand Russell’s problem with “Turtles all the way down,” Ptolemaic epicycles, or fractal patterns.) We have a hard enough problem talking with businesses about the forest before they leap into the trees. So much IT technical discussion launches businesses into a discussion somewhere in the tree leaves between xylem/phloem and DNA. Talk about a lost audience! My advice: Supply chain Process Management is fine – for now. Ensure you don’t get confused with technologies and software, and don’t get confused with specialized process languages. Stick to real “how work gets done issues,” and you will be successful—and successful in communication. The “Describe, Understand, Improve” model of what it is tends to help a lot—at least, until my team pointed out to me that the acronym is, therefore, “DUI.” A rose is a rose.