article page
| 1
| 2
| 3
|
driving all those processes in the Operations area alone to level 4, where it needs to be in the day-to-day world. It is nearly impossible to argue with budget-focused IT managers that there is value in doing that. I've found that a more pragmatic approach is to take the processes vital for Day 1 operations success and focus on those. The remaining processes can be built out as the organization matures. The Operations processes to focus on are:
In CRM
- Order/Request Handling
- Problem Handling
In Service Management & Operation (SM&O)
- Service Configuration & Activation
- Service Problem Management
In Resource Management & Operation (RM&O)
- Resource Trouble Management
These processes define how to add, change, and delete UC Services. They also map out how to provision and fix them. The great thing about processes is they also tell you who does each task plus the support systems used, all very useful input to an impact analysis. Communications is always a problem in organizations and this project was no different. The development team had been beavering away in virtual isolation. The rest of the company had heard vague rumors of UC but the details were sketchy. Time for some process definition workshops! There is nothing better than a good Process Workshop to open communications channels between groups and to stimulate thought. They clarify workflow, establish task responsibilities, bring issues to the surface and get people involved. (But keep the number of workshops to a minimum or they will become tedious and viewed as time wasters.) Two to four well prepared workshops of 2 to 3 hours can achieve great things. In the three workshops I ran, we covered:
- Ordering
- Provisioning
- Logistics
- Network Planning & Engineering
- Help Desk
- Fault Restoration
- Performance Monitoring and
- The Support Systems for all of the above.
For me, the most interesting processes were Problem & Trouble Management. As the development team PM said, "Unify your communications and unify your problems." Understanding how to troubleshoot and
|
|
There is nothing better than a good Process Workshop to open communications channels between groups and to stimulate thought. |
|
repair these services, where the reported problem may only be a symptom of the underlying cause, is a challenge - especially where Voice is just another application running on the network. It is fair to say that the tools available to help out here are under-developed, but they will mature as the number of UC deployments grow.
The Systems impact assessment was also interesting. Sixteen affected systems were identified through the workshops and interviews. Only four systems had some work underway. That left twelve systems completely out of the project, although each required enhancements to be specified, built, and deployed. Not huge amounts of work required here but sufficient to warrant a budget being calculated and allocated. Obviously, this cost didn't make it into the business case. Failure to identify, prioritize, and get the changes into the development schedules for these systems was definitely going to cause problems in the rollout and user experience.
Organization optimization analysis is certainly called for when collapsing IT and Voice Support, but I would leave that for later, unless you come across issues that are going to greatly impede the rollout and support of UC. People tend to get concerned-- even threatened-- when you mention re-organization. Optimizing your support organization can happen as part of your ongoing productivity improvements. The obvious and suggested change is to merge your messaging and voice support groups within IT. Again, voice is now just another app on the network. How you do this depends largely on the individuals in the teams, but multi-skilling and cross-skilling is definitely the name of the game.
So what messages should you take away from my experience? Unified Communications is inevitable. VoIP will become the pervasive technology for voice communications. UC brings all the communications apps under the one banner. You will evolve into it anyway. Early adoption can deliver significant financial benefits, but these need to be weighed against the immaturity of the available support tools. My suggestion is to look at it now, and seriously. If you decide to go for it, remember to budget and plan for Operationalization. It's the details that will make or break your implementation. You don't want to mess with people's phone calls. They get angry. Be thorough and take care!
|
|
|
|
|
article page
| 1
| 2
| 3
| |
|
