Notre métier

La Business Analyse ou AMOA est un métier à part entière :

La rédaction de livrables clairs, concis, univoques, compréhensibles de tous et conformes aux besoins réels des utilisateurs ne s’improvise pas. Exigences, items de backlog… ces livrables nécessitent une véritable expertise en Business Analyse.

Les connaissances fonctionnelles et/ou techniques des Systèmes d’informations sont insuffisantes pour fiabiliser les projets.

Il est donc important d’être doté d’un savoir-faire permettant :

d’industrialiser les phases de conception

de cadrer un projet jusqu’à son terme

de s’adapter à tous les environnements projets, en cycle en V comme en agile grâce à nos consultants Scrum Master et Product Owner

de mener les projets en respectant les bonnes pratiques CMMi.

→ 80 % de la réussite d’un projet se joue lors des phases d’analyse et de conception.

D’après le rapport « CHAOS » (2015) du Standish Group :

19 % des projets informatiques sont abandonnés ;
52 % des projets informatiques sont à la dérive.

Concernant l’origine des erreurs :

56 % apparaissent dès l’expression des besoins ;
27 % en conception.
Par ailleurs, 82 % du surcoût d’un projet découle des erreurs des livrables d’expression de besoins.

Nous mettons systématiquement en place les métriques permettant de piloter de manière quantifiée toutes les phases d’un projet. Ces métriques facilitent le cadrage des projets, contribuent à respecter les délais et fournissent des indicateurs objectifs de performance permettant de s’améliorer et de mesurer les progrès effectués. Nous appliquons notre savoir-faire pour réaliser les prestations suivantes :

– études d’opportunités, expressions des besoins, cahiers des charges, spécifications fonctionnelles générales et détaillées, progiciel, recette ;
– chef de projet, directeur de projet, PMO sur tout le cycle de vie d’un projet ;
– méthodologie, urbanisme, processus métier, schémas directeurs ;
– projet en cycle en V ou en mode agile.
Parce que les phases amont contribuent à plus de 80% dans la réussite d’un projet, nous les renforçons de manière significative en produisant des livrables de haute qualité grâce à l’approche industrielle de l’ingénierie des exigences. Nous contribuons ainsi à sécuriser tous les processus clés : développement, recette, pilotage, etc.

Alors que le ROI de l’effort fait dans la rectification des problèmes est beaucoup plus élevé en phases amont (EB, CDC, SFD) que lorsqu’il est réalisé en phases aval (tests, recette et maintenance), ce sont pourtant ces dernières qui sont le plus industrialisées tandis que l’effort qualitatif fait sur les phases amont reste négligeable. Pourtant, plus une erreur est détectée tardivement, plus sa correction est coûteuse.

En résultat, les applications livrées ne répondent aux besoins des utilisateurs qu’après de laborieuses phases de rectification et ne donnent qu’une satisfaction partielle aux utilisateurs et commanditaires (sources 01 DSI et Standish Group) :

– 70 % des projets accusent des retards significatifs ;
– 50 % des projets connaissent des dépassements budgétaires supérieurs à 50 % ;
– seuls 16 % des projets sont considérés comme des succès.

Depuis sa création, Telys s’inscrit dans une démarche d’amélioration continue. Pour cela, elle met à profit les connaissances et les compétences de ses consultants, développeurs ou docteurs en informatique, linguistique informatique ou encore lettres modernes, pour mener des activités de R&D (Recherche et Développement) autour d’axes tels que la lisibilité, la cohérence des documents et la sémantique.

Plus de 50 % de nos consultants œuvrent chez nos clients dans des contextes agiles (Scrum, XP, Kanban, etc.). Forts de cette expérience nous sommes régulièrement consultés pour optimiser les pratiques agiles afin d’éviter les écueils récurrents rencontrés lors de leurs mises en œuvre :

– Taux de rework important : nombreux sont les projets agiles confrontés à des taux de rework importants : une partie significative de ce qui est réalisé lors d’un sprint est défait ou fortement modifié durant l’itération suivante. Il va de soi que contrairement à un projet en cycle en V classique le préjudice est moins tardif mais reste persistant, entraînant au final un surcoût pour le système et un rallongement des délais.
– Baisse progressive de la performance dans le temps : un autre problème qui apparaît également de manière fréquente est qu’au fil du temps la performance des équipes se dégrade. Tout d’abord, la vélocité baisse, on produit moins de points de complexité ou de story points. L’effort d’analyse devient de plus en plus important pour réaliser un sprint du fait qu’il n’existe aucune documentation consolidée du système en l’état actuel (les user stories et backlog ne traduisant que des différences ou incréments entre chaque itération, les impacts des nouvelles versions sont de moins en moins maîtrisés).
– Non-visibilité : nous avons également observé plusieurs projets menés en agile avec une non-visibilité sur la cible finale, tant en matière de délais que de coûts. Ainsi, par exemple, sur un projet mené en agile depuis 1 an et demi, la direction générale n’ayant pas de visibilité a commandité un audit qui a mis en évidence que seul 10 % du système final avait été construit après avoir dépensé près de 5 000 jh.

Pour chacune de ces problématiques nous avons identifié les causes, à savoir les pratiques contre-productives dans les contextes agiles. Ceci nous permet d’apporter une plus-value significative en sécurisant les projets.