GB560 Unit 6 Seminar Reflection Example

Seventeen Percent of Returns, Twenty-Seven Percent of the Labor: A Unit 6 Seminar Reflection on Exceptions

[Student Name]

Purdue University Global

GB560: Designing, Improving, and Implementing Processes

Unit 6 Seminar Reflection

[Instructor Name]

[Date]

The seller, its returns center, the weekly tally and the seminar classmates are composite and illustrative; the sources cited are real.

The Position I Brought

My notes from the week before the seminar say it plainly: "Exceptions are rare, and the problem cage handles them." I had spent three units mapping and timing the standard path, and I treated anything that left it as a small, messy remainder that a redesign could ignore. The current state map showed the problem cage as one loop among three, and the timing analysis showed that returns without authorization were under 12 percent of the sample. I came to the seminar expecting to argue that the redesign should fix the main path and leave the cage alone.

The Count

Before the session, the instructor asked each of us to define an exception precisely and then count them for one week. I defined an exception as any return that cannot follow the standard path without a decision the written procedure does not cover. That definition mattered, because a vaguer one would have let me count whatever suited my argument. The tally for one week came to 246 of 1,450 returns.

No usable authorization: 157. Bundles returned with pieces missing: 38. Gift returns with an unclear refund recipient: 27. Recalled units: 12. Items belonging to a marketplace seller: 12.

Then the time. Standard returns took 11.4 minutes of handling each; exceptions averaged 21 minutes. The 1,204 standard returns used about 229 labor hours that week, and the 246 exceptions used about 86, out of roughly 315 in all. Seventeen percent of the volume took 27 percent of the labor.

I had been treating a fifth of the work as noise because it did not fit the map I had drawn.

The Remark

A classmate who runs a hospital admissions office listened to my tally and said that the problem cage is not a process but a place where the process stops. I wrote it down because it named what I had missed. The cage has no steps, no owner and no clock. Returns go there when nobody knows what to do with them, and they leave when someone finds time. The five kinds of exception each need a different decision: identifying an order, contacting a shopper about a missing piece, finding a gift's purchaser, following a recall procedure, routing an item to a marketplace seller. The cage treats them as one pile.

Why My View Was Wrong

Frei (2006) argues that customers bring variability into service processes, in what they request, when they arrive and how prepared they are, and that a process designed only for the average customer will struggle with everyone else. My map had been designed for the average return. Hammer (1990) warned against designing a process around the standard case and handling everything else by exception, because the exceptions then consume the time the standard path saves. Spear and Bowen (1999) describe well-run processes as ones where every path, including the unusual ones, is specified, so that problems surface instead of piling up. The cage is a pile.

I also realized that my own earlier analysis had understated the problem. The timing analysis measured how long exceptions took to reach a refund, which showed the delay to shoppers. It did not measure how much of the staff's time they consumed, which is what the seminar tally showed. Both matter, but I had only looked at one.

What I Would Measure Next

The tally covered one week, and I would want more before drawing the new lane. In particular, I would count how long each kind of exception waits before anyone touches it and how long the decision itself takes once someone does. My guess, from watching the cage, is that the waiting dominates and the decisions are quick once the right person sees the item, which would mean the fix is ownership and routing rather than more skilled staff. I would also count how many exceptions repeat for the same reason each week. If 157 returns a week arrive without a usable authorization, the more useful question is why the authorization barcode fails so often, not how fast the cage can clear them.

Where I Ended Up

My view has changed. Exceptions are not a remainder to be ignored. They are a fifth of the work and more than a quarter of the labor, and they need their own drawn path and a named owner, not a shelf. I will not design that path here; that belongs to the proposal in the next unit. But I now expect the redesign to fail if it treats the standard path as the whole process, and I will start the proposal by drawing the exception lane before I touch the main one.

References

Frei, F. X. (2006). Breaking the trade-off between efficiency and service. Harvard Business Review, 84(11), 92-101.

Hammer, M. (1990). Reengineering work: Don't automate, obliterate. Harvard Business Review, 68(4), 104-112.

Spear, S., & Bowen, H. K. (1999). Decoding the DNA of the Toyota Production System. Harvard Business Review, 77(5), 96-106.