When you ask managers and executives about the business outcomes they are trying to achieve, their answers are a pretty good indicator of the reports, metrics, and key performance indicators you should bake into your solution.
Knowing Where Your Parents and Children Are
When you ask different people to describe the outcome of the work you’re trying to improve, you sometimes get different answers. Imagine that you work for a credit card company and have been asked to improve the way your company handles disputed transactions. A disputed transaction is an incorrect or potentially fraudulent transaction that shows up on a cus-tomer’s bill, often in conjunction with some other event, such as a lost or stolen card. If you asked the customer what he wants to happen, he’d probably say, “I lost my wallet. How do you fix everything?”
What happens when you ask your business team? You might get answers like these:
✓ The vice president of your fraud department might say,
“We need to make sure we investigate any potential fraud and file the appropriate documentation with the government.”
✓ The vice president of operations might say, “We need to work with our merchants to refund any incorrect payments.”
✓ Your chief marketing officer might say, “We need to get the customer a new card as quickly as possible so he can keep using our products.”
Each of these people has described a case type — that is, each has described a complex piece of work that has a mean-ingful business outcome. In this case, completing the cus-tomer’s outcome (“fix my lost wallet”) depends on completing the other outcomes as well. In this example, you’d call the customer goal (“fix my lost wallet”) the parent case. The other cases are children, subordinate to the parent.
The children of one parent case can also be parents to other child cases. This relationship between parent and child cases is often called the case hierarchy (see Figure 3-1).
Source Pegasystems.
Figure 3-1: Parents and children in a case hierarchy.
Don’t confuse child cases with tasks. Tasks are individual steps completed by a person, often in a single sitting. Cases — even child cases — aggregate multiple tasks to deliver a meaningful business outcome.
Managing complexity
Defining parent and child cases allows different parts of a busi-ness to manage the work they need to manage while still deliver-ing a cohesive experience. Child cases, especially at the bottom of the case hierarchy, often align with the needs of individual departments or teams within an organization. Top-level parent cases often reflect the customer-facing goals. In the example in the preceding section, the customer can monitor and manage the status of his lost-wallet claim without being exposed to the organizational and regulatory complexity needed to address the other pieces of work that must be done.
Creating child cases is one of the ways in which DCM helps insulate your customer from the work silos in your organiza-tion. Organizations develop silos for a good reason: Silos allow a company to manage functional areas and align employees who are working on related tasks. This approach becomes a problem, however, when a large organization with multiple business lines and work silos tries to deliver a cohesive customer experience. Employees struggle to navigate silos, often dealing with multiple systems and applications. Worse,
Chapter 3: Organizing Your Work for DCM 35
customers end up feeling like pinballs, bouncing between silos (“Let me transfer you to. . .”) without ever getting clear answers to their questions.
Organizing cases into parents and children allows you to address the needs of your customers — represented by the parent cases — while insulating them from the complexities of your organizational silos, which can be managed by the child cases.
In the lost-wallet example, the complexity of the work to be done isn’t going away. Government regulations and rules issued by the credit card companies themselves require organiza-tions to follow certain processes, obtain certain documents, and meet certain deadlines. The beauty of using DCM, with its parent/child case relationships, is that you can manage those requirements by having child cases that reflect your organi-zation’s internal outcomes. Rolling those child cases up to a parent allows you to manage your customers’ needs and expec-tations as well.
Working in parallel
Parent and child case relationships also make parallel work easy to manage. In the lost-wallet example, the parent case (“fix my lost wallet”) may spin off multiple child cases. Each of those child cases — transaction payments, fraud investiga-tion, and so on — can be processed in parallel, with the parent case managing the relationships among the child cases.
Adding children to a parent
Part of the definition of a case type includes the definition of the child cases it could contain. If a case type can contain child cases, it becomes a parent to those cases. Additionally, the case type should define when (and whether) that child case should be attached to the parent. Some child cases are created automatically at the start of the parent case or when the parent case crosses a particular milestone. Other child cases are defined as optional and are added to the parent only under specific conditions or when requested by a stakeholder or user.
Breaking Cases into Work Stages
When case types are defined and parent/child relationships are assembled into the case hierarchy, the next step is defin-ing how work in each case type is to be completed. You begin by defining the stages that outline the journey from starting a piece of work to completing it. Stages represent the high-level flow a case goes through.
Stages aren’t child cases; they don’t represent meaningful business outcomes on their own. Stages aren’t tasks, either, because they aren’t individual steps. If you’ve ever drawn a series of steps on a whiteboard, you’ve probably defined a series of stages.
Using stages to define the high-level flow of a case can be a lot easier than defining the detailed steps that make up a business process. It’s easier to get stakeholders to agree on stages than to get them to agree on low-level steps, which have levels of detail and variation that are challenging to capture. For this reason, capturing case stages is a great way to start defining your DCM application.
Meaningful stages
Define stages in such a way that their meaning is apparent to all stakeholders in the case, including the customer. Stages become the way that participants in a DCM solution communi-cate about the status of the cases they’re managing.
A great example of meaningful stages is the Domino’s Pizza online ordering system, called the Domino’s Tracker. When you order a pizza from Domino’s online, the Domino’s Tracker graphically displays the stages your order is going through:
Order Placed, Prep, Bake, Quality Check, and Out for Delivery.
A customer can watch her pizza progress through these stages in real time. Because the stages are easily understand-able, the customer knows exactly where the store is in its progress on the work. Domino’s employees and managers can use the stages to track bottlenecks or areas for efficiency improvement.
Chapter 3: Organizing Your Work for DCM 37 Milestones as markers
The markers between stages are called milestones. Milestones are the gates that a case must pass through to move from stage to stage. Defining the milestones at the beginning or end of each stage is essential to tracking and monitoring to the progress of work in your DCM application.
Tasks and processes
After you define your stages, you begin to fill in the work to be done. That work most often takes the form of tasks and processes. Tasks are individual steps in the case, completed by a single person, often in a single sitting. For example, a task in making a pizza might be “Add Toppings.” If your stage con-sists of nothing but manual tasks, or if the tasks in your stage can be performed in any order, defining the stage as a set of tasks is generally sufficient.
If you need to string a series of tasks together in a specific order, or if you want to include automated steps or decisions in your stage, it is useful to define a process. A process is a set of tasks, activities, material, and/or information flow. Often, DCM tools will let you use graphical process models to define a set of steps, and then associate those processes with indi-vidual stages. This allows you to keep process models concise and manageable, while using the stages of the case to overall view into the end-to-end work.
Service levels and deadlines
Each stage should also have service levels associated with it.
Service levels define the time frame in which stages should be completed and are often expressed in the form of a goal (when you want to have this stage completed by) or a dead-line (when you need to have this stage completed by). Some DCM applications define both a Goal and a Deadline stage for each service, increasing the level of escalation as each goal or deadline is met.
Service levels are usually defined in either of two ways:
✓ Based on an explicit date: In a case type for processing a mortgage application, for example, a closing date is usually defined. Each stage of the mortgage application has a service level that’s defined relative to the desired closing date.
✓ Based on a number of days from the start of each stage:
A customer service case may demand that the Fulfillment stage be completed within three days of starting the stage, for example.
Define service levels not just for each stage, but for the over-all case type as well. Make sure that the service levels for the stages (or even for individual tasks and processes, if you have them) roll up into the overall case-type service levels.
Service levels should also define actions. When the goal or deadline for a service level is crossed, the case and its tasks should be escalated. Escalation could take the form of increasing the urgency of the case so that tasks float to the top of users’ work lists. It may also include triggering esca-lation actions such as sending an email or text, or transfer-ring the case to a supervisor.
Alternative stages
Cases usually flow linearly from one stage to the next. In the pizza example (see “Meaningful stages” earlier in this chap-ter), a pizza goes from Order Placed to Prep to Bake. But what if the customer calls in to cancel the order? At this point, the case needs to drop out of the normal flow of stages and into an alternative stage called Canceled.
Alternative stages handle exceptions or alternative paths in case processing. Tasks responsible for cleaning up from Canceled or Restarted processes often live within the alternative stages of a case. In the pizza example, a canceled order may require recall of the driver and collection of the uneaten pizza for donation to a food bank. The alternative stage called Canceled would con-tain this work.
Chapter 3: Organizing Your Work for DCM 39 Resolution: The final stage
The last stage of every case type is Resolution, which repre-sents the completion of a piece of work. Most cases get to the Resolution stage and stay there indefinitely. At this point, the case, its data, and its processing history become vital pieces of information for reporting on and improving your business.
Some cases are reopened when stakeholders demand review or reprocessing. A pizza case may be resolved when the order is completed, but if a customer calls back to complain about the order, the pizza case — and all the data collected for it — can be reopened to process the complaint. When a case is reopened, it can drop into an alternative series of stages (see the preceding section) or go back to an earlier stage for reprocessing.
Looking at resolved pieces of work is a great way to under-stand the stages and the data of your cases. Because resolved work has already passed through all the stages, you can find evidence of the stages in the resolved work and use that evi-dence to define the stages for your case type.
Thinking about Reuse
As you define the case types, parent/child relationships, and case stages of your DCM application, keep reuse in mind. You may eventually expand your DCM solution beyond its initial project to other pieces of work, so you want to find ways to reuse the case types and stages you’ve already defined.
Reuse is important for two reasons:
✓ It delivers improved time to market. If you’ve already defined a case type that you can reuse in multiple places, reusing that case type means you don’t have to rebuild it a second time (or a third or fourth time).
✓ It provides consistency. Your organization’s legal depart-ment may have a way of handling fraud investigations that it wants every department and line of business to conform to. Creating a reusable case type called Fraud and defining that case type as a child case with many
parents (Account Opening, Claims, and so on) ensures that all groups in your organization follow the same best practices for investigating fraud.
You reuse much more than just your case types and stages, of course. In fact, as you think about your DCM solution, you find many opportunities for reuse, especially when you think about the tasks and processes that define how a piece of work is to be completed.
Chapter 4
Get ting Case Work Done
In This Chapter
▶ Understanding automation
▶ Managing cases and their data
▶ Automating cases with business processes
▶ Using analytics and reporting to guide and track cases
C
hapter 3 shows how case types are defined and how stages and milestones are identified. In this chapter, you see how to focus on the core purpose of dynamic case man-agement (DCM): getting work done.Seeing the Power of Automation
DCM is unique in that it focuses on all three ways in which software enables work to be improved:
✓ Automating what can be automated
✓ Guiding users when automation isn’t possible
✓ Tracking work that’s too unpredictable to guide or automate
Automating work is powerful. Eliminating manual work has delivered efficiency benefits and improved worker productiv-ity by a factor of four since the 1950s, according to the U.S.
Bureau of Labor Statistics. But many types of work can’t be fully automated: The work may be too unpredictable or may require a degree of human judgment. In such cases, you can guide the users who perform the work toward a goal while ensuring adherence to best practices that meaningfully affect throughput and consistency.
Most organizations — especially large, complex organizations — don’t have enough insight into many work processes to consider automating them end to end. Process visibility must precede automation, and there’s real business value in providing that vis-ibility. If you can obtain visibility into which stages take the most effort or have the most negative effect on customers, you gain the insight you need to focus your improvement efforts. To get that insight, you need to start with the data.
Don’t think about automating everything. Strive to gain vis-ibility into the overall case while automating key process hot spots. This approach delivers significant benefits.
Getting the Data Right
To use DCM to bring a case to resolution, you must give the system and its users the right information. This information — the case data — includes everything from a customer’s email address to an account balance to a transaction amount. Case data also contains metadata, which is the information recorded by the DCM system as it tracks the progress the case makes as it performs work (see Figure 4-1). This metadata includes infor-mation like case IDs, status inforinfor-mation, and audit history.
Source Pegasystems.
Figure 4-1: Data associated with a case.