From Transaction to Process to Case


Many applications, especially those built more than a few years ago, start with transactions. Update an address, post a payment, pay a claim. Transactions are immediate. They operate at a super-granular level and are reusable. But they aren’t very user-friendly. Somebody has to painstakingly paste these transactions together. Either the customer service agent swivels between a variety of systems, or a highly trained investigator maintains a paper folder of data, or—even worse—your customer bounces between channels, systems and contacts until they get the answer they need.


Tansactions are immediate but no business-friendly

Figure 1: Transactions are immediate but not business-friendly


Better applications stitch these transactions together by creating processes. Those of us who embraced business process management (BPM) several years ago thought we could orchestrate transactions and human tasks using simple diagrams. This would enable business people to understand what was happening, manage it and change it. Unfortunately, process models started to get too complicated. Once a process expands to contain the richness of the customer context and lifecycle, it becomes unwieldy and the business visibility disappears.


Processes Get Complex Quickly

Figure 2: Processes get complex quickly


In my experience with customers, I’ve found the best way to start a business application is by thinking about the “case.” The case captures work that needs to be done, and an outcome that needs to be delivered. It’s a powerful and adaptable concept. It can represent everything from an airplane taking off from Frankfurt and flying to Heathrow, to a diabetic being cared for by a major health plan, to a customer calling a credit card company to report a lost wallet.

When a businessperson starts explaining their needs, they don’t generally dive into process – they think in terms of what we call the “stages of a case.” We start our implementations by talking about cases and stages—rather than processes and transactions. This enables the business to define what the major steps are of how work gets done, essentially building the skeleton on which you hang the more detailed process. You establish a common language, a business view of the data, and a flexible structure before you start debating the details.


Processes Get Complex Quickly

Figure 3: Case stages work how business thinks


Rather than drawing an end-to-end process, “case-first” thinking lets you start at the level of abstraction, providing a level of context that doesn’t drag you into the guts of BPMN modeling. You can get all your key stakeholders—the users of the systems, the business analysts designing it, the developers building it—talking in the same language. This provides a collaborative canvas on which both business and IT can work together. Pega calls this approach “Case Lifecycle Management.”

The next time you start thinking about a business application, throw out your transaction diagrams and process models. Start your thinking with a case. We believe so strongly in this approach that we’ve written an eBook, Dynamic Case Management (DCM) For Dummies, to explain the concept of “case-first” thinking. Take a read, and feel free to leave your thoughts and questions in comments below.

Dynamic Case Management (DCM) brings together people and information to get work done. Download Dynamic Case Management For Dummies now to discover how DCM can digitally transform your business.