AMOA : traduire votre besoin en exigences, et choisir la bonne solution

Dans quelles situations une AMOA est-elle utile ?

Une entreprise fait appel à une AMOA lorsqu’elle s’apprête à engager de l’argent sur une solution informatique et qu’elle veut décider sur des éléments comparables plutôt que sur une proposition reçue. Plusieurs situations y conduisent.

Un schéma directeur qui débouche sur des investissements. L’état des lieux est fait, la trajectoire est posée : il faut maintenant savoir ce que le marché propose, à quel niveau de service et à quel coût, avant d’engager quoi que ce soit.

– Le renouvellement d’une brique majeure du SI. Un cœur de réseau, une plateforme collaborative, une application structurante : plusieurs fournisseurs sont en jeu, les périmètres se recouvrent et les offres arrivent construites sur des bases différentes.

– Un nouveau bâtiment ou un nouveau site à équiper. Le volet informatique se décide en même temps que le reste du projet, avec des délais qui ne se rattrapent pas et des choix difficiles à revenir en arrière une fois les travaux lancés.

– Une équipe interne compétente mais sans le temps. Les métiers et l’IT savent ce dont ils ont besoin ; personne n’a les semaines nécessaires pour l’écrire, consulter le marché et dépouiller les réponses en plus du quotidien.

– Une proposition de fournisseur que personne ne peut challenger. Le prestataire en place propose une solution. Elle est peut-être la bonne mais l’entreprise n’a pas les moyens de le vérifier, ni de savoir ce qu’elle aurait obtenu ailleurs.

Quand confier la direction d'un projet à l'extérieur ?

Plusieurs situations peuvent conduire une PME à faire diriger un projet informatique par un intervenant externe.

– Un projet structurant arrive, sans pilote disponible en interne. Une migration, un renouvellement d’infrastructure ou le déploiement d’un outil métier tombe au moment où l’équipe informatique tient déjà l’exploitation quotidienne.

– Le projet a commencé et il dérive. Les jalons reculent, le périmètre s’élargit, le budget se tend, et les décisions attendent.

– Plusieurs prestataires interviennent sur le même projet. Chacun livre sa partie ; personne ne tient l’ensemble, ni les interfaces entre les lots, ni le calendrier commun.

– Le sujet est technique, l’enjeu est métier. L’informatique d’un nouveau bâtiment, la refonte d’un intranet qualité ou un projet d’archivage engagent l’organisation autant que le système d’information.

– La Direction a validé l’investissement et n’a pas de visibilité sur l’avancement réel. Les points de situation sont techniques, les écarts se découvrent tard.

Des exemples de missions d’AMOA

Ces exemples illustrent le rôle de l’AMOA en amont de la décision : formaliser le besoin et préparer un choix sur des bases comparables. Selon le projet, l’AMOA se poursuit ensuite pendant la conception, la recette fonctionnelle et l’accompagnement du changement.

– Une consultation du marché dans le cadre d’un schéma directeur (RFI). Le champ est ouvert : l’objectif est d’identifier les acteurs et les solutions qui existent, de comprendre les modèles et les ordres de grandeur, et de restreindre le champ avant d’écrire un appel d’offres.

– Un appel d’offres réseau (RFP). Le besoin est arrêté : exigences techniques et de service, cadre de réponse imposé, comparaison des offres, éclairage de la décision.

– Le choix d’une plateforme collaborative. Formalisation des usages attendus, des exigences de gestion documentaire et des contraintes existantes, puis consultation sur cette base.

– Le volet informatique d’un nouveau bâtiment. Traduction des besoins d’exploitation en exigences, consultation des fournisseurs concernés et arbitrages posés au bon moment dans le calendrier de construction.

 

Ce que l'AMOA change pour votre entreprise

Cinq effets concrets d’un besoin formalisé avant d’aller sur le marché.

Les exigences sont construites à partir de ce que font vos équipes et de ce qu’elles doivent obtenir, puis validées par elles. Le marché répond ensuite à votre besoin, dans vos termes, et non à la lecture qu’un fournisseur en a faite.

Un cadre de réponse imposé oblige les candidats à chiffrer le même périmètre, à traiter les mêmes hypothèses et à exposer leurs coûts récurrents de la même manière. Sans ce cadre, l’écart entre deux propositions renseigne plus sur leur rédaction commerciale que sur leur contenu.

Dépendances, réversibilité, engagements de service, responsabilités en cas de défaillance, prérequis d’infrastructure, charge à prévoir côté interne : ces points se traitent pendant la consultation, tant qu’ils sont encore négociables.

Vos équipes restent sur ce que personne ne peut faire à leur place, exprimer le besoin, arbitrer, valider. La rédaction, la relation avec les candidats, le dépouillement et l’animation des séances sont pris en charge.

Certaines équipes ont besoin d’un accompagnement continu ; d’autres d’une expertise sur un point précis, à un moment précis. Le niveau d’intervention se définit avec vous au cadrage et n’a pas à être le même du début à la fin.

Vos interlocuteurs

Cyril Chapon fondateur de Lunova, ancien Directeur IT Europe, près de vingt ans d’expérience dans les systèmes d’information et leur transformation. Il conduit lui-même les missions et mobilise, selon les sujets, un réseau d’expertises spécialisées.

Besoin d’échanger ?

Un doute sur votre système d’information, un projet à arbitrer, un départ à anticiper ? 

Trente minutes suffisent pour savoir s’il y a matière à aller plus loin.