December 1996 € Volume 23 € Number 6

Special Delivery

New, sophisticated software helps United States Postal Service sort out complex problems while identifying $2 billion per year in potential savings

By Michael D. Lasky and C. Teo Balbach

Every day the mail arrives at your door step. Every few days, you drop a few letters into the blue mail box, and you forget about them. While most of us recognize our mailman, few of us stop and perform some simple reasoning: If a mail carrier visits our house every day, then other mail carriers must also visit every other home in America, every day.

More accurately, some 220,000 mail carriers combine to visit every home in America, six days a week, every week of the year. While some simple statistics about mail carriers start the logistical mind spinning, it is important to note that mail carriers are only the tip of the postal iceberg -- most of the postal work is performed by hundreds of thousands of clerks working throughout the night. In total, the United States Postal Service employs more than 800,000 people who focus on getting the mail across town, across the state, across the country to your door.

The United States Postal Service is an independent, $55 billion a year organization. All of its funding comes from stamp revenue, none from tax dollars. The USPS is essentially a massive, regulated utility spanning the nation. There are five times as many local post offices as there are McDonald's franchisees in the United States.

The Postal Service has its fair share of problems, as most people are well aware:

the letter that arrives three days late,
a counter worker at the local branch who never seems to hustle.

Despite these concerns, the USPS performs an impressive array of operations and logistics on a daily basis, and is continually striving to improve its operations.

Approximately two and a half years ago, the USPS committed itself to another major step in its long-term plan to automate mail processing through the use of bar codes. The plan called for a half-a-billion dollar equipment and facility purchase to be spread across 98 sites around the country. While each site essentially performs the same task, the nightly operations of any two sites can look completely different. Every site has different mail volume, a different arrival profile for mail, and a different amount of processing equipment.

A major deployment of this same automation equipment had previously been rolled out to 40 trial sites with some success, so the technology had been proven. Unknown, however, was the extent to which particular local operations would be affected by this massive "Phase II" deployment to the next 98 sites. How many of hundreds of jobs would shift within each plant? Would there be enough bar code sorters to sort all of the mail once the new equipment had processed it? Because of equipment, space and potential job loss considerations, these questions and many more were critical to the planning process of each site.

The problem
The Postal Service relies heavily on optical character recognition technology to place bar codes on mail. Once a bar code is on a piece of mail, it can be sorted by a bar code sorter at approximately 12,000 pieces per person-hour. If Optical Character Recognition (OCR) cannot resolve the address, the letter drops into a "mechanized" stream, where it will be processed by 1950s-era technology at about 1,200 pieces per person-hour, or approximately a ten-fold decrease in efficiency for all downstream operations (see Figure 1). Further, once a piece of mail falls out of the automated stream, it is doomed to stay in the less efficient mechanized mail stream until it is delivered.

While Figure 1 clearly illustrates the labor savings from processing bar-coded mail, the true potential for enormous cost savings from barcoding exists at the carrier level. If enough mail is properly bar coded, it can be precisely sorted before it reaches the carrier, removing 25 percent of the carrier's daily total workload. When mail sorted by a mechanized letter sorting machine (LSM) arrives in a carrier's hands, the carrier must still spend an additional four hours sorting that mail (after which the carrier spends four hours walking his route and delivering the mail).

If a facility can get a critical mass of mail into the bar-coded stream, it is possible to precisely sort the mail before it reaches the carrier. This precisely sorted mail cuts the carrier sorting time in half, saving two hours of carrier time every day. With the extra time, the carriers could walk longer routes, thereby reducing the total number of carriers needed. Remember that there are approximately 220,000 carriers, so a two-hour savings every day has a potential cost savings of well over $2 billion per year.

For good, typewritten addresses, the OCRs at the Postal Service have a read rate of around 60 percent, with 40 percent dropping into the inefficient mechanized stream. For handwritten mail, an OCR has a read rate of about 2 or 3 percent. In order to deal with the problem of sloppy mail and handwritten mail, the USPS developed a set of technologies called the Remote Bar Coding System (RBCS). Under RBCS, an OCR "lifts the image" of any letter for which character recognition has failed, and the digital image is sent to a remote site. At the remote site, the image is presented on a screen to a worker, who reads the address displayed on the letter's image and keys in the appropriate information.

Once a proper bar code has been associated with the image, it is reunited with the letter. When the letter originally had its image lifted, it was sprayed with a fine pink bar code reserved for later use. (If you look on the back of a letter that you have received, you will often see this pink bar code.) The letter is run through a bar code sorter, which reads the pink bar code, queries the database, and applies the appropriate black address bar code to the front of the letter.

RBCS technology is a gamble. While you get mail into a more efficient mail stream, you are significantly complicating the floor operations of an already complex process. Also, the RBCS implementation bets that it can generate enough precisely sorted mail to achieve enormous labor savings at the carrier level. Before each site could implement this technology, some critical questions needed to be answered on a site-by-site basis:

How many images would arrive at the remote site?
What is the volume profile of images by time of day and by day of week?
What is a plausible labor schedule for workers at these remote consoles?
Would there be enough bar code sorters available to process all of this newly bar coded mail?
If more bar code sorters were required ($250,000 each) would their be enough room to fit them in the building?
How much labor savings would be generated by moving mail away from the inefficient letter sorting machines?
Given the extra bar code volume and the one-and-a-half hour delay generated by the remote encoding site, would there be enough time in the critical early morning hours to process all of the mail on the bar code sorters?
In short, what does each site need to do to prepare for the arrival of the new technology?

The Solution
A total of 98 sites needed to be analyzed for this equipment deployment, and it was soon clear that this was a modeling problem of enormous proportions. Not only was a powerful modeling tool necessary to capture the complexities and nuances of postal operations, but this tool needed to be flexible enough to build site scenarios for 98 unique facilities.

Because of the intricacies and peculiarities of postal operations, off-the-shelf modeling packages were either inappropriate or too slow. Under the supervision of Dr. Michael Lasky, a team of software engineers at Kenan Systems Corp. developed a software engine which could accommodate the postal work rules, flow network and operations methodologies, while simultaneously generating a set of machine schedules and a corresponding labor schedule. A flow-based software model was already under construction by Kenan Systems for postal site modeling for different purposes, and this model was used as a point of departure.

The software tool is called SiteMETA, which stands for Site Model for Analyzing Technological Alternatives. At a high level, it is a node-based flow model that is sensitive to time. The software is set up to accept different flow networks, the way a spreadsheet engine like Microsoft Excel can accept different spreadsheets. The software is a Microsoft Windows-based application and the user interface was originally written in Visual Basic and later converted into Visual C++.

The back-end model performing all of the calculations was written in C, and all of the data was stored in a local callable database called Raima Data Manager. While the background model resembles a network flow model from an analytical perspective, SiteMETA generates its flow network hierarchy through the use of a topological sort. Separate machine and labor scheduling algorithms are called to assign facility resources to this sorted flow network.

The complexity of the labor scheduling routines required a 32-bit architecture, so the original model required the Microsoft "Win32s libraries" in order to run under Windows 3.1. The front end and database were converted into 32-bit architectures as soon as the development tools became available. While the software is technically sophisticated, all of the development efforts would be wasted if the software did not appear to "think" about operations problems in the same way that postal managers think about their daily problems.

As the software grew, the development team made periodic field trips to show progress to site managers and floor managers. For the initial months, the focus of the project was on pushing the software to answer more and more questions. The software was originally designed to model the operations for a single day; after meeting with managers in Portland and Dallas, the model was changed to operate on a seven-day-a-week basis. Because mail volume varies so dramatically over the course of the week, postal managers think of their staffing and operations issues on a weekly basis. While most of the critical analysis arguably could have been performed on a one-day basis with the proper assumptions, it was critical to enable the software to mimic how managers envision their operations problems. The model was also altered to operate on a half-hour basis for a total of 48 time slices a day for every day in the week.

Having watched postal managers use the tool, the Site META team made many small but important changes to the user interface design to make it more friendly and accessible to the postal manager. After many months fine tuning the software engine to managers' concerns, the focus began to shift to the generic flow template upon which all sites would eventually base their local models.

The generic flow structure tries to set up a flow framework that describes the operations of the average postal facility. The process of adding and deleting flows from the flow network requires more work than simply adjusting existing flows, so accuracy in the flow template minimizes the work of postal managers learning to use the system. Fine tuning the flow template was critical to the success of the entire project. If the generic flow template did not behave in a fashion that was similar to the manager's way of thinking about their operation problems, it was entirely possible that managers learning the system would push back on their senior executives and effectively scrub the whole project.

In order to improve the flow template, several sites were modeled and the results were shown to postal managers. The lessons learned in these initial modeling sessions were incorporated into the generic flow network, and the final flow template grew to have 150 processes or nodes, and over 700 flows or arcs. While these numbers might not seem high, remember that the model is calculating machine schedules and labor requirements for each of the 150 processes for 48 time slices every day, seven days a week.

Customizing the Model to Each Site
It soon became apparent that developing a comprehensive scenario for a single site was a major undertaking. The model was data hungry, requiring thousands of inputs for a single scenario. Each scenario required extensive data on the daily arriving mail volume, the arrival profile of that mail (7 percent at 8:30 p.m., 16 percent at 9 p.m., etc.) and an ocean of facility-specific infor mation such as accept rates, process start and stop times, machine inventory, staffing indexes, etc. To manage all of this data, three separate software programs were developed solely for the purpose of collecting, manipulating and feeding data into SiteMETA.

The mail volume tool and the volume arrival profile tool (both written in Visual C++) churned and analyzed data that had been stored in a characteristically cryptic fashion on the corporate mainframe. The facility information tool was a simple questionnaire database that allowed a facility expert to input hundreds of datapoints about his facility in a user-friendly fashion.

Because of the difficulty in creating a site scenario from scratch, SiteMETA experts at Kenan Systems developed an initial scenario for a site, drawing from mainframe volume data, the site's facility questionnaire, and phone conversations with the postal facility's operations expert. Once the initial scenario was complete, representatives from a site came to U.S. Postal Service head quarters in Washington, D.C., for a week of training alongside four other postal facilities involved in the same planning process.

During the week of training, postal managers learned how to use the software. The training process was challenging because postal managers brought such diverse modeling and computer backgrounds. Some managers had been modeling their opera tions for years, and they were excited by the power given to them by the new set of tools. Some managers knew their site operations very well, but had never handled a modeling problem before and were unfamiliar with a mouse and the Windows environment.

After some initial training, the postal managers received the initial scenario of their site developed by the SiteMETA expert. At this point, ownership of the scenario passed to postal site managers, and they added the final, critical pieces of operations expertise into the model. Almost every site had some unusual set of processes that were not captured in the generic flow template, and postal managers consulted with SiteMETA experts on how to best implement their desired functionality. The model's flexibility allows the user many different ways to solve a given problem, and the postal managers and software experts discussed the merits of each.

Once the Postal managers were familiar with the software and with their scenario, they attempted to develop an accurate "baseline" scenario which properly modeled the operations of their facility. After a baseline model was built, managers simply threw a few switches in the flow network to activate the complex new set of "image lift" flows required by the change in floor operations described in Figure 2.

The Outputs
The model generates an enormous amount of output for postal managers to digest. The model produces a half-hour-by-half-hour machine schedule for an entire week, resolving capacity and machine contention issues. After the machine schedule is completed, an initial labor schedule for the week is developed in accordance with the Postal Service's labyrinthine work rules. If a user is satisfied with the outputs of a particular scenario, he might also run an additional labor schedule optimizer. This more sophisticated scheduler produces an optimized person-by-person labor schedule for an entire plant (possibly thousands of people) using a non-linear optimization technique called simulated annealing.

The very first result of the SiteMETA was to reveal flaws in the underlying data. SiteMETA was very quick to illustrate internal inconsistencies in a site's data sources, and all major problems needed to be addressed before a site could complete its baselining process. With the baseline model complete, postal managers began to forecast their site-specific labor and machine requirements for a massive overhaul to their existing operations.

The Results
In the initial round of modeling, 98 sites were modeled to determine how many jobs would be gained at the new remote image sites. Also, each site needed to determine if its pre-existing equipment allocation was enough to process all of their mail using these new operations. According to the numbers produced by the SiteMETA, the software experts and the postal managers, approximately 24,000 job positions at remote sites were posted around the country. Now that sufficient bar codes are becoming available to precisely sort the mail, USPS management is beginning to focus on capturing the savings generated at the carrier level. Because of the strong carrier unions and the logistics involved with restructuring the carrier routes, capturing this savings will be a lengthy process. In addition to the labor analysis, the modeling process revealed that several sites needed additional bar code sorters. The analysis allowed the sites to have more of the $250,000 machines in place when the operations changeover occurred.

In addition to the 98 sites described in this article, the 40 sites already running the initial deployment of this remote technology subsequently used SiteMETA to forecast the impact of small changes to their operations. Currently, more than $100 million has been allocated to bring this new operations technology to the remaining 100 mail processing facilities. The sites in this "Phase III" deployment are currently modeling their facilities and learning how to use the software tool; the final round of training is due to be complete by the end of the year. Once this final round of training and baselining is complete, every significant mail processing facility in the United States will have completely modeled their processing facility using an advanced suite of custom designed software tools for modeling, scheduling and forecasting.

Other Uses of SiteMETA While SiteMETA has primarily been used to forecast the effects of the operational overhaul generated by the remote image facilities, it is important to remember that the underlying software is a generic modeling tool which can be applied to a host of other modeling problems.

The software suite and the software experts at Kenan Systems were brought in to develop a model of the enormous and problematic Chicago central mail processing facility. A new facility was under construction, and changes in the greater Chicago mail routing network brought into question whether all of the necessary equipment would fit into the new facility. The modeling and forecasting team built a scenario to model the Chicago facility (with volume of approximately 50 million pieces a week) and provided quick-turnaround analysis for postal managers under immediate decision deadlines.

The software was also used to model a proposed nationwide network of Priority Mail hubs. A proposal was put forward to build a dedicated network of 78 Priority Mail facilities nationwide to handle the nation's annual volume of almost one billion pieces of Priority Mail. SiteMETA was used to develop a labor forecast for each facility. Because Priority Mail flows are so different from standard mail flows, an entirely new generic Priority Mail template was constructed for the endeavor. Individual site models were built using the generic flow template and forecasted volume estimates.

Dr. Mike Lasky is a Project Manager with the Kenan Systems office in Washington, D.C. Teo Balbach is an independent information systems consultant and has worked at Kenan Systems and at the Microsoft Corp. in Redmond, Wash. Lasky and Balbach design large, custom software solutions for complex modeling problems.

For more information, put the number 5 in the appropriate space on the
Reader Service Form

E-mail to the Editorial Department of OR/MS Today: orms@lionhrtpub.com

Lionheart Publishing, Inc.
2555 Cumberland Parkway, Suite 299, Atlanta, GA 30339 USA
Phone: 770-431-0867 | Fax: 770-432-6969
E-mail: lpi@lionhrtpub.com