Le contexte
Intis a accompagné une filiale d’un groupe étranger de l’industrie électronique dans son projet SI-Finance. Il s’agissait de modéliser une application de reporting et de prévisions pour la direction financière : digitaliser le processus financier, du reporting au P&L. Le responsable informatique de la filiale nous fait part ici de son expérience de la mise en place de la technologie IBM Planning Analytics with Watson.
Les attentes et objectifs du projet
Quels étaient les objectifs métiers de ce projet SI-Finance ?
“Nous souhaitions acquérir une meilleure visibilité sur nos activités et une meilleure compréhension des comportements clients. Nous voulions détecter facilement les faiblesses, faciliter la prise de décision stratégique ou tactique en fonction des éléments observés, être réactifs face à un événement…
Ce projet pilote concernait la préparation budgétaire. Il a été découpé en 3 lots:
> un module « frais généraux »
> un module « immobilisations »
> un module “RH et analyses des coûts”.
A la suite du budget, l’équipe souhaitait travailler sur le suivi des forecasts, les réalisés et les simulations. L’objectif était de pouvoir faire dans un seul outil tout le processus : du reporting au P&L.
Le module « ressources humaines et analyses des coûts » était également prévu afin de mesurer la répartition des coûts de personnels directs et indirects. L’objectif final était d’obtenir un suivi budgétaire complet avec une intégration des budgets RH.”
Quelles difficultés aviez-vous avant ce projet SI-Finance ?
Les outils de pilotage utilisés auparavant présentaient des problématiques qui ont permis d’identifier deux besoins principaux :
> Un besoin d’amélioration des rapports et des prévisions, difficile à mener avec des outils bureautiques.
> Un besoin d’homogénéiser les multiples outils informatiques satellites ramenant différentes informations.
S’est posé la question de continuer avec Excel, mais des limites avaient été identifiées avec cet outil bureautique :
> Une difficulté à élaborer des simulations
> Un reporting limité aux données accessibles en direct et en une dimension
> Une gestion fastidieuse de la contribution des 60 utilisateurs métiers (20 personnes sur les saisies et 40 managers/valideurs)
Il y avait donc un besoin de fiabiliser les données durant toutes les étapes : collecte, saisies et compléments d’informations. Ces tâches, réalisées manuellement auparavant sur Excel, prenaient du temps. Les données étaient ensuite transférées vers l’AS400, à revalider et à réévaluer suivant l’année.
Quelle solution pour y répondre ?
Nous recherchions un outil de gestion capable de piloter l’ensemble du processus d’analyse financière : contrôle et préparation des budgets, jusqu’au P&L. Nous devions répondre aux différents besoins d’analyses et de simulations financières de manière à améliorer toute la partie reporting et la partie prévisionnelle.
Le choix de la technologie : IBM Planning Analytics
Pourquoi avoir choisi cette technologie ?
Les fonctionnels, la DSI et l’intégrateur ont étudié plusieurs possibilités qui présentaient des inconvénients et qui n’ont pas été retenues :
- Modéliser les besoins dans les outils bureautiques existants avec les limites évoquées précédemment.
- Développer en interne une application de Business Intelligence.
Le désavantage : les outils BI n’intègrent pas d’espace de simulation avec des « bacs à sable » (espaces de tests personnels), à l’inverse des outils EPM (Enterprise Performance Management) comme IBM Planning Analytics.
Le choix s’est donc porté vers la technologie EPM IBM Planning Analytics, solution de planification, budgétisation, d’analyses et de prévisions.
Quels avantages avez-vous trouvé à cette technologie ?
Les critères qui ont joué en sa faveur :
- Le rapport qualité/prix
- Un progiciel déjà éprouvé au sein d’autres filiales du groupe
- Un développement informatique low-code
- Une analyse des données multi-dimensionnelle
- Une compatibilité avec tous les systèmes d’information existants
- Une intuivité
- Un niveau de détail poussé
> Un développement informatique intégré à l’application
La solution permet de développer directement le module de préparation budgétaire. Elle intègre un outil de développement low-code (interface utilisateur graphique, au lieu d’une programmation informatique traditionnelle codée à la main). Cela répondait à notre besoin de piloter le processus budgétaire dans sa globalité.
> Une construction multidimensionnelle
L’aspect multidimensionnel (croisement de multiples critères d’analyse) facilite la manipulation de grandes quantités de données et permet de réorganiser les informations à volonté, afin de réaliser des analyses pointues et d’appuyer une décision. L’outil ne présentant aucune limite en termes de nombre de dimensions, un élargissement à d’autres fonctions que la direction financière peut être envisagé : RH, planning de production, coût de production, contrôle qualité, contrôle de mesure.
> Une compatibilité avec les systèmes d’information existants
La technologie récupère les données d’une multitude d’outils et les croise pour générer des rapports. Cela était impossible auparavant, ou très difficilement, et nécessitait une extraction laborieuse de plusieurs systèmes.
> La convivialité de l’outil
La solution, avec ses tableaux de bord, est graphique, moderne et élimine les validations manuelles, remplacées par une validation électronique (à l’inverse d’Excel, qui reproduit les erreurs de calculs). Les utilisateurs voient l’impact sur leurs budgets totaux avec les simulations et ont désormais la possibilité de mettre un objectif budgétaire.
> Un niveau de détail poussé
IBM Planning Analytics offre la possibilité d’accéder aux rapports par service/par département/par compte budgétaire, et d’obtenir un espace de simulation permettant de voir l’impact quand il y a des modifications de données. Ce qui appréciable à un niveau P&L.
Quels points ont été plus difficiles ?
> Des délais de latence et ralentissements
Sur le module « frais généraux », on constate une rapidité de saisie malgré quelques délais de latence. En revanche, on note des ralentissements sur le module « immobilisations ». En effet, les calculs intègrent différentes contraintes de dates, de périodes d’amortissements, des calculs d’amortissements…, ce qui alourdit l’outil. La saisie est perçue comme longue par les utilisateurs. Cependant, la modélisation étant sur mesure, ces éléments peuvent être affinés et optimisés, de façon à rendre l’application plus performante. La technologie derrière la modélisation est capable de gérer de fortes quantités de données et une modélisation complexe.
> L’optimisation des calculs automatiques
La capacité des serveurs est un autre élément à prendre en compte. Dans ce cas-ci, la validation automatique des calculs d’une seule ligne entraînait un recalcul de l’ensemble des rapports, ce qui poussait les serveurs à leur capacité maximale. Au fur et à mesure de l’usage, les calculs ont pu être optimisés et ainsi, éviter ceux qui n’étaient pas nécessaires.
> La complexité dans la gestion des dimensions et l’allongement des temps de calculs
Quand une donnée est modifiée, celle-ci se reporte dans de multiples dimensions et de multiples sections budgétaires, ce qui participe à l’allongement des temps de réponse des calculs. Pour pallier cette problématique, on optimise en effectuant les calculs le soir, puisqu’il n’y a pas un besoin de temps réel pour l’instant. Cette solution est temporaire car le but est de mettre à jour les calculs plus fréquemment.
> Les flux de validation
Le processus de validation était complexe, constitué de 4 niveaux, avec des pré-checkers en amont. La fonctionnalité de workflow de validation a pu répondre aux besoins. Cependant, le groupe possédait des outils de validation perçus comme plus conviviaux. S’est posé rétrospectivement la question d’utiliser une technologie existante en interne. Cependant, intégrer les workflows de validation et les formulaires de saisie dans IBM Planning Analytics présentait l’avantage de tout faire dans le même outil.
Avez-vous rencontré des obstacles dans la mise en oeuvre de ce projet SI-Finance ?
> Réfléchir en cubes
Les cubes permettent le croisement de plusieurs axes d’analyse. La notion de cube était nouvelle pour les équipes. Les autres systèmes d’information n’en comportent pas et fonctionnent avec des bases de données à plat. L’équipe projet a vite perçu que si le cube était mal préparé, mal étudié au départ, il allait très vite manquer des données et des dimensions pour concevoir les reportings. Les premiers cubes ont dû être modélisés et modifiés plusieurs fois lors de leur élaboration. La question importante à se poser : que veut-on comme dimension (axe d’analyse) dans le reporting ? Dans ce cas-ci, les métiers n’avaient pas forcément conscience de toutes les dimensions nécessaires en amont. C’est au fur et à mesure de l’expérience que les éléments importants ont été établis. Il y a eu des points positifs et des points pour lesquels l’équipe a dû monter en compétences pour comprendre si les cubes avaient bien été évalués.
Le point de vue de l’IT sur l’autonomie des métiers
L’autonomie des métiers est-elle nécessaire selon vous après un projet SI-Finance ?
Mon avis sur la question : si la solution technologique n’a pas vocation à être étendue à d’autres métiers ou à d’autres usages, alors l’autonomie des métiers n’est pas forcément nécessaire.
Dans notre cas cependant, nous voulions être autonomes sur la partie reporting. En revanche, la structure des formulaires ne change pas tous les ans. Nous aurions donc pu questionner la nécessité d’être autonomes sur ce sujet. Mais en nous formant en interne, nous sommes non seulement en mesure de faire des modifications, mais également, grâce à la connaissance de l’outil, de savoir ce qu’il sera possible de faire dans le futur sur cette technologie.
Quels sont les avantages à être autonome vis-à-vis d’un prestataire externe ?
> Pouvoir dédier un support en interne
En période de préparation budgétaire, le temps est limité. Il faut pouvoir résoudre rapidement une problématique. Même si le prestataire externe continue de soutenir l’équipe et garde une vision globale, une personne, interne ou externe, doit travailler régulièrement sur le sujet pour rester efficace dans les délais de réponse (surtout avec les spécificités qu’impliquent notre activité). Dédier un développeur pour accompagner les évolutions de l’application est important.
> L’aspect financier
Si on a les ressources nécessaires pour assurer le maintien, on s’y retrouve très vite financièrement. C’est un investissement de temps, mais c’est aussi une question de priorité. L’objectif est de pouvoir maintenir à la fois toutes les applications développées et d’être en mesure de faire tous les prochains développements. L’intégrateur intervient quand nous avons besoin de nouvelles compétences, qui dépassent celles acquises sur l’outil ou quand il y a un manque de ressources pour un projet non prioritaire. Notre activité n’étant pas très changeante, une partie du travail peut être faite en interne.
« Si l’on n’a pas les bonnes données au départ, peu importe la modélisation qui va suivre, le projet sera un échec. Quand on a les données et que l’on sait ce que l’on veut, la mise en oeuvre technique est facilement réalisable. »
> La préparation des données
La partie IT n’est pas la plus complexe dans un projet SI-Finance. Sur ce genre de projet, que l’on soit autonome ou non sur son application, il y a une partie non externalisable : la préparation des données. Si l’on n’a pas les bonnes données au départ, peu importe la modélisation qui va suivre, le projet sera un échec. Il faut donc préparer les données avant le projet. Quand on a les données et que l’on sait ce que l’on veut, la mise en oeuvre technique est facilement réalisable.
> Une compréhension technique de l’application
Dans notre cas, si les métiers sont autonomes sur le développement des reportings, le reste nous semblait trop complexe pour être géré par le business. Ce n’est pas infaisable car Planning Analytics est un outil de low code. Mais à partir d’un certain niveau, il manque au Business des compétences de développement, une compréhension d’une méthode et des difficultés qui peuvent survenir. Evidemment, cela dépend des personnes et des compétences. Nous avons fait le choix de centraliser le projet à l’IT car c’est notre métier. L’avantage est que nous avons les connaissances techniques sur les analyses et le développement. Cela nous permet également d’affecter une ressource dédiée.
> Disponibilité et réactivité
La problématique n’est pas de travailler ensemble mais d’avoir les personnes disponibles quand il le faut. Si on veut être réactif, le soutien d’un prestataire qui a les compétences, l’expérience et la connaissance de l’outil est nécessaire. Sans les techniques adaptées, on passerait notre temps à faire, casser et refaire. Et si l’IT construit pour les métiers, alors les spécifications risquent de ne pas être adaptées et l’adhésion à l’outil n’est plus aussi forte. Quand le projet est porté par les métiers, l’adhésion des utilisateurs, même si elle n’est pas garantie, est plus facile, dans la mesure où l’on promeut bien l’outil et que l’on aide les personnes à se l’approprier.
L’accompagnement de l’intégrateur
Comment l’intégrateur vous a-t-il accompagné dans ce projet SI-Finance ?
Pour faire face à certaines difficultés techniques rencontrées par les équipes lors de la mise en oeuvre, comme notamment le fait de devoir réfléchir en cubes, l’intégrateur a accompagné les équipes internes :
> dans la montée en compétence
> pour le support.
ORIENTER
L’objectif était que l’équipe intégratrice ne réalise pas tout le développement et tous les entretiens de définition des besoins avec les métiers, mais :
> qu’elle nous soutienne et nous oriente lors de la phase de démarrage (sur les questions de dimensions notamment),
> nous oriente sur les éléments à prendre en compte en amont,
> nous signale les problématiques que l’on pourrait rencontrer et, si possible, nous permette de les éviter.
CADRER
L’équipe intégratrice a été d’une grande aide au départ pour nous mettre le pied à l’étrier. Certains points, prévus comme larges au début pour couvrir tous les aspects, peuvent se révéler finalement insuffisamment précis pour adresser tous les besoins. Cela peut avoir pour conséquence des oublis de certaines données, dimensions et informations à prendre en compte dans les cubes. L’intégrateur a pour rôle de cadrer le besoin le plus précisément possible pour limiter les rajouts par la suite.
FAIRE MONTER EN COMPETENCES
L’intégrateur a également été une assistance dans la montée en compétences. Les phases de développement et d’appropriation de l’application se sont déroulées sans accroc.
Le projet a été mis en oeuvre lors du premier confinement de la crise du covid 19. Sans possibilité de présence sur le site, sans être tous réunis autour de la même table avec les mêmes informations devant les yeux, ce projet SI-Finance aurait pu être plus long et plus ardu. Le présentiel aurait permis de creuser facilement les détails, de montrer facilement des exemples.
Avec la crise, nous avons basculé sur des outils de prise en main à distance, ce qui était nouveau pour beaucoup de nos collaborateurs. Cela a été l’apprentissage d’une nouvelle façon de travailler en collaboratif, et ce, en plein projet. Si cela a complexifié l’ensemble des échanges et rallongé les délais, nous avons pourtant atteint les objectifs.
L’aide d’Intis a été très appréciée. Sur la phase de démarrage, comme aujourd’hui sur la phase d’optimisation, nous faisons appel aux compétences et aux expériences de l’intégrateur pour améliorer notre usage de la solution.
Qu’est-ce qu’un bon intégrateur selon vous ?
LA QUALITE DES REPONSES
Un bon intégrateur se définit par la qualité de ses réponses et de leur suivi. Dans notre cas, l’intégrateur a apporté sa valeur ajoutée en creusant la problématique, ce qui a été apprécié.
> Il proposait différentes solutions,
> orientait la solution technique en se basant sur son expérience,
> proposait des réponses reposant sur des cas concrets.
Il a su nous orienter vers la solution la plus viable, la plus adaptée à nos besoins. Le contact a été très bon et les discussions ouvertes.
Quels ont été les critères de choix de l’intégrateur pour ce projet SI-Finance ?
Le choix de l’intégrateur s’est fait via le choix de la technologie. En effet, l’équipe intégratrice a su montrer que l’outil apportait la réponse aux besoins. Par ailleurs, la négociation s’est faite sans blocage. La qualité et la rapidité des réponses avec des présentations de cas concrets et d’exemples nous ont convaincu sur de nombreux points. Les transferts de compétences ont été bons puisque l’on a toujours su trouver des solutions.
Comment s’est déroulé l’accompagnement à la technologie ?
> Les formations techniques de l’éditeur ont été dispensées en e-learning, accompagnées par l’intégrateur.
> Nous avons eu des moments d’échanges sur des points précis.
> Des réunions entre le business et l’IT ont été organisées pour donner une direction, ou seulement avec l’IT pour avancer techniquement.
> Nous faisions une liste de l’ensemble des questions puis faisions un point avec l’intégrateur pour y répondre et voir si toutes les données étaient correctes. Se rajoutait un échange technique avec l’équipe de développement pour structurer les données.
Quelles difficultés avez-vous rencontré lors de projet SI-finance ?
UNE CRISE SANITAIRE
Le projet a été réalisé en pleine crise covid. Une situation qui a généré plusieurs obstacles sans pour autant porter atteinte aux bons, voire très bons résultats pour cette première partie de projet. Le projet a notamment accusé un léger retard. Si les résultats ne sont pas encore parfaits à ce jour, l’équipe a désormais une vision claire des différentes contraintes liées à la solution, des éléments à optimiser, à modifier. Si des problématiques ont été rencontrées, elles sont habituelles sur ce type de projet, liées à la phase d’adaptation.
L’organisation du projet SI-Finance et des équipes
Organisation, disponibilité et méthodologie
Comment avez-vous organisé les équipes pour mener ce projet ?
Certaines ressources étaient dédiées intégralement au projet. Pour d’autres, le projet était intégré à leurs tâches habituelles.
Côté informatique, trois personnes y ont été intégralement dédiées au début. Au fur et à mesure, l’équipe à temps plein sur le projet s’est réduit à deux puis un.
Côté fonctionnel, deux personnes participaient au projet en parallèle de leurs activités habituelles. Et le fait qu’il n’y ait pas de personne entièrement détachée côté métier a eu pour conséquence un ralentissement dans l’avancée du projet. Quand il y avait un besoin de certaines données à certaines périodes, il arrivait que personne ne soit disponible pour répondre aux demandes.
Une personne était entièrement dédiée à la communication entre le métier et l’IT et à la centralisation des informations dans l’objectif de faire gagner du temps au reste de l’équipe.
UN PROJET SI-FINANCE PRIORITAIRE
Le projet étant prioritaire pour l’IT, les demandes liées à des dysfonctionnements et aux demandes de droits d’accès étaient instantanément traitées. En revanche, si la demande impliquait un gros développement et nécessitait un accompagnement au changement, se posait alors la question de la priorité de cette demande.
UNE METHODE COACHING
Nous avons fait le choix de développer nos applications d’aide à la décision en coaching : les équipes internes développaient, guidées par des consultants experts. Les équipes métier, l’informatique et d’autres personnes concernées par un point spécifique du projet ont dû s’organiser entre elles pour avancer. Pour aider à atteindre cet objectif, la personne dédiée à la communication entre le métier et l’IT se consacrait au suivi du projet et aux résolutions des difficultés.
Pourquoi une méthode coaching ?
Trois possibilités s’offraient à nous pour développer notre application de pilotage selon nos besoins :
> La sous-traitance à 100% du développement de l’application.
> Une sous-traitance partielle avec une partie faire en interne.
> Un développement effectué à 100% en interne avec l’intégrateur en support et accompagnant la montée en compétence.
Nous nous sommes orientés vers la 3ème solution car nous avions l’ambition de faire d’autres projets au sein de l’entreprise sur cette solution. Nous voulions être capables de développer en autonomie les autres modules quand il faudrait étendre l’usage.
Le coaching s’est très bien passé malgré la période de confinement et le manque d’habitude d’utilisation d’outils collaboratifs des équipes internes.
Bien que nous soyons désormais autonomes sur la solution, nous continuerons de solliciter l’intégrateur pour le développement des autres modules et pour garder une visibilité globale. Nous continuerons de profiter de son expérience et de son expertise sur ces nouveaux projets, qui nous exposeront probablement à de nouvelles problématiques.
Comment avez-vous géré la disponiblilité des équipes de ce projet SI-Finance ?
Les difficultés d’un projet informatique pour les métiers résident souvent dans la disponibilité des ressources et les possibles incompréhensions… Ces difficultés impactent souvent les délais. Pour un projet de 3 mois, on peut compter un retard de 1 mois à 1 mois et demi, plus un temps de rattrapage.
Pour ce projet, le retard était moins lié à des problématiques de ressources ou d’incompréhensions et davantage lié au travail à distance dû à la crise covid (manque d’ateliers, de temps de travail sur lequel les équipes sont monopolisées : à distance, il est difficile de bloquer toute une journée).
Les bonnes personnes doivent être disponibles pour les étapes clés du projet. L’intégrateur avait insisté sur la disponibilité, essentielle à certaines étapes du projet, notamment de l’équipe IT.
