Neil Ward-Dutton of MWD Advisors is attempting to uncover for their customers the true differentation between BPM vendors.  This isn’t easy – partly because they can all hide behind a common modeling paradigm (BPMN, among others), and an expert in any one of them might be able to build a solution to a given business process problem.

But to actually deliver on the promise of re-use, agility, and scale, if the BPMS doesn’t support your efforts organizationally you will run into roadblocks that have consequences… We’ll get to those in a moment… Here’s Neil’s take:

Most of what I’ve heard in discussion around this point focuses primarily on implications for the time to deliver projects: in other words, don’t think that once you’ve created a BPM and model your even close to finished application for real-world deployment. However there is a bigger issue at stake here, which is: exactly what kind of provision a given BPM technology platform makes for the specification of those items in the list above – and specifically, to what degree you’re encouraged to design and (when necessary) code these items so that each kind of concern is kept separate from all the others.

The quality of this “separation of concerns” in design might not make a huge amount of difference when you first start in implementation, but it can become incredibly important over time. And support for it turns out to be one of the most important (to my mind) differentiating points between BPM technology platforms.

Neil has hit it exactly.  The separation of concerns seems like quibbling between different philosophical approaches at first – but it is more important than that.  But when the separation of concerns is poor, or when the support for agility is poor, what are the consequences?

• The level of product and technical expertise you need to maintain your solutions goes up.  You can’t easily integrate people who are new to BPM to your project, and even when you do they have to be incredibly skilled computer scientists.
• The level of specific knowledge required of your business (and your technical hacks) is too high to easily bring new people into the project.  Anything they touch may have unintended consequences – sometimes far reaching and affecting more than just the process they intended to affect.
• Fear of change.  If a small change can have broad negative consequences or unintended side-effects outside of the process we’re editing, we will fear changing it.  We lose agility.  We might abandon a common implementation in exchange for process-specific implementations – and therefore losing the benefits to efficiency that re-use provide.
• Testing overhead.  If a small change in one process or process area can affect a broad array of other processes, the testing overhead is quite high.  Essentially I have to re-test everything.

But these are just the tactical problems. The real problem is that your BPM team won’t achieve the business outcomes you’re looking for – the I in ROI will be more expensive, the time to market slower, and the R lower.  It can wipe out much of the promise of BPM in the first place.

You can see some of this differentiation when you hear pundits and gurus talk about how “rigid” BPMS’ are – this says more about the BPMS they’ve been using than it does about the notion of a BPMS.  Meanwhile, some of us are pretty happy with how flexible our BPMS is… draw your own conclusions.

Neil’s next point:

Of course, because almost all BPM technology platforms centre implementation work around a graphical process model there is always likely to be a clean separation between definition of process and all of the other important design elements I’ve listed. But whereas some platforms provide a rich, well structured asset repository and clean design tools that implement the principle of “a place for everything, and everything in its place”, other platforms really provide quite weak facilities of this kind. With this latter group of platforms, it’s still theoretically possible to create process applications that are relatively easy to maintain; but designers and developers are going to be pushing against the tools available rather than working with them.

Reading this, it reminds me how much hue and cry there was over a certain company with a BPM product, buying an upstart company with an allegedly overlapping BPM product…. There was real differentiation in the process repository and in the basic architecture of the design environment.  But it was the kind of differentiation that customers and analysts would often miss – because the value isn’t as apparent in iteration 1 of project 1 (although it is apparent if you do them side by side).  It becomes much more apparent in iterations 3 and 4, projects 5 and 6.  If you’ve owned a BPM product for more than a year and you’re still looking at getting process #1 deployed, I’d recommend two things:

1. See about getting some professional help from a boutique consultancy focused on project success.  If you’re already working with one, consider a new one.
2. If that doesn’t get you on the path to more productivity and better use of your product, consider a different BPM platform.  You might have picked the wrong one.

Meanwhile, keep an eye on MWD’s research and their attempts to delve into the real differentiation between BPM vendors, and don’t just get caught up in the bright shiny features they’ll parade in front of us.

Frank Michael Kraft’s post on Taylorism is interesting, in that it is a response to Jakob Freund’s post on the same subject, but with a different perspective, and a pretty balanced view.

Since I mostly agree with his post I’ll just focus on a few of my nitpicks:

“We cannot conclude that if a management style is good for physical production that it is good for brain work as well.”  We also can’t conclude that if a management style is good for physical production it is NOT good for brain work as well.  Or vice versa.  That requires more data and analysis than has been discussed on the blog posts linked above.

Kraft goes on to say that we should use “the right type of tool for the right type of work.”  To my mind, BPM has always been about that.  In my experience it includes mind maps, BPMN, BPEL, interaction diagrams, Failure Mode Effects Analysis, and other tools of the trade.  Not to mention the data analysis, simulation, optimization side of things.   Most of what I hear about ACM sounds like tools of the trade people have been using in BPM projects for quite some time (which is why, to me, they aren’t that differentiated).

He also has a nifty graphic:

And he’s right, when he makes the point that the arguments about BPM and ACM often sound like mutual exclusivity – only one can be right.  But I think the argument between these advocates is more along these lines:

• ACM proponents: ACM is different and separable from BPM as a method, and (less consensus) a tool set. Corollary: the language used often implies it is just better and more important than BPM.
• BPM proponents:  ACM is fine. But it is clearly one of the tools in your BPM tool belt, rather than its own distinct and separate market (tooling), and methodology.

It is easy to mistake the first group’s arguments as saying BPM doesn’t matter, or that ACM is “the only thing”.  Clearly it does matter, and the staunchest proponents of ACM will also say and write that.  It is easy to read the second group’s arguments as saying “BPM is the only thing.”  But the argument is a bit more subtle, it is just that BPM is the umbrella in these advocates minds.  Maybe this is consistent with “BPM is the only thing” – but only because the BPM proponents likely have a more flexible notion of “what is BPM” than the ACM group.

Finally, we see this from Kraft:

And – what we need is a “process funnel” – as I tried to depict in the diagram. That is – a process that today is a completely unmanaged process (only by email) should become an ACM managed process. After a while – if it is a mature process – it can become a BPM managed process (for example by exporting it from an ACM system and importing it into a BPM system). After a while – if the process has further matured – it may become part of an ERP system.

I think Mr. Kraft is essentially correct, and most people would benefit from adopting some kind of funnel, just as he describes.  However, there are two small issues, which don’t detract from the main point he’s making – but the inconsistencies between these layers may not be obvious in a casual read, while they do affect how you approach the funnel:

1. ERP is a tooling (or software package), without a methodology.  In essence, the “methodology” is to standardize on a big software package.  That may also include giving up on differentiation, but it doesn’t have to.
2. ACM and BPM “methodologies” can both be accomplished with the same tool sets (software packages), even if you accept that the methodologies are distinct.
3. As a result, the transitions from one layer to the next have different degrees of friction with your IT and Business groups.

The funnel itself makes perfect sense.  In fact some of the customers and IT staff we’ve worked with prioritize their process work this way: by forcing new project ideas to go into the funnel starting with a fairly loose “ad-hoc” definition, and only with volume does it move into the more structured definitions more commonly considered “BPM”.

As usual, a strong contribution to the body of thought from Mr. Kraft, around ACM, BPM, and Taylorism.

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.

Gary Comerford:

I think one of the reasons that a lot of process management projects tend to get bogged down is because they try to understand the ‘whole level of detail’ issue way too early. I sat today with one guy who had brought Visio diagrams to the meeting detailing everything he did. These diagrams had about 25 or 30 activities on each one. At the end of the sessions we had been able to simplify and condense those activities into about four boxes. For each workflow we were looking for: A trigger, A set of high level activities, any important deliverables, touchpoints to other processes and an end state. Nothing more.

So true.  BPM depends upon building the right abstractions for your business, and business processes.  Getting to the right level of detail (rather than the lowest) allows us to build solutions at the right level.  When you see flowcharts covering a wall (or more than one screen in Visio) – the yellow flags are waving.  Slow down, caution.

Yesterday’s post on the Cosmonaut has me thinking about how new products are developed and released into the wild.  We focus so much on startups and processes in the software and virtual world, but Kickstarter has exposed a new process for physical products:

1. Come up with an idea for a product that you think people will want, but you don’t see satisfactorily provided to the market.  (ideas are often for art projects or music albums, not just consumer products like this)
2. Build a prototype and put together a pitch video to sell the idea
3. Do the research to figure out how big a production run you need to do to make the object “affordable” (whatever that means for what you are pitching).
4. Put your kickstarter project page together, including a fundraising goal that supports your minimum requirements.
5. Wait to see how many people and $ show up to support your project.
6. When (if) project funds, get started building the product (or producing the benefits the contributors are entitled to).
7. Ship it.  If it sells well, consider selling more of the product online, knowing that you now have won over an early adopter fan base.

It favors small production runs, prepaid by motivated customers.  The magic is that you don’t put capital at risk until buyers have paid (up front!) for the product.  It is a great way to get pre-commits from a motivated community. And to my way of thinking, this is just a new (and better) process for finding demand when you don’t have the capital to “build it and hope they come.”

If we relate this to the Lean Startup, or specifically to Steve Blank’s incarnation the Lean Launchpad – one of the key tenets is to “get out there and talk to customers”.  Moreover, to find paying customers.  Not just customers who say they will buy it, but customers who will literally write checks to you.

And when they do this – in great dollar amounts or numbers of customers – then you move into production. Kickstarter gives the product team a chance to do this with physical goods in a way that was nearly impossible 10 years ago.  It also allows an innovative team to address niche demand in a way that they previously couldn’t.  In the same way that eBay allowed people to find markets for niche products, so does kickstarter – in one case auctioning used goods, in the other case contributions toward products that don’t yet exist!

This moves physical products into the realm of a process that looks like:

1. Design
2. Sell
3. Build

Which is much more capital efficient than

1. Design
2. Build
3. Sell

As it allows for less waste (building products that no one wants- akin to getting the requirements wrong in software and BPM projects).  And it allows for some feedback loop between design and selling, before moving into the build phase.

It feels like something that could be truly transformative for small business product development.  I have several friends in the business of producing physical objects for sale (furniture, productivity tools, gadgets), and I’m telling all of them they have to try this process and see if it works for their business, and reduces the risk for them.

As a buyer, the other thing that is really fascinating is the exposure to the process, or craft, behind the production of these objects.  The videos and written updates about the procedures are quite educational.  As a process guy, I see it all through the lens of repeatable process with, typically, an irreplaceable human component.  Gratifying craftsmanship.

(Editors note: this is part product review, part examination of a new process emerging)

Well, we know Steve Jobs was not a big fan of the stylus.  And I’m happy Apple didn’t design touch interfaces that required them.  But like many others, I still want to be able to draw my ideas on an iPad with more precision than my fingers will allow.  There are a bunch of these products on the market now, but at the time the kickstarter project for Cosmonaut was kicked off, I hadn’t seen one that didn’t look cheap yet.

Marco Arment has done us all the favor of reviewing the Cosmonaut – “I’ve tried a lot of iPhone and iPad styli, and I haven’t liked any of them before. But this one’s very different.” and also trying out lots of other products.  I haven’t personally used any other stylus for the iPad, but I agree with Marco’s general sentiments:

• First, that the packaging is excellent, and nice branding to boot.
• Second, that the wide grip of the Cosmonaut is a big advantage – because you really do use it more like a whiteboard marker than a pen or pencil.
• Third, that it is the first product I’ve used that actually feels good when you use it. The rubber tip requires just the right amount of pressure to register with the iPad, and glides effortlessly and smoothly across the surface (even if that surface has the sticky finger prints of your 2yo son on it).
• It exudes quality.  And since we were part of the kickstarter project, we know why.  The creators were meticulous about finding the right materials.  They switched manufacturers more than once.  Getting the right grip, the right aluminum core, and the right tip were all quite time consuming (to, I think, the frustration even of the creators).

Choice quotes from Marco’s review:

There’s no foam anywhere in it. The soft rubber tip gives slightly when pushed, because there’s a small air pocket between it and the solid aluminum core.

and:

It doesn’t feel like a brick of solid plastic writing on glass, and it doesn’t feel like a flimsy sponge on a stick. It feels like a marker, as designed.

I forgot to bring it with me on vacation (I switched laptop bags) and I’m actually annoyed.  I was hoping to try out additional drawing applications. I’ve used penultimate and a few others. But the feature I really want is an “infinite” canvas, or at least a canvas much larger than the screen.  That way I can use rough handwriting with the stylus, then shrink the whole thing down to fit on a screen and reduce to “normal” writing size.  Hopefully I can find an app that does this without too much trouble – it would make a perfect companion to the Evernote note-taking app (though truly, I wish Evernote would just solve both problems… a rare case where you want the app to do two things well, rather than just one).

At the end of the day, the team at Studio Neat worked hard to produce something that looks deceptively simple.  It just looks like a rubber stylus.  But it has the right heft, the right feel, the right size.  It takes a lot of work to produce the right, simple, product.

Good news, you can now buy your own here.

No doubt the Cosmonaut will come in handy for me when I need to sketch an idea or process while attending a meeting.  But my daughter’s first contribution to the blog is a bit of artwork… what surprised me is how much better it is than what she usually sketches with her finger, and the process she used to draw it.  First she colored everything blue, by hand (she could have done this by changing the background color, which I’ve seen her do before… she told me she liked the texture).  Then she drew the clouds and flowers on top… green shoots first, then flowers, then a bit of yellower grass at the bottom.  This is a process that works much better in software than it works with pen and paper, though you can do something similar (with some mess) with crayons.  But try drawing white on top of blue in almost any medium – it doesn’t work too well!  Her work is already better than some of my process drawings!

