Lokad news - Integrated business forecasting

Thanks to the contribution of Toby Champion, we have updated our forecasting tutorial for PHP5. Indeed, PHP5 now natively supports SOAP web services (the standard used by Lokad). The old PHP4 tutorial based on NuSoap remains available.

Since the launch of the Developer's corner, I have noticed that Lokad was lacking some high level documentation that would rather address Why? questions as opposed addressing How to? questions.

Thus, I have summarized in the newly published Programmer's guide for the Time Series API a couple of answers to the questions that get frequently asked by our partners. If anything is missing, just ask.

We have just added a Developer's section. Lokad has been designed to be easily integrated into any 3rd party application right from the start. Yet, the information targeting developers was somehow spread into many different sections of our website. Adding a Developers section was the obvious solution to this problem.

In all the Lokad applications, both add-ons and the web application itself, there is a mysterious forecasting task setting named the period start.

Mea culpa. Choosing this name was really unfortunate and lead to many incomprehension.

Thus, I have decided to rename this parameter the period reference. It's default value is 2001-01-01 (i.e. Monday, January 1st, 2001), and unless you know why you need to change this value, I would strongly suggest you did not.

Let's start with a practical example. Let's assume that, as a retailer, you need monthly sales forecasts in order to make your monthly sales replenishment orders. Yet, your business months are starting the 15th of each month. All your suppliers are expecting your orders to be passed the 15th, and for years, all your monthly sales analysis have been starting the 15th.

In such a situation, it would be a real pain if Lokad was arbitrarily deciding that a month had to be starting the 1st. In order to avoid such a pitfall, Lokad provides an additional setting for the forecasting task definition that lets you adjust when you want the period to start: it's the period reference.

If you want your monthly forecasts to start the 15th of each month, then you can use 2001-01-15 as your period reference (or 1999-02-15 or 2017-11-15, the result would be the same). This date is used as a reference to infer all the other period's starting dates.

Further examples:

• If the period reference is set to 2001-01-15 for a yearly forecast, then all years start January 15h (instead of January 1st).
• If the period reference is set to 2001-01-15 for a weekly, then all weeks start on Tuesdays (because 2001-01-15 was a Tuesday).

In summary: The period reference, previously named "period start", is a date (past or future, it does not matter) used by Lokad to adjust the period boundaries both for historical data aggregation but also for the forecasts themselves. In particular, it has nothing to do with the starting date of the forecasts.

Although the Lokad services themselves are closed source, all the integration components have been released as open source. The two upcoming products Lokad Safety Stock Calculator and Lokad Call Center Calculator are also developed as open source products.

For the Lokad customers, key benefits of open source components are

• no spyware, no badware. We don't ask you to trust us, you go and check the code yourself. We do our best to maintain a documented code, nothing gets buried in the dark.
• greater control on your IT infrastructure. Having the source code means that you can't be locked in (through proprietary file formats that could not be migrated for ex.).

Yet, as Jeff Atwood is pointing out, open source isn't only about disclosing the source code. His definition of open source involve further requirements:

• An OSI approved license. Lokad is using the (new) BSD license that allows code reuse into both closed and open source applications.
• The project must use a commonly available method of public source control. Lokad is relying on the Subversion hosting of SourceForge.NET. Thus, Lokad can't just take the code offline on its own.
• The project must provide public evidence that it accepts and encourages code contributions from the outside world. Well, you can check the Ohloh page of Lokad to have a look to see how many people are involved in those projects.

Also, on a more technical side, we have also setup a public build server. Our continuous integration builds include unit testing, automated code guidelines validation, and documentation generation. Check it out!

Since its launch in November 2006, Lokad has been providing a programmatic access to its forecasts through the Lokad Web API. Since the very first day, we have done our best to ensure the best forecasting accuracy. Yet, the future may not always be accurately predicted based on the sole historical data.

It is far better to foresee even without certainty than not to foresee at all. Henri Poincaré in The Foundations of Science, 1946

This situation is typically dealt with through an estimation of the forecast error: in addition to the forecast itself, an estimate of the forecast error is also computed. For example, this is the suggested approach for safety stock calculation.

Thus, we have decided to extend the Web API with estimated forecast errors. For any forecasting task, it is now possible to retrieve the Mean Absolute Percentage Error, see GetMape and GetMapes web methods. The new version of the Web API stays fully compatible with the existing applications.

Lokad can be accessed programmatically through our web services. We are already providing tutorials for quite a few languages, namely C#, Java, PHP and C++.

But we were not providing any Python tutorials so far, although there are several promising ERP implemented in Python. If you're not convinced, have a look at TinyERP and ERP5.

Thanks to Maxim Krikun, we have now a complete Python tutorial that explains how to use our Forecasting Web Services. As usual, the source code has been released as open source on SourceForge.

The Lokad forecasting technology is accessible through our Forecasting API. We already had published tutorials for C#, Java and PHP.

Thanks to the contribution of Tomasz Szulist, we have just published a new tutorial for C++. As usual, the source code is available as open-source on SourceForge. In order to communicate with SOAP, we have been using the excellent gSOAP toolkit. Check-it out.

In retail, the ultimate goal of sales forecasting is usually to calculate optimal safety stocks. Unfortunately, most online resources do give much detail about the explicit algorithms that should be used for safety stocks.

In order to facilitate the task for customers and partners (and competitors :-), I have just published an extensive guide Calculate safety stocks with sales forecasting. The guide is illustrated with a Microsoft Excel spreadsheet.

The intent of this guide is to be a valuable piece of information for practitioners. I have pushed some efforts in order to make it independent from the Lokad forecasting technology (thus, you can grab your favorite forecasting tool, and re-use the formulas as such).

There is a question of utmost importance when it comes to statistical forecasting: what is error function used during the learning process? Indeed, it's based on the error function that you can evaluate whether a forecast is good or bad. It's also the very same error function that drives your learning process when building a statistical model.

Finding an error function isn't hard. Quite the opposite, there are plenty of error functions available: Mean Squared Error (MSE), Mean Absolute Deviation, Median Absolute Deviation Error (MAD), Mean Absolute Percentage Error (MAPE). ...

Yet, in almost 1 year of existence for Lokad, the question of the choice of error function has never been raised by any customer. Well, this situation is very natural, as Lokad is precisely taking in charge the whole forecasting process.

For those who might be interested, the answer is, unfortunately, not simple. Lokad using several error functions depending on the context. We are often using bounded version of the MAPE (identical to the classical MAPE, but the function gets upper bounded to 1) for the benchmarks. The upper bound is used to make the process more robust against pathological time-series that would have had huge errors otherwise.

Yet, if the data is not too noisy (i.e. not too much outliers), then we are often using the MSE function which tends to be much more practical from a computational viewpoint.