Performance monitoring interfaces for warehouse operations

A warehouse coordination system performs a simulation of tasks to be performed over a shift for a warehouse process, according to a defined sequence of the tasks and defined resources to be applied to the tasks, and generates simulation output data. The warehouse coordination system stores data that represents the defined sequence of the tasks, data that represents the defined resources to be applied to the tasks, and the simulation output data. The warehouse coordination system receives real-time warehouse data that indicates tasks being performed over the shift. The warehouse coordination system provides data for a performance monitoring interface, and the performance monitoring interface presents, for a plurality of time periods, an amount of tasks that have been predicted to be performed according to the simulation of the tasks, in comparison to an amount of tasks that have been performed according to the real-time warehouse data.

TECHNICAL FIELD

This specification generally relates to a platform that includes integrated planning, simulation, and reporting tools, for coordinating warehouse operations, such as processes for distributing physical items from a warehouse to a store.

BACKGROUND

Warehouse management systems (WMS) can perform a variety of operations to manage the physical distribution of goods in and out of warehouses. For example, a WMS can receive orders to be distributed from a warehouse and can translate those orders into specific warehouse operations, such as selecting particular pallets from locations in the warehouse and loading them onto trucks for distribution. WMS systems have traditionally been designed to focus on processing orders within the warehouse. For example, a WMS may simply identify operations that are needed to fulfill an order and send those out to be performed by the next available resource within the warehouse (e.g., send out instructions to forklift operator).

Simulation modeling platforms have been used to facilitate simulation modeling for various business and industrial processes. Within the simulation platforms, users may develop custom models for discrete elements (e.g., processes and agents), and may define interactions between the elements. By performing simulations, for example, experiments may be conducted to determine how randomness and parameter changes affect model behavior. Simulation results may be analyzed and changes may be made based on the analysis to improve the business and industrial processes.

SUMMARY

This document generally describes computer systems, processes, program products, and devices for providing a platform that includes integrated planning, simulation, and reporting tools, for coordinating warehouse operations among multiple different groups/teams within a warehouse. For example, a warehouse may include multiple different teams who are assigned a specific set of tasks, such as a team receiving inbound shipments (e.g., unloading pallets from trucks arriving at warehouse), another team handling storage and retrieval operations (e.g., moving pallets in and around the warehouse), another team handling sortation operations (e.g., breaking apart goods on pallets and packing pallets using goods from different pallets), and another team performing shipping operations (e.g., assembling and loading outbound pallets onto trucks for distribution to retail stores). For efficiency, workers in a warehouse can be assigned to different teams to distribute the labor and operations that are performed. However, unharmonious workflow between the different teams in the warehouse can create inefficiencies because the operations that are performed among teams within a warehouse are linked to each other. For example, a receiving team working too quickly to unload inbound trucks to a warehouse can create a backlog of pallets in the dock area of the warehouse, which then makes the operations performed by a storage and retrieval team and/or a shipping team less efficient. Similarly, under-utilized labor on the receiving team can degrade the productivity of the storage and retrieval team and/or the sortation team even though those teams may have the capacity to work at a faster pace.

The disclosed technology provides solutions to these problems by generating plans that provide for harmonious coordination among teams within a warehouse that take into account relationships among teams to provide for improved efficiency for the warehouse and its teams as a whole, instead of simply for each team individually. For example, the disclosed technology provides a warehouse operation coordination platform that includes labor and production planning tools for generating and simulating detailed work plans at the team level (e.g., receiving, storage and retrieval, sortation, and shipping), and performance monitoring tools for monitoring various performance metrics (e.g., productivity, throughput, safety, etc.), across multiple teams to provide for a more efficient overall operation with coordination among the multiple teams. For instance, the disclosed technology can generate plans for each team, including the allocation of workers among the teams, that are easy to follow and that provide for synchronization among the multiple teams so that one team is not working too far ahead of or behind of other teams and thus injecting inefficiencies into the system. The end result is a plan that, when followed by each team, provides an efficient and balanced outcome for the warehouse as a whole (e.g., maximize throughput of pallets through warehouse) even though it may require one or more team to work at a pace that is below their maximum output.

The disclosed performance monitoring tools can additionally provide for and facilitate the generation of integrated performance monitoring user interfaces. The performance monitoring interfaces, for example, can integrate plan simulation data, real-time work task data, and observation data, to facilitate collaboration among different teams within a warehouse in order to provide balance and harmony between the teams and to improve overall efficiency under a production plan. The user interface features can include work plan information according to a simulated work plan that team leaders are instructed to follow, along with variances indicating acceptable ranges of actual production output relative to simulated production output. The interface can also provide alerts prompting team leaders for feedback and observations with respect to work tasks being performed by their team, when actual production deviates from planned production. Additionally, the interface can prompt collaborative check-ins among team leaders throughout a work shift, which can facilitate adjustments and modifications to each team's performance during the shift. By providing each operations manager in a warehouse environment with a respective performance monitoring interface that aggregates and simplifies complex data that pertains to their respective team, for example, the operations managers can more effectively focus on their respective objectives, which may be to produce according to the performance goals for their team (instead of always a maximum amount), in order to improve efficiency for the warehouse as a whole.

In some implementations, a method performed by data processing apparatuses includes performing, by a warehouse coordination system, a simulation of tasks to be performed over a shift for a warehouse process, according to a defined sequence of the tasks and defined resources to be applied to the tasks; generating, by the warehouse coordination system, simulation output data based on the simulation of the tasks to be performed; storing, by the warehouse coordination system, data that represents the defined sequence of the tasks to be performed, data that represents the defined resources to be applied to the tasks, and the simulation output data based on the simulation of the tasks to be performed; receiving, by the warehouse coordination system, real-time warehouse data that indicates tasks being performed over the shift for the warehouse process; and providing, by the warehouse coordination system, data for a performance monitoring interface for the warehouse process, wherein the performance monitoring interface presents, for each time period of a plurality of time periods, an amount of tasks that have been predicted to be performed according to the simulation of the tasks, in comparison to an amount of tasks that have been performed according to the real-time warehouse data.

These and other implementations can include any, all, or none of the following features. Performing the simulation of tasks to be performed over the shift for the warehouse process can include modeling the tasks to be performed according to an assigned sequence of tasks over time, using a collection of state variables that represent workers and containers in a warehouse. The real-time warehouse data can include one or more identifiers for a task that has been performed, and a timestamp that indicates a time at which the task has been performed. The performance monitoring interface can include a first graphical indicator that plots, along a time axis, a cumulative amount of tasks that have been predicted to be performed according to the simulation of tasks, and a second graphical indicator that plots, along the time axis, a cumulative amount of tasks that have been performed according to the real-time warehouse data. The first graphical indicator can represent a predetermined variance for the cumulative amount of tasks that have been predicted to be performed according to the simulation of tasks. The performance monitoring interface can present an alert when the amount of tasks that have been performed according to the real-time warehouse data is outside of a predetermined variance for the amount of tasks that have been predicted to be performed according to the simulation of tasks. The performance monitoring interface can provide an input mechanism for providing operator information when the amount of tasks that have been performed according to the real-time warehouse data is outside of the predetermined variance for the amount of tasks that have been predicted to be performed according to the simulation of tasks.

The systems, devices, program products, and processes described throughout this document can, in some instances, provide one or more of the following advantages. Data from warehouse management systems (WMS) and performance tracking systems can be ingested, enhanced, and stored, such that processes for generating work plans can execute without burdening the WMS and performance tracking systems, conserving system resources. A workflow can be provided that deepens understanding of both operations and planning processes, providing transparency to plan details while automating manual data sourcing and input. Feasible and integrated work plans can be efficiently generated. Planning simulation tools can be used to test process improvement and/or physical layout changes in a warehouse before the changes are implemented, facilitating process and layout improvements. Work plans can be based on a low level of available detail to produce a high level of output precision. Work plans for multiple different teams can be coordinated with a shared set of priorities among the teams, increasing production efficiencies throughout a warehouse. Planning processes can be standardized across warehouses that have similar operational structures. A consistent user experience can be delivered through a standardized set of tools, increasing collaboration between teams during a common planning process, and improving in-depth understanding of holistic operations by managers and higher-level leadership.

Other features, aspects and potential advantages will be apparent from the accompanying description and figures.

DETAILED DESCRIPTION

This document describes technology that can coordinate warehouse operations through the use of integrated planning, simulation, and reporting tools. In general, warehouse operations managers (e.g., leaders of various warehouse teams, such as receiving, storage and retrieval, sortation, and shipping teams) may lack specific tools for creating detailed production plans and for monitoring holistic warehouse performance. For example, using manual techniques and/or ad hoc tools, a warehouse operations manager may spend several hours over the course of a shift collecting and organizing data from multiple different sources to create a production plan for their team and track team performance according to the plan. Further, a production plan created for a team through manual data aggregation and production planning techniques may be difficult to coordinate with production plans created for other teams. For example, a receiving team may be responsible for receiving goods delivered to a warehouse (e.g., unloading cartons from a truck), and a storage and retrieval team may be responsible for storing those goods in the warehouse (e.g., delivering cartons to specific warehouse locations). If production plans for the receiving team and the storage and retrieval team are independently created, for example, a production plan for the receiving team may specify that the team is to receive more goods than the storage and retrieval team is capable of storing, resulting in production inefficiencies throughout the warehouse.

