Recently at IBM Impact I said that “process data wants to be free” – available in more places, more accessible to users and managers, and more sensible in form and structure.

Jacob Ukelson makes the case (paraphrasing) that process just wants to be free:

From my perspective the simplest answer is that we focus on unstructured, unpredictable, ad-hoc human processes that knowledge workers do, while BPM suites focus on structured, predictable processes – and the two approaches are complementary.

In other words, make it easier for the everyman/everywoman to execute their processes.  He focuses on three key themes that differentiate ActionBase from other approaches to knowledge work:

1. Familiarity – ActionBase leverages email and documents in a way that is immediately famliar, rather than asking users to learn a new tool or URL.

2. Collaboration – This is as much a benefit of leveraging email as anything, but the point is that users can dynamically bring others into a process to help, at runtime.

3. Managed – applying “enough structure to make the process manageable, but not so much as to strangle it.” And so the focus is on visibility rather than constraining or controlling the flow.

These are good tenets for anyone to build software around.  Philosophically, I think ActionBase has it about right.

(As an aside, this article from Keith is a good read, but I disagree with his conclusions)

Keith Swenson on Airline Mergers not using BPM, making the case for ACM:

Usually when I talk to BPM experts, they say something like “Of course you wouldn’t use BPM for something like a major airline merger”.    Most people understand that you would never use BPM to arrange a lunch with a colleague.    There is broad understanding that there are things that BPM is simply overkill for, or too slow for.

The merger between United and Continental is a unique event.  It has never been done before, and will never be done again in the same way.  It has similarities with other mergers, but not to the level of detail that specific action plan (process definition) could be drawn up and re-used.  This is a case where a pre-defined process will simply not be worth the benefit, or the cost in terms of delay.

Am I to believe that they used an ACM product for this?

Going into the weeds here, though I think that makes my basic point, here’s some of the background thinking:

Companies that engage in acquisitions a lot actually do have pre-defined processes for acquisitions – IBM, Cisco, Oracle.  Are there parts of the acquisition that don’t fit neatly in a box? sure there are.  That’s why it is called BPM, and not automation.  Keith is giving us a false choice: all paths must be defined in BPMN in order to be BPM, on the one hand; on the other – nothing predefined in ACM and process nirvana is achieved.  I’ll just assume that ACM would equal process nirvana in this case, and focus on the BPM choice to demonstrate my point.

With the right abstractions in your BPM models, you don’t model all possible choices, the choice is just data along the path to the next node, rather than having a separate path per choice. Nodes can be well-defined BPMN models, or they can be applications, or they can be “ACM” style processes like “Meet and make a Final Decision”, which may end up being 3 meetings or getting some additional emergent process defined.

Or they could map out the process they’d like to follow in Blueprint or ActionBase and go from there – much lower overhead for a one-off process- although THIS process has an effect measured in Billions so it might actually be worth it to spin up some cycles on defining the process even if it isn’t a running implementation of the process.  Yes, requires a little bit of thinking ahead – but it doesn’t require BPMN – and it also allows for documenting any changes as you go.  And yet, I’d still call it “BPM”.  From a technology point of view, these folks may not be using a BPMS to do their acquisitions.  But that doesn’t prove that they couldn’t.  Whether a BPMS would be helpful or not largely depends on how well it supports this kind of use case, and that varies widely from one software package/vendor to another. Part of the problem: is “BPM” defined by what a BPMS can do for you? or is a BPMS defined by what you need to do “BPM”?  Tough one.  But you see this kind of problem all the time in software market definitions.

Do I think ACM could be a good fit for an airline merger? Sure, depending on the specific software and its features – this isn’t a run-of-the-mill situation.  But if I use Keith’s logic, the fact that the airlines didn’t use ACM for this merger is proof that ACM doesn’t solve the problem.  (tongue in cheek)

Generally in my experience if your modelers can’t model the process, you need to find new modelers.  I might need to add a corollary though – your BPMS should be capable of handling abstractions well (like generic failure events, arbitrary data definitions, dynamic binding to service definitions or sub process definitions… )  It sounds like a lot of the folks writing about BPM and ACM still haven’t used a BPMS that supports these features.

