You've Already Got Communications-Enabled Business Processes

Communications-Enabled Business Processes, or CEBP, is one of the hot buzzwords in enterprise communications. Many people see CEBP as the Holy Grail of communications technology, something that may be attained years from now. But, in fact, you have CEBP in your enterprise now. It's called PBX features.Before I elaborate, let's make sure we're in sync on terminology. Definitions are still shaking out in this whole business -- some people use CEBP synonymously with UC, some present it as a subset or a parallel technology. My working definition is that, when we're talking about next-gen technologies, UC is the combining or integration of multiple communications channels -- voice and IM, for example -- while CEBP is integrating communications capabilities into business process applications -- anything from spreadsheets to custom, enterprise-specific apps. UC is more horizontal, tying together applications that do similar things in different media; while CEBP is more vertical, blending two types of applications.

So, for example, back-end linkages between Active Directory and Microsoft Office Communications Server let you have smart tags that allow you to hover over a name in a spreadsheet or Word doc and get the presence status and reachability info for that person or entity. CEBP gets way deeper, but that's a simple illustration.

That's what the vendors generally mean when they talk about their ability to do CEBP; an emerging capability. But a couple of weeks back, I spoke with Christian Szpilfogel, who works in the CTO's office at Mitel, and Christian made a very good point: "Let's face it," he said, "people have processes today."

Christian's example: Most businesses have processes in place for client interaction and escalation. It may be that if a call comes in to a senior member of the business, the policy says that the call has to be answered within X number of seconds, or else it goes off to that individual's personal assistant, and if the personal assistant doesn't pick up in X number of additional seconds, it goes to a backup person. Altogether, the policy may state, no more than 36 seconds is allowed to elapse before the call is answered by a human being.

There's a process in place for doing this, and it's enabled by the feature set of the PBX that's currently implemented. Changing this process into one that interacts with whatever business applications these employees work in is not going to be a trivial endeavor. For one thing, the current process, built on solid, 20-year-old technology, presumably delivers the 36-second performance. It's that bottom-line metric, not the technical elegance of the solution that provides it, that is the primary concern. Before moving to a more technically elegant solution, the business must above all else ensure that it won't lose the value it receives from the PBX features' ability to meet the metric.

There's a pretty common argument in the PBX world: Vendors who are new to the market and don't offer the full feature set that the incumbents do, tend to tell enterprises that they don't need all those features: There's 500 features! they exclaim. Nobody uses all those features. In fact, nobody uses any features, it's implied. It's too hard! There's no GUI!

The typical response, from the likes of Allan Sulkin of TEQConsult Group, is that all those features are there because somebody needed them. There's also a bit of sleight of hand going on; as the commenter to this post of mine points out, it's not as if all 500 of those features were things the user does -- many are administrative.

Ultimately, the current way of communications-enabling business processes -- via the PBX -- will give way to the SOA-enabled embedding of communications within business apps, together with fixed-mobile convergence that allows users the flexibility they require, while preserving the enterprise access and functionality they'll still need. Such "next-gen" CEBP offers tremendous promise in the form of improved business processes, quicker and more efficient exception handling, and more.

But we're not there yet, and the transition will not be a flash cut.