Great interview of Ron Johnson, the new JC Penney CEO, by Seattle Times… In it, Ron pointed out the stores he admires – Whole Foods and Starbucks, and why:

Q. Other than Apple, which stores do you admire?
A. I admire lots of stores. Whole Foods is a great store. I just like their passion for food. It shows up in everything they do. It shows up in their packaging, their presentation and their employees. Starbucks. It truly has created a community. As I travel around the world, I just know that if I go to Starbucks I will have a great experience.

He’s right -Whole Foods is almost the sale of groceries art form.  Starbucks has an incredibly consistent experience.  These are two companies with a very strong process culture.  Ron focuses on the end result (the store experience), but it is deeper than that -  these companies also go deep into their supply chain and understand the origins of everything they’re selling (and then use their buying power to influence the supply chain).  When you motivate that process-focus with a passion for the product (organic food, or coffee), the results seem to be much better than passion without process, or process without passion.  It is almost impossible to tell whether process-focus led to a designed-in passion for food and coffee (to achieve the desired result) or whether passion for the food/coffee drove the focus on process in order to achieve the goal.  But the two together are a powerful tool for a big company to drive excellence.

Another part got my attention:

Q. What ideals have you embraced from Steve Jobs?

A. The importance of doing everything you do to your very best. And that the journey is the reward. If you do things well one at a time, you end up in a really good place. Don’t get ahead of yourself. Control the things you can.

The Apple approach to building a relationship with the customer starts with doing each of the little things really well.  Being a retailer, perhaps “each of the little things” doesn’t start with designing product, but for sure JC Penney has to be looking at design of stores, pricing, brand presentation, and customer service.  I have such a negative opinion of the JC Penney brand, that it is hard for me to imagine shopping there for any reason, for any product.  Literally, it is hard to conceive.

Yet reading this interview, I’m rooting for Ron.  He gets it.  If anyone can turn this around, he can.  But I’d be more inclined to shop there if the name were changed to “Ron Johnson’s” instead of JC Penney.

Getting introspective for a moment – is your organization getting better, one thing at a time?  Are you prioritizing to address the most important things first – but without forgetting about the little things?  Are you distracted by trying to do or change too many things at once? Are you marrying passion and process and following where that leads you in your business?

There aren’t quite as many independent BPM software vendors to report on these days, but I still try to keep track of their financial performance because it still seems that the overall trend is up and to the right – apparently the market still hasn’t gotten too crowded for more than one vendor to be successful. And of course I’m always looking for confirmation (or exceptions) to that trend.

Appian reported “record growth in 2011″ the other day with some key statistics:

• 90 new-name customers
• 219% YoY license order increase for Appian BPM Software
• Appian Cloud represented 37% of their total license orders in 2011
• Highlighted new customers include several government agencies.

The press release goes on to describe Appian’s mobile BPM offering and several industry awards they won over the course of 2011.  Appian’s press release and blog certainly support the thesis that BPM still has room to grow.

But what I find interesting is the wordsmithing of what seem like otherwise healthy numbers:

• “90 new-name customers”  – how is a customer defined, then? As a department, subsidiary, purchasing group, or corporate entity?  (the use of new-name rather than just “new customers” makes one wonder what the caveat is).
• 219% year-over-year license growth sounds fantastic. But then they added another word – they didn’t actually say license dollars, they said “license order increase”.  An increase in orders could happen if you lowered the price to free, which isn’t nearly as interesting as a 219% year-over-year revenue increase in license dollars.
• I’m surprised the 37% cloud customers is as low as it is.

My beef isn’t that the numbers are good – they’re great numbers, but part of the value of a number is the context.  If Appian grew license revenue 219% why didn’t they just say so?  So if they didn’t just say so, then why did they feel the need to trump up the numbers by obscuring which metric they’re really reporting? It just isn’t necessary.

This isn’t a problem unique to small private companies though.  Just the other day Google reported some misleading vanity metrics about Google+.  The effect of using these misleading figures though was to undermine their credibility rather than enhance it.

This odd cherry picking of metrics isn’t new however, 6 months ago Appian reported “Sales orders for the Appian BPM Suite grew 158%” – again, orders, not revenue.

