A business intelligence project, within an organisation, whatever its activity and size, and therefore even within the smallest, covers too many dimensions for it to ever be described as simple or easy.
Defining objectives, fitting into a financial envelope, analysing the real needs of decision-makers and anticipating their evolution, identifying sources of information and analysing their potential, drawing up the architecture of a solution, modelling the expectations, choosing tools and software for implementation, obtaining authorisations and connection parameters to access sensitive data and implementing the technical means to do so, designing, developing step by step and finalising the documents, imagining their circulation and inventing new vehicles for their transmission to users, thoroughly testing and debugging, inaugurating the first publications, activating a continuous improvement loop. .. All of this in a short timeframe, a changing environment and frequently shifting priorities. It’s a long list, and one that can discourage the best of wills.
And yet the demand for relevant, precise, functional, fast and flexible decision support tools is pressing, everywhere. Because the business world, but not only the business world, demands ever greater reactivity, speed of decision and depth of analysis. Because the data to be implemented covers ever-increasing volumes since the digitalisation of activities is now global.
Some IT projects, although essential in concrete terms within the organisation, will remain ignored by almost everyone because they are not shared internally and are not very visible externally.
Let’s caricature it a little: who really cares about the Warehouse Management System apart from the logistics teams whose daily efficiency it steers and guarantees? And yet the challenges of customer satisfaction and stock control are obviously vital for a company.
On the other hand, the documents produced by Business Intelligence will circulate at the heart of multiple decision-making centres and levels, be present on the desks of a multitude of key players, be displayed on computers, electronic information panels in corridors or workshops. Sales people will carry them in their pockets with their mobile phones and in their briefcase on a graphic tablet, to consult them in the evening at the hotel or even to share a few selected pieces with their customers or prospects.
Business Intelligence conveys the image of the organisation as much as it shapes its data.
As a result, the BI project will become a flagship project, focusing managerial attention on the grounds that it is no longer possible to make decisions without an effective support tool, and ultimately arousing competition between the organisation’s major functions, and the covetousness of their managers, to steer its implementation under the full glare of the managerial spotlight, and then retain operational control.
Rivalries and a natural tendency to monopolise the most brilliant objects will then quickly transform the initial desire to make useful information available, at the right time, in the right place and in the most relevant form, into a centralising solution of which the internal promoter will become the owner and whose data will enable him to know the hidden secrets of his colleagues. Cooperation thus gives way to competition. The data reveal their hidden power of influence. Business Intelligence can also become an instrument of power.
Centralised Business Intelligence
Business Intelligence systems implemented in organisations rarely escape this temptation, which is monopolising and therefore centralising. They become the useful plaything of the most senior function: the finance department very often, via one of its control vassals, and the IT department quite regularly, since the system involves the operation of information systems and networks.
Both departments are strongly marked by verticality. Shouldn’t all the information go back to headquarters to produce the accounts and analyse them? Shouldn’t the systems be managed and their security guaranteed by central access control?
The replacement of departmental software by ERP (Enterprise Resource Planning) systems bears witness to this attachment to a single set of tools and procedures: a single software framework, a single database containing all the information required for processing, a single pilot (a single management team) to manage its complex operation and updating. Everything therefore starts from the top, since the operational staff cannot have a complete view of the information system implemented.
The same logic applies to the IT infrastructure: central internal or outsourced servers for maintenance reasons, centralised opening of access rights for security reasons, a global call centre for lack of local skills.
The implementation of a Business Intelligence solution is therefore carried out in this Jacobin context and it is quite natural that the project, often initiated by general management, is entrusted to central players rather than to operational staff, who are directly concerned by its use.
The arguments for centralisation
Those in favour of centralisation will point to the advantages expected from a command and decision-making unit: the single management of the project and later of the Business Intelligence system makes it possible to guarantee the consistency of data repositories and work processes, the performance of dedicated databases (the data warehouse) and a real capitalisation of skills around the central BI team. The need for coherence is all the more important as the structure of the organisation is complex, both horizontally and vertically. Centralisation is therefore always presented as a criterion of the organisation’s maturity.
Can we counter these arguments, which seem so common sense? Undoubtedly, yes, but what use are coordination structures if there is nothing left to coordinate when governance is completely centralised? Let us detail these needs.
The uniqueness of the model put in place, of the processes and definitions of tasks, of the reference systems, of the definitions of data is really indispensable. Can we imagine several definitions of turnover competing for the presentation of results? In fact, the situation is frequently encountered in organisations that do not impose a common reference framework on the various branches and departments. This is an untenable situation, leading to permanent internal contestation of shared information and the circulation of parallel dashboards.
A single reference framework is necessary, but will it be enough to impose it from above to eliminate any alternative definition in the organisation? A decentralised review of approaches and coordination generally makes it easier to gain acceptance for a “group” definition, possibly combined with complementary business indicators.
Data warehouses are databases that require excellent structuring of the data they will have to manage in order to be effective. Let’s not forget that they will very quickly have to deal with very large volumes of data (in particular for historical management), with a multidimensional relational design of great density. And yet they will have to guarantee users the shortest possible synthesis and access times.
A central vision would seem to be necessary to achieve this feat, since it allows the implementation of high intensity technical capabilities: powerful servers, high skills in information systems, large bandwidth on the networks, etc., while more easily ensuring higher levels of security against breakdowns and intrusions.
But wouldn’t specialised and decentralised warehouses close to where the data is produced meet these same constraints while reducing the overall complexity of the relational scheme? This would in no way prevent the reduced volume of synthesised data needed to produce the Headquarters’ dashboards from being grouped together in a central warehouse. In terms of security, the risk would be spread, which is one of the basic principles of insurance, a model that has long since proved its worth.
The capitalisation of knowledge and know-how is also presented as an argument in favour of centralisation. A Business Intelligence system is complex, and the technical mastery of network settings, database knowledge and the creative use of Business Intelligence software imposes a fairly heavy human and training investment. Centralising on a specialised central BI team seems to be the best way to avoid multiplying the number of dedicated staff or spreading them out in isolation in the various branches of the organisation.
This is understandable, but does not mean that there are no alternatives in this era of institutionalised and systematised remote working. Capitalisation is achieved as much, if not more, through tools for formalising knowledge (Knowledge Management), or by sharing it across several levels of technical expertise, than by centralising it in a few well-trained and well-filled heads grouped together in a single office. A single team will only handle a small number of maintenance tasks simultaneously and will give priority to blocking anomalies. Local improvement or modification requests will then remain at the end of the list for a very long time.
These three arguments of model uniqueness, data warehouse structuring and knowledge capitalisation are in any case not enough to create an efficient Business Intelligence system, really close to the decision-makers, adjusted to their individual needs, flexible enough to adapt to permanent change, and easy to take over and appropriate. A central Business Intelligence system, on the other hand, has every chance of quickly becoming fixed and turning into a machine for producing useful graphs… for the small number of users close to its governance.
For an alternative approach to Business Intelligence
An organisation, even a highly centralised one, will not be able to function without sufficient decision-making space entrusted to employees on the ground. Managerial centralisation will certainly set the principles, rules and margins left, but local decision-makers will apply them according to their own understanding, and will exploit the flaws, if necessary, to succeed in their mission and achieve their objectives.
Even the most totalitarian of institutions generates a local autonomy without which its workings cannot run. Control of compliance with the rules is only possible a posteriori and must give the actors the benefit of their successes. As a result, the more centralised management is, the more local decision-makers will need a fast, precise and well-tuned Business Intelligence tool to measure the use of their limited margin of initiative.
It is therefore a decentralised BI system that should prevail to support local decision-making: a dashboard with indicators (Key Performance Indicators, KPIs) defined by each decision-maker according to his or her own needs but based on a data model shared with the higher organisational level.
The system can thus be built brick by brick at high speed by each employee in coordination with his or her superior level. Consistency is easily ensured by sharing indicators (KPIs, calculation methods and data sources) both horizontally between colleagues and vertically. Why not leave the choice of indicators to the teams in the field, since in any case in a centralised BI system they will only really take into account the indicators that suit them best? One salesperson will focus on the number of new customers, which generates bonuses, and another on the total turnover and average basket.
The hierarchy can ensure coordination and harmonisation at each level; it therefore guarantees the consistency of the data model, with technical support (IT feasibility) and organisational support (broader vision of needs) from headquarters. At each level, there are few interlocutors, so there is no risk of discussions getting bogged down, and the work of building a complete table of indicators will be completed quickly. The repository (processes, data, indicators) can be built by simply collecting and comparing local feedback.
The analysis phase, divided into elementary cells working simultaneously, can only be accelerated. Of course, this will not be achieved without serious preparation and training of the management. It will also be possible to identify ‘champions’ who are willing to participate in the project and whose motivation and personal investment will facilitate the analysis phase, but also the subsequent operational implementation and continuous improvement phases.
Data warehouses: the analysis of source data and the organisation of the information systems that produce them, on the one hand, and of the indicators to be produced, on the other, will make it possible to build homogeneous sectorised data warehouses, connected to sources that are closer and smaller in number, with a smaller volume of data and used by fewer users. Their updating will be improved by proximity, using the most relevant time slots so as not to penalise the performance of the source systems and networks. It will therefore be possible to use less sophisticated technical solutions. This will not prevent the information needed for processing at headquarters from being fed back, but in reduced volume because it has been synthesised, nor the application of central control and uniform security protocols throughout the organisation.
The capitalisation of skills should encounter fewer obstacles in a deconcentrated Business Intelligence system due to the presence of BI specialists in the field, the “champions”, with first-level skills, and able to act as intermediaries between users and decision-makers, and the software team or the network team. Questions from users will thus be dealt with more quickly by people who understand both languages. The more complex points will be dealt with by the central teams alone. The training of these champions is rapid because it is not very specific and is centred on use, basic parameterisation, the creation of simple queries and the creation of documents. The most motivated among them will deepen their skills on their own out of curiosity and to make themselves indispensable to their colleagues. They are the ones who will build the core of the organisation’s Business Intelligence knowledge base.
This is probably the case if one is stuck in a centralist way of thinking.
There is a wide range of software targeting either specialist audiences, advanced users or inexperienced beginners. The accessibility of software is often more related to the generation of the software than to its core functionality, but not always. The choice of software must therefore be thoughtful and based on a rational study, not only of its technical potential but also of its ergonomics, by studying each of the modules (extraction and transformation of data to feed the data warehouse, design of summary documents, and distribution of documents in the organisation).
If the choice of software is left centrally to business intelligence specialists, the software will certainly be more complex and not very accessible to field analysts. Conversely, the latter would prefer simple tools with perhaps somewhat limited performance for the former…
But can’t the organisation simultaneously offer its users a choice of tools adapted to different needs and levels of BI competence? The important thing is not so much the data formatting software used, as the content of the warehouse. Why impose on the management controller in charge of a sales unit in a subsidiary to use the same software as the central department in charge of producing the summaries for the management committee?
The management controller, who masters Excel in the exercise of his primary activity, will undoubtedly find it advantageous to build the sales team’s dashboard using the data management functionalities of his spreadsheet (Excel Data Model, Power Query, Power Pivot, etc.), by automatically drawing the necessary information from the data warehouse. And rather than having a standard format imposed on all the group’s sales units, he will refine a document adapted to the specificities of his unit, to the interests of his sales representatives: a document that can be easily modified to follow the evolution of their needs.
The management committee’s dashboard, with its more sophisticated data visualisations, but also more synthetic and more fixed, published on the organisation’s intranet and distributed via the network to different levels of management with automatically personalised content, could come from a more communication-oriented Business Intelligence software.
The maturity of an organisation in Business Intelligence does not necessarily lead it to evolve from a cobbled-together dashboard on a spreadsheet to the centralised operation of heavy and complex software by a central BI team. A decentralised approach is perfectly compatible with the needs and imperatives of an organisation, even a large and complex one.
But first you have to dare to change your point of view.