Big Data or No Data?

Big data and analytics are all the rage in both the technology and the public press. But it’s hard to find much of this happening in the telecom and UC sectors – more like no data than big data. This seems to be true even while Jim Burton is advising vendors that we are entering the age of analytics and Artificial Intelligence (AI) that is built on analytics.

Sure, there is a lot of data collected to monitor network performance. Some vendors build this into their IP Telephony and UC products. Two examples are the monitoring functions of the Front End Server role on Lync 2013 with back end SQL server data repository and the Cisco Prime Collaboration which takes from one to many virtual machines to provide “efficient, integrated assurance management of applications and the underlying transport infrastructure.” As the Cisco site says, these tools are provided primarily to assure performance of the services and the network routes so that the quality of service (QoS) can be maintained for the users. This is a good thing, but it’s not "big data."

In addition to the vendor’s products, there are a number of monitoring packages that are available for use by the customer in their Network Operations Center (NOC) or by the system integrator as a value-added (i.e. for a fee) managed service for the customer’s system. In my experience, these tools are also almost entirely real-time QoS and availability management.

In addition to that, some customers use the call recording services offered by the IP Telephony vendor or use a call recording software package or cloud-based service to capture the call data. With this, we’re starting to see a possible "big data" (well, more like "small data" in the context used by IBM and others to talk about "big data"). However, the primary purpose of this data collection is for tracking toll service costs, which has declining value as per-minute charges are declining and voice traffic through the PSTN is shrinking.

However, for those of our clients who are using call recording services and can provide data for a representative period, such as a week or month, it is possible to begin the analytic process on this "small data." For example, for one client with multiple sites it was possible to map all calls by number and duration for intra-site, inter-site and to/from the public network. That data, when analyzed, showed a number of important patterns, of which the following are just three examples:

• Call traffic to and from the PSTN was far less than the trunk capacity that was configured, supported and funded, since voice communication was increasingly being replaced by email and, to some extent, online conferencing using the IP network.
  
  
• Most of the internal call traffic was intra-site, i.e. from one extension to another in the same facility. A large percentage of these calls were very short calls, which typically indicates the called party is busy or did not answer and the call went to voice mail, at which point the caller hung up and called another person or sent email. An increased use of presence (prior to a call) and instant messaging (instead of a call) were definitely indicated.
  
  
• Over 30% of the calls from the public network to the company’s locations were of short duration, pointing to the same pattern of disconnection after reaching voice mail, a behavior that was corroborated by the voice mail statistics. This recommended strongly in favor of federated presence or a presence-enabled client portal for the company’s major clients and partners which would greatly improve client service levels and, likely, client loyalty.

However, these examples are still trivial. Even the simplest of web sites can add Google Analytics to the site’s pages and be able to track usage on the site, including even a trace of the pages that each visitor touched during their session. But there is no evidence of this level of information in the IP Telephony and UC applications space. Or, if that data does exist, there’s no evidence of vendor leadership to use that to support user adoption, user satisfaction, and business process optimization. Almost every IP Telephony or UC vendor that we have asked is not capable of providing any detail on the use of their systems and features beyond QoS management and call logging; pretty trivial, it seems.

Perhaps the vendors really don’t want customers to see this data. What if it were possible to see which IP Telephony and UC features and functions were actually being used, at what frequency and by how many users? Would customers be motivated to increase adoption, or would customers begin to move users to less robust licensing options or to less costly, simpler communications solutions? Since few vendors and even fewer of their channel partners are able to clearly explain the organizational value or business process value that can be created by IP Telephony features or UC functions, the vendors would be very justified to anticipate accelerating customer migrations away from the over-featured and, perhaps, over-priced IP PBXs or UC systems.

Meanwhile, companies that sell business process software have comprehensive data collection and analytics and can prove the value of their solutions. These same companies are also providing communications tools as part of their software, including data notifications and alerts, email messaging, presence and instant messaging, and even peer-to-peer voice, video and screen sharing. This communication is "integrated to optimize the business processes" (a UCStrategies definition of UC) so the business results are measurable and the opportunities for optimization are easily highlighted by "big data" analytics.

The IP PBX and UC market segments are at a crossroad on this topic of "big data" for communications. Those that get on-board so that they and their channels can provide value-confirming feedback on system feature adoption and use, supported by analytics engines have a chance to thrive in this new world of "big data." Those that don’t should not complain when their customers migrate to higher planes of visibility. We’ll see.