Best Practice (BPM)

March 29, 2006
Volume 4, issue 2

Download PDF version of this article PDF

Best Practice BPM

In business process management, finding the right tool suite is just the beginning.

DEREK MIERS, ENIX

Just as BPM (business process management) technology is markedly different from conventional approaches to application support, the methodology of BPM development is markedly different from traditional software implementation techniques. With CPI (continuous process improvement) as the core discipline of BPM, the models that drive work through the company evolve constantly. Indeed, recent studies suggest that companies fine-tune their BPM-based applications at least once a quarter (and sometimes as often as eight times per year). The point is that there is no such thing as a “finished” process; it takes multiple iterations to produce highly effective solutions. Every working BPM-based process is just a starting point for the future. Moreover, with multiple processes that could benefit from BPM-style automated support, the issue becomes how to support dozens or even hundreds of engagements per year.

As the intervals of change get shorter and shorter, companies need to develop effective methodologies to get around the business optimization cycle quickly enough.

Figure 1 depicts a way of organizing activity and ensuring that a project stays on track. The methodology involves many smaller iterations focused on a particular topic, each with “playback” sessions in which the BPM team, subject matter experts, and business managers interactively validate newly developed functionality. This approach ensures that no surprises emerge along the way, while delivering the flexibility to change as needed. There are iterations in the requirements area (discover and understand), iterations during the design phase, iterations at build and test, etc. Further, managers need to monitor the process and control the way in which it operates. Before repeating the cycle, the analyze and optimize phases involve several additional iterations as business analysts and managers experiment with alternative scenarios.

Given four or five business optimization cycles per year, each overall cycle must complete within three months. To achieve this, it is necessary to time-box the different phases of activity. Otherwise, the temptation is always there to spend more time, which encourages scope creep and increases the risk of project failure.

Process Discovery and Understanding

Every organization has a different starting point and, as a result, different needs. Some already have a defined process; others are not as well developed. Some want to emphasize automation of the process, whereas others need better traceability, visibility, and performance measurement. Either way, the first objective is to understand the process. Instead of developing a 400-page requirements document with every detail tightly specified, the organization should focus on tying down the core functionality that will deliver the most value.

There is always a need to capture the as-is process. The underlying requirement is the ability to step outside of the process and understand it fully. The key protagonists need models that allow them to communicate effectively with each other. Secondly, these models will form the underlying structure to underpin the capture of baseline metrics. It is important to gather reference metrics to ensure that the team can later prove the performance improvements.

To achieve a rich appreciation of the process, it is necessary to model the process at a high level, from a number of different, complementary perspectives. Assessing the business situation using a set of complementary modeling techniques allows people to comprehend the fundamentals of the process better. The ideal techniques for this phase are:

Flow diagrams to look at the order of activities, using BPMN (Business Process Modeling Notation).
Role activity diagrams to focus attention on role interactions and the desired behavior of the various actors.
Object state transition network models to focus on how the things moving through the process change state.
Capability models to look at the process as sets of reusable business components. A capability may be composed of other capabilities or implemented by a procedure (BPMN-style model).

The emphasis here is on understanding the process, not building models for transformation into code or executable process definitions. This then enables both the business analyst and the business user to step outside of the business-as-usual view and see the process differently.

Given suitable access to subject matter experts, a good rule of thumb is that this phase of activity should complete within a week or two. Although this might sound challenging, it is entirely feasible. The trick is to ensure that models are at a suitably high level. The team should always keep in mind the purpose of the modeling and the intended audience. Models should be detailed enough to drive understanding and discussion, but no more detailed than is necessary to support this aim.

From Design to Deployment

A comprehensive BPM suite is necessary to underpin the target process-enabled application. The BPM suite provides a configurable platform that executes procedural models, delivering work to the relevant employee or partner (or even customer). It ensures traceability of individual cases of work and guarantees compliance. Modern BPM suites include integrated process modeling and business rules environments, integration facilities, sophisticated user interface capabilities, and powerful analytics.

