Process for the Enterprise » Keith Swenson

Will ACM eclipse BPM?

Scott Francis — Tue, 10 Jan 2012 22:50:10 +0000

Peter Schooff once again asks the provocative question: “Will case management eclipse BPM in importance this year?”

The answers were pretty interesting. I guess I should first own up to my own:

Short answer : no.

More thoughtful answer : When people have trouble listing which products are ACM, and which are BPM, and which are both, the “ACM” tag has some work to do to eclipse BPM. Even as it grows, it is perceived as part of BPM, not separate.

Of course, BPM took a decade or more to come into its own. I don’t think it comes undone overnight.

Perhaps some take this as tongue-in-cheek, but I’m serious. The market perceives ACM as a part of BPM. So do I. Even as case management gains traction in some sectors, the customers are reaching out to BPM vendors to solve those problems. Because case management is a good fit for BPM as well.

Keith Swenson posits that BPM is just “tactical” and ACM is “strategic” – in the long run BPM will automate all of the routine processes and ACM will increase in importance as work inevitably shifts there.

First, I don’t see anything inevitable about it. Second, my response to this argument: “There will always be new, evolving processes (even “routine” processes). Enhanced productivity just means that less valuable routine processes can also be addressed (lower I to get the lower R).” But of course the other part of the argument is that word-choice is so important. The word routine might merely imply “repeatable”. But the word choice implies other judgments as well: routine sounds less valuable, less interesting, less problematic, less valuable. In fact it is none of those. These routine processes are what allow large companies to function at scale. The really large scale routine processes aren’t even handled by BPM, they’re handled by specialized software for those functions, because they are so valuable.

So don’t let the use of the adjective “routine” fool you. The routine processes are typically where the money is.

Christopher Taylor sums it up well at the bottom of the thread: “I predict that it [ACM] is like the lone rider out in front in the Tour de France… it causes the peloton to speed up and take the breakaway back into the pack.”

Still, good perspectives to think through on this thread, from all corners.

Fill in the White Space, and Inverting the Process Life Cycle

Scott Francis — Tue, 13 Dec 2011 04:43:13 +0000

It isn’t easy to fill in the white space. It is harder to design a good software solution from scratch than to fix a bug in an otherwise working solution, or to design a small addition to a working piece of software. What if you could have tools that just help you right away, and then later infer the process (filling in the white space for you)? That’s the promise of “process mining”.

Along those lines, Dave Brakoniecki tackles the idea of “inverting the process life cycle“, in response to a post by Keith Swenson on the subject:

Imagine a patient file or case. This is a favorite example in the ACM space since the expertise of the doctor defines the process or work to be completed. How useful to the doctor is a case management tool that has no information on the patient and no ability to schedule tests? Not very – all of the work would need to be done outside the tool and duplicated in the tool. Still, building integrations to the patient records and to the systems that organize blood work, for example, would be better done at design time than run time.

Even if this was possible at runtime, few doctors would be interested in doing it.

(incidentally, I think this is why something like IBM Watson is getting good airplay in medical / healthcare circles. It has data and context on a subject domain)

So, a lack of preloaded or pre-integrated data seems like a problem. But supposing you have this pre-existing data, there are a small number of firms prepared to help you discover the processes you are already executing without realizing it. It isn’t yet clear to me how big these services projects are (there aren’t any shrink-wrap solutions that require no services).

And Dave points out another issue:

In most organizations, what is problem with their Sharepoint deployment, their Lotus Notes application or that little Access database application they wrote three years ago? In almost all these cases, the problem is the same. End users were given a powerful and flexible tool without training and ending up building a system that is impossible to maintain but essential to the business.

I have seen many successful projects start from this position: The end users actually asking for more help in managing the technology so they can spend more time doing their jobs.

This is summarized nicely as “the Sharepoint Effect” in a previous post on this blog. And I agree with Dave – many projects start exactly this way.