The warehouse operation coordination platform described in this document includes labor and production planning tools for generating detailed work plans for warehouses at the team level (e.g., receiving, storage and retrieval, sortation, and shipping), across multiple teams. The platform also includes reporting tools for providing real-time information about work progress with respect to the generated plans, such that work across the various teams can be better coordinated, and production staffing needs can be shifted when appropriate. At a high level, the platform has three main components: a data ingestion component that receives relevant data from warehouse management systems (WMS) and performance tracking systems used to generate the work plans, a plan creation tool through which operation managers can generate and simulate plans for their portion of the warehouse, and a performance monitoring tool that provides work progress information to each of the operation managers to promote collaboration between the teams.

FIG.1Ais a conceptual diagram of an example warehouse environment100, and an example system150for generating warehouse process plans and coordinating warehouse operations, as represented in example stages (A) to (E). Stages (A) to (E) may occur in the illustrated sequence, or they may occur in a sequence that is different than in the illustrated sequence, and/or two or more stages (A) to (E) may be concurrent. In some examples, one or more stages (A) to (E) may be repeated multiple times during a warehouse shift.

The warehouse environment100can be a storage warehouse, a packing warehouse, a retail warehouse, a distribution center, or another sort of warehouse or facility, for example. In the present example, the warehouse environment100includes multiple docks102at which vehicles104(e.g., trucks) can be loaded and/or unloaded with various containers106(e.g., pallets, boxes, etc., containing various goods). The warehouse environment100in the present example also includes a storage area110, which can include various storage racks112which can be arranged in rows and/or columns and configured to store the containers106in different levels. For example, elevators and/or rack conveyor belts may be used to elevate the containers106to different levels and move them to and from desired locations in the storage racks112. Various workers114and equipment116(e.g., forklifts, pallet jacks, automated guided vehicles (AGVs), etc.) can be employed in the warehouse environment100, for example, to perform various warehouse tasks.

In general, workers and equipment may be organized into different teams, each team performing a different sort of task in the warehouse environment. For example, a receiving team120acan include workers114and/or equipment116for performing various receiving tasks, such as unloading containers106from vehicles104. A storage and retrieval team120b, for example, can include workers114and/or equipment116for performing various storage and/or retrieval tasks, such as moving the containers106throughout the warehouse environment100, placing the containers106in the storage racks112, and removing the containers106from the storage racks112. A sortation team120c, for example, can include workers114and/or equipment116for performing various sortation tasks, such as breaking apart containers106of goods and/or repackaging goods into different containers106. A shipping team120d, for example, can include workers114and/or equipment116for performing various shipping tasks, such as loading containers106into outbound vehicles104for transportation to other locations (e.g., warehouses, distribution centers, stores, customer locations, etc.).

In general, each team may include and/or be directed by one or more operations managers that use computer applications running on computing devices to create work plans for their team (e.g., a work plan that specifies work to be performed by the team during a shift), and to monitor the progress of the team according to the work plan (e.g., over the course of the shift). For example, an operations manager of the receiving team120acan use computing device122a, an operations manager of the storage and retrieval team120bcan use computing device122b, an operations manager of the sortation team120ccan use computing device122c, and an operations manager of the shipping team120dcan use computing device122d. Each of the computing devices122a-d, for example, can be various forms of stationary or mobile processing devices including, but not limited to a desktop computer, a laptop computer, a tablet computer, a personal digital assistant (PDA), a smartphone, or other processing devices.

Referring now toFIG.1B, an example shift timeline130is shown for warehouse operations. A warehouse shift, for example, can be a defined time period (e.g., six hours, eight hours, twelve hours, or another suitable time period) over which various teams (e.g., teams120a-d, shown inFIG.1A) perform various operations in a warehouse environment (e.g., warehouse environment100, also shown inFIG.1A). In general, warehouse shifts may be divided into multiple different periods having defined start and end times (e.g., organized around breaks). In the present example, the shift timeline130includes a pre-shift period132during which pre-shift planning routines are performed, and multiple shift periods during which shift operations are performed. A first shift period134a, for example, begins at time point136(e.g., the beginning of the warehouse shift) and ends at time point138(e.g., the start of the first break). A second shift period134b, for example, begins at time point138and ends at time point140(e.g., the start of the second break). A third shift period134c, for example, begins at time point140and ends at time point142(e.g., the end of the warehouse shift).

During the pre-shift period132, for example, operations managers of various teams (e.g., teams120a-d, shown inFIG.1A) can use computing devices (e.g., computing devices122a-d, also shown inFIG.1A) to create work plans for their respective teams for the warehouse shift. In the present example, computing device122acan be used during pre-shift period132ato create a work plan for the receiving team120a, computing device122bcan be used during pre-shift period132bto create a work plan for the storage and retrieval team120b, computing device122ccan be used during pre-shift period132cto create a work plan for the sortation team120c, and computing device122dcan be used during pre-shift period132dto create a work plan for the shipping team120d. During pre-shift period132e, for example, the work plans generated during pre-shift periods132a-dcan be adjusted and aligned by the operations managers of the various different teams120a-d, such that a consensus plan is locked when the shift begins at time point136. Example interfaces for creating work plans are described in further detail below. In some implementations, data corresponding to a work plan for a team may be used as input for creating a work plan for another team. For example, data corresponding to a work plan for the receiving team120acan be used as input for creating a work plan for the storage and retrieval team120b, data corresponding to a work plan for the storage and retrieval team120bcan be used as input for creating a work plan for the sortation team120c, and data corresponding to a work plan for the sortation team120ccan be used as input for creating a work plan for the shipping team120d.

During the warehouse shift (e.g., during an operations monitoring period144aof the first shift period134a, an operations monitoring period144bof the second shift period134b, and an operations monitoring period144cof the third shift period134c), for example, operations performed by various teams (e.g., teams120a-d, shown inFIG.1A) can be monitored. In the present example, real-time data that pertains to operations performed by the receiving team120ain the warehouse environment100(shown inFIG.1A) can be collected (e.g., by data collection devices, such as manual input devices, scanners, cameras, or other suitable devices in the warehouse environment100), and used to determine progress of the receiving team120arelative to its work plan for the shift. Similarly, in the present example, real-time data that pertains to operations performed by each of the storage and retrieval team120b, the sortation team120c, and the shipping team120d, can be collected and used to determine progress of the respective team relative to its corresponding work plan for the shift. In general, information related to progress relative to a work plan can be provided to each of the computing devices122a-d(shown inFIG.1A) for review by operations managers of the respective teams120a-d. For example, computing device122acan be used to present performance monitoring information for the receiving team120a, computing device122bcan be used to present performance monitoring information for the storage and retrieval team120b, computing device122ccan be used to present performance monitoring information for the sortation team120c, and computing device122dcan be used to present performance monitoring information for the shipping team120d. In some implementations, a different interface may be provided for presenting performance monitoring information for each different team. Example interfaces for presenting performance monitoring information are described in further detail below.

During and/or after the warehouse shift, for example, operations managers of various teams (e.g., teams120a-d, shown inFIG.1A) can use computing devices (e.g., computing devices122a-d, also shown inFIG.1A) to provide information regarding tasks being performed by their respective teams, and can adjust team resources (e.g., workers114and/or equipment116, also shown inFIG.1A) based on performance monitoring information presented by the computing devices, such that each of the various teams proceeds according to their respective plan. For example, during check & adjust period146aat the end of the first shift period134a, and during check & adjust period146bat the end of the second shift period134b, an operations manager of the receiving team120a, an operations manager of the storage and retrieval team120b, an operations manager of the sortation team120c, and an operations manager of the shipping team120dcan provide team updates with respect to their various plans using their respective computing devices122a-d, and can compare work progress with respect to their respective work plans. In general, team resources allocated to an overproducing team may be shifted to an underproducing team. For example, at the check & adjust period146a, if the receiving team120ais identified as having overproduced and the storage and retrieval team120bis identified has having underproduced during the first shift period134a, team resources may be shifted from the receiving team120ato the storage and retrieval team120b. In the present example, by re-allocating resources among teams during the shift, the production of each team120a-dcan better align with their respective work plan for the shift, thus improving coordination among the teams and increasing overall production throughout the warehouse environment100. During an end of shift recap period146c, for example, operations managers of the teams120a-dcan use performance monitoring information presented by the computing devices122a-dto evaluate overall performance of the teams with respect to their plans, to identify root causes of problems that may have occurred during the shift, and to potentially improve various warehouse processes.

Referring again toFIG.1A, for example, the system150for generating warehouse process plans and coordinating warehouse operations can include various computing servers160and data sources162. In some examples, the computing servers160can represent various forms of servers, including but not limited to network servers, web servers, application servers, or other suitable computing servers. In some examples, the data sources162can represent databases, file systems, and/or cached data sources. The computing servers160, for example, can access data from the data sources162, can execute software that processes the accessed data, and can provide information based on the accessed data to the computing devices122a-d. Communications between the computing servers160, the computing devices122a-d, and various data collection devices (not shown) in the warehouse environment100, for example, can occur over one or more communication networks (not shown), including a LAN (local area network), a WAN (wide area network), and/or the Internet. In the present example, the computing servers160and the data sources162can be used to implement a warehouse coordination system, which is described in further detail with respect toFIG.2.

