While UC network infrastructures, application integrations, and implementation and support costs are very important to IT management planning, they also need to know what technologies different end users involved in high-value business processes require to perform their jobs most efficiently and effectively. Who in the organization will represent the selective UC technology needs of specific end users inside an organization?
I should qualify the "WHO" in the enterprise as being one (or more) of the following:
- Business Managers
- Communication Application IT Management
- Business Application IT Management
- Individual End Users
- All of the above
What do you think? Which of the above will be most available or knowledgable to be involved?
I don't think it will be a centralized group any more. Telecom has always been centralized because of the PBX. IT was always centralized because of the glass room. When I was an IT Director at GE, we policed things pretty good. We had to worry about data base integrity, off site backups, disaster recovery, etc. We slowed things down. I imagine groups today will just go find a cloud service and be done with it. I see the same thing with voice. Hosted solutions, APIs, companies like Twilio, wireless solutions, etc. I think organizations will have a real tough time trying to keep UC and voice projects centralized moving forward.
I think you are right on about technology decentralization, i.e., wired and wireless networks, business process applications software, mobile endpoint devices, etc. Mobility will also drive hosted application services for both business users and consumers. But I think that the bottom line for control of who will use what UC technologies will come from two sources - business management, that will require operational flexible connectivity and interoperability away from a wired desktop for their business processes, and the individual end users, who will decide what devices and software applications they will use when away from an office desktop.
IT management's role will be to match these two sources of requirements and provide cost-effective technology options to support such needs. As I have pointed out many times, UC flexibility is not merely required to support internal business users, but must also support key external end users who are involved in a high-value business process. That means business partners and customers (consumers) who contribute to the "human latency" in the performance of a business process. Customers and customer-facing staff, in particular, need UC support because they are the key to revenue generation and achieving business objectives, as opposed to simply reducing costs.
So, how do we represent those two user constituencies, business process management and individual end users, in defining operational UC needs for IT to implement and support one way or another?
What can and should still be centralized is for business process call and message routing to a non-specific recipient ("person-to-process-to-person"), as opposed to a direct "person-to-person" contacts. That applies to both customer contacts as well as internal suppport activities, e.g., IT "Help Desk" functions. With UC presence, these can all be more efficiently handled by whoever is qualified and available (Skills-based routing) and not limited to just conversational voice connections. Any form of contact that satisfies both parties can be used. With increasing "smart-phone"mobile accessibility and various flavors of messaging, what I have labeled as "as soon as possible" (ASAP) communications will be very acceptable in most business process situations.
The question on the table is "Who will represent the user's requirements." I believe the obvious answer is "the users." I believe the users are speaking, but in many cases, no one is listening. Over the years of seeing technology deployed and used, I have seen some interesting applications of the features. Some users use the software and hardware in ways never imaginged by the creators. That fact speaks more to the ingenuity of the users than the creativeness of the developers. Therefore, the users will determine how they will use UC technology. In order for that to happen, UC facilities need to be available.I believe the bigger problems lies in the lack of process developing requirements for the system. In my recent article, I defined a requirements gathering concept called IT Cube - Six Perspectives to Project Requirements. I published an artilce similar to it focused more toward the UC industry and called it Will the REAL DefinitionS of UC Stand Up: 6 Perspectives For A Single Definition. In both articles, I discussed the six perspectives of any particular product or service. To answer the question of who will reperesent the end users of UC, the answer is two-fold: the users must represent themselves and the business analysts must collect, analyze and collate the requirements into solution sets to let the users create their final solutionsThe users must represent themselves. The beauty of UC is its ugliness: flexibility. Because of the many features involved in UC, users will adapt it for their use. For the mobile person, he will make more use of the mobility features. For the more stationary person, she will make more use of the stationary features. For the support staff, though, the variety of resulting solutions becomes a nightmare (different topic for a different time).For example, email still is an important communication medium. For a mobile person, the use of a smartphone with a decent keyboard is a life-saver. But as a stationary person, the dinky QWERTY keyboard on the smartphone won't cut it, therefore, they will use the more robust and feature-rich email components. The users will create the solution they need for their particular requirements. They need the building blocks and mortar to tie together. Fortunately, it is easier these days than the days of yore from the user's perspective to complete the process.Of course, that makes it more difficult for the technology staff to create and support. They need to know what to supply and then learn how users will create the solution. The tech staff may be proactive and put together solutions that meet specific user groups, which points back to the requirements of the systems and the lack of requirements gathering processes.For many companies, I find gathering requirements is a race to implementation, not a process with methodical steps involved. Fortunately, with the adoption of industry standards such as
we can put structure into the requirements gathering process with resulting benefits such as measureability, clarity, and requirements/functionaly grouping.With the proper processes, business analysts can gather the requirements for the system. The end users represent their needs and requirements, which the analyst must document. From the gathered requirements, groupings of end users will emerge so packaged, supportable solutions can be delivered.With that said, analysts must consider the other perspectives mentioned in the UC Cube article so their requirements can be met such as ROI, business justification, alignment with business initiatives and strategies, etc. No perspective exists in a vacuum, therefore, the final result must be a balancing act distilling all the viewpoints into something tangible and beneficial to the organization.So, to answer the question "who will represent the users' needs," the answer is clear: the users themselves first and foremost and the business analyst is responsible for putting them in a form that can be implemented.
To confirm your view about UC implementation planning responsibilities, I have started to see pundits, analysts and consultants increasingly warn IT management NOT to second-guess end user needs and requirements for telephony and UC technologies, especially when planning to replace legacy business telephone systems. One of the biggest mistakes IT/Telecom can make is to try to select new technology without doing any "homework." (And not just comparing pricing costs!) That "homework" is to ask business management what their current communications-based business problems are and what their new operational business process requirements will be in light of UC capabilities. If they don't have any answers yet, its time to find out more before making infrastructure implementation decisions, including the use of hosted services vs. traditional technology ownership, and the growing role of wireless mobile devices in business contacts.
I want to call your attention to the interesting white paper by Blair Pleasant, highlighting the end user's perspective of benefits from unified messaging (UM) features. It does a good job of summarizing and confirming much of what we expect users, who have access to UM capabilities, to say (after the fact). They will then be able to reportfrom experience more efficient and flexible messaging capabilities, including UC-based "click-to-call" benefits such as responding to a message with a "call back."
The study specifically noted that UM benefits will apply to customers as well as customer-facing internal staff, reinforcing the need to view UM and UC as important to direct customer interaction activities (contact center), or what I call "Customer UC." This view expands traditional emphasis on inbound customer person-to-person telephone contacts to include inbound messaging and outbound process-to-person messaging contacts and time-sensitive notifications. The latter is based on integration with business process self-service applications and what is now being lebeled as Communications Enabled Business Processes (CEBP).
CEBP, coupled with the rapid consumer adoption of multi-modal mobile "smart-phones," will explode the use of UM capabilities as an integral part of both enterprise UC for internal use, as well as for "Customer UC" interactions. However, this all begs the original question posed in this Forum, who in the enterprise will be representing the different end user needs (internal staff, customers, business partners) and priorities for UC (and UM) for implementation planning? Will it be line-of-business management, IT management, individual end users, or all of the above?
If all of the above, how should you orchestrate their involvement and who should be in charge?
End users can’t always speak for themselves. They may know what their problems are, but may not know how best to remedy them.
It is at this point they will need the help of “experts” who know what solutions are available and how best to utilize them.