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.
Be the first to comment on this post using the section below.