CRM systems offer workflows, approval processes, and other business process enforcement features. But it's not always clear which feature you should use, and overly strict enforcement mechanisms cause big user satisfaction problems.
Business processes in some parts of a business may be water-tight, with strict policies and mechanistic task sequences. But not all business processes are strictly sequential or deterministic, and in some parts of a CRM application the workflows need to be very flexible. Particularly during the sales cycle, there are just too many important steps that your people cannot control. So let's examine some example business processes to illustrate the relevant CRM features and implementation approaches.
These are the classic strict workflows that typically involve controls, document updates, timeouts, approvals, escalation, and delegation. Business examples of these include order configuration, quoting, credit checks, special contractual terms, order fulfillment, customer support escalation, and subscription renewals. In CRM, most of these examples are focused on the order close and fulfillment areas of the sales process.
While some of these business processes really do require a tightly controlled series of steps, there are situations where variation is required. A key indicator of the need for variance will be frequent requests for: administrative override of thresholds; cancellation and restart of a "cloned" instance of the business process; requests to unlock records; and re-routing of exceptions. Whether or not those variance requests are granted, they need to be recorded so that analysts can troubleshoot that area of the business process. If there are a significant number of legitimate variance requests, the approval process may need to have more elaborate branches (with more subtle branching criteria), or may need a complete redesign.
Workflows and Trigger Sequences
In some cases, however, the real issue is that an approval process is just too rigid. It may be sufficient to have a series of workflows or triggers daisy-chained together to achieve a more loosely-coupled desired business process. (Note that in Salesforce.com as well as other CRM systems, workflows and triggers should not be intermingled on the same object, as this can cause race conditions or endless loops.)
Using a series of workflows to replace a formal approval process allows bypasses that let the business process proceed even if an explicit approval step has been delayed. The need for this is common in customer support and service processes. For example, if your replacement-part ordering business process requires a credit check prior to shipping, the workflow can allow the order to be kitted and put into a credit-hold area of the distribution center so it's ready to ship the instant the credit check is complete. Adding this flexibility to your workflows can increase order velocity even when approvals are delayed.
E-mail or Task threads
Classic workflow systems use tickets, transaction documents, or other explicit task assignments to manage the flow of work across the task owners. When a user completes a task, the ticket/document/task status is updated and the work moves on to the next person.
In some business processes -- particularly those involving knowledge workers or testing/measurement cycles -- the "next step" can't be known until the user completes the task. When the "next ticket" cannot be pre-undefined, the current worker needs to write up the specifics of the step for the subsequent worker. While the workflow system can assign a "write up the next step" task to that user, the meaningful assignment of work is really done by the users themselves. The details are often communicated by e-mail.
A variation of this issue occurs when task owners do not have system access (either because they don't log in often enough, or the company is trying to save on CRM license costs). Since it's inconvenient for these users to receive or update tasks within the system, e-mail -- the lingua franca of business -- is often a better way to notify users that they have action items.
In these situations, the workflow system should be used more as a reminder mechanism that manages deadlines, reminder e-mails, and metrics that track "who's got the ball." When business processes involve asynchronous activities and rework may be required (for example, drilling a well or passing a qualification test), a strict workflow system may just get in the way.
In all too many business processes -- particularly the early part of the sales cycle or the customer onboarding processes -- it is impossible to really know the exact sequence of steps. In the worst case, you have vague guidelines of what represents progress, rather than clear status indicators. Steps may happen out of order, in parallel, or out of your control. In these cases, any traditional workflow is overkill. All you really know is your belief about where the work is.
The classic examples of this are lead qualification in marketing and the prospecting/needs analysis phases of sales. In any CRM system, these are represented as status fields that are manually advanced according to the best judgment of the user. A given prospect can move forward or backward in the process at any time, and the semantics of each status may be highly debatable. While this is hardly the basis of a deterministic, efficient system...it fairly represents the real world.
As these processes may be long-running (e.g., sales cycles of 9 months, customer onboarding of 9 weeks), it is essential to use workflow concepts even though you won't have a true workflow. In particular, leverage:
• Deadlines for action
• Metrics for "time in stage" and alerts for "too long"
• Alerts for regression (e.g., a deal moving out in time, backwards in stage, or down in value)
• Reports that highlight the work pipeline, particularly bottlenecks such as "training class full" or "no travel after week 11 of the quarter")
Even though we'd like all our business processes to follow consistent rules, sequences, and timelines, the real world is filled with activities that just don't. If you can, characterize everything as a business process -- so at least you have a model. But make sure to apply the right level of workflow discipline so you don't drive your users (or worse, your customers) bonkers with heavy-handed enforcement.
Sign up for Computerworld eNewsletters.