CORONAVIRUS (COVID 19) - FORCING YOU TO WORK FROM HOME?!
Watch our Video with some tips (view here)
Article : Missing The Metrics
Our analysis courses focus on generating metrics for physical items. How many units are produced per hour? What is the reject rate, and how much does it cost to fix them? What line produces the best product, and for how what cost? For traditional manufacturing, traditional metrics give true insight into the processes. They also provide easy means of identifying which lines or plants are doing best. Hence it is straightforward analysis to determine what factors allow those manufacturing centers to do better and copy the best practices to other lines and sites.
With a shift to software "manufacturing", the product becomes amorphous. You do not produce a new line of widgets. You create an updated version of your existing product. Does this count as a product completion? Or does it count as a repair?
When it comes to product support, everyone wants data. Data produces metrics by which individuals and projects are judged. When your software is your product, your support of your product often determines whether they will continue using your product. Thus customer service is the measure of your company's performance and key to its continued existence. Yet it is often the first area of a budget to be cut because it is so difficult to measure and often deemed to be nearly a waste.
The underlying problem is that the data collected in software service is both easy to quantify and more easily manipulated. Often such manipulation affects both the bottom line and customer service. Let me give an example.
Managers track performance of support personnel by the number of problem tickets resolved. Hence, support staff generates tickets for informational inquires resolved in less than a minute, wasting time and bumping up their ticket count. They also often close a customer's ticket the moment they believe they have implemented the solution. The desire to complete the action means that they do not follow up with the user to confirm it is resolved. If the customer calls back saying it still doesn't work, the support staff generate another ticket.
This causes a number of problems. One is that customer service goes down in a rush to garner completions. It secondly often frustrates customers by reducing their overall service by reducing the odds the fix actually worked and increasing the odds they must call back to complain. It also generates excess data entry by focusing staff on entering "informational tickets" rather than "problem tickets", decreasing efficiency and reducing emphasis on true user problems.
Other systems focus on time per call or time per incident. This is essentially focusing on the bottom line of number of people helped. It does not, however, improve the number of people helped. Performance tracked by number of tickets encourages staff to write up informational tickets to drive up their count, but does not drive a support person to cut calls short unless someone else is on the line. Time based metrics actually encourage staff to cut calls short, whether or not they've cut to the chase. It also reduces the odds they will work four hours to solve a problem if that is what is needed. That problem that took all day to resolve cannot be offset by enough two minute phone calls to meet the magic quota for the week.
If you cannot apply labor per unit (time per incident) or units per shift (incidents resolved per shift), how can you apply metrics to a software support environment? There are several possibilities.
As traditional manufacturing moves off shore, software projects remain in the United States. The reasons for this are as diverse as intellectual property concerns and remaining close to the end user. Industrial engineering must also shift its focus to better understanding of this change in the economy. We need to determine a standardized methodology and means of collecting minimally biased metrics for our software products. Furthermore, we need to teach these new skills to the next generation of engineers. Otherwise, we don't really know if we're making progress because we don't know how to track it.
About Tamara Wilhite:
Today's Tip of the Day - Headset Choice
More Editorial From Not Applicable
Published: Wednesday, May 4, 2005
Upcoming EventsSubmit Event