Editor’s note: this is a repost of Gary Samuelson’s post of the same title on his own blog, found here. 

As in business, BPM projects either produce or fail. And, in varying degrees, BPM honestly tries. Maintaining net-value is an effort of direct participation. To remain relevant… one must keep up with the pack – speed counts. This demands agile, quick development iterations and, consequently, a serious weaning from project fat.  Cutting corners gets us ahead of the game. Knowing when, how, and which ballast to cut throughout keeps us in the game.

Evolution

Focus on the relationship between software development methodology and business success.

The catalyst behind change is our drive towards increasing efficiency. The tools and methods behind process management effectively short-circuits communication channels and re-wires the organization. Brought into focus are traditional gaps in execution between business leaders and software development. Otherwise impeding the flow of evolutionary progress, and spotlighted for what they are, progress forces its way around unnecessary bureaucracy.

Obvious like highway congestion and air-travel delays – we need change. It’s our impatience. It’s nearby, within reach, and forces itself as matter-of-fact: keep up or be left-behind.

A Spotlight on Bureaucracy: Tradition

“There are protocols that must be followed, regardless of their cost or waste.”

Let’s take a look at a more traditional methodology.

The Business Owner communicates values to our Requirement Analyst who, in turn, produces documentation which is then, in turn, handed over to the Process Architect.

Process models flow into software which then become rooted within operations via services (SOA) and general integration architecture.

The “playback”, or software demo’, provides a theater where our Business Owner communicates direction back into the next cycle. Iterations repeat until we find usability.

In theory we have a fairly good working methodology. In practice we do not.

Short-circuit Communication and Evolve

No barriers. No handoffs. One team.

Our new model has the Business Owner working directly with the Process Architect.

Reasons:

• Direct communication between Business Owner and Process Architect is simply more efficient. This efficiency produces working, executable process in a fraction of the amount of time that would have otherwise been spent on traditional, time intensive, requirements documentation and review cycles.
• As business feedback (aka requirements) now flow directly into development there’s neither room nor slack for misunderstanding.
• Reduction in administrative overhead (requirements documentation) allows shorter iteration cycles and early delivery.

Business Value

Work occurs with the immediacy of market conditions.

Value-driven methods and purpose force efficiency. From the Business Owner’s perspective, “value” is executing process:

• Strong User Interface
• Valued Process Outputs
• Supporting Services
• Shows Strategic Direction while supporting tactical agility

We now understand the nature of process development. BPM projects DO NOT build systems because “systems” lack context – technology isn’t the point. The effort behind building “systems” is as irrelevant as attempting to build a house before its blueprint… more so even before understanding the intended home owner’s perspective. The best approach then is to isolate our system builders – take them out of the picture.

Irrelevance

Those who once lead must now follow

Removing system builders removes distraction. Without this distraction we’re able to maintain business alignment and, consequently, remain focused on business process development.

So what does a roomful of system builders do when left on their own? They build an irrelevant system.  Frequent the result of specialized teams is competing effort – things created, with good intent (we hope), that offer much less support as interference.

We’re left with a dichotomy.

Our goal still focused on business process and yet diplomacy plays in as a key strategic requirement? Though completely outside the scope of process development, “change management” (politically correct term) is none-the-less required.

Rebuild The Team

NEXT WEEK’S PREVIEW…  (to be continued)

The best solution here is to break these specialized teams apart and reassemble as cross-functional units (aka “pods”). We keep our specialized skills, such as QA and integration, while maintaining orientation on process development.

As a BPM effort we have “process” goals on our plan. Competing milestones no longer receive management’s attention. Goals become aligned and focused on process development iterations.

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.

Peter Schooff of ebizQ asks: “How big of a role does BPMN play in today’s projects?” And the responses were interesting to me.  Most of them took the line that BPMN isn’t that important, or that they don’t typically use it.  That someone who fails to understand BPMN will fail to understand the process, just as surely as you might get false agreement in a process by being vague in its description.  My response:

We use BPMN all the time in our projects, but we do a lot of process implementation projects, and it is a good fit for the tooling we use.  Craig makes a good point about someone not understanding BPMN precisely – but at least BPMN has a precise definition – unlike the usual whiteboard drawings.

I like to get on the whiteboard and build out the diagram and explain and talk as we do it.  By seeing and hearing the build-out, there’s much less chance of confusion about the interpretation.  And when you’re done, the diagram is actually accurate for someone who reads it “after-the-fact” if they know BPMN.

Having said all that, BPMN is a means to an end.  It isn’t the goal, it is a tool.  There are other tools and in the right time-place each one is useful.

Whenever there is a standard there’s inevitably a bit of back-lash against the standard from experts – almost as if it is a badge of honor to buck the industry standard.  I say this knowing full well that I’ve done it before myself!  But with experience comes a little wisdom and perspective and I don’t hand out badges of honor for either obeying doctrine or bucking it.  The badges of honor come for delivering great results.

BPMN isn’t perfect.  In fact, to misquote Churchill, it is the worst form of process modeling that has been tried… except for all the others that have been tried from time to time.

Jim Sinur weighs in with a blog post that supports a point I’ve made before:  that companies who aggressively acquire other companies use standard processes to make it work.  Take this anecdote from Jim:

This success snippet is about an organization in the insurance industry that has experienced significant top line revenue growth while simultaneously increasing it’s net profits over 40%. This company uses BPM for aggressive acquisitions by leveraging standard processes with local variations while driving down overall costs on a large scale.

Not only do they use standard processes to acquire and assimilate, they use standard processes (with local variations) for their core business functions, which the acquired companies will also participate in.

It actually doesn’t matter if this is defined as “structured” or “unstructured”, knowledge work or routine work.  The world will look at this and likely call it “BPM”.  Because it is about managing business processes. And this is why the arguments among experts about naming are really a bit off-point.

As Jim Sinur says – the success of BPM is spreading and is too big to ignore.

Jakob Freund has written an interesting defense of Taylorism, and he makes a few interesting points that I don’t recall seeing in previous discussions about ACM v BPM.

Actually, when I am driving, I am a zombie worker most of the time. Sometimes, of course, there are “unpredictable” events, like a child running over the street, or an alien spaceship landing in the middle of the highway. Then I become a knowledge worker, handling that case with my horribly flexible brain.

No, I don’t mean the point about alien spacecraft, I’m referring to his point that being able to operate on auto-pilot leaves our mind free to focus when we really need to, in value-added situations.

So the bottom line is: Making the world more predictable (yes, it can be done), and then applying axiomatic systems to it, is nothing invented by Taylor and somehow an “accident” of the 20th century, but it is a central component of human evolution. It has always been there, and it will always be there, as long as people are interested in less work and more free time.

This is also an interesting argument.  A bit too much credit has gone to Taylor over the years for putting into words what might already have been in progress.

The central thesis seems to be that reducing “knowledge work” to scalable process work is one of the key imperatives of scaling a business.  It is an interesting take on things, and fits a lot of the process efforts that focus on efficiency as a goal.  And it is a refutation of much of the hype around ACM as being something shiny and new.

ebizQ has an interesting two-page article on BPM and Healthcare titled “BPM: The healthcare industry’s prescription for serving patients better“, which uses the label BPM broadly (not specifically meaning “BPMS”):

For example, Nunn says, one facility used BPM to reduce the number of patient falls—a common problem among elderly people and those recovering from surgery. After analyzing data, the facility changed the layout of its beds so nurses could better keep an eye on patients when they got up at night to use the bathroom, which was when most falls were recorded.

In another case, Nunn worked with a hospital trying to pinpoint why many of its heart-surgery patients were getting infections. By examining the entire process of surgery from admittance to discharge, Nunn’s team was able to determine that an autoclave, a machine for sterilizing instruments, was not working properly, even though its gauges indicated that it was reaching the proper temperatures. After the hospital replaced the machine, infection rates plummeted.

As I’ve said at other times, there’s a place for more “case” oriented approaches in hospitals and healthcare, but the case approach would *never* address changing the layout of beds, nor determining that the autoclave isn’t sterilizing sufficiently.

To those that think that examining aggregate outcomes is irrelevant in patient care, I’m telling you, you are missing the boat.  Note that the above two examples I picked out don’t necessarily require BPM (six sigma analysis likely would turn this up), BPM can be the instrument for collecting and analyzing the data that allows the six sigma (or other experts) to determine root cause – or failing root cause, at least to identify correlation.

This isn’t the first time we’ve pointed to good work by others, documenting the benefits of BPM to the healthcare business, and I’m sure it won’t be the last.

David Brakoniecki wrote a great post on “those pesky rules” last month and I just had to comment on it.  The startling finding was that at one insurance company, 30% of the rules were flat wrong.  As David says:

Given that the insurance business is really little more than sets of rules – underwriting rules, claims management rules, customer cross-sell rules – and that it is a heavily regulated business, incorrect rules are more than bad business but potential regulatory nightmare.