(Incidentally, I agree with Keith that you wouldn’t use a BPMS to schedule lunch with a colleague.  However, that’s because there are already good software solutions for scheduling lunch.  If I was writing one of these solutions, like Tungle- I might very well use a BPMS to coordinate finding the right time on our schedule – because it is often done via electronic means and the back-and-forth is pretty inefficient.  Tungle.me didn’t use a BPMS – but they sure could have.  The point of BPM or ACM isn’t to do everything that they could do – it is to apply them when you don’t already have a good solution)

Jacob Ukelson is once again pushing email and documents as the way process should happen when it is “design by doing”:

The only way “design by doing” can work is if you observe knowlwedge work in its natural setting. That means email, documents, meetings and telephony. That just doesn’t mesh with a BPMS. I think that most BPMS vendors would like people to tidily do all of their unpredictable, ad-hoc work in the BPMS, but the real world doesn’t work that way. People use what they like, and like what they know.  They are not going to change their habits just because the vendors think they should.

The idea that design by doing is antithetical to BPM doesn’t seem right to me – there’s a spectrum between these poles, and i’ll give you an example.

The way I’ve seen Lean applied to white collar (officework/knowledge work) processes resembles design by doing. You start by running whatever they currently do, document the wasted effort/steps, try out changes in the process, til you get it right. Then you start training more and more people to follow the process. A BPMS can support this kind of work because you can iterate fast enough to keep up with the changes, even over a very long improvement cycle with many changes.

Now, design by doing isn’t quite the same as “unpredictable work” – but obviously, they are related concepts. If the work is inherently unpredictable, or improvements to it do not justify IT investment in a doing-by-design approach then I think ActionBase is a great answer to that need. As Jacob says, email and documents are the tool of choice when one doesn’t have a process – precisely because of their ubiquity and rather than compete with that, I like how ActionBase leverages that truth.

As to his characterization of BPMS vendors – he may be right that they would prefer to have the unpredictable work go into tidy processes. But this is not a fair description of the BPM service provider community (or at least, of the firm yours truly works for), which has often been creative about applying hybrid structured and unstructured techniques to address knowledge work.

No matter what the vendors say, no business user can take a BPMS out of the box and start using it for their own work.

True – if you mean to use it without a single implementation dollar spent.  But if you have 100s or 1000s of people doing this email and document thing for a process, you can probably afford to spend a few IT dollars to figure out what the best practices are. Let the doing guide the design, but you have some efficiencies of scale to achieve. In general, BPM has to get simpler – and the kind of approach ActionBase takes seems (to me) to be a great example.

Jacob wraps up with something I couldn’t agree more with:

So if we are really to make “design by doing” a reality as part of BPMS, then somehow the tracking and management of  existing end-user tools and work paradigms (especially email) have to become a part of the conversation.

So true. BPMS vendors need to be able to track email-based processes.  A Lean or other process improvement expert can work without this technology, but as with structured processes, it is so much easier to get to the “right answers” when technology supports your efforts.

Jacob Ukelson of ActionBase once again writes an intriguing post on complex business processes, referencing a Clay Shirky article on the collapse of complex business models.

Ironically, while I share Jacob’s optimism about the future of products like ActionBase, I don’t agree with some of the points he makes in his post even though they are in support of a conclusion we both agree on.  First, in areas of agreement: whether you call it case management or ad-hoc processes or knowledge work – software products are increasingly going to target what Phil Gilbert used to call “the 98% of the business that isn’t in IT”.  Different vendors will tackle this differently.  A few interesting examples:

• ActionBase lets users create a process (and amend it) on the fly using Word, Excel, and Sharepoint to drive that process.  Several other vendors have been pushing “case management” or “adaptive case management”, and it looks like ActionBase is adopting some of this terminology in their positioning as well.
• Lombardi (now part of IBM) created Blueprint to foster more participation in building and understanding process models (and not strictly BPMN process model views). Simultaneously Lombardi released products to integrate ad-hoc subprocesses leveraging Sharepoint (a common example is collecting interview feedback via Sharepoint, but collecting the final decision on follow-up steps in a structured process).  Several other “community” and “social” sites have cropped up since:  Alignspace,  Blueworks, Signavio, to name a few – each with different target audience from formal process modeling to more informal networking and sharing.