Referring now toFIG.2, an example system200for generating warehouse process plans and coordinating warehouse operations is depicted. The system200in the present example includes a warehouse coordination system210that receives data (e.g., using a data collection component) from one or more warehouse management systems220, performance tracking systems230, and configuration systems240. The warehouse management system(s)220, for example, can provide real-time information related to a state of the warehouse environment100(shown inFIG.1A). For example, the warehouse management system(s)220can provide information related to containers of goods that have been received and are waiting to be placed in the storage area110(shown inFIG.1A). As another example, the warehouse management system(s)220can provide information related to requests for goods that are to be picked from the storage area110and that are to be loaded into containers106(shown inFIG.1A) and sent to a retail store. As containers106and/or goods in the warehouse environment100are involved in a warehouse operation (e.g., receipt, transport, put away, pick, sort, repackage, ship, etc.), for example, real-time operation data (e.g., including an operation timestamp and various identifiers related to the operation, such as location, worker, team, equipment, container, and/or goods identifiers), can be collected and stored by the warehouse management system(s)220. The performance tracking system(s)230, for example, can maintain and provide data related to historical performance of various warehouse equipment, workers, and/or teams. For example, the performance tracking system(s)230can provide data that indicates productivity rates (e.g., a number of warehouse operations per time period over a defined time range, such as over a previous week, month, quarter, etc.) of warehouse equipment, workers, and/or teams, such that productivity of current combinations of equipment, workers, and/or teams can be projected over a current shift. The configuration system(s)240, for example, can maintain and provide data related to a configuration (e.g., physical layout, processing capabilities, available equipment, etc.) of the warehouse environment100. Data received from the warehouse management system(s)220, the performance tracking system(s)230, and/or the configuration system(s)240, for example, can be combined and stored in an enhanced warehouse data source250for use by the warehouse coordination system210.

In the present example, the warehouse coordination system210can include and/or communicate with a plan creation interface generator260, a performance monitoring interface generator270, and a warehouse planning simulator280. The plan creation interface generator260, for example, can be used by the warehouse coordination system210to generate respective plan creation interfaces for presentation on each of the computing devices122a-d(shown inFIG.1A) when requested during the pre-shift period132(shown inFIG.1B). The performance monitoring interface generator270, for example, can be used by the warehouse coordination system210to generate respective performance monitoring interfaces for presentation on each of the computing devices122a-dwhen requested during any of the shift periods134a-cand/or during the end of shift recap period146c(shown inFIG.1B). The warehouse planning simulator280, for example, can be used by the warehouse coordination system210(e.g., as part of a plan creation process) to run granular, discrete process simulations for operations to be performed by a team during a shift.

Referring now toFIG.3, a flow diagram of an example technique300for generating warehouse process plans and coordinating warehouse operations is shown. In general, the example technique300includes data collection and visibility operations, planning and simulation operations, and monitoring operations that can be performed by various components of the system200(shown inFIG.2) for generating warehouse process plans and coordinating warehouse operations. In the present example, the example technique300can be performed by the warehouse coordination system210(e.g., also shown inFIG.2), the warehouse management system220(e.g., also shown inFIG.2), the performance tracking system230(e.g., also shown inFIG.2), the configuration system(s)240(e.g., also shown inFIG.2) and a client device302(e.g., similar to any of the computing devices122a-d, shown inFIG.1A).

At350, the warehouse management system220transmits warehouse data, and at352, the warehouse coordination system210receives the warehouse data. Before, after, or concurrently, at354, the performance tracking system230transmits performance data, and at356, the warehouse coordination system210receives the performance data. Optionally, the configuration system(s)240(shown inFIG.2) can transmit configuration data, and the warehouse coordination system210can receive such data. Referring toFIG.1A, for example, during stage (A), the computing server(s)160(e.g., one or more computing servers for implementing components of the system200) can receive warehouse, performance, and/or configuration data170. The data170, for example, can pertain to a current state of the warehouse environment100, historical performance of various warehouse resources (e.g., equipment, workers, and/or teams), and/or a configuration of the warehouse environment and/or resources. Warehouse data received from the warehouse management system220, for example, can include data related to current locations and contents of containers of goods in the warehouse environment100, work that is to be performed in the warehouse environment100(e.g., goods to be received, moved, and/or sent), worker, teams, and equipment employed in the warehouse environment, and other relevant data for managing warehouse operations during a shift. Performance data received from the performance tracking system230, for example, can include data related to historical performance (e.g., productivity statistics) of various equipment, workers, and/or teams in the warehouse environment100. Configuration data received from the configuration system(s)240, can pertain to a configuration of the warehouse environment100.

At358, the warehouse coordination system210generates enhanced warehouse data, based on the received warehouse data, performance data, and configuration data. Referring toFIG.1A, for example, during stage (B), the computing server(s)160can generate enhanced data172based on the received warehouse/performance/configuration data170, and can maintain the enhanced data172in data source(s)162(e.g., similar to the enhanced warehouse data source250, shown inFIG.2). For detailed and accurate planning, for example, neither warehouse data from the warehouse management system220, nor performance data from the performance tracking system230, nor configuration data from the configuration system(s)240may be entirely sufficient. For example, the warehouse data may include data related work tasks to be performed over a shift, but may lack data related to the performance capabilities of equipment, workers, and/or teams that perform the work tasks, and an environment in which the work tasks are performed. The performance data, for example, may include data related to performance capabilities, but may lack data related to work tasks to be performed. In general, generating the enhanced data172can include techniques for mapping performance capabilities of available equipment, workers, and/or teams to a backlog of work tasks to be performed, with respect to a particular environment. By generating and maintaining the enhanced data172in the data source(s)162, and using the enhanced data for plan creation, work simulation, and progress monitoring applications, for example, load on the warehouse management system220and the performance tracking system230can be reduced. Further, by combining and cross-referencing data from the systems220,230, and240, and preparing the data for use by the plan creation, work simulation, and progress monitoring applications, resources of the warehouse coordination system210can be conserved.

In some implementations, data related to performance capabilities may include productivity rates (e.g., a number of warehouse operations per time period) of various warehouse resources (e.g., equipment, workers, and/or teams or portions of teams). For example, performance data from the performance tracking system230can indicate that over a defined time range (e.g., the previous week, two weeks, four weeks, eight weeks, or another suitable time range), a team or a portion of a team (e.g., a specific picking team of the storage and retrieval team120b, shown inFIG.1A) has historically performed at a particular productivity rate (e.g., 250 cartons per hour) when picking a particular type of container (e.g., conveyable containers) from the storage area110(shown inFIG.1A). When generating a production plan for the team, the performance data can be applied to work tasks to be performed to predict how many of the work tasks may be accomplished by the team during a shift. In some implementations, generating enhanced warehouse data may include attributing particular warehouse resources to warehouse tasks that have been and/or are being performed. For example, the warehouse management system220may store data that indicates that a warehouse task has been performed (e.g., a particular container of goods has been received at a particular time), but may lack data that indicates which warehouse resources performed the warehouse task. By attributing warehouse resources to warehouse tasks, for example, performance capabilities of various resources may be more readily determined.

In some implementations, generating enhanced warehouse data may include using configuration data that indicates how a warehouse is operationally and physically configured. For example, the data source(s)162(shown inFIG.1A) can receive, maintain, and use data that maps areas of the warehouse environment100(shown inFIG.1A) to various warehouse resources (e.g., equipment, workers, and/or teams or portions of teams) that are designated as being assigned to operate in the areas. As another example, the data source(s)162can use data that maps various warehouse resources and/or warehouse areas (e.g., one or more docks102, shown inFIG.1A) that are designated as being capable of handling containers106(shown inFIG.1A) having particular properties (e.g., conveyable cartons, non-conveyable cartons, etc.). Based on the performance data and the configuration data, for example, a data linkage between work tasks to be performed during a shift, resources for performing the work tasks, and predicted productivities of the resources can be determined.

At360, the warehouse coordination system210can use the plan creation interface generator260(shown inFIG.2) to generate and provide data for a plan creation user interface. Referring toFIG.1A, for example, during stage (C), the computing server(s)160can generate and provide data for plan creation user interface180, for presentation and use by any of the computing devices122a-d, shown inFIG.1A). In general, the plan creation user interface180can be used by an operations manager of one of the teams120a-dfor creating a feasible work plan for their respective team, the work plan specifying work tasks to be accomplished by the team during a particular shift. In some implementations, a work plan may be optimized according to various optimization criteria (e.g., time, throughput, resources, etc.). For example, the plan creation user interface180can provide suggested sequencing and/or resource application values such that the work plan is optimized according to the criteria.

At362, the plan creation user interface is presented by the client device302(e.g., similar to any of the computing devices122a-d, shown inFIG.1A). In general, plan creation interfaces may include multiple different screens which can be presented according to an application flow, in which an operations manager selects work tasks for their team to perform during a shift, the work tasks are sequenced, and resources (e.g., equipment, workers, and/or teams or portions of teams) are applied to the work. Once resources have been applied to the work tasks, for example, the work tasks can be simulated, and simulation results of performing the work tasks can be presented to the operations manager. If the simulation results are acceptable, for example, the operations manager may certify and submit a work plan that includes the selected, sequenced, and staffed work tasks. In some implementations, a different interface may be provided for creating work plans for each different team. For example, a receiving plan creation interface can be provided on computing device122afor creating a work plan for the receiving team120a, a storage and retrieval plan creation interface can be provided on computing device122bfor creating a work plan for the storage and retrieval team120b, a sortation plan creation interface can be provided on computing device122cfor creating a work plan for the sortation team120c, and a shipping plan creation interface can be provided on computing device122dfor creating a work plan for the shipping team120d.

