In Montreal, as elsewhere in the world, the BI market is evolving rapidly. Organizations are investing more and more in BI solutions. From the point of view of BI technologies, we can observe profound upheavals (Big data, In-memory, etc.). A lot of things are changing fast around us, and we're taking little time to analyze the level of overall business intelligence maturity here in Montreal. In this article, I'm going to present my vision of a BI advisor in Montreal, based on my own experience as well as exchanges with other advisors and customers.

Organizations' lack of knowledge about BI

It's interesting to see that organizations in Montreal are somewhat unfamiliar with BI. Indeed, how many organizations are aware of what BI is? If BI were better known, wouldn't there be more user-initiated BI projects in organizations?

Organizations! This paragraph is for you... Know that even if you don't know it, you're doing BI every day. BI should not be seen as a gadget from the IT department. The aim of BI solutions is to provide users with data so that they can make decisions based on facts and not just on intuition. Whenever a decision needs to be made, a BI tool could support your thinking.

BI projects... proposed by IT?

If BI is there to solve business problems, why is it that most initiatives are taken forward by IT departments? Does IT need BI tools to make business decisions? How many organizations let IT make decisions for finance, sales or operations?

That's the reality of life in Montreal! Too few BI initiatives are initiated by the business side of organizations. As a result, BI projects become complex and time-consuming. IT usually goes the other way, coming up with solutions for their users before taking the time to analyze their problems in depth. This makes it difficult for IT project teams to analyze what users really need. Subsequently, traditional project implementation is usually long and tedious. When the final product is delivered, in the best-case scenario, users are generally disappointed, because the solution doesn't meet their needs, or their needs have evolved during the design phase.

Let's take the example of a BI mobility project for a retail organization. Typically, IT teams will justify this type of project with the following arguments: "we want to make it easier for different sales reps to access company information, so they can save time". Indeed, mobility can facilitate and accelerate part of the sales process. In hindsight, it may be that in reality, the non-value-added tasks of sales reps are elsewhere in the process, rather than at the level of information consumption. An automation solution could offer more value in this case. As a result, a mobile BI solution may not be the most appropriate in this situation. In this case, the ROI of a mobile BI solution would actually be lower than that of the automation solution.

Montréal child geek

It's interesting to see in Montreal how willing organizations are to test new technologies. This open-mindedness ensures that organizations are always on the cutting edge of technology.

It would be interesting to ask why organizations do what they do. Part of the answer may lie in how organizations deal with BI. When a BI project has failed in an organization, it's not uncommon to see a second BI project aimed at solving the same problems, but with different or better tools. Nor is it uncommon for the second project to fail. We could make the analogy of a child who starts to learn how to skate and, after his first fall, is offered new and better skates by his parents.

Technology in general, and BI technology in particular, should not be seen as a solution. They should be seen as an element that will support a solution. It's not with new skates that the child will be able to skate better.

What if we wanted to do things differently?

If we wanted to do things differently, we could focus on three areas. The first is agile project management, then BI solution architecture, and finally data governance.

Agile project management in a BI context is an approach that works. In a context where users are unfamiliar with BI, it enables them to focus on resolving their needs and delivering small pieces of the solution quickly. During iterations, user requirements are refined or new needs are identified, and the solution evolves along the way. The main advantage of this type of project management is that, at all times, users are responsible for the solution's final outcome. What's more, development can be stopped after two or three iterations, as users realize that the gain is not as great as had been envisaged.

BI solution architecture is an exercise that is generally forgotten in organizations. The solution architect is the person who is able to take a transversal view of the BI ecosystem. For new projects, he or she is able to anticipate problems that may arise as a result of over-demanding user requirements. As a result, he or she helps users to re-prioritize their needs and what is most valuable to the organization, while ensuring that what is delivered lives up to their expectations.

Data governance is a set of concepts and processes designed to define, store, maintain, distribute and enforce a complete, reliable and up-to-date view of metadata. The success of this type of initiative lies in the fact that it must bring together end-users, analysts and IT people alike. It starts by empowering the business side of organizations to take responsibility for their data, and will then begin to create an interest in BI that will lead to a discussion with the organization and IT on business issues.

A final word

In Montreal, we face many challenges in the field of BI. To overcome them, it's vital to educate organizations about BI and its potential. It's our duty to make them understand that BI is not a solution to a business problem, but a tool to get there.