comment 0

Interview with the 2014 winner of IIE’s Undergraduate Student Technical Paper Competition

From IIE staff reports

This blog includes an interview with Patrick Gathof from the Milwaukee School of Engineering, winner of the IIE Undergraduate Student Technical Paper Competition. He was recognized at the IIE Annual Conference & Expo 2014 for his paper, “Supermarket Redesign: Demand-driven Inventory Planning.”

IIE: Tell me about your winning paper and its research focus.
Gathof: The paper was created from my senior design project that I worked on with fellow classmates Matthew Waech and Jonathan Paulino. Here is the paper abstract:

This senior design project report examines the use of a forecasting model to predict customer demand, leading to informed inventory planning decisions.

The goal of the project was to develop a forecasting model to allow Benz Oil to better predict customer demand, as well as use the forecasted demand to develop inventory planning strategies. An additional goal of the project was to reorganize the raw materials in the facility to minimize travel distance and decrease the non-value-added time for the employees.

The project team developed a forecasting model in Excel that projects customer demand three months into the future. With the use of the model, the team analyzed three potential inventory planning strategies: Economic Order Quantity (EOQ), Kanban, and Safety Stock. The implementation of the EOQ strategy would decrease annual inventory costs by $1,051,739 and would yield a 1-year return on investment (ROI) of 277%.

The team used ABC, From-To, and Spaghetti Diagram analyses to determine the locations for raw materials that would decrease annual walking distance by 89.4 miles for the employees. This equates to an annual net savings of $133 with a 1-year ROI of 24%.

The team also developed a map of the raw materials that could be used by Benz Oil to eliminate the need to memorize the various locations. The implementation of the map would yield a net annual savings of $920 due to a decrease in training time, which would yield a 1-year ROI of 160%.

Who or what guided you to this paper topic?
For our senior design project, our advisors gave all of the students a list of companies and each of their respective projects.  Benz Oil was the only project that seemed open ended.  I was not excited about the other projects that had a narrow focus or those which seemed to already have the project figured out so-to-speak.  Benz Oil said:  our company has a variety of low hanging fruit within the facility, we would like a team to come in, find that low-hanging fruit, and make improvements that they deem as necessary or important.

The company provided the team with feedback regarding which of the several areas of improvement presented would be of most interest to their employees.  After this feedback was received from the client, the team presented this feedback to their advisors, and it was suggested that the team use this project as an opportunity to try and pitch a brand new idea to the client. With this in mind, all of the issues were taken into consideration and prioritized by using a weighted factors table which included factors such as client interest, client impact, as well as team member knowledge of the problem. This weighted analysis was used to assist the team in determining the areas of improvement to be addressed for this senior design project.

Using the results of the weighted factors table, the team narrowed the scope such that it would provide an optimal effect on the company at this current time. The team’s focus turned to the issues regarding the locations and organization of both the raw materials and the finished goods. Along with the focus on the location of materials, the team also attended to the outdated documentation of the facility layout; this combination allowed for improved control of the storage of the materials throughout the Benz Oil facility. Additionally, the team took the advisors’ advice and moved forward with developing a formal forecasting model for customer demand and creating stock levels for the finished goods.

Is this your first research paper to be published or recognized?
Yes it is.  I have of course done multiple projects and papers for other organizations, classes, and projects, but nothing to this extent.

How do you feel working on this research paper prepare you for your future career in industrial engineering? What lessons did you learn in respect to how you went about your fact-finding and writing?
Working on this research paper will help prepare me for working with unknown clients, and working the challenges of different cultures and mindsets that various groups can bring.  One of the hardest parts of the project was trying to convince the client to do something that they really did not want to do.  It was exciting to show the true monetary value of executing such deliverables.

Outside of receiving your award, what did you enjoy most about the IIE Annual Conference in Montreal?
I truly enjoyed participating in the Industrial Advisory Board Track, in Applied Solutions.  It was fun to listen to the various problems people have been facing and also hearing about how they came to a solution.  I enjoyed getting resume and interview tips from professionals, and I enjoyed connecting with professionals from all over the world.  This was truly an invaluable experience.

comment 0

Their Problems Should Be Our Problems

By Tamara Wilhite
An IE in IT

The book “How to Become a Rainmaker” is geared toward salespeople but applies to businesspeople and businesses as a whole. The book says that customers buy for only two reasons: to feel good or to solve a problem.  IT teams too often forget that fact.

Software rarely helps people feel good, unless it is a game. In that regard, games like Candy Crush manage to make a lot of money and many people happy. For everyone else in IT, software changes must solve a problem to be worthwhile. The problem many IT managers, programmers and developers face is aligning their solutions with the customers problems.

Before planning any software changes, upgrades, updates or whatever term you’d like to apply to the process of altering your application, ensure that the answer to at least one of these questions is a resounding “Yes!” before you go forward.

1. Does this change solve a user problem?

While reviewing the facts, verify that the problem it fixes applies to enough people that making one customer happy doesn’t annoy many others with the downtime or lost productivity of installing a new version.

2. Does it fix something we ourselves broke?

These software changes should take priority, in order to restore the company’s reputation.

3. Have we verified that this update or change is what the customers want?

Too many software changes are implemented because someone in engineering or IT considers it cool, cutting edge or the next big thing. However, it may not be what the customers want.

4. Does this change or improve an attribute customers consider critical?

A software change to improve IT security doesn’t need customer approval – we already know that no one wants to lose their credit card information or have personal information leaked.
Software changes that improve system uptime can be assumed to meet customer needs if reliability and uptime are critical to the customer base.
Software changes to stay in compliance with ISO, CMMI or another standards organization standard that customers want or need to achieve are worthwhile.

5. Have we verified that our change isn’t going to create problems?

There is a joke that all that matters in real estate is: location, location, location. In IT, we need to have the adage “test it, test it, test it”. All software changes need to be thoroughly tested for all environments and operating conditions, user types and transactions. Verify that the new functionality works – and that it doesn’t break anything else. And never remove functionality in order to add new features without verifying with the customers that they don’t need the old functions. After all, it was there for a reason.

Summary

In IT, it is essential that the problems we choose to solve are the ones that matter most to our customers, not the system administrators or techies that dominate the software development group. Focus on what matters to the end users, not the performance metrics or high tech projects that look best on someone’s resume.

comment 0

The Major Goals in IT – And How to Reasonably Achieve Them

When it comes to quality, the goal is zero defects, but Six Sigma quality of near perfection is considered good enough. Yet IT often sees goals for 100% perfection. What are some of the goals set in IT, and how can you actually make progress toward meeting them?

Goal: 100% Uptime

This goal is often set after repeated outages or a disastrous one.

There are several potential solutions to meeting this goal in IT.
• Track all outages after they occur, including the duration and scale of impact. Identify root causes so that they can be resolved long term.
• Focus on reducing the severity of outages and their duration when large scale infrastructure is required to prevent them altogether. For example, improving automated reporting of outages or access to servers by those who can reboot them shortens the duration of outages before a new mirrored server is installed.
• Appreciate a reduction in the duration and/or severity of outages in the quest for improved uptime.
• Run your systems off Linux and Unix instead of Windows servers. There are Unix and Linux servers that have approach 100% uptime.

Goal: 100% Customer Satisfaction

Installation time, bug fixes, time to release and other metrics are variable and can change release to release. However, many organizations want their customers to be happy. So they seek 100% customer satisfaction.

Solutions

• Track satisfaction on a five or ten point scale instead of a yes/no request. If users can report intermediate responses or “It’s OK” are less likely to pull down the satisfaction rating because their only options are “perfect/not”.
• Ask for more information when people say they are dissatisfied. Did software install incorrectly? Are they unhappy with customer service when they requested a refund? Does the software no longer interface with another tool? Is there a bug in the new release, or is someone upset that your product doesn’t have the latest feature of a competitor? Identify root causes that aren’t your fault so that you don’t inadvertently ding the team for factors they cannot control.
• Separate enhancements for defects in customer surveys. Track the recommended enhancements but don’t count them as dissatisfied customers unless you actually removed the feature they want to add back.

There Can Be Only One?

I worked for a company that found that its dozens of disparate PDM systems were a source of inefficiency and thus wasted money. Checking three different PDM systems was by definition inefficient and a waste of time. Add in the effort to maintain all these systems, their servers, redundant user accounts and you can see why this was far from ideal.
The logical solution was migration to a single PDM system. It required multiple migrations, but a common PDM system evolved. IT support costs, user efficiency and licensing costs went down.
However, a single software system is not always the right solution.

SAP has a strong financial and payroll system. Visiprise Manufacturing is a good inventory tracking system. However, when it comes to its manufacturing management system, the process of creating routers is notoriously difficult. PTC’s Windchill application is a decent PDM application. It can be used as a content management system. However, it can’t track as-built configuration information for individual assemblies or track depot parts. Each tool has its strengths, they all have their weaknesses.

The mistake an organization could make is trying to eliminate software tools that are not actually redundant.

Let’s take a different example, many small businesses use QuickBooks or another financial software application. These tools track spending, generate invoices and print pay checks for employees. These applications may be able to handle MRP with an add-on module, but otherwise trying to use this tool to track inventory, manage to do lists, track team calendars or store legal documents isn’t ideal.

It easy to say, “There should be only one.” However, the caveat is that there should be only one tool in the organization per category or intended purpose. You cannot use a single tool to run many businesses, or you’ll be as inefficient as the company that has too many tools.