Roadmap for 2010

Published on by Joannes Vermorel.

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.

Categories: business, community, insights, roadmap, subscriptions Tags: history insights roadmap No Comments

Follow us on Twitter

Published on by Joannes Vermorel.

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.

Categories: community, history Tags: history team undefined No Comments

Modeling varying lead time

Published on by Joannes Vermorel.

Yesterday, we discussed why lead times were varying in the first place. Let's go further and see how varying lead times impact safety stock calculations.

Schema of a lead time distribution

Let's start with qualitative insights of a lead time distribution. For the sake of simplicity, we are considering working days here to avoid week-end artifacts.

  1. The lead time distribution starts with a gap (illustrated by Point 1) that illustrates the minimal amount of time needed to perform shipping and transport.
  2. Then, there is the lead time mode which corresponds to the average shipping and transport time when the product happens to be available at hand in the supplier inventory. This mode is located at Point 2.
  3. If replenishment takes longer, it's because the supplier has been encountering a shortage. As illustrated by Point 3, the lead time distribution is rather flat, and reflects the lead time mode of the supplier itself, that is to say the amount of time needed by the supplier to replenish its own inventory.
  4. Finally, there are rare situations where replenishment takes even longer (Point 4). This situation happens if both the supplier and the supplier of the supplier get a shortage of their own at the same time; or if there are disruptions at the producer level.

The safety stock model model proposed in our sample Excel spreadsheet does not take into account varying lead time. Yet, it happens that this formula can be adjusted in a simple way to take lead time variations into account.

If we assume supplier shortages to be independent for the ones of the retailer being replenished then, lead time should be adjusted to match the desired service level. Obviously, if the supplier supplies only one company, the retailer itself, this assumption does not make much sense; but it's well adapted to the frequent situation where there are many retailers passing order to a larger wholesaler.

Visually, as illustrated in the schema here above, if the desired service level is at 70%, then the surface of the area colored in orange must represent 70% of the total area under the curve; that way the lead time ends up matching the desired service level.

Looking at the schema, it is clear that the higher the service level, the larger the corresponding lead time which is a rather reasonable behavior.

In order words, instead of handling the full complexity of the lead time distribution, we propose a mathematical trick where a single lead time quantile that matches the service level is used. This single value reflects the amount of uncertainties undergone by the retailer to ensure a certain level of service to its own customers.

Percentile formula in Microsoft Excel

The good news is that Microsoft Excel does natively support quantile calculations through the PERCENTILE function. Thus, you can list all the observed lead times in an single Excel column and then apply the PERCENTILE function, the first argument being your list of observations, the second argument being the service level percentage expressed as a value between 0 and 1 (ex: 0.30 represents 30%).

Once you have computed this lead time quantile, you can inject the value as such into the Safety Stock Calculator. It will directly reflect the lead time variations into the reorder point calculation.

Schema of a lead time distribution, higher service level

This analysis initiated with real-world eCommerce observations is leading us to interesting conclusions: in order to ensure high service levels, someone has to the take the financial hit as far inventory levels are concerned.