At364, user input provided using the plan creation user interface is transmitted by the client device302for receipt by the warehouse coordination system210. Referring toFIG.1A, for example, the plan creation interface180can include a work task input interface182through which an operations manager (e.g., a manager of one of the teams120a-d) can use various interface controls to select and sequence work tasks to be performed by their team during a shift, and to apply resources (e.g., equipment, workers, and/or teams or portions of teams) to the work tasks. In some implementations, at least a portion of the enhanced warehouse data can be presented on a plan creation user interface for a warehouse process. For example, the work task input interface182can present a list of work tasks that are available to be performed by a particular team during a particular shift (e.g., available work and/or work in progress, based on the enhanced data172), and the operations manager can select from and sequence the available tasks. To assist the operations manager with applying resources to the work tasks, for example, the work task input interface182can present information related to resources that are available to the team during the shift (e.g., resource functions, productivity rates, and/or other relevant information, based on the enhanced data172). Selection and sequencing of work tasks and application of the resources can be performed based on priority information presented along with the tasks, process guidelines of an organization, and/or expert knowledge of the operations manager, for example. In the present example, after the operations manager has selected and sequenced tasks (e.g., Task A, Task B, and Task C) to be performed by resources of their team (e.g., one of the teams120a-d) during the shift, the operations manager can submit the selected, sequenced, and staffed work tasks for simulation by the computing server(s)160, and can provide a command to run a simulation of performing the tasks by selecting the simulation control184of the work task input interface182.

In response to receiving the user input and the simulation command, at366, the warehouse coordination system210performs a simulation of the tasks to be performed over the shift for the warehouse process, according to the user inputs. For example, the warehouse coordination system210can receive from the client device302(e.g., similar to one of the computing devices122a-d, shown inFIG.1A) a data structure that includes data that indicates the selected, sequenced, and staffed work tasks input by the operations manager using the plan creation interface180(shown inFIG.1), and can use the warehouse planning simulator280(shown inFIG.2) to run a granular, discrete process simulation of the work tasks being performed in the warehouse environment100(shown inFIG.1A). Running the process simulation, for example, can include modeling the selected work tasks according to the assigned sequence and the applied resources over time, using a collection of state variables that represent a current state of various warehouse entities (e.g., vehicles, equipment, workers, containers, products, etc.) within the warehouse environment100. The state variables, for example, can be modified by the simulation to model an evolution of the state of the various warehouse entities over time.

At368, the warehouse coordination system210transmits an output of the simulation of the tasks to be performed over the shift for the warehouse process, and at370, the client device302presents the simulated output. Referring toFIG.1A, for example, the plan creation interface180can include a simulation output interface186through which the operations manager can review the output of the simulation of the tasks (e.g., predicted throughput of a team over a shift when performing the warehouse process according to the specified plan). If the output is not acceptable, for example, the operations manager can again use the work task input interface182to adjust the work plan (e.g., by selecting different tasks, resequencing the tasks, and/or assigning different resources to the tasks), and can provide a command to run a simulation of the adjusted work plan. By experimenting with various different task, sequence, and resource scenarios, for example, operations managers can efficiently generate and refine feasible work plans for their respective teams. When the output is determined by the operations manager as being acceptable, for example, the operations manager can confirm and submit the work plan for his or her team for possible inclusion in an overall plan for a shift. In the present example, at372the work plan is confirmed and submitted by the operations manager at372, who provides a command to confirm and submit the work plan by selecting the submission control188of the simulation output interface186.

At374, the warehouse coordination system210receives and stores the simulated warehouse process plan that specifies the tasks to be performed over the shift. Referring toFIG.1A, for example, the computing server(s)160can store the plan in data source(s)162, along with simulated output corresponding to the plan, and along with simulated plans/output for other warehouse teams120a-d.

At376, the warehouse management system220transmits real-time warehouse data, and at378, the warehouse coordination system210receives the real-time warehouse data. Referring toFIG.1A, for example, during stage (D), the computing server(s)160can receive real-time data174that pertains to work tasks being performed over the shift for the warehouse process in the warehouse environment100. Real-time data provided by the warehouse management system220, for example, can include data related to updated locations and/or contents of containers of goods in the warehouse environment100, updated locations of equipment and/or workers in the warehouse environment100, specific work tasks being performed by the equipment and/or workers, or other relevant real-time data. In some implementations, real-time data can be periodically or continually provided and received during a shift. For example, the warehouse management system220can periodically (e.g., once per minute, once every five minutes, once every fifteen minutes, or at another suitable time interval) provide updated batches of warehouse state data for receipt by the warehouse coordination system210. As another example, the warehouse management system220can provide updated warehouse state data for receipt by the warehouse coordination system210as changes to the warehouse state occur.

At380, the warehouse coordination system210can use the performance monitoring interface generator270(shown inFIG.2) to generate and provide data for a performance monitoring user interface. Referring toFIG.1A, for example, during stage (E), the computing server(s)160can generate and provide data for performance monitoring user interface190. In general, the performance monitoring user interface190can be used by an operations manager of one of the teams120a-dfor comparing actual work progress during a shift according to real-time data, relative to predicted work progress during the shift according to the performed simulation of work tasks included in the warehouse process plan.

At382, the performance monitoring user interface is presented by the client device302(e.g., similar to any of the computing devices122a-d, shown inFIG.1A). In general, performance monitoring user interfaces can include various numeric and/or graphical indications of actual work progress for a team during a shift, relative to predicted work progress for the team. In the present example, the performance monitoring user interface190includes a predicted work progress indicator192and an actual work progress indicator194. The predicted work progress indicator192, for example, represents work tasks that have been predicted to be performed by the team over the shift, according to the simulated warehouse process plan. The actual work progress indicator194, for example, represents actual work tasks that have been performed by the team over the shift. As shown in the present example, the team overperformed during the first portion of the shift, then adjusted its performance (e.g., possibly as a result of a reallocation of resources prompted in one of the check & adjust periods146a-b) such that its rate of performing work tasks was more closely aligned with its warehouse process plan. By aligning the actual production of teams to their respective production plans, for example, process bottlenecks and physical congestion can be reduced in the warehouse environment100, improving overall efficiency across the various teams120a-d. In some implementations, a different interface may be provided for presenting performance monitoring information for each different team. For example, a receiving performance monitoring interface can be provided on computing device122afor monitoring performance of the receiving team120a, a storage and retrieval performance monitoring interface can be provided on computing device122bfor monitoring performance of the storage and retrieval team120b, a sortation performance monitoring interface can be provided on computing device122cfor monitoring performance of the sortation team120c, and a shipping performance monitoring interface can be provided on computing device122dfor monitoring performance of the shipping team120d.

Referring now toFIG.4, example data interactions between warehouse process plan creation interfaces480and warehouse performance monitoring interfaces490are shown. Each of the plan creation interfaces480(e.g., similar to the plan creation interface180, shown inFIG.1A), for example, can be presented by a different computing device (e.g., one of the computing devices122a-d, shown inFIG.1A) used by an operation manager of a different team (e.g., one of the teams120a-d, shown inFIG.1A) to create a warehouse process plan for their respective team. In the present example, the plan creation interfaces480include a receiving plan creation interface480afor creating a receiving plan450afor the receiving team120a, a storage and retrieval plan creation interface480bfor creating a storage and retrieval plan450bfor the storage and retrieval team120b, a sortation plan creation interface480cfor creating a sortation plan450cfor the sortation team120c, and a shipping plan creation interface480dfor creating a shipping plan450dfor the shipping team120d.

In general, use of and interactions between the plan creation interfaces480a-dcan reflect operational workflow in a warehouse environment. For example, containers of goods in the warehouse environment100can generally be processed sequentially by the teams120a-d, such that the containers are initially received by the receiving team120a, are then handled by the storage and retrieval team120b, are then optionally processed by the sortation team120c, and are eventually shipped by the shipping team120d. As shown inFIG.4, and as shown in the shift timeline130ofFIG.1B, for example, the plan creation interfaces480can also be used sequentially to reflect the operational workflow, such that output resulting from simulation of planned work tasks of a first team is used as input for creating a work plan for a second team, after the work plan for the first team is confirmed and submitted by the first team's operations manager. In the present example, output resulting from simulation of planned work tasks for the receiving team120acan be used as input for creating a work plan for the storage and retrieval team120b, output resulting from simulation of planned work tasks for the storage and retrieval team120bcan be used as input for creating a work plan for the sortation team120c, and output resulting from simulation of planned work tasks for the sortation team120ccan be used as input for creating a work plan for the shipping team120d. In some implementations, output resulting from simulation of planned work tasks for an upstream team can be used as input for creating a work plan for any downstream team. For example, output resulting from simulation of planned work tasks for the receiving team120acan be used as input for creating a work plan for the storage and retrieval team120b, the sortation team120c, and the shipping team120d. Similarly, for example, output resulting from simulation of planned work tasks for the storage and retrieval team120bcan be used as input for creating a work plan for the sortation team120cand the shipping team120d. By cascading output generated using plan creation interfaces as input into other plan creation interfaces, for example, warehouse simulation processes can be simplified (e.g., by limiting the number of process variables), while promoting collaboration between the various teams.

