Systems Views and Reporting
In larger networks, you can get consumed with individual problems and miss out on general, systemic problems that are affecting many endpoints.
I had an interesting conversation with a vendor a few months ago at Enterprise Connect Orlando. I am naturally interested in network problems that affect applications, including Voice and Video, so I was talking with one of the vendors of a Voice/Video management tool. The product manager was showing me how their product worked for detecting and diagnosing a problem on a phone.
What’s Wrong With This Picture?
Learning how a product works for diagnosing a single endpoint problem is ok. There are always problems where you need something that allows you to collect and analyze the data necessary to diagnose individual problems. However, I tend to work with networks that are pretty large. Diagnosing individual problems is like missing the forest because you’re looking at individual trees. In the larger networks, I could get totally consumed with individual problems and miss out on the fact that there are general, systemic problems that are affecting many endpoints. If I can identify the systemic problems, I can improve the service for many endpoints by addressing those problems.
Let's take the case where an infrastructure link to a remote site has incorrect QoS configured. I may have several trouble tickets about poor voice quality and dropped calls at the location serviced by that link. I can work on each ticket individually and may eventually determine that all the tickets are related to a QoS problem. I may even figure that out while working on the first problem. But then I'll have the other trouble tickets that I'll need to check to make sure that they're not some other problem than the one I've solved.
Finally, when I'm working from trouble tickets, there are already problems that are affecting the customers. It would be much better for them and for me if I could proactively determine that a problem exists that is affecting multiple endpoints, and address it before the customers call the help desk, file trouble tickets, and we have to process the trouble tickets. It is all about efficiency and reducing the cost of running the help desk and of increasing the productivity of the customers who are using the voice/video systems.
There are other factors that come into play. I may be working on problems that are less important than other problems. Let's say that I have a trouble ticket from a manager and another ticket from a call center employee, both complaining about poor call quality of their phones. Which ticket is most important to the business? It might be the manager in some cases. But in other cases, an entire call center may be experiencing a problem and only one person called to report it. Customers calling into this call center may be dropped or may terminate their calls due to poor call quality. If this is an order placement call center, it is the revenue generation part of the business and should probably have priority over fixing the manager's phone.
Please Give Me System Views In our conversation at the show, I asked the product manager to show me a more global view of the endpoint performance. He initially didn't understand what I wanted. I explained that I wanted to generate a report that showed me all the endpoints that had poor call quality, grouped by common criteria, such as subnet address or regional location. It took a while to explain why I wanted this grouping. The product manager hadn't any experience running a very large network and hadn't thought about how the tools should operate in large-scale networks where there are thousands or tens of thousands of endpoints.
Next page: Attacking the problem