Forecasting for Business - Blog

Width vs. Depth, Rotate your sales forecasts of 90 degrees

2010-08-31T16:05:49Z

We have already discussed why Lokad did not care much about forecasting Chinese food rather than Sport Bar beverages. Another way of thinking our technology consists of rotating your sales forecasts of 90 degrees.

We are observing that a consumer product has, on average, 3 years lifecycle. This means that on average the amount of data available for every single product about 18 months. When, we look at the sales history with a monthly aggregation, 18 months of data means 18 points.

With 18 data points, no matter how smart or advanced is your forecasting theory, you can't do much simply because we face an utter lack of data to perform any robust statistical analysis. With 18 points, even a pattern has obviously as seasonality becomes a challenge to observe because we don't even have 2 complete seasonal observation.

Your mileage may vary from one industry to the next, but unless your products stay in the market for decades, you are most likely to face this issue.

As a direct consequence, classical forecasting toolkits require statisticians to tweak forecasting models for every single product because no non-trivial statistical model can be robustly fit with only 18 points as input data.

Yet, Lokad does not require any statistician, and the magic lies in the 90 degrees rotation: our models do not iterate over data a single time-series at a time, but against all time-series at once. Thus, we have a lot more input data available, and consequently we can succeed with rather advance models.

This approach is just common sense: if you want to forecast the seasonality of your new chocolate bar, the seasonality of the other chocolate bars seems like a good candidate. Why should you treat each chocolate bar in strict isolation from the others?

Yet, from a computational perspective, the problem has just become a lot harder: if you have 10,000 SKUs the number of associations between two SKUs is roughly 100 millions (and 10,000 SKU is nowhere a large number). That's precisely where the cloud kicks in: even if your algorithms are well-designed not to suffer a strict quadratic complexity, you're still going to need a lot of processing power. The cloud just happens to make this processing power available on demand at a very low price.

Without the cloud, it is simply not possible to deliver this kind of technology.

How bulk purchases impact safety stocks

2010-08-04T15:12:12Z

We have published an introductory tutorial that provides the formula used to compute the reorder point based on the forecasted demand, the demand uncertainty, the lead time and a couple of other factors.

This classical safety stock calculation comes with a couple of key assumptions about the demand. We have already posted about how to handle varying lead time. Then, there is another implicit assumption in the classical formula: buyers are assumed to be independent.

Recently, we have been approached by a company that frequently sell items in bulk to classrooms. Although most of the sales are single-item order, from time to time, comes a 20-30 items order for a whole classroom. The graph below illustrate the resulting sales patterns of intermittent bulk purchase.

Dislaimer: numbers made up and some results are widly approximated for the sake of simplicity.

Over those 12 months, we can see that we have 2 patterns:

ongoing single-unit orders which account for 13 orders per months on average.
intermittent bulk sales which account for +30 orders on average.

The average monthly sales is at 23 orders per month, but if we remove the bulk order factor, then the average purchase drop to 13 orders per month.

Now, what is the right safety stock in this situation? If we consider the classical safety stock formula with typical settings, then we are going to have a reorder point established at roughly 30 items: the 23 orders per month average, plus the safety stock itself covering the demand uncertainty. Bulk purchases at 30 items are very likely to be missed short of a hand-few items.

Yet, the classical safety stock calculation is less than optimal: here, we end-up storing about twice as much items than we need to to address the individual purchase, and yet, the safety stock is not high enough to cover big bulk purchases.

In order to address bulk purchases, we need to refine our safety stock formula to take this pattern into account. For sake of simplicity, we are going to model the bulk purchase pattern as a single factor later reintegrated in the safety stock formula.

In order to reflect the bulkiness of the sales, we could consider the largest purchase for each item being sold. Yet, this value is not robust in the statistical sense, as a single super-large historical purchase can completely skew the results.

Instead, we should rather consider a quantile of the bulk order quantity distribution as illustrated by the threshold Q in the illustration here above where all orders have been ordered from the smallest quantity to the largest one.

In this safety stock analysis, there is a natural fit for the quantile value to adopted for Q: it should be equal to the service level - as defined for the classical safety stock formula - that is to say the desired probability of not having a shortage.

