So you’ve invested in a Business Process Management Suite (BPMS) and have achieved success in your initial project. Now what? Our research tells us that many organisations fail to capitalise on initial project successes, leaving other potential business transformation and improvement stones unturned. In this report we reveal the two questions you should ask yourself before applying BPMS technology to other potential projects, and present four patterns for BPMS usage, helping you think outside the box of your initial project and drive additional value from your investment in technology and skills.
Many organisations fail to truly capitalise on initial BPMS project successes
A good BPMS, used in the right way, is a tool that “improves the process of process improvement”. Nevertheless, more than ten years after the BPMS concept was first implemented, the adoption of BPMS platforms is still low in comparison to the overall size of the process improvement field.
One of the challenges we find in our research and advisory work is that many organisations fail to truly capitalise on initial project successes by leveraging what they’ve learned and applying the technology to more business processes and domains. To make the most of your investment in technology and skills, as you look beyond your first BPMS implementation project it pays to think broadly about how the technology can be applied.
There are four common usage patterns for BPMS technology – and it’s not all about automation
There are many ways that organisations can and do use BPMS technology to support process improvement initiatives – and only some of them relate to ‘process automation’.
In this report we highlight four common usage patterns:
- End-to-end work co-ordination
- Integration orchestration
- Interactive operational guidance
- Performance monitoring and assurance.
Understanding your process improvement goals and challenges are your guide to BPMS usage
Working out the most appropriate way to use the technology in a particular situation means you have to take a step back and think clearly about two things: what are the goals you are trying to achieve in your process improvement work, and what are the challenges that stand in the way of bringing any improvements you identify into operation?
To capitalise on your investment and experience you should use the explanation of the four BPMS usage patterns in this report to help you expand your current use of BPMS technology into new scenarios, projects and parts of your organisation.
Beyond your first BPMS implementation project
Let’s take a step back: why use a BPMS?
Organisations around the world have been working on process improvement initiatives for well over 50 years – and for the vast majority of that time there’s been no specialised technology available to help drive the results of process improvement work right into the operational environment. Until relatively recently (within the last ten years or so) process improvement teams had to rely on patchworks of written process and procedure manuals, knowledge management systems, custom-built or generic business application software, and so on.
The introduction of specialist “BPM systems” or “BPM suites” in the late 1990s built on the core concepts of workflow systems, but improved their value to process improvement initiatives by firstly, enabling customers to specify systems using graphical workflow models, and secondly, delivering built-in measurement and monitoring facilities that gave administrators and managers visibility into business process health and performance. The result was software that could for the first time legitimately claim to be highly tailored to the operational needs of process improvement teams.
A good BPMS, used in the right way, is a tool that “improves the process of process improvement” – providing technology to create shared understanding, shared visibility and consistent application of business processes in operation, and supporting an iterative, collaborative, cooperative approach to process improvement that can yield great benefits. Nevertheless, more than ten years later, the adoption of BPMS platforms is still low in comparison to the overall size of the process improvement field.
Through our research and advisory work we see a number of reasons for this. This report focuses on just one of the challenges to broader adoption of BPMS technology in industry, and here it is: many organisations get solid results from their first BPMS implementation project, but then fail to translate these early results into more projects and greater business benefits. Why is that, and what can be done about it?
One application to rule them all?
One of the key reasons that BPMS technology fails to be more broadly applied, in our experience, is that project teams automatically think of it playing just one particular role in supporting work and business processes in their organisations – it’s what we call “one application to rule them all”.
When you look at marketing and education material from BPMS vendors, consultants and other suppliers, the assumption is that you will use and deploy all the elements of a BPMS – discovery and design tools, a workflow and integration runtime platform, monitoring and optimisation tools – in a way that creates an additional layer of technology on top of the databases, middleware and business applications you already have in place. The runtime elements of the BPMS, configured to run specific ‘process applications’, wraparound and hide other investments, remove the need for people to interact with existing applications directly and only interact directly with the user interfaces provided by your BPMS or custom designed by you to work with that BPMS.
This is the “one application to rule them all” assumption – the assumption that if you want to improve or change the way your business works, then you’ll have to deprecate or demote in some way the existing systems you’ve put in place to help support your business. This is sometimes absolutely what you need. But just as often, it’s not. Investing in and implementing a BPMS to support a process improvement initiative is not that simple, or that restricted.
There are many ways organisations across industries can and do use BPMS technology to support process improvement initiatives: we commonly find four in practice. But before we get into describing these four usage patterns, it’s worth taking a step back – to help you think clearly about two things: what are the goals you are trying to achieve in your process improvement work, and what are the challenges that stand in the way of bringing any improvements you identify into operation?
Revisiting process improvement goals and challenges
The figure below highlights some of the common goals that organisations have in improving business processes, and the challenges that can complicate putting improvements into operation. When you’re looking at how to apply BPMS technology to a potential project, you should start by understanding the particular mix of goals that you have and challenges that stand in your way.
Four patterns for the application of BPMS
In this report, we explore and explain the four most common usage patterns for BPMS technology – explaining how each pattern draws on BPMS technology elements and how it fits with other investments you have in place. As we explain each pattern, we highlight which blends of process improvement goals and challenges (as introduced in the figure above) are particularly suited to it.
It’s quite possible that for any particular project, you will get value from implementing more than one of these patterns. In many situations, BPMS technology can and should be applied in multiple ways at the same time to support the goals of a process improvement initiative. In any given situation though, there will be one major pattern that should govern the shape and the prioritisation of the work you do – with one or more other patterns supporting this major pattern.
Pattern 1: End-to-end work co-ordination
Pattern 1 – end-to-end work coordination – is the “one application to rule them all” pattern we talked about earlier in this report. The figure below provides an illustration of this pattern.
In this pattern, business processes are automated through the BPMS and participants in the process primarily carry out their tasks within the user interface of the process application – selecting and completing tasks typically using task lists, inboxes, task forms and dashboards that have either been configured through the BPMS or are custom-built to work closely with the core features of the BPMS.
Here, business applications that support individual tasks within the process are very deliberately hidden from users of the process application. Sometimes this is for training, usability and efficiency reasons; other times it is for the much more pragmatic desire to minimise spending on expensive end-user licenses for business applications.
Where existing applications need to be used behind the scenes – to create or amend business records, to query records, or to initiate some system processing – those interactions between the BPMS and the existing applications are invoked in predetermined ways as part of the business process logic your BPMS is executing.
As we’ve already mentioned, this pattern is the most commonly talked about; but it’s not necessarily the pattern that you need to employ when you’re looking at a new potential project.
|The end-to-end work coordination pattern is likely to be the most suitable for a project when:
This pattern may also be suitable when:
In situations where you have people participating in a process who have low levels of familiarity with the process or any systems that are in use, or where you have high levels of staff turnover, implementing a BPMS using this pattern makes a lot of sense because the BPMS itself acts as a constant and proactive training companion to the people working on the process.
However, if you have people who have high levels of skill and familiarity with the process and existing systems that support it, the fact that in this pattern existing business applications are hidden from process participants means you’re likely to encounter resistance to change. Your case for promoting this pattern has to be strong enough to overcome the cost of that resistance. For example you might be facing challenges in scaling up resources to meet current or projected demand; having a system automatically distributing and coordinating work is what will give you the ability to scale and distribute work to multiple teams in multiple locations.
This pattern is going to make a lot of sense if your processes are fragmented or if they are still paper-based. Here, any goals you have to improve efficiency or quality and consistency will be hampered by challenges relating to information flows – there’s likely to be significant waste associated with unnecessary handovers, rekeying of information, time spent searching for information, information loss and so on.
This pattern can be implemented with: most mainstream BPMS products.
Example case studies include:
- Irish Life – This report examines the implementation of BPMS technology at Irish Life’s Corporate Business Division, which administers pensions investments and associated life assurance benefits on behalf of corporate customers.
- Pinnacle People – This report examines the implementation of BPMS technology within Pinnacle People, a private provider of welfare-to-work services to the UK Government.
Pattern 2: Integration orchestration
Pattern 2 – integration orchestration – is the pattern that infrastructure software and development tools vendors offering BPM tools as part of their portfolios historically focused on. In this pattern, the value of the BPMS is typically described in terms of how it enhances a Service Oriented Architecture (SOA) implementation. The figure below provides an illustration of this pattern.
In this pattern, the work coordination capabilities of a BPMS are front and centre in terms of the value the technology delivers, just as for pattern 1. However in this pattern the technology goal is primarily to orchestrate automated tasks and avoid human involvement as far as possible. In this pattern, most of the tasks within process models are fully automated and used to coordinate the sharing of information and the invocation of business logic across multiple business applications, systems and databases. You will find tasks in these process models that are not automated, and are distributed to people, but in the vast majority of cases these tasks relate to exception handling and error processing. The people involved in these processes are typically systems administrators.
|The integration orchestration pattern is likely to be the most suitable for a project when:
This pattern may also be suitable when:
This pattern has very little impact on the operation of high-level business processes; its impact is focused very specifically on improving the efficiency and accuracy of execution of detailed procedures by automating them as far as possible. It’s particularly helpful in situations where information flows are disrupted by a lack of co-ordination between systems.
The dangerous thing about this pattern is that many organisations we’ve come across assume that because it’s also commonly associated with the term ‘BPM’, employing the pattern will help fix business process problems. By itself, it won’t.
However, the integration orchestration pattern can be used very effectively with the end-to-end work co-ordination pattern (pattern 1): here, the two patterns create two distinct but inter-related layers of co-ordination technology. The lower layer is responsible for co-ordinating information flows between existing business applications, systems and databases; the upper layer co-ordinates the distribution and completion of work tasks within and between teams. The upper relies on services provided by the lower layer in order to create or amend business records, to query records, or to initiate some system processing.
Patterns 1 and 2 work well together when the existing applications and systems landscape is complicated and fragmented; and where you want to create a process-oriented work environment that’s separated from that complexity – possibly because you have plans to significantly update, migrate, merge or retire some of those back-end systems with minimal impact on people.
This pattern can be implemented with: many mainstream BPMS products – but those with specialisations in straight-through processing scenarios (such as Active Endpoints, Bosch, IBM, Oracle, Software AG, and TIBCO) are the best fit.
Pattern 3: Interactive operational guidance
Pattern 3 – interactive operational guidance – doesn’t receive anywhere near as much airtime as our previous two patterns but it can deliver great value in certain situations. You can think of this pattern as a kind of “halfway house” between using tools to model a process and simply making that model available for people to refer to, and pattern 1 here (end-to-end work coordination). The figure below provides an illustration of this pattern.
In this pattern, the work coordination and distribution capabilities of a BPMS are not the main features that add value to your project. Instead, it’s the modeling tools and the models you create that are at the centre of how the technology delivers value. In the end-to-end work coordination pattern (pattern 1), process participants don’t see the business process as they carry out tasks; their view of the work is limited to what they need to complete individual tasks one by one. In pattern 3 however, the business process map or model is the foundation information that process participants use to guide their work. Visual maps or models are enriched with additional notes and documentation that people can interact with and drill into. With some of the commercially available tools, these maps or models can be enriched with live links to existing business applications and systems that people need to use to complete particular tasks.
|The interactive operational guidance pattern is likely to be the most suitable for a project when:
This pattern may also be suitable when:
The interactive operational guidance pattern is ideal for situations where you need to provide an interactive system to help people get their work done, but where either it’s not practical or politically possible to employ the more invasive end-to-end work co-ordination pattern (pattern 1), or you can’t make the investment case to do so. It has the virtue of providing a quick and interactive reference to help process participants work in the right way, but without requiring any significant operational system changes. This means it’s useful in situations where the challenges to process improvement aren’t so much related to information flows or inappropriate tools and systems, but are more related to getting the best out of people who may have to pick up new processes and procedures quickly, or people who move in and out of your organisation quickly.
Not all BPMSs provide all the features you need to be able to employ this pattern “out of the box”, but it’s becoming an increasingly strongly considered use case for product development by the vendor community and we expect out-of-the-box support to increase in the coming 12 months.
This pattern can be implemented with: ProcessGene, QPR, TIBCO Nimbus, Triaster.
Example case study:
- Steria – This report examines the implementation of BPM technology within Steria’s Finance and Accounting (F&A) and other BPO businesses, which manages and executes back-office processes on behalf of enterprise customers across Europe.
Pattern 4: Performance monitoring and assurance
Pattern 4 – performance monitoring and assurance – is often considered as a component of patterns 1 and 2, but in actual fact you can use a BPMS for monitoring and assurance without either using it to coordinate work directly or orchestrate systems integration logic. The figure below provides an illustration.
In this pattern, just as in pattern 1, an executable business process model that details tasks, milestones and choices is at the core of the application that you deploy. However, whereas in pattern 1 that model is used to actively coordinate and control the flow of work between people and systems, in this pattern the model is used passively as a way of determining the current status of process instance in operation. The BPMS runtime, executing this model, “listens” to existing systems, applications, and databases via event passing middleware of some kind. Adapters integrate with these existing assets and emit events that the BPMS runtime picks up. The BPMS – either by itself or with the help of a separate event processing engine – correlates these events to figure out which events relate to which process instances. As a result the state of individual instances is advanced through milestones in the process model – so it’s possible to get a real-time view of how business processes are proceeding without process participants seeing anything different to what they saw before.
To take this pattern beyond passive monitoring towards more direct performance assurance, you can use the facilities of the BPMS to take actions if certain milestones aren’t reached in line with service levels that you specify – for example sending reminder e-mails, sending notifications to managers, and so on. Dashboards can provide visualisations that clearly show any process instances that are in jeopardy, so administrators or managers can take remedial action before issues impact on end-to-end service levels.
|The performance monitoring and assurance pattern is likely to be the most suitable for a project when:
This pattern may also be suitable when:
The great advantage of this pattern is that it allows you to get business processes under management without disrupting the existing working environments of experienced and skilled staff. It can be used in the long term to maintain a watch over quality, timeliness and compliance with respect to business critical policies; alternatively it can be used short-term as a way to get her initial intelligence about opportunities for process improvement. Conversely though, this pattern by itself isn’t going to be the most appropriate if your process improvement goals are focused on significantly improving quality and consistency or efficiency over a short period of time, or improving process agility.
Often this pattern is combined with all of patterns 1, 2 and 3, where its role is to complement the automation and guidance to those that deliver with the ability to measure ongoing health and performance of processes. Interestingly though, although most BPMSs include process monitoring and assurance functionality as described here, many projects don’t spend the time and effort to really utilise that functionality. Moreover, as we’ve seen here, the performance monitoring and assurance pattern absolutely can stand alone.
This pattern can be implemented with: most mainstream BPMS products – but those with quasi-separate Business Activity Monitoring capabilities (such as Aurea Software, IBM, Oracle, Software AG, TIBCO) are the best fit.
What should you do?
When you’re looking at how you can apply BPMS technology in your organisation beyond your first project, it makes sense to think broadly about how the technology could add value to different situations.
Working out the most appropriate way to use the technology in a particular situation means you have to take a step back and think clearly about two things:
- What are the goals you are trying to achieve in your process improvement work, and,
- What are the challenges that stand in the way of bringing any improvements you identify into operation?
Analyse before you automate!
Use this report to understand whether one or more of the four main BPMS usage patterns are the best candidates for new projects on the slate in your organisation. Don’t assume that the simplistic ‘marketing speak’ of the technology vendors is all there is; don’t assume that unless an improvement project fits a particular pattern of requirements, BPMS capabilities are a poor fit.
In many situations, BPMS technology can and should be applied in multiple ways at the same time to support the goals of a process improvement initiative. In any given situation though, there will be one major pattern that should govern the shape and the prioritisation of the work you do – with one or more other patterns supporting this major pattern.
Putting this into the context of a broader process improvement project or program, if you make decisions about use of automation technology too early – before your improvement team has really figured out the terms of reference of the improvement effort and dug into the challenges that need to be overcome – you run the real risk of using technology inappropriately. Decisions about automation should be deferred until after a significant amount of collaborative discovery and initial analysis work is done.
Get the right people together to get a holistic perspective
When it comes to getting all the inputs for your decision about using BPMS technology in a particular project, the other thing you should take away from this report is that you can’t really restrict your inputs to just your expert IT and software development people (solution architects, integration architects, and so on). Without the right business context – which is likely to come from process analysts, business analysts and other subject-matter experts embedded in individual lines of business – you won’t have what you need to make an informed decision.