BPM Futures

Where are the Process Apps?

Recently reading that 2011 is to be the Year of the App Store,  I visited some App Stores to look for BPM Apps. The results start by unearthing some real BPM Apps and conclude with a vision of the App Store as a whole new paradigm for BPM.

You’ll be amazed to read that there are currently 134 BPM Apps for the iPhone alone, and equally disappointed to learn that nearly all of these relate to music (beats per minute). One of the features of today’s App Stores* is that their search and filter features are remarkably limited considering that a successful search is intended – presumably – to conclude with a sale.  Is there ever going to be a better business case for additional features? Anyway, I digress…

As the table below shows, the type of BPM App best represented in the App Stores I visited could be described as a ‘BPM Participation App’, that is, an App that acts as a client to a remote BPM server allowing the user to start and track cases, and complete work items from an Inbox. Note that the table is simply the result of myself as a ‘mystery shopper’ visiting these stores (which included an Australian filter in some cases) – there may be other BPM vendors with an iPad story (for example), but they just weren’t in evidence in the store on the week that I looked.

BPM Apps Table

(click to enlarge)


Leaving aside the final two (which I’ll come back to), the list is interesting in that it includes few BPM household names.  Metastorm is the obvious exception, with an iPad/iPhone client provided by partner BTI’s Nymbul product. Software AG is also there via IDS Scheer, whose APG product is an iPad/iPhone front end to the ARIS Business Server/Process Governance framework (albeit a ‘Preview’ release).

Of the others, Activiti deserves a special mention because it is advertised as being entirely free of charge, including the open source BPM server. Also SPM Workflow, a Taiwanese product that not only has a wonderfully original graphical audit trail, with each step apparently a gatehouse on the Great Wall of China, but also has the first new original and useful native feature I’ve seen for a while (maybe I don’t get out enough) – a manual reminder function. So if you look at the audit trail and see the case is stuck with Jim, you just select the ‘Reminder’ button and a message is shot off telling him to get a move on!

Most importantly all of these require that you host a BPM server before you’ll get any business benefit from the App.

The final two on the list, Cordys and RunMyProcess are different. Each of these is a complete BPM system, cloud-based and accessed through a web browser. They may not be Apps in a technical sense (no download required) but they certainly are in the sense of this article – they are distributed (amongst other channels, no doubt) through the Google Apps Marketplace site, where access can be purchased immediately, on a per user basis.

Cordys is relatively well-known to BPMers and, like Metastorm, features in the Gartner 2010 BPM Magic Quadrant Report. RunMyProcess doesn’t, though its web site states that it was designated a Gartner ‘Cool Vendor’ in 2009, and it certainly looks intriguing. These two are quite clearly not the only cloud-based BPM products out there (Blueworks Live and Tibco Silver come to mind). But if you go shopping at your local App Store, Cordys and RunMyProcess are what you’ll find.

As I understand it, their target market is any organisation, big or small, private or public sector, that wants to build and manage its own processes without actually investing in their own BPM platform. This is essentially the traditional BPM market, expanded down towards SMEs that could not previously afford the upfront investment that BPM has tended to require.

Moving on from this list, what interested me most were the first hints of ‘Process Apps’. Process Apps (my term, as far as I know, but hopefully useful) being self-contained Apps that provide a service to the consumer, with the service actually – or at least potentially – fulfilled through a BPM platform.

For example, a PR professional or copywriter could define and offer a process that combined the manual task of writing a press release with automated updates of the PR (or variants on it) into a range of social networking media. This Process App could be published through an App Store as ‘One Hour PR’, priced at, say, $99.  The potential for adding human tasks to this type of process will expand significantly as service marketplaces, such as eLance, start to provide BPM-compatible services and plug-ins.

So far I’ve found just two examples of Process Apps, both for Insurance Claims (in the iPhones store, search ‘insurance’) – ‘Just Car Insurance iClaim’, and ‘nib Health Insurance’ each support insurance claims through their App. Now I have no way of knowing whether these particular Apps pass off the claim to a claims process in a BPMS or to a dedicated Claims system, or to a hive of busy worker bees using pencils and paper. However, the principle is clearly there – the App, which is provided free of charge, provides the entry point to a remote process with great potential for value-adds (Just Car iClaims provides info on local tow truck services, for example, and case tracking would be an obvious add-on).

