Enterprise Software optimize

Workflow, bean counters, and averages

What happens when the average work load is not a true reflection of real life? There's no such thing as an average day but the statistics are used to make judgements on everyday life.

Our staffing levels are based on the figures reported to our logging system. It is easy to look at a year’s work, average it out to the number of working days, and decide that each person has an acceptable workload. I think for our team it works out at fewer than three calls per day per engineer. Sadly, in the real world, this hides the fact that some days I drive for six hours and work for one, and on others I work six hours and drive one.

-------------------------------------------------------------------------------------------------------------------

On the days when I drive for hundreds of miles and do only one job, the other jobs that arrive have to wait until I am back in my own area. Fate has a way of arranging for calls to arrive in clusters, not evenly spaced as the bean counter’s simulation would have you believe.

There are a couple of things that need to be taken into consideration when deciding on staff cover levels. One is that you can arrange the statistics to form the conclusion needed. The other is that there is no such thing as an average. All the calculations for budgets, manning, and resources are based on averages, but real life is different. An example of this was a batch of print heads that were supplied for our machines. They were not up to standard, so we were replacing them frequently until the rogue ones were all replaced.

The trouble was that the bean counters looked at the totals and continued to order the part, even when we no longer needed it. It is a nightmare job to keep stock levels at workable levels, and I do not envy anyone who has that task, although I feel that it takes more than a review of records to manage this kind of task. Reviewing part usage is only part of the task, checking with the frontline workers to see that the circumstances that prevailed during the period of maximum usage still prevail is another part.

If I had the skill to accurately predict the future, I would have retired from work years ago. Sadly I don’t, so I keep going back every Monday morning, chasing around, doing the best I can. If anyone ever comes up with a mathematical formula that can calculate staff coverage, parts ordering, and the best route between calls, I will be very grateful.

There is a reality gap between real life and the ordered, predictable world of the bean counter, which is easier to understand so companies use their data to model their requirements. Up at the sharp end of the business life isn’t so easy to keep in order. Every call has a back story to it and real people who are trying to make their living. My biggest frustration is that people prefer to believe the spreadsheet over real life.

10 comments
rellis1949
rellis1949

Unlike another respondent, I have not been on both the "bean counters" and techies side of the fence; I have been on the educator's and techies side of the "average" fence. For years, I worked for a large banking-based IT department and our operation was charged with building budgets based on prior period activities. I, and my counterparts, would build extensive budgets based on actual values and would attempt projections based on patterns and trends. Upper management would change the proposed budgets in favor of straight-line forecasting techniques (the unrealistic use of arithmetic means). Respectively, each budget was prone to monthly, quarterly, semi-annual, and annual variances that were results of "mean" forecasts mandated in lieu of patterned proposals. The reality is, forecasting is rarely (if ever) perfect; however, forecasting was never intended to be perfect. There are several concerns that have to be addressed with forecasting; too much discussion for one response. Issues that need to be addressed include the use of averages (all central tendency values), the appropriate interface of patterns and trends into forecasting, the characteristics of the management level requesting and distributing the final analyses, and the completeness of the input being collected for forecasting purposes. The use of the "average" is not bad; the use is limited. The "average" (which is really the arithmetic mean as related to the source author's discussion) will rarely have value for operations staff and management in an environment that is laden with peaks and valleys (practically all service environments). However, the use of seasonal projections (patterned means reinforced with trend effect) can provide much greater value in these same erratic environments. Again, perfection will not be achieved through most forecasting techniques but projection accuracy should be increased with the use of seasonal forecasting. "Bean counters" are not the culprit in the real-world variation that the operations personnel see with "average" statistics. Bean counters (a very biased term by the way) are usually messengers. The use of average statistics are probably assigned by middle or upper level managers that are not on the firing line. The more senior managers have to deal with aggregate figures that often dictate the use of arithmetic means and straight-line computations. The detail that is needed at the operations level is usurped by the more holistic needs of the middle and upper managers. Thus, the "averages" reflected and reported by those in the middle are not representative of reality but are lesser-valued models to the realistic, operational subset.

rellis1949
rellis1949

