Smart WarehouseMaterial Flow
Different requests. Same flow problem.
Across facilities, I found recurring needs addressed through separately maintained tools. That shifted the design question from solving each request locally to deciding what could be shared and what needed to remain configurable.
Material flow is a whole-site concern. A single upstream team can meet its output goal, but cause bottlenecks elsewhere. Site leadership teams spend countless hours trying to solve "team-first mindset" with various approaches at their facilities.
A local win could put the rest of the building under pressure.
Strong receiving performance released large bursts of product into the system.
Strong inbound activity created urgency in put away and storage, increasing demand for equipment.
Sorter teams struggle to keep up with heavy demand, creating jams and uneven flow.
Limited access to equipment shared between Put Away and Pick make pick and repacking difficult to sustain.
When work stalled upstream, downstream teams wait for product to arrive, leading to low productivity and delays.
Though the facilities are different, they experience flow issues in similar ways. As leadership teams meet with each other, they often share potential solutions, often leading to localized updates.
Operating rhythms
Sorter visibility
Inbound productivity
Feed control
Standardize what repeats. Configure what differs. Material Flow connected local operating needs into one reusable product direction without assuming every warehouse was identical.
Reporting, sorter monitoring, inbound productivity, and feed control arrived as separate requests. Comparing how four facilities actually worked exposed recurring gaps in visibility, reuse, and local control.
These requests belonged in a larger Material Flow epic:one supported foundation, with room for the local variations the investigations had revealed.
Riverside
The request: Reporting and how the Control Center monitored the building.
A commissioning visit began with reporting discussions and led to the Control Center. Teams worked in roughly 30-minute check-and-adjust cycles, using local tools and a LEGO-based model to explain material movement.
Those local practices reflected a whole-building mental model that the supported software did not yet show. The reporting request was really asking for connected operational context.
Whole-building communication
Teams used these views together to communicate material flow across the entire site.
Indianapolis
The request: Understand sorter behavior and recurring jams.
Engineering tracked sorter problems in spreadsheets. During peak periods, someone could be stationed nearby to watch the equipment and help keep product moving.
The workaround revealed missing equipment-state information and an ownership problem. The question became which conditions engineers actually needed to see in the supported system.
One sorter area
The team coordinated monitoring and decisions for a single sorter area.
Chicago
The request: Make inbound productivity easier to understand.
Chicago relied on TV dashboards and whiteboards, while requesting at least five tools from other sites. Significant modifications were needed for its unique equipment and operating setup.
Definitions, available data, equipment and workflow differences determined what could actually be reused. Copying the interface alone would not solve the underlying problem.
Site-specific adaptation
The site requested at least five tools used elsewhere, with substantial modifications for its own setup.
Topeka
The request: Coordinate how product enters downstream gaps.
Topeka built its own Splunk dashboard to see and manage how product entered the flow. That approach later informed the Gaptimizer dashboard for Jetson.
Both overfeeding and underfeeding could reduce throughput. A local control decision made sense only in relation to capacity and timing farther through the flow.
Local dashboard to Jetson tool
A locally created Splunk dashboard was later repurposed into the Jetson Gaptimizer dashboard.
Instead of rebuilding similar solutions for each facility, the product direction focused on reusable patterns, discoverable tools, and configuration for legitimate site differences. Material Flow contributed to the direction of a broader platform evolution.
The backlog was more than a queue of unrelated fixes. Grouping related tickets into a larger Material Flow epic made the recurring problem visible and gave the work a shared direction.
Before
Warehouses copied tools from other sites, then adapted them locally. New facilities had no single dependable starting point.
Local changes created independent versions that did not automatically receive improvements from other warehouses.
Future
A central library maintains the same base tool while supported features can be enabled for each facility.
Shared tools could remain consistent while supporting legitimate differences between facilities.
The investigations separated what could improve immediately, what needed a unified tool, and where local variation needed greater support.
I revised the motor-status pattern so people could recognize operating conditions without decoding inconsistent OK, YES, and NO labels.
Use condition-specific language so people don’t have to infer whether “YES” or “NO” indicates a problem.
Show the possible conditions together and highlight the active state.
These incremental improvements could be applied across site applications and placed in EAM for future synchronization.
I prototyped a comprehensive Material Flow tool to connect recurring needs across warehouse operations. The direction was a shared application that could be hosted in EAM and distributed across sites, while accommodating differences in equipment, layouts, and workflows.
Bring warehouse areas into a shared view so teams can examine how activity in one part of the building affects another.
Use common navigation and interaction patterns while mapping each facility’s equipment and operating relationships accurately.
Live equipment signals and delayed operational data needed to remain distinguishable when presented together.
Applies across all facilities using the tool.
| Element | Purpose |
|---|---|
| Tool type | Establishes the shared tool purpose, interface, and core functionality. |
| Facility type | Defines the common experience appropriate to that kind of facility. |
Enables site-specific information and functionality.
| Element | Purpose |
|---|---|
| Vendor | Enables relevant vendor-specific indicators and information. |
| Equipment | Determines which equipment-specific icons, metrics, and capabilities appear. |
| Version | Accounts for differences in supported features and information between versions. |
A shared tool structure provides consistency across the warehouse network. Local configurations account for vendor, equipment, and version differences, enabling relevant icons, metrics, and functionality without creating separate tools for each site.
Facilities retain a consistent tool experience while seeing the information and functionality relevant to their particular equipment.