In general, the performance monitoring interfaces490can be used to compare real-time work progress for various warehouse processes to simulated work plans. Real-time work progress, for example, can be determined based on real-time data474(e.g., similar to the real-time data174, shown inFIG.1A). Each of the performance monitoring interfaces490(e.g., similar to the performance monitoring interface190, shown inFIG.1A), for example, can be presented by a different computing device (e.g., one of the computing devices122a-d, shown inFIG.1A) used by an operation manager of a different team (e.g., one of the teams120a-d, shown inFIG.1A) to monitor performance of their respective team. In the present example, the performance monitoring interfaces490include a receiving performance monitoring interface490afor monitoring performance of the receiving team120arelative to the receiving plan450a, a storage and retrieval performance monitoring interface490bfor monitoring performance of the storage and retrieval team120brelative to the storage and retrieval plan450b, a sortation performance monitoring interface490cfor monitoring performance of the sortation team120crelative to the sortation plan450c, and a shipping performance monitoring interface490dfor monitoring performance of the shipping team120drelative to the shipping plan450d.

In some implementations, performance monitoring interfaces may include mechanisms for receiving feedback based on observations related to real-time work progress for various warehouse processes relative to simulated work plans. For example, each of the performance monitoring interfaces490a-dcan include one or more controls for providing user annotations476(e.g., comments, markup, ratings, etc.) that are used to update the respective interface490a-d(and, optionally, one or more other interfaces490a-d). The user annotations476, for example, can provide context for reported productivity metrics, and can be shared among various operations managers to help identify root causes of potential problems within the warehouse environment100and to help make collective decisions.

Referring now toFIG.5, a flow diagram of an example technique500for providing a performance monitoring interface for a warehouse process is shown. The warehouse process, for example, can be a receiving process (e.g., unloading containers from inbound trucks arriving at a warehouse), a storage and/or retrieval process (e.g., moving containers in and around the warehouse), a sortation process (e.g., unpacking goods from containers and repacking the goods in other containers), a shipping process (e.g., loading containers onto outbound vehicles for shipment), or another sort of process that occurs in a warehouse environment. In the present example, the example technique can be performed by the computing server(s)160(e.g., shown inFIG.1A, implementing components of the system200(shown inFIG.2)), and any of the computing devices122a-d(shown inFIG.1A).

Performance monitoring user interfaces can be used by various operations managers (e.g., respective managers of the receiving team120a, the storage and retrieval team120b, the sortation team120c, and the shipping team120d). Through use of the performance monitoring user interfaces, for example, collaboration among different teams within a warehouse can be facilitated in order to provide balance and harmony between the teams and to improve overall efficiency under a production plan. The user interface features can include pacing production metrics that team leaders are instructed to follow, along with variances indicating acceptable ranges of those metrics. The interface can also provide alerts prompting team leaders for feedback on deviations of actual production metrics from the pacing production metrics. Additionally, the interface can prompt collaborative check-ins among team leaders throughout a work shift, which can facilitate adjustments and modifications to each team's performance in order to meet performance goals. By providing operations managers with a performance monitoring interface that aggregates and simplifies complex data, for example, the operations managers can more effectively focus on their respective objectives, which may be to produce according to the performance goals (instead of always a maximum amount), in order to improve efficiency for the warehouse as a whole.

In general, different performance monitoring interfaces may be provided for monitoring the performance of different warehouse teams that each perform different types of warehouse operations. As described with respect toFIG.4, for example, different performance monitoring interfaces can be provided for monitoring the performance of the receiving team120a, the storage and retrieval team120b, the sortation team120c, and the shipping team120d. A general application flow of each of the different performance monitoring interfaces is described with respect toFIG.5, for example, however each different performance monitoring interface can be customized to possibly have a different application flow, and/or to monitor the performance of a different warehouse process. In further detail, example performance monitoring interfaces for receiving operations are described below with respect toFIGS.6A-C, an example performance monitoring interface for storage and retrieval operations is described below with respect toFIG.7, an example performance monitoring interface for sortation operations is described below with respect toFIG.8, an example performance monitoring interface for shipping operations is described below with respect toFIG.9, and an example performance monitoring interface for a check and adjust session is described below with respect toFIG.10.

At502, a simulation of tasks to be performed over a shift can be performed. For example, a warehouse coordination system implemented by the computing server(s)160can perform a simulation of tasks to be performed over a shift for a warehouse process (e.g., a receiving process, a storage and/or retrieval process, a sortation process, an shipping process, etc.), according to a defined sequence of the tasks to be performed and defined resources (e.g., equipment, workers, and/or teams or portions of teams) to be applied to the tasks. In some implementations, a defined sequence of tasks to be performed and/or defined resources to be applied to the tasks may be provided through one or more user interfaces. For example, the warehouse coordination system implemented by the computing server(s)160can receive, through the plan creation interface180, a simulation command to execute a simulation of tasks to be performed over the shift for the warehouse process (e.g., as a result of the user selecting the simulation control182). In response to receiving the simulation command, for example, the warehouse coordination system can execute the simulation of the tasks. The simulation, for example, can be executed according to user input that indicates the sequence of the tasks to be performed, and according to user input that indicates the resources to be applied to the tasks. Optionally, the simulation of the tasks to be performed over the shift for the warehouse process can also be performed according a defined configuration of a warehouse environment. For example, the warehouse coordination system implemented by the computing server(s)160can receive user input through a warehouse configuration portion of the plan creation interface180that indicates a configuration of the warehouse environment100in which a warehouse process is to be performed. Configuration information provided through the configuration portion of the plan creation interface180, for example, can include information that may not be available from the warehouse management system(s)220(shown inFIG.2) or performance tracking system(s)230(shown inFIG.2), such as information related to docks102, storage racks112, and/or equipment116that are available (or unavailable) for performing tasks during a shift, and other relevant warehouse configuration information.

At504, simulation output data can be generated, based on the simulation of tasks to be performed. For example, the warehouse coordination system implemented by the computing server(s)160can generate simulation output data resulting from the simulation of the tasks to be performed. As shown inFIG.2, for example, the warehouse coordination system210can use the warehouse planning simulator270to run granular, discrete process simulations for operations to be performed by any of the teams120a-dduring a shift. When running the process simulations, for example, the tasks to be performed over the shift by one of the teams120a-dcan be modeled according to the defined task sequence, and according to the defined resources to be applied to the tasks (and optionally, according to the defined configuration of the warehouse environment). In some implementations, the simulation may be performed at a unit level (e.g., pallet, carton, package, or another transportable container of goods). Transportable containers of goods can be of different types, such as conveyable freight units that are capable of being processed by automated equipment, for example, and non-conveyable freight units that are to be processed mainly through manual interaction. The simulation output data can indicate that a particular transportable container, a particular type of transportable container, and/or a transportable container from a particular vehicle or area of the warehouse environment100is estimated to be processed at a particular time (or during a particular time range), according to a warehouse plan represented by the output data. By performing a discrete process simulation at the unit level, for example, warehouse plans can be feasible, accurate, and readily comparable with real-time warehouse data.

At506, data that represents the defined sequence of the tasks to be performed, data that represents the defined resources to be applied to the tasks, and the simulation output data can be stored. For example, the warehouse coordination system implemented by the computing server(s)160can store (e.g., in data source(s)162) the user input that indicates the sequence of tasks to be performed, the user input that indicates the resources to be applied to the tasks, and the simulation output data based on the simulation of the tasks to be performed.

At508, real-time warehouse data that indicates tasks being performed over the shift for the warehouse process can be received. For example, the computing server(s)160can receive real-time data174that pertains to work tasks being performed in the warehouse environment100by any of the teams120a-dfor a respective warehouse process (e.g., receiving, storage and/or retrieval, sortation, shipping). In general, team leaders may direct their teams to perform work tasks according to a work plan represented by the simulation output data, however some tasks may be performed more quickly than estimated, more slowly than estimated, or out of sequence according to the work plan. The real-time data174, for example, can indicate a current status of containers, equipment, and/or workers in the warehouse environment100, such as actual locations and/or contents of containers of goods, locations of equipment and/or workers, specific work tasks being performed by the equipment and/or workers, and other real-time data. For example, the warehouse management system(s)220(shown inFIG.2) can communicate with data collection devices (e.g., manual input devices, scanners, cameras, or other suitable devices) in the warehouse environment100, and can receive real-time operation data when containers are processed by workers and/or equipment for various work tasks (e.g., unloading a container from an inbound vehicle, transporting the container from a location to another location, storing the container in a storage location, retrieving the container from the storage location, unpacking the container, repacking the container, loading the container onto an outbound vehicle, or another work task). The real-time operations data, for example, can include an operation timestamp, and various identifiers related to the operation, such as location, worker, team, container, container type, and/or goods identifiers, and can be received periodically or continually during a shift.

At510, data can be provided for a performance monitoring interface for a warehouse process. For example, the computing server(s)160can provide real-time data and simulation output data for performance monitoring interface190. A leader (e.g., an operations manager) of any of the teams120a-dcan use the performance monitoring interface190, for example, to compare actual work progress of their respective team during a shift according to the real-time data for the team, relative to predicted work progress of the team according to the simulation output data for the team. By providing a customized interface for each different team, for example, a team leader can have access to data that is useful for making decisions for their particular team, without having to review data that mainly pertains to other teams. The performance monitoring interface190, for example, can present, for each time period of a plurality of time periods (and/or for a given point in time), an amount of tasks that have been predicted to be performed by the team according to the simulation of the tasks, in comparison to an amount of tasks that have been performed according to the real-time warehouse data. An amount of tasks can be represented by a number of containers (e.g., broken down by container types, and/or containers from particular vehicles or areas) that are predicted to be or actually have been processed according to a work task (e.g., unloading, transporting, storing, retrieving, unpacking, repacking, loading, or another sort of task), for example. A different performance monitoring interface190can be provided for various different warehouse operations (e.g., receiving, storage and/or retrieval, sortation, and shipping), as described in further detail in the examples below.