Unlike another respondent, I have not been on both the "bean counters" and techies side of the fence, I have been on the educator's and techies side of the "average" fence. For years, I worked for a large banking-based IT department and our operation was charged with building budgets based on prior period activities. I, and my counterparts, would build extensive budgets based on actual values and would attempt projections based on patterns and trends. Upper management would change the proposed budgets in favor of straight-line forecasting techniques (the unrealistic use of arithmetic means). Respectively, each budget was prone to monthly, quarterly, semi-annual, and annual variances that were results of "mean" forecasts mandated in lieu of patterned proposals. The reality is, forecasting is rarely (if ever) perfect; however, forecasting was never intended to be perfect. There are several concerns that have to be addressed with forecasting; too much discussion for one response. Issues that need to be addressed include the use of averages (all central tendency values), the appropriate interface of patterns and trends into forecasting, the characteristics of the management level requesting and distributing the final analyses, and the completeness of the input being collected for forecasting purposes. The use of the "average" is not bad; the use is limited. The "average" (which is really the arithmetic mean as related to the source author's discussion) will rarely have value for operations staff and management in an environment that is laden with peaks and valleys (practically all service environments). However, the use of seasonal projections (patterned means reinforced with trend effect) can provide much greater value in these same erratic environments. Again, perfection will not be achieved through most forecasting techniques but projection accuracy should be increased with the use of seasonal forecasting. "Bean counters" are not the culprit in the real-world variation that the operations personnel see with "average" statistics. Bean counters (a very biased term by the way) are usually messengers. The use of average statistics are probably assigned by middle or upper level managers that are not on the firing line. The more senior managers have to deal with aggregate figures that often dictate the use of arithmetic means and straight-line computations. The detail that is needed at the operations level is usurped by the more holistic needs of the middle and upper managers. Thus, the "averages" reflected and reported by those in the middle are not representative of reality but are lesser-valued models to the realistic, operational subset.

Deadly Ernest
Deadly Ernest

I can tell you the problem is just as much the techs in the field as the staff back in the office; plus the managers have a hand too. The people entering the data in the spreadsheets usually do have ways of noting unusual events, IF they're told about them. One place I worked in the early 1980s was involved in third party computer mainframe maintenance. The techs had forms to fill in about the work they did so the people in the office can charge clients, account for tech time, do stats, and order replacement parts. ALL the reports were always seriously out. I got tasked with why because I'd had training in how to design information collection systems in the 1970s. I found out why the problems. First problem, the tech manager designed the report forms and it wasn't all that user friendly and focused on the fine technical details. Second problem, every tech hated filling in the paperwork and often didn't do it for simple or short jobs and usually skimped it when they did complete it. the simple and short jobs they skipped paperwork for were usually those with clients where we had a period support contract as against a parts and labour, so it was not an extra charge. I got approval to redesign all the paperwork involved and consolidated four forms into one, the majority of which was a tick and flick type things with places for listing parts used, comments on said parts, and another for a summary of the technical side. The time taken to fill the new form was less than a tenth of that for the old system. Suddenly the amount of paperwork being completed tripled in the next month, and accuracy went up across the board. It proved to management is the system for gathering the data needs to be done by someone who knows how to design such a system. It also proved the data must be easy to collect and include places for comments to convey unusual aspects. The next stage is to ensure relevant comments are taken into account when analysing the data. The analysts can't do it properly if important data is not provided to them. After that it needs to be reviewed by someone who understands the field situation and knows of unusual trends. A good stock control manager (which I was) will pick up odd trends early and ask field staff about them, then adjust accordingly. They'll also keep an eye on the trend and regularly seek updates to know when it tapers off again. Good stock control handles blimps by being proactive in getting extras in as soon as the blimp emerges in view. but again, they depend on the techs to tell them the blimp is in sight as the SCM is indoors in an office and can't see the sky.

dogknees
dogknees

Part of the issue is that people don't interpret "average" correctly. It's a mathematical term with a formally defined meaning and should be interpreted as such. The "average" number of legs that human beings have is somewhat less that 2 (many are missing one or more limbs). That doesn't mean most people have a fractional leg, and that is not the purpose of an "average". In the same way, looking at your average, you shouldn't expect it to be representative of any particular day. You have ups and downs, and you accept that on the up days, you may not keep up with the workload, and on the slow days, you won't make a profit. Few businesses can manage the highest possible workload and still be profitable on the slow days. It's why service levels usually state that the level is to be reached on 98% of days for example rather than requiring 100%. Disasters happen. Perhaps the issue is to use more useful measurements than the average. I doubt there is a way that suits all business models, so it's up to the individual to work out how to model their business in the most useful way.

JamesRL
JamesRL

It becomes a bit of an art. Before you look at the historical data, the best thing to do is a bit of a risk analysis to put things into context. What is the cost of a customer waiting an extra day for service. What is the cost of having a customer wait 5 minutes on the phone to report an issue. What is the cost of running out of disk space, running out of backup tapes etc etc. Figuring out the pain points should help set up priorities. Then figure out how long it takes to adjust. Buying tapes may take only days, installing disk space may take weeks, hiring new staff and training takes months. Then you can go through and figure out your averages and peaks. You want to be able to handle peaks at whatever you deem is a "minimum service" level, while having enough staff for the "goal" service levels at the "average" demand times. Call centres, like the one that shares my office space, make a science out of reaching optimum service levels and staffing accordingly. They set hard targets (30 second wait times, callback targets etc.) and try to adjust staffing levels to meet them. The trick is trying to find the goals in the first place. James

wgweinbe
wgweinbe

I've been in the service engineering business for a long time and one of the most difficult things to do is to justify manpower levels to the bean counters. I've always said that this situation is equivalent to? =0. In case you're wondering, on the left side of the equation, "If you don't know what it takes to do the job", the results are 0! All too frequently companies rely on data extracted from reports, spreadsheets, databases & etc. and don't bother to have anyone in the decision making process talk to, ride with or otherwise try to gain a first hand knowledge of what it actually takes to do the specific job. Critical business decisions will be made affecting the company?s ability to provide adequate coverage for call volume due to sickness, vacations, personal time off, etc. The mean time to respond to individual service calls will also be affected, many times to a level that is unacceptable to the end user. A department or company?s reputation can be damaged and take quite a while to gain back their credibility to where it was before the bean counters actions were taken.

dboundscpa
dboundscpa

Jeff, you've identified a problem in time and process management. That problem is communication. Regardless of your frustration, though, it's both harmful and inaccurate to trash the bean counters unless you can demonstrate when, where, and how you've communicated to them that these parts (in your example) are no longer needed. It is true that bean counters utilize historical data to attempt to be prepared for future events. It is also true that bean counters seek information from any available source to place orders or otherwise prepare for future events. How loudly will you complain if the bean counters haven't ordered the parts you need every Friday when you didn't tell them you needed them next Friday? Will you insist that they should have known based on history? As the bean counter that has been the liason between the techies and the 10-key bangers, I can assure you that both groups must endeavor to work together and throw the blame game in the trash. On the other hand, when you can readily identify a problem, it seems to me that you have a golden opportunity to be a hero by making a serious proposal to proper parties showing how to change processes to end the problem and improve the business. Such a no-brainer!!! One final thought, Jeff. You mentioned that the bean counters kept ordering the parts even when they were no longer needed so you could continue replacing the defective heads. Were you going out and changing heads since they provided them? If you were, who is it that isn't using their head intelligently??? Remember, Jeff, that you and everyone else will be far better off when you actually work to improve the business instead of trying to blame your way to the top.

Ed Woychowsky
Ed Woychowsky

As an earily riser, the biggest problem that I've encountered are the managers that decided that if you get in at 7 going home at 3:30 is leaving early. I've lost count of the number of times that I've heard, Dan or Jim is a better employee because they leave at 6. The fact that they don't drag their butts in until 9:30/10 never enters the manager's head. Basic arithmatic is beyond them. - End of rant.

BiggestDawg
BiggestDawg

That we are in the mess we are today. Not because they are bad or stupid people but because they are not capable of seeing past their spreadsheets to the reality that goes on around them. Therefore they make their decisions based purely on numbers and statistics and we all know that they can easily be wrong. It is still not the fault of the bean counter though. It is the fault of leaders to take the information from bean counters and from the front lines and properly interpret the information. In other words to put the human face to the numbers. This is not something that comes naturally to the bean counter. So bean counters that wind up in positions where business decisions need to be made tend to favor the one thing they know and understand and as a result they often make the wrong decisions I have seen it many times over that is why bean counters should not be allowed into the final decision process.

cillbat
cillbat

seems like a bit of communication projection here and assumptions running rampant. i think the general idea is that its unlikely to be realistic when looking at stats alone to base staffing decisions since stats never tell the whole story. so much of what gets done never meets the user's eye nor the 'bean-counter's' eye because its very difficult if not impossible to quantify how different calls can be. Therefore you average them out and hope for the best which is never going to come out right if you try to only meet and never exceed the need for support. Therein lies the true problem.