Let call y_Qthe bulk quantity associated to probability Q (in this illustration here above, we have y_Q = 30). Technically, y_Qis the inverse cumulative distribution of sales function taken at the quantile Q. The reorder point calculation becomes:

R = D + MAX(σ_L * cdf(P); y_Q)

where σ_L * cdf(P) happens to be the safety stock as computed based on the demand uncertainty.

Computing y_Q in Excel is a bit tedious because there is not equivalent of the PERCENTILE function for inverse cumulative distribution. We have to resort either to an histogram scheme or to a VBA macro.

The ICMD User Defined Function for Excel, pasted below, performs the y_Qcalculation, assuming the sales orders are listed in an Excel range and sorted in increasing order.

' Inverse cumulative distribution
Function ICMD(r As Range, q As Double)
    ' Computing the total
    Dim s As Double
    For Each c In r
        s = s + c.Value
    Next
    ' Finding the threshold
    Dim a As Double
    For Each d In r
        a = a + d.Value
        If a >= (q * s) Then
            ICMD = d.Value
            Exit For
        End If
    Next
End Function

Based on this refined formula applied to the sample data, we obtain a reorder point R = 13 (demand forecast) + 30 (bulk quantity) = 43 which is sufficient to address the bulk purchase with a high probability while keep the inventory as low as possible.

Got business-specific constraints too? Don't hesitate to let us know. We can adjust Salescast to better fit your business.

Honored by the Windows Azure Partner Award of 2010

2010-06-23T12:30:43Z

Today, Lokad has been announced as the Windows Azure Platform Partner of Year by Microsoft. This year, Lokad has been chosen among the nearly 3000 entrants worldwide for those awards.

This award recognizes Lokad for demonstrating innovation, competitive differentiation and customer value by using Windows Azure. The Microsoft Partner Awards recognize partners that have delivered exceptional Microsoft-based solutions over the last year.

The Lokad team is extremely proud of achieving this level of recognition. The last French company to get an equivalent award was Dassault Systèmes, the largest French software company and it was two years ago.

As outlined in our previous post, we have been working hard to really get the most of Windows Azure. We did not just port an existing technology toward the cloud, but we did re-design from scratch a cloud-native architecture.

Our ambition is to deliver the most accurate and most scalable forecasts of the market. Windows Azure has already demultiplied our efforts and the results we bring to our clients on a daily basis, but that's only the start. We firmly intend to keep up with the hard work to unleash all Windows Azure potential for the next generation of business analytics.

Designed for large scale forecasting with Windows Azure

2010-06-11T16:12:16Z

Lokad is a proud user of Windows Azure, the cloud computing plateform of Microsoft. Our forecasting technology would be nowhere as scalable and accurate without Azure.

Cloud computing opens tremendous opportunities as far reliability, security, performance and costs are concerned. Yet, to get the most out of the cloud, apps have to be natively designed for the cloud. Our current cloudy architecture is drawn below.

Our migration toward Azure costed us about 1 year of efforts that spread from late 2008 to early 2010 (which was still pretty fast considering the tremendous challenge it represented to redesign the architecture from scratch).

Best patterns and practices for entreprise apps in the cloud are still a very nascent area. At Lokad, we want to share our experience and get feedback from the community.

Although Lokad is not an open source company, we release as open source components that we believe to be applicable to other businesses. As a matter of fact, we are supporting multiple open source projects such as:

Lokad.Cloud - an O/C mapper for Windows Azure (object to cloud)
Lokad.CQRS - Command-Query Responsibility Segregation for Windows Azure.

Willing to design an enterprise app on the cloud? Make sure you check those two projects.

Salescast, sales forecasting made WAY EASIER

2010-05-28T20:02:25Z

We are proud to announce that we have just released the first version of Salescast.

Salescast is a web application hosted on Windows Azure that deliverers sales forecasts, the easy way. Feature-wise, Salescast is very close to our Lokad Safety Stock Calculator (LSSC), a desktop app which, despite its name, is also delivering sales forecasts.

Why another client app?

Over the two years of existence of LSSC, we noticed that data integration represented the No1 issue faced by our clients. Forecasting issues were simply dwarfed by the sheer amount of data import issues. We have been trying to add more and more data adapters to LSSC, reaching +20 supported apps, and yet LSSC keeps failing at properly importing data as there are thousands of apps in the market.

