Continue in 2 seconds

BPM Implementation: Don't Let Failure be an Option

  • May 01 2004, 1:00am EDT
More in

Back in the early days of business performance management (BPM), numerous implementations failed because dependable best practices had not yet emerged. The bad news is that these still are the early days of BPM. The good news is that by following some proven guidelines, you can minimize the risks during implementation to increase your project success.

We previously touched upon BPM system implementation when looking at the entire BPM project life cycle. Here, we drill into the major implementation steps. You'll see that as with other aspects of BPM, such as needs assessment and vendor selection, the implementation will have its familiar side. You'll also note pieces that are specific to BPM and should, therefore, be handled somewhat differently.

We break BPM implementation into four major steps: select and train the team, prioritize the modules to implement, address design considerations and execute the implementation. The assumption here is that you already have a budget, a vendor, an overall project plan and a timeline.

Select and Train the Team

As you weigh whether to have the project run by IT or by finance, we suggest you consider that the financial group will ultimately administrate the system. Usually, it makes sense to draw the BPM project leader from finance, with IT lending key support.

Two finance people should be deeply engaged as project participants early on so they can learn to be the system administrators. One individual will run it, and the other will be the backup. The team also needs a more senior financial staffer as the go-to person for complex calculations. For example, if your project requires tracking days sales outstanding, you will need an authority who knows exactly how that metric is derived in your company.

Typically, there will also be team members from your IT department focused on infrastructure, technical implementation and linking to data sources. Rounding out the group would be a vendor or third-party consultant who has hands-on expertise with the particular software system you've chosen.

The leader of the project team carries two external liaison roles. He or she will operate on a "dotted-line" basis to the senior tiebreaker, the project sponsor who can break stalemates when necessary. In addition, the team leader is the interface to the overall engagement manager. In last month's column, we discussed the role of a strategic engagement manager and the value of that role in a BPM initiative.

Choose the participants with consideration for how much of their time is needed and how much they can realistically be expected to devote to the BPM project. Once they are on board, announce the team to the company so they receive the cooperation they'll need.

To get up to speed, the team should take courses offered by the vendor. Your future administrators should enroll in the full-blown systems administration training. For your senior sponsor, there may be convenient, abbreviated overview training.

Prioritize the Modules

BPM implementations are often distinguished by having numerous, potentially standalone, components. A logical sequence to the modules might be self-evident, but sometimes the main driver is where the company has the greatest pain or where the earliest payback is possible.

Even with a high-level project plan and timeline in place, you should take stock of the software components and consider the sequence of implementation before work begins. When coming from a fix-the-pain perspective, the planning module(s) often jumps to the front of the line. Many companies still struggle with the entire process of planning. Coincidentally, it forms the foundation of your final BPM system.

Portal delivery is another element that is often chosen for early completion due to its quick payback. A portal can give rewards right out of the gate by delivering information to the masses. Implementing a portal first and using it to securely distribute existing enterprise resource planning (ERP) reports is not that difficult. The portal may constitute just a small portion of the ultimate value of your finished BPM system, but it's a good way for people to get introduced and achieve some comfort with the system.

Design Considerations

How does the system fit together? What are the common shared elements, and how do they interface with existing databases and systems in the company? BPM systems fundamentally require a chart of accounts that is consistent across all modules, an organizational hierarchy (or multiple hierarchies), plus clear categories of data you will track.

Avoid cloning structures from current systems. You are probably migrating from an existing system, such as a transaction system with limited reporting or an Excel-based budget system; therefore, the temptation to replicate familiar structures can be strong. Instead, stay focused on the output your BPM system is meant to provide. It might be evident that current structures (and reports) may not be the best choices.

There are fundamental design decisions that will shape the project. Will you track both current and most recent prior forecasts? How many budget scenarios will need to coexist for comparison purposes? What level of line-item detail will your company track and what does that imply for the chart of accounts used in the new system? Will you enable analysis along the line of management responsibility as well as legal entities?

Other issues to be addressed are system-specific, but fundamental and important. For example, you will need to decide how, when and where particular calculations are performed. It could be when data is entered, when it's saved or at report time. It probably depends on how frequently a particular number is viewed and the complexity of the calculation.

This is closely related to the elements of the system that will be most dynamic. You need a design that lets the system easily update those areas. If dozens of line items are added each month, try not to hardcode all line items into the reports. You need a change-once, impact-many structure that fits with the frequency of updates and data conversion processes.

The dimensions of the BPM system are spelled out during the design phase, and they often go beyond tracking by product, geography, subsidiary, market and customer. Additional dimensions are likely to come up for debate. Typically, the project will need to accommodate most of your company's existing legal, management and geographic structures. However, the inverse could be true, where new system dimensions get incorporated into the organizational structure.

A good rule of thumb is to stay output-focused. Think of the reports you want to get from the system, and you will be able to see if you are providing the right data structures. Before making too many promises, it's a good idea to be sure your desired reports are going to be feasible (i.e., the required source data is available).

Consider the impact on data sources. What is the source of data that will feed your system and reports? Is it entered manually, derived from spreadsheets or retrieved in batch form from legacy systems? Make format decisions early in the game so that all data is stored consistently, be it in thousands or whole dollars, summary level or detail, headquarters currency or local currency.

Look at the scope of your planned output. If it calls for dozens of reports, they should be prioritized. Those containing key performance indicators usually merit higher priority. Don't just automate all existing reports. You'll probably find that many of them are rarely viewed. Make sure the reports add value and tie to the metrics that are driving this BPM initiative.


These guidelines represent some of the lessons that have emerged from real-life BPM implementations. We recommend these practices because we have seen them contribute to project success. Our two most fundamental recommendations for BPM implementers are very simple. First, don't be reluctant to call on BPM-specific expertise where you can find it. Outside experts won't know the innermost workings of your company, but they know what goes into a good BPM system implementation. Second, approach the implementation with your eyes open, alert to BPM differences from the projects you've run before. Don't just assume it's like any other IT project. That should keep you on safe ground.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access