There's an episode of "The Simpsons" called "The Spin-Off Showcase" that features fictional spin-offs starring characters including Chief Wiggum, Seymour Skinner and Moe Szyslak. Springfield Elementary school bus driver Otto Mann didn't get his own spin-off but probably should have, given that lovable losers are such a sitcom staple.
After all, as I just discovered after reading a post by Adam Deane on his Business Process and Workflow blog, Otto can even be used to explain adaptive case management (ACM), a concept I know from experience can be somewhat nebulous.
Deane, head of BPM at software and consulting company Casewise, uses Otto to make the point that ACM's lack of structure and reliance on ad hoc processes can create problems. As Deane tells it, Otto loses his way but decides to stick with ACM instead of using business process management because "there's no such thing as wrong in ACM." As Otto says: "We just take longer. We don't fix bottlenecks. We just go around them."
Deane's post prompted a response by Max Pucher, chief architect of ISIS Papyrus Software, who uses Otto to make his own point, that BPM isn't as effective as ACM because it doesn't adequately allow for exceptions and puts process control in the hands of someone who creates a workflow despite having little if any real-world experience with it.
So OK, neither BPM nor ACM are without potential problems. But they can also both be effective approaches to process improvement. That got me thinking: Given that some workflows are a mix of structured, highly repeatable (and thus easily automated) processes and more ad-hoc ones, are BPM and ACM always mutually exclusive?
Perhaps not, based on a comment left by Greg Carter, CTO and EVP of product development for BPM software provider Metastorm, as part of an eBIzQ discussion over what type of event calls for ACM vs. BPM. "The same event may trigger a highly structured BPM process or a more dynamic and iterative case management process," says Carter, offering the example of an automobile manufacturer and Metastorm client that uses an enterprise resource planning (ERP), enterprise content management (ECM) and BPM to manage the reconciliation and payment of its supplier invoices.
As Carter writes, most of these invoices are generated from highly structured procurement processes with invoices easily matched to purchase orders. Business rules are automatically applied, discounts for prompt payment are calculated and settlement occurs. Often, the entire process is automated. But some 10 percent of invoices lack needed information, so they are scanned, coded and stored in an ECM system. This creates a case, complete with the invoice and any supporting material. Clerks must use search tools and organizational information to match the invoice to the facility that placed the order. Writes Carter:
The case may pass through many hands, picking up information along the way. At some point the process will declare victory, complete the purchase order match, and the invoice will be settled using the payment portion of the process. Both scenarios are handled by the same process and the same technologies-BPM, ECM, and ERP. In this example, using process analysis of the cases that were not automatically handled, the customer is combining dynamic cases, discovering patterns, and using this information to expand the automated process to handle more and more exceptions.
This idea seems to be reinforced in another eBizQ discussion over whether case management will replace BPM. Sandy Kemsley, an independent BPM analyst and blogger, suggests most organizations will require both BPM and ACM capabilities to deal with a wide variety of processes. She writes:
... At one [end] of the spectrum are highly-structured processes, such as regulatory and compliance processes; at the other end is completely ad hoc, such as innovation management. In between, however, you find all flavors of the rainbow: ad hoc with some structured process snippets (e.g., insurance claims processes, where some of the functions that a work may select to include on a case are actually predefined subprocesses that have to be executed in a specific way for regulatory reasons), and structured with ad hoc pieces for exception management (e.g., financial services transaction processing). ...
Emily Burns, from BPM software provider Pegasystems, raises what I think is an important point in the discussion, urging organizations not to take an either/or approach to BPM and case management. She writes:
... most organizations and people want to move their unstructured work further down the spectrum towards greater structure. This is because after you do something once you have identified some best practices for how to handle that type of event in the future, whether that is content generated, a process here or there, what the overall breakdown of the work is, who is best equipped to handle what, etc. Taking a binary view of case and process doesn't allow you to migrate work from one end of the spectrum to the other, just as it doesn't allow you to handle work from across the spectrum. ...