Of course ‘insurance claim’ is a classic example of an ‘enterprise’ process, in the sense of scale – if you can afford to underwrite insurance policies, you can probably afford your own BPM system, cloud-based or otherwise.

The individual or small company offering the ‘PR Process’ mentioned earlier would most certainly not have these resources, though. For such an organisation cloud-based BPM is a necessity. And, importantly, it is not sufficient.

The gap in the market today appears to be for a BPM App (provided by a SaaS BPM Platform Provider, perhaps like Cordys or RunMyProcess) that encourages small developers to sign up with a view to developing and reselling their own ‘Process Apps’. Such ‘Process App Developers’  won’t be integrating with an Insurance Policy or ERP system, but they will join simple human services with existing consumer SaaS applications to deliver new, better and above all cheaper business processes, particularly for SMEs.

The benefits from this will flow mainly to the end consumer. In the same way that much software that would previously have been boxed and sold for, say, $20-$50 is now available in App Stores for $4.99, there is no reason why business processes should not provide similar economies of scale. And the profits of the successful Process Apps will be shared by the App Store, the BPM Platform Provider and the Process App Developer.

To support this, App Store owners and BPM Platform Providers will need to combine forces to allow the Process App Developer to

  • Easily publish his or her Process App in one or many App Stores where it may be accessed by individual consumers. This means the BPM Platform Provider developing a ‘Process App Publication’ BPM App for iOS4 (for example) that supports such publication functionality, underpinned by an appropriate commercial agreement with the App Store owner (eg  Apple), if necessary.
  • Easily invoke, and where necessary pay for, third party services called from the Process App. This is means not only providing uniform and very easily used technical interfaces, but also a marketplace in which to buy them, including on a per use basis. In the ‘Web Services Department’ of the App Store, perhaps?
  • Easily publish the Process App as a service that may itself be called by other Process App Developers, in the same ‘Web Services Department’.

Combining the traditional BPM virtues of ease of process build** with new App Store publication and subscription functionality will encourage and support a whole new world of competing micro-processes, benefiting all involved parties.

If 2011 is to be the Year of the App Store, will 2012 be the Year of the Process App?

* In researching this article I used iTunes to search the Apple App Store for iPhone and iPad; Zune for the Windows Phone; Ovi Store for Nokia Apps; Chrome App Store and Google Apps Marketplace for the web. I was unable to access many Android Apps via the Android Market site because this requires an Android handset. If anyone can suggest any other Tier 1 app stores, I’d be interested to hear about them.

** I repeated the word ‘Easily’ four times in the previous bullets deliberately – I believe that the platforms that will really succeed in this new mass market in Process App Development will probably re-think process definition usability. A great example of making the complex easy that is completely unrelated to BPM – have you ever wanted to create animated films? Too hard? Well first check out this fun animation on the topic of Quantitative Easing, and then the site that allows you to build one like it. If you have 30 minutes to spare, that’s how long it will take you to create your first film. XtraNormal has an interesting approach to monetising the service for developers, with a contractual solution for commercial film makers apparently in the pipeline.

Back to basics – why use a BPM system?

January in Sydney tends to be a quiet month for business, only really coming to life after Australia Day on the 26th. From the 4th onwards there is a gradual return to workplaces that are abuzz with new projects, new sales opportunities, new marketing campaigns, all scheduled to start towards month end or early February. As a result, energy levels of those at work tend to be higher and minds – less stressed than usual, perhaps – a little more open to reflection. So, with that audience in mind, here is a blog about the bedrock of BPM systems (BPMS), and indeed BPM in general, that is, the reason why any business should bother to use it.

