Agilité en BI AGILITÉ EN BI. L'agilité en BI afin d'augmenter votre retour sur investissement. Contactez-nous:

Transcription

1 AGILITÉ EN BI L'agilité en BI afin d'augmenter votre retour sur investissement

2 Les auteurs Alexandre Langlois Fort de ses 13 années en technologies de l information, dont 5 ans en intelligence d affaires, M. Langlois démontre une capacité d adaptation et de compréhension des environnements d affaires lui permettant d offrir du conseil stratégique qui surpasse les attentes. Titulaire d une maîtrise en administration des affaires sous profil conseil en gestion et Scrum Master certifié il a exercé des postes de gestion pendant une dizaine d années. Ses interventions sont ciblées pour adresser les enjeux concrets allant de l évolution des environnements analytiques, de l optimisation des processus opérationnels à l efficacité de la structure des équipes. M. Langlois a su prouver sa valeur dans des mandats d envergure dont de l accompagnement stratégique pour la mise en place d environnements analytiques, des plans directeurs, des audits ainsi que pour des initiatives impliquant la gestion de sous-traitants à l étranger. Dans tous ses mandats, ses interventions ont su créer de la valeur pour l organisation, et ce, d une manière pérenne. Ghislain Gagné M. Gagné compte plus de 8 années d expérience en développement de systèmes décisionnels et en services-conseils. Ses mandats l ont amené à travailler dans plusieurs secteurs et industries, dont la finance, la logistique, le secteur manufacturer et les télécommunications; ce qui lui a permis de parfaire une approche de livraison agile en intelligence d affaires. Depuis quelques années, M. Gagné se spécialise dans l implantation de pratique agile, la gestion du changement et l élaboration de programmes en Intelligence d affaires. Il est diplômé de HEC Montréal où il a obtenu une M.Sc en Logistique ainsi qu un Baccalauréat en Finance et Technologie de l information. M. Gagné possède également la certification Scrum Master.

3 L agilité en BI afin d augmenter votre retour sur investissement Avez-vous l impression que vos projets d intelligence d affaires n apportent pas les bénéfices promis? Êtes-vous constamment en compétition de délais et de coûts contre des solutions non centralisées de type «Excel» et «Access»? Malheureusement, cet état de fait se confirme dans de plus en plus d organisations. Il serait facile de débuter ce livre blanc avec des statistiques liées à l échec des projets d intelligence d affaires, tant en ce qui concerne les budgets, les échéanciers que de la faible valeur organisationnelle livrée par l initiative. Par ailleurs, il est inutile de mettre de l avant les statistiques pour confirmer ce que nous savons tous, soit que les projets d intelligence d affaires, dans bien des cas, n ont pas apporté à l organisation la valeur promise. L industrie du BI tente d expliquer cette problématique à l aide de plusieurs arguments: La complexité des outils; Le manque d intégration entre les composantes de l architecture d intelligence d affaires; La maturité des organisations vis-à-vis l intelligence d affaires ou IA; Manque de leadership organisationnel; Le manque de compréhension des affaires par les TI. Certes, ces facteurs ont tous eu des impacts importants sur la complexité de ce type de projets et, du même coup, de la difficulté inhérente à la livraison de ces derniers. Cela dit, complexité ne signifie pas nécessairement un dépassement des échéanciers et des budgets duquel découlerait une valeur organisationnelle concrète. Les projets produisant des solutions complexes doivent être encadrés conséquemment afin d en assurer le succès. Afin de mieux cerner ces problématiques, nous avons isolé quatre pistes de réflexion que nous analyserons afin d en découler des actions concrètes et réalistes: Les besoins changent constamment, c est une réalité! Comment arrimer flexibilité et structure? Comment rivaliser avec les solutions décentralisées? Les sprints : une approche itérative permettant de livrer de la valeur rapidement L équipe est le moteur de réalisation. Comment garder son équipe motivée et productive tout au long du projet? Comment assurer un maximum de valeur organisationnelle? La maximisation du ROI par l agilité. Arrimer flexibilité et structure Une réalité inhérente au développement d une solution, qu elle soit de nature transactionnelle ou analytique, est que la vision du client évoluera considérablement tout au long du projet. En intelligence d affaires, il est fréquent d observer que plus l utilisateur s approprie son environnement analytique, plus ses besoins informationnels sont portés à changer. Par exemple, au début du projet, l utilisateur demandera à voir les ventes de ses 10 meilleurs produits par régions. Lorsqu il aura cette information en main, d autres questions lui viendront certainement à l esprit afin de bien comprendre la situation.

