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!

ORdinary Spreadsheets and ORdnances

The July-August 2008 Interfaces Journal ran a theme of "The Use of Spreadsheet Software in the Application of Management Science and Operations Research". In their article from that issue, "A Spreadsheet Implementation of an Ammunition Requirements Planning Model for the Canadian Army", Hurley and Balez describe a successful spreadsheet model for planning training ammunition expenditures.

Ammunition is expended in training courses in a highly uncertain environment. Course registration rates, failure rates (before completing the entire course), and other uncertainties make it difficult to accurately forecast ammunition consumption. Planners must choose a course portfolio that will not result in an ammunition shortage. Of course, to minimize the chances of running out of ammo, planners to date had been planning to the maximum expenditure per course. The consequence of this was that the program came repeatedly under budget, 38.7% in 2002-03. This is far from ideal when attempting to allocate scare resources. Naturally this was an opportunity to apply risk management principles in order to either request a smaller budget to accomplish the same goals or to do more with the same budget.

The solution took the form of a spreadsheet tool. The Excel spreadsheet combined with Visual Basic for Applications (VBA) provided an easy and inuitive interface for planners to interact with the risk model. As a result, in 2004-05 the program was only 3.1% under budget. I will not go into too many more details as they are available in the article, but I had two interesting thoughts:

[1] A big advantage of using spreadsheets is the familiarity most managers have with it. Leveraging this, the team built a simple spreadsheet simulation to demonstrate the portfolio effect of running several courses. With repeated "F9-Simulations" (my term) they were able to demonstrate that while 10 course sections will never use 10 times the maximum (as presently budgeted), it is actually reliably much less than this. Moving up a level and using @Risk to run 10,000 simulations they were able to convincingly demonstrate the concept.

We cannot overemphasize the value of this type of spreadsheet demonstration in selling the potential of an OR model.

Interestingly enough their experience differs from my own. I tried to convince an utlrasound department supervisor that if average-45-minute appointments of uncertain lengths are booked every 45 minutes, her technologists would reliably work overtime. To do this I built a simple spreadsheet simulation, but it was totally lost on her. This is not meant as a knock against this approach, but rather to emphasize the importance of manager familiarity with spreadsheets. My ultrasound supervisor as a senior medical radiation technologist thinks differently from a rising Canadian Colonel.

[2] When selecting a portfolio of courses to fit the approved budget (less than requested), the Army chose to manually optimize using the tool rather than accept a priority-optimized result from a linear program. This perplexed the authours and I think they wrongly blamed themselves for a failure to achieve buy-in. It is my experience that when dealing with problems of a magnitude that an individual can wrap their heads around, clients prefer to leverage their intuition and optimize by hand. As OR practitioners we may not trust the client to acheive a truly optimal result, but as a client they do not trust a model to capture all of the nuances they know inuitively and the answer, of course, is somewhere in between.

The idea of doing OR with Excel probably wasn't what got you started in the field, but if you like seeing results it might just keep you in it.

Hurley, W.J., Balez, Mathieu. 2008. A Spreadsheet Implementation of an Ammunition Requirements Planning Model for the Canadian Army. Interfaces 38(4) 271-280

Computer Age Workers Suffer Digital Fatigue - Can OR Help?

The October/November Issue of Scientific American Mind magazine highlights the increasing digital fatigue we are facing as a result of always being plugged into technology.

According to a study conducted by the article's authors, our neural circuitry is actually rewired as we become more computer savvy. Internet-naive subjects, after only five consecutive days of internet use (one hour/day), had already (unconsciously, of course) rewired their brains to match those of the computer-savvy subjects in the study.

While the prospect of adapting our brains to optimize our use of the internet may sound exciting, the authors warn that the computer age has plunged us into a state of "continuous partial attention" - which they describe as keeping tabs on everything, while never truly focusing on anything.

This can result, according to the authors, in a state of "techno-brain burnout", where people place their brain in a heightened state of stress by paying continuous partial attention to anything and everything. Because our brains were not built to sustain this level of monitoring for such extended periods of time, this "techno-brain burnout" is threatening to become an epidemic.

While these heightened stress levels can have short-term productivity benefits, they are proving to be significant hindrances to medium-long term productivity, due to worker fatigue and inability to concentrate.

So where does OR come in? Well, let's review the characteristics of this vexing problem to the computer age, with workers who:

• Have too much to do, too little time
• Are overwhelmed by incoming stimuli
  
• Fatigued and drained

Perhaps an old school approach - from the early days of scientific management - could be the right prescription.

Our old friend Frank Gilbreth, father of motion study, on his second day on the job as a bricklayer, questioned why he was being taught several different methods for laying bricks. So Frank developed motion and fatigue study, and created a process for laying bricks that was vastly more efficient than the processes currently in place.

In fact, Frank's new method increased productivity by nearly 200%, while simultaneously reducing worker fatigue. Here's a nice two-minute overview of Frank's bricklaying study from YouTube - a nice refresher course if it's been awhile:



It seems that computer age workers could greatly benefit from motion study analysis - and who better to deliver it than OR practitioners?

If you walked into a factory, and saw everyone on the assembly line improvising and doing their job any way they pleased, without any knowledge of best practices or recommended techniques, wouldn't you be stunned? Yet to this point in time, this is how the computer age workforce operates.

Time management and productivity experts have been at the forefront of efforts to tackle these problems, but their recommendations are usually fairly general, and without quantification. While advice such as "don't check email first thing in the morning" may indeed be worth practicing, eventually, we should be able to help guide specific individuals and workers to their optimal level of productivity.

And if that isn't ripe for OR, I don't know what is.