Network and application visibility is turning the tables for IT administrators, because when they get a complete, instantaneous and comprehensive view into applications, connections, and users, they can much more rapidly identify problems and cut to the chase to solve them.
Extreme Networks offers a lot of demos on Purview (a network-based application analytics tool), and when we do, we break the discussion into two segments: one half talks about analytics, and the other on PC/network troubleshooting. Right now let’s talk troubleshooting.
Here is a dirty IT secret… Sometimes we have no idea what to do when a user calls to complain. It’s not that we are incapable; we make good decisions based on what we know. Sometimes the data we have happens to be either wrong, or incomplete.
In a traditional environment, when a user calls in to say that the network is slow, that has meant sending a technician to the user who then typically will troubleshoot the issue like this:
- Reboot the machine. (We always start with this, yes even if you tell us you already tried this. Don’t ask why, there is no good reason. It’s habit)
- Switch from wireless to wired, or wired to wireless.
- Change wireless networks, cables, docking stations.
- Go to windows update and update the software. Mac or Linux users aren’t immune to this step either, we’ll check for updates from them too. (Yes even if you just did it – see #1)
- Update drivers. No, this is not the same as #4
- Try having you log in with a different machine, or we’ll log in on your machine.
- At this point we call someone else because it could be a network issue, a server issue or something entirely different.
Sometimes steps 1-6 will fix something, but often times this is the point that we figure out that the problem may be bigger than just the user’s end device, and we bring in the server team (or network team). If you are lucky we won’t start back at 1.
If we called the server team and it isn’t actually a server issue, we then call the network team (and vice-versa). Probably start back at 1. Yes again. You can see why fixing issues takes a typical IT organization so long, right?
Now in an Extreme Networks environment running Netsight and Purview visibility tools, it looks like this:
- Go into Purview and search for your name to see all the applications you are using. This will show us if it is the network causing the delay or the application. If it is just one application that is showing an issue, right click on that and see if it is just you, or everyone in the company. If it is just you, fix your machine/network.
- If it is more than you and the network response is slow, call the network team. If the application is slow, call the application team.
You may notice something. In the second scenario, we don’t spend a lot of time troubleshooting the wrong issue and instead in a few seconds get the right people working on the problem. This wastes a lot less of your time (and ours as well).
My “back of the napkin” estimate on savings that can be achieved, based on what we see internally at Extreme Networks:
The average “network” troubleshoot can consume 3-4 hours. Sometimes we get lucky and rebooting it really does fix it. Other times we can spend days figuring things out and pointing the finger at someone else.
Internally as a network team we see an average of 4-5 of these a week. I’m guessing the helpdesk sees a lot more and resolves them without us.
So in an average week that is 16-20 hours. That is close to half of one person’s time just troubleshooting. It is no wonder Gartner estimates 60-70% of IT’s resources are used just to keep things running!
Now some quick math: we assume $55 an hour per employee (That is probably a little low, but the last time I checked in 2004 that was what we used). At 18 hours a week, that comes out to $990 per week in lost labor savings. And to be fair that is just the IT time, not the user time. So let’s round that to $1000 and double it.
So in an average year, just by reducing the time to troubleshoot issues, you can save $100k, per year. Not a bad ROI! (And that doesn’t even include the analytics piece…)
The post Traditional Networking vs. Better Network Management Tools appeared first on Extreme Networks.