All enterprise social collaboration platforms include gathering points whereby people can unite with others around a common goal; for example, a program or project, social interest, organization, market segment, product, corporate initiative, technology, etc. Within Quad – Cisco’s Enterprise Collaboration Platform and product – these gathering points are referred to as communities. The longevity of any given community will vary based on several factors, which include temporal needs, relevancy, and usefulness. Some communities will be required for a long time while others may only be needed for a short time. Without clear mechanisms to identify the usefulness of each community and manage those that reach end of life, a social collaboration platform can become difficult to manage from a community governance vantage point. The performance of the platform can be negatively impacted by excessive community clutter resulting from orphaned or unused communities.
In Part 1 of this post, I described how Cisco IT addresses the first key question—about reporting on voice service availability. In this Part 2, we’ll cover the second question: How does the call sound to all of the connected parties?
Cisco IT Metrics for Measuring Call Quality
Although it seems counter-intuitive, the best source of information about voice quality may not be the people who were on the call. Of course, user trouble tickets about problems such as static and echo can be important indicators of bigger issues in a voice system. But we often find that users don’t report voice quality issues, so additional tools are needed.
Several of the brightest minds – academic leaders from Babson College and Bentley University – have written a great profile on social media strategies for the enterprise in the Harvard Business Review. The authors give readers a quiz to determine which of four types best describe their organizations’ approach to social media: Read More »
If you saw any coverage of the recent opening of Cisco’s Data Center in North Carolina, you likely noticed that it features two distinct server environments – an in-building facility and a containerized one. Having them side-by-side naturally raises the question when is a container a good alternative to a brick-and-mortar installation?
I researched that topic a few years ago when I was part of Cisco IT’s Data Center design team, as we explored different approaches to address the company’s computing needs. I found eight great reasons to consider a containerized Data Center, and three potential reasons not to: