Roadmap for 2010

Joannes Vermorel

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.