Of course, as a private firm, they don’t have to report anything, but if your business is growing it is hard to resist crowing about it at least a little! But I would encourage private companies reporting metrics to use plain words in what ever language you need to get through to your audience.  Finessing the terminology only undermines credibility.

Editor’s note: This is reposted with permission of the Author.  Gary Samuelson’s original post can be found here.

Forward

If you haven’t already done so I highly recommend you “tool up” for iOS (iPhone) or Android development. Speaking more on the Android platform with this point, but Android is based on Linux – meaning that the Android “smartphone” is a small, pocket-sized Linux computer. And, behind this tiny, touch-screen UI, we have an event-driven framework suited for wireless IO (communication) and  distributed client (end-user) services. This makes a good fit for BPM mobility as it applies focused, via platform constraints, user-to-process interaction.

So, in warming up to enterprise-scale BPM Mobility, I want to first walk through a few system architectures – this prior to diving into the details of Android computing. Goal being a build-up towards mobile device UI/IO requirements: from current state to future capabilities.

BPM Desktop Client: Web-portal, JSP Struts/Tiles

The portal has been with BPM practically from the very beginning and it exists today mostly in its original form as a JSP STRUTS/Tiles web-application.

Though somewhat dated in its technology, we must give credit as it has been and still is the BPM workhorse: delivering process execution, management, tracking, and reporting to our end-users. However, the portal leaves us wanting. Today’s users require a “rich web” experience – something beyond the reach of traditional architectures (form based: HTTP get/post). And, though the BPM Portal remains unsurpassed in features it simply cannot function as a mobile application.

For example, with the portal loaded into a 10″ tablet web-browser, there are just too many active features and UI elements for reasonable touch-screen interaction. I found myself constantly zooming in for navigation and then back out again to review effects and options. However, dashboard and charting elements do work well when broken out on their own as separate elements.

IBM-BPM v751 – Advanced: Dojo, Widgets, ReST API

Business Space enhances end-user experience with iWidgets and supporting dojo infrastructure.  Users now have rich web-applications without the downside of additional overhead costs required for custom in-house web development.

New BPM ReST APIs also opens the door to previously unattainable (within reason) web capabilities. Fully in-browser, JavaScript libraries now have direct access to process management. This leads to better performing web applications with reduced UI-interrupting side-effects caused by (legacy) HTML “post” and “get” operations.

Though very close, I’m not sure that we’re at mobile computing. I need to qualify this however because Business Space runs well on Tablets. The catch is that it requires screen real-estate, network bandwidth, and additional CPU. Honestly, these are negligible on today’s desktop/laptop computers. Even reasonably powerful tablets are fully capable of running Business Space over WIFI.

Business Space on a smart-phone though does spot-light a few problems.

Screen real estate is tight on smart-phones! Slow performance is also noticeable as the phone’s CPU just doesn’t seem to keep up and deliver on the same snappy performance previously experienced on both desktop and tablet execution.

Phones require their own native BPM application.

Mobile Applications for Mobile Process Management

Writing native applications feels counter-intuitive but it’s our only alternative given the constraints and limitations for mobile computing. Moving task services to Android (for example) significantly improves performance. Execution latency and UI “lag” disappear as timings drop into sub-second range.

With local execution, we’re looking at:

Reduced IO traffic via local application loading

• Discrete JSON server requests via ReST APIs.
• Native (java) run-time execution
• Local device data-storage. For example, Android includes a database usable for both caching and offline process execution.
• Local application services. These include: notification, document viewers, contacts, identity, and geo/mapping.

Conclusion

In working towards an architecture suitable for mobile BPM we take into account accompanying constraints and capabilities. We’re on a different path in that we’ve re-focused on building native phone applications.

Smartphones require discrete UIs, optimized coding techniques, and light-weight network IO. These challenges though are well worth the investment as mobility advances user-to-process interaction to near-personal proximity.

Acknowledging the tens of millions of new users purchasing smartphones, new expectations are set/re-set on almost a daily basis. Now’s the time to revisit our architecture and build-in these future capabilities.