Stepping back from the actual situation, we asked ourselves: why should clients even bother about data integration? Shouldn't this sort of thing be part of the service in the first place? Letting our prospects and clients face such issues was not acceptable.

Thus, we decided to address the problem from a radically different angle: just grant Lokad an access to your data, and Lokad will figure out the rest; and the project codenamed Salescast was born.

Salescast needs one single information to setup the whole forecasting process: a SQL connection to your database. Nearly every modern ERP, CRM, accounting, shopping cart, POS, MRP ... software store data in a SQL database. Most of your business apps are probably powered by SQL. Salescast also supports the different SQL flavors: MSSQL, MySQL, Oracle SQL.

Do you believe in magic?

We haven't discovered the ultimate technology that would make all data integration issues go away. In order to solve data integration issues, Salescast uses a combination of technology and process.

1. Salecast attempts to auto-detect the target application leveraging its library of known apps, and if the data format is recognized, it proceeds with the forecasting process.

2. If the database is not recognized, then a Lokad engineer gets appointed to design the data adapter. Once the adapter is designed we get back to step 1.

How much is this going to cost?

We don't intend to charge beside our primary per-forecast pricing. More precisely, we promise to give a try at integrating every single app that gets plugged to Salecast. If the integration proves to be really complicated (which happens with old ad-hoc systems) then, we might come back with a quote to complete the job. Naturally, you're free to refuse the quote.

What about the future of Salescast?

For the initial release of Salescast, we have been exclusively focused on SQL database. Later on, we plan to add a wider range of data formats (Excel spreadsheets, REST APIs, ...). We will also enhance the reporting capabilities of Salescast. Just let us know what you need.

Salescast is readily available, get your forecasts now!

Forecasting API v3 is live (REST + SOAP)

2010-05-02T12:13:09Z

About 18 months ago, we were announcing the release of the API v2. Today, we are proud to announce that Forecasting API v3 is live.

Both Safety Stock Calculator and Call Center Calculator have been already upgraded toward API v3 starting from the versions 2.5 and above.

As a primary benefit the 1h wait delay between data upload and forecast download is no more. We recommend to upgrade toward the latest versions of those apps.

(note: our Excel add-in has not been upgraded yet)

The primary focus of this release is simplicity. Indeed, the API v2 had incrementally grown to +20 web methods with both a certain level of redundancy and a lack of separation of concern.

Then, over the last 18 months, thanks to our growing partner network, we discovered many minor yet annoying glitches in API v2 related to popular programming environments (Java, Python, C++, Apex, ...). Thus, we made sure API v3 would avoid designs that prove to be troublesome in some environments.

Also, API v3 comes with both REST and SOAP endpoints. Indeed, REST has emerged as THE approach to ensure maximal interoperability in modern web-oriented enterprise environments, and we are very committed in staying up to the industry standards.

Here are a few facts about API v3:

8 web methods (and only 4 of them actually required to for production usage) while API v2 had +20 methods. Less methods mean less time to spend deciphering our API spec.
The .NET Forecasting Client for API v3 has been reduced about 1k lines of code against +10k lines of code for the previous API v2 version.

Since API v3 provides all the features of API v2 while being much simpler, we have already started to migrate all existing service in production toward API v3.

API v2 won't be available for new users any more, but we will make sure all customers in production are properly migrated before shutting down the service for API v2.

Don't hesitate to contact us if you need you need any assistance in this process.

Shortage vs. Stock, forecasting accuracy matters

2010-04-26T15:55:06Z

Demand forecasting is a cornerstone of inventory optimization. Yet, the exact relationship between:

the service level (probability of not having a shortage),
the safety stock (amount of inventory above the expected demand),
and the forecasting accuracy

is sometime a bit fuzzy. Hence, let's try to clarify the situation.

Shortages costs money: customers are dissatisfied and less likely to return, money invested in customer acquisition gets wasted, indirect sales may be lost too, ...

Yet inventory costs money too: more stocks mean more working capital, more product obsolescence, more warehousing costs; excess inventory means higher advertising costs and lower selling points, ...

Hence, serving customers is a financial tradeoff between the amount of inventory and the amount of shortages.

We are implicitly considering a retail situation here, but a near identical reasoning applies to manufacturers as well.

