Forecasting for Business - Blog

30 days free trial vs. $30 free trial

2010-03-10T13:15:14Z

A few months ago, we upgraded our pricing for a much simpler strict pay-as-you-go pricing. In short, we charge for every single forecasts retrieved from Lokad: the greater the number of forecasts, the larger the bill. Then, if no forecasts are retrieved during for a month, no charges are placed on your account.

This pricing evolution leads us to revise the notion of Free Trial as well, but in a more subtle way. Indeed, our old 30 days free trial was both not enough and too much in the same time:

Not enough, because companies frequently need a few months to evaluate a new technology.
Too much, because we did not previously put any usage limitation within the 30 days period (*).

As a consequence, we decided to go for a Free Trial with $30 of pre-paid services.

Simply put, when you open a Lokad account, your balance starts at $30 instead of zero (or the equivalent amount in other currencies). Hence, you will only get charged if you consume more than $30 worth of forecasts which represents almost 3000 forecasts.

Then, we haven't set any expiration policy on this pre-paid amount. Hence, if you open your account now, but only start using it in 3 months from now, the free trial amount will still be available.

(*) We did choose $30 as we think it's sufficient for the most situations. If your company require more than that to evaluate Lokad, don't hesitate to drop us an email, as we are usually extending this amount on simple requests.

Auf Deutsch!

2010-03-01T17:24:52Z

Thanks to the ongoing efforts of Nicole Backhaus, Lokad now features an up-to-date German translation. Our next target are Spanish and French. Stay tuned.

Measuring forecast accuracy

2010-02-23T08:32:50Z

Most engineers will tell you that:

You can't optimize what you don't measure

Turns out that forecasting is no exception. Measuring forecast accuracy is one of the few cornerstones of any forecasting technology.

A frequent misconception about accuracy measurement is that Lokad has to wait for the forecasts to become past, to finally compare the forecasts with what really happened.

Although, this approach works to some extend, it comes with severe drawbacks:

It's painfully slow: a 6 months ahead forecast takes 6 months to be validated.
It's very sensitive to overfitting. Overfitting should not to be taken lightly, and it's one the few thing that is very likely to wreak havoc in your accuracy measurements.

Measuring the accuracy of delivered forecasts is a tough piece of work for us. Accuracy measurement accounts for roughly half of the complexity of our forecasting technology: the more advance the forecasting technology, the greater the need for robust accuracy measurements.

In particular, Lokad returns the forecast accuracy associated to every single forecast that we deliver (for example, our Excel-addin reports forecast accuracy). The metric used for accuracy measurement is the MAPE (Mean Absolute Percentage Error).

In order to compute an estimated accuracy, Lokad proceeds (roughly) through cross-validation tuned for time-series forecasts. Cross-validation is simpler than it sounds. If we consider a weekly forecast 10 weeks ahead with 3 years (aka 150 weeks) of history, then the cross-validation looks like:

Take the 1st week, forecast 10 weeks ahead, and compare results to original.
Take the 2 first weeks, forecast 10 weeks ahead, and compare.
Take the 3 first weeks, forecast 10 weeks ahead, and compare.
...

The process is rather tedious, as we end-up recomputing forecasts about 150 times for only 3 years of history. Obviously, cross-validation screams for automation, and there is little hope to go through such a process without computer support. Yet, computers typically cost less than business forecast errors, and Lokad relies on cloud computing to deliver such high-intensive computations.

Attempts to "simplify" the process outlined are very likely to end-up with overfitting problems. We suggest to say very careful, as overfitting isn't a problem to be taken lightly. In doubts, stick to a complete cross-validation.

Forecast consumption reports

2010-01-24T17:15:06Z

We announced a few weeks ago that Lokad had evolved toward a simplified pay-as-you-go pricing. We have pushed today a significant upgrade of app.lokad.com, the web app that lets you manage your forecasting subscription.