David Brakoniecki chimes in on ACM’s product/market fit problem, and hopefully he won’t mind me quoting liberally from his post.  On the one hand, there is the rock:  free or nearly free software from various providers that addresses the freelance/collaboration use case…

Freelance Web designers and developers need a tool to collaborate with clients and to manage projects. They simply can’t afford to pay much for it but there are thousands of them. Basecamp pretty much plays perfectly to this market. It’s SaaS delivery model and freemium pricing makes it easy for users to get started quickly.

On the other side is the hard place: difficult integrations that must be completed before something like ACM or BPM can be successfully implemented…

If your target market is hospitals or insurance companies then just setting up the integrations and data migration is a massive upfront investment. The promised business agility depends on getting the set-up right and the compelling difference with other case management and BPM technologies is less.

And in this latter market, you find yourself up against established technology companies with robust BPM and separately, robust integration offerings (often well-integrated into a single suite).

This doesn’t shoot holes in the “methodology” side of the ACM pitch, but it sure points out a problem for the technology side of the house.  And there is some market evidence to support this view.  A few of the “ACM” vendors have run into the reefs – e.g. ActionBase (which I still think had the best articulation of a product that reflects ACM values, and yet was clearly not a BPMS).

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.

After all the mergers and acquisitions in the BPM space over the last 2+ years, you could hardly blame people for thinking the BPM space was going to be dead or at least lacking innovation.

However, some of us argued that innovation would continue – both within the independents that were left standing, and even somewhat among the biggest players.  We have some evidence of that today with BonitaSoft’s press release – 350% growth year over year with their open source BPM platform.

First, the positives:

1. This is a great achievement for BonitaSoft
2. It shows that there is a wider, deeper demand for BPM software than what the big commercial software packages are addressing.  This also indicates there is likely an umbrella underneath current commercial software pricing where a lot of the demand is dormant.
3. An open source package can get real adoption (200 customers+).
4. Innovation and market shifts continue in the BPM market

Now, for the questions (the answers to which might make these positives or negatives):

1. Where does the revenue come from?  The site mentions subscriptions and I assume one can get pricing but prices aren’t on the website (note: BonitaSoft manifesto includes “transparency” as a core value :)
2. Is it all open source or just some of it?  One thing I note is that BonitaSoft, while flying the open source flag, says in its overview: “Bonitasoft is already developing additional versions of Bonita with professional grade technical support and advanced features to facilitate collaborative work and to industrialize Bonita deployments.  BonitaSoft reserves the right to give access to these versions on a subscription basis to its customers only.”  That sounds like closed-source on top of open source to me.  The fact that it is subscription based is a minor tweak to the traditional commercial model.  There’s nothing wrong with this, per se, it just means that these subscription packages don’t benefit from being open source in the same way that a truly open source project might.
3. 350% year-over-year… starting from what number?  $1? $1000? $1MM?  Without context it is really hard to put this great performance in context.  According to one source, revenues were under $10MM as of June 2011.

Regardless of the answers, 350% is a great number to put up, the answers just put color around it.  It is great to see the BPM space still producing growth numbers that surprise. Looking forward to more updates from BonitaSoft in 2012!

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.

I liked Dave Brakoniecki’s analysis of OpenText’s December comments on their BPM strategy. Like Dave, I find it interesting that they think they’ll be most often running into Pega and IBM.  Dave’s thoughts:

OpenText probably need to acquire some rules technology to really compete with Pega and IBM. Shame that Progress snapped up Corticon a few days ago.

His analysis is spot-on in that without a rules engine, OpenText has a chink in the armor that the other vendors can exploit.  And they’re not exactly a pure play vendor that can appeal to the “best-of-breed” argument with their customers.  It just looks like a tough hill to climb.

Rules engines aren’t that complicated, per se.  It is thinking through the design of user interface and maintenance of these rule systems that is where the value is, and where the challenges are.  Incorporating them with a BPM suite is another interesting problem to solve, though one option is obviously to leave them loosely coupled.  I think OpenText has their work cut out for them to differentiate themselves in this market, but we’ll certainly have a chance to see how it develops.

Happy New Year to our readers!

2011 was a very good year for BP3 – again, thanks to our customers, and our team.  Our customers continued to invest in BP3 and in BPM, and we’re grateful for the opportunity to help customers achieve success with BPM.  We had some great moments this year – we spoke at IBM Impact with one of our customers, rolled out more production deployments than ever, and had our first all-hands meeting.

Our team is the other major factor in our success.  It is a really good feeling to see teammates pulling together to help each other.  The maturity and experience of our team is the best, bar none.  And yet, our team is humble enough to keep trying to get better, to be well-aware of our weaknesses and strengths.  Every day we go to work thinking about how to improve.

We also made the 2011 “Fast 50” list in Austin for the first time in 2011 (covering years 2008, 2009, and 2010).   We followed up with another banner year – we doubled revenue in 2011, above our expectations.  Without releasing the exact number, you can do the math based on previous publications.   One can argue that a rising tide lifts all boats, but it isn’t so much the big, general, service providers that I see getting traction in the market, it still appears to be the focused “pure play BPM” consultancies that are getting the most traction (and creating the most successes).  This isn’t just true in one vendor ecosystem – it appears to be true across several different OEM software vendor ecosystems.

2011 exposed several memes that were circulating among pundits and bloggers.  My summary of our learnings follows each:

• BPM is Dead.  In fact, 2011 has seen BPM achieve more mainstream success (and press coverage) than ever before.  Far from dying, it is still fostering innovation, consolidation, and customer adoption.
• BPM won’t do well as the economy improves.  I think we could all agree that the economy in 2011 was better, but not good enough to really test this theory.  I still contend that you can’t predict the next economic cycle based on the results of the last cycle – each one is just enough different to surprise you.  This one might be the one where companies continue to invest in process improvement even as growth resumes.
• BPM innovation is over.  I still see interesting innovations happening across a number of vendors-  IBM BPM’s chief innovation has been leveraging IBM’s software in an environment that still feels like Lombardi’s user-friendly BPM environment- versioning and all.  Appian continues to innovate in cloud deployments and mobile BPM.  Isus continues to blaze its own path.  Tibco has picked up Nimbus to add to its own ActiveMatrix BPM.  Activiti and Bonitasoft continue to improve open source options – and Activiti in particular is taking a few different turns as they build out their feature set.  And that really doesn’t do justice to the other folks who are testing out innovative ways to build processes – from data mining for processes to using natural language to express them.
• Austin and Texas will fare better than the US in general in 2011.  Based on Novembers statistics of a 6.6% unemployment rate in Austin, I’d say that’s true.  It appears likely to drop again for December.
• The Process Body of Knowledge effort kicked off with the aim of being the wikipedia for BPM.  These kinds of efforts take a long time to get momentum and really take on an inertia and life of their own.  But if they can get it going, it should be really interesting for the BPM community.
• We started to hear concerns from within the ACM community itself about its risk of  failure.  In fact, in February, ACM was declared dead by one of its own.
• Simplicity and Experience.  These themes just seem to be driving value in the software and consumer markets right now.  And yet many enterprise software companies still aren’t paying attention to these key value propositions.
• There is a lot to learn from startups, which can be applied to our BPM efforts. As startups examine the process of starting, and the process of product development and customer discovery, they’re exposing a lot of nuggets of wisdom about BPM, though the terminology and perspective is different.  Moreover, researchers and entrepreneurs are starting to coalesce around a set of processes for starting up companies and developing products.  It is really fascinating to both observe and participate in.
• SXSW-interactive is a monster.  The conference continues to have an impact on tech and social media.  And despite being “too big” every year, it just keeps getting more interesting and evolving in unexpected ways.  The latest transformation seems to be more startup orientation.
• BPM conferences’ attendance was up.  Both Impact and Gartner had much higher attendance in conferences closely aligned with BPM in 2011.
• We had our first all-hands meeting.  We should have done it sooner.  Leadership and people are the heart of any business, and the heart of any BPM initiative.
• There were several more acquisitions. Consolidation continues, even as new seeds are planted in new startups.

The future for BPM never looked brighter. And by implication, the future for BP3 has never looked brighter.  We see some really important opportunities in front of us, and we are, right now, making the investments that we think will position us to better help our customers going forward.

