I know Kevin’s article was targeted at web analytics, rather than, more generally, business analytics – but the points he makes are entirely valid for business analytics – and business process analytics:

We analyzed each promotion code, using “A/B” test panels. Customers were randomly selected from the population, and then assigned to one of two test panels. The first test panel received the promotion, the second test panel did not receive the promotion. [...]

In almost all cases, the segment receiving the promotion generated more profit than the control segment. [...]

Being a huge fan of “A/B” testing, I decided to try something different. I asked my circulation team to choose two customer groups at random from our housefile. One group would receive promotions for the next six months, if the customer was eligible to receive the promotion. The other group would not receive a single promotion for the next six months. At the end of the six month test period, we would determine which strategy yielded the most profit.

At the end of six months, we observed a surprising outcome. The test group that received no promotions spent the exact same amount of money that the group receiving all promotions spent. After calculating the profitability of each test group, it was obvious that Eddie Bauer was making a significant mistake. [...]

In 1999, we backed off of almost all of our housefile promotions. At the end of 1999, the website/catalog division enjoyed the most profitable year in the history of the business.

This is a classic cautionary tale for anyone measuring business processes and looking for improvements.  In process improvement, often an efficiency gain comes at the cost of customer satisfaction – which is why many businesses now manage to a “double bottom line” or use extremely customer-focused culture to counter-act that tendency.  In the case above, they’re looking at how incentives shape behavior. The thought process is equally valid for customers as it is for internal staff incentives. Do the incentives actually drive better behavior or just more short-term-optimized behavior?

Kevin goes on to recommend several remedies, most of which revolve around having a longer term view of things.  Well. Imagine that.  Good read.

We had a great success with the original bpmCamp @ Stanford in January, this year.  We’re now ready to start the ball rolling for a bpmCamp in Austin.  We’re just at the formative stages, but we are targeting dates in October, and currently scouting locations in Austin.  We’ve also had tentative discussions with Stanford about having another bpmCamp at Stanford, but a bit later in the year 2011 (maybe even in the summer of 2011). Our goals and thought process are much the same as last time:

1. BPM Conferences are good, but BPM Conferences are (usually) too general, too big, too expensive, and stuck on platitudes because of the above.
2. bpmCamp is intimate. It was 40 people (max capacity) at Stanford.  We’ll figure out our max capacity for Austin, it might be just a tad bigger.
3. bpmCamp is specific.  We will be focused on the Lombardi Software products acquired by IBM earlier this year, and now known as IBM BPM Blueprint (aka Blueprint), and Websphere Lombardi Edition (aka Lombardi Edition aka Teamworks).  (We would welcome the chance to organize a bpmCamp for another product offering – but we need a partner to help)
4. bpmCamp is affordable.  Exact price is TBD, but it won’t break your budget.
5. bpmCamp is focused on what attendees care about.  Topics are crowd-sourced, so anyone attending can help shape the agenda.

If you’re interested in attending, watch this space, or keep an eye on posts with the tag bpmCamp. If you’re interested in sponsoring bpmCamp, we’ll have more details about that soon.

If you have any questions in the meantime, contact us at:
bpmCamp Email:

(editor’s note: bpmCamp is not affiliated with or sponsored by IBM.  bp3 is not acting on IBM’s behalf, nor is bp3 an affiliate nor subsidiary of IBM. )

I’ve previously written about Apple’s need to step up their level of service, using luxury car service shops as an example.  Apple Insider has a story about Apple rolling out business-friendly, or at least small-business-friendly, services to its retail stores:

Apple is said to have at least one salesperson dedicated to managing accounts with local businesses, and has also recently begun recruiting within its sales staff to create a team that negotiates leasing and pricing terms for business clients. People familiar with the company’s plans said the strategy has proven successful, as some stores have seen their revenue more than double after implementing the program.

Well, it is brilliant to leverage the retail outlets as a differentiator for small-business-owners, who might prefer to just pop into the Apple store for something rather than ship their laptop off to a repair center. However, if that is going to be a differentiator, Apple still needs to address services like in-store repair rather than shipping off your laptop, or else provide reasonable loaner programs.  Providing discounts to small businesses is a smart way to get some buyers off the fence, who might have only been holding back over pricing concerns.

