BI Application Convergence: Build, Buy or Both?

History Repeats Itself

To understand the trend in applications, one needs to look no further than the history of enterprise resource planning (ERP), which has gone through four levels of maturity.

1. Custom code. Until the mid-80s, the type of project I described was the norm. Organizations designed their own databases, code, screens and architecture.
2. Individual, off-the-shelf applications. The next wave was a series of individual applications that came mostly prebuilt. Two examples are general ledger systems and manufacturing floor systems. Both came as prebuilt applications that required configuration rather than custom coding. In most cases, the applications were standalone. For example, an organization’s data processing department (as IT was known in those days) was required to code a custom interface from each related financial system (payroll, etc.) to get transactions into the general ledger. There were a limited number of off-the-shelf applications, and many of the financial feeder systems were still custom systems.
3. Integrated applications. Following the success of individual applications, software companies started offering integrated application suites with similar functions or users. An example of this was the general ledger/accounts payable/accounts receivable combinations that formed the basis for the next wave.
4. End-to-end applications. Moving beyond integrated applications, the focus became end-to-end processes. Two examples are procure to pay, handling all functions from procurement through payment, and hire to retire, designed to handle all employee functions through the duration of employment.

Currently, BI and performance management are undergoing their own maturity evolution.

1. Custom code and online analytical processing (OLAP). Early decision support systems were custom databases running on PCs and other standalone systems. Data structures, loading and reporting code were all manually created. Adding to the challenge was the fact that coding standards prevalent in many of the mainframe systems were not adhered to in this first wave. It was very much the Wild West of BI.
2. BI platforms. As BI became more important to organizations, software vendors responded with integrated platforms that combined the database; extract, transform and load (ETL) tool; reporting; and analytics. These platforms allowed organizations to build applications that reached across various functional areas such as finance, marketing and HR.
3. Combined applications and platforms. Certain functional business areas were faster to adopt an application approach, such as finance with various consolidation, planning and budgeting applications. Additionally, as the enterprise resource planning (ERP) vendors consolidated, it became much more practical for vendors to prebuild the applications supporting these highly related business functions. Custom code is still required to provide management and performance intelligence on a wider analysis chain basis.
4. End-to-end BI applications. Similar to how ERP has defined end-to-end applications, BI will be able to provide seamless intelligence and performance management applications.

Where are We Now?

The industry is currently between level three and level four. Most organizations using any type of BI and performance management systems combine prebuilt applications and custom platforms.

As stated earlier, finance organizations were early adopters of prebuilt applications. There are three main reasons why finance adopted BI and performance management applications first. The first reason is availability. Vendors offered prebuilt applications to functional areas such as finance years before they offered them to other functional areas. Second, the standardization that exists in the finance business area, such as adherence to Generally Accepted Accounting Practices (GAAP), made it more economical and easier for both vendors and customers. Third, finance is very metrics-based and was a natural fit for the adoption of BI and performance management.

BI and performance management applications are not limited to finance, though. Other key areas where prebuilt applications have taken hold include HR, supply and customer service.

Build, Buy or Both

As new business requirements in BI and performance management emerge, organizations should take a structured approach to evaluating whether to build, buy or do a little of both. This involves a multistep evaluation process:

1. Understand the business requirements. Organizations must be able to express their business requirements. Whether this is in the form of use cases, structured specifications, report layouts or any other business documents, it is critical to understand what you want before deciding to build, buy or do both.
2. Evaluate components of the application. Prebuilt BI and performance management applications have different components that will be applicable to different organizations. The main components are: data model; ETL, key performance indicators (KPIs) and metrics; reports, dashboards and analytics; and metadata. With business requirements in hand, an organization can evaluate the match to each of these areas. For example, how closely do the application data model and hierarchies match the business needs? Are the KPIs and metrics matched to what the business requires? Does the ETL come prebuilt for the ERP and customer relationship management (CRM) sources in place? Most organizations will find that the result of using a structured approach to matching requirements to applications will be that at least part of their needs will be satisfied by a prebuilt application. With a match at hand, it becomes a financial decision on TCO of the prebuilt application versus trying to build your own.