The benefits of using a BPMS can be summarised as:

  • Higher productivity
  • Faster process times (eg end to end)
  • An order of magnitude improvement in process transparency/visibility
  • An entry point to a virtuous circle of process understanding, improvement and execution
  • Better control over the process (eg through the use of embedded business rules)
  • Improved job satisfaction for operational staff using the system

Of these the most significant – in terms of both impact and universality – is undoubtedly process visibility. Businesses that lack a BPMS – or alternatively core or ERP software that fully encompasses their business processes – are like vehicles driven in a thick fog. Data about the past is patchy and unreliable, data about today incomplete and highly reliant upon personal observation, and data about the future seriously compromised.  (‘Data about the future’ can be both hard – today’s backlog, how much work is in pending and when it falls due – and relatively soft, for example resource forecasting based upon historic productivity data). Most obviously true of operations teams, this extends further into customer interaction. For example, without accurate end-to-end process times there is little chance of understanding the customer experience except by analysing complaints.

Whilst senior business managers can be passionate in demanding visibility, Boards can demand more. IT investments do not always produce a return and, to continue the fog analogy, we may not be able to see much out the windows but we’ve got this far OK, there is some rear and side vision, and the future’s always going to be largely uncertain.

Which is where the higher productivity benefit comes in handy. Higher productivity in the operations teams can pay for the initial project and the ongoing IT costs, whilst the benefits arising from enhanced visibility (tightly focussed process improvement in operations lowering costs, better informed product development and customer service increasing revenue) are spread across the business.

Some productivity benefits pretty much come with the territory – work distribution, management of pended/diarised work and enquiry handling are all areas where the BPMS will automate previously manual tasks, delivering benefits pretty much by default. Other areas like load balancing (between teams or individuals), exception handling (eg duplicate requests) and re-work management can take a little more work to achieve results. Hard benefits from these and other BPMS features are commonly augmented through add-ons such as automated outgoing document management and integration with core systems, which – whilst initially adding to project costs – can be relied on to provide further productivity improvements.

Faster process cycle times, particularly end-to-end times, routinely arise from a BPMS implementation. Naturally, additional focus and effort can drive further improvement. Where tiered service levels are required, the BPMS can use prioritisation to ensure that outcomes are optimised – something that can be especially hard to achieve where processing is manual.

Process control may be a more or less compelling reason to use a BPMS, and may mean high-end technical control and/or regulatory control. Running business processes through a BPMS will prove to the regulator – and to other stakeholders – that the process has been followed in a specific case (through the audit trail), and is followed in general (through sharing the process definition). Automating business rules will ensure 100% compliance with those rules that are automated and typically will make it harder for a careless or rogue employee to break others. It will also provide control where a – highly automated – process must happen so fast that people are no longer able to participate except on exception, that is, straight through processing.

And improved job satisfaction? Well, whilst rarely at the heart of the business case, the evident satisfaction of employees in receiving better tools for their work certainly makes change management that much easier. And doesn’t everyone want happier employees?

OK – that’s it. Your revision for the day is complete. And as a reward, here is my favourite viral video of the holiday – the Brooklyn Space Program. Any connection with BPM? Just inspiration from their ambition and ingenuity, and perhaps aspiration that we could achieve as much with so little. Maybe we need to recruit some younger project team members?

IBM Cloud steals Lombardi thunder

Another IBM Agility seminar at the Shangri-La Hotel, and some BPM announcements. And in contrast with the sunny spring skies warming Sydney’s harbour (for those of you in the northern hemisphere :cool: ) the best bit in here was the cloud.

But first …. Websphere Lombardi Edition is to have drag and drop integration with both FileNet P8 Content Server and Content Manager 8. The extent of the functionality involved wasn’t clear to me – presumably IBM will start with search/retrieval and later move on to others like metadata update and new document insertion? Anyway, further integration will be with Websphere Service Registry and Repository – useful for orchestration purposes – and with iLog, where it will be possible to browse and select an existing Ruleset on a predefined iLog JRules Execution Server.

In the meantime Websphere iLog itself is to be coupled with Websphere Business Events to become Webspher Decision Server, extending IBM’s business events capability, whilst the iLog BRMS SupportPac is to provide Websphere Business Monitoring and predictive analytics integration