When developing the actual BPM-enabled application itself, the BPM team will find it much easier to gain clarity if they have a deep understanding of the process provided by the previous phase. Rather than attempting to define 80 to 90 percent of the final functionality, the team should start with tying down a more modest target of around 20 to 40 percent that delivers the vast majority of the value.

The process, however, is just one area where work is required in the development and implementation phases. Focused effort is essential to ensure effective integration with third-party applications. Similarly, the user interface needs special attention, as do the metrics gathered and the mechanisms provided to managers for controlling the functionality.

Rather than trying to address all issues together, the team should focus on just one aspect of the development before moving to the next. They can create a separate subphase of work for each facet:

• Process flow. In the initial iteration, the aim is to agree on the core 20 to 40 percent of functionality that will deliver the bulk of the value. Although a fair amount of modeling was undertaken when looking at the as-is model, this effort is all about creating the to-be process. Although organizational change may be considered a deployment issue, the way in which activities are assigned to the groups and roles will also be important.

• Integration. This subphase focuses directly on information extraction and update from/to external applications. Associated with this subphase is design of the data for the process. Again, ensuring that the data model is developed separately from the as-is model ensures that team members design and support what is necessary, rather than taking for granted what is already there. The deliverable should concentrate on proving to the user community that the necessary data can be placed on a default user interface (i.e., do not attempt to customize the user interface).

• User interface. Ensure that the screens deliver the information required by the various roles involved in the process.

• Metrics. Explore the management information deemed necessary, how this data is gathered, who should have access to it, and how it is presented. The BPM suite should capture all the necessary information, often referred to as KPIs (key performance indicators). It is worth noting that the metrics used to track process efficiency and effectiveness may differ significantly from the data used to maintain the state of the process.

• Controls. Business managers will want a way of throttling performance of the process, allowing them to control process execution. They need mechanisms that help them cater to peaks and troughs in demand, or influence the way in which business rules apply.

It is important to separate these portions of the development, as this will allow specialist resources in the team to focus their efforts. Depending on the situation, the order of these subphases may change. For example, if extracting data from third-party applications will present the greatest difficulty, then this subphase should probably run first. Of course, in many projects, individual subphases may reiterate based on feedback from their particular experts and managers.

Moreover, each subphase allows the team to present results to the subject matter experts and managers of the business area. Supported by a shared model approach, these interactive playback sessions ensure that users can see the implemented functionality requested. Moreover, because the outputs are graphical, participants can quickly step through the changes made since the last iteration.

The capabilities of the BPM suite should ensure that project team participants have direct access to all related events, rules, user interfaces, process flows, code, and analysis from the same tool set, in the same context. The product should not force application developers and analysts to switch tools or contexts to see what is going on in the process.

Monitoring and Control

The capabilities of the system to support effective business monitoring and control derive from an effective design and deployment phase. This section discusses the types of capabilities delivered. Several perspectives are important, including dashboards, alert and escalation mechanisms, control loops, and personnel management.

• Dashboard-style user interfaces deliver appropriate metrics to managers and supervisors. The assumption is that managers will intervene where necessary to expedite items of work as long as they have suitable visibility on work in the system. Of course, the system itself can help facilitate this through the provision of mechanisms that enable the manager to inspect the item of work, reassign that item, or interact directly with the worker responsible. Moreover, the system can prompt individual users directly, bringing to their attention items of work that are in danger of exceeding any milestone or SLA (service-level agreement) established.

• Monitoring and control mechanisms should also enable suitably authorized managers to direct the overall operation of the process. When most vendors talk about BPM and continuous process improvement, they are discussing the larger, overall business optimization loop. They have failed to grasp the importance of the secondary optimization loop where suitably qualified business managers control the running process directly. Generally, this is a design issue. The application should have built-in capabilities that provide managers with the controls they need to throttle business performance. (See the Pulte Mortgage sidebar for an example.)

