There are design and technological factors that, if not considered, risk in the short or medium-long term to be actual blocks, leading to failure and abandonment of the project itself.
During a project for the evolution of analytical tools in a company, obstacles are often encountered that can only be partially foreseen at the beginning.
Beyond the more “sociological” aspects, linked for example, to the low propensity for change on the part of users or the lack of a real sponsorship, there are more design and technological factors which, if not considered, risk if not in short, at least in the medium-long term, to turn out to be fundamental blocks, even to lead to a failure and the abandonment of the project itself.
It would help if you had an initial push, coming from Information Technology and the business, to be able to hope to give life to a corporate analytics project which, among other things, by its nature is difficult to measure through the “cost-benefit” balance. Identifying this motivation and bringing it to the company’s attention is the first aspect to consider carefully.
Table of Contents
Corporate Analytics: Technological-Functional Assessment
Here you have to be very careful. Because the reason is mainly technological, such as the adaptation of a Data Warehouse (or Data Lake ) environment following, for example, the change of an ERP inside the company, it will be essential to understand the impacts on the user output side and plan from immediately an assessment of the “as is” in terms of current dashboards and reports.
This assessment will have to estimate the times and costs necessary for the “change management” so that it is as transparent as possible for end-users. On the contrary, if the motivation for the evolution comes from the business, Information Technology must be immediately involved in understanding the impacts in terms of sustainability within the current infrastructural ecosystem, with possible effort estimates for a necessary adaptation.
In the first case (technological push), the risk is that the company, in terms of the end-user, does not understand the need to change what is already working. In the second case (functional thrust), the risk is that the thing is not feasible or, even worse, is implemented outside the “recognized” company systems.
Business Analytics: Trust In Data Is Not Trust In Information
A trap that often falls into when a corporate analytics project evolves is considering the result achieved when the “data” is certified. That is, the relative loading and updating processes starting from the data sources are certified. This is enough to say that the data is “formally correct,” of course, but not that it is “useful” to the business for analytical purposes. The new loading and data preparation must also integrate all those “downstream” data management operations carried out in the past by the same users and, over time, remained outside the official analytics processes but paradoxically vital for users.
Local and non-certified operations that thus become shared and certified (for example, using a form instead of an Excel file). In other words, from data to information. It frequently happens that these aspects are overlooked or only discovered when it is (almost) too late. This leads to a lack of trust on the part of the end-user in the initiative in general.
Functional Integration
Another issue that we tend to underestimate concerns the integration between data, starting from the presence of different data types in different systems for the same “information” up to the logical impossibility of putting together the metrics of a new tool together with those of an already existing one due to a different construction (precisely, logic) of the metrics themselves.
Thus it may happen, for example, that a digital transformation project runs out of difficulties in creating an online + offline database of registered customers, only because the standard “information” present in the source systems differ from each other in terms of data type or naming convention., something that perhaps in the effort planning stage had not been adequately considered.
Evidence Of “Results.”
It has already been said that the cost-benefit evaluation is very little applicable to an analytics evolution project, except perhaps for an advanced analytics project. The comparison between final balance and forecast can constitute a reliable, albeit partial, measure of the initiative’s advantage.
Precisely for this reason, an effort by the promoters, technological or business, must be to fix quantitative terms as much as possible and bring the “results” to the maximum evidence: for example, the availability of data in a faster time, the least effort necessary for the creation of an “on demand” report, the savings in the management of the infrastructural part thanks to automatic control and optimization mechanisms. An analytics project, precisely because it cannot be measured in “absolute” terms, is in desperate need of “marketing pills” to demonstrate its usefulness in the company.
Need Or Opportunity?
Ultimately, a business analytics environment undergoes a change or evolution project for two reasons: necessity or opportunity. Necessity can be technological obsolescence and the lack of support from the vendor, the sudden deterioration of the performance of a user tool, the adaptation to a new company ERP.
Opportunity can be a tool that allows you to obtain essential analyzes automatically, take advantage of advanced analytics to have competitive advantages, and reduce the costs of demand planning, a technology that drastically reduces data management time and effort.
However, the boundary between the two “thrusts” is blurred if we consider the business context.
By definition, anticipating choices (wisely, of course) is a goal at all decision-making levels.
And then perhaps the natural division is not between necessity and opportunity but between action and reaction. In the first case, we anticipate what will be, and we move in time; in the second case, the process begins in the face of a technological or competitive problem, only when it becomes evident (and it is perhaps too late).
Finally, there is also the “whim” as a possible motivation. Or perhaps the initiative of an individual, often a new member of the organization and who brings “as a dowry” a project of change regardless of the context. I would say to leave this situation out, indeed, to avoid it as much as possible, since failure here is almost inevitable. And in this case, the sooner, the better.
