About this blog

Lokad staff posts here tips, news and tutorial either related to Lokad or related to business forecasting in general.

Check our archives for a selection of posts to help your business with insights about forecasting.

Entries in history (4)

Wednesday
Oct282009

Roadmap for 2010

Compass illustrationThe 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.

Tuesday
Oct272009

Follow us on Twitter

Twitter Logo

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

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

Monday
Aug312009

New team member, Dario Solera

We started in 2007 as a tiny company. We are still small but we are growing fast. Yet, when it comes to statistical forecasting, more people does not equate better forecasts. This is why we focus on top notch profiles who have the potential to create the next generation of forecasting tools.

This week, we are very proud to announce that Dario Solera is joining the team. Dario Solera graduated from the prestigious Politecnico di Milano. While being a student, he created ScrewTurn Wiki, an impressive open source project that got a significant momentum on its own.

Interview with Dario Solera, Developer at Lokad

Q: Why did you start working in software? Good question, hard answer. I'd guess many people have made-up an answer for this one. In high school I attended a mechanics-oriented course and in the latest two years of it I started getting more and more interested in computers and especially CAD software and 3D design. The interest in computers caused me to also want to program them and then naturally led to my university studies in Computer Science Engineering at the Politecnico di Milano.

Q: What did you do before joining Lokad? I worked for an Italian engineering company. The goal was to design a web-based system for acquiring, collecting and analyzing data generated by large fleet of vehicles. Server-side is based on ASP.NET/C# and SQL Server, while data are acquired by an on-board device built around a Microchip PIC micro-controller that interfaces directly with the Electronic Control Unit of the vehicle. It's been a very challenging work mainly because of the recurring trade-offs between application performance and operation costs, especially due to the potentially enormous amounts of data it can store and process.

Q: You have also created a community project named ScrewTurn Wiki that has now become quite popular. How did it start? I was still attending university (early 2006) and I needed a simple web application that worked like a CMS to publish some stuff on the web. For the sake of learning a new framework (ASP.NET) I decided to write my own and it soon became decent enough to be released to the public. In the old days of version 1.0 the users were not many, probably a few dozens at best, but I kept working on it, releasing version 2.0 a few months later. STW now counts several hundreds users and version 3.0 is on the way.

Q: ScrewTurn Wiki has been awarded $5000 as best .NET open source project by Jeff Atwood. In your opinion what were the key factors that lead to this success? I'm still not sure, but I think that STW was something big enough and working well enough to be noticed by a sufficiently large number of users and developers. Wikis were and are being used extensively by teams of software developers and are now even entering the less-techy enterprise world of non-developers. STW is probably one of the first choices in the .NET world because there are not so many competitors in the same price range (free). The cash grant that Jeff decided to give us was really welcome, yet has been initially of little practical help for the project. I think Jon Galloway, a friend of Jeff, was right when he warned Jeff that open-source projects run on time, not money. In the end, I used the money to "hire myself" for several days of full-time work on STW. They helped a lot.

Q: What are the aspects that are looking the most interesting in your upcoming works at Lokad? Working on Windows Azure is probably the most interesting part: I believe that the cloud computing race has finally began and I want to be part of it. On a broader view, I think that working on large amounts of data is still a challenge and I can learn a lot while working at Lokad. Also, I never had the opportunity to work on so many math-focused algorithms, and this is another intriguing aspect of the work.

Monday
Mar022009

Flat forecasts

Statistical forecasting is a counter-intuitive science. This was already said in the past, but we are going to emphasize again this point.

Frequently, we get people asking for support because they have just pushed some data to Lokad, and the forecasts they obtain are flat. In other words, the forecasted values are constant for all steps ahead. Ex: constant sales values for the next 6 months, if we are considering 6-month ahead monthly sales forecasts.

It's perfectly clear though that there is not-chance for business sales to be perfectly flat for the next 6 months, so why Lokad keeps producing such meaningless results?

Well, we know for sure that business is going to change (at least a little) during the next six months. No question about that. Yet, the problem is: how can we produce a forecast as close as possible to those future changes? If we take the statistical road, then we need a statistical model to the forecasts.

The problem is that we need a good forecasting model; and the cardinal rule of statistical forecasting is that the more complex the model, the more data is needed for the model to be reliable. Models producing distinct forecasts for each step ahead are definitively more complex than the ones producing the same value for all steps ahead.

The other way around, we can also say that those more complex models are also less reliable on limited datasets which means that using them is very likely to decrease the overall forecasting accuracy in certain situations.

Back to the situation where people complain about flat forecasts, what is usually happening is simply that the data that has just been uploaded is either very short (like only 3 months of monthly history) or very sparse (like an eCommerce with only a handful sales for each product). In those situations, Lokad frequently goes for flat forecasts.

It's not a bug, it's an accuracy-improvement feature.