In our first schema, the orange area was illustrating a lead time associated to a 70% service level (numbers here are made up, it's just for the sake of the explanation), but what happens if the retailer want to increase its service level?

Well, there is a threshold effect matching the service level of the supplier itself. In the present case, we have a supplier with a service level at 75%. This threshold is caused by lead time distribution itself that comes with a strong statistical mode.

If the retailer wants service levels below 75% (i.e. below the supplier's own service level), then the matching lead times are small. Ex: 3 days for the real world example considered in the previous post.

On the contrary, if the retailer wants service levels above 75%, then matching lead times are inflating very fast. This behavior is visually illustrated with the second schema displaying a 90% service level. As you can see, the duration of the matching lead time get more than doubled, which mechanically more or less double the amount of inventory as well.

As we were saying initially, high service levels - which increase sales along with customer satisfaction - do not come for free. In the end, a company in the chain ends up paying for that. Retailers need to be careful concerning service levels offered by their own suppliers, because the threshold effect that we just outlined radically impacts the amount of inventory needed to satisfy its own customers.

Categories: business, insights, safety stock, supply chain Tags: formula lead time model safety stock supply chain 3 Comments

Understanding varying lead time

Published on by Joannes Vermorel.

Recently, quite a few questions have been raised about varying lead times, and how it impacts safety stock calculations. Indeed, Salescast associates a static lead time to each SKU.

It's clear though that lead times aren't deterministic and that there is some uncertainties involved when a reorder is send to a supplier. Thus, we have been - rightfully - asked for a safety stock formula taking into account the lead time uncertainty as well as the future demand uncertainty.

Yet, before jumping straight into the equations, every quantitative business analysis must start with some data at hand to better understand what's going on. Fortunately, Anthony Holloway (from k9cuisine, Dog Food & Dog Treats) was kind enough to hand us over a small dataset representing a series of observed lead times.

Lead time distribution with calendar days

As expected, lead times are varying. Yet, it can already be noted that it's clearly not a normal distribution (it's way too asymmetric for that). Thus, the uncertainty behind the demand forecast and the uncertainty behind the lead time cannot be handled with a symmetric formula.

Our experience at Lokad is telling us that - on average - there is not so much variations in lead time due to shipping and transport. Those two operations tend to be fairly deterministic.

Usually, the root cause of lead time variation is supplier-side shortage. Yet, with the graph here above, the shortage pattern isn't that obvious.

Yet, we started thinking more about this graph, we noticed a suspicious pattern: the 2 lead time peaks are at respectively 3 and 5 days. This looks an awful lot like a week-end effect to us. In other words, shipping & transport take usually 3 working days that is to say 3 or 5 calendar days depending on an eventual week-end.

Discussing more with the retailer who had produced the dataset, we got the confirmation that, indeed, lead times were expressed as plain calendar days.

Lead time distribution with working days

Thus, we decided to apply a working days correction to this graph. The green graph here above displays the very same lead time distribution as the previous blue one, but lead times are now expressed as working days instead.

With the new corrected graph, a much sharper pattern emerges. We have a clear two phases process:

  • the supplier has the product available at hand, in which case, lead times takes 3 days on average, with a minor +1/-1 variation.
  • the supplier does not have the product at hand, in which case. lead times takes a random amount of time, with a rather flat distribution reflecting the supplier-side (longer) lead time.

Furthermore, we can even easily evaluate the supplier-side service level, that is to say the probability for the supplier not hitting a shortage when a reorder is made. In the present case, if we consider 5 days as being the shortage indicator threshold, then we end up with a service level at 75% which is within the usual range for retail wholesalers.

A key question remains: how should we adjust the Salescast settings to take into account varying lead times? The question will be addressed in the next post. Stay tuned.

Categories: insights, supply chain Tags: formula lead time model supply chain 2 Comments

What's your statistical model?

Published on by Joannes Vermorel.

We have already disclosed a few insights about what's being used at Lokad. Yet, a frequent support request remains what's your model, precisely?

We‘re looking through various forecasting statistical packages with the intent on selecting one at some point in the near future. One thing I find lacking in Lokad is to see which statistical model was used. I understand that the selection of which model is used is a trade secret, but I would like to verify the final selection, in the trial that is, with our in-house mathematician before we trust you with our actual forecasts. Most software vendors operating in this space provide the model selected. Is it possible to get that result with Lokad?

Well, unfortunately, the correct answer is that Lokad isn't a statistical package. In particular, we don't deliver models, we deliver forecasts.

The whole architecture of Lokad has been designed around this very assumption, which unfortunately is very ill-suited to deliver any information about our models.

Our forecast flow, which grabs input data and outputs forecasts, is:

  • vastly more complex compared to models shipped with statistical packages. Forecasts cannot be associated with well-known models.
  • tailored for distributed computing in the clouds, thus, the design feels very alien when compared to classic toolkits.
  • subject to ongoing changes, as we are carrying experiments on a daily basis with agile deployment strategies.

But this design has very specific benefits too:

  • no need to tune complex forecasting parameters.
  • no need to constantly watch your parameters, we monitor the results.
  • scales up as much as you need to, up to millions of forecasts.
  • handles complex patterns that are way beyond classical toolkits.

Then, we don't ask anyone to take our results for granted. Just go and see for yourself, our trial is free for 30 days.

Categories: forecasting, insights Tags: forecasting technology 2 Comments

What's wrong with promotion forecasts?

Published on by Joannes Vermorel.

It has been a little while since we posted some technical content about our forecasting methods. Let's discuss further the case of promotion forecasts.

Promotion forecasts are especially interesting for two reasons:

  • promotions represent a heavy part of the business for many companies.
  • forecasts are likely to end up really wrong when ad-hoc methods are used.

In order to clarify the traps looming behind promotion forecasts, let's have a look at the following schema. The two black curves represent fictitious product sales - illustrating typical consumer response to a promotion.

Model for retail promotion forecasts

Disclaimer: Those behaviors have been measured on Lokad databases. Yet, market responses vary a lot from one promotion to the next and from one business to the next. Our purpose here is not to provide accurate quantitative models, but rather to focus on what we believe to be key insights for promotion forecasts.

1. Primary promotion impact

The most important effect of a promotion is usually a large sales increase of the promoted product for the duration of the operation. This effect is illustrated with (1) in our schema.

Guessing that the sales are likely to increase is trivial, yet precisely estimating the impact of the promotion - that is to say the extra sales generated by the promotion itself - is a complicated process. Lokad is using its tags+events framework to do this.

It can be noted that classical forecasting methods such as exponential smoothing are completely missing promotional patterns.

2. Demand drop due to market saturation

The second effect of a promotion - which is too frequently overlooked - is the demand drop that comes just after the end of the promotion. See point (2) on the schema.

Indeed, by observing thousands of promotional operations, we have found that frequently, just after the end of a promotion, sales levels are dropping below the initial pre-promotion sales levels.

This drop reflects the temporary market saturation caused by the promotion itself. Basically, people who would have bought the product anyway have hurried their decision, resulting in fewer sales when the promotion stops.

When this drop is overlooked AND combined with a naive forecasting method, the combination can lead to extremely poor inventory management and overstocks. Indeed, the delayed behavior the exponential smoothing is likely to suggest inventory replenishments precisely when the demand is going to drop.

3. Mechanical echo due to customer synchronization

The third pattern comes from the synchronization effect of the promotion on customer replenishments. This point is illustrated with (3) on the schema.

All products (consumable or not) tend to have a lifecycle of their own. The promotion is synchronizing - to some extent - consumption patterns of customers. As a result, after the initial shock (the promotion itself), there is likely to be decreasing echos in customer demand.

In our measurement, it appears that most of the time only the first echo can be measured with enough confidence to be of any use for forecasting purposes. Subsequent echos do exist but they are too diffuse to be used to refine forecasts.

Again, if the demand bounce (3) happens right after the demand drop (2), then the exponential smoothing model is likely to cause frequent inventory shortage, because it completely fails to anticipate the bounce.

4. Demand drift due to market evolution

The fourth effect is the demand drift caused by the promotion. This effect is illustrated by point (4) in the schema.

A promotion acts as a market perturbation, and the base sales level is likely to be different after the promotion; hopefully higher, but our measures shows that the opposite, i.e. lower sales, also happens, yet with a lower frequency.

In our experience, establishing a quantitative forecast for the drift is really hard. Yet, the drift can be taken into account in order to speed-up forecasts adjustments after the end of the promotion.

5. Sales cannibalization

Sales cannibalization is typically the second major effect of a promotion in terms of absolute sales volumes. Cannibalized products end up with reduced sales during the promotion as illustrated by (5) on the schema.

Yet cannibalizations are harder to model, because the effect can be diffuse and potentially impact a wide range of unrelated products. Indeed, depending on the situation, some customers may have a fixed threshold for their spending. The immediate consequence of the threshold is that the opportunity spending offered by the promotion ends up compensated by restrictions on somewhat unrelated products.

Lokad is trying hard to provide fine grained promotion forecasts, taking into account all the effects that we can measure. If you decide to go for in-house forecasts (which we don't recommend, but well), we suggest to make sure that neither (2) nor (5) gets overlooked.

Categories: accuracy, forecasting, insights, time series Tags: forecasting issue practices promotion 2 Comments

Oct 1st, inauguration party of new Lokad offices

Published on by Joannes Vermorel.

For 14 months, we have been located at the startup incubator of Telecom ParisTech. Yet, at 6 people in 12m2, it was feeling a bit tight from time to time.

That's why starting from July 1st, we have moved to Place d'Italie in Paris. Our new location is much bigger, and now, much nicer too. Yet, when we arrived, it felt as if no renovation had been made for the last 3 decades.

Pictures board for the Lokad renovation works

Thus, we have spend a good part of summer 2009 with our office renovation. We did handle 100% of the renovation works on our own. Lokad is proud to be the only company where construction workers are also knowledgeable about advanced statistics, although, it's not clear how much it helps to become a true plaster master.

Inauguration party at Lokad on Oct 1st, 2009

Yesterday, October 1st, the inauguration party for our newly renovated offices took place. Thanks a lot to all of you who've had to opportunity to come to cheer us.

Categories: community, history Tags: office paris team No Comments