But the real value is value-added services for businesses: that’s what creates lock-in.  And, if possible, leveraging the install base of Apple Stores to differentiate.  Given how crowded these spaces are already, however, it may require rethinking how much square footage is needed in a typical Apple Store to provide the full range of services.

Congratulations to local Austin Software company Zilliant, which just raised $13M in a Series G financing round.  Zilliant was founded in 1999 by a group of people that includes a few former colleagues.  And I still have some friends working there. Thanks to Austin Startup for breaking the story (for me at least).

Zilliant’s software helps companies optimize their pricing.  If there is a process for pricing – and I’m confident there is – it is folks like Zilliant and Mimiran that will figure it out in specialized software. At the very least, they’ll figure out the hard part (optimum price).  It looks like the surrounding process of signaling, proposing, refining, approving, and rolling out pricing changes is also being targeted by these packages.  You might call it BPM for Pricing…

IBM’s BPM Blueprint folks recently posted a short video that shows how to create a “join” in a process.  Its a painless video to watch because it is in double-time, but it definitely exposes an opportunity for improvement in how one goes about modeling joins.

It relates to our previous post on process patterns. This video simply shows how to leverage a basic BPMN construct (the join) in a specific collaboration and modeling tool (blueprint). But this is also one of the van der Aalst “patterns”, that, as I mentioned previously, I’d rather call construct than pattern. And I think everyone would benefit if we start to discuss patterns with more useful abstractions embedded.

Dr. Stein of Aris has a blog about workflow patterns in BPMN2:

“In many areas, patterns are used to codify best practices. A pattern describes a solution for a problem. Originally, patterns were used in architecture to describe architectural design ideas. In software engineering, patterns are used to describe typical software design solutions, for example like client-server architecture.

In business process management, the so called workflow patterns by Prof. van der Aalst and friends exist. In their original description, they described the most important 20 workflow constructs like loops, decisions, and sequence flows. Later, Prof. van der Aalst and other research fellows extended the list of patterns and revised the initial description (see workflow pattern homepage). Still, the original 20 workflow patterns are valid and a useful tool to learn a modelling language such as BPMN.”

I’m just not excited about the van der Aalst “patterns” that are oft-quoted in BPM circles. The more accurate statement is that they are snippets of BPMN that demonstrate how various “constructs” work.  They’re useful demonstrations of how BPMN can work, and how to use a particular tool to diagram specific constructs.  And the work of van der Aalst and colleagues was very useful as well in identifying edge case diagrams that expose tricky aspects of the notation’s execution semantics.  They are not, truly, patterns as I would think of them.  Showing three activities executing in a sequence is hardly a “pattern” any more than three lines of code that execute in a row are a pattern.  Splits and joins are just constructs of the notation. The patterns don’t identify the usefulness of the pattern or the “why you would want to do this” aspect.  In that sense, they largely fall short of the bar for a pattern in my book.  A typical name for a “pattern” in this study : “Multiple Instances without Synchronization”… huh?  A name only a parent could love.  What’s the business case for this that helps me understand how it relates to business process? There isn’t one.  The point of these patterns, documented here, is to identify technical edge cases and compliance, not to create patterns that you will base your actual design work off of … and maybe that’s my main complaint.

The “four eyes” pattern is a pattern (where n-1 potential reviewers have to approve something before it moves on).  There are lots of real patterns out there – and generally they’ll get names that make sense- an “observer” pattern, the “shadow process” pattern, etc.  Having voiced my complaint, maybe I need to take some time to document a few BPMN2 style patterns to clarify.  Anatoly Belychook has described a few on his blog, in the past (as well as anti-patterns).

Ben Farrell of Appian notes on their blog recently:

Dealing with varying levels of security requirements in ramping up new federal employees and contractors is a common pain. It is usually handled through manual, paper-based processes involving lots of documentation to be passed around, verified and tracked across multiple systems. This means major time and effort for the staff performing the processing, and delays in getting new hires into a productive work mode.

Other process areas common across government organizations include things like Procurement and Sourcing, Program Planning, Budgeting and Management, Grants Management, and a variety of HR processes. Not coincidentally, these are areas where Appian is seeing great success.

BPM software helps the federal government solve pervasive cost and productivity problems – and not in the “tried-and-failed” approach of commercial off-the-shelf software packages that cause as many headaches as they solve thanks to rigid coding. While attacking an area of common concern, BPM solutions are easily configurable – by business users – to the unique requirements of an individual agency.

I’m not an expert on which BPM vendors have market share in the Government space (it is hard to measure this kind of “market share”), but being based in or near DC doesn’t hurt Appian’s chances.  And as probably every BPM practitioner has noted, BPM is what the government needs – processes that don’t get lost in the paper stack on someone’s desk, processes that proactively notify participants about progress within the process, and processes that have consistent performance.  Ask anyone who has gone through the green card application process and you will get a story of broken processes – or at the very least, broken visibility (the applicants rarely have any sense how far along they are in the process).

One interesting note from Ben’s post on cloud computing:

There will be more to come on government adoption of BPM in the Cloud. For now, I’ll close with a reminder about why BPM in the government really matters: every one of us, as taxpayers and consumers of government services, benefits when government operations are conducted more efficiently and effectively.

Government adoption of cloud computing is interesting.  I think most people assume that most government functions won’t be in the cloud – but clearly some could be.

BPM Guide has some examples of BPMN 2.0 diagrams, on the heels of Stephen White’s blog post that the BPMN 2.0 spec has been ratified by OMG.  Thanks to Jakob Freund for publishing them.There are a couple of key points that Jakob makes throughout the article, that I’d like to call attention to:

Creating process models for both business AND it is actually one of the absolutely main topics of our consulting business. And it is a very big struggle, of course. For us it was important to show in the document that BPMN is not necessarily “too complicated for business”, because it totally depends on how you actually use the standard when process modeling. That’s why we always need a Framework around BPMN if we want to apply it in bigger modeling engagements.

This is a well-said point – BPMN doesn’t have to be too complicated for the business. But drawing diagrams that are not more complicated than they have to be takes some skill and practice.  I often tell people who aren’t familiar with BPM that it takes a reasonable degree of abstract thinking to really do well.  It is the abstractions and generalizations afforded by a process and its subprocesses that comprise the solution.

Apparently they built these examples with Trisotech’s tools:

The diagrams in the examples document however are all made with Trisotech’s Visio-based BPMN Modeler, provided for this purpose by Denis Gagné. The cool thing is that we could directly serialize the diagrams into BPMN 2.0 XML with that tool.

Denis, where is this tool! Sounds interesting!

Jakob also gives interesting examples of how to take advantage of collaboration diagrams.  His final thoughts:

Make a “strategic” process diagram (Figure 6.1), just a simple sketch for a quick understanding

Make an “operational” process diagram (Figure 6.2) for analyzing the collaborational aspects

Enrich the diagram with the aspects of a process engine, therefore adding a pool for the process engine

Take that process engine pool into your technical environment and enrich it for execution (make a “technical” process diagram).

Good advice for how to approach modeling in BPMN.

In a previous post, I argued that (contrary to Alain Breillatt’s expert perspective) Apple’s approach to product actually saves money rather than “wastes” money.  What most people would look at as waste, I would look at as costly-wrong-turn-avoided.  If you understand the arguments behind technical debt or process debt, the idea that a bad design (or more than the minimum necessary number of designs) is expensive makes perfect sense.  This argument was an exercise in looking at the R&D process around one future product – the 10:3:1 ratio of product design weed-outs, for example.  In another post, we looked at the big picture R&D spending versus revenue and profit growth – and in this wide angle lens, it is hard to argue with the idea that Apple’s R&D is quite efficient.

Recent events and a few good blog posts bring some additional data and perspective to bear on this.  First, we have the Tyner Blaine post, The High Costs of Building the Wrong Product, which is a fantastic explanation of the concepts discussed between myself and Alain Breillatt.  As Scott Sehlhorst writes for Tyner Blaine:

There’s an analog to the market dynamics of making poor product decisions – executing with poor quality. Many research studies and articles have identified the market impacts of poor quality.  This has become so well accepted that people today cite it like a law of physics (one example here based on this 1988 IEEE research by Barry Boehm and Philip Papaccio) as the “1-10-100 rule.”  The primary conclusion of that research is that ten dollars spent on fixing bugs:

• Costs and saves $10 when you catch (and fix) the bug during implementation.
• Avoids $100 in costs when you catch the bug during QA and send the product back to development (then test again).
• Avoids $1,000 in costs versus waiting until your customers catch the bug in the field, causing the team to remedy the problems, rush out a patch release, and/or go to heroic lengths to manage a PR problem.

