PRODUCT-ORIENTED DELIVERY FOR SUPPLY CHAIN (LECTURE 1.3 SUMMARY)

learn menu

The aim of supply chain optimization (SCO) is to deliver or improve a software application that automates an otherwise expensive array of repetitive, mundane decisions, thus liberating managerial bandwidth for more pressing matters. This application, like supply chain itself, ought to be considered an asset rather than an operation cost, given its inherent, long-term value to the organization. The software requirements for such an asset, however, go well beyond the scope of mainstream supply chain theories and tools, including the intrepid office mainstay, Excel.

product-oriented-delivery-for-supply-chain

Watch the Lecture

Supply chain is not OpEx

Traditional supply chain methodologies tend to leverage manpower in lieu of software. This is reflected in teams of clerks with Excel spreadsheets, manually devising and revising decisions on an almost daily basis. The primary downstream effects of this are greater overhead and increased firefighting, not to mention the enormous amounts of bandwidth dedicated to manually processing and addressing the myriad, inevitable exceptions and emergencies common in supply chain.

Supply chain, as expressed above, is treated as an operating expense (OpEx), which refers to the day-to-day expenses incurred in the running of a business. This designation reflects a grave misunderstanding of supply chain’s true relationship to a business. However, given the vast resources that must be dedicated to maintaining traditional supply chain orchestrations, the OpEx classification is not surprising.

In a traditional supply chain system, salary, benefits, training, technological overhead, etc., must be allocated on a per-clerk basis, and makes supply chain something that requires constant manual tinkering by design. This represents an inordinate outlay for what is, in effect, a series of repetitive, mundane tasks, typically performed daily1.

This does not even consider the lost bandwidth associated with the manual execution of mundane tasks, to say absolutely nothing of the constant firefighting when exceptions arise. Calculating the dollar cost of all that misallocated concentration is difficult, but its profligate contributors include not only clerks but their supervisors, managers, and even C-suite executives.

Supply chain is CapEx

Lokad’s position is that supply chain should be reframed as capital expenditure (CapEx), as it is, in sum, a strategic asset to the company, much like buildings, machinery, and vehicles2. By treating supply chain as a productive asset rather than an ongoing - and costly - activity, a company can make it more scalable and profitable, much like software companies that build their businesses around an underlying product. In this case, the product is a numerical recipe designed to auto-generate all the mundane daily decisions that would otherwise require expensive human input.

This manpower would, in all likelihood, yield decisions of some accuracy, but at a far greater cost – both financially and in terms of bandwidth - than those made by a software-based counterpart. On a day-to-day basis, such a numerical recipe - supply chain optimization (SCO) - would run quietly and independently, much like any other high-value piece of machinery in an organization.

Things SCO must consider

The range of considerations for any given company’s SCO is extensive and varies depending on the type of business. This, from the very outset, disqualifies the very notion of purchasing a standard, off-the-shelf SCO.

Consider SCO in the context of a B2B company versus a B2C one. The latter may have several orders of magnitude more clients than the former, and thus losing an average client may not even be noticeable - as in the case of a supermarket with thousands of regular clients. B2Bs likely do not have that luxury, as they generally have far fewer clients than B2Cs, hence losing even a single client could prove devastating - as in the case of a supplier whose clients are supermarkets.

Thus, the inherent value of a single client shifts depending on one’s perspective, and this perspective informs the service level and safety stock targets a company ought to set. Beyond this indubitable first principle, both B2B and B2C businesses have unique constraints that make the very notion of leveraging a stock SCO incredibly difficult, including:

Inventory: Are the SKUs fast or slow moving? Perishable or not? Orders: Do customers make spot or planned orders? Are the orders configurable? Prices: How much do we charge? Are prices flat? Do we have loyalty cards or bonuses?

The variability introduced by just these factors - and there are countless more - means trying to deploy a standard SCO product is an expensive exercise in futility.

Things SCO must do

SCO is not a typical piece of software. Unlike any other asset, supply chain is a scattered array of actors, materials, and forces - both natural and market. Consequently, the demands on SCO far surpass anything expected of seemingly comparable software, such as an ERP humming in the background. There are no expectations of agility from such software, whereas an SCO must not only be agile but decisive.

A key dimension to this agility is the SCO’s responsiveness to adversarial - or even existential - threats. These are the classes of threats that pose extraordinary financial risks to one’s business and demand prompt and cogent intervention. Excel, for all its strengths, is not designed to respond to these types of threats, let alone yield decision recommendations when they occur.

For example, Excel is completely mute when an airline’s entire fleet is grounded due to a sudden recall, or when wars rage and tsunamis strike. Any of these events could prove cataclysmic to one’s supply chain, thus one needs an SCO that is capable of responding to emergencies with intelligent recommendations. Furthermore, these threats must be computed and responded to quickly. The time horizon for addressing these threats is measured in hours, not days (and certainly not months).

This level of responsiveness is not feasible with traditional supply chain management practices, many of which are bloated even by bureaucratic standards. SCO is the best way to program responsiveness to the threats a physically and geographically distributed network like supply chain encounters.

SCO secret ingredients

The successful implementation of SCO requires a raft of individual software features and ingredients, but the broad categories can be summarized as follows: 

  • Versatile data storage: The SCO can store and provide access to vast amounts of data.
  • Programmable logic: The SCO can be adapted to address different problems.
  • Versatile user interfaces: The SCO displays data related to the areas of interest.
  • Collaborative capabilities: The SCO allows many people to interact with it.
  • Accessible to non-specialists: The SCO is operable by everyone. 

Though applications like Excel arguably satisfy most of the requirements listed above, it is not a supply chain panacea and does not meet the demands of SCO as described in this document. In other words, just because Excel can be used for SCO purposes to some success does not mean it is the best - or even a good - option for this purpose3.

For example, though it can store and process large amounts of data, Excel is not designed to stably process hundreds of thousands – if not millions - of lines of data for an extended network of stores. To give Excel its flowers, it is very expressive in terms of its programming logic in the context of non-SCO functions, but it is not suited to performing computations with random variables - amongst other limitations.

On its face, this may seem like a trivial limitation, but this programming deficiency means that probabilistic forecasting in Excel is exceptionally difficult. Probabilistic forecasting is the very foundation of decision policies like prioritized inventory replenishment, something meaningful SCO is effectively naked without4.

In short, successful SCO requires, amongst other things, software engineered with supply chain in mind, rather than attempting to foist prepackaged software, like Excel, into the corporate mix.

Notes


  1. Routine examples include inventory replenishments and price updates. ↩︎

  2. This is not meant in a literal sense, i.e., for tax purposes. This is more of a philosophical point and speaks to supply chain’s actual meaning and worth within a business’ overarching framework. Simply put, supply chain costs should not be considered analogous to biscuits for the break room. ↩︎

  3. This is a teleological argument, not an uncharitable one. Excel is a very fine tool and is suitable for many office-related functions. That concession aside, saying Excel is not apt for the kind of large-scale SCO described here should be as controversial as saying a scalpel is, on average, a better surgical implement than a spoon. (Inversely, I wouldn’t advise eating ice cream with a scalpel, either.) ↩︎

  4. For the sake of brevity, only a few limitations were discussed here. The lecture, however, dedicates entire chapters to elucidating Excel and Python’s SCO frailties. ↩︎