Then Dave gets into what might be an example of ACM in the wild – Basecamp. Although it doesn’t bill itself as an ACM tool, one could argue that it is one, by accident. In which case:

Perhaps the most important reason for the ACM camp to try and adopt a solution like Basecamp is that it would give them immediate mainstream legitimacy with tangible customers who have already inverted the process life cycle and will do it again next week. It probably also indicates the delivery model and price point required to disrupt the markets they are targeting.

I’m not sure the ACM vendors are prepared to be at those price points, however.

Keith makes some interesting points in his original post, not all of which are argued by Dave. Certainly measurement before improving is A Good Thing. We’ve been implementing “shadow processes” and listening to processes implemented in other systems for years, and using that data to inform our new process models. But because we’re listening to real systems, we have to implement the broadcast or listening of those interesting transitions in the systems of record.

In short, there’s no magic bullet. But you can certainly do better by measuring twice and cutting once, as they say. But we can do better than that. We can measure any number of times, and we can get more than one “cut” at the new and improved process by leveraging A/B testing to determine what actually produces the best results.

Lamenting Definitions

Scott Francis — Tue, 15 Nov 2011 06:02:17 +0000

In a flurry of posts recently there’s another attempt to sever ACM and BPM. It’s a strange urgency among some ACM advocates to separate it from the idea of managing business processes.

Keith misinterpreted my recent post on ACM/BPM – confusing product efforts by software vendors with implementation and execution efforts by business users. Bruce Silver and I are speculating about whether “ACM” will really exist as a distinct market from BPM – and we both doubt it. Keith is questioning whether doctors and lawyers should use BPMN. A bit unrelated.

In another post, Keith attempts to put the wheels back on the track. But Adaptive Process advocate Max J. Pucher notes that he sees a benefit to customers in a holistic solution – and goes on to advocate his own company’s approach:

Therefore I do not see a clear distinction between ACM and BPM, except that a BPMS cannot perform the kind of ACM user-driven processes that you describe so well. My recommendation of a homogenous system that does both really well is not only driven by my product orientation. Remember? I don’t have to sell what I have – I develop what empowers people!

I see it the opposite way: The only reason people have to keep ACM and BPM as independent functions are sales perspectives or BPM design or consulting skills that might become obsolete. From a business benefit perspective, a homogenous solution that also encompasses architecture, content and rules is the only thing that makes sense. Agree? Whether this is easy to sell or argument from an existing BPM mindset is a completely different story.

If it is a single solution, it really doesn’t matter if ACM and BPM are separate or the same. It just matters whether you can solve the problem for the customer – or not. Or if the customer can solve the problem for themselves – or not. I believe Max’s firm is in competition (in a sense) with BPM vendors – because they’re both competing for a market around improving business processes. Max’s competitive differentiators are related to the adaptive way his firm approaches this subject. A company like IBM will pitch different differentiators for their product offering. They may coexist in the market or within customers, or they may compete. But so far this looks like one market to me. I might have more faith in BPMS based on my personal experience, than Max does – but in the wide angle view I see more agreement than disagreement in terms of what BPM is (versus what a particular product can deliver).

Jacob Ukelson proposes to call this area “knowledge process” instead of ACM. I expressed a bit of my frustration with this distinction, though I generally sympathize with his frustration as well! -

As I mentioned on twitter, I don’t think the problem is that they got in the weeds on features. The problem is that ACM folks got too caught up in trying to prove that BPMS can’t do ACM – which is silly. Or worse, that ACM was superior/above/better-than BPM – which again, is just a silly argument to get into. Like arguing that BPM is better than SOA – they’re either complementary or competitive and if they’re not competitive than better doesn’t really have meaning.

Knowledge work is business work, last I checked. business people describe knowledge work as being part of their business processes. Fighting a definition battle that isn’t worth fighting. Go ahead and convince customers that they don’t have a sales process. That it is, instead, a sales knowledge process or a sales case management. Or that they shouldn’t apply process improvement techniques to aggregate outcomes.[...]