4 Les méthodes traditionnelles de livraison sont plus ou moins appropriées pour gérer adéquatement l impact que cette réalité peut avoir sur les délais de livraison et les coûts du projet. En effet, l approche de livraison en cascade (waterfall) implique une collecte des besoins en début du projet, suivi d une longue période d analyse et de développement. De par la ségrégation des tâches, souvent exécutées par des personnes différentes, il n est pas rare d observer des cycles de développements qui se déroulent sur une période de 4 à 6 mois, parfois même plus. Ces coûteux développements impliquent plusieurs transitions, communément appelées hard hand-off. C est souvent à la fin de cette période de développement que le client prend possession, pour la première fois, de la solution et réalise que ses besoins ont évolué ou se sont raffinés. Le résultat? Une solution qui n apporte pas la valeur escomptée. Comme nous le savons, par définition, l'analyse d'une situation d'affaires peut avoir de nombreuses ramifications dans l'organisation. Ces ramifications sont souvent identifiées pendant et après l'implantation de la solution. Cela mène inévitablement à des changements aux priorités pour tenter d'atteindre l'objectif visé. Contrairement aux méthodes traditionnelles de développement, les approches de livraison agile, telle que SCRUM, permettent de s adapter aux besoins évolutifs du client. Ces approches visent à établir un calendrier de livraisons fréquentes, que l on appelle «Sprint», d une portion entièrement fonctionnelle de la solution. De ce fait, les projets d intelligence d affaires s assurent de livrer une valeur réelle pour le client, dans le respect des délais et une maximisation du retour sur investissement (ROI). Comment? Nous verrons ceci plus en détail dans les sections subséquentes. Il est important de bien comprendre la notion de livrable fonctionnel. Par livrable fonctionnel, nous parlons d une fonction complète permettant de produire une valeur mesurable. En exemple concret : «Une information disponible à l'utilisateur, dont la qualité a été mesurée et dont l'accessibilité est rendue possible via un outil simple pour lequel l'utilisateur a eu une formation». Il est certain que le développement de ce descriptif fonctionnel inclus une multitude de tâches connexes dont : les spécifications fonctionnelles, la modélisation, l architecture, les traitements ETL et autres. Il est donc évident qu un sprint, qui dure généralement entre 4-6 semaines, se doit d être d une envergure réduite. D un autre côté, lorsque le résultat du sprint est livré, la valeur est réelle et le ROI en est mesurable.

5 Les sprints : une approche itérative L objectif principal d une approche itérative est de livrer rapidement de la valeur à l organisation en adressant un besoin d affaires spécifique, dans le délai le plus court possible, en minimisant l investissement requis. Par ce moyen, il est beaucoup plus simple de rivaliser contre les solutions décentralisées qui, comme nous le savons, apporteront à long terme, des coûts de maintenance et d évolution élevés. L approche Scrum est composée de trois types de «sprints» soit : le sprint d avant match, les sprints de développement et le sprint de fermeture.

6 Le sprint d avant match L objectif de cette période de travail est de rassembler toute information nécessaire au développement de la solution et de se préparer pour la livraison des fonctionnalités. Ce qui implique : 1. Une documentation exhaustive de la vision du client (qualifié comme «propriétaire du produit») capturé sous forme «d histoire utilisateur 1» 2. Le design de la solution sous forme d une représentation des flux de transformation des données ainsi que des modèles conceptuels et logiques des environnements d analyses 3. Le «découpage de la solution» à travers les cycles de livraison fréquents et selon la priorité d affaires 4. La définition de «complété 2», déterminée par le propriétaire du produit 5. L organisation du travail par les membres de l équipe et la durée des sprints de développement 6. L organisation des environnements de travail afin de minimiser les dépendances de l équipe sur d autres groupes dans l organisation. 1 Dans un contexte d intelligence d affaires, il est adéquat de catégoriser les histoires sous deux catégories: les histoires qui traitent des données (métriques et axes d analyses) et les histoires liées à la couche présentation, soit l interactivité des utilisateurs avec la solution 2 Par «complété», nous parlons ici de la vision du client par rapport à la définition de livrable fonctionnel complet

