Role-Managed Modeling of Business Processes: A CRM Example

by Alan Rickayzen | SAPinsider

January 1, 2003

by Alan Rickayzen, SAP AG SAPinsider - 2004 (Volume 5), January (Issue 1)


Alan Rickayzen,

A well-oiled customer interaction center is the secret to success for many organizations; it can serve as your virtual “shop assistant” in service-oriented companies and manufacturers, or in any commoditized industry where customer satisfaction and retention have become the keys to competitive advantage. Customers expect knowledgeable service and a high degree of responsiveness to inquiries, complaints, and orders.

But what about customers who need additional information for questions that can’t be addressed in real time? These processes can involve behind-the-scenes coordination between colleagues with different skills and different priorities. Without support of tools and processes to make sure inquiries are dealt with effectively and promptly, customer satisfaction — and customer retention — will suffer. And because these processes will differ according to the type of interaction (e.g., complaint, inquiry, or sale) and even the product involved (e.g., life insurance or home insurance), a simple “rule book” will not be enough. Enter the Process Modeler, which provides the software design support to coordinate the pertinent activities and colleagues via a simpler user interface so that the functional professional user can model the processes directly instead of depending on the IT department.

A role-managed modeling environment makes it a reality for operative functional staff to model business processes themselves. Although SAP’s Workflow Modeler was originally conceived for use within the Interaction Center, as in the example detailed here, it is now also used in other SAP areas.

There are many process-modeling tools that allow you to shape the way your processes should run or to communicate a new workflow design to your colleagues. But with the role-based Workflow Modeler, SAP goes one giant step beyond this. With this Workflow Modeler for mySAP CRM, once the processes have been designed, they actually run. You have created not just a simulation or a prototype — the process you design executes. Simply put, at the end of the session, you have an executable workflow.

For a manager in a customer interaction center, all that is needed is the ability to model the process flow, including loops, branches, and simple conditions. So SAP kept it simple. While the technology behind the Workflow Modeler is sophisticated, call center managers or other professional users will find just the resources they need to define or change a process themselves, without requiring the services of workflow specialists or outside help.

An Introduction to the Workflow Modeler for mySAP CRM

The engine that drives this workflow design process is Business Workflow,1 but the tool that models the process is something quite different. The Workflow Modeler for mySAP CRM runs in the Web browser and supports drag and drop, frame-to-frame eventing, and integration into the SAP Enterprise Portal. The Workflow Modeler is role-based, so the user interface and scoped-down feature set is designed specifically for the type of user involved (see Figure 1).

Figure 1
A Workflow Process Model with an Expanded View of a Nested Block

The user’s role determines the tasks of the workflow and the processes that are viewed. This means there is no risk of one call center manager — who, for instance, normally handles breakdown reports — interfering with processes defined by another manager responsible for managing customer contracts. It also means that even when a single call center services clients from many small companies, it can keep one client’s processes separate from the others.

Of course, when it comes to designing a workflow, the last thing you want is a dead-end process definition. A faulty process could be followed hundreds of times over before it is discovered — and any needed corrections will have high overhead, since they’ll have to be made while the workflow is running (a bit like trying to shoe a galloping horse!). To prevent design errors, the Workflow Modeler is block structured. Each new step creates or is added to a “block.” When a step is deleted, it automatically affects the entire block the step is in. This design ensures that workflows are in a consistent state when editing is complete.

This block structure not only keeps the total cost of ownership low but also serves another purpose. As a workflow definition grows, it might contain hundreds of steps. With a block structure, you can still implode the blocks that you are not currently working on to free up more of the screen (as shown by the red circles in Figure 1). This makes it easy to edit even large processes.

Designing a New Process in the Workflow Modeler

Consider the processing of a customer complaint: the customer contacts you, the complaint is forwarded to the appropriate service representative for handling, and a response goes to the customer.

Clearly, this is just the start — there are many possible variations and enhancements to be made (not least because, once the workflows are modeled, Business Workflow takes care of the periodic reporting to help you identify any bottlenecks or redundant steps in the process!). But let’s look at how to build a very basic customer complaint process from scratch with the Workflow Modeler.

Start from the mySAP CRM Interaction Center (IC) portal, usually within the administration area (see Figure 2). As part of the IC manager role, the iView2 displaying the Workflow Modeler can be started. The empty workflow definition displays the start and end points of the workflow.

Figure 2
Defining a Trigger for the Workflow

  Define the Process Trigger

The first thing to do is to specify how the workflow is started — whenever a new complaint is logged in the system. To define this as the start criteria, the manager in our example, “Alex Nielsen,” simply double-clicks on the start box of the empty process definition and selects the event customer complaint – created from the pick list under “Event Trigger” (not shown in Figure 2). This will:

1. Define a trigger for the workflow.

2. Inform the workflow that it is dealing with customer complaints. As a result, the reference to the customer complaint is added to the workflow definition3 and can be used downstream in the definition of the workflow process.

It’s worth pointing out that because this is a CRM environment, CRM actions could be selected, rather than business events to trigger the workflow. This is another example of how the Workflow Modeler has been tailored to this CRM role.

   Add Steps and Task Assignments

