Centre national de la recherche scientifique Direction des systmes d'information

REFERENTIEL QUALITE

Procdure Qualit

Dveloppement d'un systme d'information avec un Progiciel de Gestion Intgr

Rfrence : CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI Date : 11 avril 2001 Version : 1.3 Etat : A terminer Auteurs : F.Villeneuve Diffusion : DSI

Objet du document : ce document a pour objectif de prsenter le cycle de dveloppement d'un systme informatique avec un progiciel de gestion intgr (PGI). La version actuelle de ce document ne se positionne pas comme une rfrence en la matire au CNRS mais elle contient un certain de nombre de conseils collects dans la littrature sur le sujet (essentiellement d'tudes du CIGREF, club informatique des grandes entreprises franaises). Par ailleurs, le document n'aborde pas de manire dtaille les rles et responsabilits de l'quipe projet dans l'organisation choisie.

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

Table des mises jour du document

Version 1.0

Date 20 octobre 2000 7 novembre 2000

Objet de la mise jour Cration du document, diffusion restreinte comme base de rflexion pour le projet BFC. Ajout d'informations sur la description des besoins et la modlisation des processus. Simplification des tapes. Complments : l'intgrateur apport sa mthode de dveloppement ; l'tape de ralisation des adaptations et complments s'effectue le plus tard possible dans le dveloppement ; recette plus courte gnralement. Modification du plan, de l'en-tte, du pied de page et de la rfrence du document suite l'volution du systme qualit de la DSI et la mise en place du site web de conduite de projet.

1.1

1.2

28 novembre 2000

1.3

11 avril 2001

CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI

11 avril 2001

2 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

Sommaire

1 - OBJET ET DOMAINE D'APPLICATION......................................................................4 2 - DOCUMENTS DE RFRENCE.....................................................................................5 3 - ABRVIATIONS ET TERMINOLOGIE ........................................................................5 4 - DESCRIPTION DES TAPES (SYNOPTIQUE)............................................................6 5 - ENREGISTREMENTS QUALIT (ERQ).....................................................................17 6 - ANNEXE : GNRALITS SUR LE DVELOPPEMENT AVEC PROGICIEL...17 6.1 Projet d'entreprise et amlioration des processus....................................................17 6.2 Analyse des cots....................................................................................................18 6.3 Organisation du projet.............................................................................................18 6.4 Gestion de la documentation du projet ...................................................................20

CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI

11 avril 2001

3 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

1 - OBJET ET DOMAINE D'APPLICATION La phase de DEVELOPPEMENT-PROGICIEL sapplique lors de dveloppements bass sur l'acquisition d'un progiciel de gestion intgr (PGI), avec, le cas chant, ralisation dadaptations spcifiques qui doivent rester limites. Elle concerne les activits de choix d'un progiciel, paramtrage et adaptation, mise en uvre de lapplication et de ses lments daccompagnement. Elle se termine lorsque le produit est install et oprationnel sur les sites des utilisateurs. Ces activits sont mises en uvre lors du dveloppement initial dun systme dinformation puis certaines, chaque itration de dveloppement dune nouvelle version en phase de MAINTENANCE/EVOLUTION.
version

MAINTENANCE / EVOLUTION DEFINITION DEVELOPPEMENT PROGICIEL EXPLOITATION / UTILISATION

Le dveloppement avec un progiciel doit faire l'objet d'un vritable projet : il ne faut pas se laisser piger par le choix d'un outil et oublier cette dimension projet. Les changes interentreprises, bien que difficiles organiser, sont une source d'conomie et d'enrichissement d'exprience, notamment pour les progiciels RH, la comptabilit : rgles communes, paramtrage, actions d'accompagnement... Ces changes se font naturellement dans les clubs d'utilisateurs. Le CIGREF permet galement aux grandes entreprises de rapprocher leurs expriences. Le dveloppement se droule de manire ordonne au cours de cinq tapes : choix de progiciel, tude de distance, ralisation (paramtrage et adaptations), conduite du changement et mise en uvre. Dans le cas dun systme de taille importante, les tapes peuvent tre suivies de manire linaire globale pour le systme dans son ensemble ou, de prfrence, de manire incrmentale, en dcomposant le systme en plusieurs ensembles successifs et complmentaires. Gnralement le dcoupage s'effectue en fonction des domaines fonctionnels couvrir par le systme. Le premier domaine pilote doit tre "encapsulable" en cas de problme ou de retour en arrire. Cette dmarche permet de dvelopper des ensembles plus lgers et de les mettre disposition des utilisateurs de manire chelonne dans le temps. Une fois le choix du progiciel effectu, les tapes suivies restent les mmes dans les deux cas.

CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI

11 avril 2001

4 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

Dveloppement progiciel global Etude de distance Ralisation Conduite du changement Mise en oeuvre

Choix progiciel

logiciel complet

Dveloppement progiciel incrmental Etude de distance Mise en oeuvre

Choix progiciel

Ralisation

domaine 1

Conduite du changement

Etude de distance

Ralisation

Mise en oeuvre domaine 2

Conduite du changement

2 - DOCUMENTS DE RFRENCE CIGREF : "Progiciels" - septembre 1996 CIGREF : "Retours d'exprience ERP" - septembre 1999 Schma stratgique des systmes d'information et des tlcommunications 2000-2002 du ministre de l'ducation nationale et du ministre de la recherche - avril 2000 Dossier spcial ERP : L&S 46 Joseph Gabay, Berhanou Gbr : "La conduite des projets d'volution des systmes d'information" - InterEditions 1999 Actes de la confrence du 20 juin 2000 l'INSA de Lyon : "Simplifier la mise en uvre des ERP grce aux outils de modlisation"

