Pourquoi votre reporting ne peut plus être un projet ponctuel

Une chaîne de magasins ou un groupe de restaurants pouvait autrefois planifier un déploiement technologique comme on planifie la rénovation d’un magasin. Choisir un système, le mettre en place en six mois à un an, puis le faire tourner sans grand changement pendant les trois à cinq années suivantes. Ce calendrier avait du sens tant que l’entreprise elle-même évoluait à peu près au même rythme.

Ce n’est plus le cas. Un réseau qui revoyait sa stratégie une fois par an se retrouve désormais à changer de cap en un trimestre, parfois en quelques semaines, parce qu’une relation fournisseur a évolué, qu’un canal s’est ouvert ou fermé, ou qu’un mouvement d’un concurrent a imposé une réaction que personne n’avait eu le temps de prévoir un an à l’avance. Les entreprises avec lesquelles j’ai travaillé ont toutes eu besoin de changer de plus en plus vite. Très peu de leurs systèmes de reporting ont suivi.

Ce que « digitalisation » veut dire en général, et pourquoi cela s’arrête là

La plupart des déploiements de reporting et de BI que j’ai vus suivent le même schéma. Quelqu’un spécifie les rapports dont l’entreprise a besoin aujourd’hui, un système est construit ou paramétré pour produire exactement ces rapports, et le projet est déclaré terminé. Pendant un an ou deux, cela fonctionne bien. Puis l’entreprise pivote, et les rapports soigneusement construits pour répondre aux questions de l’an dernier cessent discrètement d’être ceux dont on a besoin.

À ce stade, mettre à jour le reporting devient un projet à part entière. Quelqu’un doit cadrer les nouveaux besoins, obtenir un budget, attendre un cycle de développement, et le temps que les nouveaux rapports sortent, l’entreprise a peut-être déjà changé de direction. Cela rejoint une idée bien connue en management stratégique. La théorie des capacités dynamiques de Teece, Pisano et Shuen soutient que l’avantage concurrentiel vient rarement du fait d’avoir pris un jour la bonne décision ou bâti le plan parfait. Il vient de la capacité à percevoir en continu les changements et les opportunités, à comprendre ce qu’ils signifient pour l’entreprise et à s’adapter assez vite pour en tirer parti (Teece, Pisano & Shuen, 1997). Un de mes anciens patrons, qui m’a aussi donné l’habitude de faire du sport, appelait cela garder le périscope levé. La plupart des outils de reporting sont construits comme si cette veille permanente s’arrêtait le jour où le projet est clôturé.

Pourquoi cela pénalise particulièrement le retail et le secteur HoReCa multisites

Une entreprise à site unique peut parfois contourner un reporting dépassé avec un tableur et un responsable qui connaît bien son magasin. Un réseau de dix, trente ou cent sites n’a pas cette possibilité. Chaque virage, un nouveau format, un nouveau canal de livraison, un changement de mix de catégories, une nouvelle région, doit être visible de façon cohérente sur tous les sites presque immédiatement, sinon la direction perd la seule chose qui rendait le réseau pilotable au départ : une vue comparable d’un site à l’autre.

Quand le reporting ne suit pas, ce qui se passe en général n’a rien d’un échec spectaculaire. C’est une lente dérive. La direction commence à poser des questions auxquelles les rapports actuels ne savent pas répondre, quelqu’un construit un tableur ponctuel pour combler le manque, ce tableur devient la source de vérité officieuse pour une question précise, et en moins d’un an l’entreprise tourne discrètement sur un patchwork de solutions de contournement que personne n’a planifiées et auxquelles personne ne fait entièrement confiance.

Une couche de reporting qu’il n’est pas nécessaire de spécifier à nouveau chaque fois que l’entreprise change de cap, c’est un autre type de système à construire.

Une autre façon de construire la couche de reporting

Essayer d’anticiper toutes les questions futures avec un déploiement plus vaste et plus complet ne fonctionne pas, puisque personne ne peut spécifier les questions d’une entreprise trois virages à l’avance. Une couche de reporting qu’il n’est pas nécessaire de spécifier à nouveau chaque fois que l’entreprise change de cap fonctionne mieux, et c’est un autre type de système à construire.

C’est la raison concrète pour laquelle marql est construit autour d’une question plutôt que d’un ensemble figé de rapports. Une chaîne de magasins, un groupe de restaurants ou un réseau de franchise garde ses systèmes existants exactement tels qu’ils sont, caisse, comptabilité, stock : marql les lit sans les remplacer, avec un hébergement dans l’UE. Quand l’entreprise pivote et qu’une nouvelle question apparaît, qu’il s’agisse des premiers résultats d’un nouveau canal ou de l’effet d’un changement de catégorie sur le stock, c’est une nouvelle conversation, pas un nouveau cycle de développement. Personne n’a besoin de déposer une demande pour un rapport qui n’existe pas encore.

Nous ne prétendons pas que cela rend une organisation agile à elle seule. Une couche de reporting n’est qu’une partie d’un ensemble plus large qui comprend les personnes, les processus et les droits de décision, et aucun produit ne change cela à lui seul. Ce que nous pouvons dire simplement est plus restreint : une revue qualifiée de vos outils, une première vue en direct sous 24 heures et des tarifs à partir de 200 € par mois, avec un objectif précis : supprimer le décalage entre le virage d’une entreprise et un reporting capable de répondre à des questions à son sujet.

La question à se poser avant le prochain virage

La plupart des entreprises découvrent que leur reporting est en retard sur leur activité au pire moment possible, en plein virage, quand la direction a besoin d’une réponse que les rapports actuels n’ont jamais été conçus pour donner. Cela vaut la peine de vérifier plus tôt. La dernière fois que votre entreprise a changé de cap, combien de temps a-t-il fallu pour que votre reporting voie clairement la nouvelle situation ?