Le juste cahier des charges

Discussions sur la conduite d'un déploiement, l'accompagnement du changement, les formations, le coaching. Tout ce qui concerne le projet
#1

Le juste cahier des charges

Messagepar franck_29 » 11 Août 2015, 14:25

Voilà c'est fait,
vous avez visité quelques collègues au sein d'autres entreprises, vous avez parlé autour de l'apport d'une gestion de courrier ou tout simplement de la mise en oeuvre d'une GED, et la décision est prise, votre organisation va passer à l'acte. vous allez vous équiper, enfin.

Que vous sachiez quelle solution vous allez retenir, ou que vous vous en remettiez au marché, vous allez devoir passer un contrat pour acquérir votre solution, ou plutôt, pour que la solution soit mise en place à votre profit, et, selon vos besoins, le contrat peut être plus ou moins complexe (ben oui, on n'achète pas word ou excel)

Que vous soyez dans une organisation publique ou dans le secteur privé, vous allez devoir rédiger un cahier des charges.
C'est une étape essentielle et décisive de votre projet, un cahier des charges bien "ficelé" peut engendrer la réussite de votre projet, en revanche, s'il est peu clair ou sujet à interprétation, si vous avez "oublié" quelque chose, l'insuccès n'est certes pas garanti, mais à tout le moins vous perdrez du temps, et le temps c'est ...

Cet article s'adresse aux chefs de projet de maîtrise d'ouvrage, responsables conduire le projet de mise à disposition d'un système de GED pour leur organisation. Son 'objet est de lister quelques uns des chapitres possibles de votre cahier des charges (les entités soumises au code des marchés publics liront "CCTP", le cahier des clauses techniques particulières). Mais encore une fois, selon votre besoin, certains n'auront pas à en faire partie.

Image

  • Les exigences fonctionnelles

    C'est dans ce chapitre, pour ceux qui ne savent pas vraiment quel outil retenir, ou qui veulent ne pas passer à côté de la pépite toute récente disponible par le marché, que l'on va trouver ce que doit faire le système que vous voulez accueillir. Vous allez y mettre également l'ensemble de vos spécificités, celles qui sont susceptibles d'engendre des paramétrages, voire des développements spécifiques qui ne font pas partie, en standard, du produit que vous allez acquérir.
    Il suffit de les mentionner avec précision et détail, en n'omettant jamais les éléments qui pourraient engendrer des coûts et des imprévus pour le futur titulaire de votre contrat.
    C'est certes plus facile à dire qu'à faire, mais vous devez au moins avoir une idée de ce qui est important à cet égard.

    Ce chapitre doit normalement refléter intégralement le fruit des échanges que vous avez eus avec vos utilisateurs, votre vision complémentaire du besoin à traiter, et la vision plus globale des autorités de votre organisations.

  • La maintenance ou TMA (tierce maintenance applicative)

    Dans ce chapitre figure ce que l'on met derrière le vocable "maintenance", c'est à dire :
    • la TMA corrective : l'abonnement aux mises à jours, les corrections de bugs (si vous prévoyez quelques choses de plus que les mises à jour officielles à ce sujet
    • la TMA évolutive : ici, on va prévoir que les besoins fonctionnels peuvent évoluer en cours de projet, de nouvelles fonctions impérieuses devenir indispensables,

    Au delà d'avoir lister ces deux sous-chapitres (il peut y en avoir d'autres), il faut décrire le "comment vous voulez que ça se passe" en cours d'éxécution de votre contrat. Vous êtes sensibles aux délais précisez les. Les fournitures (livrables) du titulaire doivent respecter des exigences particulières? dites les également. Vous voulez une procédure d'escalade, dites le.

  • La définition de la juste architecture technique

    Voilà un chapitre qui dépendra assurément de la taille de votre organisation, de son implantation géographique (au sens que vous avez des sites distants du siège, reliés par des réseaux qui n'offrent pas les caractéristiques d'un réseau local), et aussi parfois de son organisation (mode de fonctionnement).
    Dans ces cas précis, il ne suffira peut être pas de mettre un gros serveur sur lequel installer la belle Elise. Du coup, il faut étudier, réfléchir à la meilleure architecture technique du système et préparer l'arrivée du dispositif.
    Cela représente de la charge, et des coûts qu'il faut absolument anticiper, sous peine, à l'issue du projet de regretter amèrement des performances en deçà de que vous escomptiez, ou inapte à satisfaire le légitime besoin de vos usagers de disposer d'un système performant et fluide.
    C'est bien souvent au niveau de l'architecture technique que cela se joue
    .

    Et c'est donc dans ce chapitre que vous porterez vos exigences de performance, de disponibilité, vos contraintes en terme de site distant ou susceptible de créer des difficultés. Ces exigences et contraintes doivent être prises en compte par le titulaire afin qu'il puisse vous proposer la meilleure architecture technique possible.
    De deux choses l'une, soit vous savez les exprimer complètement dans le cahier des charges (dans ce chapitre) et c'est parfait, l'offre que vous recevrez chiffrera cet aspect. Soit cela vous est impossible et vous pensez qu'une étude "sur site" est nécessaire, alors prévoyez là, mais prévoyez aussi les livrables que vous attendez (vous devrez obtenir à minima un dossier d'architecture technique) décrivant l'architecture à mettre en place pour votre système.

    C'est également, pourquoi pas, le lieu de spécifier le nombre licences qui vous seront nécessaires, prévoyez de les acquérir par tranche si votre projet s'étale sur la durée avec des entités à faire rallier progressivement.

  • La reprise de données de vos anciens systèmes

    Là encore c'est selon votre environnement, selon le parc de document que vous avez décidé de reprendre. Dans certains cas, vous souhaiterez ne pas reprendre les données de votre ancien système, dans d'autres cela sera considéré comme un préalable à l'ouverture du nouveau service. dans ce cas d'espèce, vous vous poserez les questions soulevée dans l'article Mise en oeuvre d'une GED : Les gradients de valeur.

    Quoi qu'il en soit, selon le système source (vous pouvez aussi en avoir plusieurs) vous allez devoir décrire la structure des documents à reprendre (et surtout l'ensemble de leurs métadonnées associées) et leur volume. Le fait de disposer d'une capacité d'export à plat des données du système à reprendre est un gage de simplicité (et donc de coût moindre). Bref il vous faudra décrire tout cela le plus finement possible de façon à permettre au titulaire de chiffrer forfaitairement cette prestation de reprise des données.

    Si cela vous est impossible (et il y a un tas de raisons fort légitimes pour lesquelles cela pourrait effectivement être impossible, secret, décision non encore prise, volonté d'avancer indépendamment de cette problématique, etc...) vous pourrez toujours invoquer le mode de fonctionnement prévu dans le chapitre TMA Maintenance évolutive (car convenons en, une reprise des données peut consister dans le développement d'un module d'import, qui de facto représentera une évolution du système)

  • La tierce maintenance d'exploitation (TME)

    L'exploitation d'un système informatique c'est "l'activité qui consiste à maintenir opérationnel de manière stable, sûre et sécurisée un système dans un environnement de développement, de qualification, de formation, ou de production, dans ses parties matérielles et logicielles". (source wikipedia). On va donc retrouver dans ce chapitre, et pour peu que vous ayez à l'externaliser, tout ce qui concerne ces activités pour votre système de GED. A minima, la mise en oeuvre des sauvegardes, la surveillance du système, l'application de patch de sécurité ou autre, feront partie des spécifications de ce chapitre TME.

    Bien souvent, ces aspects seront pris en compte par votre équipe de soutien informatique, dans ce cas, il faudra penser à leur dispenser la formation nécessaire à l'accomplissement de la fonction TME, et donc, la prévoir dans le contrat (cf. "Les formations à l'outil Elise", plus bas)

    Il est enfin possible que la TME soit complètement masquée dans le cas où vous souscririez une offre SAAS.

  • Assistance au paramétrage et à la configuration

    Vous le verrez, Elise est un système hautement paramétrable, et il sait s'adapter à des situations, des cas d'usages et des contraintes plutôt variées. Vous entendrez d'ailleurs souvent vos correspondants côté éditeur, vous dire "oui c'est possible, c'est du paramétrage".
    En l'essence c'est une excellente nouvelle, pas de développement spécifique à consentir mais un simple paramétrage.

    Il est nécessaire, surtout dans les débuts de votre projet, de disposer d'une "capacité" d'assistance à la réalisation et à la mise à jour de vos paramétrages. Celle-ci peut s'obtenir par "formation" (cf. chapitre formation plus bas) ou par sous-traitance.
    Dans ce dernier cas, sachez juste que c'est "un métier" que d'assurer ce paramétrage, ne l'oubliez pas.

  • La TRA, ou encore la tierce recette applicative

    Ce chapitre ne sera pas souvent utilisé, mais externaliser une partie de l'activité de la "recette" est possible. C'est applicable à la recette du produit Elise lui même, mais également et surtout, si vous avez consenti des développements ou des paramétrages spécifiques, et que vous ne disposez pas des ressources (humaines) suffisante pour procéder à la qualification de la solution dans le délai qui vous était imparti.

    Dans la plupart des cas vous réaliserez vous même, avec vos utilisateurs choisis, ces activités.

  • Les formations à l'outil Elise

    Elise est un outil puissant, et donc, pouvant représenter une certaine complexité à l'usage. De toute façon, il est clairement hors de question de laisser vos utilisateurs sans la moindre formation ou coaching, à l'usage de l'outil.

    Les cas d'usage d'Elise sont variés, les types de formation qui peuvent vous être nécessaire le sont donc également. les types de formation les plus usuels sont les classiques :
    • Formation utilisateur (plusieurs cas en fonction des profils fonctionnel de vos utilisateurs)
    • Formation à l'administration fonctionnelle (il faudrait faire un article sur l'administration fonctionnelle d'Elise)
    • Formation à l'administration technique (Je n'aime pas ce vocable passe partout et peu clair, mais je n'en trouve pas d'autre)
    Mais, selon la complexité de votre organisation il peut être intéressant de penser à des formations en mode "coaching" (très prisé des grands chefs ;))

    Vous noterez que ce formations ne concernent que l'outillage, en réalité, il est important (il y va de l'adhésion au projet) de procurer à l'ensemble de vos acteurs un véritable accompagnement au changement (cf. chapitre ci-dessous) et de simples formations à l'outil ne peuvent en tenir lieu

  • L'accompagnement du changement

    C'est le complément du chapitre "formation". Il va consister essentiellement à préparer vos acteurs, à leur expliquer et leur donner hâte et envie d'utiliser au mieux l'outil Elise.
    Là encore le message à faire passer est différents selon les acteurs, et leur rôle au sein du groupe.

    Vous prévoirez des séances de communication (qu'il est nécessaire de préparer), vos acteurs vous poseront des questions très précises par rapport à leur propres préoccupations, il faut y répondre dans le cadre de ces séances. Bien souvent d'ailleurs elles seront plutôt ciblées organisation et fonctionnement, qu'outillage.
    Il est important de prévoir ces communications très tôt dans le déroulé du projet, afin d'éviter le syndrome du "quelque chose se trame dans mon dos" et la méfiance comme posture a priori.

    Prévoyez aussi de construire de toute pièce, avec votre titulaire, des sessions de communication (formation, accompagnement, ...) spécifiques à votre propre cas de figure. N'hésitez pas, c'est bien souvent sur cet aspect des choses que se joue l'adhésion à votre projet.
    Il est certes important que les acteurs comprennent ce qu'on attend d'eux, mais surtout il est vital qu'ils perçoivent ce qu'ils vont gagner. Et d'expérience, la mise en place d'un tel système est de nature à faire gagner nombre d'acteurs.

    L’accompagnement ne se limite pas à "l'avant mise en place", c'est une opération qui doit s’installer sur la durée. Certains prévoient des enquêtes de satisfaction pour mesurer (et ensuite l'améliorer) le degré de satisfaction de leurs utilisateurs. Le support à l'utilisation est lui aussi très impactant sur l'adhésion de vos acteurs, surtout dans les phases de lancement (voire chapitre ci-après)

  • Le support à l'utilisateur

    Une fois le système en place, tout commence. Il est essentiel que vos utilisateurs aient quelqu'un vers qui se retourner en cas de souci, de dysfonctionnement ou tout simplement d'incompréhension.
    Au titre de ce chapitre vous pourrez spécifier l'assistance que vous compter mettre à disposition de vos utilisateurs.
    Cela peut être une adresse de messagerie, un numéro de téléphone à appeler auquel une personne compétente répondra.

    Vous devrez y faire figurer des clauses de disponibilité, et préférentiellement vous préciserez le nombre d'appels mensuel que devrait traiter le support. Cela n'est pas toujours facile à estimer mais ces métriques ont une incidence directe sur le coût de la prestation de support, alors il conviendra de viser juste.

    N'hésitez pas à prévoir également une forme de suivi de ladite prestation afin d'en améliorer la qualité, n'oubliez pas que ce support sera en première ligne vis à vis de vos utilisateurs et qu'il détiendra à terme la "vraie" connaissance du ressenti de l'utilisateur vis à vis de l'outil. Il est très important d'attacher une grande importance à la qualité de ce support.

  • L'assistance au déploiement

    Dans une grande organisation ou complexe (lire plusieurs milliers d'acteurs à terme) le mode de déploiement "big bang" devient difficilement envisageable, alors la question se pose du déploiement du service. Comment procéder : Par entité? par zone géographique? une fois cette stratégie de déploiement décidée, comment initier le déploiement, comment en déléguer certaines parties, comment le cadencer, comment détecter au plus tôt et corriger les dérives éventuelles.
    Tout cela représente une activité très consommatrice de temps et d'énergie, pour laquelle il peut être nécessaire de se faire seconder.

    Vous en spécifierez les attendus (livrables délais) dans ce chapitre.

Le mot de la fin

Nous voilà rendus à la fin de cet article "fleuve", j'ai sans doute omis des chapitres importants (faites nous en part en réponse à cet article).

Ce qu'il faut retenir c'est que chaque cas est particulier, cet article ne prétend aucunement dresser la structure du cahier des charges parfait. Au contraire, il pourra vous être utile, le moment venu, dans la seule optique d'y piocher les quelques éléments que vous estimerez nécessaire.

Il faut également préciser qu'un seul titulaire, sauf cas rare, ne sera pas en mesure d'adresser l'ensemble des classes d'exigences listées ci-dessus. Par exemple l'assistance du déploiement n'est sans doute pas de ressort de l'éditeur du progiciel. La formation et l'accompagnement du changement peuvent également être traités par des candidats différents. la TRA quant à elle, pour des raisons d'indépendance ne peut être prise en compte par l'éditeur.

Merci encore de m'avoir lu jusqu'ici, j'espère que ce partage vous sera utile ;)

à très bientôt.

--
Crédit illustration : http://www.acitechnology.eu/
Pour bien débuter sur le forum : la charte, FAQ, Comment faire ?
Les points essentiels en quelques clics : Notre Blog
Président du club des utilisateurs d'Elise, administrateur de la communauté "Lettre à Elise"
Ancien directeur d'un projet visant à déployer Elise dans une grande organisation
.
Avatar de l’utilisateur
franck_29
Administrateur
Administrateur
 
Message(s) : 246
Inscription : 01 Juin 2015, 13:43
Localisation : France, Paris, Cléder

Retour vers Le projet, le déploiement, l'accompagnement, article de fonds

Qui est en ligne ?

Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 1 invité

cron