Beside an (hopefully) improved look & feel, the web app now reports your current forecast consumption, expressed as the total number of forecasts that have been retrieved from Lokad. In particular, forecasts delivery are now reported in 15min increments.

In the back-office, we have also upgraded many aspects of our infrastructure as well to make it a better fit for Windows Azure.

In particular, we recommend to upgrade client apps (such as Safety Stock Calculator or Call Center Calculator) toward their respective latest versions.

In order to avoid data quality issues that tend to lower the overall accuracy (as a mild case of Garbage In, Garbage Out problem), data validation of our Forecasting API has been made a bit more strict, and this change could cause upload failure with old client apps.

In order to upgrade, just launch the client app, wait for about 5s, and click the Update button that should appear in the upper right corner. If no button appears, then you already have the latest version.

Ask.Lokad and get answers

2010-01-12T16:53:04Z

Although some of you might have already noticed, we did quietly launch ask.lokad.com about one month ago as a replacement of our old forums that were suffering several terminal Web 1.0 design syndrome.

Ask.Lokad is powered by StackExchange, the engine behind StackOverflow the most popular Q/A forum for programming matters.

We have decided to revamp our forums, because we were getting the feeling that most simple questions such Should I consider working days or calendar days for lead time? or Why does ASA get negative when the number of agents get below call intensity? tend to be poorly addressed on the web.

Although, answers are probably buried in textbooks somewhere, our ambitions is to make this sort of knowledge as openly reachable as possible.

Have a question about forecasting, or about the usage of forecasts in your business? Don't hesitate to post on Ask.Lokad, we do our best to get all questions addressed. Then, as Lokad does not have a monopoly over smart people, the community can also challenge our answers with their own.

Tags and Events user guide

2010-01-07T13:28:50Z

First of all best wishes for 2010. Lokad has been nicely growing and moving forward during 2009, we really hope to be able to move forward according to plans for 2010.

As a first token of goodwill, we have finally published the long missing User guide for Tags and Events.

Indeed, tags and events are a powerful extension of our Forecasting API, that let Lokad refines forecasts through meta-data. Both LSSC and L3C support this framework.

Tags and Events are especially useful in retail and manufacturing to better handle promotion forecasts, but also product launches as well as all sort of factors that impact the business.

BizSpark One, we made it out of 25,000 startups

2009-12-22T09:58:46Z

We are very proud to announce that among more than 25000 startups that have applied for the BizSpark program worldwide, Lokad has been selected with 13 other startups (wordwide too) for the new elite program named BizSpark One.

This selection has been made public on December 9th at LeWeb'09 in Paris.

We are taking the opportunity to thank Microsoft once again for its ongoing support.

Where does Windows Azure folks get their inspiration?

2009-12-14T22:03:53Z

At PDC'09, Microsoft and Lokad unveiled a case study about Windows Azure. Yet, what was our surprise when discovered the following video at the Windows Azure booth (check for video links below).

Once upon a time, there was a little company with little funds, but great ambitions.

The little company wanted to process truckload of historical data. Yet, it could not afford buying tons of computing stuff.

Yet, through Windows Azure, the little company was suddently able to process truckload of data, and to output truckload of forecasts too.

The massive amount of forecasts would then flow into the IT systems of large retailers to optimize their companies.

The little company produced lots of profits, and its employees lived happily ever after. THE END

Unified pricing system

2009-11-30T14:20:36Z

We are pleased to announce that we are upgrading Lokad toward a new pricing for our Forecasting Services. The details have already been published, check it out.

Although your mileage may vary, simulations indicate that this change will represent, on average, a 20% saving for current customers. Our goal remains to stay far ahead of the competition, both in terms of forecasts accuracy but also in terms of TCO (Total Cost of Ownership).

Pricing has been simplified ...

It's simple enough to be expressed with a single compact formula $0.15 * forecasts 2/3 . And, yes, we still have the Power 2/3 coefficient. For those those who don't enjoy mental calculations of cubic roots, we do provide a calculator .

