EFFICIENCY IS NOT THE GOAL; DYNAMIC EFFECTIVENESS IS

Business is like life. Just when you think everything is going as planned, stuff happens. And you are suddenly faced with new challenges and new opportunities. And, like life, if you aren't equipped to respond and willing to improvise, you'll never get anywhere.

For this reason, defining and automating static business processes is of limited value. For as long as there has been business, companies have established processes to address the day-to-day activities of running the company. Processes were based on explicit policy (e.g., only paying customers get service), sequence (e.g., all orders must be entered first in the accounting system before an invoice can be generation), and authority (e.g., only the boss can approve a line of credit). (Note that these map to the Rules, Routes, and Roles of workflow that we have talked about for almost a decade.) The goals of these processes were consistency, accuracy, and efficiency.

In the industrial age, efficiency experts scrutinized the factory floors to determine how to achieve the desired result using the least amount of effort and redundancy. (As my father explained, you looked for the laziest person doing an adequate job and copied his movements. The lazier the person, the more likely he is to find the easiest way to do anything.)

In the service economy, customer-centric processes, such as claims adjustment and credit application processing, were defined, automated, and implemented, again, based on eliminating redundancy, ensuring accuracy and consistency, and finding new efficiencies.

But, today, in the customer economy, the efficiency-based approach to process automation and management doesn't work. Why? Because today's business processes must support customers' goals and contexts (or scenarios) rather than merely codifying internal operations. Processes must be defined from the customer's point of view, and the customer's goal and context must be carried across and throughout all activities that make up the process. And the goal, context, and current status of the process should dynamically determine the next step in the process. In a world where customers' goals and contexts are continually changing--even ever so slightly--it is next to impossible to anticipate every scenario and outcome that a customer needs.

KEY TENETS OF CUSTOMER PROCESSES

So what do you do? Here are some key tenets to live by as you define and automate your business processes:

You Don't Own your Customer Processes--Your Customers Do!

Your job is to respond to your customers. Remember that every customer process or scenario has a starting point, a goal or outcome, and the steps the customer expects to take to reach that goal (see Illustration 1). In the customer economy, you can't force the customer to do things the way you want them to. For example, in most e-commerce processes, the e-tailer wants the customer identified immediately, before she even begins to shop. From personal experience, I can tell you that, when I am forced to register on a site before being able to browse and shop the site, I am gone!

A recent example: I was sent a solicitation via e-mail for a real-estate site that let's you know what properties in your neighborhood (or your desired neighborhood) are on the market along with details such as asking price. The site acted as a brokerage for both buyers and sellers. This intrigued me. I wanted to know what the property values were in my area. If they were sufficiently high, and those is some of my other desired neighborhoods were slightly lower, maybe I would consider selling and upgrading to a larger condo. If I found information that pleased me, the site would have realized some definite business with me.

When I arrived at the site, I was prompted for the zip code that I wanted to investigate. No problem. Makes perfect sense. How could the site know what information to present to me without knowing this crucial piece of information? However, the next screen didn't display any real estate info, but presented a registration form, including required fields such as name, e-mail address, and whether I owned my own home. I was not about to provide this personal information just so I could peruse the site. I suppose I could have provided phony information--and a lot of people I know do just that. Instead, I left the site never to return. Obviously, I was not meant to put my house on the market that day.

A Generic Customer Scenario(r)
Please download the PDF to see the illustration.
Illustration 1. Customers own their business processes. They have steps they are willing to take to achieve their desired result.

Customer Processes Aren't Always Linear

When designing processes in workflow and business process tools, you follow a flow of steps (tasks) and information from start to finish, capturing exceptions and different possible routes based on defined choices. However, one of the "gotchas" of creating processes from what you think is the customer's point of view is that you design with the expectation that customer will start at a specific point and then move step-by-step to the end. But customers often enter at one point, double back, loop around, stop and come back later, all the time assuming that they are following a straight and logical process and not understanding why they hit stumbling blocks.

Think about planning a trip. Some people start with the location, some with the dates, and some with an open-ended Trailways ticket to anywhere! For example, I knew a couple who planned their annual trip to New York based on when they could get a reservation at their favorite (and trendy) restaurant.

Even formal business processes like applying for a mortgage might not begin with submitting an application. A perspective mortgage customer might first submit a financial statement, or an assessment of the value of their current home, or the building plans for a new home before he ever formally applies. Your systems must be built to support the often circuitous routes that customers take to their goals.

Customers Change Their Requirements

Now let's add another common monkey wrench into the smooth running of automated processes--the "never mind" or "I changed my mind" scenario (see Illustration 2).

A Customer Changes His Mind Customer Scenario(r)
Please download the PDF to see the illustration.
Illustration 2. Within the course of a process, customers often change their minds about what they want as the ultimate outcome.

Here are two examples:

Scenario One. You are a car dealership, and you have just sold the customer your top-of-the line model--a Silver Volvo Convertible with black leather seats and a custom-installed GPS system. The day before she is scheduled to pick it up, she calls and changes her mind. She wants the Red Sedan instead with the same GPS system. And she still expects it tomorrow.