7 Les sprints de développement Au cours de ces sprints, l équipe travaille à la livraison de fonctionnalités spécifiques du produit. La durée moyenne d un sprint est de 4 à 6 semaines 3. Ceci implique qu à la fin de cette période, une tranche de solution entièrement fonctionnelle est livrée au client. Pour en arriver ainsi, il va de soi que l architecture de la solution développée se doit être assez flexible pour répondre à des demandes de changements sans engager des coûts de «rétro fit» trop élevés. Comme le sprint d avant match et le sprint de déploiement, les sprints de développement ont une structure précise. Celle-ci se décline en quatre phases: 1. La planification Au début d un cycle de développement, l équipe et le propriétaire du produit, confirment les fonctionnalités à livrer, déterminent les tâches nécessaires au développement et estiment les efforts requis. Cette planification peut prendre quelques jours et permet à l équipe de valider que le périmètre de livraison soit réalisable dans la période de temps prévue. 2. Le développement C est durant cette période que les membres de l équipe travaillent au développement des fonctionnalités de la solution. 3. Le déploiement Lorsque le développement est terminé, l équipe migre les nouvelles fonctionnalités dans un environnement similaire à celui de la production. 4. Rétrospective C est lors de cette rencontre que l équipe se rassemble pour discuter : a) De la dynamique de groupe en identifiant les points forts ainsi que les aspects à améliorer b) De la solution livrée. Celle-ci est revue en détail avec le propriétaire du produit. Les conclusions de cette séance de travail peuvent faire émerger d autres histoires utilisateurs qui seront priorisées par le propriétaire du produit. 3 Contrairement à la durée des sprints des projets de développement conventionnel, il est difficile dans les projets d intelligence d affaires de livrer de la valeur à l organisation en moins de 4 semaines.

8 Le sprint de fermeture Celui-ci se résume à deux parties : 1. Déploiement : le déploiement de la solution dans l environnement de production 2. Documentation : finaliser la documentation entreprise lors les sprints précédents : Contrairement aux sprints de développement où l emphase est mise sur le code et l échange avec le propriétaire du produit, c est pendant le sprint de fermeture que l équipe s emploie à documenter la solution. Dans cette section nous avons démontré que les changements de vision des clients constituent une réalité inhérente au développement d une solution en intelligence d affaires. En raison d une ségrégation des tâches et d une documentation plutôt lourde, l approche de développement en cascade ne constitue pas un moyen efficace pour adresser cette contrainte. À l opposé, Scrum offre la flexibilité requise par les utilisateurs en mettant de l avant des livraisons fréquentes d une portion entièrement fonctionnelle de la solution. Ceci est rendu possible grâce à la structure de livraison qui comporte 3 types de sprints (avant match, développement et fermeture) ainsi qu aux processus suivis tout au long des sprints (planification, développement/exécution, rétrospective). Nous avons aussi mis l emphase sur la collaboration entre le propriétaire de produit et l équipe de développement, chacun tourné vers la même cible. Par ailleurs, pour réaliser une approche de ce type, l équipe se doit d être engagée et motivée. L équipe est le moteur de réalisation La motivation de l équipe est importante dans la réalisation de tout type de projet et devient un impératif en intelligence d affaires. En effet, la complexité des liens fonctionnels entre les différentes composantes nécessite une forte collaboration entre les membres de l équipe. Maintenir la motivation continue des membres de l équipe est génératrice d une valeur sans équivoque. Le cadre de réalisation agile offre la possibilité à chacun des membres d avoir un apport réel au projet et d en apprécier le résultat rapidement grâce aux sprints de courte durée. Aussi, le fait d avoir une équipe autosuffisante ayant un lien direct avec le client (propriétaire de produit) crée une dynamique qui engendre créativité, productivité et efficacité. Cette dynamique est maintenue par le biais des rencontres de suivi quotidiennes, ou daily Scrum 4 qui favorisent le lien d appartenance à l équipe de réalisation et l engagement envers le projet. Un autre élément important suscitant la motivation de l équipe se retrouve dans la nécessité de multidisciplinarité des ressources. Tel que mentionné antérieurement, il est requis que chacun des membres puisse effectuer plusieurs types de tâche. Qu un analyste ait la capacité de produire les spécifications, de réaliser les essais intégrés et la mise en production en serait un bel exemple. La résultante est une équipe impliquée et compétente. Tout le monde y gagne! Le client, l équipe et l organisation. Jusqu à maintenant, nous avons discuté du cadre de gestion agile et des impacts sur l équipe qui mènent à des projets davantage alignés vers les besoins du client, le tout avec un coût de réalisation réduit. Voyons en dernier lieu l impact de l agilité sur le ROI. 4 Rencontres de 15 minutes ont lieu chaque jour et permettent aux membres de l équipe de réalisation d échanger sur leurs accomplissements, leurs enjeux et leur planification pour la journée.

