About oranges, an apple and lean

Last week there was a discussion going on Twitter about case management; what it is and how it relates to BPM. You can read a summary in @andrewonedegree’s blog. Not much later, Forrester analyst @cmooreforrester tweeted about the difference between flow in lean and flow in BPM. The first is good. (For background information on flow in lean, look for example here). The second is bad from a lean perspective, because it chunks or segments the work, thereby hindering flow. This made me realize that Pallas’ BPM solution, often referred to as case management, allows for better flow and would therefore qualify as a lean form of BPM.

However, as Andrew’s blog shows, there is a lot of confusion on what case management is. I am guilty of the confusion as well, because I know very well that Pallas’ tools are referred to as case handling tools. Because most people don’t know what you are talking about when you mention case handling, I usually use case management instead. WRONG! I should have known better and used the right terminology all along. All this time I was trying to make apples to be oranges, thereby comparing apples and oranges… Definitely time to set things straight and provide some background info, so I can also explain why case handling is a lean form of BPM…

First, let’s look where the term case handling came from. I think (I am not 100% sure, so please correct me if I’m wrong) it was first used in a paper written in 2001 titled Beyond workflow management: product-driven case handling by Van der Aalst and Berens. It describes a new concept, which was implemented by Pallas in a product called FLOWer. I don’t want to give you a full company history or toot the company’s horn, but I do have to give some background information to be able to explain my point. So please be patient…

So you are wondering what makes case handling so unique? Well, the big difference is that case handling is data-driven. Please think about that for a second. Data-driven. That means that, unlike “traditional workflow”, where work is routed from one person to the next, work depends on what information is required and what information is available (read entered into the system). The comparison between workflow and case handling looks as follows:

	Workflow management	Case handling
Focus	Work-item	Whole case
Primary driver	Control flow	Case data
Separation of case data and process control	Yes	No
Separation of authorization and distribution	No	Yes
Types of roles associated with tasks	Execute	Execute, Skip, Redo

Again, I don’t know the true source of this table, but it is used in this paper by Van der Aalst, Weske and Grünbauer. Of course it would be even better if there were another column named case management added to the table above. I think that would clarify the case management vs. BPM discussion, although I don’t think the rows in the table above would be sufficient, as case management -in my opinion- tends to be low on process and more about case status. To be honest, I wouldn’t be able to fill that column, because the only case management solution I know is really a case handling solution…

As you can see in the table above, case handling is more than case management on process steroids. There are other discriminating factors that make case handling stand out. I think the separation of case data and process control is self-explanatory as  I have already mentioned that case handling is data-driven. The separation of authorization and distribution is a very powerful concept that provides enormous flexibility to administrators of a case handling system. On the flip-side, it tends to be a little more difficult to get your head around the set-up of such a system. Last but not least, case handling provides the execute, skip and redo roles as opposed to just the execute role. These three roles combined with the possibility to make them dependent on the roles of the users makes for a flexible authorization mechanism, that lets users do the things they need to do to get their work done (which isn’t always the happy flow…).

At this point I assume you have some basic understanding of what case handling is. I’d like to go back to my statement in the first paragraph, linking case handling to Lean. As you know, Lean is all about Flow. Where traditional workflow breaks up the flow and routes the work from user to user, case handling enables you to let the user enter as much information as is available, thereby improving flow. I italicised enables, because you have the option to let users enter more information in a process step than strictly required to fulfill that particular step. So if more information is available and the system has been set-up to allow for this, the user can just enter the additional information. Of course you can still have authorization steps that break up the flow, but if the user with the authorization role pulls the cases from the queue, the effect can be minimised. I guess what I am trying to say is, that with some smart designing, the negative effects on the flow can be minimized. I am trying to figure out what a totally Lean process would look like, but I think it would be a process not worth automating. So my guess is that case handling is as lean as you can get in BPM…

Case handling is not some newfangled thing. It has been around for years and there are literally thousands and thousands of users who use these tools every day. They tend to fall in the category of knowledge-workers, but I don’t want to start another discussion on the definition of those… Because case handling allows for flexible authorization of when what data can be entered, it helps the flow of the system. Therefore my statement: Case handling is a form of Lean BPM… Please let the discussion continue on Twitter, but hopefully within a clearer context of definitions. Don’t you just love a juicy apple?

Advertisement