Saturday, February 10, 2007

物流策略:构建物流模型

Logistics Strategy: Modeling "Logistics Flows

Have you modeled your “logistics flows” lately?

I received a call recently from an industrial company that attended our 2006 version of “How to Select a WMS” (2007 version to be announced shortly). The issue initially had to do with whether the same WMS/logistics software suite would work for each of several different businesses.

You hope, of course, the answer is yes. But what’s a quick way to get a handle of that? The conversation turned to a discussion of how many “fulfillment chains” they really had – and did they understand what the specific physical flows and capability requirements that were associated with each?

In the past, I’ve used an approach that is useful for this as well as a number of other scenarios – modeling “logistics flows.” While it’s quite common for companies to map physical product flow in some way when something forces the need to do that, this approach adds a couple of other useful elements.

Most companie operate two or more distinct physical supply chains- and sometimes a number of them. At a high level, some of the typical flows would include inbound raw material and finished goods shipments from suppliers; internal company shipments from plants to distribution centers, or plants to plants (one plant supplying another); shipments to customers from distribution centers or direct from plants; customer service related flows (such as spare parts); and reverse logistics flows (product returns, recyclable containers, etc.). They often involve handling by third party logistics providers somewhere in the flow.

I’d argue that many organizations don’t really well understand these multiple physical goods flows, don’t have an accurate model of the multiple information flows that support these physical processes, and have not documented the current and future capabilities needed to support these supply chains.

So what’s the approach? First, you start with modeling the physical flows – what are the distinct paths by which material/product come into your company, move within the company, or move to customers? As we said, this is fairly common.

But to that, you also add the “information dialogs” that accompany these physical flows. Each physical flow will have associated information flows (inputs and outputs to steps of the process) that accompany the movement of goods. This may sound a bit “academic,” but it is useful to characterize the nature of these information flows.

In general, information flows are either electronic or paper-based, and can generally be characterized as being: (1) system-to-system (e.g., EDI); (2) system-to-person (forecast information is provider over a web application) ; (3) person-to-system (a carrier uses a web application to enter delivery status) ; or (4) person-to-person (manual). Clearly, there may be a mix of these communication methods by trading partner, and that also needs to be understood.

These information “dialogs” can be within the enterprise itself, or external to trading partners or service providers. In other words, if you pick up the phone and call carriers to secure a freight move for inbound raw materials, this is a “person-to-person” dialog between your company and an outside service provider that is part of this logistics flow.

The final piece – document the key supply chain “competencies” required at each stage of the logistic flow. In other words, what important capabilities are required at each step? It can also then be useful to identify what additional capabilities could/should be added to the mix?

A simple version of a logistics flow map, constrained by the limits of space, is available here. A real version would identify the nature of the dialogs, and be a bit more granular about current and future capability requirements.

So, you are probably asking, would I use such an approach? I’d argue there are a number of opportunities.

It's a good way to really get a handle on how product really moves within your company, and opportunities for standardization, integration, and automation. Where there is “person to person” information flow predominant, for example, there is probably an opportunity to provide some automation to the process.

It can also be useful in a number of other ways:

• Provide an increased understanding of the supply chain requirements for each distinct physical flow, identifying the holes in current capabilities and “dialogs” and assisting in the prioritization of IT-related projects. Companies employing this exercise often find some of the biggest gaps involve internal information dialogs (e.g., lack of advance ship notices between plants and distribution enters).

• Identify opportunities for use of postponement strategies (the delay of value-added processing and/or product customization until late in the delivery cycle).

• Help provide clarity to potential outsourcing decisions for logistics services, and the IT requirements needed to support outsourcing strategies.

• Use as the key guide for decisions about whether to deploy common or differentiated supply chain applications across different logistics flows (for example, warehouse management software). This can be particularly useful for system decisions following mergers and acquisitions.

I once worked with a leading consumer durable goods manufacturer that used a similar logistics flow modeling process to construct the physical and information technology requirements for three separate market segments:

  • Large mass merchandisers that were shipped in full truck load quantities directly from manufacturing plants – this was a new strategy/logistics flow that required a series of new “competencies”
  • Smaller retailers supply from third party distribution centers supplied by multiple company plants and outside suppliers
  • Parts and aftermarket logistics flows supporting both internal and external repair organizations).

I suggest modeling an enterprise’s unique logistics flows along all three dimensions (physical, information dialogs, and supply chain competencies) can be a powerful mechanism when the need arises for understanding internal and external system requirements, especially when used in conjunction with market segmentation by supply chain service requirements.

But I welcome your thoughts.

What is your approach to modeling logistics flows? Is adding "dialogs" and "capabilities" to traditional physical flow modeling useful? How would you improve or use this approach?

Let us know your thoughts at the link below