Next, Alex looks at the list under the “Components” tab (see Figure 3), which has been defined previously as part of IC customizing activities. This ensures that Alex’s workspace is not cluttered with components unrelated to the processes his team handles.

Figure 3
Creating a Basic Customer Complaint Process

He drags the first-level processing component (1stLevelSup) over to the workflow and drops it into the process panel. 1stLevelSup is little more than the encapsulation of a workflow task or subflow, together with an assignment of agents that will fulfill this task, a default agent determination rule, and the assignment to this manager role.

When Alex drops the component into the process definition, he is specifying that it applies to the customer complaint. If he wants to further restrict the agents that will receive this work item, he can also assign the component to a particular organizational unit or group of users. The outcome of this component is that the complaint is either completed or requires further processing; this outcome is automatically added to the workflow data pool4 so that it can be used later. The information is automatically updated in “Step Attributes.”

In Figure 3, you will see that Alex has also dropped in a component (InformCust) to send a final message to the customer when the complaint has been processed.

   Add Branches and Conditions as Needed

More involved complaints will often require additional steps beyond what a first-level service center can support. In that case, the manager will want the complaint to branch off to a group of more specialized users. So he adds a second-level branch to the workflow and includes a condition to determine whether or not the processing was completed.

To do this, he selects the “Elements” tab and its list of standard modeling elements, such as loops or branches (see Figure 4). Note that Figure 4 shows all the possible elements, but in practice only a few of these elements will be assigned to the IC manager role, once again keeping Workflow Modeler uncluttered.

Figure 4
Adding Branches and Conditions

Alex has dragged the Condition into the workflow, which immediately generated a new branch. He can now specify the exact condition in the Step Attributes panel. The result of the first-level processing is automatically visible in the drop-down list for the condition (in this case “Completed”).

You will notice that dropping this condition into the workflow creates a new block. It is worth giving the block a name (in this case “Complications?”). As the process becomes more complex, this helps to see, at a glance, the different phases of the process.

Finally, Alex drops the second- level processing (2ndLevelSup) and the inform manager command (InformManage) components into the workflow. InformManage is slightly different from the other components in that it simply instructs the system to send an email to the manager. No user interaction is required.

So the workflow is now complete, as shown in the full screen mode in Figure 5. Alex can save it, and the definition is automatically checked so that there are no syntax errors (such as an impossible condition). If, and only if, there are no errors, he can activate it. The next time a complaint arrives in the system, this workflow will be triggered.

Figure 5
The Completed Workflow


What the manager won’t see is that when he saves the workflow definition, it is passed to Business Workflow in XML format and converted into the native Business Workflow format, so that it behaves just like any other workflow in the SAP Web Application Server (SAP Web AS). What’s more, workflow designers and developers can view it in the standard Workflow Builder to look at the technical details of the workflow definition that are hidden from the customer interaction center manager.

Because it is the Business Workflow that executes the workflow, all the administration, archiving, and reporting features are identical to other workflows running in the system — whether they are related to the IC or not. This reduces administration, training, and end-user education, so the total cost of ownership for these IC workflows is virtually zero.

And while it has a powerful engine behind it, the IC Workflow Modeler offers end-users a simple, intuitive, browser-based user interface that can be used by managers in the IC. This same modeler has been preconfigured to suit the roles in the SAP NetWeaver Master Data Management (MDM) environment, as shown in Figure 6. There are differences — for example, CRM actions are a specialty of mySAP CRM and have no meaning outside this context, so they are not offered as triggers in the MDM environment. Clearly both customizations contain a separate set of components. However, the underlying modeler, together with the connection to the workflow management within the SAP Web AS, is identical and enables functional users to model their own workflows without being distracted by complexity.

Figure 6
IC Workflow Modeler Uses Business Workflow as the Workflow Management System or Engine

For more on the IC Workflow Modeler, visit the IC section of the CRM service marketplace ( For information on workflow, visit

1 With Business Workflow, SAP provides an efficient cross-application tool that enables integrated electronic management of business processes. Business Workflow is a workflow management system that enables customer-specific business process flows to be coordinated and controlled on a cross-application and cross-work center basis (source: Business Workflow has a powerful modeling tool - the Workflow Builder - that supports many more workflow features than the Process Modeler. However, the role-based Process Modeler can only achieve its simple user interface by jettisoning workflow features not usually needed in this functional users environment (in this case the IC).

2 iViews are the programs that run within the SAP Enterprise Portal. You can think of each iView as a frame displayed in the Enterprise Portal.

3 Those of you familiar with Business Workflow will know that this is a Business Object Repository (BOR) or ABAP object reference stored in the workflow container.

4 The workflow container.

Alan Rickayzen has been with SAP since 1992 and in data processing since 1988. Since 1995, he has been performing development work as well as process technology consulting for various major US customers and, as a result, has amassed a good deal of technical knowledge in collaborative process technology. Alan Rickayzen is co-author of the book Practical Workflow for SAP, available at, and may be contacted at

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!