Beaucoup de textes du document ont t repris quasiment mot mot des documents du CIGREF. 3 - ABRVIATIONS ET TERMINOLOGIE BPR = Business Process Reengineering, reconfiguration des processus oprationnels. CIGREF = club informatique des grandes entreprises franaises. ERP = Enterprise Resources Planning, "sous-ensemble du systme d'information capable de prendre en charge la gestion intgrale de l'entreprise, incluant la gestion comptable et financire, la gestion de la production et de la logistique, la gestion des ressources humaines, la gestion administrative ainsi que la gestion des ventes et des achats". (source : CIGREF) Caractristiques : gestion effective de plusieurs domaines de l'entreprise (collaboration des processus) rfrentiel unique de donnes adaptations rapides aux rgles de fonctionnement uniformisation des IHM.

CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI

11 avril 2001

5 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

PGI = Progiciel de Gestion Intgr. "A tort considr comme la traduction de ERP : rassemble l'ensemble des applicatifs intgrs de gestion couvrant les fonctions horizontales ou verticales (mtiers) d'une entreprise. Or les ERP couvrent seulement les fonctions horizontales". (source : CIGREF) Progiciel = "ensemble cohrent et indpendant constitu de programmes, de services, de supports de manipulation ou d'informations (bordereaux, langages) et d'une documentation, conu pour raliser des traitements informatiques standards, dont la diffusion revt un caractre commercial et qu'un usager peut utiliser de faon autonome aprs une mise en place et une formation limite". (source : Journal Officiel 1980) 4 - DESCRIPTION DES TAPES (SYNOPTIQUE) Deux dmarches de dveloppement sont possibles : la rdaction a priori dun cahier des charges complet sans connatre le progiciel, puis la comparaison avec les fonctionnalits du progiciel ; la rdaction du cahier des charges partir des fonctionnalits du progiciel (avantage : plus rapide). Le risque possible est d'oublier les fonctionnalits ncessaires lentreprise mais absentes dans le progiciel, et d'enlever une part du sens critique vis vis du progiciel. La premire dmarche est dveloppe ci-aprs, tout en privilgiant un cahier des charges "minimal", suffisant pour effectuer le bon choix de progiciel et apte voluer dans l'objectif d'amlioration des processus de l'entreprise.

CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI

11 avril 2001

6 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

Etape 1 dfinir le cahier des charges 2 faire l'inventaire des progiciels

cahier des charges

5-6 progiciels

Choix progiciel

3 consulter les fournisseurs

2-3 progiciels 4 analyser les progiciels retenus

progiciel choisi 5 prendre en mains le progiciel

Etude de distance et Conduite du changement

8 concevoir l'accompagnement du changement

6 mener la conception gnrale

7 prparer la rception

Ralisation et Conduite du changement

11 raliser les actions d'accompagnement (fonctionnel et organisationnel)

9 raliser et tester le paramtrage

10 raliser et tester les adaptations et complments

12 effectuer la rception interne

Mise en oeuvre et Conduite du changement

13 effectuer la rception externe sur sites pilotes

14 gnraliser la diffusion

CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI

11 avril 2001

7 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