I keep hearing from people about what isn’t the answer… but not hearing much about what is unless it is a plug for “read the book” or very high level – as you say – principles – which of course could just mean “use email”.

I think the ACM discussion has been useful in that it reminds people that BPM shouldn’t be just about automation and eliminating human work. But to me, separating ACM from BPM is a bit like saying that what’s good for the goose isn’t good for the gander- that some work (usually whatever work we envision ourselves doing) isn’t subject to the same general rules as the work others are doing. My work is creative, but their work is not. My work is knowledge work but their work is routine.

I promise you, all work that involves people involves creativity, passion, skill, energy, pride – or the lack thereof. Our goal should be to reduce the mundane and routine, and allow the people to focus on the creative and expressive and decisive. We could argue over ACM vs. BPM or just agree that BPM and ACM are two slices of bread in the same loaf.

Just because I don’t use a BPMS to tie my shoes doesn’t make it knowledge work. Nor does it mean it isn’t a process.

Keith Swenson’s Notes from Forrester BPM Forum

Scott Francis — Wed, 28 Sep 2011 16:00:48 +0000

Keith has posted a summary of his notes from Forrester’s BPM Forum – great read and good insights into several topics – in particular he has a great writeup of Derek Miers’ session on designing your BPM engagement program around the customer experience:

He draws a correlation between process maturity and focus on customer experience. Maturity level 1-2 cost reduction is the top category (74%). Level 2-3 customer experience is the biggest. levels 3-4 and 4-5 customer experience remains high but value innovation becomes most important. Waste elimination remains that the same levels at all levels. The “ah-ha” moment was that if at level 2-3 you don’t focus on customer experience improvement, you will never get to level 3-5. (Survey is mostly business people, not IT – Forrester/QPC business process maturity survey)

Looks like a great day of sessions, but I agree with Keith that 7:30am is inhumane in any timezone.

Interesting Read on Self-Organizing (Business) Networks

Scott Francis — Mon, 19 Sep 2011 22:17:17 +0000

Keith Swenson just put out an interesting blog post on Self-Organizing Business Networks- there’s a focus on what makes for enterprise social software, and what the “social” part really means. But this particular bit caught my attention:

Most current systems are built in such a way that they require a technically knowledgeable person to make these reconfigurations. I am NOT suggesting that we simply open these capabilities up to business users. Instead, I am suggesting that the system should be built from the very beginning to allow this kind of change; so these changes are safe for users to do. It needs to be easy as well. A system that requires coordinated changes in multiple places (such as adding a network user, and adding them to access control) is going to be difficult and error prone.

Directionally this is right – it isn’t about exposing business to the complexities of IT administration, it is about writing software, apps, or mediums that don’t require such technical reconfigurations.

Count me in for Simplicity

Scott Francis — Tue, 13 Sep 2011 03:06:33 +0000

There’s an argument that says the world is too complex for humans to understand. Further, that by thinking we understand cause-and-effect, we’re doomed to act in ways that have unforeseen (usually negative) consequences. It is a really interesting debate, and informative on the more than two sides represented.

Personally, I found myself rejecting this notion as useful. Not that the notion of complexity isn’t useful – but letting it paralyze you is not useful. When it comes to running your business, simplicity is more powerful than complexity. A combination of relatively simple interactions has more power than a complex single interaction. Simple interactions are more replicable, more scalable. I would focus more on enabling “emergence” than disabling decision-making by leaders.

Simplicity and abstraction go hand-in-hand. The iPad has a significant amount of complexity baked in – from the hardware, to the software, to the production processes that lead to its creation, to the design processes that lead to its conception. But to me, it is just a glossy glass enclosure that responds to my touch.

