- How Multisourcing Works
- The Reasons for Multisourcing
- The Reality of Multisourcing
Within supply planning systems, in the vast majority of instances, single locations are assigned to fulfil the demand of internal locations. Multisourcing is the opposite of this and can mean the fulfilment of demand from more than one, but up to many sources of supply.
- Multisourcing is the ability for a supply planning system to intelligently choose between alternate sources of supply. This can apply both to the selection of suppliers as well as to the selection of a source of supply along with the supply network for internal locations.
- The functionality’s driving logic can be multidimensional, from total costs to meeting order dates, etc..
The Reasons for Multisourcing
- One common reason for multisourcing is when one location is the primary location, but cannot handle the capacity of the order, then the supply planning system would move to a second or even third location in order to satisfy the demand.
- Another reason can be to spread, by rough percentages, the total demand among various sources of supply in order to meet contract responsibilities.
The Reality of Multisourcing
Very few supply planning applications can actually perform multisourcing. And I am unaware of any ERP system that can do this. Some applications like SAP SNP that are sold on the ability to perform multisourcing actually cannot practically do so because of the computation time, and therefore after great expense, the functionality is turned off by companies that implement it.
For this reason, in the vast majority of instances, multisourcing continues to be a manual decision and a change made to the purchase order or stock transfer. Sourcing teams within companies contain individuals who know what the various sources of supply are. They alter the purchase order or stock transfer to account for the need.
Multi sourcing is a motivator for companies to implement cost optimization, as it is stated that the cost optimizer can be used to perform multi-sourcing. It should not be simply assumed that your company will be able to get multi-sourcing to work. Still, multi-sourcing is a major motivating factor for the selection of cost optimization as a method of supply planning.
Multi-Sourcing Due Diligence
Before merely assuming your company will be able to enable multi-sourcing successfully, and therefore choosing cost optimization, it makes sense to evaluate the problems other companies have had in activating this functionality and the likelihood your company has in doing the same.
Introduction to Multi-Sourcing
One of the exciting features of software selection is why companies select one method of supply planning over another.
Primary reasons companies select cost optimization are:
- To perform constraint-based planning.
- To perform multi-sourcing.
Constraint-based planning is the ability to restrict capacity. Primarily in the production resources. Although hypothetically companies are told, they will be constrained by other supply chain constraints. Constraints like transportation and warehousing.
Multisourcing is the ability to pull sourcing from multiple locations and to make decisions based upon costs. It is easy to setup locations as sources of supply for an area, and this is performed in all supply planning systems, through the master data setup by making the locations valid to and from shipping point. The logic for when to source from one location versus another and making this match the business requirements is where the trick comes. The way that cost optimization accomplishes this is with the combination of transportation lane costs and resource constraints.
The Multi-Sourcing Requirement
In the perfect state, one location would have a higher cost to supply the second location. However, when the primary sourcing location runs out of capacity, the optimizer, in concept, will then move to the secondary source of supply, without the planner having to do anything. The diagram below can be used to help understand this.
In this scenario, two producing locations have been set up as sources of supply for Location A, which is a DC. If the requirements are within location B’s capacity, location B fulfills the requirements from location A, because the transportation lane cost is only $1 per mile, versus $2 per mile as with location C. When the costs are set up in this way, nothing further is needed to be done. The system will naturally source from location B.
However, if in any one period, the requirements are higher than 100 units, location C will begin to serve as a source of supply to location A.
If the resource that produces the product for location A goes down for maintenance, the resource has no capacity in location B, and C becomes the sole source of supply for this material to location A.
A major reason this is so appealing is that this hypothetical example auto-adjusts. Executive decision makers love this idea and foresee great cost savings from such a system. However, the reality of what tends to occur with multi-sourcing is quite a bit different from this hypothetical example.
The Reality of Multi-Sourcing in SAP
The fact is, in SAP SNP, at least few companies make the jump to multi-sourcing. There are several reasons for this, and these reasons should be considered when selecting both a supply planning method as well as selecting software.
- SNP is a very high maintenance application. This means that there are always many other issues to fix and other things to focus on before multi-source can be reviewed. It can and often is years of fixing problems and focusing on other things until multi-source can be reconsidered.
- Multi-source significantly increases the run time of the optimizer.
- Several clients, I have had that started out with multi-source turned on, ended up turning it off because of the run-time specifically.
- Turning on multi-sourcing in addition to getting resource constraints right and keeping them updated is a heavy burden for even the biggest companies, and both of these capabilities must be present in order for multi-sourcing to work. Therefore, while seeming relatively simple in concept, it is, in fact, one of the most evolved uses of cost optimization for supply planning.
The assumption that a company will be able to multi-source with a cost optimizer drives a decision to the cost optimization method over others. It is not an assumption that is practical. To perform multi-sourcing with SAP SNP, a company must maintain the master data. They must do this for the multi-source option. But must also spend on the servers to make the multi-sourcing model run. In short, multi-sourcing is expensive to do.
If companies are not willing to support this expensive solution, it makes little sense to head down this path. Right now, across the US, there are plans to turn on multi-sourcing in supply planning applications, that may never work properly. This is one of the major areas of cost optimization that promises great things. But which companies are not able to successfully implement.
Multi-plant planning is considered (by this site) to be the second method within the Superplant Concept (see link for definition).
Search Our Supply Planning Articles
Brightwork MRP & S&OP Explorer for Tuning
What is the Superplant Concept?
This book addresses several production and supply planning software functionalities that are all related to the location-based adaptability of the supply chain planning application (multi-plant planning and subcontracting, and contract manufacturing planning).
Solving a Historic Weakness in Production Planning and Scheduling Software
This adaptability is a historical weakness of both advanced planning applications as well as ERP systems. Some of this functionality is rarely found in commercially-available applications, while other functionality is more commonly found but ‘s hard to implement. This book explains these how these multiple functionalities can be leveraged to provide the ultimate in planning flexibility in both supply and production planning.
Why This Book is Unique
The only book about planning for a “Superplant,” by the author who coined the term.
In an environment of increasingly globalized manufacturing, a very long production line that spans the globe is more common than ever. For an increasing number of corporations, multi-plant planning is a reality. “Superplant” describes the ability to plan separate locations as if they were part of one giant plant – or superplant, and is the more accurate modeling of location interdependencies for production and supply planning than is provided by standard advanced planning functionality.
This book delves into the three advanced functionalities that must be enabled for superplant planning: multi-plant planning, subcontracting and multi-source planning. By reading this book you will:
- Investigate how multi-site planning works from a design perspective.
- Learn about the functionality that exists to specifically address multi-plant planning and understand why most supply planning software can do nothing with multiple plants.
- Explore in-depth the PlanetTogether application, which targets the unique planning requirements of a superplant.
- Learn how to set up master data objects to support multi-plant planning functionality.
- Improve Key Performance Indicators (KPIs) through proper deployment of multi-plant planning functionality.
- Examine how subcontracting, and contract manufacturing fit into the superplant concept
Who is This Book For?
This book was written for those with interest in leveraging leading approaches in the supply network for planning improvement. The particular audience would range from executive decision makers to software implementers to supply and production planners.
- Chapter 1: Introduction
- Chapter 2: Understanding a Superplant Conceptually
- Chapter 3: Multi-plant Planning
- Chapter 4: Single Versus Multi-pass Planning
- Chapter 5: Multi-source Planning
- Chapter 6: Subcontracting Planning and Execution
- Chapter 7: Combining All Three Superplant Functionalities
- Chapter 8: The Superplant and the Integration Between ERP and the External Planning System
- Chapter 9: Superplant-enabled Capable-to-promise
- Chapter 10: Conclusion
- Appendix A: Labor Pools in Galaxy APS
- Appendix B: Time Horizons in Galaxy APS
- Appendix C: Prioritizing Internal Demand for Subcomponents over External Demand