Referring now toFIGS.6A-C, example performance monitoring interfaces for receiving operations are shown. Performance monitoring interface600a(shown inFIG.6A) for receiving operations, for example, can be used to compare actual work progress of the receiving team120aduring a shift according to real-time data for the receiving team, relative to predicted work progress for the receiving team according to the simulation output data for the receiving team. Actual work progress relative to predicted work progress can be determined for each time period of a plurality of time periods that occur during a shift, for example. In the present example, the shift includes three four-hour time periods—a first time period that occurs from 06:00-10:00, a second time period that occurs from 10:00-14:00, and a third time period that occurs from 14:00-18:00. However, in other examples, a different number of time periods may be specified, and/or the time periods may be of different lengths and/or may occur over different time intervals.

The performance monitoring interface600a, for example, includes a time period selection control602that can be used to select a previous, current, or future time period of a shift. In response to receiving user input from the time period selection control602, for example, the performance monitoring interface600acan be updated to present work progress information related to a selected time period (e.g., actual work progress compared to predicted work progress for the selected time period, and/or cumulative actual work progress compared to cumulative predicted work progress for the entire shift up to the selected time period). In the present example, a current time is 15:45, and the user has selected the first time period (e.g., to review what had occurred earlier in the shift).

The performance monitoring interface600a, for example, can also include presentation controls that present views of actual work progress compared to predicted work progress of the receiving team120aduring a shift. For example, the performance monitoring interface600aincludes a volume by dock presentation control604that presents, for each different area in which the receiving team120aperforms tasks in the warehouse environment100(e.g., an ART (Automated Receiving) dock, and a Manual dock), a view of actual work progress of the receiving team relative to predicted work progress. In the present example, at the end of the first period, the receiving team120ahad been predicted to process 15,420 cartons, with 10,400 of those cartons being processed at the ART dock, and 5,020 of those cartons being processed at the Manual dock. However, based on the real-time data, for example, the receiving team120ahad actually processed 18,675 cartons, with 12,593 of those cartons being processed at the ART dock, and 5,797 of those cartons being processed at the Manual dock.

In some implementations, a performance monitoring interface may present an alert when an amount of tasks that have been performed according to the real-time warehouse data is outside of a predetermined variance for an amount of tasks that had been predicted to be performed according to the simulation of tasks. For example, during and/or at the end of the first time period (e.g., during check & adjust period146aat the end of the first shift period134a, shown inFIG.1B) an operations manager of the receiving team120acan review the volume by dock presentation control604for possible alerts that indicate that an amount of tasks (e.g., a number of cartons processed) that have been performed according to the real-time warehouse data is outside of a predetermined variance for an amount of tasks that had been predicted to be performed. The predetermined variance, for example, can be a percentage value (e.g., 5%, 10%, 20%, or another suitable percentage value) that is used for a variance around a target value (e.g., a predicted value according to the simulation of tasks). As another example, a first percentage value can be used for a variance that is higher than the target value, and a second, different percentage value can be used for a variance that is lower than the target value. In the present example, at the end of the first time period, the receiving team120ahad processed 21% more cartons than predicted at the ART dock, and 15% more cartons than predicted at the Manual dock, as determined by comparing the real-time data to the simulated work plan for the receiving team. Thus, in the present example, an alert610a(e.g., a graphical icon and/or a selectable control) can be provided by the performance monitoring interface600athat indicates that the performance of work tasks by the receiving team120aat the ART dock is outside of the predetermined variance, and another alert610bcan be provided by the performance monitoring interface600athat indicates that the performance of work tasks by the receiving team at the Manual dock is also outside of the predetermined variance.

Through such alerts, for example, operations managers can be notified of specific areas of underproduction and/or overproduction by their respective teams. The operations managers can then quickly identify sources of potential problems, and can adjust resources from one team to another (or a portion of a team to another portion), such that operations in the warehouse environment100proceed according to an overall plan. For example, if the receiving team120aunderproduces, a downstream operation (e.g., operations performed by the storage and retrieval team120b) may not have access to enough cartons to proceed according to their own plan (e.g., a storage and retrieval plan), causing wasted downstream productivity. On the other hand, if the receiving team120aoverproduces, for example, backlogs of cartons may be built up in the warehouse environment100, leading to congested areas, and reduced efficiency of the storage and retrieval team120b. Use of the various performance monitoring interfaces, for example, can help the operations managers to follow their respective work plans and to collaborate with each other, such that overall efficiency across an organization is maximized.

In some implementations, a performance monitoring interface may present multiple different presentation controls, each presentation control presenting a different view (e.g., broken down by a different type of data) of an actual performance of work tasks compared to a predicted performance of the work tasks. For example, the volume by dock presentation control604breaks down actual and predicted performance of work tasks (e.g., processed cartons) by warehouse area, whereas a volume by process presentation control606breaks down actual and predicted performance of work tasks by container type. The volume by process presentation control606, for example, presents, for each different type of carton processed by the receiving team120a(e.g., BFL, BRS, CFL, CRS, NFL, NRS, PFL, PRS, TFL, TRS, and Unknown), a view of actual work progress of the receiving team relative to predicted work progress. In the present example, at the end of the first period, the receiving team120ahad been predicted to process 15,420 cartons, with 990 of those being BFL cartons, 1,771 of those being BRS cartons, 4,212 of those being CFL cartons, and 5,727 of those being CRS cartons. However, based on the real-time data, for example, the receiving team120ahas actually processed 18,672 cartons, with 1,098 of those being BFL cartons, 2,870 of those being BRS cartons, 4,282 of those being CFL cartons, and 5,880 of those being CRS cartons. Similar to the alerts610a-bprovided for data presented by the volume by dock presentation control604, alerts612a-bcan be provided with respect to the BRS cartons and the CRS cartons in the present example, as for each of these types of cartons, a number of cartons that has been processed by the receiving team120aduring the first period is outside of a predetermined variance for a number of cartons that had been predicted to be processed by the receiving team. In the present example, the performance monitoring interface600aalso includes a plan variance by process method control608that breaks down actual and predicted performance of work tasks (e.g., processed cartons) by warehouse area and by container type. The plan variance by process method control608in the present example is a bar graph that shows a number of cartons that have been processed in each warehouse area (e.g., ART dock and Manual dock) and by carton type, according to the real-time data and relative to the predicted number of processed cartons. By referring to the plan variance by process method control608in the present example, an operations manager can quickly determine that overproduction by the receiving team120aduring the first period is largely due to over processing CRS containers in the Manual dock area. This sort of granular information, for example, can help the operations manager quickly identify the source of the problem, and make adjustments to correct the problem.

In some implementations, a performance monitoring interface may include a first graphical indicator that plots, along a time axis, a cumulative amount of work tasks that had been predicted to be performed according to the simulation of tasks, and a second graphical indicator that plots, along the time axis, a cumulative amount of work tasks that have been performed according to the real-time warehouse data. For example, the performance monitoring interface600acan include a receiving plan control620that plots, along a time axis for the shift (e.g., from 6:00 to 18:00), a graphical indicator622(e.g., a “plan” indicator) that represents a cumulative number of cartons that had been planned to be processed by the receiving team120a, and a graphical indicator624(e.g., an “actual” indicator) that represents a cumulative number of cartons that have actually been processed, at each point in time along the time axis. In some implementations, the first graphical indicator represents a predetermined variance for the cumulative amount of tasks that had been predicted to be performed according to the simulation of tasks. For example, the graphical indicator622(e.g., the “plan” indicator) can be a line having an expanding thickness plotted over time, the line thickness representing a range of an amount of work tasks that can be performed by the receiving team120aat a given time, while falling within the predetermined variance. In the present example, the receiving plan control620shows that at the end of the first period (e.g., 10:00), the receiving team120ahad been overproducing relative to its plan, and that the team had then adjusted its rate of production (e.g., as a result of a check & adjust session and a reallocation of resources). Over the course of the remainder of the shift, for example, the receiving team120ahad mainly produced within the predetermined variance represented by the graphical indicator622. Through the receiving plan control620, for example, an operations manager of the receiving team120acan quickly determine whether the team is performing according to its simulated plan, and can track the overall progress of the team over time.

