Understanding Risk with Unified Communications

During the last few posts I’ve been talking about the merits of remaining premise-based when deploying Unified Communications. There are several factors to consider in that decision, and depending on your circumstances, a case can be made that way – or just the same to go with a cloud-based option. Of course, the definition of “circumstances” can vary greatly, and that may merit a few posts down the line.

I could write further about the rationale for remaining premise-based, but I think you get the idea by now, and would like to move on the topic of risk. This is another term that has many meanings, and I touched on that in my last post. Some forms of risk are obvious and some are not, and the cloud-versus premise decision for UC is just one example. I’d like to now step back and further examine some of these variations for the broader decision to adopt UC.

To UC or not UC?

This is really the start of your UC journey, and there is inherent risk to both sides of the coin. It may not have occurred to you until now, but this is actually a less obvious form of risk, since UC does not get on your radar like other forms of technology. Unless you are running a pure R&D operation, most business decisions – technology-related included – are based on the problem-solution paradigm. In IT terms, this is analogous to the break-fix model, where technical support springs into action only when a problem arises, and billable hours are in play. Similarly, IT investment decisions are usually made based on the need to replace, enhance or update infrastructure.

Think back to when you deployed VoIP. In some cases, there was a break-fix scenario, which we often refer to as a trigger event. Your legacy PBX had reached its limits – either capacity was maxed out, performance was eroding, or even lapsing altogether. Perhaps more commonly, the system was holding up, but could not grow to meet your needs. The architecture was too rigid to incorporate the new features that IP-based systems provided, leaving you to patch together home-grown fixes that were spotty at best.

In the worst scenario, your PBX vendor has announced end-of-life (EOL), a pretty clear signal that they’ve seen the writing on the wall and have moved on without you. Not only does this mean you’re on your own for system maintenance, but you’ll likely need to resort to the aftermarket for parts to keep things running.

Hopefully, these examples are familiar, and you may have experienced them all. Whatever your situation, you were faced with a decision to hang on to the PBX or move forward with VoIP. In all cases, the risk factors were evident, as reliable communications is the lifeblood of any business. You could certainly stand pat, but the risks were very real if the situation got worse – not just for everyday workflow, but in dealing with suppliers, partners and of course, customers.

While many businesses move to VoIP for the cost savings, the above risk factors have business value, and whatever the cost savings may be, this business value can often be the deciding factor. Every business wants to save money, but long term what really matters is having happy customers and efficient business processes. These elements are easy to see with VoIP, but less so with UC. In most cases, VoIP addresses a problem – or even multiple problems, along with being the solution to some looming problems as your legacy phone system continues to decline.

Whereas VoIP replaces an old technology with a new technology, UC usually comes into play when that new technology is already in use. VoIP is typically a stepping-stone to UC, as most businesses aren’t ready to make a wholesale change from legacy PBX to a full-blown UC platform. In this regard, moving to UC is actually low risk, since you’re already familiar with IP-based technology.

The only wrinkle, however, arises if VoIP has not performed as expected, in which case you may not be enamored with IP. In that case, I would say the results have more to do with not making the right IT decisions than the underlying technology itself. Remember, not all VoIP services are created equal, and performance is highly dependent on having the right network environment.

Chances are, however, that you’re considering UC with a fairly positive mindset about VoIP. The main difference in terms of risk, though, is that UC doesn’t usually address a clearly-defined problem. UC is rarely deployed to replace a broken-down phone system – the decision is typically more strategic than tactical. If you view all IT investment issues as break-fix scenarios, UC will not rate high as a priority, and nor will be seen as a transformational opportunity for the business.

This brings us to the existential question posed earlier – to UC or not UC? There may be no perceived risk in keeping the status quo with VoIP, especially if cost savings is your top telephony priority. However, there is risk by not adopting new technology that takes communications to a higher level, and moves beyond the telecom-centric model of the PBX.

Just because UC doesn’t address a clearly defined problem set doesn’t mean there is no opportunity cost by keeping the status quo. In other words, you won’t see this with a problem-solution mindset, but you will with an opportunity-solution lens. This thinking comes by taking a broader view of risk, and I’ll continue expanding that horizon in my next post.


Permanent link to this article: http://blog.adtran.com/understanding-risk-with-unified-communications/


  1. mcmurdo north face says:

    Hi woulԁ уou mind shаring whісh blog platform уou’rе working with?
    I’m looking to start my own blog in the near future but I’m having
    a hагd tіme choosing between BlogEngine/Wordpress/B2evolution and Drupal.
    The reason I ask is becаuse yοur design seems different then most blogs
    and I’mlooking for somethіng comρletely unique. P.S Sorry for being off-topic but I
    had to аsk!

    1. ADTRAN says:

      mcmurdo north face – Thank you for the compliment! We use Word Press. Good luck getting started!

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <p> <q cite=""> <strike> <strong>