Partners » Here
Case study: forecasting for scheduling software
By Joannès Vermorel, November 2007Summary: Scheduloo (fictitious scheduling software company) adds staff level optimization through forecasting to its current application.
Target audience: this scenario is intended for executive or developers who work in software companies (or IT departments) in charge of a staff management application.
Introduction
Scheduloo (a fictitious company) is delivering a staff management application typically targeting Point of Sales (POS). The application is sold as SaaS and hosted on Scheduloo.com. Staff managers are using Scheduloo to schedule the working hours of their employees. The employees can connect to Scheduloo as a regular web application to check out their personal work schedule.
The two main benefits of Scheduloo are first to
increase the manager's productivity while designing a schedule for each employee; second, to
ease the communication with the employees, since they can check their own work schedule directly on the web.
As a third major benefit, Scheduloo would like now to help the staff managers to
optimize their staff levels to match exactly the customer demand. Too much staff, and money gets wasted paying idle employees. Too few staff, and the customer satisfaction drop.
The goal of Scheduloo is now to add a new feature that would deliver staff level suggestions to managers. Indeed, the stronger the pain they solve for their customers, the more they can charge for the license.
Getting staff forecasts
Varying staffing level is the consequence of the varying customer demand. In theory,
demand forecasting does not strictly equate sales forecasting]. But in practice, when it comes to retail, sales are often a
fairly good approximation of customer demand.
Warning (tricky issue): also it makes sense to forecast future sales based on historical sales, it does NOT make sense to forecast future staff levels based on past staff levels. Staff level must be seen as an actionable variable that is actively chosen.
Depending on the estimated amount of sales, the staff manager needs to decide the corresponding appropriate staff levels. In practice,
staff managers use rules of thumb such as "if we do more than 100 then we need a third person". Thus, if the total (aggregated) sales are forecasted, the staff manager can use this information to choose the corresponding staff levels.
In practice, choosing the
right amount of staff, once on the future demand has been estimated, is quite a repetitive operation. Thus, there is a significant productivity gain for the staff manager if
sales forecasts are directly converted into staffing forecasts by Scheduloo itself. A tractable approach is to let the manager define his own
sales2staff mapping through a simple rule-based approach (from a theoretical viewpoint, it's nothing more than a
simple function): a list of rules
if SALES > foo then STAFF = bar.
Design of a solution
At this point, the staff optimization feature includes a few pieces:
- an adapter to retrieve the sales data from a POS application.
- a forecasting toolbox that produce the sales forecasts.
- a mapping utility to convert total sales into staff levels.
- a reporting interface to display the suggested staff levels.
Naturally, we suggest to use Lokad to perform the forecasts. In that case, the new components in the Scheduloo system looks like:
The sales data are first retrieved by Scheduloo from the POS (Point of Sale). The aggregated sales are then uploaded to Lokad. The forecasts are downloaded from Lokad and then converted into staffing forecasts by the
sales2staff utility. Finally, a reporting UI display the results to the staff manager.
How much does it costs?
A staff optimization features has multiple costs:
The two first costs are mostly beyond the scope of this document, since they mostly depend on business perspectives and design extensibility of Scheduloo. Yet, it should be noted that Lokad provides some
extensive materials to get started with its technology, as well as several
open source products that can be used as application examples.
(The section below is using the pricing as published on 2007-11-05, please always refer to the pricing page to be sure to get up-to-date information)Lokad charges per-forecasting task. Since, the concept of
forecasting task is not exactly obvious, we are going to spend a few lines on that concept. Lokad handles basically two types of objects: the
time-series and the
forecasting tasks. The time-series are lists of time-value pairs, and contain the historical data of our customers.
A forecasting task is always associated to a time-series and defines the type of forecasts to be produced. For example, a task can indicate that the forecasts must follow a weekly aggregation: each upcoming week gets its own forecasted value.
CAUTION: When we say a
weekly forecast, we are referring to the
level of aggregation, NOT the frequency of the actual forecast computations. For example, let us consider a Lokad customer having a single monthly forecasting task (it costs 1.35 USD / month). This customer can update his data and download his forecasts as much as he wants; everyday if he wish to.
There is no extra charge: his Lokad subscription does not cost him more than 1.35 USD / month. BUT, each time, the customer gets a 1-month forecast. If he wants a sales forecasts just for next week (as opposed to next month), he will need to define
weekly forecasting task.
The Lokad pricing has been designed in such a way that the average task price quickly decreases as the number of tasks increase. For example, if Scheduloo needs to get 1000 hourly forecasts for 1000 staff managers: it costs 1.35 USD / month / manager. If Scheduloo increases its customers base and now requires 10.000 hourly forecasts for 10.000 managers: the cost decreases to 0.63 USD / month / manager.
No need to say that Scheduloo can charge much more than 1.35 USD / month to a manager to gets his staff optimization done.