9 La maximisation du retour sur investissement par l agilité Le retour sur investissement (ROI) peut sembler le plus difficile des indicateurs à calculer dans un projet en intelligence d affaires. Ceci dit, plusieurs techniques simples existent pour établir un seuil et mesurer le ROI d une solution BI. Dans le cadre du présent article, nous ne traiterons pas des méthodes permettant de mesurer ce ROI, mais bien des facteurs pouvant influencer positivement ou négativement ce dernier L approche en soi se veut simple, amener plus de valeur tout en minimisant les coûts des projets, ce qui implique très certainement une réduction dans les délais de réalisation. Dans un projet en mode cascade, les étapes telles que décrites précédemment sont simples et prévisibles. Certes, le cycle est rassurant et semble promettre une structure permettant de prévoir à l avance les coûts et les délais, mais il n en est rien. Comme vous l avez probablement déjà vécu, des situations surviennent qui ébranlent ce type d approche telles que : Les besoins du client changent alors que le plan de projet et les budgets sont approuvés Le budget est réduit avant que le projet ne soit terminé La solution prévue pour adresser une problématique particulière n est finalement pas réalisable, les estimations et le plan de projet doivent être révisés. Toutes ces situations impactent le budget, les délais et surtout l image de l équipe de projet qui s efforce de livrer avec des points de repère changeants. Sachant que ces situations sont souvent inévitables, le point n est pas d adresser ces problématiques par des plans de contingences, pour amortir le choc lorsqu elles se produiront, mais bien de changer l approche pour que ces situations aient le moins d impact possible, voir même aucun impact. De par les courtes phases de livraison de l approche agile, l envergure est inévitablement réduite tout comme les préalables. Rappelons aussi qu un sprint agile produit un livrable fonctionnel permettant de créer de la valeur tout au long du projet et non uniquement à la toute fin. Le ROI est donc quantifiable plus rapidement. Sprint 1 = Valeur Sprint 2 = Valeur+ Sprint 3 = Valeur++ Les autres bénéfices tangibles ayant un impact positif sur le ROI sont la diminution de la documentation et des efforts reliés aux réalignements de la solution. Révisons ces aspects plus en détail.

10 Diminuer le coût des spécifications fonctionnelles et de la documentation Quelle est la valeur réelle de la documentation liée aux livrables d un projet? Que l on parle de documentation opérationnelle, de guide de mise en production, de manuel utilisateur, de spécifications fonctionnelles, de webinaires ou toute autre forme de communication d information relative au projet, il est difficile d y attacher une valeur organisationnelle. Selon la méthode traditionnelle, plusieurs documents sont requis pour passer d une étape à la suivante et d un groupe de réalisation au suivant. Nous nous retrouvons donc avec beaucoup de documentation de «transition» à produire qui amène pourtant peu de valeur au client. Cette documentation ne sert en fait qu à supporter le processus de réalisation du livrable ainsi que les nombreux «hard hand-off». Dans la section précédente, nous avons parlé de documentation légère et efficace. De ce fait, partons des trois simples principes suivants du cadre agile: L équipe de développement a l expertise complète pour accomplir son livrable La documentation à livrer fait partie du sprint (phase de déploiement) Le client fait partie intégrante de l équipe de réalisation Sachant ceci, nous évitons d emblée la documentation de transition. L équipe de développement n a aucune valeur à produire ce type de documentation, car il n y a pas de transition, tout est réalisé à même l équipe. Elle n est requise que dans un cadre d exception pour lequel l expertise ou le rôle (exemple pour une mise en production) ne fait pas partie de l équipe. Suivant le deuxième principe que la documentation à livrer fait partie du sprint, nous ne livrons que ce qui est requis pour réaliser les fonctions planifiées pendant le sprint, incluant bien sûr les «histoires utilisateurs». Donc, aucune documentation globale que l on devra réajuster constamment, aucune spécification fonctionnelle pour des livrables «potentiels», etc. Nous incluons ici aussi les diagrammes d architecture (de solution et d entreprise) dans le sens où l architecture est partie intégrante de l équipe de développement et accomplira ses livrables requis pour le sprint. En intelligence d affaires, il est préférable de concevoir les diagrammes d architecture de haut niveau en sprint 0. Par la suite, nous les ferons évoluer au même rythme que la solution, au fil des sprints. Cela va sans dire que l on va ainsi à l encontre du fonctionnement de la plupart des groupes TI, affaires et d architecture. Malgré tout, ce changement de paradigme est nécessaire pour obtenir le gain souhaité. Ne pas oublier que le résultat sera le même. Seuls la séquence et le rythme diffèrent. Finalement, avec un client étroitement lié à l équipe de développement, les statuts de projets sont plus légers et la documentation de projet réduite.

