- Service levels are terribly managed within companies.
- This is primarily because sales and marketing set service levels without understanding the implication on constraints and supply chain costs.
The choice of service levels sets priorities for how much of each product to stock at each specific location (a warehouse or other internal stock location), which we’ll call the product/location combination.
Placing a product into the supply chain network requires a capital investment, takes up space in a warehouse, and must be transported to its location. Therefore, each item placed in stock is in competition with other stock to consume the limited resources of the company. The decision on setting service levels for product/location combinations has important cost and profitability implications.
Functional Versus Dysfunctional Service Level Setting
A service level can be functional or dysfunctional. By functional, we mean that the service level is “right” for a high percentage of the product/location combinations – that is, the stocking levels are neither too high nor too low for the product locations. When service levels are too high, products are manufactured or purchased and then deployed into the supply network that do not have to be.
When service levels are too low, customers aren’t able to get the stock they demand. Each type of error imposes costs on the company.
Service Level Example
If we imagine a company with a single product at a single location – so that the product can be viewed in a vacuum – the service level calculation is straightforward. The inputs are the per-unit carrying cost for the duration of the lead time and for the time the product is kept stocked, and the per-unit stockout cost. From the business perspective, the service level represents a tradeoff between the cost of inventory and the cost of stock-out. A (cumulative) probability distribution –commonly the Normal distribution – translates these inputs into the target service level. An example of an online calculator is available at the following link.
Quotations from Vendors on Service Level Setting
This assumption is implied in virtually all consulting and vendor documentation on supply chain service levels. Such documentation tends to begin from the point of how to attain service levels, assuming the company knows when and how the targets are set. This is not so simple to demonstrate because it is more of an observation of what is excluded from the documentation rather than what is included.
Here are a few examples. First Llamasoft.
Running safety stock optimization in order to identify optimal safety stock placement is the first step. Once these parameters are defined service level optimization is run. The model considers the cost of safety stock for each product type and target average service level across products as defined by user.
Typical inventory “segmentation” approaches (often incorrectly labeled “inventory optimization”) group SKU-Locations (SKU-L) into arbitrary “segments” and then apply “one size fits all” logic by assigning all SKU-Ls within the segment the same service level target. These approaches lead to poor recommendations, very distant from the optimum. ToolsGroup’s MEIO instead automatically assigns a different service target to each individual SKU-L, achieving the desired global service level while simultaneously yielding the mathematical optimum for the objective function chosen (options include minimum inventory investment, minimum storage space, maximum net margin, minimum obsolescence, maximum freshness and more).
PTC’s service parts management solution, Servigistics, empowers logistics organizations to control the balance between inventory (supply) and service levels (demand) at the lowest cost.“
There is nothing wrong with any of these quotes, but they illustrate the implicit assumption that the user knows how to set service level targets. It is a normal sales pitch to not make it appear as if there are other complications that stand in the way of the customer achieving what it requires. So the presentation of the steps to attain the final goal are made to appear less involved than they actually are. This is also why there is such a great discrepancy between reading the marketing literature and viewing vendor demos versus observing how software is implemented in reality. This last part is something that almost no one is interested in discussing, including the customers, particularly after they make a purchase.
Extreme Service Level Target Setting
Some of this is evident in the thinking and influence of Six Sigma, where very high manufacturing quality levels are promoted. The basis of Six Sigma is to strive for 3.4 defect parts per million. But such a standard can be unwarranted.
Consider an example of a manufacturer of toilet paper roles considering whether an investment should be made to upgrade a machine that currently allows defects of 1 in 100,000 rolls of toilet paper to achieve only 1 in 3.4 million.
What if that investment cost $300,000? Will your customer compensate you in excess of $300,000 for that extra quality?
What if the company finds that its 1000 sheet rolls actually contain between 995-1005 sheets? Is any customer going to do the count?” Are goals that no one will ever care about and no one will ever pay for a good idea to commit to? This same issue plagues service level setting. Rather than see service level targets as an opportunity to feel good about the benefits of “high service level”, the process should be viewed as a mathematical exercise that accounts for the cost-benefit tradeoffs.
How Supply and Production Planning Implementations Tend to Play Out
There tends to be a great focus on the method used for supply and production planning. On most projects, that I have either implemented or evaluated, most of the resources and emphasis goes into setting up the method, training users on the user interface, building data interfaces, etc.. What time is left over on the implementation goes to parameter setting? How many times has a company made no addition to headcount to manage parameters, expecting the software they purchase to do this automatically for them?
When companies move from one method to a more sophisticated approach (for instance, MRP to cost optimization), it is usually the case that the company will have not yet mastered their parameters. This means that they will, I think in the vast majority of cases, have not come close to optimizing the software they currently use, before moving onto the next software package.
However, outside of inventory optimization and multi echelon (which is still lightly installed) none of the planning methods do anything to help set those parameters. This does not mean the functionality does not exist to do this — it does. But the software expects intelligence from the implementing company to set up the software to do so.
Safety stock and service levels are two of the most important of these supply and production planning parameters.
In the presentation, I will provide the following:
- The Appropriate Context: The background for the reasons that safety stock and service level, as well as the other parameters, end up, so sub-optimized.
- Improvement Opportunities and Rought Effort Estimates: How to improve this condition at a reasonable expense of time and money.
- Actual calculations: I will show calculations that explain how this can be accomplished using several test cases that can meet all of the objectives that I layout at the beginning of the presentation.
The Common Feature of Dysfunctional Service Levels within Companies
The disfunction in service level setting emanates at least partly from misbehaviors in the organization. Companies virtually never create an “S&OP process” where service levels are modeled and trade-offs are accepted. Rather, the assumption often is that the alignment of different functions within the organization will occur naturally once the right software is in place and the right communication environment is established. However, what we find is that different departments, as well as different groups within departments, are not on the same page as to what the service levels should be.
High service levels benefit Sales but are a cost to the rest of the business. Since salespeople are compensated partly based upon how much they sell, inventory that ends up not being sold is not their problem. And salespeople are not generally held accountable for their forecast accuracy, only for quota attainment. Clearly, the sales departments in companies and the operations or supply chain departments do not have the same goals. For a salesperson, the ideal service level is of course 100% and across the broadest possible product line. This will maximize the commission of the salesperson, but it is not profit-maximizing.
This problem has a nearly perfect analogy to that of product proliferation. In the past few decades, the product database at companies has expanded often explosively, a situation largely driven by marketing departments. Marketing seems to believe that the way to add value to the company is to offer as many varieties of products as possible. But product proliferation spreads demand across ever more items, increasing the difficulty of forecasting individual item demands. Often the product database is littered with slow-moving items that Marketing still insists are critical to continue stocking. Marketing, of course, is not held accountable for dead stock, or for service-level; rather it is pursuing its silo objectives.
Now there is no guarantee that Sales will accept the limitations on service level recommended by the modeling. It is naïve to think that people value data over self-interest. It may be proposed that CFO’s or CEO’s, having the broader view will moderate the Sales impulse to have excessive targets, but this potentially moderating influence is not apparent at any of the clients I have worked with. That said, the modeling may reveal to Sales how costly and feasible their designated service levels are across the entire product/location database and thus prompt an understanding as to which product locations are a top priority for very high service levels.
Brightwork Explorer is about reaching a functional relationship between service levels and operational capabilities. We will discuss this in more detail when we complete our the development of our application that will bring this capability to virtually anyone.