Bingo.  The problem with rules is that many of them are simple, but the interactions between them are not.  The resulting outcomes are not.  There are better ways to represent these kinds of solutions (constraints, heuristic search, etc.) but they require pretty advanced education to model, and most companies are looking to de-value expertise rather than invest in expertise. So simple rules are used – simple in each instance, but complicated when taken as a whole. Unpredictable as well.  The right abstractions are not available for modeling, so granular abstractions are used, and they’re just not good enough.  It becomes unmanageable or inaccurate over time.

As Dave goes on to say, it just isn’t realistic for the business to maintain rules without assistance from IT.  We have to get past the idea of IT or Business owning the assets of the business.  Both parties need to take responsibility for the health of the business and the health of the assets that allow that business to perform smoothly, or at all.

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.

Bruce Silver, never one to shy from a debate, weighs in with a post I largely agree with:

The question is BPM part of case management, or is case management part of BPM? is a metaphysical one.  I think, however, it is a proxy for the real question, can a BPMS do a good job with case management, or do you need a special dedicated tool?  It’s obvious that if a single offering could provide both, users would prefer it over separate dedicated offerings.  And it’s equally obvious that it can be done, although it’s fair to say that the offerings may not be good enough yet.  Back in 2005, people said you needed separate BPM platforms for human workflow and integration processes.  It was just a matter of time, and not that long a time.

In one paragraph, I think Bruce has succinctly cut down 90% of the noise:

1. This is a metaphysical question. In a practical sense, who cares.
2. To the extent that people care, it is because they’re substituting this metaphysical / philosophical question for a practical one: “Can a BPMS do a good job with Case Management?” (or ACM)
3. Everyone understands customers would like to have one tool that does both. And makes breakfast.  Thus the fear and uncertainty and doubt about this issue among software vendors.
4. Anyone who can code worth a lick can see that it can be done. But as Bruce says, there’s a lot of room for improvement on most of the tooling out there.
5. History suggests the ultimate answer.

He then moves on to discuss how a case might be different from a process.  Overall a great read.

Jacob Ukelson posted about preventing failure vs. fixing failure.  He make a few good points and along the way once again compares ACM / BPM by implication.  In a sense, many will argue, ACM is about learning from failure, and BPM about preventing failure:

One of the key reasons companies deploy a BPM suite is to prevent failure. This is a major selling point for many BPM solutions. A key goal of a BPM suite is to enable the deployment of process driven solutions that prevent a deployed process from failing.

But of course, as he points out later, it isn’t always cheaper to prevent failure rather than fix it. ( Not to mention, in some businesses, fixing it is an opportunity to delight the customer. ) This  is the crux of it:  the arguments about failure are talking past each other.  Process Improvement (BPM) should aim to reduce preventable failures of a fairly routine nature.  Data entry errors, for example.  Logical inconsistencies. This isn’t the primary or only goal, but it certainly is one important form of process improvement for many processes out there. But the idea that we should learn from failure isn’t exactly a new one either… Max Pucher’s blog is an excellent example of this concept in the 70′s and 80′s.  The Lean Startup is an excellent example from the startup world.

If you’re familiar with six sigma technique (a fairly mature method that predates my professional career), then you’re likely familiar with the Failure Mode and Effects Analysis (FMEA).  In it, you rate possible or anticipated failures by:

• Severity – how bad will it be if it happens?
• Frequency – how likely or how often is it to happen?
• Detectability – how easy and reliable is the detection of the failure (or pre-detection).

Different remedies apply to the failures depending on their characteristics.  Often this is applied at a pretty tactical level.  But conceptually you can apply it at a macro or management level.  Such aphorisms as “worry about what you can control, not what you can’t” and “prepare for the worst hope for the best” are perhaps simplified examples of this kind of thinking.  Much business advice could be reduced to focusing on what matters and letting go of what doesn’t.  Some failures don’t warrant preventative treatment, and some do.  This isn’t exactly a new idea.

The kind of “preventing failure” behaviors that ACM folks are pushing against are mostly organizational or cultural in nature rather than procedural. It isn’t like BPM proponents are advocating that businesses circle the wagons and just focus on preventing failures.

So in summary -  where you want to play it safe deploy a process solution focused on managing structured processes, if you need agility (and are willing to accept its associated risk) then you should focus on “first fault problem resolution” for your unstructured processes – rather than try to structure them to prevent failure.

This isn’t as easy as it sounds for some businesses.  Let’s talk the First Horizon oil spill disaster in the Gulf of Mexico.  Did they need agility or preventing failure out there on the platform?  And which situation did their decision-making process most resemble?  (Given that individual operators could and would override long-established safety protocol, I think we can infer that they were on the side of more agility vs. more preventative).  Other businesses, and other situations, would have a different profile and tolerance for various kinds of failure.

If you’re going to have agility and learn from failure, don’t forget one other thing.  You need really good leadership.  If you don’t have that, the results of failure might surprise you.