All very worthy, but much less interesting than the next piece of news, which was the launch of Blueworks Live. This combines three elements – the Blueworks BPM collaboration community (blogs, wikis); the highly successful (Lombardi) Blueprint process discovery and definition environment; and a new workflow execution engine. All running in the Cloud and, apparently, available through your browser for a test drive from November 20th. (Yes, that’s this Saturday – perhaps one of the software world’s most specific launch dates ever…!).

Now, Cloud-based BPM is hardly new. Cordys was one of the first to offer it globally, and there are niche players too, such as Australian company OpenSoft, which uses open source products to provide integrated Cloud-based BPM to the burgeoning Australian energy and resources sectors. However, Cloud-based BPM from IBM is something else entirely. IBM’s existing mindshare in the global BPM market and its credibility as a corporate Cloud (and FM) provider mean that the interest in this product will be enormous, and as a result it could well be a game-changer for all BPM stakeholders.

The PowerPoint-based demo that followed included a marketing manager setting up a new process for her latest marketing initiative. Yes, that’s one process for one case/process instance. And if the Powerpoint is to be believed, it only took her a few minutes.

How can this fail? The CIO’s happy because it’s SaaS; the Board because it’s IBM; the Ops Manager is comfortable because its running in an IBM Datacentre; the process improvement people have Blueprint to play with; the IT teams can focus on integrated, production BPM system work; and best of all the Business can replace its endless email trails with easy to access, auditable business processes.

So what next? Well, here’s a prediction –  Blueworks Live will do for business processes what Microsoft Sharepoint did for enterprise content – it will get everywhere. That means a step change in awareness regarding BPM (how many business – or even IT – people knew of ECM before Sharepoint?) and huge opportunities for BPM professionals to sort out all of those ‘home grown’ processes. Bring it on!

Renewing BPM for the coming decade

Isn’t it time we re-thought the definition of BPM? It seems to be getting increasingly jelly-like – wobbling and spreading to encompass every possible interest group. Check this out – the ‘official’ definition (at least until the editing debate settles down) from Wikipedia: “Business process management (BPM) is a management approach focused on aligning all aspects of an organization with the wants and needs of clients.” Presumably contrasting sharply with previous generations of business management methodologies, which focussed on aligning all aspects of an organization with the wants and needs of small furry animals. I love Wikipedia, but if this is the wisdom of crowds, then civilization is surely doomed.

My recollection is that the term BPM came into usage in the late 90s as a way for new entrants (Savvion, Lombardi, Metastorm and Ultimus come to mind) to the existing workflow automation market to differentiate themselves from the incumbents. A key aspect of these newcomers was a serious attempt to make the process definition environment more friendly and useful to business process analysts/modellers, for example with simple BPMN flowcharts and built-in simulation.

However, the newcomers could not emphasise this aspect alone, partly because the incumbents already used graphical process definition (albeit, they would argue, a less business friendly version), and partly because their prospective clients were also concerned with other features, such as ease of integration and reporting. So “BPM” became associated not only with built-in business modelling/simulation but also better integration and reporting (think Business Activity Monitoring) – something not contested by workflow automation incumbents, since some already had excellent integration and they could swiftly match any reporting improvements. Very quickly, everyone sold “BPM” products.

And everyone bought them. The tremendous success of BPM technology, particularly in banking/financial services, telcos & the public sector, over the last 12-13 years (since the explosion of new “BPM” products in the late 90s) has had a further, diluting effect on the terminology. BPM projects are now routinely enterprise-scale, and are therefore attracting a spending level significantly higher than most process improvement /modelling initiatives. This in turn means that a much wider constituency of professionals wants to be involved in BPM projects – and often rightly so, given that enterprise roll-outs do require a wider range of skills, particularly in relation to business (process) analysis. Unfortunately some of these folk are taking positions in relation to BPM terminology that owes much more to their history in process improvement than to the technology that created BPM.

