In Part 1 of this article series, "Business intelligence and corporate performance management: What's the difference?" I discussed
Build versus buy is always an important consideration in an IT systems project. Often the default position is that buying a pre-built, vendor-supported software package has a lower total cost of ownership (TCO). But the conventional wisdom that buying has a lower TCO than building is based on an assumption that the purchased solution meets your business needs. If it doesn't, the cost to customize pre-built software -- or worse, the costs of changing your business to fit the software -- can seriously impact that supposedly low TCO.
When evaluating a build versus buy decision for CPM packages, it is critical to assess your business and technical requirements. Often, any IT systems purchase decision is solely based on technical and cost considerations. The technical specifications are clear, so it's easy to see what you are getting.
A CPM package evaluation, however, isn't so clear. In order to really understand what the CPM package provides you need to dive beyond the sales PowerPoint slides and into the details of what processes, metrics, data definitions and data sources are implemented in the package.
You also need to examine the software tools, such as BI and data integration tools such as extract, transform and load (ETL) functions, that you are buying with the package to determine how they fit into your existing architecture and standards. Once you've seen what the CPM package offers both from a business and technical perspective, then you should perform a serious gap analysis to determine if it actually offers what you need.
Quite often, when you evaluate a CPM vendor's software, you find a gap between what you need and what the vendor provides. This gap can be non-trivial, and often requires modifying all the application components such as KPIs, data models, reports, ETL data mappings and business application logic. The need for these modifications shifts the decision from build versus buy to build versus buy-and-customize (and maybe quite significantly.) This certainly changes the TCO equation.
The second realization that you arrive at quickly when evaluating CPM packages is that you might just create another data and application silo. CPM solutions bundle BI and ETL software, so if you are not purchasing from the BI vendor you already use -- then you are faced with adding another set of BI and ETL software along with the associated business user and IT training. Since many businesses have standardized recently on BI and data integration software -- it seems ironic that that decision may lock them into their BI vendor's CPM solution.
If you wanted to pick and choose particular applications from multiple CPM packages you'd probably be forced to implement multiple BI suites and ETL tools, plus you'd likely have incompatible data models, KPIs, reports and analytics across the packages. Building CPM silos is NOT what you want to be doing.
If your company has not made significant investments in BI yet or has not groomed sufficient BI skills, CPM software may offer a quick start approach to your firm. If you have invested in a particular BI software package and that vendor has CPM application specific to your industry then it would make sense to leverage that solution as your starting point.
It may be heresy, but I'm going to say it anyway: you can deploy CPM programs without buying a CPM package. You will use BI and ETL software tools, but of your own choosing. Yes, you may build your own CPM applications rather than buying a particular vendor's CPM package. And, building your own CPM application can mean that you're more closely meeting your business needs. And, ultimately, the most important factor for the success of your CPM initiative is that its processes, methodologies and metrics fit your unique business requirements, rather than having them fit your vendor's.
- Check out the complete list of Rick Sherman's contributions to SearchDataManagement.com -- including articles, podcasts and more.
This was first published in October 2007