I might not have commented on the post, but for reading Neil Ward-Dutton’s response, and then Evan McDonnell’s response. Neil points out that CapGemini’s BPO offering uses IBM BPM (Lombardi), Steria’s F&A uses Nimbus/TIBCO.  And AWD from DST.  So it looks like there are a few examples – perhaps not getting much press.

Evan’s comments were even more interesting to me, crediting BPO providers with some foresight.   He rightly points out that BPO has largely been “lift and shift”, and that they’re running out of steam (but trust me, there are still low wage geographies and polutions for BPO providers to exploit).  Evan goes on to describe the BPOs with foresight and the great benefits they will achieve by adopting BPM.

I have no argument with that – clearly any company with scale, and customers, will benefit from good leverage on a BPM suite/system/solution.  BPO providers are, after all, just companies like yours and mine.

But I took some issue with the idea that we aren’t hearing about their success because they’re keeping it secret, and wrote:

I file this under “I could tell you about our successes, but then I’d have to kill you” (smiley face)

BPO organizations are/were not exactly known for being innovators. I didn’t notice any of them “anticipating” the lack of cheap labor – their whole business was typically based on the premise that the cheap labor pool was virtually limitless. It is no surprise that they are late to BPM, late to process improvement (for real). And a BPO’s process improvement is not for the customer’s benefit, it is for their own. As a customer to a BPO firm you have to own your own process improvement.

You might think I’m crazy or talking nonsense. Does Apple leave it to their suppliers to figure out how to improve their processes or their manufacturing? Or do they go in there and make it happen at a detailed level? Don’t think you can just hand off and walk away. If you do, you’ll find something that went from differentiator (when you made it a core competency) to commodity (when you stopped differentiating on it), eventually turn into a weakness and a cost center (after BPO has set in for a couple years). Only by then, you’ll have lost the critical internal organizational expertise to run that outsourced process…

There are benefits to BPO, but big risks as well. Handle with care.

Of course, many people would argue that most companies don’t do this investment in process and people – but whether companies do or do not invest, it is pretty clear that they should be investing.

As for BPOs, trust me, when a company’s whole business model assumes that individual people are not valuable nor interesting, it is hard for them to suddenly retread for the world where skilled labor is more expensive, and choosier.  Instead, they migrate down the experience ladder, or the education ladder, until they find people who meet the right cost structure (often regardless of the impact on customer outcomes).

To the BPOs out there: invest in people and process, it is the best way to add value for your customers.  But to the customers of BPO vendors – own your own processes.  Improve them.  Don’t let all the benefits of process improvement accrue to someone else.

Related posts:

1. The Economy and Process Improvement
2. Sloan Review on Process Improvement
3. HBR and Process Improvement Culture

It’s a great vision, but BPM isn’t there yet.

The concept of Process on Demand enables you to build dynamic processes that can be changed “on demand” to meet changing business needs. This dynamic process selection provides a substantial improvement in flexibility and agility and reduction in design complexity.  But we have to see if those advantages are sufficient enough to achieve the gains in agility, scalability, and robustness to meet the ever changing needs of today’s business environment.

The blog goes on to describe his new approach to process application development.  The conclusion:

What we have defined here constitutes an entirely different approach to the way we think about application development.  Providing services on demand removes almost all of the complexity of handling multiple options, exceptions, change, and uncertainty— all of that is transferred from the process developer to the system.  The consequences of which are dramatic. More complex applications can be built, far easier and faster simply because it is no longer necessary to encode all the special cases for dealing with a complex, unpredictable world.

This description is a bit too Utopian – someone still has to handle all those special cases and exceptions… that just doesn’t go away entirely.  And the “entirely different approach to the way we think about application development” is actually exactly the approach that startups building applications in Amazon Web Services (and other cloud infrastructure providers) use to think about building applications.  So there’s actually some proof in the world of this approach, outside of BPM.

Certainly it will be interesting if these “mashup” processes are manifested “on demand” as Jon describes.  This approach will work better for processes “outside the four walls” of a given business rather than internal processes that happen inside the four walls (Why? Because for the moment, critical internal systems aren’t exposed via services to machines in the cloud).

Luckily, we don’t have to jump straight from internally hosted, on-premise software to this Utopian dream.  There are shades of grey that are achievable today, and tomorrow… (more on that in a future post).

Related posts:

1. Ismael Defines Cloud Computing for Business Users
2. Demand = Jobs
3. Congratulations to Demand Media, Austin

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

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

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

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

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

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

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

Neil’s next point:

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

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

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

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

No related posts.

In their core market of electronic content management (ECM), the Opentext world is neatly divided in two:  Microsoft/Sharepoint and SAP are allies and ECM Documentum and IBM Filenet are the enemies.

At least this simplifies their strategy.  They know who their friends are and who their “enemies” are.  Companies rally around relatively simple strategies and objectives.

Also interesting were the comments about BPM integration (two BPM suites integrating, not to mention integrating them with the rest of OpenText’s offering):

• 2012 will be a year of product development to bring the products together and create a coordinated roadmap
• The combine BPM product line will be integrated with the rest of the Opentext business in 2013

So far David’s blog has been the best way to keep up to date on OpenText’s BPM developments.

Related posts:

1. Brakoniecki on OpenText Competition
2. MWD on OpenText + Metastorm
3. More on OpenText and Global 360

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?

Related posts:

1. Who Shall Champion Process Management?

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.

No related posts.

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.

Related posts:

1. Server Side Javascript
2. With Competitors Like These…
3. App(le) or Website?

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).

Related posts:

1. Good Advice for a Tough Job Market
2. #IBMImpact: Damion Heredia and the Lombardi Product Roadmap
3. Is Process Everybody’s Product?

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.

No related posts.

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!

Related posts:

1. BonitaSoft Raising $11M
2. GNUstep lives
3. Carrying the BPMN Interchange Torch