We’ll have some interesting announcements to make in 2012 as we get deeper into the year.  We have a few opportunities to really improve our value proposition to the BPM market and intend to follow through on a couple of those this year, and we’re looking forward to sharing our thoughts about the future soon.

What a great year for BPM 2011 was.  And it was also a good year of blogging for BP3!

Not that volume page views is our goal per se, but something happened in 2011 as pageviews jumped from a ~3000/month range to a 4500-5000/month range.  Hopefully this means we’re doing our job well, which is writing about BPM, startups, staffing, and other topics that affect business processes.  Our main goal is to communicate our passion for BPM and foster discussion and thought in the space.

One change in 2011 is the iPad2.  With this new device, I was able to take notes at conferences more comprehensively than before – no concerns over battery life, and it is lightweight enough to lug it around all day without needing to see a chiropractor.

Most popular posts in 2011:

1. Apple and Business Process Management
2. Penny for Your Thoughts (IBM BPM 7.5)
3. BPMN 2 Examples Courtesy of Camunda
4. IBM Quietly Updates BPM
5. The Battle of TLAs: BPM is Transforming ECM
6. Consulting Math vs. Software Math
7. Why use BPM over other workflow tools? – A succinct explanation of why you use BPM
8. Migrating to IBM BPM 7.5
9. SXSW 2011 day 2. The Lean Startup Phenomenon
10. Beauty is in the Eye of the Beholder with IBM BPM 7.5. #ibmimpact

Clearly posts about IBM’s products were well-received, perhaps because of the practical and immediate value of this kind of information.  But it is nice to see the staying power of a few other topics.  The most surprising thing about this list is that the most-read blog is from 2009.  Yes, Apple and BPM is still a hot topic in 2011… and that post still shows up regularly on our daily top-reads list.  Perhaps the reason it is still well-read is that it didn’t become quickly dated.  Similarly, I wouldn’t be surprised to see Consulting Math vs. Software Math on the list next year. Finally, “Why use BPM” is a post that is from 2008 – and still cracks our top-10 for 2011.  It is as relevant today as it was 3-4 years ago.

For a second year in a row, despite plenty of posts and comments, the ACM posts did not crack the top 10 most-read posts.

1. Search engines -> Search results
2. Twitter
3. Google
4. LinkedIn
5. Lijit
6. brsilver.com – thanks Bruce!
7. activiti.org
8. paper.li
9. Google Reader
10. BP-3.com

So search is the #1 way people find our blog posts apparently.  But what were they searching for?

1. IBM BPM 7.5
2. Apple business process
3. Apple operational processes and procedures
4. bpms definition
5. bpmn examples

Look for more guest posts from our team in 2012, and more about BPM!

IBM has released a new update to BlueworksLive, on December 17th.  We had a preview just two days before it went live to discuss some of the thought behind the features. What interests me isn’t just the outcome but the thought and direction behind it.  Once again the specific features seem “small” but have interesting consequences and implications.

Starting with the shorter topics first:

The Word Export is much more pleasing to the eye than previous versions.  Having the graphics of severity and the diagram itself exported are a big help to the overall readability of the document.

The expand-all/collapse-all functionality in the Process Diagram is also convenient – especially when prepping to export a large diagram.

The BPMN export API works as advertised.  This is an important step to allow people to use BlueworksLive without feeling locked in.  After all, in a cloud “rental” model, one of the big fears is that your data is residing on someone else’s servers.  IBM needed to provide a clean way to get at that data and make it portable.  Not to mention, this lets customers apply some of their more standard SDLC to their requirements production in BlueworksLive.

First, there was quite a bit of attention given the Decision Discovery feature added to BlueworksLive.  I’d heard that this was coming, but I was picturing it as something that would be added to the automation features of BlueworksLive – I should have realized that the “Discovery” in the name implied that it would be part of the modeling (“Blueprinting”) part of the product.

The premise is that you set up a few Considerations (one or more).  The combination of these considerations is like a truth table.  However, BlueworksLive also lets you provide more than one conclusion – which is nice.  When modeling, we can label the column headers smartly, allowing the contents of each cell to be concise and simple (Yes/No, >$500/<$500, etc.).  Finally, we can label the conclusions well- “Adjustment Required”.  If we have more than one conclusion, it gets its own column to keep ideas separate.