However, part of Jacob’s post I don’t find myself agreeing with.  Jacob makes the argument that BPM-targeted products are becoming more complex – by adding rules, simulation, event processing (and by adding to the modeling notation itself).  I’ll agree that the BPMN notation has evolved to become more complicated – and that is a concern – but mitigated by the fact that you aren’t required to use the most complicated elements to get the job done.

As Jacob notes, supporting rules, simulation, and complex (or even simple) event processing is valuable, but I think he overstates how much complexity is added by including these elements in a BPM offering.  For one, processes often leverage rules and events regardless of whether these features are integrated into the BPM offering.  For another, transparently supporting events and the way they interact with your processes actually reduces complexity of the software solution being built.  If you have a simple process that doesn’t require events, you don’t pay a complexity penalty for those features existing – but if you need to deal with events interacting with your process, then having a well-integrated event model actually helps quite a bit.  Finally, simulation is almost a completely separate function – it doesn’t complicate execution or building the executable model, but it does give analysts a way to model behavior before they go live.

An interesting example.  One of the things you often want from a process is to be able to report on what’s happening within the process, or to do analysis on the aggregate data.  If data tracking capabilities aren’t baked into the process software you use, then you’ll have to build the data tracking capabilities (and likely, the reporting capabilities).  But if the data tracking capability is built seamlessly into your process software, then you’re more likely to track the data you need, and at less expense and complexity (as measured by lines of code written, or by just about any other measure you choose).

I guess my point, with regard to complexity is this: a given process is easier to describe and translate to execution today than it was before these features were added to BPM suites, not harder.  Of course, with increased efficiency for previously mundane but time consuming tasks, the difficulty of problems being tackles is growing – but that’s just the way the software business works – the goal posts are always moving. There is an opportunity for BPM solutions to differentiate by providing a better overall experience- making sure the various parts that Jacob describes work together as “one” product rather than feeling like they were bolted on with duct tape and bailing wire.  Some product teams have done a better job than others in this respect… in part leading to the conclusion that BPM is “too hard” or “too complicated” by some, while others think BPM is the best thing since sliced bread (and all points inbetween).  A fair amount of this variance in perspective can be traced to early experiences with specific BPM suites.

I think it is healthy for ACM (adaptive case management) advocates to hash out what ACM truly is in their own discussions and forums (as WfMC has separated it from bPM), but I think ultimately organizations are going to see ACM as a necessary component of their Business Process Management initiatives, rather than something separate from their process initiatives.  Jacob is right – many of the BPM software vendors won’t “get” the unstructured world of ACM, until it has a chance to mature and coalesce around what the key features and benefits are.

There’s been a lot of coverage of what it means for IBM to buy Lombardi.  Jaisundar proposed that this would upset the balance of power and cause more acquisitions… But perhaps the side effect he (and others) didn’t foresee was the positioning of the remaining BPM vendors (pureplay or otherwise) for the benefit of their suitors.

