A couple of weeks ago, we were announcing the new capabilities of the Forecasting API v2, namely tags and events.

We are proud to announce that our Forecasting API v2 has just been released. In addition to this release, we are also shipping Lokad SDK for .NET, a development-oriented library designed to facilitate the integration of Lokad within Microsoft .NET applications.

Forecasting API version 2

Forecasting API v2 is the next generation of our cross-platform application interface for accessing Lokad business analysis and forecasting services.

It allows software developers and integrators to easily add forecasting features to their products.

Forecasting API v2 supports SOAP Web Services and features:

• Time-serie operations.
• Management of Tags and Events for improved forecasting quality.
• Efficient retrieval and submission of large data sets (batching and paging).
• Methods that simplify migration from the previous version of Forecasting API.
• Additional methods for user support and revenue sharing programs.

Note, that the first version of Forecasting API will be supported for the backwards compatibility. Yet, it is recommended to migrate to the second version to obtain access to the new advanced features such as tags and events, and ultimately obtain better forecasting results.

Please, check out our Forecasting API v2 product page for the documentation links and more details.

Lokad Software Development Kit for .NET

Lokad SDK for .NET targets popular Microsoft .NET framework platform. It simplifies all development tasks related to the integration with the Lokad forecasting technologies.

This SDK is free and includes following resources:

• Libraries for developing .NET apps that leverage our forecasting technologies.
• Sources of the Lokad SDK for.NET.
• Sample applications.
• Reference Documentation for the API and the SDK.
• Free testing server made available for developers.

Lokad SDK allows .NET developers to leverage the API v2 without the need to deal with the mundane tasks of:

• Implementing and coding against Forecasting API v2 web-services.
• Validating requests before sending them.
• Breaking down large requests to avoid timeouts and performing paging.
• Handling connectivity issues and other exceptions.

You can download Lokad SDK for .NET for free or visit the product page for more information.

Any feedback is appreciated, as always. We will be glad to hear any comments, questions or integration stories from you.

Thomas Defaye (Microsoft) is organizing a round table about their Software+Services strategy. Lokad has been invited to join the table. If you are in Paris December 1st, don't miss this event. See below for the full program (in French).

Joannes Vermorel, Founder at Lokad, discusses some aspects of Cloud computing: a personal review about Azure, Amazon, Google Engine, VMWare and the others on his personal blog.

Last week, we introduced the concept of events for the second version of our Forecasting API. This week, we introduce the second major feature of Forecasting API v2: tags.

Another limitation of the API v1 is the management of very short time-series. Indeed, retailers need to forecast their sales starting from Day 1 - but at Day 1, you have exactly zero historical sales data to leverage for this product. Thus, you can't produce a statistical forecast. Seems obvious ...

... but wrong because at Day 1 when launching a new product, there are a lot of historical data already: it's the historical sales of all the other products.

Intuitively, let assume that we have a retailer selling candies who introduces a lollipop with new orange flavor. Even if the retailer doesn't know exactly how much orange-flavored lollipops he is going to sell, he can reasonably approximate his sales forecast by assuming it's going to be roughly on the same level than the other lollipop's flavors (assuming no cannibalization for the sake of simplicity).

Through this small example, it's clear that lack of historical data on a single series do not prevent forecasts to be produced. Yet, most of the forecasting literature is devoted to the study of stationary processes that are usually a significant mismatch with business where time-series do have both a start and an end, frequently associated to the lifetime of a product or a service.

This is why our Forecasting API v2 introduces the notion of time-series tags. For those who are not familiar with tags, it's both a user-friendly way and an expressive way to decorate almost any object - a web page, a file, or a time-series in the case of Lokad.

There are many businesses where long lasting products are rather rare:

• fashion with two collections per year, the products of the new collection never exactly matching the products of the previous collection.
• electronics with fast-paced technological changes where almost no product stay on the market more than 18 months.
• media where the market is driven by novelties - new clips, new movies, new songs.

Tags should express product properties and Lokad will use them to perform a loose matching with the products sold during the past and somehow exhibiting the same tags.

Thus, tagging time-series is the answer provided by Lokad in order to produce statistical forecasts with little or no data.

We provide a Forecasting API that lets client applications (either provided by Lokad or by other people) upload their data and download their forecasts.

The current Forecasting API has been virtually left untouched since the Lokad launch early 2007, but we are currently developing the Forecasting API v2 and we are planning for a release late November.

Note: The Forecasting API v1 will be maintained, the v2 will just be available side-by-side next to the v1.

The main limitation of the API v1 is the lack of time-series meta-data. Indeed, so far, Lokad has been providing a pure time-series framework where only list of time-values could be send to Lokad.

As people have been pointing out, this framework does not make possible to add information on top of the time-series.

For example, if you have a call center, and the call center is down for 2h because of a power outage, you want to be able to tell to Lokad: we had zero calls during those 2h because of a power outage, not because nobody called.

Lokad was treating such events as noise - yet, with extra-information, it becomes possible to properly handle events, instead of ignoring them (at best).

For example, for call centers, typical events include marketing operations, such as mail advertising or service outages. For retailers, it would be product promotions or inventory shortage. And more specifically for eCommerce, it would be front page product display and product inclusions in newsletters.

More technically, Forecasting API v2 introduces the notion of events where an event has several properties:

• a date of start
• a duration
• a name

All events having the same name are supposed to reflect the same phenomenon. For example PowerOutage could be used to name all the events related to an actual power outage of the call center.

By analyzing the impact of events on the actual time-series, Lokad will be able to refine further its forecasts.

But this is not all about the API v2, there is more. Next time we will discuss about forecasting time-series when there is no historical data. Stay tuned.

Our Safety Stock Calculator v1.8 has been released. This version supports OpenERP (previously named TinyERP). This version also comes a with slightly more tolerant behavior when importing data from Excel spreadsheets.

What do reCAPTCHA, Akismet and Lokad have in common?

Well, they are all application blocks leveraging their respective communities to better fulfill their goals.

At Lokad, we believe (like many others actually) that the future of enterprise software, such as ERP or CRM, will rely on Service-oriented Architecture (SOA is short) where each component of the system is largely decoupled from the other components, and eventually provided by independent software vendors.

Considering our initial question, let's note that

• Akismet collects blog comments from a crowd of blogs in order to better filter out the blog spam.
• reCAPTCHA (*) provides an anti-botnet filtering system to distinguish real human users from machines on the web.
• Lokad collects demand data from a crowd of companies in order to improve the overall forecast accuracy.

A modular approach gives much more flexibility to the enterprise to design an IT system that really fit its needs (rather than the other way around). Modularity also reduces the risks of being dragged down because one piece of system is completely obsolete due to lack of investment of one particular software vendor.

Yet another type of benefits brought by specialized actors (think Akismet for blog spam filtering) is that it suddenly becomes possible to leverage the community to deliver smarter behaviors: Akismet is using the information obtained on each blog to improve its spam filtering on all the other blogs.

Today, it seems like that the first wave of crowd-enabled enterprise components was mostly oriented toward security tasks. The raise of security standards such as OpenId are likely to push even further this componentization of security blocks within enterprise software.

Yet, we believe that the second wave of crowd-enabled components will be oriented toward business analytics, ranging from intellectual property management, customer behavior analysis to operations research. Obviously, we want Lokad to be a leading player in this second wave. :-)

(*) Due to a botnet attack on our forums last week, we have upgraded the forum captcha toward reCAPTCHA. The amount of non-human registrations has dropped from hundreds per day to zero.

We are often asked is if Lokad supports seasonality in its forecasting technology. Indeed, neither our add-ons nor the web application provide settings for seasonality.

Our answer to this question is twofold: yes, Lokad handles seasonality but no, there is no settings to tweak seasonality.

Indeed, seasonality or rather seasonalities - because beside yearly patterns, weekly and daily patterns should be taken into account as well - are natively handled by Lokad.

Thus, there is no need to tell Lokad about it because such types of frequent patterns are always explored and evaluated, and eventually rejected if data do not exhibit the seasonal patterns.

Our goal is to provide best possible forecasts right out of the box, batteries included, and not asking users to partially address forecasting questions for us.

The video produced by Kirix about Lokad was a great source of inspiration for us. We realized that videos were a pretty efficient way to communicate on software. Thus, we decided to produce a couple of video tutorials for Lokad.

Our first tutorial is about Lokad Safety Stock Calculator. Check out how to start optimizing your inventory with Lokad within minutes.

