The Problem

Analyzing the flow of mail (mailflow) in the Postal Service is very challenging due to the varying ways that mail moves through a processing plant. Advertising mail has a different delivery standard than first class mail, parcels, periodicals and expedited products such as Express and Priority Mail, so these different types of mail have separate streams within a facility.

All of these separate mailflows moving through automation and mechanization within a postal facility create a complicated web of physical and information flows associated with each mail stream.

Existing Simulation Model

The existing simulation model that is used in the Postal Service requires a week of training to learn to use and requires someone who already has a very good understanding of mailflow. It is not intuitive. The user enters volumes of each mail type, operation numbers, arrival profiles, maintenance schedules, percentages of mail that flow from one operation to another, and so on. The simulation produces equipment requirements in order to process the associated volumes of mail. The user must trust the simulator since it produces only the final results in table format.

Additionally it does not calculate people requirements (staffing) let alone attempt to optimize staffing according to varying workloads. Another major problem is that if a person who is proficient with the simulation retires or changes positions, the learning curve for the replacement is significant.

Since many postal managers and supervisors don't really understand the mailflows or the impact one mailflow has on another, one of the key benefits of using a tabletop system would be to develop intuition of these mailflows. A simulation tool that allows hands-on manipulation of various operations would allow a small group of people, such as the managers of one plant, to work with the model collaboratively around a tabletop.

This would be invaluable to help postal managers figure out how to balance workhours to workload and increase throughput of time-sensitive mails. It would also give them the opportunity to physically place equipment in adjacent patterns to visualize actual movement of mail, something that the current computer simulation model can't do.

Using the Media Lab's Programmable Brick Technology

The Engineering Vice President of the U.S. Postal Service, after seeing a demonstration of the Crickets simulating possible delivery scenarios, asked if a physical model could be built simulating actual operations in a postal processing plant. In September 2001, Bakhtiar Mikhak, Tim Gorton and I attempted to create an engineering prototype using Crickets and Microworlds software to simulate mailflow in a postal facility. One mail type, pre-barcoded letters (remittance mail) was chosen. This mail type is referred to as FIM (Facing Identification Mark, the vertical bars on the face of an envelope adjacent to the postage indicating that the letter has a barcode). An actual volume arrival profile for FIM mail was provided based on a high volume Monday in the Boston Processing and Distribution Center in South Station.

Prototype System [more information on the prototype]

Each operation that FIM mail might flow to, depending upon the letter's address, was designated as a node in the system and the associated characteristics were assigned. A separate Cricket represented each node. Each Cricket transferred the mail flowing from one operation to another and statistics were stored at each node. The characteristics were initially intended to be variable (operational throughput, operational staffing, threshold on-hand volumes etc.) however the memory limitations of a Cricket soon forced assignments of values for each variable. The ultimate goal is to allow each variable to be controlled at the appropriate node by the user in a hands-on manner. This requires a redesign of the Cricket-based system to increase the memory, processing power, and communication capability or each node. The 9-volt batteries used to power the Crickets also proved insufficient to operate the nodes for longer than a few hours.

The result of each simulation run produces the workhours and start/end times of each operation. This will allow the managers of a particular operation to staff each operation.

Feedback from the Postal Service

In November 2001 I demonstrated the model to a group of thirty technical people in the Postal Engineering Group. They asked lots of questions and saw the value of such a tool. I was asked to develop a model for a proposed revised mailflow, sequencing of flat-size mail (mail bigger than a letter) for letter carriers.

This mail type is currently sequenced (in delivery order) manually by all 300k letter carriers throughout the country and requires an average of one hour per day for each carrier for a total cost of $9 million daily. If this operation could be mechanized there would be significant labor savings. If, for example, in the Boston area this were implemented it might save as much as $100k every delivery day for a total of $30 million per year. There would of course be a cost for equipment, space, maintenance, power, labor etc. to mechanize this operation and a simulation tool that provides the means to estimate the potential benefits of such a change is not currently available.

This simulation tool would provide a hands-on model which would help managers visualize the operation and determine how much equipment would be required, what window of time during the day would be needed, staffing requirements and what the return on investment would be. Various scenarios could be compared to find the optimal solution(s). Extending the current prototype model to fulfill this purpose presents a real challenge for the Media Lab and for the Postal Service.