Making sense of BPM
Process is a very broad term…
The term ‘process’ could be used when discussing SAP functionality, and in a different breath, to describe Visio diagrams – so can it really be both? Well, yes. SAP functionality is the execution of a process. A Visio diagram is a simple pictorial representation of a process flow.
Add to the mix the concepts of ‘process automation’ and ‘process management’ and it’s hardly surprising that the business person is confused when talking with the IT team, and even more so when looking at some software vendor’s websites.
In an area buzzing with definitions, one common process-related acronym is BPM – which stands for Business Process Management which was typically used to describe a type of software. In response to deepening sophistication in approaches to process, IT analyst Gartner has recently redefined BPM as an umbrella term to describe ‘approach, methods and software’. Their full definition follows:
Gartner: Definition of BPM
BPM is a management practice that provides for governance of a business's process environment toward the goal of improving agility and operational performance. BPM is a structured approach employing methods, policies, metrics, management practices and software tools to manage and continuously optimize an organization's activities and processes.
So, where does this leave you? Probably a little confused. You’re in a business function and you want to improve your operation. You can tell the difference between SixSigma, CMMi and EFQM. You’re looking for tools that can help you with this improvement.
However, all software under the BPM banner looks the same at the outset – or at least seems to offer the same benefits, especially if you read vendors’ claims on their websites.
‘…has been helping to build better businesses for more than three decades.’
‘…continually manage and deliver improved business performance.’
‘…helps organizations gain better insight into their business, improving decision-making and enterprise performance.’
‘…to help customers reduce costs, improve service and achieve agility.’
These quotes were taken from the websites from a major ERP vendor, a process automation start-up, a business intelligence player and a process-modeling vendor. So which is which? Beats me. Which is why my clients are constantly asking me to unravel the ‘process conundrum’.[1]
And just when you thought you’d understood the different vendors’ solutions, a spate of acquisitions of complementary technology changes it all again.
BPM tools unraveled
Clearly there is software that supports Business Process Management – at the last count there were more than 200 vendors. This space will consolidate as some vendors combine through M&A, some retrench to focus on a small niche, while others fail and die.
This consolidation is creating vendors with a broader set of functionality, and Gartner has coined the term “BPM Suites” to describe them. The BPM Suites will have capabilities in each of the five circles in the diagram.
These capabilities fall under three broad headings which make sense to the end user rather than the Marketing Department of a BPM vendor. They are Simplify – Automate – Monitor.
Simplify
This concerns the capture and understanding of a business process from an end-user’s perspective. Ideally, this should be approached top-down in live workshops to get alignment and consistency from a senior level down to the shop floor and across the end-to-end process. The processes may be costed to establish the value of any proposed changes, and simulation may be used to establish the best way to streamline the process and assess impacts.
Automate
Once the processes have been captured and streamlined, they can be automated to improve productivity further. Automation can be implemented in a number of ways:
- Pure-play: If the process is very people-oriented it may require a ‘pure-play BPM’ software application which enables forms to be strung together to support the end-to-end process. A simple example is the expense process. It requires data to be captured in an expenses form by the claimant, which is then sent to the manager for authorisation. The form will sit in the manager’s work queue until they review it, add their electronic signature to authorise, and then send it on to the accounts team to pay it.
- Biz Rules: A further level of sophistication is to add some business rules. In our previous expense example, rules may determine who has to authorise expenses, based on the total value of the claim, or there may be escalation rules if the immediate manager is away. These rules will need to be coded and managed
Monitor:
Once the processes are captured, streamlined and automated, they should be monitored to establish that they are performing, to identify opportunities for fine tuning, or to show where more remedial work is required. Any metrics that are reported need to be pulled from existing systems and presented in the context of the processes, so a manager can see clearly what decisions to make.
Simplify then Automate, don’t simply Automate
Some software vendors seem happy to dive in and automate the current processes, hoping that automation will identify any weaknesses and opportunities for streamlining. Call me cynical[2], but these are more likely because the Automation vendors do not have strong products in the simplification area. For them, talk of simplification means that any project has probably been delayed for six months. Therefore, they fall into the ‘Simply Automate’ camp.
Simplification software vendors are not saints either. They appear unwilling to help the organisation automate the streamlined processes, as they’d prefer to focus on identifying other areas of the business that could be streamlined.
However, there can be a smooth transition from simplification through automation to monitoring. Currently this is achieved through integrations and alliances between vendors, but pretty soon we will see full BPM Suites offering all the capabilities.
This is much like the world of operational applications ten years ago. Once there were standalone customer systems, stock control, order management, accounts and manufacturing. Now they have been rolled together and delivered as ERP systems made up of tens of integrated modules. The same aggregation of products is starting in the world of BPM. An example of the start of this roll-up is the acquisition of Staffware (Pure-play BPM) by Tibco (EAI).
So, looking at this set of software in a different way- the top of the triangle is the strategic direction setting, leading to a top level process diagram or strategy map and related key targets such as profitability, revenue growth, ROCE (Return on Capital Employed) etc.
Benefits of simplification
So can an organisation get benefits through Simplification without using any Automation vendors? Yes. Many organisations already have core operational systems which work, and simplification simply enables them to optimise how they use their systems. Here are some real life client examples of simplification
‘Project scope was a SAP & Siebel rollout, which was reduced from 36 to 18 months, the quote process reduced from 14 days to 10 mins, and no additional spend to achieve Sarbanes-Oxley.’
‘For a project based software development organisation, $50m new business, $21m savings from process improvement and achieved CMMi Level 3 – six months early.’
‘A distributed paper-based operation in 80 offices. Rationalisation & streamlining processes across 1,000 people generated $8m savings in year 1, and a further $15m in year 2.’
The additional benefit of addressing simplification before automating is that the automation effort is focused in improving value-added activities, i.e. it is not automating the ‘invoice error correction process’. Streamlining will eliminate this process by fixing the invoicing generation process to eliminate errors so they don’t need to be corrected.
Integrating modelling tools and automation tools
Very visual hierarchical modeling is key to communicating change across end-user organisations. But these models are also critical in eliminating any ambiguity in describing the business requirement, which often occurs with a purely textual document.
The information held in the models needs to be transferred into the more technically-detailed single-level modeling that the automation vendors provide for IT analysts. The interface is based on ‘similar looking’ models, but the IT analyst plays an important role working with the end-users to interpret and validate the processes to be automated. This activity enables the additional technical and contextual information to be added to the process model so that it can be automated (executed). [4] Compromises or changes from the end-users could dramatically increase the performance of the automated application, or massively reduce the development effort.
Therefore, blindly (or automatically) converting the end-user’s view of process into a technical view, pressing the button and having a running application is neither desirable nor feasible. There was a dream of a company where the end users can change a process by moving boxes and lines around, and in the morning the core applications (SAP) have been reconfigured. That would make the company infinitely agile, but I doubt that the end-users could keep up and understand the changes, leading to complete anarchy.
Benefits from automation
Automation should build on and multiply the benefits achieved by process simplification, and as the models have been built top-down there can be confidence that there is alignment between the lowest level automated activities and the aims & objectives at the top of the organisation. So can you get benefits from automation without some level of simplification or streamlining first? You may certainly see benefits, but these will never be as significant as when combined with simplification.
The benefits you get from automation are:
‘Quickly implement the appropriate controls in order to enhance compliance capabilities in Accounts Payable and Accounts Receivable processes.’
‘Identify distressed deliveries and act immediately before the shipment arrived back at the company. These capabilities saved money on each shipment and greatly improved the customer experience.’
‘Guide users through the validation and approval process for incentive compensation which reduces the amount of human error in the previous cycle of manual calls, e-mails, and faxes.’
Standards, standards everywhere and not one everyone agrees on
Standards must be developed so that the integration between Simplification vendors and the Automation vendors can be as clean as possible – in both directions. There have been a number of standards proposed for interoperation of the Automation vendors. But this is not the most important area, unless the organisation is looking to standardize on one automation vendor. Of more importance is the integration between Simplification, Automation and Monitoring, and there are emerging XML standards.
Let’s be clear. You wouldn’t expect a normal end-user to be able to read or write BPEL, BPMN or other similar standards. BPEL (Business Process Execution Language), pronounced ‘Bee-ple’, is essentially an XML programming language for defining the automation of a process, which a process engine use to run (automate). BPMN (Business Process Modeling Notation) is more end-user friendly, but both BPEL and BPMN are focused on the systems elements of a process i.e. the bits than need to be automated, which is only part of the models held in the Simplification vendors’ software applications.
The integration journey
So the end-to-end journey for BPM is shown in the diagram:
‘Senior management set strategic direction and then build out an end-user hierarchical model of processes and metrics (Simplification). This model is transferred into a set of IT tools that allow technical context detail to be added and then the process to be executed (Automation). The metrics generated are fed back into the end-user model to present them in the context of the processes (Monitoring).’
How this happens, in the nitty-gritty detail is the topic of a more detailed paper ‘The nitty-gritty of the integration journey’. It describes in detail, based on practical examples not theory, how you can build a complete solution, integrating each of the technologies. It will also discuss how this approach supports the design principles of Service Oriented Architecture (SOA) development and delivery.
Conclusions
Correctly applied, BPM can add a huge value to organisations, as they fight to streamline processes to eliminate non-value-added activities, and then automate those that are left to reduce costs, improve accuracy and compliance. Once the processes can be monitored and problems highlighted, users can see the metrics in the context of processes and make better decisions and improvements.
This correctly positions BPM at the heart of any organisation’s intent of improving their performance.
[1] Conundrum: A paradoxical, insoluble, or difficult problem; a dilemma. Not to be confused with an Oxymoron, which is where two terms contradict – such as Military Intelligence or Microsoft Help.
[2] A Cynic is what an Optimist calls a Realist.
[3] I’m hesitant to list any other vendors as they could be acquired by these three and it would date this article
[4] or ‘Orchestrated’ to use the Service Oriented Architecture (SOA) lingo.
posted by Ian Gotts at 8:54 PM
14 comments