A couple of surprising perks:  you can reorder columns and rows with a simple drag-and-drop.  Look, this makes sense given the point of the tool – flexible discovery of decisions.  But this is the kind of fit-and-finish often missing in enterprise software.

I also appreciated that they thought through why the cells should be free-form rather than constrained to integers or strings or a particular data type. The goal is to leave discovery unconstrained.  Plenty of time for constraints when you move into modeling for execution (had this been targeted at execution, you can bet there would have been tight treatment of data types).

Like David Brakoniecki, I think BlueworksLive is showing that it will live up to its promise as a BPM discovery tool.  Not because it does everything it needs to do today, but because IBM have shown that they’ll keep turning the screws until they get there.  His take on the impact of tiny changes at this point in the maturity of the product:

Now, at the push of a button, the process documentation and process diagram can be exported into a single word document. Basically, this document becomes the high-level scope of any potential BPM deployment or process improvement initiative. All of the great power of Blueworks around social collaboration and process discovery now can painless produce a document to playback to the client or business teams for review and iterative improvement.

SaaS products really emphasize the benefit of incremental improvement.

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.

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.

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.

Analysts were predicting more consolidation in 2011, and it looks like the late-year acquisitions are happening again.

First, doc capture specialist Kofax has acquired Singularity, a BPM and case management provider.  Kofax has been part of many a BPM project, whether they realize it or not, as the doc capture element.  Almost every BPM project needs that transition from “physical world” to “electronic bits” or “process world” – and document capture is a common entry point.

Neil Ward-Dutton, of MWD, comments:

In a call first thing today, Kofax CEO Reynolds Bish highlighted that he expected the acquisition to double the size of the company’s addressable market – in large part through the expansion of sales coverage and effort for Singularity’s products, which Singularity itself had largely confined to the UK.

In other words, Kofax expects to expand the reach of Singularity, as well as of their product set itself.  Interesting, to me, was that Singularity’s revenue mix was 50% services, and that Kofax intends to adjust that downward.  Good news for Singularity partners or services experts.

Meanwhile, in another corner of the BPM world, Progress has acquired Corticon, a pure-play rules management (BRM) vendor:

Progress is pitching Corticon as a crucial ingredient as it continues to develop its RPM story, and this makes sense. Progress’ Savvion BPM technology already had a fair business rules capability (BizRules) as an integrated component, but my view is that Corticon’s technology is more widely-applicable, as well as being widely acknowledged for a very strong ease-of-use story, enabled by its heavily model-driven and graphical approach to rule specification. Its open stance towards rule management repositories will also serve it well, as Progress seeks to blend Corticon’s tools into broader capability mixes.

In a previous life, we used Corticon for rules for a while.  We didn’t find it particularly compelling and ended up writing our own, similarly non-compelling rules solution.  More often than not, customers would use ILOG or Fair Isaac or Drools. But it has been several years now, and no doubt Corticon has made some progress in that time (pun intended!) on their rules capabilities.

The conclusions I’m drawing from these acquisitions:

1.  BPM and Rules are a natural combination.  BPM seems to be the value driver, as it is the rules vendors getting gobbled up.

2.  BPM and Content Management or Document Management combinations are also happening.  But the major BPM vendors have (largely) already purchased Doc Management or Content Management solutions… So the remaining players in these spaces are forced to go pick off the weaker BPM vendors instead (OpenText acquired two of them, Lexmark acquired Pallas Athena, and now Kofax is in on the act).

3.  There’s still a lot of shakeout to occur in the market – and execution at a detailed level for each vendor is really going to matter.  At this point it isn’t all marketing fluff – real differences in product are apparent.  But the target keeps moving.  A well-integrated solution that is coherent to the end-user is going to win the day.

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.

Alberto Manuel’s End to End BPM blog lists BPM Blogs worth reading in 2011 – linked here in case you don’t follow his blog directly or haven’t seen his posts on twitter.  He lists some of our favorite blogs, including Sandy Kemsley’s and Anatoly Belychook’s blogs.

There are a couple on the list I haven’t been following which I’ll now be checking out.  Thanks to Alberto for putting this list together!

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.