Wait! What do you call a forecast? If you want sales forecasts for a single product for the next 3 months, one value for each month ahead, it counts as 3. If you repeat your forecasts twice during the same month, it counts as 6. If you do the same with 1000 products instead of a single one, it counts as 6,000 forecasts.

Then, the power 2/3 just acts as a large discount volumes:

1k forecasts cost $15
1M forecasts cost $1,5k (instead of $15k)
1B forecasts cost $150k ( instead of $15M)

Bottom line, it's rather simple. Our inspiration was a mix of the Windows Azure pricing and the Twilio pricing.

In particular, it must be noted that there is no setup fee. Obviously, such a pricing is only made possible because Lokad is powered by cloud computing.

Then, if you happen to use or need Lokad, only once in a while, you wont be charged unless you actually use Lokad. If your account stay idle for 1 month, then you don't get charged at all!

Finally, there is no threshold effect our pricing (thanks to the power 2/3 approach). The more forecasts you need, the higher the costs, but the higher the volume discount too.

Our old pricing system, which had not been revised for almost 2 years, was suffering from one major issue: there were subtleties. Not major ones, still it was sufficient for people to routinely estimates their subscription costs to thousands of $ while it was only less than a hundred.

We are not going to make the same mistake twice. Our pricing page now includes dedicated simulators for inventory optimization and call center optimization. Any doubt about the new costs, just type in you number of SKUs or you number of calling queues.

... but it's still a variable pricing

Many analysts have been expressing concerns about variable pricing in software. How I can get my business plans in order if everything is changing all the time? you might ask.

In our humble opinion, and as far forecasting is concerned, we believe that variable pricing to solving way many more problems than it causes. You might wonder, what will happen if the subscription costs increases? If your Lokad subscription costs increases, it means that your company is growing and so are your forecasting needs. The last thing you want while undergoing a steady growth is get your forecasts wrong, and let improper planning wreck havoc in your business. Then, our volume discount factor (power 2/3) ensures that the more you grow, the more volume discounts you get from Lokad.

But there is the other situation that analysts usually don't both bother to consider: what if my business is going down, what if we are downsizing, what if branches get sold?

With Lokad, your subscription will be going down accordingly. You will not be stuck with an over-sized on-premise solution to maintain. Pay-as-you-go guarantees that the software you buy today will not accelerate the demise of your business if the economy turns out to be really rough.

Scalable Forecasting, a Microsoft case study

2009-11-17T19:00:00Z

Forecasting has been available as a rationalized business practice for more than a century. Yet, we believe that we when it comes to scalable forecasting, Lokad is one of a kind. We invested a lot of efforts to scale Lokad up during 2009 to address the needs of our largest customers. In particular, we have migrated our technology toward Windows Azure, the cloud computing plateform of Microsoft.

Today, we are at PDC'09, and we are pleased to announce the release of a case study produced by Microsoft about our scalable forecasting technology. Special thanks to the Azure marketing team.

Internet is needed for your forecasts

2009-11-14T18:28:46Z

Do I really need an Internet connection to get your forecasts? is a question frequently asked by prospects having a look at our forecasting technology.

Well, the answer is YES. With Lokad, there is no work-around. Our forecasting engine does not come as an on-premises solution.

But why should we need an internet connection for an algorithmic processing such as forecasting?

The answer to this question is one of the core reason that have lead to the very existence of Lokad in the first place.

When we started working on the Lokad project - back in 2006 - we quickly realized that forecasting, despite appearances, was a total misfit for local processing.

1. Your can't get your forecasts right without having the data at hand. Researchers have been looking for decades for a universal forecasting model, but the consensus among the community is that there is no free lunch; universal models do not exist, or rather, they tend to perform poorly. This is the primary reasons why forecasting toolkits feature so many models (don't click this link, it's 3000 pages manual for a popular toolkit). With Lokad, the process is much simpler because the data is made available to Lokad. Hence, it does not matter any more if thousands of parameters are needed, as parameters are handled by Lokad directly.

2. Advanced forecasting is quite resource intensive but the need to forecast is only intermittent. Even a small retailer with 10 point of sales and 10k product references represents already 100k time-series to be forecasted. If we consider a typical performance of 10k/series per hour for a single CPU (which is already quite optimistic for complex models), then computing sales forecasts for the 10 points of sales take a total 10h of CPU time. Obviously, retailers prefer not to wait for 10h to get their forecasts. Buying an amazingly powerful workstation is possible, but then does it make sense to have so much processing power staying idle 99% of the time when forecasts are made only once a week? Outsourcing the processing power is the obvious cost-effective approach here.

3. Forecasting is still under fast paced evolution. Since our launch about 3 years ago, Lokad has been upgraded every month or so. Our forecasting technology is not some indisputable achievement carved in stone, but on the contrary, is still undergoing a rapid evolution. Every month, the statistical learning research community moves forward with loads of fresh ideas. In such context, on-premise solutions undergo a rapid decay until the day the discrepancy between the performance of current version and the performance of the deployed version is so great that the company has no choice but to rush an upgrade. Aggressively developed SaaS ensure that customers benefit from the latest improvements without having to even worry about it.

In our opinion, going for an on-premise solution for your forecasts is like entering a golf competition with a large handicap. It might make the game more interesting, but it does not maximize your chances. Don't expect your competitors to be fair enough to start with the same handicap just because you do.

Refreshing Min/Max inventory planning

2009-11-02T12:07:31Z

Min/Max inventory planning has been available for decades. Yet, some people argue that Min/Max drive higher costs and that it should be replaced with other methods

Before jumping on conclusions, let’s try to clarify a bit the situation first. For a given SKU (Storage Keeping Unit), the inventory manager needs only two values to specify his inventory management policy:

A threshold, named reorder point, which defines if any reorder should be made (Point 3 in the schema).
A quantity, named reorder quantity, to be reordered, if any (Point 1 in the schema).

The Min/Max system simply states that:

MIN = ReorderPoint
MAX = ReorderQuantity + InventoryOnHand  + InventoryOnOrder

Thus, as long you’re not carving in stone your Min & Max values, the Min/Max system is perfectly generic: it can express any reorder policy. As far inventory optimization is concerned, adopting the Min/Max convention is neutral, as it’s just way to express your replenishment policy. Contrary to what people seem to believe, Min/Max does neither define nor prevent any inventory optimization strategy.

What about LSSC and Min/Max?

Let’s see how our Safety Stock Calculator can be plugged into a Min/Max framework. The goal is to update the Min & Max values to optimize the inventory based on the forecasts delivered by Lokad.

The calculator reports reorder points. Thus, handling MIN values is rather straightforward since MIN = ReorderPoint. The calculator even lets you export reorder points directly into any 3rd party database through our adapter framework. Yet, MAX values are slightly more complicated. The MAX definition states that:

MAX = ReorderQuantity + InventoryOnHand  + InventoryOnOrder

Let’s start with the ReorderQuantity. The safety stock analysis gives us:

ReorderQuantity = LeadDemand + SafetyStock
                             - InventoryOnHand - InventoryOnOrder

Which could be rewritten as:

ReorderQuantity = ReorderPoint - InventoryOnHand - InventoryOnOrder

where ReorderPoint = LeadDemand + SafetyStock Thus,

MAX = ReorderQuantity + InventoryOnHand  + InventoryOnOrder

Becomes

MAX = (ReorderPoint - InventoryOnHand - InventoryOnOrder)
    + InventoryOnHand  + InventoryOnOrder

Which simplifies into MAX = ReorderPoint that is to say MAX = MIN.

