When The Correct Answer Isn’t Right Part 1: Objective

In a previous post I started discussing what to do when an optimization model’s correct answer isn’t the “right” answer according to the user. I am currently working on developing a scheduling MIP for a client that generates an optimal solution but the client did not feel it was the “right” solution. The users had a clear idea of certain tasks that should always be scheduled together, even if it potentially resulted in a sub-optimal schedule. In their minds, pairing the tasks was a requisite part of the schedule.

In my initial post, I discussed why it’s not good enough to be optimal; the model also needs to be “right”. Then I outlined a few areas I could investigate to help tune the model towards the “right” solution. Since then I have probed deeper into these areas and, with the help of the users, been able to tune the model’s optimal solution more towards the solution the users are looking for.

Today I’d like to share the results of my investigation into the first area: the objective function. The objective function defines the goal of a model so it’s important that the objective function clearly reflects the goals of the model. If a model’s goal is to reduce costs, minimizing the various costs of a model is the correct approach. But if the model’s goal is to increase profitability, an objective function that solely minimizes costs may be overlooking key aspects that impact profitability.

Talking with the client, I gathered more detail about the true objective of the model. Originally I had believed the goal of the model was to minimize the cost of the schedule. This cost is made up of several components, including the cost produce an item, the cost to use each machine, and a slack cost for not completing a task (otherwise the model won’t schedule any tasks because not producing tasks costs $0 without a slack cost).

What I learned from deeper discussions with the client was that the users felt that not scheduling together their paired tasks resulted in a lost opportunity cost. Although this wasn’t a concrete cost like the cost of resource time or construction materials, not incorporating these pairings led to a poorer schedule in the mind of the users. So I added an additional cost for each of these pairs of tasks that were not scheduled together. The cost was large enough to encourage the model to try to schedule them together whenever possible, but not so large as to force the model to not schedule other tasks to make room for the pairs. As a result, the model tends to schedule the majority of these pairs, although it is sometimes neither feasible nor globally optimal to schedule all of the pairs every time.

In the case where the objective function is mostly correct but is missing a key element or two, it is generally easy enough to add the missing pieces as long as there is enough information to determine their costs, distance, time, etc… This was the case for modeling the opportunity cost of not scheduling pairs of tasks together. But sometimes the basic goal of the objective function needs to be rethought, like when a model is minimizing cost when the real goal is to minimize empty miles. I ran into a similar situation with a scheduling model whose original objective function was maximizing the number of trips scheduled. With this objective, each trip was equally as important to schedule as every other trip.

During testing I realized that this objective function caused the model to prefer scheduling shorter trips rather than longer trips because more trips could be scheduled if they were all short. However, after talking about the results with the client, it became clear that the revenue from the trips was based on the mileage. This often made longer trips more desirable than a group of shorter trips. Clearly the model was solving towards the wrong goal. Instead of maximizing the number of trips scheduled, the model should maximize the revenue made from the trips. Longer trips with greater revenue should be given scheduling priority over shorter trips that generate less revenue.

These are just two examples of how the definition of the objective function can steer the model towards an optimal solution that isn’t the “right” solution. Most of the time, the objective function is pretty close to the model’s goal, but not quite 100% correct. Discussing actual and expected results with the users can help clarify the gaps between the objective function and the model’s actual goal and get the model back on track towards achieving the users’ goal. In a comment to my initial post, Paul Rubin reminded us of the importance of maintaining a dialog with the users. A modeler should not create a model and then just throw it over the wall to the users and move on to the next project. The modeler and the users should talk during all stages of the development to make sure the modeler understands the data, the model’s goal, and the users’ expectations. The model is a tool for the users and their insight is invaluable in the modeling process.

Up next: Part 2 Constraints

This entry was posted in Uncategorized and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s