11 La clé : s ajuster rapidement (fail fast, fix quickly) Que la cause soit TI ou affaires, il arrive parfois que la valeur escomptée ou que la fonctionnalité promise ne puisse être réalisée. L idée générale est de limiter les dégâts et de le faire le plus rapidement possible. Dans un cadre traditionnel, il est relativement difficile de constater les dégâts tôt, car les livrables ne prennent leur valeur qu une fois assemblés. Cet assemblage est souvent fait en fin de projet ou en fin de phase, quelques mois avant la mise en production. Dans un cadre agile, les assemblages sont faits plus fréquemment, soit à chaque sprint, permettant de prendre action dès lors. Prenez action et faites partie des agents de changement pour maximiser la valeur organisationnelle de vos projets d intelligence d affaires. Un autre élément favorisant l ajustement rapide est la notion de limitation de temps ou «time boxed». Tel que mentionné antérieurement, les sprints ont une durée limitée et celle-ci ne change jamais. Conséquemment, si le développement a été fait selon une hypothèse qui ne tient plus ou si un besoin a été mal compris avant le début des travaux, le maximum de temps «mal investi» est la durée du sprint. Les enjeux actuels des projets en intelligence d affaires ne sont pas propres au contexte, mais sont le résultat d un cadre de réalisation qui ne convient pas à ce type de projet. Comme nous en avons déjà discuté, que ce soit les changements fréquents des besoins des utilisateurs, la pression pour livrer plus rapidement à moindre coût ou la motivation de l équipe, la finalité n est en fait qu une maximisation pure et simple du retour sur investissement au sens propre du terme. Il est important de s assurer que l organisation profite le plus tôt possible des bénéfices engendrés par une solution d intelligence d affaires. Par ailleurs, la mise en place du cadre proposé ici, nécessite un changement organisationnel important qui se doit d engager tant l équipe de réalisation, le client utilisateur, le bureau de projet que les instances de gestion. Les bénéfices engendrés par ce changement organisationnel seront tout aussi importants que les efforts demandés pour y arriver, mais nous suggérons l implication d une équipe spécialisée sur le sujet qui pourra vous orienter vers l approche appropriée. Cette dernière saura également vous conseiller sur le séquencement des activités de changement et vous accompagner en effectuant le mentorat nécessaire auprès des ressources touchées par ce changement. Pour assurer une transition positive, la gestion du changement est importante, et ce, auprès de chacune des ressources impliquées.

12 Gestion de projets agile en BI Nous pouvons vous aider à améliorer le temps de livraison et l'arrimage de vos solutions d intelligence d affaires avec les besoins évolutifs de vos utilisateurs. Certifiés en agilité par une firme renommée, nos conseillers sauront vous accompagner dans une démarche visant l agilité et les résultats grâce à: Un cadre de gestion de projets «agile» éprouvé et adapté à l intelligence d affaires Des gestionnaires de projets certifiés SCRUM Master ayant dirigé plusieurs projets d envergure en utilisant une approche «agile» Une équipe de conseillers en intelligence d affaires actifs dans le monde de l agilité à l affût de l évolution de la pratique Des équipes de réalisation avec de l expérience concrète et une connaissance appliquée de l agilité CLIQUEZ ICI POUR PLANIFIER VOTRE DÉMO ET AMÉLIORER VOTRE BI Ou visitez: marketing.agiledss.com/fr/demo/project

13 Partagez ce livre blanc! Nous joindre À propos d agiledss agiledss est un «Centre d excellence en intelligence d affaires» combinant expertiseconseil, meilleures technologies et solutions innovatrices afin d accompagner nos clients vers un objectif de croissance et d évolution continue.