At this point, it's still unclear how the forecasting accuracy gets into the picture. In particular, for some companies, it might look like as if no forecasts were produced in the first place. Ex: just min-max reorder policies, and no forecasting.

In fact, even if no one in your company explicitly produce forecasts, your inventory still get an implicit forecasting accuracy (illustration here above, the orange triangle representing the constraint). Indeed, it is possible - albeit a bit complicated - to compute the implicit accuracy by companies in your safety stock levels with your shortage frequencies.

Adjusting the tradeoff either in favor of the service level, or in favor of inventory reduction does not improve the implicit accuracy, as one cost is exchanged for another (illustration on the right, the constraint is rotated, not reduced). Forecasts might be hidden by your processes, it won't prevent your company to suffer financial losses if those forecasts happen to be incorrect.

Unless there is a deep lack of analysis in your inventory policies, the improvement brought by adjusting the shortage vs. stock tradeoff is expected to be marginal (which could yet represent substantial savings nonetheless, especially if the margin is thin).

In order to improve both sides of the equation, you need better forecasts.

The impact of an improved accuracy is illustrated in the graphic on the left. Compared to the previous situations, we see that reducing the accuracy let you reduce both the frequency of shortages and the amount of safety stock.

The theory roughly says that reducing the forecast error from 1% (relative) can be used to either reduce the shortage frequency from 1% (relative) or reduce the amount of safety stock from 1% (relative).

In practice, there might be obstacles to fully leverage the improvement brought by the extra accuracy, such as the service levels offered by your own suppliers. Yet, with a conservative position, we can still estimate that 1% extra accuracy bring either 0.5% of shortage reduction, or 0.5% of safety stock reduction.

Then again the tradeoff shortage vs. stock can readjusted keeping the new improved accuracy.

Open Lokad accounts with Lokad.TinyAuth, a tiny REST API

2010-04-17T08:33:08Z

http://app.lokad.com/rest/newacount.ashx?partnerkey={key}&email={email}&name={name}

Forecast's species: classification vs. regression

2010-04-06T10:21:02Z

The word forecasting is covering a very large spectrum of processes, technologies and even markets. In the past, we introduced the worlds of forecasting software, distinguishing between:

Deterministic simulation software
Expert aggregation software
Statistical forecasting software

Lokad falls in the last category as our technology is purely statistical. Yet, Lokad is far from covering the entire statistical spectrum on is own. Two broads categories of forecasts exist in statistical forecasting (*):

Classification forecasts
Regression forecasts

(*) We are oversimplifying here for the sake of clarity, as statistical learning subtleties are well beyond the scope of this modest blog post.

Classification attempts to separate (or classify) objects according to their properties. The illustration below from Tomasz Malisiewicz illustrates a classification task trying to separate images picturing a chair from images picturing a table.

Illustration from tombone's blog

The output of a classification is binary (or rather discrete): objects get assigned to classes with more or less confidence, i.e. higher or lower probabilities.

On the other hand, regressions typically output curves. The illustration below is considering a time-series representing historical sales, and displays the corresponding forecast.

The regression forecast is a curve rather than a binary (or combination of binary) settings. Inputs get prolonged into the future.

How does this distinction impact the business?

Well, it turns out that Lokad - as it stands early 2010 - only delivers regression forecasts. Thus, there are many interesting problems that cannot be tackled by Lokad because these are classification problems:

Customer segmentation: for each customer, we would like to evaluate the probability of achieving successful up-sale through a direct marketing action. Following the same idea, we could try to predict the churn as well.
Fraud detection: for each transaction, we would like to evaluate - based on the transaction pattern - the probability for the operation to be a fraud attempt.
Deal prioritization: based on the properties of the prospect (availability of budget, industry, contact rank in the company, expressed level of interest, ...), we would like to evaluate the likelihood to get a profitable deal out of each prospect to prioritize the sales team efforts.

Frequently, we are asked whether Lokad could deliver classification forecasts as well. Unfortunately, the answer will be negative for the time being. Albeit being rooted by the same mathematical theory, classification and regression entail very different technologies; and Lokad is pushing all its efforts toward regression problems.

Although, we are not dismissive about classification problems, they truly deserve attention and efforts. For 2010, we are sticking to our roadmap, but further ahead, classification could be a natural extension of our forecasting services.

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.