Le décisionnel déteint sur le pilotage financier

Les applications décisionnelles sont de plus en plus intégrées au système de pilotage financier. Objectif : mieux mesurer et améliorer la performance d’entreprise.

« La Business Intelligence (BI) est un sujet au carrefour des systèmes d’information, des métiers et de la direction générale : elle s’apparente plus à un processus continu au sein des entreprises, cadré par une stratégie, qu’à un projet ponctuel », notait le Cigref dans son dernier rapport sur le sujet, paru en novembre 2009.

Le Club informatique des grandes entreprises françaises précisait : « L’organisation de la BI dans l’entreprise est fortement dépendante de l’organisation de l’entreprise elle-même. Cependant, la BI peut avoir un impact structurant pour l’entreprise, notamment par la formalisation de référentiels de données et par la mise en place de centres de compétences.

La BI a aussi un rôle fédérateur entre DSI, métiers, DG, et renforce le rôle du DSI par rapport à la performance globale de l’entreprise. » Une mesure de la performance qui passe par la case finance.

Début 2010, la plupart des études montrent que les DSI plébiscitent toujours autant la BI. Le décisionnel reste, certes, une affaire de grandes entreprises (52 % des organisations équipées emploient plus de mille salariés, selon le dernier baromètre Decideo, publié fin 2009) mais les cas d’entreprises qui ne possèdent qu’une seule application décisionnelle deviennent anecdotiques : 84 % des entreprises en gèrent plusieurs. Outre la consolidation des applications décisionnelles, les refontes de systèmes d’information sont l’occasion d’intégrer encore plus finement le décisionnel pour répondre aux besoins de pilotage financier.

Par exemple, Sonepar, groupe industriel spécialisé, entre autres, dans le génie climatique, l’éclairage et le câblage, a engagé la migration de cinq systèmes d’information vers un système centralisé. « Nous voulions à cette occasion réduire notre risque métier et avons opté pour un choix de progiciels plutôt qu’un logiciel ERP unique », souligne Jacques Peccaud, DSI de CGE Distribution du groupe Sonepar (*).

Le projet, réalisé entre 2007 et 2009 (avec les outils Open Text), portait sur la synchronisation et la diffusion d’un nouveau référentiel métier ainsi que sur l’intégration d’un décisionnel unique et de l’application finance.

« Le choix d’un ETL a été privilégié pour sa capacité à interconnecter simplement des données multiples : SGBD, système de fichiers et XML », précise Jacques Peccaud. Celui-ci conseille, d’une part, de ne pas négliger l’aspect humain : « Le niveau de compétence de mise en œuvre d’un ETL est en effet significatif. »

D’autre part, toujours selon Jacques Peccaud, « des mesures d’optimisation de performances sont à prévoir régulièrement pour accompagner la montée en charge ». Autre exemple : dans le cadre de son projet « Destination 2012 », la direction Finance de la branche Infrastructure de la SNCF (l’une des quatre grandes branches de la société aux côtés des branches Voyageurs, Proximités, Transports et logistique), avait deux objectifs essentiels : « Installer une logique de refacturation interne pour facturer le service au meilleur prix et simplifier le pilotage en mettant en cohérence les priorités de la branche et les indicateurs de performance associés », précise Stéphane Juillard, directeur du projet chez SNCF Infrastructure.

La direction finance de la branche Infrastructure est en charge de la production de l’information comptable et du pilotage économique de la branche (plan d’affaires, élaboration du budget, contrôle de gestion opérationnel, animation des contrôleurs de gestion…). Pour répondre aux besoins de pilotage, une cellule MOE est en charge de bâtir les restitutions avec pour objectifs de les concevoir et les développer (en mode projet), de les produire et de les restituer de manière industrielle (environ 45 tableaux de bord par mois).

« La direction finance était confrontée à plusieurs problématiques : une évolution fréquente des besoins sur des restitutions existantes ou nouvelles, une diversité des données par domaines métiers et dans le SI (PGI, logiciels propriétaires, fichiers externes…), une volumétrie de données parfois très conséquente (balance comptable d’environ cinq millions de lignes) et une hétérogénéité des supports demandés (PowerPoint, Excel, Word) », détaille Stéphane Juillard.

Le projet (réalisé avec les solutions Reportive) s’est déroulé en deux phases. La première a concerné le tableau de bord pour le comité de direction et les directeurs régionaux, avec 35 indicateurs basés sur des données retraitées par les directions centrales des activités. « Nous disposons d’un tableau de bord par région et d’un benchmark régional », précise Stéphane Juillard.

La deuxième phase a porté sur le tableau de bord pour les directeurs d’établissements, avec 58 indicateurs pour deux tableaux de bord distincts (pour l’équipement et l’exploitation). « L’enjeu était de restituer des données issues directement des systèmes d’information amont sans retraitement manuel », souligne Stéphane Juillard.

Chez Apria-RSA (Réunion de sociétés d’assurances), une association loi 1901 créée par les assureurs pour la gestion des régimes d’assurance maladie obligatoire des professionnels indépendants, un programme de refonte du système d’information a été initié en 2007, partant d’un constat classique : une ancienneté du SI (à la fois pour les logiciels et les architectures) et, de fait, des coûts de maintenance significatifs.

« Nous avons également suivi les recommandations d’un cabinet d’audit sur la nécessité d’une traçabilité des écritures pour la justification et la certification des comptes, et nous souhaitions une solution standard et paramétrable par la direction financière, avec une liaison avec les systèmes métiers existants ou à venir », précise Jean-François Richard, responsable du domaine chez Apria-RSA. Une équipe de six personnes (un chef de projet, deux ingénieurs d’études, deux personnes de la direction financière, une personne de la direction métier) a mis en œuvre la solution (OpenText).

Principe de développement : un découpage de l’interface en trois processus indépendants (voir tableau) : d’abord, le contrôle et la conversion des actes métiers en actes standards ; ensuite, la génération des écritures comptables à partir des actes standards ; enfin, la centralisation des écritures comptables et l’archivage des données. Sept tables de paramétrage ont été définies (règles de centralisation, schémas comptables, sites, combinatoire de transformation des actes métiers…).

Bilan, selon Jean-François Richard : « Une unicité du moteur d’imputation comptable vis-à-vis des applications métiers existantes ou à venir, une maintenance simplifiée, une autonomie de la direction financière en matière de paramétrage, une traçabilité assurant la justification des comptes, un gain significatif des temps de traitement (passage de quarante-cinq minutes à moins de cinq minutes) et une reprise de traitement automatique, sans intervention de la DSI. »

Autre exemple, dans le secteur public : le conseil régional Languedoc-Roussillon a créé un système d’information de gestion et de pilotage (Sigep). Objectifs, selon Bruno Stavy, directeur du contrôle de gestion de la région : « Offrir une information adaptée, pertinente et rapidement disponible aux agents qui doivent répondre aux objectifs politiques, stratégiques et opérationnels.

Cette information doit être adaptée à tous les agents de la collectivité selon leurs besoins : du gestionnaire qui assure la saisie au cadre instructeur, du chef de service au directeur jusqu’aux directeurs généraux. » Un tel système de gestion répond à trois types de besoins. D’abord, une démarche et un dispositif de reporting. « L’outil doit mesurer la gestion interne (les moyens, les délais de traitement, les activités…) ainsi que les politiques publiques régionales : quels résultats et quels effets… », souligne Bruno Stavy.

Ensuite, un besoin de reporting modélisé selon plusieurs axes d’analyse : la politique publique, un dispositif d’intervention (quoi ?), le type de bénéficiaire (qui ?), la localisation (où ?), la période (quand ?), le montant en euros (combien ?) et les résultats (combien ?). Enfin, troisième besoin : un dispositif d’alerte qui doit provoquer une réaction et aider à la décision.

L’architecture s’appuie, pour la production, sur une dizaine de bases de production applicatifs métiers, logiciels, autres bases…), sept univers Business Objects et 300 rapports créés par la direction du contrôle de gestion. Pour la diffusion, un portail est accessible à 270 agents par l’intranet.

À terme, l’objectif, selon Bruno Stavy, est de « perfectionner sans cesse la qualité des données, de récupérer des indicateurs de résultats via les applicatifs de dématérialisation ou via les formulaires des extranets et pour l’équipe des contrôleurs de gestion, de passer d’une logique de production d’états de reporting à une logique de système d’information qui doit alerter, provoquer une réaction et aider à la décision ».

Groupe Mutuel, groupe suisse d’assurances (1 500 collaborateurs, 875 000 assurés individuels), a également refondu son système de BI à l’occasion, en 2006, d’une refonte complète de son système d’information. Boris Horquin, responsable de la Business Intelligence du groupe, se souvient : « Nous avions une contrainte unique, mais de taille : livrer la solution de BI au plus tard quatre semaines après la livraison du nouveau système d’information. Il nous fallait donc développer la BI en parallèle du développement du nouveau SI et concevoir le datawarehouse sans connaître nécessairement le modèle de données du futur système source. »

Par rapport à l’existant, les objectifs étaient, ajoute Boris Horquin, de « pouvoir rafraîchir les données de manière journalière, d’intégrer le décisionnel au système d’information, de mieux maîtriser les délais et les coûts des projets datawarehouse, de disposer d’une solution facilement maintenable et performante et, surtout d’être, pour l’entreprise, le fournisseur officiel en matière d’analyse et de statistique tout en laissant une part d’autonomie au métier ». L’approche retenue a été le modèle en étoile.

Une cartographie a été établie en 2006 avec une centaine de sujets d’analyse identifiés, en production ou en développement. « L’équipe projet comprenait un représentant de la direction ou du domaine métier et des key users », précise Boris Horquin. David Queloz, de la direction générale du groupe en charge des produits, des statistiques et des innovations, et qui s’avoue « grand consommateur de statistiques », précise : « Ce projet était plus que stratégique. Il a été soutenu par la DG car c’est notre outil de demain. La technologie, c’est un peu de la cosmétique, l’important, ce sont les ressources et la cohésion des métiers. »

(*) La plupart des citations reproduites dans cet article ont été collectées lors du Forum Decideo 2009.

Tableaux de bord adaptés aux catégories d’utilisateurs : l’exemple du conseil régional Languedoc-Roussillon
Utilisateurs Besoins Outils proposés
Direction générale, directeurs S’assurer de l’évolution des grandes thématiques transversales Tableaux transversaux
Directeurs, chefs de services, cadres instructeurs Piloter et évaluer leurs dispositifs métiers Tableaux métiers
 Chefs de services, cades instructeurs, gestionnaires Optimiser la gestion du portefeuille de dossiers de cofinancements Tableaux de gestion (état des stocks de dossier : à traiter, en cours, soldés…)
Source : Conseil régional Languedoc-Roussillon.
Business case : les dix meilleures pratiques
Meilleures pratiques Pourquoi ?
1  Adapter le business case à la complexité du projet  La construction d’un business case ne suit pas un schéma figé.
2  Identifier la raison du changement  Pour identifier et décrire précisément le problème à traiter.
3  Examiner les autres options Le business case étudié n’est qu’une façon parmi d’autres de répondre à un enjeu identifié par l’entreprise.
4 Définir un langage commun  Une incompréhension entre les différents acteurs d’un projet, en particulier entre la maîtrise d’ouvrage et la maîtrise d’œuvre, est un facteur d’échec connu.
5 Bien délimiter le périmètre du projet à analyser  La valeur du business case sera estimée en fonction de ce périmètre.
6 Estimer les coûts de manière exhaustive  Cette phase est incontournable pour estimer la valeur de l’investissement étudié.
7  Présenter des bénéfices clairs et mesurables  Susciter l’adhésion des différents acteurs concernés par le projet.
8  Évaluer les risques Tout projet comporte des risques : identifier ceux-ci dès la prise de décision évite certaines déconvenues.
9  Démontrer la valeur du projet Lorsque les bénéfices intangibles occupent une place importante dans un projet, il faut les faire apparaître.
10  Mettre en place un suivi dans le temps  Faciliter le dialogue entre les différents intervenants d’un projet.
Source : Best Practices Systèmes d’Information.

Les best practices de la SNCF

  • Identifier les sources de données les plus pertinentes et pérennes (évolution des systèmes, des organisations et des référentiels métiers).
  • Étudier la faisabilité pour construire l’indicateur (sur le réalisé et aussi sur l’objectif associé).
  • Gérer l’hétérogénéité des sources (une codification s’avère nécessaire sur toute la chaîne de traitement).
  • Garantir la fiabilité de la production (en cas de défaillance d’une interface, par exemple).
  • Ne pas négliger la mise en œuvre des spécifications détaillées pour pérenniser la connaissance (une méthodologie est nécessaire).

Les best practices du Cigref

Le pilotage des projets de décisionnel s’effectue selon quatre axes : stratégique, financier, méthodologique et humain. Pour chacun de ces axes, le Cigref propose quelques meilleures pratiques :

Axe stratégique :

  • définir une stratégie décisionnelle ;
  • lotir les projets ;
  • avoir un sponsor métier fort ;
  • définir des référentiels de données ;
  • disposer d’équipes BI avec des compétences métiers/IT.

Axe financier :

  • assurer la coopération DSI-métiers et le partage du financement ;
  • ne pas chercher forcément une évaluation financière du ROI ;
  • définir des plans d’action liés aux usages d’outils BI et amenant de la valeur ajoutée aux métiers.

Axe méthodologique :

  • assurer une durée inférieure à six mois ;
  • impliquer les utilisateurs dans la conception, créer des ateliers de travail DSI-métiers ;
  • produire rapidement des prototypes ;
  • utiliser des check-lists.

Axe humain :

  • mesurer l’utilisation des outils et prévoir des formations ;
  • soigner l’ergonomie ;
  • faire évoluer les outils et les données et maintenir les métiers impliqués ;
  • privilégier un faible turn-over des équipes BI ;
  • utiliser des outils appropriés, ce qui facilite leur adoption.

Sources : Business intelligence : place de la BI et pilotage des projets décisionnels dans les grandes organisations françaises, Cigref, octobre 2009.