Analysis and Optimization

Analysis and optimization are usually the responsibility of the business analyst or process owner. In an ad hoc fashion, these people are looking to identify the problems and suggest changes for the next release of the application. They are looking at the overall business process, its historical performance, and related business data, with the aim of identifying ways to improve performance.

Of course, the KBOs should drive performance optimization. For most companies, adding more people (resources) to a process to improve performance is just not an option. The best BPM products provide mechanisms to test alternatives (other than simply adding resources at bottlenecks).

Simulation

In response to this need, most vendors have focused on providing simulation tools for comparing different what-if scenarios. At its core, simulation is a statistical technique that uses probabilities to predict average activity durations, queue lengths, resource utilization, etc.

Usage of simulation should come with a few health warnings, however. Simulation is most effective when used as a way of testing assumptions. For example, if interest rates fell, leading to an increase in mortgage applications, what would the impact be on the ability of the company to provide the same level of customer service? At what point would additional resources be required? But simulation models are notoriously difficult to construct, with each linkage in the model requiring careful statistical checking. In the Pulte Mortgage example in the sidebar, that might mean checking the sensitivity between interest rates and the number of mortgage applications. Solving this problem entails gathering historical data to support this testing. The best BPM simulation tools available today extract this data from the running process model to provide the baseline information. This dramatically changes the cost/benefit ratio associated with simulation.

Optimization

Best-in-class BPM suites have optimization mechanisms that provide automated support to help determine the best means of process improvement. This takes simulation a step further, addressing some of its inherent difficulties. Rather than leaving it to the analyst to determine options for improvement, the system should help identify areas to consider. Moreover, it is often difficult to compare different simulated scenarios in ways that are meaningful to the business.

For example, business managers are usually most interested in assessing the effectiveness of a particular product or service. It is not good enough to know the average cycle time of all loans; they want to know the cycle time of the jumbo loan (since they know that has the best margin). Or they want to assess a particular line or service by sales channel.

Alternatively, they may want to analyze performance over time, comparing some slice of the past with current results or looking into the future. For example, rather than looking at the average over the last six months, the managers might want to compare the holiday sales season with the summer sales season. They might prefer to compare the amount of business in production today with the business situation three months ago, or the same period last year.

Growing the Team’s BPM Capabilities

How does an organization go about improving its ongoing BPM delivery capabilities? Clearly, experience will grow over time. But responding to the situation outlined in the beginning of this article—where the organization needs to support dozens of BPM engagements per year—has its challenges. Companies should develop a proactive strategy to manage and grow the knowledge of the BPM team, capturing insights and developing effective engagement methods.

The most common response to this challenge is to develop a BPM COE (center of excellence) or process management office. The idea is that a group of committed individuals focus on the processes of the company as they drive bottom-line profitability and performance. The team can support a number of BPM projects across the business, keeping momentum going across a broad front. They are usually responsible for developing common principles, language, frameworks, and methodologies for process development and process architecture management.

In the early stages, however, the COE can present unnecessary overhead as it typically has a much wider scope than is necessary for a pilot project. The COE concept comes into its own as the BPM program starts to address the needs of the wider organization. With more and more projects, the need increases for a coordinated and integrated approach. The COE provides a central repository for knowledge and best practices development around BPM projects.

Conclusion

For companies to make the most of BPM initiatives, they must first realize that BPM involves a different way of working.2 The methodology of BPM application development is vastly different from that found in even the most agile programming environment. Rather than the traditional waterfall-style implementation—where application functionality appears in large monolithic blocks—iteration and adaptation are prevalent in every phase of the development life cycle. Instead of a timeline measured in years and months, application updates roll out in a few weeks or months.

From a BPM technology perspective, it is important to identify a product that supports the entire BPM life cycle, facilitating the interaction of the various individuals involved, as well as identifying process trends and optimization options. Alongside the technology component, the vendor should provide a robust development and implementation methodology with direct support provided by the platform itself. The technology and methodology components are interdependent.

