Au-delà de la réponse théorique, c’est une question à laquelle il faut bien répondre dans le contexte du projet en cours.
Le cas du jour : une recette qui ne se termine pas chez un client, principalement parce que leurs applicatifs sont des sources inépuisables d’anomalies de données.
Alors ça ne rate pas, le chef de projet MOA et le sponsor s’agacent en comité de pilotage : « Y’en a marre, ça n’en finit pas, en plus vous êtes en régie et ça nous coûte trop cher ».
Certes, mais l’objectif initial du datawarehouse, ça n’était pas d’avoir une base centralisée, consolidée, propre de la comptabilité du groupe ?
Parce que la plupart des anomalies rencontrées sont bien des erreurs dans les données, qu’elles soient mal saisies dans les systèmes comptables ou résultantes de bug de ces mêmes systèmes. Chaque anomalie résolue c’est des données nettoyées, c’est une comptabilité plus propre, c’est donc bien de la valeur ajoutée !
Celui qui en a conscience c’est le futur utilisateur de la solution, responsable du contrôle de gestion qui se doutait que sa compta n’était pas bonne, qui en a enfin la preuve, et qui est enfin capable de le détecter et de le corriger.
Reste à convaincre les décideurs…
La BI ça vous gagne! 
Tu enchaines les articles intéressant en ce moment, à croire que ton Titre MVP te boost ! 🙂
Oh un troll !
Ce discours peut se tenir mais il faut l’avoir auprès du sponsor et les membres du comité de pilotage dès le début du projet (avant que la situation ne se produise pendant la recette).
Et si les anomalies détectées pendant la recette n’auraient pas pu l’être avant, il faut peut-être le sortir du cadre de « la recette qui traîne ».
@Charly : Pis du contenu technique en plus, t’as vu? 🙂
@Damien : Effectivement Damien, ça fait partie de notre travail en tant que consultants d’accompagner les clients sur ce genre de réflexions. Mais ce n’est pas toujours facile, tu le sais bien 😉
Pour le fait que les anomalies soient détectées en continue, c’est également en raison de l’extension du périmètre à chaque semaine qui passe (j’aurai aimé pouvoir te dire que c’était par itérations agiles, mais c’est plutôt par manque de préparation initiale du projet), et que chaque nouvelle source amène de nouveaux problèmes.
Tiens un argument du grand kimball group : Some observers, especially some BI tool vendors, argue that you can skip the relational data warehouse and deliver the dimensional experience virtually. This sounds appealing – no one really wants to build an ETL system – but it’s a chimera. No semantic layer tool provides the transformation and integration functionality of an ETL tool.
http://www.kimballgroup.com/2013/08/05/design-tip-158-making-sense-of-the-semantic-layer/
Il dit qu’il voit pas le rapport, mais c’est intéressant dans l’absolu! 🙂