This is an opportunity in front of your product team – a 100x payback from investing in quality during the development process.  Of course, be pragmatic about it – if the cost of testing exceeds the cost of bugs, don’t test.

We just recently witnessed the cost of a “bug” in the final version of a very popular product.  Apple has taken it on the chin in PR because of this.  Imagine the launch coverage absent this issue – the press and blog coverage would have found something to complain about, but this issue was almost too easy for them to focus on.

Now, imagine that Apple had developed, say, one of the many bad Android phones.  There are Android phones that review well.  But had Apple wasted the resources to build one of the ones that wasn’t good – that is quite a cost, isn’t it?  To reputation for one.  But there are marketing costs, support costs, potentially recall costs (analysts were estimating north of $1B in recall costs to Apple if it came to that). The Droid X is already getting criticism for its bad User Interface (allegedly, worse than the default Android 2.1 interface – though I don’t claim to be an expert on that).  What is the cost to Moto’s business to develop “a bad product” or, a product with a few really bad bugs?  People often compare Apple to “Android” – but actually each Android handset maker is a separate competitor.  Each one has to invest significant energy into developing their handsets.  As long as Apple has significant volume advantages over any single competitor, they should enjoy economies of scale that the other manufacturers don’t.

TechCrunch has an excellent article detailing Apple’s surprising vertical integration benefit. I say surprising, because in economics we’re generally taught that vertical integration is less efficient than specialization.  Apple seems to buck that trend.  Steve Cheney writes:

Perhaps the best example of this so far is FaceTime, Apple’s take on video-calling. FaceTime makes video-calling on the Android-based Sprint HTC EVO look silly, because the EVO awkwardly requires users to sign up and download a third-party app, then launch it every time they want to talk. Normal people simply won’t do this.

Apple eliminated this friction by innovating at the confluence of hardware and software—hit one button mid-call and the feature just works. It really is amazing (yes, I am channeling Steve Jobs).

Once Apple does release a product, they really know how to market it.  In this FaceTime ad compaign, they do a great job of not marketing technical specs and instead marketing human value.  This is what makes the difference between evangelizing your product and just geeking out.  Not every body likes it – but think back to when the iPod commercials were ubiquitous.  They didn’t market the # of songs so much, nor the quality of the build (though it was high), nor the RAM, nor the CPU speed.  They marketed people dancing in their heads while going about their every day life (the shadows are dancing while the person calmly walks to the subway).  Sell the benefit, sell the humanity.

Back to the TechCrunch article… the author argues that Apple actually benefits from feature bloat in component vendors.  For one, they get to strip out unnecessary features from their designs (which aids battery life, for example).  For another, Apple gets an inside track view of what is coming down the pipeline in these components that their competitors depend upon.  And then Apple has degrees of freedom to decide how to respond.

Good food for thought for anyone running a product business.

Well, I just read an article I really found agreement with:

Jeff Kaplan of Think Strategies writes “Yes – the SaaS Experiment is Over“, in response to an article asking if the SAAS experiment was over, and a second one on ebizQ that asked “Is SaaS Dead?”

The fact is that the SaaS ‘experiment’ is definitely over. It is now a mainstream movement.

Just take a look at the growth of Salesforce.com and SuccessFactors. Or, check out how NetSuite and Workday are encroaching on SAP. Listen to CIOs who are frustrated with being in the server business and want to shift into the services business.

And, pay attention to the major moves which the ‘legacy’ hardware and software players–led by IBM, HP, Microsoft, Oracle and SAP–are taking to transform and even cannibalize their traditional business to respond to rapidly escalating customer demands for change.

Yes, the SaaS experiment is over. It is now for real.

I agree. SaaS is past the “experiment stage” and on to the implementation stage across nearly all forms of software.  Hardly dead.

Meanwhile, last year there were calls for BPM’s death, and asking if our experiment with BPM is over. My personal experience with BPM argues otherwise.

This seems like a great BPM Thought for the Day from John Reynolds:

Just came across this short but sweet posting from David Novick:
BPM consultants should be SME’s in… well BPM

David’s “point” is that it’s our skill at approaching problems from the Process Perspective that provides true value to our clients.  The details of the business problems are known by our clients – Our skill is in knowing how to develop solutions for those problems through process analysis and process management.

Its a great thought.  Be a subject matter expert in BPM.  That is, after all, what our customers are asking from us.

