Case Study: Optimizing Order Fulfillment with Simulation

To improve labor productivity and customer satisfaction across Target’s stores, I led the development of a discrete event simulation. The project created a modular, high-fidelity digital twin of in-store operations, helping teams evaluate trade-offs across staffing strategies, order flow policies, and new consumer offerings.

Problem Statement

Several operational challenges highlighted the need for a reusable simulation tool. For instance:

• Labor balancing: Some stores had only one employee for both order picking and packing, raising questions about how to sequence these tasks for maximum productivity without risking late orders.

• Mobile shelf deployment: Leaders needed to understand how equipment like mobile shelves impacted flow efficiency and where it should be prioritized.

• Starbucks pilot: A new service integrating Starbucks orders with Drive Up pickup needed rapid validation to determine feasibility, staffing impact, and customer wait times.

Our simulation provided a safe, fast, and repeatable way to test these operational changes under varied conditions.

Model Design

The DES simulated the lifecycle of a store order, from arrival to handoff:

• Inputs included order data (real or synthetic), worker schedules, task times (e.g., walking time to fridge/freezer), and policies for task prioritization.

• Outputs were timestamped events, which we post-processed into key metrics like average wait time, late orders, and labor utilization.

Architecture and Technical Stack

• SimPy managed second-by-second simulation timing and event orchestration.

• Pydantic validated the input data.

• Each task component was written as its own class (e.g., order drops, employee behavior, task types, customer arrivals) could be flexibly assembled and reused. The core logic was dictated by a "work policy" object that encoded business rules (e.g., “prioritize picking during peak hours and packing during off peak hours”).

Benchmarking and Productionalization

To ensure realism, we benchmarked the simulation’s output against historical data. This required tuning task-time hyperparameters to match known results.

• We used Spark for parallel processing on a Hadoop instance for hyper parameter tuning. 

• Doing the hyper parameter tuning in a programmatic way created a secondary dataset that was incredibly useful for analysis and productionalization of the code.

• From this derived dataset we did an analysis of the input and output characteristics to group stores into cohorts. (A trivial example of this is that smaller stores were well served by using the average task time, but that larger stores needed an additional buffer on average task time.) This meant we could do modeling on 6 groups of sister stores instead of 1800 stores individually.

Cross-Functional Collaboration

I collaborated with both the business process team and the data science team to define use cases, validate assumptions, and ensure alignment with operational goals. I also secured buy-in from stakeholders on both sides, helping bridge the gap between technical experimentation and real-world applicability.

To scale this project, I built and led a team of six data scientists, ensuring consistent coding practices, shared model components, and aligned research questions across team members.

Impact and Outcomes

The proof of concept was successful in:

• Demonstrating labor savings opportunities in the Starbucks Drive Up pilot

• Reducing customer wait times in simulation scenarios

• Creating a flexible tool that could be adapted for other operational questions