1. Dfinir le cahier des charges : Le "systme cible" dfini dans le cahier des charges ne doit pas tre conu comme une solution absolue non ngociable, sinon le risque est de ne trouver aucun progiciel capable de rpondre au cahier des charges. Les lments du cahier des charges peuvent tre pondrs en fonction des besoins des utilisateurs (fonctions juges indispensables, souhaitables, facultatives, proscrites), ou de la politique gnrale d'acquisition de progiciels. Le cahier des charges est structur en plusieurs parties. les besoins : le systme cible est dfini partir des besoins des utilisateurs et pas partir des fonctions d'une solution progiciel. Il est possible de dcrire le prsent et/ou le futur en tenant compte d'volutions prvisibles ou souhaitables (mais il faut le prciser). Il ne faut pas ncessairement tout dcrire, mais insister sur ce qui est critique ou mal connu. Il faut savoir se limiter un certain niveau de dtail (activits et non tches lmentaires). Il ne faut pas modliser les processus connus ou imposs (ex : comptabilit). La prise en compte de l'existant est toujours trs importante : il s'agit de ne pas perdre la culture d'entreprise mme si tout est loin d'tre parfait. Il faut associer troitement les utilisateurs directs et indirects l'volution de cet existant (leur prvoir un temps de disponibilit). Il faut galement dcrire les alas, les vnements qui perturbent le fonctionnement idal de l'organisation. - les processus et procdures, - les rgles de gestion, - les principes d'organisation (MOT), nombre d'utilisateurs, nombre de responsable des mises jour, nombre de types de sites, - les donnes gres (MCD, volumes traits, interfaage, volumtrie et format des fichiers, entres requises, sorties fournies, taille des bases...), - les interfaces : donnes changes, frquence des changes, volume des donnes. La dfinition des interfaces est un choix de conception majeur pour le systme d'information de l'entreprise. Les options sont dfinir par l'entreprise et non par le fournisseur, les contraintes : - dlai de mise en uvre, - cots de mise en uvre (formation, maintenance, assistance, reprise des donnes, dveloppement, documentation), - contraintes techniques (compatibilit avec les autres logiciels, systmes d'exploitation, langages et SGBD, matriels, intgration dans le SI existant, respect de normes internes, appartenance une liste de produits homologus en interne, fonctionnement en rseau, architecture ncessaire, outils intgrs, intgration dans les systmes de scurit, existence des points de reprise en cas de dysfonctionnement, facilit dintgration dans le plan de sauvegarde et darchivage, robustesse du systme en cas de dfaillance dun sous-systme, compatibilit avec les outils dadministration, performance, etc), - ergonomie : l'ergonomie des progiciels diffre souvent de lergonomie standard des applications de l'entreprise, ce critre ne doit donc pas tre trop dtaill. Il peut porter sur le style d'interface (graphique, Web), le multi-fentrage, la possibilit de paramtrer les crans ou les possibilits d'interrogation multi-critres de la base d'informations, des clauses contractuelles : dlai entre la sortie d'une version par le fournisseur et son installation, rcupration des sources (en cas de faillite ou abandon du produit) Le cahier des charges est valid formellement par les instances dcisionnelles du projet.

CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI

11 avril 2001

8 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

2. Faire l'inventaire des progiciels (2) En parallle, un inventaire des progiciels existants couvrant tout ou partie du domaine concern et de leurs fournisseurs est ralis. Une fois le cahier des charges tabli, une premire liste de progiciels correspondant "sur le papier" au cahier des charges (environ 6) est slectionne. 3. Consulter les fournisseurs Le dossier de consultation est envoy aux fournisseurs de ces progiciels afin qu'ils explicitent de quelle manire le progiciel rpond aux besoins, accompagn d'un questionnaire de prise d'informations concernant des aspects gnraux : sur le fournisseur : capital social, groupe d'appartenance, chiffre daffaire, bnfice, effectif, pourcentage de vente de progiciels sur lactivit totale, sur les produits proposs : nom, gamme des produits du fournisseur, taille des quipes de dveloppement et de support technique, versions, modalits de relation (partenariat, club dutilisateurs, etc. ), sur le progiciel: - dfinition de loffre commerciale, - date de conception, date de commercialisation, date de la dernire version, - nombre d'exemplaires vendus, nombre dutilisateurs en France, - dlais de livraison de la version initial et des versions futures, - cots, - support technique pour linstallation, le suivi aprs installation, - maintenance : couverture, dlai d'intervention, priodicit et modalits d'obtention d'une nouvelle version, - formation, - documentation, - environnement technique, - architecture des donnes et des objets (fichiers, bases de donnes, modles conceptuels et physiques), - architecture des traitements et des fonctions (modle de communication, interfaces, etc. ), - scurit, - ergonomie, - temps de rponse, - volutivit du progiciel, capacits de paramtrage du progiciel. A rception des offres des fournisseurs, l'analyse des offres est effectue pour n'en retenir que 2-3. 4. Analyser les progiciels retenus Deux solutions peuvent tre envisages pour effectuer le choix : analyser de manire approfondie les 2 ou 3 progiciels retenus, retenir une seul progiciel et l'valuer, si abandon considrer le prochain sur la liste. Evaluation des progiciels : Elle se fait de diffrentes manires : vrifier et interroger les rfrences, tudier la documentation, voir fonctionner le progiciel (dmonstration avec jeux d'essais du fournisseur, passage de jeux d'essais propres l'entreprise),
CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril 2001 9 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

faire des tests de performance, et comparer par rapport aux performances souhaites, visiter des sites comparables : afin d'avoir un clairage sur les difficults, les moyens ncessaires, les cots, les dlais, la satisfaction des utilisateurs, la qualit de la relation avec le fournisseur, mener une tude de dimensionnement pour le matriel. Les diteurs sont gnralement en partenariat avec des fournisseurs, faire fonctionner le progiciel sur le site de l'entreprise (exprimentations de prototypes intgrant tout ou partie des paramtres propres), avec pour objectifs : - validation des processus essentiels du point de vue "mtier", - validation des processus posant le plus de difficults de faisabilit, - compatibilit technique, - prcision des dveloppements complmentaires, - valuation ergonomique (plus riche que les dmonstrations), - prsentations aux futurs utilisateurs. Le prototypage aide la comprhension des besoins et garantit ladquation de la conception aux besoins. Il permet dacqurir une meilleure connaissance du progiciel, de mieux adapter la conception fonctionnelle et technique au progiciel, d'tudier les performances et les limites du progiciel. La dfinition et la squence des tches de prototypage doivent reflter la logique de paramtrage du progiciel, sur un sous-ensemble reprsentatif de cas, par exemple : les 20% de cas qui couvrent 80% des volumes, les 20% de cas les plus complexes pour lesquels il faut vrifier la faisabilit. Une formation au progiciel (complte ou partielle) peut permettre d'approfondir les choix d'utilisation du progiciel. Etude de faisabilit : Certains diteurs (exemple tir de SAP) proposent une tude de faisabilit, qui permet de prendre ou non la dcision d'implmenter le progiciel. Les rsultats de cette tude peuvent tre utilises ensuite au cours des premires phases de l'implmentation. L'tude est mene par des consultants, en relation directe avec les dirigeants et les personnes cls des services utilisateurs et informatiques. Le rsultat de l'analyse est prsent dans un document dtaillant les points suivants : stratgie de mise en uvre, environnement technique, primtre prliminaire de la mise en uvre, fonctions et processus mettre en place, primtre organisationnel, dure du projet, organisation du projet, estimation des cots, rsultats attendus et retours pour l'entreprise, carts fonctionnels entre le progiciel et les besoins, solutions possibles pour rduire de tels carts, conditions pralables remplir par l'entreprise, rsultats de l'analyse des risques. Notation des progiciels : Chaque progiciel doit tre not sur la base de critres pondrs, en utilisant une grille dvaluation comme outil de rflexion et de mise en lumire des diffrences et des points importants. Une analyse de sensibilit des critres au choix final peut tre effectue en faisant
CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril 2001 10 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

voluer les pondrations des diffrents critres, notamment en isolant les critres principaux des critres secondaires. Quelques critres : rfrences, exprience, prennit, solidit de la socit, couverture fonctionnelle et adquation de celle-ci aux besoins (fonctions, donnes, rgles de gestion). Pour chaque besoin non couvert par le progiciel, il faut vrifier la pertinence du besoin, s'il y a un paramtrage ou une adaptation spcifique possible, s'il existe une solution organisationnelle ou d'utilisation d'un autre produit, couverture organisationnelle (possibilits d'utilisation, types d'utilisateurs), flexibilit (capacit du progiciel sadapter diffrentes organisations) : dpend de son architecture technique et fonctionnelle. Un progiciel trs flexible et trs adaptable requiert de ce fait mme un travail plus long de paramtrage et dadaptation. Un progiciel peu flexible peut conduire l'entreprise sadapter aux contraintes pour viter des adaptations trop coteuses, compatibilit technique avec les choix de l'organisme. La non conformit technique par rapport aux standards de l'organisme a un cot chiffrer et mettre en balance avec les points forts du progiciel (primtre fonctionnel mieux couvert). Si une technique non standard est accepte, il faudra veiller au support et la formation des quipes internes (quipes d'exploitation et ventuellement quipes de maintenance), intgration du progiciel dans larchitecture fonctionnelle et technique du systme d'information (interfaces) cf dvelopp ci-dessous : intgration l'existant, dlais et cots de mise en uvre, qualit des liens contractuels pour la mise en oeuvre et la vie du progiciel, services autour du progiciel : installation, formation, support local, maintenance, dmarche de mise en uvre cf dvelopp ci-dessous : prparation de la maintenance, facilits d'volution : rythme des versions, acquisition de nouveaux modules, portabilit Se mfier des progiciels non totalement oprationnels et finaliser. Intgration l'existant : Les cots et les contraintes dintgration reprsentent un critre de choix important dans la dmarche de recherche de progiciel. L'intgration au systme d'information existant entrane une analyse complexe trop souvent sous estime. La difficult rside dans lintgration des bases de donnes du progiciel dans l'ensemble des bases de donnes de rfrence de l'entreprise, surtout si le progiciel doit dialoguer de manire trs troite avec des bases de donnes existantes n'ayant pas du tout la mme structure que les bases de donnes du progiciel. Les risques (de surcot, de drapage de planning, de manque dvolutivit, de dysfonctionnements, etc.) seront dautant plus levs que le progiciel s'appuiera sur des rfrentiels de lentreprise. Ils seront diminus si le progiciel a une approche de linterface sous forme de services. Lanalyste intgrateur devra se poser les questions suivantes : - comment changer des donnes entre le nouveau progiciel et les systmes dinformation existants ? - quels sont les fichiers et les messages quil faut changer entre progiciels et systmes existants ? - quelles sont les donnes conceptuellement partages par le progiciel et les systmes existants ? - quelles sont les donnes partages physiquement ? - dans quels fichiers et quelles bases de donnes se trouvent-ils ? - quand il y a redondance dinformation physique, faut-il laisser cette redondance, et assurer un rapprochement instantan ou diffr, ou garder une seule source, et modifier le progiciel ou le systme existant en consquence ? Ce choix dpend largement du caractre critique des redondances (est-il dangereux de les laisser exister ? combien de
CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril 2001 11 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

temps 2 bases de donnes peuvent-elles rester dsynchronises ?) et de larchitecture des systmes dinformation concerns (progiciel et existant peuvent-ils facilement partager des fichiers qui ont une structure diffrente et peut-tre aussi une mthode daccs ou un SGBD diffrent ?), - dans un environnement dcentralis, faut-il garder une base de donnes sur le site central ? Quel sera le systme matre ? - quelle sera la frquence de transmission des donnes entre les 2 bases ? Le choix doit tre fait d'une frquence adapte au besoin de l'utilisateur. Ce n'est pas ncessairement le temps rel. Bien souvent une transmission asynchrone est suffisante. L'intgration peut entraner des adaptations coteuses du progiciel. Le degr d'ouverture du progiciel est un critre de choix important : - il rside tout d'abord dans le type de liaison entre applications prvu par l'diteur : interfaces standards (Edifact...) ou non standards, - il rside galement dans la libert accder aux donnes du progiciel avec des outils standards du march. Certains progiciels, en effet, n'acceptent que des requtes propritaires. Prparation de la maintenance : Il est prfrable de ngocier les conditions de maintenance en mme temps que lachat du progiciel. L'entreprise doit dcider des modalits de maintenance du progiciel, de ses extensions (interfaces spcifiques) et des paramtres qui peuvent tre grs diffremment : maintenance et optimisation du produit compltement assures par l'entreprise, donc connaissance du "noyau" dur progiciel souvent considr comme "boite noire", avec ses mcanismes gnraux et les techniques utilises pour les points dentre/sortie, maintenance effectue par lquipe de l'entreprise, avec laide ventuelle dexperts du fournisseur pour des oprations complexes, maintenance sous-traite. La maintenance doit grer les demandes d'extensions techniques et fonctionnelles, les incidents et la relation avec l'diteur pour ces demandes (enregistrement, suivi, interventions sur site, corrections temporaires) et pour leur intgration dans les versions dfinitives. On veillera galement la compatibilit ascendante des diffrentes versions et la prennit des interfaces et des dveloppements spcifiques. Il est important de dfinir le mode de diffusion des versions par le fournisseur ds le stade contractuel (documentation, frquence, support). Le contrat peut prciser un dlai contractuel entre la sortie d'une version par le fournisseur et l'obligation pour l'entreprise de changer de version (par exemple pas plus de 18 mois). On peut lier l'obligation de changer de version au fait que les fonctionnalits ne subissent pas de rgression. Chaque changement de version doit tre accompagn d'un document de l'diteur recensant les diffrences de fonctionnalits ou les corrections de dysfonctionnements entre la version nouvelle et l'ancienne. Une version majeure (en terme de consquence sur les fonctionnalits, de changement denvironnement technique) devra tre traite comme un projet de manire ne pas oublier les impacts sur les interfaces ou sur les fonctionnalits offertes aux utilisateurs. Cela peut tre l'occasion l'issue de l'tude de prendre ventuellement la dcision de ne pas migrer. L'entreprise ne doit pas en effet se sentir oblig de changer de version aussi frquemment que le propose lditeur. Les risques inhrents une version majeure doivent tre mesurs et mis en balance avec les gains pour l'entreprise. L'entreprise doit rester matre des changements de versions.

CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI

11 avril 2001

12 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

Il est risqu de sauter la mise en uvre de plusieurs versions dun progiciel, pour plusieurs raisons, notamment les problmes de compatibilit avec les versions antrieures et la comptence des quipes de support. La qualit du support assur par le fournisseur est essentielle dans ce type de manipulation. Elle est intgrer dans les critres de choix du progiciel en prenant en compte l'avis d'autres clients du fournisseur. Choix du progiciel : Le rapport d'analyse est soumis la commission d'appel d'offre pour dcision sur le choix du progiciel. Le contrat est finalis avec le fournisseur et sign. 5. Prendre en mains le progiciel Avant de dfinir les options de paramtrage et les adaptations complmentaires apporter, il est ncessaire d'avoir une connaissance approfondie des possibilits du progiciel. Des formations de l'quipe projet sont organises et le progiciel est install dans l'environnement cible. Les environnements (dveloppement-exploitation) sont organiss, serveurs et postes clients. Les principes de gestion de la documentation technique et du paramtrage usage des utilisateurs doivent tre dfinis. 6. Mener la conception gnrale Dans cette phase, la dmarche globale de mise en uvre du progiciel est dfinie : primtre du projet, personnalisations, planning, scnarios de dmarrage. Ds cette phase, il faut s'attacher favoriser l'adhsion et l'implication des utilisateurs, mobiliser les comptences adaptes au moment voulu. Dfinition du primtre : Le primtre du projet est dfini : identification des domaines fonctionnels concerns par la version initiale et leur intgration dans le systme d'information existant : le champ d'application du progiciel est rduit pour l'adapter aux processus de gestion spcifiques de l'entreprise. Ceux-ci sont reconfigurs si besoin est (Business Process Reegineering). Les processus sont documents (modle conceptuel), le point fondamental de lintgration fonctionnelle est certainement lharmonisation des donnes et des services communs de l'entreprise. Il ne faut pas hsiter demander le MCD du progiciel ou le reconstruire. Il est ncessaire d'tudier rapidement les adaptations ncessaires par rapport aux applications en interface. Personnalisations : Les personnalisations sont identifies de manire globale. La spcification du paramtrage et des adaptations/complments est conduite de manire itrative pour obtenir un scnario acceptable en fonction du progiciel choisi. Chaque personnalisation fait l'objet d'une analyse de la valeur qui vise se demander son apport pour l'organisme au regard de la charge de paramtrage et de mise en uvre induite. Planification et scnario de dmarrage : La planification et les estimations de charges sont prcises. Des jalons de contrle des objectifs, des budgets et des dlais sont positionns. Des lots sont dfinis. Le scnario de dmarrage est dfini.

CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI

11 avril 2001

13 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

Une runion de lancement en prsence des instances dcisionnelles entrine les choix effectus en conception gnrale. 7. Prparer la rception Non dtaill. 8. Concevoir laccompagnement du changement Non dtaill. 9. Raliser et tester le paramtrage Chacun des lots identifis en phase prcdente est dtaill : personnalisation du dictionnaire des donnes, maquettes des crans, rgles de gestion, description des diffrentes fonctionnalits dans le progiciel Les charges sont confirmes. Il faut sorienter vers une approche maximum de paramtrage/minimum dadaptation . Au dpart, il y a un paramtrage de base, qui va concerner par exemple 80% des transactions courantes. Puis sont traits ensuite les 20% restants des processus de gestion, les exceptions. Il faut tre vigilant sur les choix structurants de paramtrage : suivre la dmarche prconise par le fournisseur, lui demander des informations, changer des expriences entre entreprises. Il est important de prendre le temps de prototyper les diffrentes possibilits de paramtrage pour choisir la meilleure et d'impliquer trs tt les utilisateurs. La confrontation entre les besoins exprims et les possibilits du progiciel ne peut tre effectue quavec laide dexperts du progiciel, collaborant de faon troite avec lquipe projet sur les points dlicats dadquation fonctionnelle. La gestion des carts doit tenir compte du cot de la solution mais aussi de la complexit engendre lors dune volution ou dun changement de version. Le paramtrage du progiciel comprend : le rapprochement des caractristiques du progiciel avec le cahier des charges initial, et la mise jour du schma gnral de fonctionnement du progiciel : - processus couverts et non couverts, - rpartition des processus en modules du progiciel (module principal, secondaire, traitement manuel), changes inter-modules (interfaces), identification des interdpendances entre le progiciel et le systme d'information cible, - le paramtrage du progiciel doit suivre un ordre logique, cal en principe sur la dfinition des tables de paramtrages de leurs dpendances et les instructions donnes par l'diteur, la dfinition pour chaque module du progiciel : - des procdures requises pour mettre en place les valeurs initiales des paramtres et des tables, - des procdures pour modifier ces valeurs initiales, - des possibilits de personnalisation des interfaces et des formats ddition. Un dossier de paramtrage du progiciel est labor : tous les changements ou ajouts au systme sont documents.

CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI

11 avril 2001

14 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

Un prototype est ralis pour servir de base des tests de performance et des exprimentations avec les utilisateurs. La dmarche est incrmentale. 10. Raliser et tester les adaptations et complments Cette tape se droule le plus tard possible dans le dveloppement, aprs avoir examin toutes les possibilits de paramtrage. Il faut impliquer en priorit les comptences du fournisseur "expert progiciel" pour trouver des solutions d'adaptations et extensions dans le produit. A dfaut, il faut envisager de traiter le problme dans une autre application ou ne prendre la dcision dadapter le progiciel quen toute dernire extrmit, aprs avoir valu limpact du dveloppement par rapport toute autre solution. Si le paramtrage ne suffit pas pour rpondre au besoin de lutilisateur, il faut rtudier le besoin avec l'utilisateur pour essayer de revoir les rgles de gestion afin d'viter les adaptations. Les cots ventuels lis aux modifications des rgles de gestion sont mettre en balance avec les risques des ventuelles adaptations du progiciel. Il appartiendra aux utilisateurs de rdiger des argumentaires qui seront arbitrs haut niveau. Pour restreindre les dveloppements spcifiques, faire en sorte que la dcision d'allouer des budgets soit prise trs haut niveau. Une grande prudence est de mise vis vis des adaptations : viter surtout les adaptations du noyau, limiter les personnalisations. Les adaptations du progiciel reprsentent un facteur de risque pour l'intgration : divergence dans le planning initial, non adquation aux besoins, non fiabilit du progiciel, gestion des nouvelles versions, qualit de la hot line, formation spcifique des utilisateurs... Donc : documenter trs prcisment les adaptations car tout changement dans la version du progiciel impacte directement ces ajouts, limiter au maximum les adaptations par une sensibilisation de l'utilisateur, les mener avec une dmarche de projet standard, spcifier selon les rgles de l'art, prototyper les fonctionnalits spcifiques. Le prototype est ralis pour servir de base des tests de performance et des exprimentations avec les utilisateurs. La dmarche est incrmentale. Au niveau fonctionnel, plusieurs solutions sont envisageables : examiner si une solution organisationnelle conviendrait, utiliser un produit complmentaire, ajouter de nouvelles fonctions, spcifiques l'entreprise et prises en charge par celui-ci ou par le fournisseur, devenant des nouvelles fonctions du progiciel ou des dveloppements spcifiques, modifier le progiciel, modifier les systmes existants pour les adapter au progiciel. Au niveau technique, lintgration ncessite aussi souvent quelques modifications du progiciel pour le rendre le plus proche possible des normes d'exploitation de l'entreprise. De plus, il est ncessaire de spcifier les exigences relatives la scurit (disponibilit, habilitations, plan de secours).

Par contre, des programmes spcifiques sont gnralement ncessaires pour les interfaces.
CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril 2001 15 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

Sil sagit de la migration dun ancien vers un nouveau systme, la reprise des donnes est galement spcifie et dveloppe. Un avantage du progiciel rside dans les outils souvent proposs par le fournisseur pour la reprise des donnes des anciens systmes. Ces deux types de dveloppement s'effectuent par contre plus tt dans le dveloppement. Les tests s'effectuent durant toute la phase, tests de volumtrie et de monte en charge, tests d'intgration pour la reprise des donnes et les interfaces. 11. Effectuer la rception interne Non dtaill. La recette est gnralement plus courte que pour des logiciels spcifiques. Elle est centre sur les problmatiques d'intgration des modules. 12. Raliser les actions daccompagnement (fonctionnel et organisationnel) Non dtaill. Des formations propres chaque fonction sont organises. Il est prfrable que les utilisateurs soient forms par des utilisateurs expriments de l'organisme (d'o l'organisation pralable de formation de formateurs).

13. Effectuer la rception externe sur sites pilotes Non dtaille Le passage sur sites pilotes permet dexprimenter le systme informatique en environnement rel ou quasi-rel dutilisation. Lobjectif est de sassurer que le systme fonctionne de manire oprationnelle et satisfait les utilisateurs. Cest une activit incontournable dans le cas dun nouveau progiciel. Les sites pilotes peuvent faire coexister l'ancien systme et le nouveau systme si c'est possible. Pour les applications stratgiques, il est essentiel de prvoir un fonctionnement en double des 2 systmes (ancien et nouveau). Toutefois, certaines entreprises excluent la marche en double pour les raisons suivantes : cette dmarche reprsente une charge de travail importante pour les utilisateurs comme pour l'quipe projet ; il est difficile d'imputer les diffrences soit des erreurs du nouveau systme, soit des erreurs de l'ancien, soit tout simplement une faon diffrente de grer et de calculer ; dans tous ces cas, la recherche des diffrences peut aboutir des charges de travail excessives, des impasses ou des erreurs de jugement ; la charge de travail doit tre concentre sur la mise en oeuvre de la nouvelle solution, le temps pass sur l'ancien systme tant rduit au maximum. Gnralement, il y a peu d'anomalies dtectes mais plutt des erreurs fonctionnelles. Aprs correction, il y a gnralement peu d'effets de bord, donc peu d'allers-retours ncessaires. Le bilan des sites pilotes est prsent aux instances dcisionnelles du projet qui donnent leur avis sur lopportunit de gnraliser et la suite donner aux diffrents retours obtenus des sites pilotes.

CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI

11 avril 2001

16 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

14. Gnraliser la diffusion Non dtaill. Les utilisateurs sont forms lutilisation de la nouvelle application. Le systme informatique est diffus sur la totalit ou une partie des sites : installation, reprise des donnes ventuelle, dmarrage de lexploitation. Une priode de fonctionnement en double entre lancien et le nouveau systme peut tre prvue. A la fin de la mise en uvre, s'effectue le transfert de comptences de l'quipe projet externe vers l'quipe projet interne (utilisateurs et informaticiens). Attention la perte importante de savoir-faire lors du transfert de comptences au dmarrage de la solution. Les inquitudes en phase de maintenance sont gnralement de : assurer la bonne appropriation par les utilisateurs, maintenir la cohrence de la solution initiale, conserver les comptences internes.

5 - ENREGISTREMENTS QUALIT (ERQ)

Nom de lERQ Identification du QFE Modalits didentification de lERQ Dure de conservation Lieu dArchivage Responsable Modalits dlimination

QFE : formulaire denregistrement Qualit

6 - ANNEXE : GNRALITS SUR LE DVELOPPEMENT AVEC PROGICIEL 6.1 Projet d'entreprise et amlioration des processus L'utilisation d'un progiciel intgr est un projet d'entreprise ncessitant une implication de la direction gnrale et une dmarche d'accompagnement du changement. Dcider d'une approche de ce type, c'est prendre le parti d'unifier et de rationaliser les applications et de ne pas toujours conserver toutes les spcifications et habitudes des utilisateurs. La mise en place d'un progiciel doit tre considre comme une opportunit pour reconfigurer les processus (Business Process Reengineering). La premire tape du dveloppement doit donc tre une remise en question des aspects organisationnels cls de la productivit et de l'efficacit de l'entreprise. Adopter un progiciel c'est s'adapter ! Cette caractristique gnre par contre un des risques lis l'emploi de progiciels : l'uniformit pourrait empcher l'entreprise d'voluer tant au plan fonctionnel qu'organisationnel, entraner une dsaffection des informaticiens, voire des utilisateurs qui s'en remettent une pense extrieure. Gnralement, pour raliser cette tape, des techniques de modlisation des processus sont utilises. Les techniques de modlisation utilisent des mthodes descriptives et des outils informatiss qui visent fournir une aide la conception, l'analyse et l'optimisation d'organisations. Toutes les mthodes placent la notion de processus oprationnel (business

CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI

11 avril 2001

17 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

process) au cur de leur dmarche, les outils incluant gnralement des notions de workflow et de simulation.

La conduite du changement est un processus classique dans son ensemble. Il convient de penser la politique de changement et au plan de communication ds le dbut du projet. La communication doit comporter entres autres les raisons du choix d'un progiciel plutt qu'une solution interne. Une attention particulire doit tre porte aux actions de communication car le changement demand aux utilisateurs est gnralement plus important dans le cadre dun progiciel. Par contre, on constate que le niveau dadhsion des utilisateurs est souvent suprieur avec des progiciels quavec des dveloppements spcifiques (il est plus difficile de critiquer ce qui se fait de mieux sur le march et ce que l'on a contribu choisir). 6.2 Analyse des cots L'analyse des cots doit prendre en compte tous les cots dinstallation et dexploitation, notamment : - cot d'tablissement d'un bon contrat, - achat des licences (seulement en moyenne 20% des dpenses), - achats dquipements, matriels, - frais dinstallation (dont paramtrage, prototypage, slection des produits), - formation des informaticiens et des utilisateurs, - maintenance et support fonctionnel et technique, - exploitation et support systme, en particulier surcots si le progiciel impose des progiciels de base (exemple : un SGBD) que lentreprise nutilisait pas auparavant, - dveloppements spcifiques et interfaces, - cots de conversion de lancien au nouveau systme, - maintenance de ces dveloppements. Elments de cots labors par rapport l'ERP de SAP (cabinet Forrester) : "le cot d'acquisition se trouve entre 50 et 150 kF par utilisateur (matriels, logiciels, services). L'externalisation de la maintenance, des travaux lis l'volution, l'euro, la monte de version, l'optimisation : une prise en charge qui correspond 3 mois, en moyenne, revient 5 10% du cot d'acquisition. Ensuite, en service continu, cela reprsente 15 20% du cot d'acquisition. Une monte de version, c'est galement 15 20% du cot d'acquisition ou en fonction du nombre de dveloppements spcifiques requis. Le cot d'optimisation peut, pour sa part, atteindre 20% du prix d'acquisition." 6.3 Organisation du projet La structure dune quipe de projet "progiciel" na pas de caractristiques particulires sauf que laccompagnement dexperts du fournisseur, tant dans le domaine fonctionnel que technique, est indispensable. Relations matrise d'oeuvre/matrise d'ouvrage : Il n'y a pas de raison majeure pour que la mise en oeuvre d'un progiciel change significativement la relation matrise d'oeuvre/matrise d'ouvrage. Toutefois, les quipes informatiques doivent grer la relation avec les divers sous-traitants (fournisseurs de progiciels, SSII, etc.. ), qui devient prpondrante. Ces quipes tiennent alors le rle de conseil au matre d'ouvrage ou de matre d'oeuvre dlgu, en plus de leur fonction de matre d'oeuvre principal.
CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril 2001 18 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

La direction des projets ERP est souvent confie aux quipes de matrise d'ouvrage (un tiers seulement aux DSI). Le rle du service informatique se limite parfois celui de garant du paramtrage et des mises jour. Le directeur de projet coordonne la matrise d'ouvrage et la matrise d'uvre. Il est souvent assist de chefs de projets, chargs entres autres : de l'accompagnement du changement, de la conception et du dveloppement des interfaces. Qui dit intgration, dit coordination de plusieurs interlocuteurs, responsables des autres applications. Organisation du matre d'oeuvre : quipe mixte entreprise/fournisseur, dont lavantage rside dans une grande osmose dexpriences et la rapidit du paramtrage mais accrot la complexit de lencadrement, quipe de l'entreprise accompagne dexperts du fournisseur, qui oblige plonger plus fond dans le progiciel mais ralentit la mise en oeuvre, sous-traitance, valable uniquement si la maintenance est aussi sous-traite ou avec un transfert de connaissance trs difficile lissue du paramtrage. Les ERP ncessitent une volution des profils et comptences : formation, raffectations Il est en effet ncessaire dvaluer quel doit tre le niveau dexprience des informaticiens. En fonction de limportance que revt le systme dinformation, il conviendra de dcider sil faut former les informaticiens au paramtrage, aux fonctions externes, larchitecture interne du progiciel, et sils doivent devenir des spcialistes de son emploi ou de sa programmation. Le temps pass en analyse, programmation et tests dun logiciel spcifique leur permet en effet de capitaliser une exprience qui peut savrer prcieuse pour l'entreprise ou, au contraire, les dtourner dactivits plus forte valeur ajoute. Organisation du matre d'ouvrage : Le pilotage du projet peut tre assur conjointement par un chef de projet de l'entreprise et un chef de projet du fournisseur. Le partage des tches de ralisations, dencadrement et des responsabilits sont dfinir dans un contrat. Deux types dintervention sont prvoir : ralisations pour lesquelles le fournisseur assure la matrise doeuvre, avec un suivi par un responsable de l'entreprise, assistance du fournisseur sur les tches dont l'entreprise assure la matrise doeuvre. Dans ce cas, la mission du fournisseur consiste assurer le contrle qualit et le contrle de la bonne utilisation technique du produit. La matrise douvrage assure la responsabilit du pilotage de la conduite du changement qui doit tre mise en oeuvre ds le dbut du projet. Ceci ncessite une bonne connaissance des concepts du progiciel, donc une formation particulire ds le dmarrage. En effet les progiciels ont certaines particularits : existence dun processus optimal du mode de fonctionnement, existence de plusieurs solutions techniques pour un pilotage satisfaisant dun processus. Participation des utilisateurs : Il est indispensable de constituer un quipe mixte informaticiens/utilisateurs et apporter une formation initiale commune ds lacquisition du progiciel. de leur

Centre de comptences ERP : Il est important de constituer un centre de comptences ERP. Ce centre de comptences s'appuie sur des ressources expertes de l'diteur ou de la socit de services, de la DSI, de reprsentants de la matrise d'ouvrage. Ses missions sont de : capitaliser les comptences acquises au niveau technique, apporter une assistance en gestion et animation des quipes projets,
CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril 2001 19 / 20

Procdure Qualit - Dveloppement avec un progiciel de gestion intgr

tenir un rle oprationnel dans les projets (intgration fonctionnelle, gestion documentaire, planning de dploiement, origine de la mthodologie et du vocabulaire commun aux projets, formation), faire de la veille technologique et fonctionnelle (tude des progiciels du march, des logiciels dvelopps par les autres organismes et les progiciels que ceux-ci utilisent).

Le fournisseur : Il faut sassurer que les experts du fournisseur ont une exprience effective du produit et reoivent un support efficace des quipes de dveloppement et de support technicocommercial. L'entreprise se doit dtre exigeante sur le profil du chef de projet fournisseur : il sera expriment, aura implant ce progiciel dans plusieurs socits. On peut recommander dvaluer prcisment lexprience relle et la comptence des diffrents intervenants. Le fournisseur est souvent un intgrateur (socit de services), en partenariat avec un diteur et un constructeur. Formation : La formation la mise en oeuvre fait partie des prestations habituelles de l'diteur. Pour les progiciels les plus diffuss, des SSII offrent des prestations analogues. L'entreprise doit penser la formation initiale et la formation rcurrente des utilisateurs. Elle peut donc tre conduite constituer un groupe de formateurs connaissant le progiciel une fois adapt l'entreprise. L'quipe projet est forme pendant le dveloppement, en plusieurs fois pour les diffrents niveaux de formation prvus. Paramtrage et adaptations : De mme, le paramtrage est une prestation habituelle de l'diteur. Des SSII peuvent avoir cette exprience et sont parfois plus comptentes. Certaines entreprises peuvent avoir intrt disposer de spcialistes internes pour le paramtrage initial et ses volutions. Plusieurs entreprises conseillent de confier les dveloppements spcifiques une SSII plutt qu lditeur du progiciel. Cet intgrateur apporte la plupart du temps sa mthode de dveloppement associ au progiciel. 6.4 Gestion de la documentation du projet La documentation habituelle doit tre complte des informations suivantes : paramtres utiliss, valeurs et signification fonctionnelle ou technique, interfaces avec les autres systmes dinformation, complments et modifications apports au progiciel. La documentation sur le paramtrage doit tre effectue tout au long du projet et dune manire trs rigoureuse. Il faut dfinir ds le dbut un projet documentation : organisation et support de la documentation technique, organisation et support de la documentation du paramtrage usage des utilisateurs.

CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI

11 avril 2001

20 / 20