Keynesian Economics in 1360?

I recently tripped across this in Prague. Originally built by Emperor Charles IV, this old city wall was built to protect Prague and some of it still stands today. Two local students who were touring us around the city told me that Charles IV had it commissioned in order to provide work for Prague's people who were suffering from a famine at the time. "Keynesian Economics!" I said.

I found this interesting in a time where the media, public opinion, and politicians suddenly all seem to believe and support Keynesian Economics completely.

Unfortunately the Prague city website reports that this is all a myth and that the wall was already under construction when the famine struck. This cannot be called stimulus money after all. For anyone who has been following the recent stimulus efforts, you could say that this wall was "shovel-ready."

Lean Prison Management

Two weeks ago, Dawen and I were in San Francisco. A mandatory tourist stop is the Alcatraz tour/cruise. Despite the poor weather, we elected to take the cruise and enjoyed an interesting visit to the island, including the award winning audio tour. While on this tour, we noticed an application of the lean principle of poka-yoke or mistakeproofing.

Alcatraz was a super-ultra-max security prison lasting 29 years from 1934 to 1963. High profile and extremely dangerous prisoners were sent here and security was tight. Guns and knives, naturally, were kept secure, but food still had to be prepared in the kitchen. Thus was born the knife board. This was a piece of wood in which each knife had it's shape cut out as a home so that it could be easily determined if a knife was missing.

Lean or Lean manufacturing has an interesting relationship with Operations Research. While Lean is not a component of Operations Research, many of the same principles are at play in its execution. They also typically share the same goals and the same field of play. Lean approaches can be excellent tools for implementing changes recommended by OR analyses. The focus of Lean is the elimination of wasted time and resources in business processes. The key to lean is the grass-roots approach it takes, involving process owners and front-line workers in the problem identification, and solution process.

The audio tour is a largely solitary endeavour, so we did not discuss it immediately. Being the sort of people that we are, though, Dawen and I both noticed this and spoke with each other about it immediately afterwards. It would be interesting to look for more applications of Lean to prison management. Perhaps one that minimizes inventory?

ThinkOR's authors looking for Operational Research positions in Europe

ThinkOR's authors are looking for exciting Operational Research and Operations Management work opportunities in western Europe. Aleksey and Dawen are moving from Canada to Europe to further and broaden their work and life experiences.

We are flexible in the cities we reside in and the industries we work in, so long as the problems are interesting and that we can contribute to the development of an exciting organization. If you or someone you know are looking to hire English-speaking OR consultants, please contact Dawen at dawen[dot]peng[at]gmail[dot]com and/or Aleksey at aleksey[dot]nozdrynplotnicki[at]gmail[dot]com. Our high-level resumes are available on LinkedIn (Aleksey and Dawen). Detailed resumes and references are available upon request. Your help is greatly appreciated. Advices are also welcomed on OR job hunting in Europe.

Since we will be in Europe, if you'd like to meet and chat, we'd certainly be glad to meet more fellow Operational Research professionals. Just shoot over an email to connect.

Breakfast optimization :)

At the end of his course on mathematical methods in optimization, the professor sternly looks at his students and says: "There is one final piece of advice I'm going to give you now: Whatever you have learned in my course - never ever try to apply it to your personal lives!"

"Why?" the students ask.

"Well, some years ago, I observed my wife preparing breakfast, and I noticed that she wasted a lot of time walking back and forth in the kitchen. So, I went to work, optimized the whole procedure, and told my wife about it."

"And what happened?!"

"Before I applied my expert knowledge, my wife needed about half an hour to prepare breakfast for the two of us. And now, it takes me less than fifteen minutes..." 

VBA: Alive and... Well?

The future of Visual Basic for Applications (VBA) has been recently called into question. In March 2008, Microsoft dropped their extended support for VB6 and the Microsoft Office 2008 for Mac did not include any VBA functionality.

This is a cause for concern in the applied OR community. In my recent post about the use of Excel for modeling, all four examples relied heavily on VBA. The ability to rapidly develop models using both cell formulas and VBA scripting is invaluable. Taking that a step further, the interface components and widely available platform of Excel are useful when developing end-user tools for clients.

Luckily our fears can be generally put to rest. An MSDN blog article: The Reports of VBA's Demise Have Been Greatly Exaggerated has assured us that:

"[T]he next generation of the Microsoft Office system will definitely contain all of the functionality that developers and power users expect from VBA."

None of this is breaking news if you're on the lookout for it, but if you're an academic director paying close attention to the relevance of your course/project work it's certainly a current issue.

Personally I'm more interested in the questions that all of this raises rather than answers. With Visual Basic (.NET) 9 and C# as viable options for interoperability between general purpose programming and Microsoft Excel, I find the more interesting question to be: Should we be coding tools with VBA?

