CLOSING THE LOOP ON MULTIPLE, RELATED PROCESSES

Expanding Function-Specific Processes

I spend a lot of time talking to CRM vendors, and almost all of them boast about how their products support closed-loop processes. But what, exactly, do they mean by “closed-loop?” In general, what they are talking about is the ability to have the results of a process reported back into some application which verifies that the activity has been completed. For example, a closed-loop sales process will report back that a sale has been successfully closed.

Many of the CRM vendors are now providing applications which can close the loop between marketing (campaigns) and sales—the campaign management tool often includes a lead-generation and routing capability, whereby hot leads are sent to the appropriate sales person/channel partner, based on pre-established rules. If and when the sale is actually made, the marketing system is notified, thus, closing the loop.

So now we have two related—but separate—processes that are, in effect, linked so that verification of results can be shared. This is terrific! But it needs to go further. There are many business processes that are related to the same customer activity—not just campaign management to lead generation to sales results.

A Multi-Process Scenario

Consider the following scenario: A customer calls the contact center to report that the color copier she just purchased for her company isn’t working. The first process that kicks off is a support/knowledge management process—the customer service rep asks questions, which have been scripted within the CRM support system, and accesses a knowledgebase of problem-fixes to determine if the problem can be easily solved while the customer is on the line. But the solution isn’t readily available, and the problem seems to be mechanical, so the customer service rep notifies field engineering, kicking off another process—one that the support rep probably doesn’t have any access to other than sending an e-mail to start the process on its way. (In the more comprehensive CRM suites, this notification can be automatic and include all the relevant customer information—a great first step.)

In a well-defined customer-care process, the support rep might also notify (or the system might notify) the appropriate account executive, who would then start a customer-retention process to ensure the relationship isn’t jeopardized. Again, the customer support rep may notify sales, but she has no visibility into the process and may never know if, indeed, the account exec ever followed up.

Other, non-CRM processes may also kick in as a result of the support call; billing might need to be notified so that a hold on the accounts receivable process can be put into place until the problem is resolved; if other customers have had the same problem, QA might be notified, launching a bug-fix process.

Indeed, these customer-centric processes might not even be initiated by a customer. Sometimes internal events, such as a new product launch or changes in pricing, need to kick off a series of connected customer-centric processes Consider, for example, what happens when QA discovers a significant problem in a commercial software product. Besides running the bug-fix process, a marketing campaign might need to be launched announcing a free “upgrade” to the bug-less version of the software.

Right now, this process-kick-off is typically done by generating e-mails to the appropriate people so that they can take the initiative to launch their own processes. The problems are that this manual method is 1) time consuming, 2) vague—you can never be sure if the other processes are actually launched or completed, and 3), from the customer’s point of view, this should all be a single process upon which they should be able to get the latest status information. But there is no one, neither customer nor internal customer champion, who has complete visibility into the end-to-end process of satisfying and maintaining a good relationship with this customer. While each of the processes may be, within themselves, a closed loop, there is no such conceptual loop—much less closure—to the complete customer scenario. For the owner of the overall customer experience—be it the support rep, the account exec, a VP of customer experience, or chief customer officer—the “meta-loop” is left wide open.

Flexible Meta-Processes

I have started to call this collection of (sometimes, loosely) related business process that are initiated in support of a customer-related scenario, a “meta-process.” As metadata is data that describes other data, a meta-process is the set of rules, outcomes, and constraints that describe a combination of processes.

I am not, however, suggesting that these meta-processes be hardwired—or even mapped out as pre-defined workflows. This would be an exercise in futility--you cannot possibly anticipate every conceivable scenario and how each process plays in achieving the desired outcomes. Rather, I envision the ability to define desired outcomes, constraints, and meta-rules that determine which function-specific closed-loop processes need to be linked together to support the situation as it emerges. For example, “if more than two customers report the same problem with a model, create a bug report and send it to QA.” Or, “if any customer reports a problem within the first 30 days of use, delay billing until the problem is resolved.”

Note that I’m talking about linking multiple processes together, not building a single, monolithic process that spans functions, department, or even organizations (customer and partners) in a single application—not even for those meta-processes that are well-enough defined that they can be mapped. This is just too hard to manage, brings up thorny issues of ownership and access, and is almost impossible to change and improve.

There needs to be a meta-process owner who defines the linking rules and/or delegates appropriate participants to kick off a necessary application in realtime as the situation demands. The function-specific processes are still designed and managed by the people who are experts in the functional domain—sales managers define the sales processes, etc. Meta-processes must be modular and completely flexible to address any situation that may arise.

Emerging Technologies to Manage Meta-Processes

The first step to closing these meta-process loops is by taking the lead-routing-to-sales-and-back model and extending it throughout the meta-process; as each process completes, not only is relevant information routed to the related process but verification is sent to a central application so the meta-process manager knows when each linked process is completed. In the past, in order to support this process-to-process notification and information-transfer, you either had to make sure that each process was created using the same workflow or process automation tool, or you had to explicitly integrate the different applications. Today, Web Services promise to make this much easier to accomplish. Web Services can be defined to either request or provide information and/or processing among different applications, either asynchronously or in realtime.

Ideally, though, you want visibility into each process as it is running, not just a report that the process is complete. For example, the account exec wants to know exactly what is happening in the field service application—has the repair been scheduled? Has it been completed? Is a second visit necessary?—so that he can be on top of the customer-related situation. In short, it is important to surface the customer-centric business events that occur within each process.

Again, the promise that Web Services bring would support this type of visibility. Instead of just sending information between applications at the start and end of a process, messages could be sent at every event, so that the states—current status, next steps, what is being waiting for, etc.—of each process in the meta-process could be monitored by all appropriate participants, including, of course, customers.

Indeed, Oracle offers exactly this type of state visibility as part of its Oracle 9iAS Web services platform.

Another vendor, FileNET, a pioneer in the workflow industry, is taking a different approach with its new Brightspire product. Brightspire is a platform for creating associations of rules, processes, content, and any other relevant information in an object model so that, as a situation demands, the proper associations can be launched and managed.

Call to Action

The planning of meta-processes needs to start now. Again, this isn’t hard-coding long, tortuous workflow applications, nor is it defining hard-and-fast rules for how processes must work together. It requires that you:

• Identify who is responsible for customer experiences. This could be a single customer experience officer or a team of executives, each of whom is responsible for the overall experiences of a customer segment. These customer experience executives become the meta-process owners.

• Inventory the customer-impacting processes that are formalized (and/or automated) within your extended enterprise. Remember, these aren’t just those processes that obviously touch the customer (e.g., support, sales), but also include internal applications such as bug fixes and financial systems. You can determine which processes impact customers based on customer scenarios.

• Surface those business events within each process where state changes are significant to customers.

• Ensure that the appropriate information is being shared with the related processes. For instance, in the customer service scenario described earlier, information such as what was wrong with the printer is important for both the field engineering process and for the QA process. However, customer address is vital to field engineering, but not particularly useful to QA.

• Kick off the right processes in the right order based on current customer context. Instead of predetermining how every customer situation will be handled, link processes flexibly as the situation emerges.

• Ensure that the relevant people have visibility into the meta-process.

It is only with these pieces in place that meta-processes can be measured, analyzed, and improved. And that, indeed, closes the loop!