Is this just technology bias? Well, consider your favourite BPM project, and imagine the impact if all of the BPM technology was suddenly removed. What new analytical or process improvement method would remain to distinguish the activities of business improvement folk today from those you might have seen 15 years ago? Six Sigma, Lean, more general process improvement techniques are tremendously important – but have they changed so much in recent years that they constitute a new business management methodology called BPM?

So is BPM defined by technology alone? Think again of your favourite BPM project, and this time remove the entire concept of process improvement, Six Sigma and Lean. What are you left with? I suspect something that looks a lot like workflow automation, at least in its primitive form – a process defined and automated … then the project finishes and the process improvement team (suddenly reappearing) pulls out its Visio charts and starts to negotiate future change with the IT department.

If BPM is to have any substantive and paradigm-changing meaning, it must include both technology and process improvement in a way that reflects their roles and illuminates their synergies. A suggestion:
BPM is the superior state of process management attained when business process analysis and improvement activities are supported by technology workbenches that are themselves deeply integrated with the systems in which the processes are to be executed.

This definition addresses the relationship between BPM, process modelling/simulation, workflow and ERP (and other types of ‘Core’ systems). The following statements become true:
• “BPM” products that do not include deeply integrated workbenches for process modelling, simulation and analysis are not BPM – they are workflow. Nothing wrong with that – many, perhaps most, of the world’s “BPM” implementations to date probably fall into this category and they have provided significant return on investment to their customers.
• Where a workflow product does include deeply integrated workbenches for process modelling, simulation and analysis it is indeed BPM or, perhaps better, ‘BPM-enabled workflow automation’.
• ERP (and other) systems that include deeply integrated workbenches for process modelling, simulation and analysis may also be classified as BPM – or perhaps ‘BPM-enabled ERP’.
• Process improvement professionals can state that they are practicing BPM (or process improvement in a BPM environment) if and only if they are using BPM-enabled technology. They might be practicing BPM in relation to processes executed in a workflow automation or an ERP system.

Such a definition would set a standard for all stakeholders and provide a target for both business and vendors to aim at, with a vision of process improvement and execution progressing in harmony that is both radical (in the context of where the “BPM”/workflow journey has actually been over the last 20 years – whilst a number of products would pass the BPM test above, many solutions based on these products remove the levers that would put process improvement professionals in the driving seat) and ‘back to basics’, in that this is very much what the pioneers of workflow automation envisaged in using ‘graphical process definition’ in the early 90s.

It remains a compelling vision, and one that could drive competitive advantage for those that adopt it in the decade to come. The first step is to collectively recognise the vision and the terminology under-pinning it for what they are, and discard all wobbly-jelly BPM definitions along with sub-prime loans and easy credit, as relics of the decade we’ve just left.

Let data make that process dance

I was recently discussing BPM agility with a senior IT manager, when the topic of configuration files came up. “Many of my colleagues don’t like them” he said “we have hundreds of them, and they don’t like changing them because they don’t know what the consequences will be”.

It’s easy to smile at this, but practically all guardians of customised systems are in a similar position. The reason that I’m writing about it is because config files (or config data, to generalise) can be a powerful way to drive change to BPM systems if used correctly, because data can be significantly easier to change and deploy than code.

What sort of data might one want to externalise in order to improve BPM agility? A few examples:

  • Field labels
  • Text to be included in reports/alerts
  • Route/path ids and sub-process ids (to permit config-driven re-routing)
  • Data relating to rules (‘if value of loan > $1000 then’ will obviously be more flexible if the value – $1000 – is a variable) if the rules are not already externalised through a rules engine (which would be better still).
  • Data that drives which cases/process instances should adopt changed config values. Should changed values be picked up by closed or archived cases? Should they only apply to new cases, or cases with particular characteristics?

As the last point suggests, there is an important system design aspect to this, regarding when config data should be (re-)read and how much granularity is required to control change impact.

And of course, the data to be held will vary widely, depending both on the business processes and the BPMS used.

For this data driven approach to deliver significant improvements to BPM agility the mechanisms used must be thoroughly tested – part of ‘Agility Testing’. Unless one can be confident that changes to the config data will result in predictable outcomes, abstracting it will provide few benefits, since changes will once more need to be system tested, delaying deployment.