Does my touch cause the apps to do what they do? Actually, it doesn’t matter whether touch is causal or not – it is, at minimum, so highly correlated between action and reaction that it feels like causation.

And that’s what we should be striving for in our businesses – that our actions would achieve the results we’re looking for – will feel like causation – though there may be a complex choreography and it may not be driven top-down.

There was a truly fantastic quote in the original HBR article:

“If you want to build a ship, don’t drum up people together to collect wood and
don’t assign them tasks and work, but rather teach them to long for the endless
immensity of the sea.”

- Antoine de Saint-Exupéry

Sometimes simple is best.

BPM Could Save Your Life

Scott Francis — Wed, 06 Jul 2011 04:13:05 +0000

Not that long ago, one of the prime examples given by Keith Swenson in support of the “ACM approach” was a medical example (picture Dr. House examining the really-out-there cases) – check out the comment stream from this post for background. Jacob Ukelson and I, not long after, proposed a way to think about ACM and BPM approaches in a complementary fashion – where ACM is concerned about an individual case, whereas BPM is concerned about the aggregate of all “cases” or processes. I used Keith’s medical analogy to make my point.

From twitter (thanks @elliotloh), I ran across this PBS story on a Denver Hospital that fairly well proves my point with respect to hospitals. There’s video, but I’ve quoted a few passages below. First, what was the outcome of this focus on aggregate quality of care?

DR. PATRICIA GABOW, Denver Health and Hospital Authority: What that translated to at Denver Health last year is that 213 people walked out of here alive who would have been expected to die. So, that makes the statistic into a very personal aspect for people who, in fact, lives were saved.

Think about that – 213 people alive today that statistically, would have passed away at the average hospital. And they’re not cherry-picking the patients and doctors, as the following passage demonstrates:

DR. DONALD BERWICK, Center for Medicare and Medicaid Services: They are getting levels of performance that most of the rest of us in health care can only envy. The vast majority of their patients are either uninsured or Medicaid patients. They deal with a very, very stressed population. And they are proving that that kind of care isn’t just kind of good enough. It can be the best care — actually, the best care in the country. They are showing the rest of us what’s possible.

But was this process improvement effort really goal-driven? (emphasis added in italics):

BETTY ANN BOWSER: One of Berwick’s chief goals is to reduce hospital-acquired infections in the next two years.

Was this really anything at all like a BPM project? Well sure it was, absent the BPMS software (emphasis added):

BETTY ANN BOWSER: CEO Gabow wanted a cultural change, so she brought in a team of efficiency experts from the business world and asked how they solve problems.

Out of that grew adoption of the Toyota automobile production system’s Lean principles, to eliminate waste, fix problems, and promote constant improvement.

WOMAN: So, as a group, we’re going to process-map it. We’re going to identify your waste. We’re going to pick part those defects.

It sounds pretty familiar, doesn’t it? And they looked at process times, steps, measurement, alerting - not the checklists a doctor might operate from, or a nurse, but the systemic approach to the overall care-giving processes:

SELEEM CHOUDHURY, Denver Health: People come in and they are sick. And when they are sick, we need to see them as soon as they arrive upon — you know, upon arrival.

And so we had to reexamine our process. We got Post-it notes — we put them on the wall — from every single aspect, from walking through the door, to seeing the nurse, to going through registration. And we had up to maybe two hours’ wait to be seen for that process. And just by making some simple changes, we cut that wait time by half.

(It does pain me a bit to see that they had to resort to post-it notes rather than software…)

But what is driving this change? A change to Medicare payments – tying them to efficacy and safety rather than just performing a service. This is going to force hospitals to re-examine how they provide care and think about how to serve patients more effectively. Of course, we can bemoan the fact that it takes a financial incentive to drive this change in quality of care, but maybe we should take improvement at face value, whatever the driving force behind it.

Another take on ACM: Feature or Paradigm

Scott Francis — Thu, 27 Jan 2011 17:16:53 +0000

