Spanish
The other day I saw a post on Linkedn that with some irony somebody said that everything on this platform was wonderful. And indeed, that is the impression that one takes after a few minutes of reading the own time-line (and the same if for example you go to any commercial presentation about IT products).
However, we all know that the world is not so beautiful and that projects do not always go as we would like. I've been in Business Intelligence for a few years now, and that post made me think about those projects that went wrong even though we had some wonderful tools to do them (yes, that last one is also irony).This post is about "lessons learned" with which I hope it will help you to avoid errors in Business Intelligence projects (some of them are specific to SAP but most would be valid for any BI technology).
This point is undoubtedly one of the main enemies of BI. Mistrust usually comes from one of these two reasons:
If the first point occurs, the user will leave the BI system and use the reports (although they are not very modern) that the source system offers. And if the second occurs, well, probably spend the day talking badly about IT and widening the myth that "everything is the fault of the IT staff."
Reconciliation data regarding source system
Obviously you have to do a development that guarantees it, but then you have to do some kind of development to prove that it is like that. You can find more or less automatic systems to cross for example lists of totals in the source system with the BI (and now with S4 / HANA many possibilities are open to us), the problem is that in the BI we will generally have more analysis dimensions (so it will probably have to be crossed with different reports), and also usually involves a maintenance cost that the client is not always willing to assume.
Traceability of the data
If our project has complex calculations or integrates many sources, take into account at the beginning of the project that we will have to show that the calculation works well.
If we have already implemented it and we have not taken it into account, then reengineering is usually necessary that the client probably does not want to assume it.
And that is accentuated in SAP environment and its happy modules. A few weeks ago, for example, I had three meetings in a client more or less in a row, one with financial users, another with purchasing department, and finally another with users of the Real Estate module, and each user, of course, experts in their field. And in each meeting we talk about totally different things and problems.
The risk we run in these situations is important, because:
To avoid this risk we have several solutions:
It is also very helpful to identify which transactions or reports are available in the source system in which we can contrast (even partially), that our developments in BI make sense and are correct.
Usually the BI projects follow a traditional planning: Project definition -> BBP -> technical design -> extractors -> modeling -> reporting -> user tests
... and it turns out that when we started with the development phase of reporting, after two months of the project's start, we realized that certain functionality ... it does not work. This can easily happen when we have a project where the architecture is not the usual or we have some atypical requirement.
In these cases, you have to think about prototyping, proof of concept or using agile methodologies (although in BI it is not always easy to do them).
(4) INFOPROVIDERS (FACT TABLES) WITH DIMENSIONS WITH DIFFERENT GRANULARITY
The SAP methodologies in BI projects tells us that the key figures with the same set of dimensions should be part of the same infoprovider, or what is the same, we must avoid that in the same infoprovider we have key figures that make sense only for a part of the dimensions.
I remember a project, relatively limited, and with expert end users. The dynamics of the project led us to make an exception to this rule. Initially it was not a problem, the users, who as I said were experts, and helped define the requirements, they understood that depending on what ikey figures and dimensions they set up in the report, they would appear null values (the famous "unassigned").It happened that after a couple of years, the project had grown and the users had changed. The behavior of the reports was not understood by the users and ended up abandoning the BI.
Now perhaps I am going to say something that surprises: in the pre-sale of a project we always make a lot of emphasis on the architecture / reporting tools that we are going to use.
Honestly, I think that whenever you choose tools that have shown that in the market are solvent, and this point is unimportant. That is to say, I believe that the success of a project does not depend so much on which tools are used, as on the scope and definition (and obviously execution) of the project.
That said, there is one exception: we can not for example establish a dashboard tool to do what in reality an undercover operational reporting.
I remember a project where it was pre-requisite for the client to use a specific dashboard tool. The reporting consisted of an initial geographic map with key figures values, but later many drill-down navigation screens were required to obtain the detail. Already in pre-sale time we discouraged this tool and offered an alternative (to which the client refused). We involve the manufacturer in the project and we pass on the risk to the client (in time and cost). We dimension the project correctly, always taking into account the risk represented by the tool. That is, we did everything that, in my view, could be done, however, the result was far from satisfying the client
Particularly I have a rule of trying not to accept calculations that can not be done in the source system (unless logically they are calculations that need to integrate data from other systems).
In short, simplify and you will be happy.
If you know the technique "bottom-up" to generate the BBP, be careful with it. Typically we use it when there are no clear requirements, and it is certainly more common to do it in SAP BW environments (because of the pre-existing extractors in business content) than in other BI environments.This technique can be used to make operational reports and also to bring us the data that will later serve us to make tactical or strategic reports.
The problem is that if we simply "bring what is in the ECC", without taking a requirement or a clear analysis of the needs, we will find that we have made very nice reports but without added value, and therefore it is More than likely, for that, the user goes directly to the source of the data.
We must review the projects well, contrast the BBP from all points of view (functional and technical), we must be permanent near the user to understand what he needs and what he does, and above all, not to make the same errors twice.
Have you encountered other problems? Please, comment!
The other day I saw a post on Linkedn that with some irony somebody said that everything on this platform was wonderful. And indeed, that is the impression that one takes after a few minutes of reading the own time-line (and the same if for example you go to any commercial presentation about IT products).
However, we all know that the world is not so beautiful and that projects do not always go as we would like. I've been in Business Intelligence for a few years now, and that post made me think about those projects that went wrong even though we had some wonderful tools to do them (yes, that last one is also irony).This post is about "lessons learned" with which I hope it will help you to avoid errors in Business Intelligence projects (some of them are specific to SAP but most would be valid for any BI technology).
(1) BAD DATA. THE USER DOES NOT TRUST THEM
This point is undoubtedly one of the main enemies of BI. Mistrust usually comes from one of these two reasons:
- Sometimes the reporting in BI does not match with the source system.
- The data does not allow traceability so there is no way to be sure that they are correct.
If the first point occurs, the user will leave the BI system and use the reports (although they are not very modern) that the source system offers. And if the second occurs, well, probably spend the day talking badly about IT and widening the myth that "everything is the fault of the IT staff."
Reconciliation data regarding source system
Obviously you have to do a development that guarantees it, but then you have to do some kind of development to prove that it is like that. You can find more or less automatic systems to cross for example lists of totals in the source system with the BI (and now with S4 / HANA many possibilities are open to us), the problem is that in the BI we will generally have more analysis dimensions (so it will probably have to be crossed with different reports), and also usually involves a maintenance cost that the client is not always willing to assume.
Traceability of the data
If our project has complex calculations or integrates many sources, take into account at the beginning of the project that we will have to show that the calculation works well.
If we have already implemented it and we have not taken it into account, then reengineering is usually necessary that the client probably does not want to assume it.
(2) EY!, THAT THE BI CONSULTANTS CAN NOT KNOW EVERYTHING!
And that is accentuated in SAP environment and its happy modules. A few weeks ago, for example, I had three meetings in a client more or less in a row, one with financial users, another with purchasing department, and finally another with users of the Real Estate module, and each user, of course, experts in their field. And in each meeting we talk about totally different things and problems.
The risk we run in these situations is important, because:
- We can misunderstand a requirement (or what is worse, not directly understand it)
- We can not detect that what they are asking us is nonsense or that there would be much better alternatives.
To avoid this risk we have several solutions:
- First of all, let's put ourselves in context (talking, for example, with the consultants of the corresponding module) and try to take some initiatives beforehand.
- Get us accompanied by the expert consultant in the corresponding module. In large projects: the participation of a certain percentage of the source system consultants is essential.
It is also very helpful to identify which transactions or reports are available in the source system in which we can contrast (even partially), that our developments in BI make sense and are correct.
(3) IT DOES NOT WORK...
Usually the BI projects follow a traditional planning: Project definition -> BBP -> technical design -> extractors -> modeling -> reporting -> user tests
... and it turns out that when we started with the development phase of reporting, after two months of the project's start, we realized that certain functionality ... it does not work. This can easily happen when we have a project where the architecture is not the usual or we have some atypical requirement.
In these cases, you have to think about prototyping, proof of concept or using agile methodologies (although in BI it is not always easy to do them).
(4) INFOPROVIDERS (FACT TABLES) WITH DIMENSIONS WITH DIFFERENT GRANULARITY
The SAP methodologies in BI projects tells us that the key figures with the same set of dimensions should be part of the same infoprovider, or what is the same, we must avoid that in the same infoprovider we have key figures that make sense only for a part of the dimensions.
I remember a project, relatively limited, and with expert end users. The dynamics of the project led us to make an exception to this rule. Initially it was not a problem, the users, who as I said were experts, and helped define the requirements, they understood that depending on what ikey figures and dimensions they set up in the report, they would appear null values (the famous "unassigned").It happened that after a couple of years, the project had grown and the users had changed. The behavior of the reports was not understood by the users and ended up abandoning the BI.
(5) WE DO NOT USE EACH TOOL FOR WHAT IT IS
Now perhaps I am going to say something that surprises: in the pre-sale of a project we always make a lot of emphasis on the architecture / reporting tools that we are going to use.
Honestly, I think that whenever you choose tools that have shown that in the market are solvent, and this point is unimportant. That is to say, I believe that the success of a project does not depend so much on which tools are used, as on the scope and definition (and obviously execution) of the project.
That said, there is one exception: we can not for example establish a dashboard tool to do what in reality an undercover operational reporting.
I remember a project where it was pre-requisite for the client to use a specific dashboard tool. The reporting consisted of an initial geographic map with key figures values, but later many drill-down navigation screens were required to obtain the detail. Already in pre-sale time we discouraged this tool and offered an alternative (to which the client refused). We involve the manufacturer in the project and we pass on the risk to the client (in time and cost). We dimension the project correctly, always taking into account the risk represented by the tool. That is, we did everything that, in my view, could be done, however, the result was far from satisfying the client
(6). WE COMPLICATE. SIMPLIFY AND YOU WILL BE MORE HAPPY
A client asked us for help in an SAP BW project that did not work. The main problem (not the only one) was that many key figures had to be calculated and continuous errors were produced.
Most key figures had up to two pages of definition of how the calculation should be (very complex in most cases) and consequently hundreds of lines of code.
A detailed analysis of the problem led us to several conclusions:
- The cost of calculating and verifying the key figure in many cases was greater than the benefit of having that key figure. With simpler key figure the practical goal was almost reached.
- Many key figures could not be calculated in the source system (because they needed to know the situation at a certain moment), which added complexity to BW and impeded the traceability of the data. With certain relatively simple modifications in the source system the situation was corrected.
Particularly I have a rule of trying not to accept calculations that can not be done in the source system (unless logically they are calculations that need to integrate data from other systems).
In short, simplify and you will be happy.
(7) BE CAREFUL WITH “BOTTOM-UP”METODOLOGY
If you know the technique "bottom-up" to generate the BBP, be careful with it. Typically we use it when there are no clear requirements, and it is certainly more common to do it in SAP BW environments (because of the pre-existing extractors in business content) than in other BI environments.This technique can be used to make operational reports and also to bring us the data that will later serve us to make tactical or strategic reports.
The problem is that if we simply "bring what is in the ECC", without taking a requirement or a clear analysis of the needs, we will find that we have made very nice reports but without added value, and therefore it is More than likely, for that, the user goes directly to the source of the data.
CONCLUSIONS
We must review the projects well, contrast the BBP from all points of view (functional and technical), we must be permanent near the user to understand what he needs and what he does, and above all, not to make the same errors twice.
Have you encountered other problems? Please, comment!
- SAP Managed Tags:
1 Comment