One significant source of comfort for the hard-pressed project manager is that Agility Testing can be carried out after the initial go-live. Not perfect, obviously, but a promise that ‘the system will become easier to change after the second deployment’ will put you ahead of many BPM solutions.

So are config files, as such, the best way of delivering the config data into production? Well, no. Config files are hard to add CRUD functions to (and so are often edited in Notepad – easy to make a mistake) and must be deployed (albeit it’s a very simple deployment).

Using a relational database (RDBMS) helps a lot, in terms of basic validation, and if already in use on your project it will be easy to piggyback on existing or planned resilience and recovery features. However, without a user interface (UI), the standard method of changing an RDBMS is via a stored procedure (for audit and repeatability reasons) and this, once more, will require testing and deployment.

A custom UI would be best. It needn’t be pretty – it will only be used by Admin users or Prod Support so some shortcuts may be possible in terms of corporate standards. However, it will need to be able to provide Read/Update (possibly Create/Delete) functions for quite an assortment of data, so some extendable way to segment the data, such as tabbing, will help. Most importantly it must include an audit log and, ideally, a function that will import an existing audit log, making the changes included.

The reason for the audit log import is procedural. Even though no technical issues should arise from changes made via the UI, there is still potential for the Business to have erred in their change request. So an initial deployment into a User Acceptance Test (UAT) environment may well be required. The UI may be used to directly change the UAT config data – indeed this should be so easy that it could be done with a business representative alongside. Once the Business is satisfied with the result, the audit log can be deployed into Production and run against the Production UI (as an import) with no further testing required, since the resulting Production changes will necessarily be identical to those in UAT.

The BPM project steering committee will need to assess the value of this sort of approach, since it clearly involves a cost. The degree to which config data can be used to drive agility in a BPM solution will vary, as will the value that the Business places on it.

And of course all of this works best within an A-BPM (Agile BPM – here today, Gartner tomorrow!) development framework.

Happy trails…

“Agile” – time for a change

Back in the early 90s we used to demonstrate workflow by building a 3-step ‘Leave Application’ process from scratch, run it from the user perspective, change it, then run it again. The message, reinforced by our patter and marketing collateral, was clear – workflow was Agile. And you can read the same from every BPM vendor today – BPM will result in (or facilitate, support – pick your own weasel word) Agility.

The reality is rather different. Most operations managers have to prioritise the changes they need to their BPM system and these typically get delivered according to a release schedule that is measured in weeks rather than hours.

Why? Well, there’s the complexity – of real business processes that are usually much more complex than their users first thought, defined in tools that are smart but not quite perfect (think workarounds), including multiple integration points (so we may need to change the Java code too), and a user interface that is shared with other systems and environments. So the typical end result of a single process implementation is something that is quite hard to ‘get your head around’ and requires special skills to change. For a multi-process deployment, this gets even harder.  And this complexity of interacting components results in genuine risk – of developer error, of user error (in terms of clearly thinking through what is required), and of deployment error.

These risks are typically mitigated through a series of tests. Systems Testing is specifically designed to test that the changed components work together as expected by the developer. Regression testing will test that the rest of the system has not been impacted by the change. Acceptance testing ensures that the user gets what they (thought they) asked for, and gives them a chance to change their minds. And post-implementation verification testing validates that the smorgasbord of changed components that has been deployed hasn’t destabilized the live system. All of this testing and deployment activity takes time and is more efficiently carried out on batches of process changes, rather than one change at a time. The actual deployment may well need to happen outside of working hours, too, as a further risk mitigation strategy. It therefore tends to happen every few weeks, not daily.

Is this inevitable? I don’t think so. After all, there are some changes that are always carried out swiftly – on the same day or, at worst, overnight. Adding a new user, complete with a required permissions profile, will have significantly complex effects – not only on that user’s system access, but also on reporting, enquiries, and supervisor access – but is typically carried out within hours. Why shouldn’t the same apply to process changes?