I missed this post from Keith Swenson the other day, as he responds to Anatoly’s post on ACM.

Keith cuts to the chase:

Anatoly Belychook asks the question: “is ACM a Paradigm or a Feature?” I could not resist responding because I like the post, and his logic is flawless, but it is based on false assumptions. I think there is a lesson here on why so many BPM experts feel the way he does.

First, his summary of Adaptive Case Management (ACM) is one of the best I have seen. There is no doubt that Anatoly understand the motivations behind ACM.

What he does next is quite surprising; he analyzes whether ACM meets certain requirements of BPM. That is the flaw in his thinking: there is no reason to believe that ACM should meet the requirements of BPM. Many BPM experts start with an assumption that ACM should have BPM-like features, and then move on to conclude that ACM is really just a type of BPM. Those wanting to understand the subject should be wary.

Hm. I would have phrased this differently- it isn’t that Anatoly’s assumptions are wrong – its just that the exercise Anatoly takes on is looking at how to satisfy BPM-style problems with ACM-style claimed feature-sets. Anatoly would state it differently: How to satisfy enterprise level problems his customers are asking him to address, with ACM-style claimed feature-sets. And, to consider whether you can solve enterprise style case management problems without paying attention to key issues of architecture, data entities, process architecture, etc.

The comments section reveal a very interesting discussion between Keith and Anatoly – well worth reading (thankfully BPM and ACM posts do not get cluttered with 100′s of comments like tech crunch articles!).

In one of his comments, Keith wraps with:

Hopefully this clarifies my point: while ACM capabilities may be a feature of a BPMS, ACM in general is not JUST a feature of a BPMS. To say the latter would be misleading.

Given that ACM describes an “approach” rather than a technology, of course this is true. Likewise, BPM capabilities are not just a feature of a BPMS… I’d consider this a tautology. I think what Anatoly was exploring is whether ACM software will survive as a standalone / separate market, or whether it will be collapsed with BPM software as a market. (Thus, feature vs. paradigm)

I might be projecting my own impressions onto his writing, however.

Interesting conclusions in Keith’s post, first this bit:

BPM needs process architecture, ACM has no such need

In BPM the person who designs the process needs to be a data architect, but in ACM these are different roles. The person who designes the “process” does not need to be a data architect.

BPM needs strong capabilities for integration, but in ACM there is little or no need for field-level integration. ACM can work well with documents, reports, and links to other application user interface.

And Keith asks: isn’t this enough to make it different? Well, in technical terms, no. But in terms of “approach”, yes. You can implement (and I have implemented) processes that required no “architecture”, “data architecture”, nor “integration”. Typically those aren’t the kinds of processes people pay consultants to help them develop however, so I haven’t worked on that many of them. But it is definitely a different approach to start with the assumption that you won’t do these things.

Keith wraps with:

BPM systems will gain ACM-like features, but few doctors, policemen, and lawyers will use that.

Social Business Software like Jive, SharePoint, Quad, Chatter, and Connections will gain ACM-like features as well, and will be far more successful than the BPM systems, because those are systems that the doctors, policemen, and lawyers will use.

How funny. I end up agreeing it is a feature of something, just not a feature of BPM. :-)

I, too, find it ironic that Keith finally agrees ACM is a feature of something else (from a technical perspective)! I think, by extension, ACM can be considered a (potential) feature of BPM. And Keith may be right- that doctors, policemen, and lawyers will be using one of these other products (SharePoint? I doubt it) – but I wouldn’t jump to the conclusion that they won’t see BPM in their lives given all the government investment in process that’s happening.

Update: the discussion has moved to ebizQ now, thanks to Peter Schooff.

Process, Structure, and the Illusion of Hindsight vs. Foresight

Scott Francis — Thu, 20 Jan 2011 05:31:42 +0000

The argument over what a process is continues. As well, the argument over what is BPM and what is ACM. Two articles recently on the subject. First, Michael Poulin argues that all process is structured, and that ACM is not about process at all, but about managing the unknown or unexpected:

ACM is not about process management due to the absence of the process, it is rather about a management of consequences of unpredicted events, which itself is very important business task.

Well, look. It is an interesting attempt to define ACM – it just happens to be a different definition than all the other ACM thought leaders have been using as an operating model. Maybe the ACM folks will take up his definition – maybe not (I feel that, as someone not classified as a proponent, I shouldn’t be the one to define the term. Though I did suggest what I think ACM is about, vis-a-vis BPM, at one point… and at an earlier point).

Then Keith Swenson weighs in – and seems to largely agree with Michael’s discussion – I think for two reasons: first, it has a very narrow interpretation of process, and second, Michael provides justification for arguing that even well-understood processes may not be as well-understood as people think (and therefore perhaps they need to be re-examined as being ACM!):

He says “But, wait a minute, do we know what/why we do things? Do we really know the logic of our actions?” Truth is, we do thing[s], and then later rationalize why we did them. However, it is not clear that that rationale is in fact the cause of the actions.

So, now the argument seems to be that we’re just rationalizing a set of actions after the fact, rather than contemplating a plan in advance. The ability to see the structure and organization of what we do is a good thing – a key organizing attribute of businesses and people. Somehow Keith has made this sound like a deficiency instead of a beneficial attribute (it might not have been his intent, but that’s how it comes across). Being able to describe a complex interaction as, instead, a smaller set of high-level actions, is a huge benefit to humanity’s ability to understand the world. And the fact that BPM leverages that capability is hardly a deficiency, for example.

Moreover, Keith uses an art metaphor:

When an art student first attempts to draw an outdoor scene involving a tree, they commonly will start by drawing a line around the tree. That line does not exist in reality, but it is a construct of the mind which automatically classifying what you are seeing. The tree “looks” separate from the surrounding, because we understand that the tree is a separate entity from the mountain behind it. The art student must “unlearn” this habit of drawing in the borders between conceptual things. Such unlearning is not trivial.

There is a fair amount of “unlearning” when learning to draw (or paint). But there IS a process for sketching landscapes, versus sketching portraits. Growing up, I observed that my sister could take a picture of something and sketch a photo-realistic copy of the same thing scaled up or down in size (I thought that was quite amazing, being the little brother). It was hardly assigning method to the madness after the fact – she had a plan before pencil touched paper. There were even a standard bag of tricks for incorporating or correcting any mistakes.

Flexibility, Technical Debt, and Process Debt

Scott Francis — Fri, 03 Dec 2010 17:24:50 +0000

Keith Swenson’s article on the fallacy of flexibility makes a good case for lean software development and the Lean Startup:

This article is about software design, and makes the case that flexibility for flexibility sake should never be your goal. There is a very delicate balance between design and implementation in order to provide both usability and capability when it comes to software. Flexibility is often held up as a axiom, but flexibility should be provided only to the extend that it is actually needed by the end user.

I’d put it slightly different: flexibility should be provided to the extent that it is either less work, or actually providing value to the end user. In that order. If the absence of doing something yields flexibility, that’s good. But if you design your software to solve hypothetical situations that have yet to manifest, you run a real risk of overdesign (and over-engineering).

Keith goes on to document a set of rules to keep software simple and maintainable, including removing outdated functionality. You could sum these up as minimizing technical debt (or in BPM, process debt). The less debt you incur, the more maintainable (and less costly) your code base will be going forward. The more debt you retire, the better, generally speaking (but, there are trade-offs to retiring debt).

The key insight:

What I am trying to say here is that our normal intuition about the value of designing up front is wrong most of the time when it comes to software because it is not like a physical production process.

So true. Great read, I recommend anyone technical read the whole article. If you’re not technical, you might want to read it anyway – it will give you insight into how much the flexibility ideas of your technical staff are costing you.