Ease of development is one thing, but are we really asking too little of ourselves? Sure someone from a non-software development background can develop a subroutine for Excel, but is that really optimal? Personally I think anyone practicing OR should have at some point learned to code in a modern Object Oriented programming language. It's not that difficult and it really maximizes your efficacy. What it takes to teach someone to code pales in comparison to the sheer educational investment necessary to get someone from high school mathematics to Markov Decisions Processes.

With a little effort C# inter-operating with Excel could produce a much "better" solution than VBA. With a modern IDE and a little experience C# can be coded with relative speed. Indeed I did just this when producing a prototype tool for my Masters project. I must admit, though, that deployment did not happen completely without a hitch. Just because I know how to code does not mean I can comfortably shrug off all of the benefits of VBA/Excel including deployment-by-mailed-attachment.

Philosophically matching the weight of the task to the weight of the approach is difficult. It would be irresponsible to code a truely complex application in VBA. Then again, it might be dishonest to dress up a hatchet job of a solution in the guise of an industrial application.

To sum the above three paragraphs up, the part of me that almost took Computer Science as an undergradutae degree fails to find VBA as an acceptably elegant solution. That said the (clearly much louder) part of me that DID take a Business graduate degree sees the silver lining:

• I read an article by Simon Murphy defending VBA and much of it rang true.
• Some would promote OpenOffice Calc as an alternative to Excel because it's free and non-proprietary. I would disagree. Excel/VBA solutions are good because their platform is free at the margin. Every organization has, has had and will have Excel, making its continuing use essentially free.

What can I say? The debate will continue to rage on. I find it hard to draw a conclusion for this article, but I will leave our OR readers with a thought: Recall the Simplex algorith. Something doesn't have to be perfect in theory for it to be excellent in practice.

Love it or hate it VBA is here to stay. With its inclusion in current and future MSOffice products (with the exception of Mac 2008, but who cares anyway? ;)) we can safely continue to use it where appropriate. We can continue to teach it to our Masters students as a gold standard of business programming.

Use of Excel Spreadsheets in Masters Program Projects

I've been involved with the Centre for Operations Excellence for nearly 2.5 years now. First as a masters student and later as an employee. Each masters student completes an applied Operations Research industry project in the summer as part of the 16-month professional degree in the Sauder School of Business at the University of British Columbia*. This industry project is the highlight of the program and is a consulting-style engagement. A great deal of the modeling done at the COE involves Excel spreadsheets and Visual Basic for Applications. Today I will go through the 4 industry projects from this summer that used Excel for modeling.

In two instances Excel was used as an interface for an ARENA model. ARENA is an excellent discrete event simulation platform and when developing complex scenarios for it, it's ability to interface with Excel is a powerful feature. In An Evaluation of Alternative Designs for the Surgical Suite at BC Children's Hospital, an Excel VBA-based tool was developed to configure surgery block schedule scenarios for the simulation model. In Complex Care & Assisted Living Resource Forecasting an Excel VBA interface was developed for inputs and outputs to an ARENA model for forecasting needs and queuing in an extended care system.

In Optimizing the Supply Chain for a Beverage Manufacturing and Distribution Company a spreadsheet was used to model the supply chain. This model allowed for what-if scenarios testing production schedules, delivery methods, order processing, and inventory levels.

In Evaluating Operational Capital Investments at an International Mining and Metals Company an Excel-based stochastic model was developed of the processing operation.

Obviously I haven't gone into great detail here, but there are confidentiality issues at play. Even without the details, I think the importance of the role of Excel spreadsheets here can be appreciated. All 9 of the projects that year used Excel for data analysis and I would say that 4/9 using Excel for modeling is remarkably few when compared to previous years. If you surveyed the students ahead of time, I don't imagine they would say they pursued a career in OR in order to work with spreadsheets, but in a project where the problem leads the solution, the rapid development environment and widespread platform of the spreadsheet is hard to argue with.


* also the Robert H. Lee Graduate School, but I think we're all getting a little tired of naming all the components of our post secondary institutions.

Operational Researchers and Industrial Engineers - Top 10 Happiest Professionals

As an Operational Research professional, the kind of work we do is pretty exhilarating. Don't you agree?

Recently at work (a major health care authority), my team did some analysis of the emergency department visits trend. We presented our findings and communicated our recommendations to the senior management based on thorough quantitative analysis. I left the boardroom thinking "geeze, who knows when the recommendations will be taken seriously, but if only they would". Then a week later (a week only, can you imagine?!), to my surprise, we hear about the ED changing the physician coverage based on our suggestions and analysis. To take it one step further, they have voluntarily asked for continuous measurement and report to see how this has impacted the ED operations. It made my day! However, I should emphasize that we are lucky to be working with progressive clinical staff who are open to quickly try new suggestions. Cooperative clients make a very happy OR consultant.

