Zeus makes some valid points about the whole "human latency" issue around Unified Communications. Human latency, for those not buzzword-current, is the time it takes for workers to move from one communications channel--say, email--to another one--say, the telephone--to respond to whatever issue they're dealing with. UC gets touted as the way to automate these multi-channel transitions, saving time and therefore money. For example, you get an email, and can see, within the email, the correspondent's current presence status, availability on various communications channels, and you can invoke the appropriate channel to respond without leaving the email program.
Zeus makes some valid points about the whole "human latency" issue around Unified Communications. Human latency, for those not buzzword-current, is the time it takes for workers to move from one communications channel--say, email--to another one--say, the telephone--to respond to whatever issue they're dealing with. UC gets touted as the way to automate these multi-channel transitions, saving time and therefore money. For example, you get an email, and can see, within the email, the correspondent's current presence status, availability on various communications channels, and you can invoke the appropriate channel to respond without leaving the email program.Essentially, Zeus says that at least when it comes to landline communications (as opposed to when we're mobile), most of us have developed pretty effective workarounds for the human latency in our communications routines, so that it's really not as inefficient to work in separate media as the UC marketers make it out to be.
But if Zeus is right, I wonder if it doesn't cast at least a little bit of doubt on all of the UC usage scenarios and, more important, all of the scenarios for Communications-Enabled Business Processes (CEBP). The vision of CEBP says that you'll add communications to workforce applications, scheduling apps, even production line applications for manufacturing. The classic scenario is that something goes wrong in the process and the system automatically calls the relevant people and sets up a conference call or whatever communication is needed to bring together those who have to collaborate to fix the problem.
But why is this really any different from the above-described "pure" communications integrations that UC interfaces/portals are meant to address? Any company that doesn't already have processes--however burdened by "human latency"--to deal promptly with exceptions, probably won't be in business very long. And the more critical the type of problem, the more likely that the relevant people have developed their own ways of overcoming the inherent human latency.
And expecting things to change relies on the assumption that everything goes off perfectly in the CEBP communications process. But CEBP will involve more complex call setups and communications among applications, and adding complexity to a process is not usually a recipe for improving its quality--especially a process like real-time communications, which is already highly sensitive to latency (the actual bits-and-bytes kind, not the soft "human" kind). And if the network happens to be running slow for any of the myriad reasons why networks run slow, and this happens just at the time your CEBP process is trying to set up a conference call to solve a critical issue that's arisen, what are the odds that the user won't just say, Screw it, and pick up the phone and start yelling? Now you've got the worst of all worlds.
I may be overstating my case somewhat here. All things being equal, the more efficient you can make communications interfaces and the more you can integrate voice into business processes, the more opportunities open up for smoother connections that actually do produce results. But I think that it's important to realize that both UC and CEBP are certain to fail spectacularly if they run over networks that can't deliver the performance required by real-time communications.
It's kind of ironic: In the IP telephony generation, voice was the un-sexy application that some IP data folks didn't care to spend a lot of time worrying about--until they had to. Now it's the IP network that gets short shrift while everyone talks about the applications layer, blithely assuming that it will be trivial to make this stuff work right.
And it's the IP networking experts' turn to say: Wait a minute...