Optimiser sa gestion de projet BI SAP – Pourquoi Agile et BW/4HANA font bon ménage ?
Un projet qui n’aboutit pas? L’impression de perdre le contrôle? Et si piloter en agile votre projet BI était la solution ?
Vous vous dites peut-être, « l’agile OK pour le reporting mais impossible pour un projet d’entrepôt de données ». Vous pensez par exemple que des cycles de développement de 3 ou 4 semaines seront trop courts pour construire un socle de données cohérent.
Vous avez aussi en mémoire ces projets où pendant 3 mois on vous dit « la mise en place du socle est en cours » et au bout des 3 mois vous ne voyez rien. Frustrant !
Le problème de notre ancien cycle en V
C’est ce qu’on appelle l’effet tunnel du cycle en V. Après des semaines à bien comprendre votre besoin puis des mois à le développer, votre intégrateur vous livre en retard un produit… hors sujet. Pour ne rien simplifier pendant ce temps là votre besoin a évolué mais personne ne vous écoute car “c’est hors périmètre !”.
L’idée est de sortir de la logique projet séquentielle du cycle en V afin de :
- voir le produit évoluer au rythme des livraisons de votre intégrateur
- d’impliquer plus tôt vos utilisateurs dans les activités de test
- pouvoir adapter/changer votre besoin en cours de projet sans que cela soit trop tard
Nous allons maintenant essayer de comprendre quels sont les enjeux d’un projet BW/4HANA et comment les rouages de l’agilité peuvent vous aider à sécuriser votre projet.
Enjeux d’un projet d’implémentation BW/4HANA
Indépendamment de la façon dont l’implémentation BW/4HANA est menée, il faudra faire face à de nombreux challenges :
- Remonter de la data de qualité adaptée aux besoins métiers
- Bénéficier de performances robustes
- Conserver la solution la plus simple possible
- Piloter le projet et les ressources
Pour vous aider BW/4HANA possède un panel de caractéristiques permettant de simplifier les développements. Nous avons déjà écrit quelques lignes sur le sujet (ICI) mais pour n’en citer que 3 :
- Performance (via encore plus de pushdown dans HANA)
- Simplification des flux (moins d’objets, plus de possibilités)
- Plus de connectivités (SDI, SDA, Big Data…)
Rappel du cadre agile SCRUM
Avant d’aller plus loin, un rappel rapide du cadre agile SCRUM via 3 slides qui abordent les concepts clés, les process, les intervenants :
Les différentes cérémonies :
Voici comment ces cérémonies s’orchestrent avec leurs intervenants respectifs :
L’approche SCRUM est celle que nous avons l’habitude de suivre. Elle est le plus souvent la plus adaptée au contexte d’un projet BI.
Pourquoi Agile & BW/4HANA font bon ménage ?
Reprenons les challenges BW/4HANA identifiés au préalable et voyons l’apport d’une approche agile.
Un tableau pour ceux qui n’auront pas le courage de tout lire (vraiment dommage)
| Challenge d'un projet BW/4HANA | Apports du cadre agile |
|---|---|
| Remonter de la data de qualité adaptée aux besoins métiers | Implication du product owner et des key users très tôt dans le projet pour valider les transformations de données et les KPI |
| Bénéficier de performances robustes | Cycles courts de livraison :
|
| Conserver la solution la plus simple possible | Le rythme des sprints nécessite d’aller à l’essentiel : pas le temps de mettre en place des usines à gaz (et c’est tant mieux) Des échanges facilités avec le métier : mieux comprendre le besoin, le challenger si nécessaire et anticiper des contraintes techniques très tôt dans le projet Meilleure prise en compte des évolutions du besoin métier |
| Piloter le projet et les ressources | Intensification des échanges entre développeurs et avec le métier :
|
Remonter de la data de qualité adaptée aux besoins métiers
Avec BW/4HANA il est possible très rapidement de livrer de la data exploitable : une vue + un composite provider + une poignée de masterdata = un classeur Analysis for Office pour explorer la donnée.
Inutile d’attendre la livraison de votre 1er rapport SAC tout beau tout finalisé. Vous aurez ainsi des retours de key users beaucoup plus rapides concernant :
- L’intégrité des masterdatas
- La pertinence des données transactionnelles remontées
- L’application des règles de gestion lors de la transformation de la donnée
Vous préférez avoir des développeurs qui font 1000 TU sur de la donnée brute ou l’œil de lynx du contrôleur de gestion qui va tamponner vos KPI financiers d’entrée de jeu ?
Chez un de nos clients nous avons commencé comme cela, une première modélisation avec des vues HANA + un Composite Provider. Très rapidement nous avons pu lancer les premiers ateliers. Les vues HANA, avec des règles de gestion virtualisées, évitent de créer trop d’objets BW et permettent de très vite intégrer les premiers retours et d’intensifier les échanges avec le métier.
Bénéficier de performances robustes
Les cycles de livraisons courts du SCRUM vont vous donner rapidement un état des lieux des performances de la solution et de l’attendu des key users. Très en amont, les choix d’architectures pourront être adaptés, notamment avec les nouvelles fonctionnalités de BW/4HANA de virtualisation et de pushdown dans HANA. N’attendez pas la fin du projet ou un éventuel sprint d’optimisation… il sera peut être déjà trop tard pour revenir sur vos choix d’architecture !
De plus vous serez très rapidement en situation réelle, en production. Vous pourrez rapidement lancer des chantiers techniques s’il s’avère que les systèmes ne sont pas adaptés (sizing).
Lors d’un projet de reporting commercial mené en SCRUM nous avons été confrontés à des problèmes de performances lié à des KPI très complexes calculés au niveau du query designer. Nous étions passés d’une ouverture de rapport en 6 secondes à 30 secondes à la suite de l’ajout de ces KPI.
Nous utilisions des fonctionnalités Query Designer classiques. Après quelques ajustements de ces dernières, nous avons réussi a pousser les calculs dans HANA sans utiliser de vues et ainsi améliorer drastiquement les performances. Nous avons évité de remettre en cause tous nos choix d’architecture.
Conserver la solution la plus simple possible
C’est l’un des principaux écueils d’un projet BI, conserver de la simplicité. Une architecture simple sera, de fait, plus maintenable et plus évolutive.
Comment une approche SCRUM peut vous aider dans cette quête de la simplicité ?
Le rythme et la durée des sprints (max 4 semaines) nécessitent d’aller à l’essentiel. Cela ne permet pas aux développeurs de se lancer dans des usines à gaz.
Les très nombreux échanges avec le product owner permettent d’affiner la compréhension des besoins et ainsi le challenger et l’aider à arbitrer. Il faut arriver à avancer en maîtrisant l’incertitude et évaluer le coût d’un refactoring. Cette évaluation sera réalisée en sprint planning, le besoin restera dans la backlog si l’incertitude est trop forte et le niveau de complexité trop élevé.
L’exemple de projet cité précédemment est très parlant. Pour trouver une solution en peu de temps, avoir un rapide retour du client sur leur ressenti à propos des performances et pouvoir échanger avec le PO, nous avons choisi de tester la solution de pushdown dans HANA sur les exceptions d’agrégation, rapide à développer et finalement suffisante.
Pour améliorer les performances nous aurions pu revoir toute l’architecture, virtualiser avec un maximum de modeling HANA, un enchaînement de calculation views, des table functions et du code AMDP un peu partout. Vous auriez vu des étoiles briller dans les yeux des inconditionnels de la prouesse technique. Peut-être nous aurions eu des performances 10% meilleures mais à quel prix ?
Piloter le projet et les ressources
Monter des usines à gaz, mal comprendre le sens métier, être isolé avec sa spécification technique ont aussi un coût très important. Comment conserver une motivation intacte dans vos équipes et celles de votre intégrateur quand vous ne voyez pas le bout du tunnel ?
Un cadre agile comme le SCRUM, peut encore une fois vous aider, même au milieu du tunnel.
Les cérémonies, notamment le daily meeting, seulement entre développeurs, sans la pression extérieure ou hiérarchique, intensifient les échanges et enrichissent leurs quotidiens. Les consultants ne sont pas isolés sur seulement une facette du projet, cela améliore la mobilité sur les sujets, le partage de connaissances et aide à la gestion de projets qui durent souvent plusieurs mois. De fait, les sujets sont plus facilement backupés.
Les échanges avec le product owner donnent du sens à ce que développent les consultants et une meilleure compréhension des enjeux techniques pour le PO. Très rapidement le projet nécessitera d’intervenir sur différents sujets : le datawarehouse, le reporting et l’accompagnement au changement. Autant d’occasions d’enrichir le quotidien des développeurs.
Sur nos projets, sur certaines problématiques nous mettons en place un système de double check entre développeurs : meilleure assurance que tout est ok, partage de la connaissance sur le sujet, regard extérieur qui peut faire la différence.
L’agile et BW/4HANA : pas une solution miracle
Malgré les possibilités offertes par BW/4HANA certains contextes projets peuvent difficilement se dérouler en mode agile. Nous voyons trois types de projets où l’agile n’apporte pas ou peu d’avantages :
- Un projet de migration ou d’upgrade technique de votre BW sans remodélisation
- Un projet où l’attendu est connu précisément
- Un niveau de complexité technique trop important nécessitant de longs mois de développement du back avant de remonter de la donnée
L’agile prend vraiment sens quand le niveau d’incertitude est important.
Enfin, quelque-soit le contexte, une condition indispensable à la réussite d’un projet en mode agile est l’engagement et la disponibilité des équipes, côté intégrateur mais aussi côté client. L’application d’une méthode ne peut pas être décidé unilatéralement sans un accompagnement des développeurs et des key users.
Le choix de votre Product Owner sera décisif, il doit porter la vision du produit, avoir une bonne connaissance du métier, prioriser les sujets, être capable de mobiliser les sponsors et autres supports pour mener le projet à son terme.
BW/4HANA en agile : It’s a Match !
Comme vous avez pu le voir, travailler en mode agile dans les règles de l’art va vous aider à livrer un projet dans les temps, dans le budget et dans la bonne humeur tout en répondant aux enjeux d’un projet BW/4HANA. Vous allez pouvoir livrer une solution avec de la donnée de qualité, adaptée aux besoins du métier, avec des performances au top. Cette solution simple et robuste vous accompagnera de nombreuses années.
Si vous voulez reprendre le contrôle sur votre projet et faire matcher votre BI SAP avec vos besoins métiers, contactez l’un de nos experts.
Nous espérons vous avoir convaincu de l’intérêt de l’approche agile pour livrer vos projets BI.