Quelle organisation autour de la Business Intelligence et du Big data dans les grandes entreprises ? (3/5)

Dans un précédent article, il a été exposé les coûts et les bénéfices à vouloir mutualiser une démarche BI au sein de la DSI. Il s’agit maintenant d’aborder la facette organisationnelle de la question, en particulier dans le rôle de la DSI vis à -vis des entités métiers et l’organisation interne de la DSI.

Quelle doit être la proximité de la DSI auprès des entités métier ?

Sur l’axe des domaines fonctionnels : dans cette dimension du décisionnel, la DSI doit avoir une représentation métier forte. S’il y a une valeur à avoir une connaissance transversale des données de l’entreprise, celle ci est surtout une toile de fond. Mais il est de plus en plus essentiel qu’une cellule décisionnelle dans une DSI puisse parler des données de chaque domaine fonctionnel et parfaitement maîtriser le fond des indicateurs ou des chiffres et analyses qu’on peut tirer des données opérationnelles dans le domaine concerné. A minima une DSI se doit d’avoir une représentation décisionnelle par
domaines fonctionnels, un point de contact qui connaisse le domaine et les enjeux fonctionnels. Cela peut être mis en oeuvre de différentes manières. Mais il est important que ces représentants travaillent en étroite relation avec leurs homologues du SI classique pour chaque domaine. Une équipe décisionnelle doit s’investir dans la connaissance des données et du SI du domaine correspondant et se rapprocher des
sachants du SI.

Chaque métier a aujourd’hui des spécificités très fortes en matière décisionnelle, non seulement sur les données, mais même sur les outils. Certaines thématiques comme le marketing des réseaux sociaux, le lean dans la production, la prévision des ventes, etc. ont aujourd’hui des solutions à caractère décisionnel qui se spécialisent de plus en plus. Et s’intègrent en retour de plus en plus vers le SI opérationnel (gestion de production, gestion des achats, site eCommerce, etc.)

Sur l’axe des entités (branches et/ou business units) : la spécificité des entités doit être comprise et cartographiée.

Il y a des domaines où il y a une volonté de mutualisation groupe et/ou des bénéfices de mutualisation évidents. Pour ces thématiques là la relation avec les entités doit aller dans le sens d’une collaboration des experts. Des cercles de compétence sont une méthode d’organisation très intéressante qui peut donner l’opportunité du partage des
initiatives et des pratiques.

Il y a des entités qui ont des besoins spécifiques du fait de leur business model, de leurs produits ou de leurs services. Il faut dans ce cas une relation directe avec les métiers concernés.

Quelle est la répartition des rôles au sein de la DSI ?

Notamment, quel  répartition des rôles entre les équipes études et les équipes de production/exploitation du SI ?

Le fonctionnement classique d’un SI est de séparer assez fortement la partie études de la partie exploitation. Et ce, pour plusieurs raisons :

  • la structure de coûts : un bon ingénieur d’études décisionnel coûte 3 à 5 fois plus cher qu’un exploitant technique.
  • l’organisation service en astreintes pour tenir les objectifs de niveau de service : les équipes d’exploitation sont organisées pour couvrir les plages étendues pour faire face aux incidents hors plages standards des équipes étude.
  • la séparation des rôles : il est dangereux qu’une même personne développe et opère un SI. Dangereux en termes de risques informatiques, dangereux en termes de qualité, en termes de pérennité des compétences. Il n’est pas rare qu’un brillant spécialiste big data ou BI change de job. S’il n’avait pas été contraint par une cellule de production à formaliser la connaissance sur sa solution, au moins en mode run, c’est le fonctionnement de l’entreprise qui peut être mis en péril.

Cependant cette séparation est mise à mal par plusieurs éléments, et cela s’accentue :

  • la complexité fonctionnelle du processus d’alimentation et de fonctionnement d’une solution décisionnelle est structurellement grande. Beaucoup d’échanges.  Beaucoup d’incidents. En effet, une solution big data est mécaniquement en aval de tout le SI. En tant que telle, elle subit tous les aleas du SI. Tout incident en amont a souvent des conséquences en aval. Avec une variété des cas telle qu’elle peut
    rarement être procédurée et laissée donc à la main de non sachants. Donc même dans une BI classique, il y a toujours une structure d’exploitation applicative qui suit le fonctionnement des solutions décisionnelles. Cela ne peut pas être complètement évité. Mais il faut en revanche toujours veiller à transférer le maximum vers une exploitation technique et à formaliser des consignes permettant le meilleur niveau de service.
  • les nouvelles solutions sont de plus en plus complexes. Les outils big data, nosql,  in memory db , les algorithmes de traitement sont des solutions très avancés et non conventionnels. L’expertise manque dans les DSI au niveau des équipes  exploitation.

Une bonne manière de répondre à ces enjeux est de regarder les sujets en face : si une solution devient critique pour l’entreprise, il est nécessaire de mettre en place une organisation pour la gérer. Le principe d’une séparation entre projet et run est indispensable. Mais l’organisation du run peut/doit avoir de la souplesse. Des équipes hybrides entre production et études a du sens au moins sur certains thèmes. Il faut juste regarder le véritable coût complet d’une solution et ne pas masquer un coût récurrent dans un coût projet ou vice versa.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *