BPPM Implementation Considerations - Part 1: Meet your business requirements

Three years after BMC ProactiveNet Performance Management (BPPM) is released, now most BPPM customers reached a conclusion that BPPM implementation is more than just software installation. But what make a BPPM implementation a successful one? What do you need to consider before diving into installation details?

"BPPM Implementation Consideration" blog series will try to address several important considerations at requirement level and architecture level.  Implementing BPPM is a lot like building a house. Many considerations at requirement level and architecture level are like the foundation of the house.  They need to be determined at the very beginning.

The most important consideration in BPPM implementation is your business requirements. The management of your organization, your entire implementation team,  and other stakeholders should have a clear understanding on a list of business requirements that your BPPM implementation is expected to meet.  Then you will need to translate this list of business requirements into a list of technical requirements with a category assignment such as mandatory, strategic, cost-saver, and nice-to-have.

Only now you can map each technical requirement into a list of detailed BPPM features and prioritize the implementation of each feature.  This will become your project scope.  Based on your project scope, you can plan your project timeline and budget.  If you outsource your BPPM implementation to a consulting company, it is critical that you do your homework on your business requirements and technical requirements first. Then work closely with the architect (not just the project manager) of the consulting company to determine the project scope.

However many new BPPM customers I have talked to seem to do it backwards.  They came up with a budget first without knowing exactly what BPPM features to implement and how long the implementation will take.  Then they picked up a list of BPPM features to implement from product datasheet without knowing how each feature relates to their business bottom line.

As an example, here is the process taken at one of my past clients.  One of the top business requirements was to cut down the cost on Remedy Gateway licenses from multiple monitoring software vendors.  This was translated into a technical requirement like this: Alerts from multiple monitoring software must be integrated into one alert management tool to communicate with Remedy for ticket creation. This requirement was categorized as cost-saver.  This technical requirement was mapped into these BPPM features: Event to BPPM cell integration through API and SNMP traps, msend API installation, SNMP trap adapter high-availability implementation, custom BPPM cell MRL rules to process events from multiple vendors, IBRSD high-availability implementation, and event to ticket categorization in BPPM cell.  The return was a 6-figure annual license saving year after year with an investment of 5-figure consulting fee.  This ROI went straight to help business bottom line.