For over 40 years I have taught applied modeling—at eight different universities, engineering and business schools, graduate and undergraduate levels. I have taught using paper and pencil for quick-and-dirty models, calculators, mainframe computers, and now PCs with spreadsheets. Generally, I have four goals for each class, and the fourth is:
Be able to actually identify problems at work and use appropriate statistical spreadsheet models after the course is over.[1]
I wish I had kept better track of the emails and stories from my students about how modeling has affected them over my eleven years here at Pepperdine, but here are a few of their stories:
One student was an office manager for a large southern California medical center responsible for handling patient appointments. She was informed that her budget would be cut by 20% and that she would have to let several employees go. Immediately, she knew this would impact the number of appointments that could be scheduled and thus reduce the number of patients and subsequent revenue. At the time, she was taking the Quantitative Analysis for Business Operations MBA course at Pepperdine and was delighted that her group’s first case was a call center scheduling integer programming model ideal for her situation. She fed in her own data, ran it with the number of her current staff and then with the reduced staff and showed her boss the impact of the 20% budget reduction. The boss immediately rescinded the budget cut because he could see the negative impact on revenue. So the model wasn’t used for scheduling the individual workers as intended, but just showing the impact of having fewer workers was dramatic enough to allow the student to keep her budget.
LESSON: Models don’t always have to solve problems—sometimes they can effectively show the problem.
Right after the disastrous unmanned missions that crashed into Mars, a former student working at JPL emailed me with her problem. JPL now required teams to watch each subsequent journey 24/7, which meant 12-hour shifts three and four days a week. Group A worked days for three days one week and four days the next; Group B filled the rest of the days; and Groups C and D split the nights. After two months, each group switched from nights to days and vice versa. The mission specialists were complaining because one week they’d get paid for 48 hours’ work and the next week for 36—accounting refused to average it out to 42 hours per week. The student remembered we had used a scheduling template in class and wondered if I could fix the problem. My first thought was highly technical with thoughts of all kinds of fancy schedules, but after thinking about it for a few hours and trying some different schedule configurations, I had a “flash of the obvious” and realized that minimizing costs made no sense because they would always be paid for an average of 42 hours per week. It then dawned on me that if Group A worked three 12-hour days and then 6 hours on the fourth day, Group B could finish up the that last shift for 6 hours and then the next three 12-hour days to complete the full week. Groups C and D could have a similar schedule for the night shift. There was nothing to optimize. Simply by reconfiguring the schedule, every employee would always be working 42 hours per week and accounting be damned! I got an email back two days later saying JPL was ecstatic—they had never thought of splitting the shifts!
LESSON: Sometimes models don’t have to be solved – they just help lay out the problem so that the solution just presents itself.
For homework, a student working in the finance industry was going over the simple capital budgeting integer programming model when he realized that he could utilize the model at work. He had been going to work at 5:30 and using his finance calculator to do an hour’s worth of work before being able to allocate the $30M or so in investment funds. Now he saw that he could write a simple model that required only five minutes of new input, run it in a few seconds, and have a junior worker come in early to enter that day’s allocations. He would be able to get in at a normal time and all he’d need to do was double-check that the money had been allocated correctly.
LESSON: A simple model can be easily given to an employee to use and remove a lot of manual labor for everyone and then be checked for accuracy later.
One student was the director of marketing for an international producer of welding equipment Each week the company’s forecasting team—VP Sales, Director of Marketing, Master Planner, General Manager, and VP Supply Chain—met behind closed doors to develop and review the monthly production build plan. Historically, they based their monthly forecast on existing materials inventory, sales performance by model, upcoming promotions, and overall consensus within the group. After a review of the month’s operating performance, the VP of Supply Chain challenged the group to come up with a build plan that maximized its monthly available production hours of 25,000 with a target of 80 machines per month. The student accepted the challenge and agreed to present an initial model the following week. This type of decision usually took several days each month but the student worked out a very simple integer programming model that included the upper and lower bounds for each machine, the profit, and the number of hours to build and ran in a few seconds. This model is now the benchmark for an optimized monthly product build schedule. The upper and lower bounds fluctuate depending on demand, sales forecast and other factors; however, the forecasting team now has the ability to measure the variances between the optimal profit and hour’s maximization from the final build schedule. After the meeting, the VP of Sales and Director of Marketing collaborated on a product promotion strategy that encouraged the sales force to push the optimal product mix. Before, the production build plan was based mostly on demand and gut-feel which resulted in lower profits and less used production hours. Now that the production schedule is optimized, the team can direct the sales force and marketing to push the various products into the right markets yielding the highest profit and production maximization. The CFO told the student that he had just earned his first semester’s tuition at Pepperdine (which the company pays for).
LESSON: Sometimes a simple model can drive the production decision which in turn drives the marketing of the product, instead of marketing determining what should be sold.
Mid-way through the MBA program, one student interested in the business side of pharmacology was approached by a large supermarket chain, which saw the future of mega-stores with pharmacy operations. They offered him a job in sales where he would be assigned the territory of northern California and would need to visit 10 pharmacies each day, two days a week, while still going to school at Pepperdine in southern California. He used a simple template for the traveling sales problem to find the shortest distance to fly up to San Francisco and visit two sets of 10 pharmacies in two successive days and then make it back to classes. Although the model was a “quick-and-dirty” solution, it shaved a few hundred miles and a couple of hours of travel from his best estimate. It did this in less than 15 minutes on a PC using the Solver’s “All different constraint” versus hours of mainframe computer time to find the optimal solution, which might have saved only a few more miles and minutes.
LESSON: Sometimes the near-optimal solution is cheaper and faster in the long run than an expensive, optimal model solution.
This student, Jed, was the plant manager of Puretec, an industrial water purifying company located in Ventura, CA, which was owned by his father, president of the company. The student’s first class in the MBA program was the Quantitative Analysis—not his favorite subject, but he really liked the idea of how data could be collected on spreadsheets, graphedn and shown to others. Although the Puretec was very successful and growing, he had no idea of how many tanks were being processed (recharged for ionization), or were out in the field, etc. So during class he started developing spreadsheets to aid his workers to see what was on the floor, entering data for each job so that it didn’t have to be re-entered, and keeping track of things. His workers loved it, and he became more and more proficient at linking worksheets to pull the information about the business so that it could be seen and analyzed. One day, after my lecture on queuing (waiting lines) he “saw” that the tanks waiting to be serviced on the plant floor were just like people waiting in line, and decided to change the procedure. Rather than having them done one at a time, with a worker setting it up and then waiting 20 minutes to have the tank re-ionized, Jed saw there was a lot of wasted time when the worker had to “watch” the process. So he quickly changed the set-up to do four tanks at a time. This took twice as long to set up but the same amount of time to re-ionize four tanks as it did one. The workers balked at the idea but trusted him because he had already implemented some time-saving techniques. Everyone was amazed that what used to take a full day to do was now done by noon! The student didn’t run any models – he just understood the principles of the model and applied them.
LESSON: Just understanding the basic assumptions behind models can lead to time and cost-saving changes in business operations.
(Read more about Jed’s newfound love for quantitative analysis on the Graziadio Voice student blog.)
[1] Allen F. Grum and Rick Hesse, “It’s the Process Not the Product (Most of the Time),” Interfaces, 13, no. 5, October 1983.
Related in the GBR
Electronic Spreadsheets: The Good, the Bad & the Ugly by Rick Hesse, DSc
