Saturday, June 16, 2007

Managing business processes outside the box

Finally I've had a bit of time to catch up again on some news and blog feeds. As I'm reading I'm noting some of the key areas that could benefit from BPM, ECM and associated analytics that I don't think are well addressed. Treat this as a little brainstorm from me that hopefully will lead to some comments, perhaps from vendors telling me how wrong I am and how they do all this stuff already. So to get going:

1. Basel II - using BPMS to measure the accumulated risk in business processes

Nancy Feig writes in Bank Systems and Technology a nice review of Basel II and its gradual adoption in North America. The spend on Basel II focused analytics software is big, with a large amount of attention being paid to cleansing and importing the data in enormous data warehouses.

I wonder if any thought has been placed on the dynamic side of the business, the capital and risk floating in business processes like loan origination and new business accounts and large transactions, which the data warehouse is weeks away from incorporating into an institution's new credit and risk calculations. This takes true end-to-end process management and analytics that can deliver business metrics rather than the typical business activity monitoring (BAM) tools can - something closer to business intelligence for process, than counting the number of workitems in a process and drawing a bar chart.

2. Project Management - using a BPMS to track progress and provide visibility

Admittedly there are more powerful tools than Microsoft Project out there for complex project planning and tracking, and there are many business processes that are repetitively performed that use Project or Excel for definition and tracking that don't need this level of functionality. These 'process projects' often fall into the bucket that are implemented through combining a number of disparate applications through a written or Excel driven manual process.

Tracking, rather than delivery is something that is often overlooked by BPM. A BPMS can act as an incredibly versatile tracking and status monitoring engine, with the ability to truly manage the monitoring of exceptions, 'illegal' or fraudulent activity, and with analytics provide a true view of the activity and performance of these projects compared to historical data. And when paired with more powerful modeling and simulation capabilities, Lean Six Sigma style process improvement can be easily applied to these under-represented processes.

3. Service oriented architecture (SOA) - for services that aren't automated

A great focus has been put into truly automating the business processes in an organization that can truly be automated: handling B2B transactions; automated decisioning with rules engines; responding to online requests and orders with machine generated information. This is valuable, since these 'process fragments' are often the most repetitive and erroneous when handled by human beings, who generally add little value to them.

Focusing on the human components of processes alongside the truly automated requires some powerful services, integration, content management, modeling and process execution capabilities, if the whole end-to-end process is going to be managed effectively. As many integration vendors wait for BPEL-4-people before really being able to work out how to model the human element of business processes (most treat humans as just another 'system'), and many human centric process tools put an SOA tag on their current poorly performing web services, there is a need for systems that can cater to both.

In doing so 'super-solutions' that blend the requirements of pure automation, human workflow and collaboration alongside services technology enable more seamless systems to be delivered faster. And they can also deliver far better business metrics around what is going on across the whole system, not just the limited portion they manage.

So I've written about three ideas that offer food for thought around the underutilization of BPM. Many organizations have a need for handling of these types of requirements and could benefit from BPM to do it. The issues is that most need a visionary leader to work this out for themselves, since it falls outside the standard pattern of an HR onboarding process, accounts payable or one of the other typical business processes that BPM vendors choose to market to.

Technorati tags:

A post from the Improving New Account Opening blog


Tom Baeyens said...

"the underutilization of BPM"

Exactly. But the biggest aspect thorougly ignored by most BPMS vendors is embeddability.

That would be my point #1 that I'ld like to add to this list.

BPMS's are monolithic systems that don't fit into todays software architectures. They sold their souls to SOA ! But since when can we assume that everything is a web service ?

Microsoft's Worflow Foundation, together with our approach in JBoss jBPM is centered around exposing a core programming model for long running processes. On top of that, the declarative process languages can be build. If the programming model is done right (as in the two examples given), you can build many declarative process languages on top of that same framework. And those *fit* on top of todays programming architectures. Our adoption (+20000 downloads per month) proves that providing the core BPM features closely alinged with todays programming architectures helps developers to integrate it into their applications.

As long as a BPMS products keep their sole focus on service architectures, they will remain niche products.

Anonymous said...

Hi Phil

In relation to your point three, I agree that the world does not (at least yet) revolve around only web services, and there is a need to link together people, processes and information in more imaginative ways than current BPMS systems.
How about looking at the other end of the telescope and addressing local problems?
I work for Blue Prism but did a quick evaluation of various companies in a similar space on my blog at

Best regards

Anonymous said...
This comment has been removed by a blog administrator.
Phil Ayres said...


I think that you have raised an interesting point - that there are different classes of BPMS, targeted at different business and technical environments.

As you say, tools like jBPM and Microsoft are ideally suited to be embedded, since they offer developers access to familiar development environments and a real openness of architecture (well, JBoss at least). This presumably allows them to get embedded insight a range of applications that have some level of process needs.

At the other end of the spectrum, BPM Suites like Global 360's Process360, and its competitors like Appian and Lombardi are marketed at business problems and rapid development of process applications by business people. Sustaining a toolkit approach for this type of problem may not be so applicable. Though I wouldn't necessarily describe these products as monolithic, since all componentize the supporting services, like content management, data persistence and so on.

I also believe that there is a mid ground. One of the products I manage, Case360, has always had an open architecture and modular design, and is highly suited to Java developers producing highly customized process and content centric applications. At the same time it enables business users to rapidly design and deploy business applications. It can become core to an organization's business very quickly due to its flexibility, while hiding the complexities of J2EE development for organizations that don't want to be quite so close to the 'bare metal'.

As for SOA - are you suggesting that it leads to monolithic architectures? To me, Services are more than web service technology. They represent a mindset around the segmentation of new applications into reusable parts, either at a business or technical capability level. For example, 'credit check' or 'process insurance claim' are viable business services that sit way above the level of an individual BPMS and a single web service end-point. A service like this incorporates the backend human interaction and may be composed of other more granular services, so web service based, others not.

That said, a BPMS manages process, and process is the centerpiece of the way business operate, so it seems natural for a BPMS to offer process-centric services and enable other applications to expose their capabilities as services as well. If a BPMS does that with configurable activities or open APIs for development, does it really matter? I think that the choice will come down to who a specific organization wants to use to build their business processes - developers or business analysts.

I do agree with you though - finding a way to help BPMS be non-niche is important if their value is to be felt across more organizations.

Thanks for your comment!



Phil Ayres said...


Interesting blog. I agree that for confined uses, mashups may be applicable. I think that for them to become a generally accepted approach, some form of central 'control' mechanism will be required and this seems to be the approach that some of the companies reviewed on your blog have taken.

I've added you to my blogroll...