Business activity monitoring (BAM) was a separated product niche until about five years ago when advanced business process management (BPM) vendors began including BAM capabilities in their product suites. The objective was to close the loop of continuous process improvement by providing business users with process monitoring dashboards.

Unfortunately, BAM adoption rates remain relatively low – dependent on industry, Forrester Research shows adoption rates to be between 20 and 40 percent of enterprises. Organizational politics, lack of skills, and lack of funding were found to be the primary roadblocks to BAM deployments. These issues are not entirely new as architects encountered them during the first waves of BPM and data warehouse implementations. But BAM implementations face the additional challenge of working in the operational dimension, mixing time- and individual-performance issues.

With the challenges facing BAM adoption in mind and based on Forrester's analysis, this article presents three best practices that will jump start your project and help you choose the right metrics and alert levels.

What is BAM?

BAM is software that lets organizations continuously monitor multiple key performance indicators (time, costs, quality, productivity and so on) of business activity. BAM enables fast reactions to problems during process execution by proactively detecting trends in operational performance and (hardware and human) resources constraints.

The general objective of BAM is to help process owners and participants to continuously improve productivity, resource usage and operational response. The immediate goal is to quickly alert operational employees when situations require attention, providing them with enough information to assess the situation and enabling them to take corrective action as soon as possible. Both BAM and operational intelligence contribute to the trend Forrester has previously labeled "enterprise performance management," which is about providing the right information at the right time to the right person.

Why Isn't BAM being deployed?

Many organizations are either in the early stages of BAM implementation, are not fully knowledgeable about BAM or lack BAM-related skills, but these factors alone do not fully explain the low deployment rates. Forrester's research shows that customers implementing or maintaining BAM can fall victim to three obstacles. Failed BAM projects often:

Attempt to traverse vertical or horizontal boundaries in siloed organizations. Organizational silos are a known problem for many BPM projects. Firms have trouble translating high-level metrics used, for example, in Balanced Scorecard (BSC) into midlevel management and individual operational metrics.

Face political or cultural barriers. BAM provides performance transparency that was previously difficult to obtain. However, in some countries, particularly in Europe, companies face trade union opposition to using BAM as a way to judge employees' personal performance.

Are never-ending. After implementation, a BAM project continues to live on, often with a high degree of change. This can provoke budget challenges when only the IT budget funds BAM maintenance.

BEST PRACTICE 1: Create A BAM Center Of Excellence

Because BAM is still a relatively immature technology, people with skills necessary to implement and maintain it are in short supply. And with product features continuing to evolve, BAM implementations require continuous support for users. To satisfy this need, create a center of excellence to:

Capitalize on available know-how on BAM project management and technologies. Establish questionnaires, interview guidance, and checklists to improve the efficiency of dashboard development and maintenance. Products are still evolving, so you need to guide business users on release schedules and new features for particularly complex dashboards.

Act as a facilitator between business and IT. Decision-makers, operational middle management, and IT staff must collaborate to create effective metrics. Establish a good relationship with the business and gain business credibility by facilitating the transformation of high-level KPIs into operational indicators. Doing this well requires a broad view of the business and an understanding of the various factors that should be considered to accurately assess business situations.

Relate to your BPM center of excellence, as required. BAM skills are still rare in the marketplace, and the situation is even worse within the enterprise. Reusing and sharing skills between the BPM COE and BAM COE can make sense, particularly if BAM technology is directly linked to your BPM choice. Most of the BAM COEs Forrester has encountered are independent. As BAM adoption increases within BPM implementations, organizations will evolve toward managing BAM competencies within the BPM COE.

When creating a BAM COE, avoid choosing a team that only has a single skill set – for instance, data warehouse designers or architects often make bad BAM professionals because they lack event- and real-time orientation.

BEST PRACTICE 2: Engage Operational Staff and Middle Management Early

The human dimension is the key to a successful BAM deployment. Organizations should:

Choose the first project carefully. Quick wins target the right audience. The project must quickly demonstrate BAM's value to business people and particularly to the first target users — the business operational staff and middle management. Follow an iterative project approach.

Train operational users and evangelize the capabilities of BAM. Operational users are sometimes reluctant to adopt new tools. They justify their role in the organization because they have developed their own paper- or spreadsheet-based tools to track their own metrics on productivity or quality. Or they just use their experience to determine how to optimize delivery. But BAM will bring them (and their top managers) more transparency and eliminate the classic battle regarding the interpretation of reported numbers. Plan for the learning curve users will experience during training.

Manage expectations before, during, and after the project. After an initial period of reluctance when operational staff members think BAM is all about managers overseeing their productivity, operational personnel will start to discover the power of BAM tools. This can lead to "transparency syndrome:" a desire to ask for more dashboards and alerts and a belief that showing every number collected increases control over complex systems and processes. But too many dashboards and alerts can kill the effectiveness of a tool. In addition, each BAM product has limitations in terms of the data it can collect as well as the ability to link to historical data.

When working directly with mid-level management or operational staff, avoid characterizing the BAM project in an insensitive manner. Business process reengineering still has a bad reputation in some countries where the corollary to process improvement is often staff layoffs. It's also important to avoid frustrating operational users by not giving them the means to correct a condition behind an alert.

BEST PRACTICES 3: Choose The Right Metrics And Level Of Alerts

BAM projects hinge on choosing the correct metrics and level of alerts. To ensure that the alerts provide the appropriate information at the right level of detail, BAM project owners should:

Work with stakeholders to transform business objectives into dashboards. The business owner or business analyst on the BAM project usually establishes the initial business objectives. During the project, these business objectives are translated in lower-level KPIs that support operational and middle management participation. Understanding how stakeholders work and how they translate high-level objectives into low-level KPIs is a cornerstone of a BAM project.

Refer to initial objectives rather than KPIs. As the project progresses and the business users learn BAM platform capabilities, they sometimes forget the initial objectives. Constantly revisit the high-level objectives and verify that the corresponding dashboards really support these objectives.

Choose a representation that simplifies interpretation and guides action. One classic mistake is to track each defect rather than the percentage of defects. Tracking absolute numbers can force users to make internal calculations to obtain the level of information they need. It also leads them to ponder whether they should do something to address each defect or if the defects they're seeing fall within the defect tolerance. Analyze your representation choices and try to avoid values prone to multiple interpretations. Sometimes this will require several trials.

Deploy to users gradually. Quality testing with a limited set of users is a key to BAM project success. Pay attention to user feedback to understand if an indicator, its representation, its position and the other related information provide adequate context and are meaningful to all types of users. This process often leads to important iterative adjustments.

Pitfalls include failing to measure what's important to operational staff and failing to avoid alert storms during initial deployments. When some users discover the power of BAM, they want more and more alerts, worrying that they'll miss something. Others multiply the volume of alerts because they think they will control more if they know more. Keep alerts to a manageable level so users and managers don't fall prey to alert fatigue. The idea is to spot the important exception conditions so your people can react and take action to correct or avoid performance problems.

Henry Peyret is a Senior Analyst at Forrester Research, where he serves enterprise architects. For free research and a diagnostic tool to assess your organization's BAM capabilities, visit www.forrester.com/iebam.