Planning Is Essential For An OCS Deployment
Author: Jamie Ryan, CIO at ASpectI’m happy to report that we’ve now deployed Microsoft® Office Communications Server (OCS) across 100 percent of Aspect – that’s for approx. 1,800 employees across 20 locations spanning 18 countries. I’m proud of my IT team for a job well done, and appreciate Aspect Professional Services’ collaboration and expertise.
I’m very enthusiastic about this deployment for a number of reasons. Aspect has now replaced all 18 of our PBXs with OCS and reduced associated maintenance costs by $176,000 annually. We’ve cut conferencing costs by about $1 million annually, and reduced long distance circuit costs by $20,000 per month. Not to mention, it’s so much easier for me to do my job. I’ve heard this comment from many of my colleagues as well, and an annual user productivity savings of $810,772 backs it up. I can tell you, however, that these results didn’t just appear magically overnight. They were the culmination of stringent planning and careful implementation.
Our first step, and one that I strongly recommend for anyone looking to deploy Office Communications Se
rver, is to define the scope of your deployment. What functionality are you introducing, and why – and what are you replacing? For us, that meant completing a current state assessment of our Microsoft Exchange environment, on which OCS is dependent, and conducting a thorough assessment of our LAN and WAN infrastructure from both a business and technology perspective. It’s extremely important to take the time to understand what is running on your network, how it is running, and why it is running, so that you can identify potential utilization problems. Then, you’ll need to determine whether you’re going to protect integrity on your WAN, your LAN or both. In our case, we decided to run quality of service (QoS) on both our LAN and WAN environments to ensure the integrity of each call across our infrastructure.
You also need to think through your deployment methodology as it relates to scalability and survivability. We chose to use the hub and spoke model with hubs at our corporate headquarters and at our EMEA headquarters in the UK. North American and EMEA locations act as spokes that connect back to these hubs for services. We could have built out OCS deployments in all locations, but decided against it because of the added cost and complexity. However, in APAC, we deployed a hybrid approach due to regulatory requirements and limitations of SIP trunking in the region.
It’s important to take some time to decide whether you want to deploy Office Communications Server 100 percent standalone, integrate into existing PBXs, or deploy in conjunction with new PBXs. And, whether or not you’d rather use SIP trunking to preserve or not preserve local phone numbers – a choice largely based on your cost structure and how you’re routing calls.
In my next blog, I’ll talk a bit more about functionality and some of the non-technical considerations for an OCS deployment. In the meantime, please send me any questions you may have about our deployment. I’m happy to answer them. Or, check out www.UCWorld.com where you can hear more detail on rollout considerations.
Author: Aspect
Catergories: Unified Communications
(1 votes, average: 5.00 out of 5)
Loading ...