Obviously there is something fishy going on here. Did you spot what’s wrong in our reasoning?

Well, we haven’t defined any cost being associated with order operations. Consequently, the maths end up telling us something rather obvious: without extra cost for a new order (except the cost of buying the product from the supplier), the optimal planning involves an infinite number of replenishments, where the size of each replenishment tend to zero (or rather tend to 1 if we assume that no fractional product can be ordered).

Getting back to a more reasonable situation, we need to introduce the EOQ (Economic Order Quantity): the minimal amount of inventory that maintain the expected profit margin on the product. Note that our definition differs a bit from the historical EOQ that is a tradeoff between fixed cost per order and the holding cost.

In our experience, the EOQ is a complex product-specific mix:

It depends on volume discounts.
It depends on product lifetime, and potentially expiration dates.
It depends (potentially) on other orders being placed in the time.
...

Thus, we are not going to define EOQ here, as it would go beyond the scope of this post. Instead, we are just going to assume that this value is known to the retailers (somehow). Introducing the EOQ leads to:

MAX = MIN + EOQ

What’s the impact of EOQ on service level?

Let have another look at the schema. The Point 2 illustrates what happens when the reorder quantity is made larger: the replenishment cycle gets longer too (see Point 4), as it takes more time to reach the reorder point.

Other things being equal, increasing EOQ also increase service level, yet in a rather inefficient way, as it leads to a very uniform increase of your inventory levels that is not going to accurately match the demand.

Thus, we suggest taking the smallest EOQ that maintain the desired margin on the products being ordered.

Roadmap for 2010

2009-10-28T12:34:00Z

The purpose of this roadmap is to help our customers and partners to better understand where Lokad is heading. We have listed what we believe to be the most important directions.

Needless to say, this roadmap is subject to change. First, we are willing to listen to suggestions being made by customers or partners. Second, although we do our best in evaluating the amount of work involved with scheduled evolutions of our technology, every forecast comes with some error margin.

Summary

Forecasting Technology
Pricing
Vertical apps
Tooling experience
Internationalization and localization

Forecasting Technology

The first and foremost priority is the quality of our forecasts. Although, nothing appears to change because we take care of making our upgrades seamless, our forecasting technology has evolved a lot over the last 12 months.

Lately, we have invested significant efforts in migrating toward cloud computing to make our technology even more scalable, which will help us in the end to deliver even better forecasts.

November 17th, 2009: we will be running on top of Windows Azure.

Later on, we will keep on improving the quality of our forecasts. Then, we are also planning a series of improvements for our core technology:

Q1 2010: Dropping the 1h delay. Users (or apps) will be notified as soon forecasts are ready. We will maintain 1h as the maximum delay for an arbitrarily large amount of forecasts, but if the dataset is small, we want the forecasts to be delivered within minutes.
Q3 2010: Horizon-specific forecast accuracy. Currently, Lokad delivers a single averaged accuracy value for each forecasted time-series. Yet, it’s clear that the accuracy depends on the horizon being considered: short term forecasts are more accurate than long term forecasts. In the future, we will provide a specific accuracy value for every single forecast.

Then, we have also a couple of unscheduled items:

Introducing the notion of explicit business saturation in our framework. Business saturation is frequently encountered in hostels, restaurants or transportation. It reflects that a market that can’t adjust itself to meet the demand all the time: there are saturation points.
Introducing explicit geo-location meta-data to further refine forecasts with geo-targeted data such as weather data. So far, we have only carried out a few (promising) experiments with temperature curves. This could be provided by default to all customers.

Pricing

Our pricing follows a simple idea: we charge for the forecasts, the higher the number of forecasts, the higher the subscription price. We believe our pricing to be fairly aggressive, as most of our competitors have a TCO more than 10x higher than ours.

Yet, our pricing as of today is still a bit obscure, as many customers told us that the notions of Forecasting Task, Forecast Frequency and Forecast Period were confusing.