Chris Adams, VP of Product and Technology at Ultimus:

Despite all of the recent recognition of processes being dynamic in the Business Process Management (BPM) / Adaptive Case Management (ACM) spaces, the majority of processes in business have ALWAYS been unstructured.  [...]

Thinking back to the inception of automated processes, the reason why workflow technology came first, arguably, is that it is “low hanging fruit”.  Like with any large project across the enterprise, the concept of starting small and growing from initial successes is a well understood strategy to achieve large scale success.

Chris depicts workflow as the lowest hanging fruit, structured processes as the middle fruit, and unstructured as the highest fruit to attain.

From reading his post, it sounds as if he’s saying that unstructured is harder, technically, to implement than workflow or structured processes.  However, unstructured is actually easier, technically speaking.  Businesses have been performing their unstructured processes for years – using email, for example.  Or Lotus Notes applications.  Or SharePoint.  We can argue whether any  of these were good solutions – but my point is just that even the ways in which these products fall short are not hard technical issues to resolve (if only the folks who write email software and the like actually cared about processes as a target).

Unstructured processes are “not low hanging fruit” due to organizational barriers, not technical barriers.  Processes that cross organizational boundaries run into resistance.  There will be users who worry that software will over-constrain their free-wheeling unstructured process – like the Borg assimilation routine. No one wants to feel like a Borg automaton.  But there are times when process *should* cross organizational boundaries – whether structured or unstructured.

Mike Gammage points out that a recent Gartner report touts BPA for the masses, but fails to understand how absurd that sounds:

Within this context, how can BPA possibly be an activity for the masses? This kind of analysis is understood and undertaken by a small group of IT specialists.

Each kitchen has only a small cadre of pastry chefs. Diners, waiters, the maitre d’ – they may all be involved in continuously improving the mille feuille aux amandes – but it’s the pastry chefs alone who sift the flour and need the rolling pin.

I think Gartner may have, in this instance, gotten tools and work confused.  Some of the tools they are reviewing (BPM Blueprint, and ARISalign) are designed for the masses – but not to turn the masses into BPAs.  The goal is to turn the masses of business users into real participants in continuous process improvement.  Of course, they have features to support BPA activities – but those particular features are primarily intended to support the analysts, not the “masses”.

A while back, Bruce Silver wrote up another thorough review of a BPM vendor’s offering, and this time it was TIBCO’s ActiveMatrix BPM.  There were a couple of nuggets that jumped out at me:

1. TIBCO is pushing task distribution as being separate from process (or orthogonal, you might say).  It is an interesting wrinkle to their product.  I’ve run into a few cases where the “process” presented to me was really a “how to distribute work to the people on this team” problem, rather than how to manage the process or lifecycle of the stuff their working on (which might extend into groups that aren’t part of the same team).  But there have been only a few, relative to the total number of processes I’ve seen.
2. Apparently they borrowed one of the best features of Lombardi Teamworks (now Websphere Lombardi Edition): “The inline preview function allows playback of running forms from within TIBCO Business Studio.   This Lombardi-ish approach is carried forward in page flow modeling as well, using BPMN to describe each step in the page flow… an advantage (in my view) over the programmer-oriented approach of most ‘enterprise-class’ BPMSs.”
3. It sounds like they’ve added performance data tracking that approaches what Lombardi does.  I’ve been surprised that this early differentiator at Lombardi (circa 2004) hasn’t been more widely copied 6 years later.
4. There was another TIBCO BPM product, but I think that’s on the way out based on TUCON coverage.  BPM vendors need to take a page from Neil Ward-Dutton’s blog.  Bring your customers with you.

Thanks again to Bruce for covering all the product releases of note.

Keith Swenson has another post where he compares Case Management to BPM:

“The two approaches are very different:

• Sherlock Holmes will use a case management approach, not a BPM approach, when solving a case.
• Bank of America will use a BPM approach, not a case management approach, to support signing up people for new regular accounts.
• Admiral Thad Allen will use a case management approach, not a BPM approach, when responding to the oil disaster.
• Amazon will use a BPM approach, not a case management approach, to handling sales of common books.”

I’d propose another example:  I sure wish BP had been using a BPM approach on that oil rig, rather than a case management approach that allowed winging it with decisions like whether or not to use drilling mud.  I wish there had been a little more BPM going on in the mortgage business pre 2008 – not just signing up new accounts but making sure that customers actually met credit and income requirements.

I think there are more than just mundane examples of where a little more BPM would be a good thing.

Keith has another interesting comment:

To say that these approaches are the same, because they both help to get work done, ignores the very essence of BPM and case management. Yes, they are both techniques to help accomplish work, but they achieve this result through different means.

[...]

This has nothing to do with any vendor’s product. I am not making a sales pitch here. Those that say their favorite BPMS can do all of this are simply pointing out that these two management practices can be supported with similar technology – and many products will support both approaches. But remember, BPM, and Adaptive Case Management are not technology, not products. They are both approaches to managing work.

Interestingly, because they are both approaches to managing work, the same people are likely to be involved in both approaches.  One can argue about which approach “wraps” the other approach, but as BPM is an amalgamation of techniques and approaches, the question (to me) is whether case management is just another one of those, or whether it is a whole “methodology” unto itself.  A relevant example:  Six Sigma and Lean are examples of different approaches to process improvement that, today, most people lump together because they both represent useful sets of tools for the same set of people engaged in process improvement.

Steve Wood, in the comments, captures my thoughts well:

“So, for example, when I look at how an agent supports a customer through an issue. At the high level, it’s very BPM-like, at the implementation level it’s very hybrid. I can optimize some tactical processes to improve performance and also optimize tactical experiences to improve case management.”

And of course, Max J Pucher has a well-worded  comment also:

“Analytic knowledge provides conversation pieces but no practical how-to knowledge and is thus quite useless.

The ‘war of who owns ‘adaptive cases’ is thus quite senseless. I do agree that I am chasing windmills in asking for a common sense approach, but at that is also the reason why the question whether BPM, ECM, E20 or ACM will bring adaptiveness won’t be agreed upon.”

Its an interesting read in the discussion / comments and the wealth of different perspectives – even from people who co-authored “Mastering the Unpredictable”.  Unfortunately, as with most of these discussions, there is a little too much focus on the arbitrary limitations of software tools (the specific experiences of the authors with either specific ACM or BPM tools), rather than sticking to Keith’s original premise that we’re talking about two different kinds of work, but it is a small blemish on a good discussion.

I don’t catch all of the updates to Blueprint, but I did see this one go past my inbox.  Once again, the folks from Lombardi (now IBM) have kept turning the crank on incremental improvement in Blueprint.  I believe this is the second update since IBM finalized its purchase of Lombardi in February.

In this iteration, attention to the news feed and the “follow” feature have been added, along with other minor fixes and enhancements.  The follow feature in particular is useful across a bigger organization with a lot of modeling and collaboration going on.  It is a great example of a “social” feature making it into a design environment:  you can now “follow” just about anything in Blueprint, to keep up to speed with changes in processes that you care about.

Of course, my first thought when I see this is – I want this in Websphere Lombardi Edition – the process implementation product suite that goes with Blueprint and came along with Lombardi in the acquisition.  I want this kind of functionality for the runtime as well – the ability to “follow” just about anything I might interact with – processes, tasks, users…

Overall I like the changes, looking forward to more improvements…

As with several previous posts from Mr. Ukelson, I really like this one, about Process Simplicity.  Simplifying and Simplicity have been themes of late- because what software needs, and specifically what BPM needs – is deeper thinking into how it is surfaced to those of us who use it.

I also like how Mr. Ukelson focuses on what his product can do for the business, and not about whether it is BPM or ACM or something else.  He offers a definition of BPM as the “discipline of making work processes simpler”, which leads to interesting conclusions and points of comparison.

I agree with the philosophy of making work processes simpler, though you could say “making work simpler” because not every participant of a process will perceive it to be a process – to that person it may look like a single action or reaction, or a case.

Finally Law 10 – This is an interesting law from a BPM perspective – isn’t BPM about exposing and codifying the routine (which is version of the obvious)? So maybe BPM’s job is to lay the groundwork so we can get to Law 10 in business processes, and something else will need to come along enabling the next step towards Law 10.

(law 10 was “Simplicity is about subtracting the obvious, and adding the meaningful.”)

I think Mr. Ukelson may be on to something.  And I think his characterization of the BPM/ACM debate is one of the better “framings” of the discussion that I’ve seen.  Not that that won’t stop anyone from disagreeing with me… please comment!

