That Human Latency post of mine has earned me another rebuke, this from Art Rosenberg. Art writes:
That Human Latency post of mine has earned me another rebuke, this from Art Rosenberg. Art writes:
It looks like the complexity of "unified communications" is even confusing the experts, especially when it comes to user metrics such as individual vs. business "productivity," "presence' vs. "availability," and "human (contact) latency." Part of the problem is that we are talking about communicating with people, not just devices (hardware and software), so everything is relative and must be personalized to the individual user and their circumstances.
Zeus Kerravala started the ball rolling by claiming that "Presence, not VoIP, is the foundation of unified communications," because it provides real-time "intelligence" about a contact recipient's accessibility. However, being accessible for a phone call does not mean being able to talk or listen. This is particularly dynamic for mobile users who don't have control over their environments. A second consideration is "time availability," which can be based on the relative priorities of other user activities that are being interrupted by an unscheduled real-time contact that can't be multi-tasked. Those other activities and any unscheduled, but perhaps important phone conversations, are therefore all subject to "human latency" delays which can be time-critical. So, user "productivity" and task performance values are really all relative to the individual end user; multi-tasking that enables more things to be done concurrently, rather than sequentially, provides the flexibility for handling the complexities of the real world in a timely manner.
Brent Kelly pointed out that your [i.e., Eric's] view of the benefits of UC flexibility was too narrow, because you thought it had to to with simplifying a communication procedure and saving a few minutes here and there. He was right! The real value is in saving hours or days to either:
1. Contacting/responding a specific individual (person-to-person or process-to-person), or
2. Contacting anyone who is available and qualified to respond to the issue at hand (traditional contact center staff)
Obviously, when the situation is time critical, the value and the need for faster contact with people, regardless of their location, becomes key. That is why mobility is becoming increasingly important to timely communications with people. Coupled with mobility, however, is the need for flexibility in communications that UC can offer. Voice conversations are no longer the only form of real-time interaction, now that IM is available (although still not "federated" across networks like the PSTN), and asynchronous, cross-modal messaging, with immediate notification and delivery to mobile handheld devices, also offers practical and flexible communications between senders (people or applications) and recipients who have different interface constraints. One can look at "asynchronous messaging" as not just a time difference between the sending to the receipt of a message, but also the difference in medium that the message is created in vs. the medium it is received in.
In the real world, dynamically switching modalities of contact between synchronous an asynchronous has always been inefficient or impossible because of the different network and communication application silos. The one early exception was switching from a phone call attempt to a voice message (telephone answering), but even those voice mail technologies were very restrictive to system "subscribers" vs. external "callers." (For example, subscribers could not "reply" to caller voice message with another voice message.)
With IP converging the communication network infrastructure, the door has opened to really run with the "unified messaging" ball and UC. This is what I dubbed "transmodal communications," where one can easily transition seamlessly between asynchronous and synchronous forms of communications, as well as enable senders and recipients to dynamically choose the medium of messaging independently of each other. "Click-to-call" and "Click-to-chat" are good examples of what UC adds to UM capabilities, and where "presence" information plays a tactical role.
The bottom line of such UC/UM flexibility will be to minimize any form of "human contact latency" that results from delays in using and switching between traditional communications to contact a person.
Needless to say, mobility plays a strategic role in reducing communication "accessibility" delays, but brings with it the need for UC flexibility. While UC works for the desktop, as pointed out by Zeus, the real payoff will come when people are away from the desktop. Multimodal mobile devices like the iPhone and Blackberry are essential ingredients for successful implementation and exploitation of UC/UM. So, I see contact initiators, decision makers, and action takers all being able to do their thing more easily, flexibly, faster, and more effectively with the combination of mobility and UC/UM.
Your concern that we still need reliability and capacity in our converged network infrastructure is a perfectly valid point, but until you know how future mobile, multi-modal traffic will flow, you can't configure those network needs very well.
The concepts and even the labels of UM and UC are not new, but the technology to implement them as a service to all end users across all networks is just starting to evolve. There is a lot to learn and a lot of new technologies to develop before we are finished with our "journey" to UC.
Zeus Kerravala started the ball rolling by claiming that "Presence, not VoIP, is the foundation of unified communications," because it provides real-time "intelligence" about a contact recipient's accessibility. However, being accessible for a phone call does not mean being able to talk or listen. This is particularly dynamic for mobile users who don't have control over their environments. A second consideration is "time availability," which can be based on the relative priorities of other user activities that are being interrupted by an unscheduled real-time contact that can't be multi-tasked. Those other activities and any unscheduled, but perhaps important phone conversations, are therefore all subject to "human latency" delays which can be time-critical. So, user "productivity" and task performance values are really all relative to the individual end user; multi-tasking that enables more things to be done concurrently, rather than sequentially, provides the flexibility for handling the complexities of the real world in a timely manner.
Brent Kelly pointed out that your [i.e., Eric's] view of the benefits of UC flexibility was too narrow, because you thought it had to to with simplifying a communication procedure and saving a few minutes here and there. He was right! The real value is in saving hours or days to either:
1. Contacting/responding a specific individual (person-to-person or process-to-person), or
2. Contacting anyone who is available and qualified to respond to the issue at hand (traditional contact center staff)
Obviously, when the situation is time critical, the value and the need for faster contact with people, regardless of their location, becomes key. That is why mobility is becoming increasingly important to timely communications with people. Coupled with mobility, however, is the need for flexibility in communications that UC can offer. Voice conversations are no longer the only form of real-time interaction, now that IM is available (although still not "federated" across networks like the PSTN), and asynchronous, cross-modal messaging, with immediate notification and delivery to mobile handheld devices, also offers practical and flexible communications between senders (people or applications) and recipients who have different interface constraints. One can look at "asynchronous messaging" as not just a time difference between the sending to the receipt of a message, but also the difference in medium that the message is created in vs. the medium it is received in.
In the real world, dynamically switching modalities of contact between synchronous an asynchronous has always been inefficient or impossible because of the different network and communication application silos. The one early exception was switching from a phone call attempt to a voice message (telephone answering), but even those voice mail technologies were very restrictive to system "subscribers" vs. external "callers." (For example, subscribers could not "reply" to caller voice message with another voice message.)
With IP converging the communication network infrastructure, the door has opened to really run with the "unified messaging" ball and UC. This is what I dubbed "transmodal communications," where one can easily transition seamlessly between asynchronous and synchronous forms of communications, as well as enable senders and recipients to dynamically choose the medium of messaging independently of each other. "Click-to-call" and "Click-to-chat" are good examples of what UC adds to UM capabilities, and where "presence" information plays a tactical role.
The bottom line of such UC/UM flexibility will be to minimize any form of "human contact latency" that results from delays in using and switching between traditional communications to contact a person.
Needless to say, mobility plays a strategic role in reducing communication "accessibility" delays, but brings with it the need for UC flexibility. While UC works for the desktop, as pointed out by Zeus, the real payoff will come when people are away from the desktop. Multimodal mobile devices like the iPhone and Blackberry are essential ingredients for successful implementation and exploitation of UC/UM. So, I see contact initiators, decision makers, and action takers all being able to do their thing more easily, flexibly, faster, and more effectively with the combination of mobility and UC/UM.
Your concern that we still need reliability and capacity in our converged network infrastructure is a perfectly valid point, but until you know how future mobile, multi-modal traffic will flow, you can't configure those network needs very well.
The concepts and even the labels of UM and UC are not new, but the technology to implement them as a service to all end users across all networks is just starting to evolve. There is a lot to learn and a lot of new technologies to develop before we are finished with our "journey" to UC.