(English subtitles are available, just click the CC button)

In this video, you will learn how get started with Lokad Safety Stock Calculator, how to import your sales data and how to generate your first report. We will also explain how the report works and what are the key figures to look at.

You can also download the Windows Media Player file of the video. Special thanks to Rex Teodosio for helping us producing this video.

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.

Lokad Safety Stock Calculator v1.6 has been released. This version includes a couple of important bugfixes. In particular, this version should be more reliable on large datasets. We have improved the handling of network timeouts. An issue has also been fixed with reorder points that were incorrectly set to zero in specific situations.

Concerning the improvements, the version 1.6 automatically saves the report at the start and at the end of the full refresh process. Thus, if Windows gets restarted (say because of an automated security update), the newly refreshed report does not get lost in the process.

We have also fixed a bug in the Check for Updates operation. The auto-update operation was failing if the MSI file had been renamed before launching the installation. If the auto-update fails, then just uninstall and reinstall.

Lately a couple of customers have been asking whether Lokad was keeping track of its past forecast errors in order to improve its future forecasts.

The answer is simple: yes, we do, but there are more than that. In particular, we do not wait for

• the forecasts to be requested,
• the course of events to happen,
• the historical data to be updated,

to finally compare our past forecasts with what really happened. Indeed, such an approach would be way too slow and inefficient.

Instead, we are using cross-validation methods adapted for the purpose of time-series forecasting.The process is more simple than it sounds, let's start with an example.

Let assume that we have a single time-series worth 1 year of weekly sales data (i.e 52 points). We want to produce 4-weeks sales forecasts - but we also want to estimate the forecasting error.

• take the N first points (with N = 10 initially).
• create a forecasting model based on those N points.
• create a 4-weeks ahead forecast based on this model.
• compare the forecast with the complete series.
• increment N of 1 point (i.e. 1 week).
• repeat.

With cross-validation, we can accurately estimate the expected forecast error of a forecasting model. In particular, if you have two different models, cross-validation can help you choosing the best one (*). Cross-validation can also be used to adjust model parameters - in order to find the parameters that best fit the data.

The Lokad team continuously monitors accuracy on delivered forecasts with such cross-validation methods and keeps working on more accurate forecasting models. Thus, we do keep track of our forecast errors, but without waiting for them to happen.

(*) If you try too many models, then you are likely to end-up with overfitting issues, but this problem is beyond the scope of this post.

Forecasting is important for many industries, but it is critical for the call center industry. Indeed. too much staff and the expenses get out of control. Too few staff and your customers are driven nuts by the long waiting queues.

Call Center Calculator (L3C) is a windows reporting application targeting call center managers to help them optimizing their call centers. The two main features of L3C are call volume forecasts (through Lokad) and staff level optimization (through Erlang C).

In this V1, L3C does not natively support yet many 3^rd party applications for call activity logs retrieval. Yet, we provide an Excel import format (because many call center applications support exporting data toward Excel) and a dedicated SQL query editor if you want to directly import data from a database.

The V1 does not handle events (typically marketing events), yet it is possible to manually tweak the staff level suggestions. This feature will be considered for later versions.

Don't hesitate to tell us what you think, what would be the most needed features and/or the most important 3^rd party applications that we need to support. We do our best to address all customer requests.

Lokad Safety Stock Calculator v1.5 has been released. This version now bring sales forecasting to Sage Line 50, a very popular accounting package in the UK. Also, thanks to Crimzone folks, ADempiere under PostgreSQL is now supported as well.

Then, the version 1.5 comes with several small improvements in case of inconsistent input data. Granted, when data is imported from an ERP, stock levels are usually numbers, but we did found out it can be otherwise in some situations.

Indeed, when data is imported from an Excel spreadsheet there is a lot of room for small data errors. In such a situations, the previous version of LSSC was just failing at importing the data. The version 1.5 should be more tolerant when small errors are encountered.

Reminder: You can update through Help » Check for Updates within LSSC.

We have just published public phone numbers for USA and France. Granted, telephone isn't new or even high-tech and there was actually no good reason for Lokad not to support customer phone calls right from the start. Yet, better late than never.

We are currently relying on a small call center setup based on Skype and PrettyMay. It might not be suited for large companies, but if you don't to need to handle more than 30 concurrent calls, then this is definitely a nice solution.