Developing Starbucks Mobile Order & Pay Algorithm Using ...

Developing Starbucks Mobile Order & Pay Algorithm Using Queueing Theory

Tae-Eun Kwak, Tea Mijatovic, Amber Sun, Ryann Ulrich, Teanna Waltenburg

Project Introduction

My Starbucks Rewards Mobile Order & Pay (MOP) feature enables customers to bypass the line by placing an order shortly before arriving in store.

Project Deliverables

Deliver an algorithm that more accurately estimates MOP order fill time, the time between when an order is placed and completed by considering:

Order complexity Number of items per transaction Staffing levels Arrival rate Excel based algorithm

Use Queuing Toolpak 4.0 Add-In

Model Element 1: Service Time

Objective

Determine data-driven service time for each product offered in the MOP feature

Service time is the time it takes to prepare an item (excluding time in queue)

Process

Data Collection

18 different days 10 different stores

5 Rapid Test Store (RTS) observations 5 mocked store observations in the Innovation Lab 22 hours and 35 minutes 1156 data points collected

Current State Opportunity

Arrival rate based on transactions per labor hour (TPLH)

Consider items per labor hour (IPLH)

Assumes all partners are assisting in production of orders

Only consider partners contributing to the production line

Aggregates all product types into one queue

Separate queues for various for product types

Fails to adjust to exception cases (e.g. coffee travelers, large orders)

Create a dynamic model that accounts for individual service times

Customer dissatisfaction due to unrealistic order fill time

Increase MOP accuracy to create a positive customer experience

Low accuracy

Figure 1: service times (in minutes) measured for various product types

Beverage Sequencing in Production

A partner's ability to sequence beverages has a significant affect on an item's total time in system. To incorporate this into our model, we looked at consecutive items where the second item's start time was earlier than the first item's completion time. This overlap time was on average 55 seconds.

We assumed that half of this time (27.5 seconds) would contribute to the service time of each of the two items. We then subtracted 27.5 seconds from the service time for each product from our recorded data.

These screenshots show the nondynamic nature of the current MOP algorithm.

Model Element 2: Number of Servers

Objective

To obtain the number of servers (partners) contributing to production at each station

Process

Station Classification-- possible partner responsibilities

Espresso / Cold Beverage / Brewed / Hot Tea / Prepared Food / Bakery / Packaged Food

Brewed / Hot Tea / Prepared Food / Bakery / Packaged Food Brewed / Hot Tea / Bakery / Packaged Food Espresso / Cold Beverage Prepared Food Cold Beverage Espresso Other (customer support, drive-thru register, drive-thru order,

caf? point of sale, line concierge)

Playbook

Playbook is Starbucks' staffing tool for labor deployment. Using store number, month, date, and time, the number of servers and store type are pulled from historical data. The playbook then uses these values to report what stations are being utilized.

Flexed Servers

As a part of playbook, all partners not only have a primary routine but also a secondary routine that allows them to flex into assisting another position. If a station is over-utilized, meaning arrival rate > service rate * number of servers, then the model moves flexible partners to that station. A flexible partner is one that is categorized as "Other" and can therefore be easily moved from their primary routine into another role.

Figure 2: Green represents partners contributing to production

As shown in Figure 2, the current model assumes all four partners are contributing to production. While according to playbook staffing, only two contribute. Additionally, in this scenario one partner may flex in to support an over-utilized station if necessary.

Model Element 3: Arrival Rate

Objective

Determine arrival rate based on historical data for each product type Arrival Rate: number of items ordered per half hour

Process

Historical Data Aggregation Alternatives

To address concerns with app maintenance and data storage, we created two models. One model contained the most detailed level of historical data, while the other aggregated insignificant factors in order to condense data. These factor groupings included:

Store: individual / volume segments Month: individual / quarterly Day of Week: individual / weekday and weekend

Analysis of Aggregation Alternatives

We tested our null hypothesis that the aggregation of factors has an insignificant impact, using seven random stores from each of the four volume segments, totaling 28 stores. Exploratory analysis showed what data segments followed the same pattern, indicating that the variance between arrival rates was possibly insignificant and may be aggregated.

Figure 3: Arrival rates per half-hour for months in the same season

These graphs revealed which factor aggregations to explore using an analysis of variance.

Figure 4: ANOVA tables for potential insignificant aggregations

Results

Our results showed that combinations of months is the only factor aggregation that is insignificant. Months were aggregated as shown below. This reduces our data by over 50 percent.

January / February March / April / May June / July / August September / October November / December

Final Modifications

Time to Notice Sticker -- 1.1 minute

The average time for a partner to notice an MOP order has arrived through the sticker printer.

Queue Capacity -- arrival rate * 6.1 minutes +

MOP orders in past X minutes This helps remove the steady state issues of the Queueing Toolpak 4.0. 6.1 minutes was the maximum possible time in system from our data collected.

Window Constant -- 1 minute for 1-2 items, 2 for 3+

Creates a window output by adding and subtracting the window constant to the max time in system output.

Errors

Missing data -- use max service time over all stations + average queue time (found from data collection to be 0.78 minutes)

Absolute minimum -- one minute Absolute maximum -- sum total station service

times + constants (1.1 + 6.1 + 2)

Model Testing

Objective

To determine which model version is most accurate by using the innovation lab, a mock store setup, to collect data as the basis of values for testing

Figure 5: Average percent error of each model compared to actual time recorded from innovation lab. Overall model 1 and 2 have 4 times less error than the current model.

*Model 1 is version with full data, model 2 is version with aggregated data

New Model Logic -- Functional Diagram

Final Results

Figure 6: Logic behind new excel-based model

Model Recommended The final model recommended after model testing is model version 2, with the aggregated data.

New Features

Aggregated historical labor data assigns number of partners Uses playbook to:

Find number of partners contributing to production Allow partners to flex roles when needed Aggregated historical data determines arrival rate per unit type (IPLH) Separated queues for each partner's station responsibilities Uses service rates for individual items Considers order size and complexity

Future Maintenance

Update historical data (for new stores and inaccurate data) Input service times for new items

Future Suggestions

Implement Andons for MOP arrivals (to reduce time to notice sticker)

Figure 7: Relative percent accuracy between current model (left) and new model version 2 (right). According to the model testing, the current model output wait time interval captures the actual wait time 20% of the time, while the new model captures the actual wait time 65% of the time.

 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download