Scenario Two. You are a subcontractor to a manufacturer of cell phones. Your customer has specified the design of a phone and wants 100,000 manufactured and delivered within six weeks. After all negotiations have been agreed upon, you are ready to start production. Then you get a call from the phone manufacturer requesting 25,000 phones to be delivered in two weeks.

Customers change their minds all the time, whether they are consumers or business accounts. In the past, we've dealt with these changes as exceptions and have penalized the customer by charging extra, adding more time, or forcing them to re-enter negotiations as if it were a new order.

Today's customers expect us to be able to adapt to their changing requirements and circumstances. And, in fact, customers reward you with their continued business when you make it effortless for them.

Customer Processes Expand

Be aware that customers will also, mid process, expand their requirements. "I wanted 2,000 widgets by Wednesday, but now I need 6,000 widgets and throw in a couple hundred do-hickeys." We call this the "by the way" or "as long as you're at it" syndrome. Customers don't care that this means starting another process or handling everything by hand to get it done. They just want it done! (See Illustration 3.)

Here are two examples:

Scenario One. My cable TV isn't working, so I call my provider and arrange for the repair. When the repair person comes to fix the problem, I want her to also be able to change my package and add the premium movie stations.

Scenario Two. I manage the telecommunications systems for my company. I have ordered 300 custom-designed cell phones for my mobile sales force, but I need to change the specs. When I put in the engineering change request, I also want to add a new authorized purchaser to the account team.

In both these cases, the person or system that is working to address the original customer goal is most likely unable to even begin to address the additional requirement. To the company, the requests are very different, satisfied by different departments and different automated systems. To the customer, this lack of seamlessness is irritating--after all, it is the same company and same relationship.

DEFINING ADAPTIVE PROCESSES

Requires Intelligence, Not Artificial Intelligence

When we talk to our clients about building or using systems to support adaptive business processes, their faces get very pale, their eyes become wary, and they haltingly ask if we mean incorporating AI into the automation of business processes. Not at all. It isn't reasonable, or even possible, to anticipate all the exceptions, variations, expansions, and changes of mind that will occur during the course of any process. You cannot program that all into a system and expect it to work.

Adding "While You're At It" to a Common Customer Scenario(r)
Please download the PDF to see the illustration.
Illustration 3. Most Customer Scenarios need to accommodate parallel scenarios as the customer, in the context of interacting with you, thinks of new or additional needs. These "oh by the way" typically cross organizational or functional boundaries. .

We advocate mapping out your processes from the customers' points of view and then determining what steps can be supported with an automated process (or manual process) and what steps require human intervention.

Build Modularly

As we have written before in earlier Reports, we strongly advocate creating small, modular automated processes (that often involve human decision-making). Each process is defined and owned by the functional department that is responsible for that area. For example, a credit checking process, which is often part of a longer sales process, is owned by the finance group, not the sales team.

These small modules are then pulled together as necessary to address customer needs. Oh, sure, rules about when to pull in certain processes can be defined so that many common scenarios are handled automatically. But the key is to recognize that requirements will change, processes must adapt to respond to these changes, and that someone must own the overall customer scenario, ensuring that the customer is satisfied.

Build in Adaptability Within Process Modules and Between Modules

The department or functional area that is responsible for each sub-process or process module needs to have the flexibility to adapt its process to the circumstances at hand in the customer's context. This is usually best done by allowing the group to set up business rules to handle common variations and to use visible exception handling for unusual variations.

Then, based on the customer's context and the outcome of each process module, you'll need to be able to trigger different paths as the scenario moves from module to module. These may be handled "automagically," using a set of predefined business rules, or they may require manual overrides. In either case, an empowered customer advocate needs to be ultimately responsible for the Quality of the Customer Experience(SM), the outcomes achieved, and the costs and benefits associated with the overall process flow.

Look for Tools that Support "On the Fly" Adaptability

As we move into this new era of Adaptive Business Process Management, we need IT tools that will enable us to design and to refine business process modules on an ongoing basis.

Each business process module should have a set of automated, visible, yet modifiable business rules based on parameters and attributes that are customer-friendly. The business subject matter experts who are the sub-process owners should have the ability to define and to continuously improve these rules.

The linkages between business sub-processes are where the real care needs to be taken. We need tools that will allow us to trigger new sub-processes or to jump over no longer necessary sub-processes as conditions change. The rules governing these inter-process module shifts should be handled by a customer experience manager or customer advocate who is able to optimize the trade-offs between customer experience and costs-to-serve. The business rules should be automated, visible, and easy-to-override.

We know that customers' contexts will change. Customers will often want or need to loop back through processes we've already handled once, but each time with a different set of parameters. We also know that customers will often spawn new processes in parallel with the ones we're already handling, and that they won't be satisfied until both scenarios have been completed and their desired outcomes achieved. Welcome to the new world of Customer Scenarios and Adaptive Business Process Management!