First we have Appian’s CEO posting here.  I don’t blame him for putting a stake in the ground that Appian is going to win, and positioning that the only two vendors left that matter are Appian and Pega.  Savvion might disagree, as would a few others, but nevermind.  He states that they’re the only ones strong enough to survive (by which, I would suppose he means financial strength, but he leaves that as an exercise for the reader’s imagination.  I don’t blame him for slagging IBM as killing innovation – in any acquisition like this, that is a very real possibility, and will determine whether this is a successful buy or not (at least, for folks who don’t work for IBM).  But methinks he doth protest too much, and may be trying to make sure that potential suitors remember that Appian still exists in case they want to get in the game by buying something.

Next, we have ActionBase, one of my favorite non-traditional BPM offerings.  In a previous post Jacob Ukelson made the argument that Sharepoint should be a better BPM tool than it is.  Now he argues that Sharepoint + Actionbase is that BPM dream team:  unstructured content + unstructured process… If that isn’t a pitch for Microsoft buying a nice Sharepoint add-on I don’t know what is.  Analysts are frothy thinking about how Microsoft or SAP might want to counter IBM’s move, and this is one option.

I’m not sure that unstructured process + unstructured data is the dream of every IT shop, but it is certainly a combination prevalent in many processes and organizations.  And of course those two offerings could work well together.

So it looks like everyone is putting on their finest Holiday Sweaters and looking to make a good impression for their potential sweethearts.  It’ll be interesting to see if there really is a wave of acquisitions or if this is it.

Its the creative destruction process of capitalism at work.  I just hope BPM doesn’t get lost in the woods in the process.

Interesting post from ActionBase’s Jakob Ukelson, positing that we need a process warehouse to store all the process data we produce.

As he puts it:

That led me to start thinking about the notion of a process warehouse – something to akin to a data warehouse but for processes. This would seem to be the next thing up the food chain (from a business perspective) from a data warehouse. It would essentially be a system-of-record of actual business process usage in an organization. It would keep actual data on process execution (in other words not just a static process catalogue). That would provide the actual business context of data usage – valuable stuff especially in this day and age of increased regulation (and with the increased focus on Business Intelligence and Operational Excellence).

In fact, this is very much the line of thinking that led to Lombardi‘s introduction of the “Performance Server” in its BPMS- a capability for tracking interesting process data in context of the process.  It is a really powerful feature of Lombardi’s offering, and one that I’m surprised I don’t see in other vendors’ offerings.  Which also speaks to the fact that Lombardi could be pushing this message harder and investing more obviously in this key, differentiating aspect of its Teamworks suite.

Jakob notes that he couldn’t find references to “process warehouse” in the literature, despite the obvious relationship to a Data Warehouse – perhaps because Lombardi decided not to position the performance server as a “data warehouse”, and because other vendors just focused on the reporting side of the equation.  And it isn’t a data warehouse in the traditional sense – but maybe it should be.  Many customers feed the data from the performance server to their data warehouse for analysis, and the data is very high quality precisely because of its close correlation to the actual executing process.

Good to see someone else in the market thinking about these issues.

I’ve previously written about various Google Wave blogs and the SAP Gravity Demo, and continuing on that theme, Jacob Ukelson asks whether Google Wave is good enough to become a disruptive force as a “good-enough” BPMS, on the ActionBase blog.

I think there’s no question that Google’s Wave could serve as a “good enough” BPMS for many collaborative, informal, or as-yet-unstructured processes.  It could also serve as a useful collaboration companion to structured process.  One need look no further than two examples from IT history, which are still with us in many enterprises and in many processes:

• Microsoft Excel
• IBM’s Lotus Notes
• Microsoft Sharepoint

After several years of doing “kill-the-fax” initiatives, businesses turned their attention to these other bastions of bad process – Excel, Notes, and Sharepoint.  We’ve done so many projects to replace Microsoft Excel-based processes and Lotus Notes-based processes that we’ve lost count – and often we’re brought in to save a process that is running on Sharepoint.  I wish we had kept statistics on this as it would make for interesting trending data now that we have a large enough sample size.

Google Wave, if it addresses the various security concerns for storing proprietary information outside the firewall, could very well get adopted for informal processes – especially when the participants and managers of the process have not yet come to think of it as a process.  We could refer to these as emergent processes.  Perhaps the first time you do it, you don’t know if it is a one-off or a process.  After you’ve done it a few times, you have a sense that it is process.  After you’ve done it a few thousand times, you start to wonder how you can do this process more efficiently or less often…

However, Jacob goes further than to suggest that Google Wave would disrupt these more entrenched technologies’ use as a poor man’s BPMS.  He suggests that with a few minor enhancements it could fully replace a “full fledged BPMS”.  I don’t see that happening anytime soon for a few reasons:

1. It isn’t really Google’s intent to build a BPMS.  They don’t think of the problem Wave is solving as a “process”.  As a result, they’re unlikely to take it in that direction.  I don’t think you end up with a good BPMS my accident.
2. The structured parts of process are actually useful for larger organizations that actually have that kind of structure or volume.
3. There is a lot of magic under the hood of a BPMS that wouldn’t be trivial to recreate using Wave.  Not impossible, just not trivial.  More likely is a mash-up approach like the SAP Gravity demonstration.
4. It still sits outside the firewall of the corporation, and for all too many companies, that is still a regulatory problem, not to mention a security problem, for their data.

Having said all of that, Google Wave presents itself as an alternative for collaborating on processes to email, Sharepoint, Excel, and Notes.  I also think the real disruptive threat that Wave poses in the BPM space is to vendors that focus exclusively on the unstructured, user-specified processes – these seem like the lowest hanging fruit to capture in Wave.  On the other hand, I can see Wave being fertile ground for tools that inspect your systems to find out what processes you’ve *actually* been running by inspecting the data, rather than starting with a top-down design.  These tools may have a massive new datasource to mine for their customers, assuming Google makes the data available.

The concept of “Dynamic BPM”, when explained, is certainly useful.  But I’m not much of a fan of the term itself.  First, it is yet another buzzword that means whatever the vendor du jour says it means.  So all the vendors immediately do “Dynamic BPM” and incorporate it into their messaging.  IBM says that they do “Dynamic BPM” by automatically configuring the process in real-time (or read their own words here).  Oracle says they do “Dynamic BPM” by incorporating rules-driven process flows, dynamic service binding, and task management.  At recent BPM conferences, Dynamic BPM has been used to refer to “knowledge worker processes” or pieces of the process that can not be well-defined in advance (Anatoly Belychook’s blog describes this interpretation quite well, as well as a couple of useful design patterns within it).

Here’s where I see problems:

1. This name “Dynamic BPM” doesn’t really mean anything – each vendor can make up a definition that suits their software, or their competitive positioning needs in current sales cycles.  This just extends the already ambiguous use of the term “BPM”.
2. IBM’s notion of “dynamic” is really more about configuring the process based on early inputs to the process instance about its requirements.  A process that can’t do this doesn’t seem worth much to me.  BPM tools have been doing this sort of thing (in abstract) for at least 7 years.  However, they do have some technology to handle more complex factors (especially with respect to health care related industries).  My favorite part about IBM’s description of “previous BPM solutions” is that they “weren’t designed with agility and dynamicity [sic] in mind”.  That’s the kind of presumption you hear from someone writing product marketing content who hasn’t worked with those “previous BPM solutions” in the field (which, I can assure you, were often designed to be agile and dynamic).
3. Oracle seems to think if you have rules then you have “dynamic BPM”.  Last I checked, rules aren’t the future of BPM, rules have been around for decades as a business-enabling technology.  Applying rules to BPM isn’t exactly a new idea.  Just ask any of the former rules vendors, or Pega.
4. Dynamic BPM as a substitute name for “unstructured process” or unstructured subprocesses is more along the lines of Anatoly’s blog.  Its also the positioning of ActionBase and a few other vendors.  The issue here isn’t a “can you or can’t you” model unstructured process as part of an overall structured process – the question is how much does the BPM vendor’s software help you model or execute such processes.  Some BPM solutions help quite a bit (e.g. ActionBase), some help a little, some just don’t get in the way, and some don’t allow for this style of subprocess at all.

I think BPM Vendors need to keep focused on what their products do for business. A term like “Dynamic BPM” doesn’t tell me anything about what this feature or product will do for my business.  That’s not a surprise when the tail is wagging the dog (selling software to IT with IT benefits, rather than selling IT to business with business benefits).  Let’s drop the IT buzzword bingo and focus on what the business needs, shall we?

Recently read the post (and watched the screencast) on Intalio’s blog about their new “Process Table” feature.  The basic idea is that you use a spreadsheet to define your process, and then have the software “auto-magically” produce a running, executable process for you (screens and all). Interestingly, I saw something similar in Lombardi’s labs when I was an employee there, one of the “science fair” projects that one of my colleagues was showing off.  Not sure what happened to it as far as a shipping product idea, but it sure made for a neat demonstration.

I think in this family of product ideas, however, ActionBase (Click on the “take the tour” link) has a better answer.  At least, if you’re going to the depth of comparing one web video demonstration to another (admittedly not up to Dennis Byron’s standards of research!).  ActionBase proposes using Word and Email to create processes “on the fly” and relies on the software to manage the hand-offs for you.  However, ActionBase also appears to let the process adapt as it is running, if someone is assigned a task and needs to add additional items to the process flow.

Both of these ideas address processes that have lightweight technology requirements but very real process requirements.  Both pure-play and stack vendors would do well to provide better support for such scenarios, but its even more important for the pure-plays because they’re more concerned with directly assessing and meeting the needs of the business, rather than just IT.  IT-led projects won’t be as interested in “process-lite” style approaches like this, but in reality it is a great way to start extracting process out of the email stream or the spreadsheet-hand-off scenario…