Thus, we have decided to go for a major pricing redesign, going for a much simpler pay-as-you-go pricing. A very rough draft is available for the new pricing page. We have run simulations, and the new pricing will represent an average 20% discount or so for existing customers.

November 17th, 2009: new pricing takes effect.

The detail of future pricing evolutions is not obvious:

lower hardware prices means that we will be able to process more forecasts spending less on computing resources;
more hardware resources mean potentially better forecasts through more intensive forecasting methods.

Bottom line: we will remain a very competitive forecasting solution, and we will keep on adjusting our pricing accordingly.

Vertical applications

Our two vertical apps Safety Stock Calculator and Call Center Calculator have undergone massive improvements. Although, it’s not widely advertised on our blog, we have pushed a dozen incremental upgrades for those two apps over the last few months.

The feature wish list is publicly available. Most of those features have been suggested by customers. Don’t hesitate to post your own request as well; that’s the most certain way of getting the feature you need implemented.

In the future, we will keep improving those applications with frequent incremental upgrades. Those applications will be maintained as open source under a liberal license (BSD) that allows the code to be repackaged within closed source apps.

Q2 2010: Release of the 3.x branch for our apps under a common framework codenamed Forecast Studio. The primary focus will be to improve the ease of use of our apps. The secondary focus will be to provide guidance concerning the forecasting operations (to detect potential issue with the input data for example).
Q2 2010: Our desktop apps are ported as web apps. Although, there are plenty of reasons to keep desktop apps, there are also plenty of reasons to provide web apps as well. In particular, it would facilitate setup within small companies.

Then, we are considering a new app named Hostel Booking Calculator, but the corresponding schedule is unclear. Hostel managers are facing a daily tradeoff between selling their rooms to a tour operator (with a large discount), or just waiting for the customers to directly fill the hostel (with a much better margin).

Forecasting the demand would help hostel managers to give up just enough rooms to the tour operator while maintaining their hostel booked all the time. This app would depend on the Business Saturation feature to be added to our core forecasting technology.

Tooling experience

Lokad has been designed to be easy to integrate into 3rd party apps right from the start, and we intend to stick to this principle. In particular, vertical apps provided by Lokad are using our public Forecasting API, much like any partner natively integrating Lokad (such as Kirix for example).

In additional to our Forecasting API based on SOAP, we also have an open source Forecasting SDK targeting Microsoft .NET. This SDK is used by our partners (and large companies too) to speed-up the Lokad integration within their systems. We will maintain and upgrade this SDK for Microsoft .NET as new features become available in our Forecasting API.

Obviously, Microsoft .NET isn’t the sole popular development environment. Thus, we intend to extend our coverage in 2010.

Q2 2010: Forecasting SDK for Java.
Q3 2010: Forecasting SDK for PHP.

Then, we are also considering additional ports, but without any schedule at that point:

Forecasting SDK for Python.
Forecasting SDK for C++.

Internationalization and localization

Lokad is based in Paris (France), but our primary language is English. We are already supporting 7 major currencies, but as far languages are concerned, even the French translation is lagging behind.

For 2010, we plan to gradually improve the situation, starting with the translation of our website, followed by the localization of our vertical apps. In order to reduce the delay between the initial publication in English and the publication of the translated content, we will upgrade toward a continuous localization process.

Q1 2010: Website localization process setup for French and German.
Q2 2010: Website localization process setup for Spanish, Italian and Russian.
Q3 2010: Localization of our vertical apps.

As a final word, this roadmap isn't carved in stone. Contact us anytime to get more details or to suggest different directions.

Follow us on Twitter

2009-10-27T09:29:38Z

A few weeks ago, we started to us Twitter. Here is the list of Lokad team members that you can follow on Twitter:

@abdullin - Rinat Abdullin
@cdrnet - Christoph Rüegg
@darisole - Dario Solera
@vermorel - Joannes Vermorel
@lokad - group account managed through CoTweet

Never heard of Twitter? It's a sleek micro-blogging social network, quite handy for business purposes.

Modeling varying lead time

2009-10-21T13:14:58Z

Yesterday, we discussed why lead times wer varying in the first place. Let's go further and see how varying lead times impact safety stock calculations.

Let's start with qualitative insights of a lead time distribution. For the sake of simplicity, we are considering working days here to avoid week-end artifacts.

The lead time distribution starts with a gap (illustrated by Point 1) that illustrates the minimal amount of time needed to perform shipping and transport.
Then, there is the lead time mode which corresponds to the average shipping and transport time when the product happens to be available at hand in the supplier inventory. This mode is located at Point 2.
If replenishment takes longer, it's because the supplier has been encountering a shortage. As illustrated by Point 3, the lead time distribution is rather flat, and reflects the lead time mode of the supplier itself, that is to say the amount of time needed by the supplier to replenish its own inventory.
Finally, there are rare situations where replenishment takes even longer (Point 4). This situation happens if both the supplier and the supplier of the supplier get a shortage of their own at the same time; or if there are disruptions at the producer level.

The safety stock model model proposed in our sample Excel spreadsheet does not take into account varying lead time. Yet, it happens that this formula can be adjusted in a simple way to take lead time variations into account.

If we assume supplier shortages to be independent for the ones of the retailer being replenished then, lead time should be adjusted to match the desired service level. Obviously, if the supplier supplies only one company, the retailer itself, this assumption does not make much sense; but it's well adapted to the frequent situation where there are many retailers passing order to a larger wholesaler.

Visually, as illustrated in the schema here above, if the desired service level is at 70%, then the surface of the area colored in orange must represent 70% of the total area under the curve; that way the lead time ends up matching the desired service level.

Looking at the schema, it is clear that the higher the service level, the larger the corresponding lead time which is a rather reasonable behavior.

In order words, instead of handling the full complexity of the lead time distribution, we propose a mathematical trick where a single lead time quantile that matches the service level is used. This single value reflects the amount of uncertainties undergone by the retailer to ensure a certain level of service to its own customers.

The good news is that Microsoft Excel does natively support quantile calculations through the PERCENTILE function. Thus, you can list all the observed lead times in an single Excel column and then apply the PERCENTILE function, the first argument being your list of observations, the second argument being the service level percentage expressed as a value between 0 and 1 (ex: 0.30 represents 30%).

Once you have computed this lead time quantile, you can inject the value as such into the Safety Stock Calculator. It will directly reflect the lead time variations into the reorder point calculation.

This analysis initiated with real-world eCommerce observations is leading us to interesting conclusions: in order to ensure high service levels, someone has to the take the financial hit as far inventory levels are concerned.

In our first schema, the orange area was illustrating a lead time associated to a 70% service level (numbers here are made up, it's just for the sake of the explanation), but what happens if the retailer want to increase its service level?

Well, there is a threshold effect matching the service level of the supplier itself. In the present case, we have a supplier with a service level at 75%. This threshold is caused by lead time distribution itself that comes with a strong statistical mode.

If the retailer wants service levels below 75% (i.e. below the supplier's own service level), then the matching lead times are small. Ex: 3 days for the real world example considered in the previous post.

On the contrary, if the retailer wants service levels above 75%, then matching lead times are inflating very fast. This behavior is visually illustrated with the second schema displaying a 90% service level. As you can see, the duration of the matching lead time get more than doubled, which mechanically more or less double the amount of inventory as well.

As we were saying initially, high service levels - which increase sales along with customer satisfaction - do not come for free. In the end, a company in the chain ends up paying for that. Retailers need to be careful concerning service levels offered by their own suppliers, because the threshold effect that we just outlined radically impacts the amount of inventory needed to satisfy its own customers.

Still having questions about lead time and inventory optimization?
Just ask.lokad.com