Selon une étude publiée en Juillet 2014 et menée conjointement par McKinsey et l’Université d’Oxford, les grands projets IT accusent en moyenne des dépassements de 66% % pour les budgets et de 33% pour les délais, sans parler du déficit de services fournis; d’autres sources donnent des statistiques encore plus pessimistes. Près de 17% des projets connaissent un destin si funeste qu’ils peuvent mettre en péril l’existence même de l’entreprise.
Les causes sont multiples (explosion des coûts de coordination, gestion du changement, silos, erreurs de casting…) mais la médiocrité des ‘cahiers de charges’ (Business Analysis) est toujours citée comme la principale source d’enlisement, depuis Barry Boehm (années 80 !) et corroborée très régulièrement par Gartner, Standish, IAG, PMI® ….. “Project managers in PMI’s 2014 Pulse of the Profession ® study said that poor Requirements Management is a major cause of project failure, second only to changing organization priorities… 37 percent of organizations report inaccurate requirements gathering as a primary reason for project failure”.
La qualité des analyses est incontestablement le meilleur levier de réussite des projets mais comment y parvenir ? Par une formation (*) dédiée aux business-analystes et à tous ceux qui sont impliqués dans cette démarche : sponsors, chefs de projets, system-analystes… rôles souvent confondus dans les PME.
Peut-on imaginer de construire un immeuble à partir d’une simple esquisse ? L’effet démultiplicateur des erreurs dans les spécifications est évident puisqu’elles vont, très logiquement, contaminer toute la chaîne de valeurs et entraîner une nouvelle rotation du ‘project lifecycle’, avec en prime des retards et des coûts additionnels. Ainsi que relevé par le groupe Gartner, il est paradoxal de constater la débauche de moyens consacrés à l’administration des projets alors que l’analyse reste un parent pauvre.
Le bêtisier des « Business Analysis »
• Absence de structure. Rédaction dans un style littéraire, lourd, ambigu, truffé d’adverbes, de phrases inutiles, de redondances, de contradictions…. exigeant une réécriture complète pour être traitée par les fournisseurs, avec le risque d’erreurs de transposition et des difficultés pour rapprocher ensuite l’expression des besoins et le descriptif de la solution. Autant de bombes à retardement.
• Exigences irréalistes, sans justificatifs économiques, ignorant les solutions déjà en place. On ne peut pas tout automatiser, ni tout contrôler car cela peut se payer très cher en développement, maintenance et exploitation.
• Exigences non-formulées. Des évidences pour les uns ne le sont pas pour les autres.
• Flou artistique dans les exigences non-fonctionnelles, ce qui laisse la place à de nombreuses erreurs d’interprétation et d’appréciation. A périmètre fonctionnel égal, les coûts de développement peuvent fortement varier selon le poids accordé à des spécificités telles que les contrôles, la capacité, les contraintes horaires, la performance, les sécurités, les interfaces, la disponibilité, l’adaptabilité, la traçabilité, les migrations…
• Vouloir ré-informatiser des processus malades, sans les avoir assainis préalablement, (Lean Six Sigma) en supprimant les éléments toxiques.
• Absence de complémentarité entre les référentiels, ce qui posera des problèmes lorsque par exemple un chef de projet devra structurer un projet en repartant des analyses.
• La démarche d’analyse est souvent abordée de manière empirique et assurée, soit par le ‘client’, soit par un analyste qui découvre le domaine à informatiser : dilemme entre fond (exhaustivité) et forme (structure, lisibilité).
Heureusement cette activité tend à se professionnaliser sous l’égide notamment de l’IIBA (créée en 2003 au Canada) et de l’IQBBA ; on ne peut que s’en féliciter vu les enjeux et la somme de compétences requises : analytiques, communicationnelles, managériales et … même « commerciales ». Il reste néanmoins du chemin pour développer de réelles ‘méthodes’. Le BABOK® de l’IIBA est avant tout une boîte à outils, une check-list sans être réellement une méthode et d’aucuns lui reprochent une relative lourdeur rédactionnelle ou un manque de maturité et complémentarité par rapport aux méthodes de gestion de projets (PMBOK®, PRINCE2®…). Se méfier des modes, traductions, du jargon et des guerres de religion : « In 2013 there were preliminary discussions between IIBA and PMI based on a proposal put forward by PMI…. After several meetings, it became clear that IIBA and PMI did not share the same vision. After some discussion between PMI and IIBA, the IIBA Board determined that the proposal was not in the best interests of our members »…
Pourquoi ne pas profiter d’une lecture illimitée de UP’ ? Abonnez-vous à partir de 1.90 € par semaine.
Business Analysis : les fondamentaux
La BA doit permettre une parfaite compréhension des objectifs et contraintes et restituer l’expression des besoins, fonctionnels et non-fonctionnels, sans nécessairement proposer d’emblée des solutions. Elle doit servir de socles et de trames pour les processus suivants :
• Analyses techniques et fonctionnelles.
• Design de la solution.
• Plan de tests.
• Procédures, ‘job descriptions’, organisation, formations.
• Chiffrage des charges et budgétisation.
• Modélisation et construction du système d’informations.
• Fixation des priorités, les arbitrages.
• Pilotage du projet : phasage (WBS) et casting (‘stakeholders’).
Le mot ‘trame’ implique une homogénéité sémantique et structurelle : tous les documents produits à partir de la BA doivent impérativement en respecter la structure et le vocabulaire, ceci pour faciliter les tâches d’interprétation, de structuration et de validation. Pour éviter de périlleuses réécritures, il faut assurer la plus grande symétrie possible entre le design de la solution et l’expression des besoins, encore faut-il que ces derniers soient rédigés dans les formes requises. Un recueil de spécifications doit également fournir un maximum d’éléments permettant d’optimiser les processus subordonnés, en précisant notamment: les objectifs stratégiques, les intervenants, les contraintes, le périmètre opérationnel, les règles du jeu. La qualité des analyses est un gage de qualité et une arme antivieillissement des logiciels.
Rôle et profil du Business Analyste (*)
Sherlock Holmes, Bill Gates, Descartes, Boileau,…
Un métier qui se détermine et qui porte essentiellement sur l’analyse et la formalisation de demandes d’amélioration de solutions informatiques ou organisationnelles, en proposant un schéma de mise en place.
Un rôle critique, exigeant une grande polyvalence et qui peut être appelé à intervenir de manière macro- ou microscopique, parfois dans un cadre de responsabilités élargi. Portrait-robot :
• Un … Analyste (!) apte à formaliser les besoins et évaluer la ‘maturité (*) des processus concernés, afin de proposer éventuellement un re-engineering. Sachant dissocier les besoins fonctionnels, techniques, légaux, sécuritaires, opérationnels…
• Esprit de synthèse: capacité d’agrégation et modélisation : cartographie des processus, les ‘règles de gestion’.
• Compréhension du métier à traiter: les experts s’attendent à rencontrer des interlocuteurs sachant aller au-devant de leurs préoccupations.
• Talent de détective. Un homme curieux, méfiant, sachant identifier les personnes clé et les ‘faire parler’, si nécessaire en animant des ateliers (Kaizen) offrant des garanties supplémentaires sur le plan de l’exhaustivité, de la cohérence et de l’objectivité… qui peuvent encore être renforcées par croisement avec d’autres sources ou des mesures statistiques.
• Bon communicant, en s’appuyant sur un ‘plan’, que ce soit sur le mode vocal, écrit ou dans un rôle d’animateur. Il doit être à même d’interagir avec la plupart des intervenants: sponsor, chef de projets, experts, fournisseur de la solution …
• Polyvalence. L’analyste doit accompagner le projet tout-au-long de son cycle de vie et intervenir pour préciser, arbitrer… ou adapter les spécifications à des changements intervenants après validation des cahiers de charges. Le monde bouge.
• Pédagogue, sachant (faire) respecter une méthodologie ou un référentiel compatible avec les autres méthodes utilisées, en amont ou en aval de la démarche.
• Facilitateur & Arbitre & Filtre. Les attentes des utilisateurs sont parfois futuristes : il y a lieu d’en apprécier la faisabilité et parfois les éliminer d’emblée afin de ne pas polluer le débat décisionnel.
• Architecte. Même si ce n’est pas sa vocation première, la BA doit proposer une vision conceptuelle de la solution attendue et il est évidemment nécessaire de dégager un consensus sur son contour: un prototype est souvent d’une grande aide.
La Tour de Babel des normes, référentiels et méthodes
Un foisonnement de normes, méthodes, référentiels, plus ou moins matures, certaines en déshérence ou portées par la CEE, les USA, le Canada, la Suisse, la Grande Bretagne… Une « Tour de Babel » soulevant la question de la stabilité, pérennité et interopérabilité entre ces différents outils.
• Des normes structurantes pour cadrer les services : CMMI, ITIL®, COBIT, ISO 20000 / 27000 – 38500 – 9001, IT-CMF, P3O
• Des techniques de modélisation. UML, ArchiMate, TOGAF, Merise.
• Des méthodes et normes de gestion de projet : PRINCE2®, PMBOK (PMI), ICB, ISO 21500, P3M3, Scrum, HERMES.
• Un référentiel de pilotage de la « Business Analysis » : BABOK développé par l’IIBA.
• Des méthodes de reengineering de processus : Lean / Six Sigma…
Ce classement est un peu arbitraire et porte sur les caractéristiques principales : il existe des zones de recouvrement, parfois sources de confusion et de frictions et, heureusement, pour certaines, des passerelles, gages d’interopérabilité et d’évolutions professionnelles. A titre d’exemple, le PMI annonce pour 2015, une extension du PMBOK traitant spécifiquement de la BA. Scrum se présente comme une méthode « agile » couvrant en même temps l’analyse, le développement et la gestion de projets, approche présentée comme plus souple et peut-être adaptée au traitement d’objectifs tactiques, mais avec une gestion improbable des coûts, délais et qualité du produit fini.
Les normes font l’objet de luttes d’influence entre les organes de certification agissant au niveau national, européen ou international. Ces luttes sont fondées sur des enjeux économiques et malheureusement elles sont un frein à l’émergence de la norme ‘dominante’. « In 2013 there were preliminary discussions between IIBA and PMI based on a proposal put forward by PMI…After several meetings, it became clear that IIBA and PMI did not share the same vision. After some discussion between PMI and IIBA, the IIBA Board determined that the proposal was not in the best interests of our members »…
Pour nombre d’entreprises et d’individus, le déploiement de ces méthodes a pour principal objectif l’obtention d’une certification, d’un label de qualité ouvrant l’accès à un marché.
Pour lutter contre la désinformation et privilégier les analyses qui décryptent l’actualité, rejoignez le cercle des lecteurs abonnés de UP’
Recommandations à la formation des Analystes
La compétence des Analystes est un très fort levier de performance stratégique ; cette compétence repose principalement sur deux piliers : expertise métier et maîtrise d’une méthode d’analyse. En respectant les principes suivants :
• Maintenir un focus permanent sur les objectifs business.
• L’expression des besoins doit proposer une première découpe du projet, établie selon des critères de cohérence et de rentabilité, en évitant le piège des projets pharaoniques, dangereux si l’entreprise ne possède pas la maturité requise.
• « Haste is no speed ». Il est peut-être urgent d’attendre. Le choix des méthodes et référentiels est capital et demande une réflexion approfondie pour en garantir le ROI et la pérennité dans la recherche de l’amélioration continue. Il s’agit également d’éviter de créer des silos en rendant certains départements prisonniers de leur excellence.
• La loi de Pareto (le 80/20) s’applique également dans ce domaine. Eviter de choisir une méthode surdimensionnée et ne jamais oublier qu’un référentiel qui n’est pas entretenu, meurt.
• Les compétences ‘métier’ peuvent être apportées par le cursus scolaire, une expérience opérationnelle, un stage… « Learning by doing ».
• Tout expert est susceptible de devoir produire des analyses et dans bien des cas, la courbe d’apprentissage est plus courte des métiers vers la BA que dans le sens inverse. La complexification croissante des processus, la pression du temps et des coûts plaident également pour des formations accélérées : il est généralement plus facile de ‘convertir’ un expert métier en Analyste que l’inverse.
Bernard Timmermans
(*) Ces sujets font l’objet de prestations de conseils et formations assurées par la Sàrl strategic-pilot.com. Une nouvelle formation BA disponible Q4/2014. Réactions et questions: info[at]strategic-pilot.com à l’attention de Bernard Timmermans
