The variables and circumstances surrounding the debate are too enormous to fully discuss in exhaustive detail, but suffice it to say, they can be extremely contentious and have polarized our BI universe for years.

Historically businesses would “buy to standardize, build to compete.” This meant that you would buy to automate every day, commodity-like processes and build when your core processes provide differentiation for your company.

Unfortunately, the world today is characterized by time to understanding and time to action so this old proverb isn’t as definite to apply so simplistically.

Given the criteria an organization must consider before truly making the right decision, the two schools of thought require some basic analysis.
Building Your BI Solution

I’ve seen the “build” mentality boiled down to two basic variables –

1. Cost

2. Customization

Let’s take a look at both here.

Quite frankly, the cost variable is almost a delusion that continues to manifest itself in the minds of ERP users everywhere. The fundamental idea is that building a BI solution is going to be cheaper to manage internally (or with the help of trusted outside consultants) than purchasing it out of the box from a vendor.

They also figure that they can account for every cost in the process by keeping the labor requirements close to home. The costs are typically gradual as well, so instead of shelling out six figures at the outset of implementation, you figure you can distribute the costs evenly.

Secondly, the customization piece typically stems from the belief that – with the complexities of the organization – it’s better to build your BI solution and adhere closely to the idiosyncrasies and realities of your operations. You alone are properly able to align the specifications of the BI solution to the business process, map it all out and plan accordingly, right?

There’s also a bit of exceptionalism involved, too. The sentiment is that organization might be so unique that it’s going to be impossible for a vendor to understand them to the point where their analytics reporting packages will satisfy their needs unconditionally. Without delving into the egotism of it all, some organizations might contend that they are best suited to devise their analytics as opposed to enlisting the help of a vendor who they believe aren’t quite tapped in to the intricacies of what they’re doing.
Buying a Packaged BI Solution

The most compelling arguments for the “buy” approach can be distilled down to the following:

1. Time to value/result

2. Risk mitigation

3. End user adoption

The first attractive variable here – the time to value/result – has to do with the amount of time, effort and money involved to deploy a functioning system and begin demonstrating real value to your user base. When you buy, there are undeniably many components and tasks that have simply been built into the application that are designed to minimize the effort on the customer’s part.

An example of this is the Dynamics application’s metadata stored within the application layer or the build out of an operational data store that’s required for a successful deployment. Tasks like these requires a significant amount of time to process and will carry a certain amount of risk. Vendors have conducted these projects countless times and can leap frog these tasks quickly, taking you closer to full implementation.

Secondly, BI projects by default are replete with risks due to the inherent nature of analytical systems. Issues like data quality, lack of end user requirements, system scalability and BI tool suitability all add up to large amounts of project risk.

The “buy” approach has taken into account the risks faced by failed implementations and has successfully adjusted for them. The risk is absorbed by the vendor and the experienced garnered by numerous deployments mitigates its future occurrence. Tell me – is it riskier to build your own house from scratch or commission the task out to a professional, commercialized home developer with years of experience in building homes?

Also, the personal risk level is of extreme importance. When someone claims responsibility for a BI implementation project, their personal and professional ownership evolves into a high stakes game, at the executive level or otherwise. A vendor also has their reputation on the line, but by virtue of their experience, the risk is dramatically mitigated. Thus, the stakeholder on the customer side feels empowered knowing that their personal risk is a fraction of what it might be pursuing the «build» path since they’ve tapped into the vendor’s critical mass.

Lastly, the single most important measure of success for a BI project and the most compelling argument in support of the “buy” mentality is the adoption by the end user community. More than 60% of business intelligence implementations fail due to lack of end-user adoption, primarily caused by insufficient understanding of how to apply the BI tool to real life business scenarios.

Vendors offering the solutions spend years brainstorming the connection between analytics, dashboards and KPIs, and how those will translate to tangible business situations. They survey the industries they serve and cater directly to them, making a very cognizant attempt to ensure their applications will resonate effectively.

Their solutions typically come packaged with thousands of pre-build “answers” to these business questions. These answers boost the usability of the application and underpin the ability to get large numbers of users adopting the solution and integrating it into their company’s informational culture.

Now, having defined and operationalized the most common components of these two approached, let’s take a look at the infographic: