Business Process Automation is one of the high value/high ROI applications for UC, but there are different approaches to accomplishing the automation.
While no one disputes the benefits of automating business processes within a company, the "process" of automating can make an IT manager tear out their hair! If I have already endured the pain of implementing a traditional BPM (business process management) solution, why would I need or want to look at something different?
You might not need something else. Everyone should evaluate the benefits of a solution as they apply to their purposes. However, the key is to do the evaluation, not just dismiss it because you have something in place. Many people find their BPM deployments have these downsides: expensive, slow to implement new processes and/or roll out changes in existing processes, requires highly specialized programmers, is typically applied to only some portions of the entire process, and is completely removed from the communications used to complete each step of the process. In these instances, often CBPA can automate entire processes across the enterprise, including the use of existing BPM applications. CBPA solutions typically have more and stronger integration with enterprise business systems such as CRM and accounting systems and can extend automation (not just management or centralization) to the whole process. In addition, because BPM solutions are typically communications unaware, they are unable to provide insight into all of the communications needed to complete the process. CBPA is the only methodology that correlates all these business transactions to related communications events like phone call history and email messages. This gives a company a complete view of interactions with customers and vendors.
OK, now I’m confused! I’ve heard about CEBP (communications-enabled business processes) and now you're talking about CBPA (communications-based process automation). Does one bring my business more value than the other?
Yes to your question! Since CBPA (the term created by Interactive Intelligence) is essentially process automation built on top of a communications platform, its main focus is managing, automating, and streamlining communications and processes, not just one or the other. CBPA acts like an umbrella over all the related communications and work within a given process, directing work to the best place to ensure the entire process is completed efficiently and initiating or responding to communications as needed or desired. CEBP’s main focus, on the other hand, is to embed communications abilities into an application that is otherwise communications unaware. This almost always requires some customization of an application to achieve. It also means that the scope of the benefits is very specific and related to the customized application.
How do companies go about identifying the processes that should be automated, and isn't this a big undertaking? What are some steps companies should take when looking at doing CBPA?
With all due respect, and I'm sure it would be fun to argue who exactly coined CEBP and what it exactly stands for, this is hardly a new concept.
In 1988, the company I was with wrote a program to take invoices generated on a UNIX-based midrange system and automatically fax them using a Canon fax machine equipped with an RS232C interface. Previous to this, a group of five employees spent the better part of their afternoon taking these same invoices off of a continuous forms-feed impact printer, breaking them up, and then feeding them into a bank of fax machines. E Voila! Real ROI generated through the implementation of a Communication Enabled Business Process. So the question is, CEBP has been around for so many years (and they have), why haven't pervaders of UC solutions been able to capitalize its benefits? The answer lies in the following question. "Who exactly cares about CEBP"
What is undeniably unique about CEBP is the approach you must take in order to effectively utilize it. The first and most important thing to recognize is that the key contacts you will need to establish are quite different from those you are used to working with. Most UC deals are done with IT or Telecom managers. However, in most organizations of size, they are simply not that familiar with the day-to-day operations of most departments, and therefore a CEBP pitch will typically fall on deaf ears here. Instead, you need to shift gears and get to the Line-of-Business managers. These managers will always have operational budgets at their control, and may even have P&L responsibility. If you can convince them that you can save their departments real budgeted dollars and/or increase their department's profitability, they will find a way to get the necessary funds to invest in your product or service. And in fact, this is much easier than trying to get a director to carve money out of a company's overall IT or Telecom budget.
I agree CEBP has its roots in many individual projects that have gone before it. However, CBPA (Communications Based Process Automation) is a completely different solution. CEBP is primarily used to enable some kind of communications within an application. This usually involves much custom programming to achieve the end result, perhaps a button in an application that dials the phone number of the customer. CBPA manages and oversees all kinds of business processes and integrates communications into them. There will be many processes automated by CBPA that don’t have the slightest thing to do with communications. Using queuing, routing, presence, and recording, CBPA delivers work to the most qualified and available worker, wherever they are located within the enterprise infrastructure. When that worker finishes with that step, automated steps can be executed or the work can be routed to the next worker in the process. The combination of actions and activities is virtually unlimited. If anywhere in that process any kind of call, email, or web chat needs to occur, CBPA initiates them seamlessly as the process requests them because of its tight integration with the communication system. Throughout the process, workers and managers have complete visibility into the real-time status, progress, time-in status, and work assignments. I also agree with you that it’s better to present these kinds of benefits to executives, line of business managers, or a CIO with an understanding of the business side of the company. Since CBPA can have a significant effect on the financial needs of a company, these executives and managers are the most likely people to recognize the potential benefits.
People appreciate CEBP concept as it involves the customization of business application to enable communication. However the reverse I think involves whole lot of work in terms of developing the communication capable business process is not it more work and will enterprises appreciate it?
Thanks for the clarification Tim. It sounds like, in order to take full advantage of your concept (CBPA), organizations with manual processes will have to retool their entire enterprise, while the one I described (CEBP) calls for an enhancement of process only where communication is involved (i.e. automated faxing, rules based routing of calls coming into to a call center, etc). If I have this right, then I understand Arun's concern.
The adoption of CEBP is quite simple and painless. Your statement claiming that CEBP “. . . usually involves much custom programming to achieve the end result” is simply not true. For example, many companies in my industry (fax server) have long since written standard connectors for the most commonly used ERP systems such as SAP and Oracle, industry specific systems such as McKesson and Cerner in the healthcare sector, and for the integration of multifunctional devices (all-in-one copier/scanner/printers) for handling paper-based documents. Other specific integrations might require 20 lines of XML programming, but no one is required to do months of custom programming.
Conversely, and please explain where Arun and I have it wrong, it sounds as if organizations are required to rework entire business processes in order to utilized CBPA toolsets. As you said, “The combination of actions and activities is virtually unlimited.” That would mean that the tools offered by a CBPA system would also have to be unlimited. Of course, it also sounds like CBPA might be nothing more than setting up workflows with rules based routing and triggered communication processes, all generating reports allowing the system to be managed properly. If this were the case, I would recant my statement about it being a long and arduous process to implement CBPA and encourage people to consider both. I look forward to your feedback.
To respond to Arun's question about the amount of work necessary to enable a communications-based business process as well as Dan's comment, ironically, the process of customizing an application to embed CEBP can be somewhat difficult. The required changes in the app and the amount of extra functionality will be indicators of how difficult the customization will be I understand the concern about the work involved in connecting business process automation to the communications system. With traditional business process management suites, that would be a big concern. However, CBPA uses the communications system (and it’s integrations to other enterprise applications) as the foundation of the business process automation engine. The inherent queuing, routing, presence, and recording abilities of the communications system are leveraged to deliver work to the most qualified and available worker. In an intuitive visual design environment, process flows could be drawn out in flowchart fashion. It doesn’t have to be hard or complicated. When the communications system is the foundation, most of the interfaces and integrations are already in place.
Using CBPA, someone can choose to automate one action or a whole process. There’s no need to “retool.” However, I do think companies who are looking for significant improvements in their productivity, time in process, or reduction in expenses and resources will want to spend some time analyzing and optimizing for automation. That is a process any company would do when using any process re-engineering. If you’re just enhancing one aspect of a process or one step, that analysis is probably not necessary.
I can see where integrating CEBP changes into some apps might take a few lines of XML, but it’s not going to be that simple to do inside a Saleforce.com, Microsoft Office, Siebel, or Oracle app unless they built-in prior support for it. As you point out, when industries have adopted a documented API to add in functionality, your workload is much lighter. We often find people trying to add in unique functionality specific to their business – functionality and flexibility not addressed by industry standards or APIs. This is especially true when companies have decided to create their own CRM, order processing system, or other key application.
CEBP is meant to add communications ability to an application that was previously not communications savvy, at least in some aspect. With CBPA, the original application still does the work it was designed to do and the communications system works with the application data and uses the UC and contact center advantages to manage and expedite that work delivery, status, and process flow. Integration to the data could be via database connection, built-in file format or application support, or a custom connector. If the process requires five applications, it doesn't matter that much to CBPA because CBPA is working at the process level and adding communications abilities at the necessary places.
In that sense, it is more like your “workflow” idea but with both queuing and routing, web service calls to additional services and resources, and the ability to take appropriate action based on changes in database records or other data changes.
Because CBPA inherently understands the communication abilities available, it can initiate a call, email, or chat to a customer, vendor, employee, or supervisor. It works the other way also; CBPA can take action based on new or additional calls, emails, or chats and thereby affect running processes with the new or updated information. CBPA immediately associates processes and interactions.
CBPA doesn’t have a huge number of commands or tools. It does have some key preset actions implemented in a very flexible way. For actions that can’t be handled within the primary set, there are tools that allow you to make web service calls and pass variables or execute subroutines to perform functions outside of the usual actions.
Additionally CBPA maintains proper data security based on roles and provides rich visibility by providing real-time monitoring and historical reporting.
I see no reason why you couldn’t use both CEBP and CBPA. In general, CBPA should help companies complete the same or improved processes faster and more efficiently while removing many areas of human latency (i.e., the file sat on my desk for two days) and errors, replacing slow tasks with automated actions, and systematizing company specific processes to provide a consistent experience.
Once again Rick, thanks for the excellent explanation. And please don't get me wrong; I can, as you envision, see a time and a place for both CBPA and CEBP. Left to choose, I think it boils down mostly to a companies individual direction and culture. There are some points in a process's life-cylce that call for a rip-and-replace mentality, clearly a perfect spot for CBPA.
In others, certain process improvements might have already been implemented which come up just short of the CBPA end-game and are just in need of a tweak or two. Still other organizations are simply not prepared to and or don't have the funds to implement larger projects, but are still always looking for ways to reduce operating budgets (hard dollar ROI). These latter two examples are often perfect for a CEBP solution.
In either case, let's just agree that the amount of work that goes into each will come out in the wash as it will be a primary factor in creating and evaluating the ROI of any such project.