The answer, today, is that your current BPM solution – typically a BPM product that has been configured, customized and extended to meet your requirements –will not have been designed to support true Agility.

Does any of this matter? Well, think back to the much-derided paper-based process that the BPM system replaced. The process was largely determined by the contents of a tick sheet stapled to the front of the manila folder that contained the case documents. The users knew the process rules, which were based upon what was ticked and what wasn’t.  So changing the process involved changing the tick sheet (thanks, MS Word) and giving new instructions to the team. It could be done in hours. Sure, the end result was much more error prone, less efficient and lacking in MIS. But are we currently trading enormous improvements in all of these, when we deploy BPM, for a loss in agility?

I believe this to be the single biggest challenge to BPM, with truly agile BPM providing potentially one of the most radical changes that technology can contribute to business processing. As an industry, can we rise to the challenge? What did The Man say….? Yes We Can?

To be continued. Happy trails….

BPM – the future starts here

Having read a few other ‘first blogs’ there seems to be a tradition of keeping the first one light. Well, I’m not going to do that – I want to really get stuck into a current preoccupation – what is the future of BPM? Now I admit that I’m biased to a positive view, having worked in BPM (nee workflow) since 1990, and the title of this blog ‘BPM Futures’ also indicates a certain confidence.

However, having been focused pretty much exclusively on business unit, account and project management for the last 5 years (mostly relating to BPM, btw), I feel in need of a domain refresh. So this is it – I hope you’ll also find it of some interest and use.

So why do organizations buy BPM, rather than other solutions available in the global software market? My answers are listed below, along with some observations that will provide recurring topics for future blogs.

1. The Spot Solution “We want to manage our process better, whilst keeping most or all of the standard data in systems other than the BPM system”.

Comment – essentially a tactical view, this generally happens because the client has calculated that it’s cheaper/easier to use a BPM system than to extend their existing system(s) for the purposes of process management.

Examples- streamlining a home loan approval process that straddles an enterprise customer information system  and  a ‘stovepipe’ home loans system;  managing an accounts payable process in which several thousand employees are occasional users and only half a dozen users – in the a/p section of the accounts department – need to use the a/p module of the accounting system itself.

Challenges and alternatives – if the cost of replacing the existing system were acceptable, most newer ‘core’ systems – such as home loans and a/p – include workflow (if not BPM) functionality appropriate to the specific application, eliminating the need for integration.

Opportunities and the future – merger and acquisition (M&A) activity, if nothing else, will maintain this market for BPM. And of course the gradual adoption of industry-standard interfaces and standards by core system vendors will make the integration challenges easier over time. That said, there is plenty of room for improvement in the BPM solutions offered.

2. The Strategist “We see benefit in using the same process management tool for a wide range of processes”.

Comment – Why? Because it makes skills management easier and allows standardization on common process management features such as process definition, version and release management;  data management/reporting; full cycle process improvement; process simulation. At a more strategic level, BPM is seen as protecting process assets from change at the transaction system level, in particular providing flexibility following merger or acquisition.

Examples – there are many large organizations that have invested heavily in BPM and deployed it very widely indeed, with enterprise process management as an explicit goal. Particular examples exist in retail banking, life insurance, wealth management, P&C insurance and telcos.

Challenges – naturally big, enterprise solutions raise the largest problems; agility/ease of change of processes; adherence to standards; the difficulty of full lifecycle process improvement in a highly diverse technical environment; the role for rules management; and managing the explosion of UI requirements that arise from enterprise BPM deployment.

Alternatives – the current wave of core system replacements in the banking industry and the increasing adoption of eTOM-based enterprise telco solutions seem to pose a medium-term challenge to BPM (and, perhaps to a lesser extent, SOA) as a separate industry, though the concepts should live on within the replacement products.

Opportunities and the future – not only core systems, but also enterprise BPM systems are potential subjects for upgrade, particularly as the limits of ‘first generation enterprise BPM systems’ become apparent to user organizations. There are a number of areas that can benefit from improvement and, at least until core system upgrades are complete (at least 10 years away), demand exists to pay for them.