SXSWi has one of the more interesting content picking processes I’ve seen for a conference.  It has turned into a well-oiled machine, and it is, in my opinion, responsible for allowing SXSWi to reinvent and remain relevant (even more relevant) over time.

Recently, topics for SXSWi-2012 were released.  These are the panels and sessions that were voted on by attendees or prospective attendees (although a vote isn’t the only input into the panel picking system).

If this year is like most, some additional featured speakers or top-down content will be added, in addition to a few late-selection panels to reflect any late-breaking news or changes in the world around us.

Topic areas:

• Keynote Presentations at the Austin Convention Center
• Featured Sessions (Austin Convention Center)
• Better Tomorrow (Austin Convention Center) – a focus on economy and social issues
• Book Readings (Austin Convention Center)
• Branding and Marketing (Stephen F Austin hotel – which was also the site of the BP3 all-hands meeting!)
• Convergence (Austin Convention Center)
• Design and Development (Austin Convention Center)
• Emerging (Hilton Austin – Downtown)
• Future of Work (Courtyard Marriott)
• Government and Global Issues (AT&T Conference Center)
• Health and Education (AT&T Conference Center)
• Journalism and Online Content (Sheraton Austin)
• Latin America (Hilton Garden Inn)
• Lifestyles and Sports (Campus TBA)
• ScreenBurn and Gaming (Campus TBA)
• Social Networks (Omni – Downtown)
• Startup Village (Hilton Austin – Downtown)
• Workshops (Radisson – Town Lake)

The biggest change I notice : moving the startup events to the Hilton (which is like ground-zero, right across the street from the Austin Convention Center), rather than having them at the AT&T Conference Center, as they did last year.  Last year’s startup sessions were really high quality – and the AT&T Conference Center at UT is a fantastic facility for an event like that – but it is removed from the core action at SXSW.  My guess is that there was an effort to bring this core area back to the center of the activity at SXSWi.  The only downside is it will be much harder to park this year!

To anyone trying to organize a conference, I submit to you that you just haven’t seen crazy til you’ve been to SXSWi.  The number of people and the logistics involved in feeding them, moving them, parking them, seating them, and providing wifi and 3g cell connectivity for their 3 connected devices is an incredible challenge.  And it is impressive how well it all works.

The Startup Village has its own set of articles on SXSW’s website.  This promises to be a great conference.  The number of topics is overwhelming, but the organization into campuses and topic areas at least helps focus attention on the topics you care about.

As I was about to post this, I ran across Austin Startup’s coverage of the same subject.  GREAT tidbits they pulled out from the schedule:

Stephen Wolfram on Computation and Its Impact on the Future. Any chance to hear him speak, I will take it.

Definitely. I look at this session as being potentially as promising as the Craig Venter session from the 2011 conference.  They also pointed out panels from Dachis Group, RecycleMatch, WP Engine, and Foreca.st (local startups).  Josh Baer will reprise a topic he owns: 3 Secrets to a Killer Elevator Pitch.  Even this far in advance it looks like a very strong lineup.

James Lawther guest-posts on Gary Comerford’s Process Cafe Blog, and it is a piece we can really relate to at BP3:

In the beginning all businesses start out as small businesses.  They start with one, two or at most a handful of employees with a vision to give customers something new and different, or just better.  They then focus like crazy on those illusive customers, doing everything that they can to find and please them.
[...]
And then the company grows.

At BP3, we’re growing.  The trick, as they say, is not to lose that focus on the customer as the company grows.  Lawther’s advice?  “It is remarkably simple.  Get your business to re-focus on the customer and optimise around them not their functions.  And that is all business process management asks you to do.”

Even better – don’t lose that focus to begin with.  Easier said than done!

I’ve been getting tired of reading about “The Melt” – the new company / concept from the folks behind the Flip camera company.  Press like this quote from the interviewer: “You’re not just trying to build a restaurant, you’re trying to build… an empire…”  Wow.  Well that makes it a tech company right?  Well, actually, all of the big restaurant chains have become technology companies to varying degrees.  They’re also process-centric businesses (though they use specialized software and hardware, not general purpose BPM software).

Tons of name dropping in the video below (which only makes me more skeptical):

This should be my dream come true – I love grilled cheese sandwiches, and I make a pretty good one myself.  Their focus on process would be really interesting if we already knew they were a success (we don’t yet know this).  It is nice to see process and process tech getting top billing, in a sense.

And despite my visceral negative reaction to the coverage of The Melt, it *is* a tech company.  Comparisons are made to McDonald’s, Starbucks, Chipotle.  These are all process and technology companies that happen to be pretty good at producing food and coffee.  But extra emphasis is given to the processes and technology that go into the restaurant chain:

