Everything you need to know about BPM 2.0

The cloud has disrupted software markets around the world and has led to the development of BPM 2.0, but what’s new about it?

First, we’ll take a look at how the cloud has changed business software markets, with a particular focus on BPM software and the technology used to manage and automate internal business processes before we dive into the differences between BPM 2.0 and BPM 1.0.

Cloud the disruptor

Cloud applications deliver new features to end-users with improved speed and cost over traditional on-premise software. When a cloud developer takes a new feature through automated testing, the feature is immediately available to end-users over a browser.

Compare that with the on-premise developer who bundles up fixes and features into a quarterly release cycle, shipping compiled software binaries to end-users, or under distribution agreements through approved Value Added Resellers (VARs).

Pre-cloud, end-users sought advice from VARs, solutions specialists, and industry analysts before investing in technology. The cloud analogue of peer review (Capterra) and easy to access demos mean that end-users can now go straight to the product and vendor to see for themselves. Licensing has changed too. Swapping up-front licence fees & annual support for monthly user fees means switching to another SaaS platform is less painful if things don’t work out. The “no-one got fired for choosing IBM” pressure has now gone and end-users are happy trialling different products until the right choice emerges.

Cloud vendors are different from traditional engineering-led vendors. Sales & Marketing inside a cloud vendor is all about creating compelling content to generate inbound interest from search engines, and leveraging platform metrics to upsell direct
to the end-user.

So what has this meant for BPM 1.0 software?

Before the cloud, BPM 1.0 projects were hard

Let’s first have a look at the major milestones of a BPM 1.0 solution:

  1. Establish the business case for automation. Internal innovation, a reaction to the market and business improvement disciplines like 6-sigma or Lean, drive change within organisations. The need for BPM software emerges when an organisation needs to support new automated processes for scale, compliance, efficiency and effectiveness. Once the need is clear, financial planning will identify investments and a procurement process begins for technology and service providers. At the high-end, choosing a billing system for an energy utility or a core banking platform at a retail bank can spend months and years in procurement. Even mid-size companies with lower demands can still expect to spend months in procurement.
  2. As-is process modelling is carried out early to baseline the current business, mixing together process goals with systems, automated & manual activity, and information flows. Process baselines help define the standard by which future change is managed and measured.
  3. Process re-engineering is then carried out to define the desired to-be definition of the business processes. Typically, the analyst will use the strategic aims of the organisation to change the as-is models into a definition of new organisational behaviour. The strategic aims will be specific to each organisation or project, but examples could be to ‘increase the ratio of products to customers from 1:2 to 1:3’ at a bank; or for an energy utility to ‘introduce pro-active tariff recommendations to domestic customers’. Simply-put objectives such as these often cause a large-scale change in big organisations.
  4. After the to-be world is agreed, a change project would kick off, before which there may be a separate service provider selection process. Large change can often join up activity across HR, office relocations, rebranding, advertising, and technology.
  5. Run and measure. When the first release of the new BPM solution is rolled out to end-users there is usually an initial wave of change which has to be managed by the project team. Metrics from the solution will also start to inform the business on the success of the change.

There are problems with this way of working of course. Months or years elapsing before a project delivers on the initial vision hurts organisations. The longer a project takes, the higher the chance that the solution is not required anymore. BPM software
failure rates are guesswork but a review by the United States Accountability Office is telling. During 2008 they found:

  1. 413 IT projects totalling $25 billion spend during 2008, were “poorly planned, poorly performing, or both”.
  2. 50% of government projects had been re-baselined due to changing goals and poor planning.

Complex projects make planning difficult. Turning a strategic aim into a highly tuned requirements specification for a significant software application is dependent on the people doing the analysis – different analysts will conceive different requirements
and solutions to the same problem. Projects where software requirements are unclear or contested are typified by continual change control and low velocity as the project tries to deliver on a vision which has been lost somewhere along the line.

Complexity is difficult to communicate, it’s even harder to manage. Tasks much longer than hours will have huge variability on them. Not surprisingly, inaccurate estimation turns into project delays, missed deadlines and increased costs. In connected
projects, when this goes wrong in a big way, the organisation’s viability can be under threat.

So how does BPM 2.0 change things?

11 reasons why BPM 2.0 is different from BPM 1.0

And it’s not all about ‘low code’. In fact, if you ever hear anyone using that phrase, you know they’re hiding something. Just ask them “how much less code is low code?” and wait for the answer.

While it’s an attractive proposition that an analyst could create a unique process solution without writing a line of code, it’s unrealistic. Code gives you the means by which custom behaviour can be delivered, by which systems can be integrated, and
by which modern organisations can differentiate. The biggest impact in BPM 2.0 is the changed role of the business analyst: from writing documents and drawing up process flows, to configuring production systems based on templates and work queue management.
This means that the analyst AND the developer work more collaboratively – the developer building out the low-level automation and integration demanded by the analyst’s process configurations.

Anyway, it’s time to dive into the reason you’re here and identify the differences which BPM 2.0 brings:

BPM 2.0 BPM 1.0

1. LICENSING

Pay as you go models, per user, per month, or transactional Up front software license fees and 25% annual maintenance. No upgrades when off maintenance

2. COMMITMENT

Monthly or annual sign up Annual rolling, perpetual or fixed term

3. SUPPORT FOR ANALYSIS

Lightweight process configuration for the rapid application developer. Modelling metaphor is hidden by tools – the end-user may be unaware they are designing a process.
Case management already offers a simpler approach using easy to configure templates and greater flexibility at the point of need.
Pre-built process offered through templating which can be changed by the end-user in live, underwritten by the platform.
Easy to integrate analytics help to drive user behaviour toward process goals.
Needs specific process analyst, skills on a methodology such as BPMN.
Models are static and represent old ways of working, change becomes more challenging over time.
Vertical-specific functions ready to go with a mixture of tools to manage change, a mix of process and application development.

4. PROCUREMENT

Try before you buy with immediate feedback on business fit. Plenty of choice specific to your domain on different marketplaces, or go for a toolkit if the challenge is unique or processes can’t be fully understood at the start A lengthy phase involving multiple vendors, systems integrators, procurement management, domain experts, tenders and negotiation

5. SPEED OF CHANGE

Rapid change encouraged through the configuration of production solutions. BPM 2.0 platforms will underwrite changes to process definitions in live, meaning the business can deliver change quickly.
Affected by the need to take any change through a manual software lifecycle process. Even if it’s just a model, the model has to be approved somehow.
Business Rules Engines only expose a small set of the behavior of the system to configuration, so change in the management of work and information will always need codified outside of the rules engine.

6. ARCHITECTURE

Reference browser and mobile applications talking directly to the platform’s REST API.
The underlying architecture below the API is irrelevant, except to the vendor who is focused on driving down platform running costs, hence the popularity of open source.
REST APIs make it easy to integrate BPM 2.0 with existing SaaS or on-premise applications using webhooks and JSON / HTTP. Inherent platform stability granted by a REST architecture approach.
 Proprietary, session based, thick clients, multiple sub-licensable components such as database server. Mix of components with mixed heritage. Stability at scale limited by session management and non-REST APIs calling into middleware. Rules engine attempts to make change easier but don’t go far enough into the management of custom behavior.

7. END-USER PROVISIONING

Vendor enables the account, automatically allocating compute, storage and an application instance to the end-user. This all happens in seconds. Buy servers & operating systems from an approved supply chain, buy BPMs licenses, install dev, test train and production environments. This happens over months.

8. BUSINESS-LED CHANGE

The analyst or operational process owner controls the change on the platform through high-level process configuration.
Developers are called in only for integration services.
Up front documentation is seen as overkill.
Productive configuration of live systems can start as soon as trial period begins.
The IT function often leads the project, with super users from the end-user community acting as advisors.
Projects are typically documentation intensive, carrying roles which aren’t contributing to the end-result.

9. SCRIPTING AND CODING

Open technologies such as server-side JavaScript node.js. The vendor will include scripts for standard features such as inbound email routing, and make them free to change by the end-user.
Education provided by how-to videos and community-based support. Accreditation slows things down and doesn’t guarantee results.
 A mix of proprietary languages and standards. Java (Pega/PRPC). .NET in Microsoft products and a variety of object-oriented languages in IBM products. You need to become vendor-approved at a vendor’s paid for accreditation program before you will be let loose. Good for vendors and CV’s, not good for the end-user.

10. SCOPE

Modern BPM platforms increase the speed of development and rate at which scope is delivered by encouraging an approach of continual, incremental change. As a result, scope is smaller and easier to manage. Traditional BPM products support a waterfall approach to solutions delivery because they aren’t designed for continual change. As a result, work packages are released during mandatory release windows.

11. VERSION COMPATIBILITY

Cloud vendors work hard to make sure that new versions are seamless to the user, versioning cloud APIs to make the transitions easier. Because of the competition and choice, introducing version rework would risk customer defections. New major releases in platforms become expensive upgrades for the end-user and are not necessarily included in the initial licence fee. Not only that, many customisations are broken during upgrades, requiring rework, often a near-total rewrite