3. The Document Manager “We started to look at document management – scanning our incoming mail and working from this and our incoming faxes through an image viewer, rather than paper – and realized that workflow and, better, BPM, was a significant value add”.

Comment – this is a common sense and frequently used reason for BPM adoption, particularly in a departmental and/or small/medium enterprise context. The current strategic challenge for document management product vendors – increasing commoditization and therefore lower margins – provides opportunities for solution/service providers and customers alike.

Opportunities and the future – whilst this customer perspective starts a little differently (with document management) it soon returns to the familiar territory of specific process management (what are the scanned documents being used for?) and interactions with other systems. So the challenges are similar to ‘The Spot Solution’ and others.

4. The Administrator “We’re looking for a cheap and cheerful way to improve our simpler, administrative processes that our business requires but none of our core systems provide”

Comment – classic examples used are leave processing; timesheets; expense claims; many aspects of employee on-boarding and maintenance, such as security card applications; and so on. Also processes needed to support short term projects often fall into this general category.

Of course even ‘simple’ processes like these would ideally include integration (do we need to see receipts before approving expense claims? shouldn’t timesheet and leave processes interact with the payroll system?). Most BPM systems will provide the technology to provide this integration, though the services required might make the overall business case tough.

Opportunities and the future – this has always been a popular area for workflow, particularly if integration can be ignored (ie worked around by a human operator). Today the relatively simple functionality required combines naturally with BPM delivered through the web as a service, with power provided by cloud computing. No doubt it will soon be as easy and cheap to build an online process as it is today to build a web site (just start with a template…), providing exciting opportunities for a huge number of users and a (very?) few cloud-based suppliers, whilst soon removing this as a market for traditional workflow/BPM solution providers.

5. The Case Manager “We need a Case Management system”

Comment – this is an interesting one. BPM products have frequently been used as part of, or even as the core product for, case management systems. The reason being the obvious one, that BPM products include much of the functionality required for case management, plus the promise of some interesting ‘extras’ (simulation, full cycle process improvement) and in addition many have a significantly larger user base than specifically ‘case management’ products.

Challenges – there are many points of divergence between case management requirements and those of other processes, and many of these can be seen as gaps in BPM product functionality. Two examples  (1) case management workflows tend to mix status (‘state’) and workflow process rules (so a case may be worked on by a case worker, who may carry out a range of actions, some of which include their own workflows, such as a referral to a colleague; once a defined status/state is reached the case must be sent for approval (another workflow); once approved, the case is returned to the case worker who now has a different range of permitted activities, because the state has changed. Standard ways of representing process flows, including BPMN (BPM Notation – think swim lanes), are very good for workflows and equally clumsy or long-winded for defining and illustrating state changes – ‘state transitions’, in the jargon); (2) case management puts a lot of emphasis on data relationships (so in a legal case a law firm may need to record many clients, witnesses, third parties, etc in respect of related cases – BPM systems tend to most easily support only simple data relationships, at both data storage and UI levels, requiring customization to support more). These ‘gaps’ provide opportunities for service providers to craft custom solutions today, and product vendors to extend their products tomorrow.

For the best summary of the special features of case management I have seen recently, check out the following, published here by the ever-readable Business Process Trends:


Yes, it’s produced by a vendor – Singularity – but it’s a great contribution to the literature on the subject, nonetheless.

Opportunities and the future – demand for, and therefore interest in, case management appears high at the moment. This probably reflects its concentration in the Public Sector, where every new government initiative requires administrators/administration and, usually, case management. And there is no equivalent of eTOM on the near horizon, as far as I’m aware (any ideas from anyone else on that?).

So the market for case management systems that manage case data, processes and reporting flexibly and reliably appears secure for now. Improvements are, again, needed. The recent signs of movement in the OMG, triggered by a draft RFP from the guys at Cordys, might result in some standards in this area, and/or might stimulate a product vendor to push ahead with some real innovation.  Lots of topics here for future blogs…

If you read this far, well done. Not an easy read, and I can assure you, not an easy write either!

Happy trails……..