Referring again toFIG.5, at512, input that relates to the performance of tasks over a shift can optionally be received. For example, input mechanisms (e.g., selectable user interface controls, data entry controls, voice input, data from data collection devices, etc.) can be provided (e.g., through the performance monitoring interface190shown inFIG.1A, through another sort of user interface, and/or through an automated data collection interface) to provide information related to performance of tasks during the shift, such as observations made by the operations managers during the shift, actions taken during the shift, staffing change events (e.g., team members joining or leaving the team during the shift, an occurrence of an injury to a team member, etc.), equipment change events (e.g., equipment coming online/offline, equipment malfunctioning, etc.), and/or information related to other events that may occur during the shift that may impact the performance of tasks according to a production plan (e.g., weather events, power outages, early or late arrivals of vehicles to a warehouse, etc.). In general, the information related to the performance of tasks can be maintained by the computing server(s)160of the warehouse management system, can be shared among multiple operations managers through their respective performance monitoring interfaces190(e.g., a performance monitoring interface for use during a check and adjust session), and/or can be used to update a knowledge base that aggregates information related to task performance and correlates the information with possible deviations of actual productivity of a team from predicted productivity of the team. In some implementations, performance monitoring interfaces can provide one or more input mechanisms for providing operator information when the amount of tasks that have been performed according to the real-time warehouse data is outside of a predetermined variance for the amount of tasks that had been predicted to be performed according to the simulation of tasks. For example, operations managers can interact with the performance monitoring interface190to provide information related to underperformance or overperformance of their respective teams during the shift.

Referring now toFIG.6B, for example, a user input control640of the performance monitoring interface600ais shown. In the present example, the user input control640can be presented by the performance monitoring interface600ain response to a user interacting with alert612a(shown inFIG.6A). The alert612a(e.g., a selection control as indicated by a particular icon, color, text, etc.), for example, can be presented by the performance monitoring interface600awhen the actual performance of the receiving team120ais outside of the predetermined variance (e.g., due to overproduction or underproduction) for the amount of tasks that had been predicted to be performed according to the simulated work plan for the team. In the present example, the operations manager of the receiving team120acan select the alert612ato provide information related to a production discrepancy of the receiving team120aduring the first shift with respect to BRS cartons. Using the user input control640, for example, the operations manager can select one or more categories that describe an observation/event related to the production discrepancy, can provide text describing the observation/event, and can provide text describing an action that the manager performed to respond to the observation/event. For example, the selectable categories can include general observations and/or various event categories, such as staffing change events, equipment change events, or other events that may impact the performance of tasks according to a production plan (e.g., weather events, power outages, early or late arrivals of vehicles to a warehouse, etc.). Information provided through the user input control640, for example, can be stored by the warehouse coordination system implemented by the computing server(s)160. The information, for example, can be shared among operations managers across different teams, shifts, and/or warehouse environments, and can be added to a knowledge base (e.g., implemented by one or more of the data sources162) for identifying performance trends and/or recurring problems, and for facilitating performance and planning improvements.

Referring now toFIG.6C, for example, a performance monitoring interface600c(e.g., similar to the performance monitoring interface600a, shown inFIG.6A) is shown. The performance monitoring interface600c, for example, presents observations/events and actions670that have been provided by an operations manager using the user input control640. The observations/events and actions670, for example, can be collected over time during the shift, and can serve as working notes to be shared with operations managers of other teams during one or more of the check and adjust periods146a-band/or the end of shift recap period146c, to facilitate cooperation between the operations managers and overall process improvements.

Referring again toFIG.5, at514, a determination of whether a work plan is to be modified is performed, based on received input related to a performance of tasks during a shift. In the present example, user input received through a performance monitoring interface (e.g., input received through the user input control640of the performance monitoring interface600a, shown inFIG.6B) can be analyzed by the computing server(s)160to determine whether the received input indicates that a work plan is to be modified. In some implementations, determining whether the work plan is to be modified may include determining whether the received input indicates a change to any of the defined resources that have been applied to the work tasks for which a simulation of tasks has been performed. For example, the received input can indicate that a staffing event change has occurred (e.g., a worker was added to or removed from a team during the shift), an equipment change has occurred (e.g., additional equipment was used by the team, a piece of equipment malfunctioned, etc.), or another change has occurred to a resource represented by simulation input. In some implementations, determining whether the work plan is to be modified may include determining whether the received input is associated with an event and/or observation that is represented in a knowledge base that correlates aggregated observations/events with deviations of predicted productivity from actual productivity. For example, the received input can indicate that a particular event (e.g., a weather event such as a snowstorm, a power loss event, an early/late vehicle arrival event, or another sort of event) is correlated with a deviation (e.g., a percentage increase or decrease) in team productivity over a shift, according to aggregated observation/event data maintained by the knowledge base.

At516, in response to determining that a work plan is to be modified, the work plan can be modified. For example, the warehouse coordination system implemented by the computing server(s)160can modify a work plan (e.g., including tasks that are predicted to be performed) for a team for a remainder of a shift, based on the received input related to the performance of tasks. In some implementations, modifying a work plan for a team may include performing an updated simulation of tasks for the team. For example, the warehouse coordination system can perform a simulation of tasks to be performed over a remaining portion of a shift for a warehouse process (e.g., a receiving process, a storage and/or retrieval process, a sortation process, a shipping process, etc.), according to a sequence of tasks to be performed over the remaining portion of the shift, and according to the defined resources to be applied to the work tasks, as modified by the received input related to the performance of tasks (e.g., input indicating an increase or decrease in workers and/or equipment to be applied over the remaining portion of the shift). Performing the updated simulation, for example, can include performing a task simulation (502), generating simulation output data (504), and storing the data (506), as described above. In some implementations, modifying a work plan for a team may include adjusting a predicted productivity for the team according to an adjustment factor that is correlated with aggregated observations/events that match the received input related to the performance of tasks. For example, in response to receiving input that indicates that a particular event (e.g., a weather event such as a snowstorm, a power loss event, an early/late vehicle arrival event, or another sort of event) has occurred, the knowledge base can be accessed, an adjustment factor for the particular event can be identified, and the adjustment factor can be applied to a predicted productivity for the team for the remaining portion of the shift. By modifying a work plan for a team (including updating a task simulation and/or adjusting a predicted productivity of the team), for example, expectations of an operations manager of the team (and other operations managers of other teams) can be aligned with current warehouse capabilities.

During a shift, for example, real-time warehouse data that indicates tasks being performed can continue to be received (508), and data can continue to be provided for performance monitoring interfaces (510). At the end of the shift (518), for example, a knowledge base can optionally be updated (520). For example, the computing server(s)160can update the knowledge base (e.g., implemented by one or more of the data sources162) with input data related to a performance of tasks during the shift (e.g., observations/events/actions), and data that represents actual productivity of the team relative to predicted productivity of the team over the shift. Data provided to the knowledge base can be aggregated over time (e.g., over multiple different shifts), and correlated productivity deviations can be identified for particular observations/events/actions for particular teams (e.g., using various machine learning techniques). The knowledge base of observations/events/actions and correlated productivity deviations can be used, for example, to accurately adjust predicted productivities for teams in response to a reoccurrence of an observation/event/action, and/or for future planning/simulation cycles.

Referring now toFIG.7, an example performance monitoring interface700for storage and retrieval operations is shown. The performance monitoring interface700for storage and retrieval operations, for example, can be used to compare actual work progress of the storage and retrieval team120bduring a shift according to real-time data, relative to predicted work progress for the storage and retrieval team according to simulation output data. Similar to performance monitoring interface600a(shown inFIG.6A), for example, the performance monitoring interface700can include a time period selection control for selecting a time period of a shift, one or more presentation controls that present views of actual work progress compared to predicted work progress for the shift (e.g., for the storage and retrieval team120b), and graphical indicators that plot, along a time axis, a cumulative amount of work tasks that had been predicted to performed according a task simulation, relative to a cumulative amount of work tasks that have actually been performed (e.g., by the storage and retrieval team120b). Also similar to performance monitoring interface600a, for example, the performance monitoring interface700can provide alerts when an amount of tasks that have been performed according to the real-time warehouse data is outside of a predetermined variance for an amount of tasks that had been predicted to be performed according to the task simulation (e.g., for the storage and retrieval team120b), can provide one or more information controls for receiving operator information with respect to the alerts, and can collect provided information over the shift.

In some implementations, performance monitoring interfaces may include one or more controls for selecting one or more types of tasks that may be performed in a warehouse environment. For example, the performance monitoring interface700can include a task type selection control732through which an operations manager can select a type of task that can be performed by the storage and retrieval team120b. The storage and retrieval team120b, for example, can perform pick tasks (e.g., retrieving containers from storage locations) and put tasks (e.g., placing containers into storage locations). In response to receiving a task type selection through the task type selection control732, for example, the performance monitoring interface700can be updated to present information (e.g., based on data that compares actual work task progress relative to predicted work task progress) relevant to the selected task type. In the present example, a task type selection of “pick” has been made, and information related to simulated and actual pick tasks performed by storage and retrieval team120bis presented by the performance monitoring interface700. By providing controls for selecting from multiple different types of tasks that may be performed by a team, for example, the performance monitoring interface700can be used to more effectively manage portions of a team (e.g., a portion of the team that performs a particular type of task), and/or the performance of particular types of tasks.

The performance monitoring interface700for storage and retrieval operations, for example, includes a pick volume by team control704that presents, for each different type of carton picked by the storage and retrieval team120bin the warehouse environment100(e.g., conveyable bulk, conveyable carton air, conveyable carton floor, and conveyable full pallet), a view of actual work progress of the storage and retrieval team relative predicted work progress. In the present example, at the end of the first period, the storage and retrieval team120bhas overproduced with respect to all carton types, and corresponding alerts can be presented for notifying an operations manager, so that the operations manager can identify possible causes of the overproduction, and can possibly provide related information. The performance monitoring interface700also includes a storage and retrieval plan control720(e.g., a “pick” plan control) that plots, along a time axis for the shift (e.g., from 6:00 to 18:00), a first graphical indicator that represents a cumulative number of cartons that had been planned to be picked by the storage and retrieval team120b, and a second graphical indicator that represents a cumulative number of cartons that have actually been picked by the team. In the present example, the storage and retrieval plan control720shows that at the end of the first and second periods (e.g., 10:00 and 14:00), the storage and retrieval team120bhad been overproducing relative its pick plan, but that the rate of production had then decreased to track closer to the plan.

