A la base, on distingue trois types de besoin :
- le reporting figé : une série de rapports récurrents sont identifiés, spécifiés par la MOA, développés par l'équipe informatique. Les utilisateurs ne font que rentrer des paramètres d'interrogation et imprimer le résultat (on parle d' "opérateurs de refresh"). S'il y a besoin de modifier une virgule quelque part, la MOA fait une demande d'évolution à l'équipe technique.
Pour répondre à ce besoin, on ne fait pas forcément de datawarehouse/datamart mais cela peut quand même être utile pour rationaliser le développement et améliorer les performance), et on utilise un outil comme Crystal Reports et ses concurrents.
- l'analyse ad hoc : on a affaire à des "power users" : contrôleurs de gestion, statisticiens, analystes financiers, actuaires, etc., qui passent la journée à analyser les chiffres et ne se satisfont pas de rapports figés. Ils veulent faire leurs rapports eux-mêmes, mais sans apprendre le SQL !
Pour répondre à ce besoin, on fait classiquement une architecture Datawarehouse/Datamart, avec une couche sémantique type Univers Business Object ou catalogue Cognos (ou autres), qui donne aux power users la possibilité de générer leurs requêtes SQL sans connaître le langage.
- la "simulation" : les utilisateurs ont besoin de saisir des paramètres en masse et de lancer des calculs. Par exemple, on veut avoir l'hypothèse de croissance de chaque produit sur chaque marché. Cela s'élargit à bien des cas qui s'éloignent de ce qu'on qualifierait spontanément de simulation : des objectifs pour faire du performance management, des ajustements comptables pour du contrôle de gestion, des clefs de répartition pour de l'allocation de coût, des enveloppes financière pour de l'élaboration budgétaire, etc.
Pour répondre à ça, on recommande généralement des cubes OLAP (alimentés par un Datawarehouse ou un Datamart) qui vont permettre de saisir et déclencher les calculs à travers l'interface de reporting, et être globalement plus simples et plus puissants pour tout calculer dans tous les sens.
Pour des grosses structures comme on en trouve en banque/finance, pour qui le coût de licence est minime par rapport aux enjeux de gouvernance, on trouve presque systématiquement Oracle/Hyperion Essbase.
Partager