It feels good to be useful. I'm sure this is a feeling shared by many other OR professionals. Naturally, we enjoy our line of work, and we are one (or two) of America's top 10 happiest professionals.

At number 7:

Science technicians
Job Description: Use principles and theories of science and mathematics to solve problems in research and development, and to help invent and improve products and processes.

Very happy: 51.0%
Median salary (research scientists): $72,435

At number 9:

Industrial engineers
Job Description: Design, develop, test, and evaluate integrated systems for managing industrial production processes.

Very happy: 48.4%
Median salary: $61,729

So we have some frustrating moments (a lot of them, actually), but when it works according to design, it puts a big smile on my face. :)

Operations Research blogger meet up at INFORMS 2008 Conference

Back in October, 2008 at the INFORMS annual conference in Washington, DC, attending as the official daily e-news reporter for the conference, I also had the opportunity to meet up with a few other operations research bloggers at one of the evening receptions. Here is a photo of us. From left to right:

• Dawen Peng of ThinkOR - Think Operations Research
• Mike Trick from Michael Trick's Operations Research Blog
• Aurelie Thiele from Thoughts on business, engineering and higher education
• Laura McLay from Punk Rock Operations Research

It was great to meet the other operational research bloggers. I got to hang out with Laura at another reception during the conference. It was interesting to learn about other blogger's reasons for starting an OR blog. Mine was to publicize operational research, because I believe in it, and I think more people should know about it. Laura's reason was to attract more high quality operational research students (she is an OR professor). I guess it is a long way to go still, but we are all making small steps in trying to make OR more known.

If you are an OR blogger, make sure to drop me a line and say hi, so we can start building up an OR network. I'd also be happy to link to your operational research blog on ThinkOR.org.

Pour Feliciter 2009

if (celebrateXmas)

    { echo "Merry Christmas!" }

else

    { echo "Happy Holidays!" }

//but we prefer: "Merry Christmas!" :)

Warmest wishes from ThinkOR.org

Operations Research's Irrational Fear of IT

IT is so embedded into the everyday running of businesses that almost no one can do their work without proper IT support these days. When was the last time your company's network or email or a very important application was down for maintenance, and literally employees would discuss whether they should go home early because they don't have anything to do? Well, that just shows the extent of IT and its effect on almost all departments of a company. OR cannot escape from IT either; in fact, I see OR depending on IT even more than the other lines of work. Advanced computing power is what helped OR to flourish in the first place. 

However, in practice, what I see more often than not is the fear of involving IT in OR projects, even though using an IT solution would avoid the painful change management required for process changes involving people. Let's face it. We only do change management because we have to, not because we like it. However, OR professionals do not like dealing with IT guys, because IT often has lengthy and formal processes to get things moving and done. The funny thing is, isn't this where OR guys can lend a hand to IT to help make the processes better? Just because a rule is defined (or in this case a set of IT processes is defined), it doesn't mean that we cannot invent new ways of doing things that would suit the situation better. Rules are made to guide the norm. When exceptions occur, new rules are employed and adopted. Pre-existing rules should not be the barrier to solving problems with simple solutions (simpler than changing people's behaviours that is).

On the other hand, to the IT guys, I would like to say the following, and bear in mind that I am on your side, IT folks, since I used to be one of you. As much as IT would like to think of themselves as the smart cookies, or worse the god's gift to humanity, IT should always remember that its entire purpose for existing is to simplify other people's lives with technological solutions. It is mostly a means to an end in the business world. Therefore, remember who your customers are, and serve them well - like everybody else does. Saying "No" should not be an option, since your purpose is to serve. IT is known as the "cutting edge" industry. Being innovative should be the virtue that IT guys hold high up above anything else.

I was reading an article on Analytics, titled "What's an IT Guy Doing at an O.R. Conference?" by Jeremy Yang from Cisco. He talked about some interesting differences between IT and OR professionals that were discussed at a session in the Practice Conference held at Vancouver, BC in 2007. One interesting point raised was the quest for an "end state": 

In practice, IT always needs an "end state" to the requirements of a project in order to start the development and testing process. However, in O.R. there is never a true "end state", since O.R. is constantly changing to find the optimal model. By nature, this is a cause of conflict and frustration between O.R. and IT.

Am I being silly or is this a prime candidate for the well-known agile development by iteration? Wait, isn't Google doing this constantly with their beta release of products?

The two groups that I am proud to be members of, Operations Research and IT, have highly intelligent people. Don't be afraid of each other. Use each other wisely. Foster a better working relation between the two groups to make each other's work having a greater impact. What about the idea of having an Operations Research liaison to IT? Personally, I think it would be an idea worth trying, because it would help simplify IT processes and reduce miscommunication or re-work. IT is not a black box to be avoided. OR and IT are both very logical groups of people. We should get each other, not be afraid of each other!