The same thing goes with The Melt. Kaplan went with grilled cheeses because he found machines that press and grill a grilled-cheese sandwich in record time, which ensures fast turnover, which improves profitability. The grilled cheese comes with soup because it’s cheap, and easy to store and manufacture. You can order from your iPhone, again, because this improves turnaround time.

Let’s hope they don’t forget to make a grilled-cheese sandwich that is absolutely better than what I make at home – and the soups better be good too.  If the food isn’t great, they won’t need fast turnover because they won’t have enough customers to eat the food.  Fast turnover only matters once you have volume.  Descriptors like “cheap”, “easy to store and manufacture”, “record time”, “fast turnover” – these aren’t encouraging adjectives at this stage of the enterprise.

The article closes with:

It’s a manufacturing and technology process. It’s really not that different from making portable cameras.

At the end of the day, you can’t taste a Flip camera.  You’re customers are going to eat these sandwiches – they better taste good.  I hope the folks at The Melt understand that better than the Business Insider.

Dave Brakoniecki writes about Technical Debt:

The fundamental metaphor underlying technical debt is easily understood in technology circles but nearly incomprehensible outside of them. Unless you understand in detail the technical trade-off you have no appreciation for how you are ‘borrowing’ which makes it a trust issue between the business and IT teams. If this trust exists, then you don’t need the metaphor to make the problem explicit. If the trust doesn’t exist, then the metaphor won’t help you.

A counterpoint to this – I recently saw a talk by HomeAway’s CEO, Brian Sharples (at Capital Factory).  I also had a chance to talk to one of their lead developers (a friend of mine from way back).  When I asked my friend how it was going these days, he said (paraphrased) “we’re paying down a ton of technical debt right now… and when I look back, and ask if we should have done anything different, the answer is no.  I think we made the right call.”  Interesting. Thanks to Eric Ries, I knew what he meant by Technical Debt.  I also knew what he meant about paying it down (HomeAway has been acquiring companies, and paying it down in this context means they are consolidating these companies onto common software systems instead of maintaining fragmented systems… )

In their terminology, technical debt is a cost that has to be paid in the future.  It can be estimated in terms of work effort.  But consider a variable interest rate – you have the same problem. You estimate costs, but you don’t know for sure what the future cost will be.

Finally, I actually heard the CEO refer in his talk to paying down technical debt.  He had the same meaning the developers had.  What this told me is that he’s invested in the whole company, not just the “business part” of the company.  Those techies are his people too, not just an IT arm to be offshored later.  And they explicitly understood they were postponing a cost (integration) into the future, a future in which they could afford to pay it down (IPO money helps with that).

Dave goes on to say:

The reason the metaphor doesn’t hold is that the unit of borrowing can’t be quantified. Technical debt is an attempt to use the well-understood concept of financial debt to explain a software development problem but everyone (business and technical) understands what happens when you borrow money and the cost of that decision. It’s explicit.

If you borrow $1, well then the amount you owe is $1. People have mortgages and credit cards and use them to make decisions to borrow money so both everyone in an organization can be reasonably expected to understand the basic concepts of financial debt.

The same is not true of technical debt. The unit of measurement is entirely a trust issue between people. Most technical debt conversations are really the engineers saying to the business stakeholders: If you make me do it this way and in this timeframe, it will cost you more in terms of effort to support per month.

But, unlike the financial debt, the interest may not materialize. On your mortgage, you know exactly how much interest you will pay. It’s not a random number.

Getting a handle on the cost (future cost) of technical debt is hard, but it can be done.    You usually have an ongoing cost that you can think of as interest (the cost of maintaining two systems, for example, or supporting two databases when you only need one).  When you remove one of the two systems, it may have a lot of accumulated debt-  which is now all retired debt.  Presumably its functionality was either no longer needed, or replaced by implementing (and paying for) another system.

As to quantifying – this all comes down to estimation and convention.  A proxy is just lines of code (each line of code incurs some maintenance cost, in theory).  Another proxy is to put work estimates against it and cost those.

One might expect me to come down against metaphors – I’m not a fan of using them as proof in arguments or debates.  They’re better used to explain yourself or your thinking, than they are as “proof”.  But in this case, technical debt is a decent short-hand for work-effort we need to plan for in the future.  It avoids people thinking they’re avoiding cost when they take shortcuts – they’re really just spreading that cost out over a longer period of time (for perhaps a much higher overall cost).  Similarly, it assigns cost to gold-plating the software implementation (more lines of code = more debt).

Pretty interesting perspectives on the concept… for more about applying this concept to processes, check out these posts.