Keith has an excellent post in the form of a Q&A session, as a followup to an ebizQ recorded session that didn’t have time to address all the questions that came in.

Some choice quotes:

The knowledge worker supporting “planning by doing” approach is less about up front definitions of a process.  In general it seems to me that rule sets are primarily useful in order to clearly specify an automated response, and must be prepared ahead of time.  It is hard to see how you would use such rules when directly performing the work.

I can imagine someone defining fairly trivial rules – such as requiring approval above a certain $ threshold after delegating some work to someone else, and deciding that “on the fly”.  But as he says, “in general” the whole point of rules is to address rules at design time, rather than on the fly at run-time (other than by executing the rule)…

4. HOW DOES THE CONCEPT OF A SERVICE ORIENTED BUSINESS APPLICATION(SOBA) RELATED TO SOCIAL BPM, IF AT ALL?
SOA is an orthogonal concept to BPM in general — although there is a widespread misunderstanding about them being similar or the same thing.

Agreed.

Q&A #7 was particularly well-done, as it relates to something Keith has been thinking or writing about a lot lately – unpredictable work and how to track it or measure it – too long to quote here, but please link over to Keith’s page and read it.  He breaks down at least 4 approaches to tracking unpredictable work for the purpose of better understanding it and improving it.

Keith has one more anecdote I had to quote because it is mind-boggling in hindsight:

I remember a friend who was at a company that was acquired by Computer Associates in the 1990′s.  At that time, CA ran an email system, but they allowed access to it only at lunchtime and after hours.  You see, nobody was allowed to access email “during working hours”.

Well, I think it is safe to say that “social” is facing some of the same challenges in the workplace today.  But 15-20 years from now people will look back and wonder that companies weren’t more encouraging of tools like Twitter and others to get work done.

Frank Michael Kraft has written a series of good reads on Knowledge Work, and this one is no exception.  In this post, he finds patterns of knowledge work:

This – in my opinion – is one pattern of knowledge work: the repackaging of parts of cases into a new case. But as I think I found out there are more.  [...] How did I find them? I did not do a scientific analysis, I admit. [... ] I had three sources for it:

1.  Managing my own knowledge work. As I wrote my own Adaptive Case Management system for my own knowledge work, I was able to organize my own work. As the number of cases increase – 3000 now including sub-cases – I become aware of patterns.
2.  Feedback from my first pilot. This was very interesting, because the main focus for my pilot is usability. Usability is strongly interwoven with these patterns of knowledge work.
3.  The things I always wanted to model, but never was able to. I governed the modeling of thousands of models of structured processes from all areas of business processes. But because the modeling language was only able to model predictable processes, I never was able to model unpredictable processes.

So when does a pattern start to look like a process?

Neil Ward-Dutton of MWD Advisors recently put this quite well, when discussing how two major customers of Oracle and Tibco’s respective BPM solutions feel about the impressive new releases from these firms:

Nevertheless it’s not necessarily the case that TIBCO and Oracle customers are punching the air with excitement about the new stuff. Both companies I spoke to have made very significant investments in earlier versions of these technologies and now see their investments as important to protect. Their investments haven’t only been in software licenses but also in skills – and protecting these sunk investments is at least as important for them as finding out what the new stuff can do.

In both cases there are question marks about how easy it will be to migrate existing investments from the ‘old’ platform to the new offering. Of course all enterprise software vendors say they’ll support previous versions of tools for existing customers, but there’s a difference between continuing to fix bugs and actually helping a customer protect the value of an existing investment into the future.

I think it is high time that commercial software vendors do a better job supporting transitions from old-to-new.  At the very least, sponsor (and invest in) an open-source project to help customers make the transition.  At best, build the right bridges to get customers from version 2 to version 3 in a meaningful way that protects their investment in software.  And if you release a new “BPM” product with different DNA than the original product, you still owe it to your customers to figure out how to bring them along with you.  They shouldn’t have to scrap their original investment to use the new tooling.

Software vendors, in general, require too much of customers when they roll out new software, and especially when they do a major refactoring of their software offering.  It is especially noticeable in the BPM space at the moment as stack vendors incorporate and digest the pure-play vendors they’ve purchased.  I’ll be interested to see if IBM can release the upgrade package promised to Lombardi customers that brings Teamworks 6 customers into the world of Websphere Lombardi Edition (previously known as Teamworks 7).

As Neil asks: is there a process for that?  There should be…