Process Discovery and Understanding

best practices

Identify subject matter experts for each area of the business affected by the process. Often there are assumptions made by those in related roles that prove to be incorrect.
Remember that the emphasis is on understanding. Use complementary techniques to help the stakeholders step outside of the box and see things differently. The techniques suggested are not the only ones available. The BPM team should test different modeling approaches and assess for themselves the ones that work best for their company and culture. Look at approaches that help challenge the status quo.
On complex processes, to ensure that the scope is at the right level, try asking, “Why?” five times. When clear answers are no longer forthcoming, that suggests the appropriate level of scope. For example: HR processes are inefficient. Why? It takes too long to bring a new employee on board. Why? There is no coordination between HR-IS, the recruiter and HR manager on where a candidate is in the process. Why? We have no way of tracking desired start date and when orientation needs to have occurred. Why? I don’t know. This sort of analysis will help identify the root cause, ensuring that the scope is neither too wide nor so narrow that the business benefit is minimal.
Ensure that the team is able to succinctly and specifically state the practical problems associated with the business domain. If that is not possible, then it suggests more work is necessary to identify the real priorities.
Build a roadmap of the short-, medium-, and long-term vision for the application. Identify chunks of functionality for delivery in successive iterations. Rescope the roadmap on the completion of the development cycle.

pitfalls

Problems can occur in this phase of activity if people set out to capture all potential paths through a process, all exceptions, or all potential activities. This is the root cause of “analysis paralysis.” IT-centric analysts wrongly assume that the path to success begins by populating a multidimensional modeling repository. In the short term, it can kill a BPM project as it distracts from the critical requirement of proving the efficacy of the BPM approach to the business.
Creating the “definitive” requirements specification is a waste of time. Documents by themselves are flat. Indeed, the whole notion of a definitive requirements specification becomes irrelevant in a BPM project.

From Design to Deployment

best practices

Ensure that comprehensive facilities are in place for continuous and ongoing collaboration between the business leadership and the BPM team.
Make sure that the end users realize that this is not a “once and done” system delivery. They need to understand that the team is coming back for future iterations so that they do not try to cram every detail into the initial release. It may be necessary to produce a functionality roadmap with future phases of activity linked to areas of functionality not yet implemented. This will help the BPM team and the end users focus on the delivery from this phase of development.
Rather than attempting to transform the as-is model developed in the initial phase (process discovery and understanding), build a new set of models inside the BPM suite. This helps to focus on the desired functionality for this phase. It removes the temptation to bend the rules in the discovery and understanding phase (by attempting to put too much detail into models). It will also help ensure that the application leverages the features and facilities of the BPM suite.
Locking down the to-be process definition in the first iteration can be challenging. Even when users know that further iterations are planned, they will push for functionality that is less important. Zeroing in on what the business really cares about is often difficult. Separate the identification of the “happy path” of the process from the handling of exceptions. In the initial iteration of the process flow loop, it may be good enough to capture and support the happy path. Subsequent iterations could then capture the major exceptions, leaving the more complex exceptions to another release of the application.
Catalog and weight exceptions to help identify those that are most important. Look at each one in terms of its impact (to the business when it occurs), its frequency, and whether it is detectable today. A severe exception may occur only twice a year. Or conversely, an exception that happens frequently may have little or no impact on the business.
Separate the management of the flow of instances (all cases in the system) from the management of a single case.
It is a good idea for the team to carry out a fundamental reassessment of metrics as part of the BPM implementation. Explore how to integrate the business-relevant data (such as customer or product information) with information on cycle time, resource utilization, etc. When assessing KPIs, make sure that they support the company’s underlying KBOs (key business objectives). Further, take care to ensure that the measures will reinforce the behavior that the initiative is trying to encourage.
When presenting finished functionality for any particular facet, ensure that the workshop includes a wider group than just the managers and subject matter experts already involved. This helps remove errors, identify additional functionality for the next iteration, and encourage broad acceptance of the application when it is released into production.
Consider data and document implementation details of the process. They are normally the mechanisms invented to keep the process coordinated, rather than the essence of the process. Look for ways of achieving the real goals of the process without that mechanism of coordination. Removing them will probably drive a massive jump in productivity and/or cost reduction.
When integrating third-party applications, take the time to wrap them first of all in Web services to insulate the process model from any changes in back-end systems (and vice versa).
Remember that both the use and understanding of data evolve iteratively. This can have fundamental implications for the design of the process and integration mechanisms.
Ensure that a subject matter expert is available from each major role affected by the system. This is particularly important in the process flow and user interface areas. Share specialist resources across projects.
When selecting a BPM suite, identify a holistic environment that provides semantic consistency across different views as participants share the same set of models and configuration data. This minimizes any opportunity for miscommunication and lowers the cost of development.

