The ‘business’ in business intelligence: There’s NOT an app for that

Ours is a society of technophiles. We readily adopt – and rely heavily upon – the software that powers our digital devices to entertain us, to make us more productive, to monitor our health, or to get us safely from Point A to Point B, and back again.

With this passionate (some might say “frantic”) adoption of consumer technology, it is understandable that we are encouraged to believe that a compelling, easy-to-install, easy-to-configure software solution already exists to address our most pressing personal and business challenges. “There’s an app for that” has become as axiomatic as “Nothing is certain but death and taxes.”

Perhaps an app does exist for *almost* all personal productivity and entertainment needs, but in the case of enterprise business systems and the workflows they enable, a software application resides within a COMPLEX and MESSY ecosystem of people, politics, conflicting expectations, and ultimately limited resources.

Start a conversation about addressing a business challenge with the question “what vendor tool/application/platform should we select to address problem X?” and you are already heading down the wrong path, as emphasized in the first two risks of Chris Doig’s 18 enterprise software selection risks and how to avoid them.

In my line of business – professional software services – we call this “jumping to the solution.” At the risk of preaching to the converted, I want to remind us all that a technical tool is not the solution to a business performance challenge – it is simply an enabler of successful execution, once we understand what we want to execute.

Cards on the table

I should probably admit that I am the worst offender of my own guidance to clients. As someone who has spent the majority of his career designing software solutions and writing code, I have an innate obsession with “talking tech.” It’s just part of the developer and software architect’s DNA.

My particular area of professional interest and focus, Business Intelligence (BI), Data, and Analytics, moderates my natural enthusiasm to move immediately to discussions of tools, platforms, and languages however. BI is all about the business drivers and designing a system that models and implements the capabilities most needed for enterprise users to obtain useful insights. Tool decisions like “we should use this digitally-calibrated Craftsman nail gun” always take a back seat to business capability decisions such as “Are we trying to cut that board into equal lengths, or just attach it to a window frame?”

A common scenario

Take for example the issue of enterprise data quality, or more accurately, the perception that your organization’s corporate data is of poor quality and therefore provides little value to your business users. A strategic priority is to leverage the value of that data.

One approach is to invest in a fancy new tool, let’s say for Master Data Management (MDM).  Plenty of excellent, well-designed MDM platforms and tools exist on the market, and the list of features they provide are indeed impressive. With one of them, your organization can create clean, well-scrubbed master lists of customer, or product, or location data. Problem solved – the world is good.

But then inevitable business questions and requirements start to arise during implementation, all of which we have seen in real-world client scenarios:

• Who makes the decisions regarding how entities like “customer” or “product” are defined? Do we all agree on the rules? How are these decisions communicated down the organizational hierarchy?
• How do we publish and make visible our policies on centrally-curated data? How do we audit and enforce compliance with using the master lists?
• Much of our required data arrives from non-curated, third-party sources; it is of poor quality, and only relates marginally, or not at all, to our master lists. How do we handle that?
• Many of our users need to include data in their reports that don’t exist within the master lists; this data resides in multiple sources.
• Historically, our business users have employed spreadsheets to create their own reports and analysis from dubious data sources; they tend not to wait for IT-created reports.
• Etc.

The list above will continue to grow and evolve based upon your particular business scenario. After careful analysis, you may discover that your organization has a “data governance,” “data access,” “data consolidation,” or “self-service reporting” problem – or all of the above – that is not addressed by the feature set of the tool your organization purchased.

Start with the goal: Required capabilities, not available features

In your role as a business manager, director, or executive, don’t allow your well-intended, enthusiastic and almost assuredly very skilled technical team members to derail the much-needed business capabilities discussion by “jumping to the solution” too quickly.

In a market dominated by hyped and trending new technologies (No SQL, Big Data, Machine Learning, Data Visualization…take your pick), the importance of identifying and prioritizing the business needs – what do we want to do, why do we want to accomplish it, and is it worth the cost – is the most important step to take before making a business investment in a technology tool or platform.