What Is Backwards Troubleshooting?
For those supporting mobile computers, networks and applications in supply chain operations the best way to describe the most common form of troubleshooting is “backwards” troubleshooting. It is a reaction to mobile-user complaints that turns a mole-hill of an issue into a mountain of problems for IT and Operations.
Using the analogy of a car breakdown to mobile latency or disconnects, imagine your car sputters out halfway to work. At the mechanic’s shop, they put your car on the lift and start taking it apart, piece by piece, testing each for functionality. After a few days the mechanic calls to tell you, “I can’t find a problem. I’ll have to drive to work with you every day until it happens again.”
In this case, the mechanic has just done the wireless equivalent of completing wireless site surveys and mobile computer hardware diagnostics, then recommends hooking-up Wireshark and following your mobile users around the factory floor for the next week. It is a backwards approach because the mobile infrastructure, or “parts”, are evaluated individually, without any connection to how each part functioned when the problem actually occurred. This process extends the time to resolution, causes confusion, and introduces more variables into the system.
Go Forward With Problem Capture and Analysis
The alternative troubleshooting approach is to first capture the problem in a way that allows for observation of how the critical parts behaved during the breakdown. Thankfully for all of us with a vehicle, the auto industry is already using this type of advanced diagnostics. Mechanics now obtain critical information needed from the on-board computer and then fix the problem efficiently, saving us time and money.
In the mobile and wireless industry, there is the CVA. It is the cornerstone of troubleshooting because it gives the troubleshooter a full description of the problem and a complete picture of how the mobile parts – apps, networks and mobile computers – were functioning at the time of the incident. This data set eliminates guesswork and trial and error, leading to a solution more quickly and with less cost.
How to Spot Backwards Troubleshooting
Beware of proposals that offer solutions without relevant data to support why a particular solution would solve the problem; this is a good indication that the troubleshooting process was either backwards, ad-hoc or trial and error. If there is not a direct link between the mobile-user complaint and the root cause proposed, be suspicious that you might be looking at a red herring.
Protect your budget and time and request an explanation of the data and process that led to conclusions and recommendations. If the explanation requires a lot of assumptions and long-winded theories based on limited data points, consider Occam’s Razor and the KISS (Keep It Simple Stupid) principle.
And most of all, remember that when troubleshooting is done well and with the right tools, it doesn’t require a lot of effort or time at all.