pitfalls

Remember that processes will inevitably change during design and development as the details are uncovered. These discoveries can happen at any point during the development. Assess each against the agreed-upon scope of the project. If the proposed change has a dramatic impact, then identify it for a later iteration in development. Too much emphasis on trying to define process nirvana is of low value.
While designing and deploying the process, the temptation is to focus on its orchestration. Ensure that equal attention is given to the points of process failure. Evaluate each failure for its severity, occurrence, and the current controls to detect.

Pulte Mortgage Case Study

The people at Pulte Mortgage set out to change the model of customer service by becoming proactive and concluding tasks before customers would expect completion. Without visibility into the metrics of the process, however, managers found it difficult to spot opportunities for improvement. Through the implementation of an automated case-tracking application, they could identify areas where service improvements were possible. Only when process metrics were gathered was it possible to identify requirements .

For example, as a result of the better visibility into the process, managers could monitor the number of hours it took to push a case through to the point of offer. As the number of cases rose in the queue awaiting approval, managers realized they could influence overall performance of the process by lowering the credit-scoring threshold (where the system automatically accepts mortgage applications). As they reduced cycle time, the financial risk would rise. This does not mean that managers were interested in reconfiguring business rules in realtime. Rather, as part of the manager’s dashboard user interface, slider control mechanisms enabled this sort of control.

This is a business judgment, however, trading off higher risk against more rapid response to customers and hence, more business. As the managers came to understand the dynamics of these decisions, they could then start to embed that enhanced understanding into a more dynamic set of business rules that supported the decision (even to suggesting the level of automatic credit-scoring approval).

Monitoring and Control

best practices

Working with LOB (line of business) managers, explore how they would react to specific peaks and troughs in demand. Work out whether it is possible to provide them with mechanisms to influence resource deployment and throughput under these circumstances.
Ensure that appropriate dashboards are created for every level of the organization—from executives, whose dashboards might subsume multiple processes, to workers, who will want to “keep score” of their own productivity.
It is particularly important to provide a focus on the needs of teams and the management of the people within them. Concentrate on identifying how much work is coming down the pipe, and what the team has to get out the door today, tomorrow, this week, or by the end of the month. This can drive a better understanding of what their collective efforts can achieve and where they are struggling.

pitfalls

With every report requested, assess whether the information is actionable—can the BPM suite take action directly? Think of it as the difference between reading the news and making the news. Otherwise, it is easy to end up with a lot of “so what” data points and miss the big opportunities.

Analysis and Optimization

best practices