Referring now toFIG.8, an example performance monitoring interface800for sortation operations is shown. The performance monitoring interface800for sortation operations, for example, can be used to compare actual work progress of the sortation team120cduring a shift according to real-time data, relative to predicted work progress for the sortation team according to simulation output data. Similar to performance monitoring interfaces600a(shown inFIG.6A) and700(shown inFIG.7), for example, the performance monitoring interface800can include a time period selection control for selecting a time period of a shift, one or more presentation controls that present views of actual work progress compared to predicted work progress for the shift (e.g., for the sortation team120c), and graphical indicators that plot, along a time axis, a cumulative amount of work tasks that had been predicted to performed according a task simulation, relative to a cumulative amount of work tasks that have actually been performed (e.g., by the sortation team120c). Also similar to performance monitoring interfaces600aand700, for example, the performance monitoring interface800can provide alerts when an amount of tasks that have been performed according to the real-time warehouse data is outside of a predetermined variance for an amount of tasks that had been predicted to be performed according to the task simulation (e.g., for the sortation team120c), can provide one or more controls for receiving operator information with respect to the alerts, and can collect provided information over the shift.

The performance monitoring interface800for sortation operations, for example, includes a task type selection control832through which an operations manager can select a type of task that can be performed by the sortation team120c. The sortation team120c(or respective portions of the sortation team120c), for example, can perform sotation tasks (e.g., unpacking goods from containers) and packing tasks (e.g., packing goods into containers). In response to receiving a task type selection through the task type selection control832, for example, the performance monitoring interface800can be updated to present information (e.g., based on data that compares actual work task progress relative to predicted work task progress) relevant to the selected task type. In the present example, a task type selection of “breakpack” has been made, and information related to simulated and actual breakpack (e.g., unpacking) tasks performed by sortation team120cis presented by the performance monitoring interface800. By providing controls for selecting between breakpack and packing tasks, for example, the performance monitoring interface700can be used to more effectively manage portions of the sortation team120cthat perform the respective tasks, and/or the performance of the tasks.

The performance monitoring interface800for sortation operations, for example, includes a breakpack volume by team control804that presents, for each different type of container unpacked by the sortation team120cin the warehouse environment100(e.g., carton air, full pallet (PLTS), and full pallet (SSPS)), a view of actual work progress of the sortation team relative predicted work progress. In the present example, at the end of the first period, the sortation team120chas overproduced with respect to all container types, and corresponding alerts can be presented for notifying an operations manager, so that the operations manager can identify possible causes of the overproduction, and can possibly provide related information. The performance monitoring interface800also includes a sortation plan control820that plots, along a time axis for the shift (e.g., from 6:00 to 18:00), a first graphical indicator that represents a cumulative number of containers that had been planned to be unpacked by the sortation team120c, and a second graphical indicator that represents a cumulative number of containers that have actually been unpacked by the team. In the present example, the sortation plan control820shows that the sortation team120chas been overproducing relative its sortation plan throughout the shift.

Referring now toFIG.9, an example performance monitoring interface900for shipping operations is shown. The performance monitoring interface900for shipping operations, for example, can be used to compare actual work progress of the shipping team120dduring a shift according to real-time data, relative to predicted work progress for the shipping team according to simulation output data. Similar to performance monitoring interfaces600a(shown inFIG.6A),700(shown inFIG.7), and800(shown inFIG.8), for example, the performance monitoring interface900can include a time period selection control for selecting a time period of a shift, one or more presentation controls that present views of actual work progress compared to predicted work progress for the shift (e.g., for the shipping team120d), and graphical indicators that plot, along a time axis, a cumulative amount of work tasks that had been predicted to performed according a task simulation, relative to a cumulative amount of work tasks that have actually been performed (e.g., by the shipping team120d). Also similar to performance monitoring interfaces600a,700, and800, for example, the performance monitoring interface900can provide alerts when an amount of tasks that have been performed according to the real-time warehouse data is outside of a predetermined variance for an amount of tasks that had been predicted to be performed according to the task simulation (e.g., for the shipping team120d), can provide one or more controls for receiving operator information with respect to the alerts, and can collect provided information over the shift.

The performance monitoring interface900for shipping operations, for example, includes a volume by team control904that presents, for each different type of task performed by the shipping team120din the warehouse environment100(e.g., depalletizing tasks, non-conveyable sorting tasks, total loading tasks, etc.), a view of actual work progress of the shipping team relative predicted work progress. In the present example, at the end of the first period, the shipping team120dhas performed according to its plan with respect to depalletizing tasks and total loading tasks, however has underperformed with respect to non-conveyable sorting tasks. Thus, in the present example, an alert910acan be presented that corresponds to the non-conveyable sorting tasks, so that an operations manager can be notified of the underproduction, can identify possible causes of the underproduction, and can possibly provide related information. The performance monitoring interface900also includes a shipping plan control920that plots, along a time axis for the shift (e.g., from 6:00 to 18:00), a first graphical indicator that represents a cumulative number of work tasks that had been planned to be performed by the shipping team120d, and a second graphical indicator that represents a cumulative number of work tasks that have actually been performed by the team. In the present example, the shipping plan control920shows that the shipping team120dhas been mainly performing according to its plan throughout the shift.

In some implementations, a performance monitoring interface may present information related to aggregated overall actual performance of multiple different teams, relative to the simulated work plans. For example, each of the performance monitoring interfaces600a(shown inFIG.6A),700(shown inFIG.7),800(shown inFIG.8), and900(shown inFIG.9) can include respective total performance controls630,730,830, and930, each total performance control providing information related to a total performance across the teams120a-dover the shift. In the present example, each of the total performance controls630,730,830, and930presents a total number of cartons processed according to the overall simulated work plan, an actual number of cartons processed, a number of planned work hours, a number of actual work hours, a number of processed cases per hour according to the work plan, and an actual number of cases per hour. Through the total performance controls630,730,830, and930, for example, the respective operations managers of the respective teams120a-dcan be informed about progress according to the overall work plan during the shift.

Referring now toFIG.10, an example performance monitoring interface1000for a check and adjust session is shown. The performance monitoring interface1000, for example, can aggregate data related to simulated work plans and data related to actual work task performance, across multiple different teams, into an aggregated presentation. In the present example, the performance monitoring interface1000includes information from the performance monitoring interface600afor receiving operations (shown inFIG.6A), the performance monitoring interface700for storage and retrieval operations (shown inFIG.7), the performance monitoring interface800for sortation operations (shown inFIG.8), and the performance monitoring interface900for shipping operations (shown inFIG.9). For example, the performance monitoring interface1000can include multiple different information presentation controls, such as a safety information presentation control1010, a quality information presentation control1020, and a productivity information presentation control1030. The safety information presentation control1010, for example, can present information related to injuries, near-misses, and other safety-related incidents that may have occurred during a shift. The quality information presentation control1020, for example, can present quality-related information with respect to planned and performed work tasks during the shift. The productivity information presentation control1030, for example, can present productivity-related information with respect to planned and performed work tasks during the shift. Each of the information presentation controls1010,1020, and1030, for example, can be repeated for presenting information related to the receiving team120a, the storage and retrieval team120b, the sortation team120c, and the shipping team120d. The performance monitoring interface1000, for example, can also present information provided by operations managers through controls of the performance monitoring interfaces600a,700,800, and900. During each of the check & adjust periods146a-b, and during the end of shift recap period146c, for example, operations managers of the respective teams120a-dcan meet, and can refer to the performance monitoring interface1000while communicating about how to possibly adjust operations (e.g., by reallocating resources) to better perform work tasks according to plan while running a balanced, quality, safe operation across the teams, and to collaboratively solve problems that may occur in the warehouse environment100.

FIG.11is a schematic diagram that shows an example of a computing system1100. The computing system1100can be used for some or all of the operations described previously, according to some implementations. The computing system1100includes a processor1110, a memory1120, a storage device1130, and an input/output device1140. Each of the processor1110, the memory1120, the storage device1130, and the input/output device1140are interconnected using a system bus1150. The processor1110is capable of processing instructions for execution within the computing system1100. In some implementations, the processor1110is a single-threaded processor. In some implementations, the processor1110is a multi-threaded processor. The processor1110is capable of processing instructions stored in the memory1120or on the storage device1130to display graphical information for a user interface on the input/output device1140.

The memory1120stores information within the computing system1100. In some implementations, the memory1120is a computer-readable medium. In some implementations, the memory1120is a volatile memory unit. In some implementations, the memory1120is a non-volatile memory unit.

The storage device1130is capable of providing mass storage for the computing system1100. In some implementations, the storage device1130is a computer-readable medium. In various different implementations, the storage device1130may be a floppy disk device, a hard disk device, an optical disk device, or a tape device.

The input/output device1140provides input/output operations for the computing system1100. In some implementations, the input/output device1140includes a keyboard and/or pointing device. In some implementations, the input/output device1140includes a display unit for displaying graphical user interfaces.