Process models are like a bikini. What they reveal is suggestive, but what they conceal is vital (paraphrasing Aaron Levenstein talking about statistics). In the BPMS environment, all process-related information should be accessible via the graphical representation. Ensure that the product allows direct access to all events, rules, user interface screens, flows, and analysis—from the same tool, in the same context. Best practice is to have one holistic environment. This gets everyone on the same page when communicating, thereby avoiding the so-called “telephone game” (however we end up describing that).
Along with analyzing activity durations and resource utilizations, it is a good idea to look at paths: identifying the percentage of work that follows the “happy path” of the process versus the percentage spent on exceptions or complex approvals.
The BPM suite should provide mechanisms to dice and slice the information on performance, linking historical process performance data with the LOB data of the application domain. The BPM suite itself should include optimization features that spot trends and suggest potential improvement options, identifying changes to business rules and process logic. Look for the ability to view this optimization data in the same diagram as the process-modeling environment.

pitfalls

Simulation is not an end in itself. It is one of many diagnostic tools. Do not rely on any one piece of information or one tool as being 100 percent accurate in its conclusion. Processes are multidimensional, and so is the “truth.” Use a variety of analysis techniques to isolate the most critical factors that affect the ability of the process in support of its KPIs and, as a result, underpin the KBOs of the company.
Avoid simulation models that are deterministic in nature—designed to prove to management a positive return on some proposed change. Such models often reflect the agenda of the modeler rather than the reality. They usually bury assumptions rather than surface them.

Growing the Team’s BPM Capabilities

best practices

As a first step, it is a good idea to conduct benchmarking exercises with other organizations. Rather than learning only from those of a similar size and culture, the group should also compare approaches with companies that have fundamentally different views of how to organize BPM initiatives.
Grow the process acumen of the team by assessing different approaches. Take time to weigh these different approaches (especially for process and business modeling). Rather than looking for a single approach for all situations, assess which techniques best support different types of scenarios. By necessity, this type of activity involves bringing in outside experts to educate and facilitate discussions
Adopt an iterative development methodology, supported by the appropriate technology. Linear application development methodologies just will not scale to handle the number of engagements. Neither will they provide the agility needed for survival in a rapidly evolving business environment.
Given the fundamentally different approach to development and implementation, it is vitally important to prove the effectiveness and validity of the approach. Look for a short, tightly scoped project that allows the team to build skills and experience. The project should have relatively low complexity and a clear business benefit.
Share the high-level vision with the business users along the way. Help them to understand the iterative approach, with multiple releases in quick succession. Otherwise, they will assume that the time between releases is infinite and will push for too much functionality in the first release. This makes it unnecessarily complex. Share the iterative builds with business users to make them more comfortable with the overall approach.
The relationship among process owners, business owners, centers of excellence, and individual BPM project teams requires careful consideration. Address governance issues comprehensively and early. Identify process owners to sustain/support applications once in production. Agree on change procedures, expectations on resource availability, etc.
The most important mechanisms to grow the BPM capabilities of the company over time are the BAR (before action review) and AAR (after action review). For each project, focus on short cycles of plan, prepare, execute, and review. For each project, phase, and subphase, plan the engagement with the user community. Set objectives for each deliverable and brief the team to ensure that they fully understand the rationale. Conduct formal BARs and AARs for the entire project and for each phase and subphase. By necessity, the BAR-AAR cycle for subphases will be relatively brief affairs. Encourage all team members to take notes and participate in these meetings.1

References

For more on BAR and AAR, see Darling, M., Parry, C., and Moore, J. 2005. Learning in the thick of it. Harvard Business Review (July-August).
This article follows a related piece that explores the best practices of BPM project success (available free at www.enix.co.uk). It provides advice on how to develop your BPM project blueprint, defining nine key stages and suggesting techniques that can support each phase.

DEREK MIERS ([email protected]) is an independent industry analyst and technology strategist. He has carried out a wide range of consulting roles—facilitating board-level conversations around BPM initiatives, establishing effective BPM project and expertise centers, and helping clients develop new business models that leverage business process strategies. Clients have included financial services companies, pharmaceutical companies, telecom providers, commercial businesses, product vendors, and government organizations.

Originally published in Queue vol. 4, no. 2—
Comment on this article in the ACM Digital Library