Développement d'un système d'information avec un Progiciel de Gestion Intégré

Transcription

1 Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Procédure Qualité Développement d'un système d'information avec un Progiciel de Gestion Intégré Référence : 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 présenter le cycle de développement d'un système informatique avec un progiciel de gestion intégré (PGI). La version actuelle de ce document ne se positionne pas comme une référence en la matière au CNRS mais elle contient un certain de nombre de conseils collectés dans la littérature sur le sujet (essentiellement d'études du CIGREF, club informatique des grandes entreprises françaises). Par ailleurs, le document n'aborde pas de manière détaillée les rôles et responsabilités de l'équipe projet dans l'organisation choisie.

2 Table des mises à jour du document Version Date Objet de la mise à jour octobre 2000 Création du document, diffusion restreinte comme base de réflexion pour le projet BFC novembre 2000 Ajout d'informations sur la description des besoins et la modélisation des processus. Simplification des étapes novembre 2000 Compléments : l'intégrateur apport sa méthode de développement ; l'étape de réalisation des adaptations et compléments s'effectue le plus tard possible dans le développement ; recette plus courte généralement avril 2001 Modification du plan, de l'en-tête, du pied de page et de la référence du document suite à l'évolution du système qualité de la DSI et la mise en place du site web de conduite de projet. CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

3 Sommaire 1 - OBJET ET DOMAINE D'APPLICATION DOCUMENTS DE RÉFÉRENCE ABRÉVIATIONS ET TERMINOLOGIE DESCRIPTION DES ÉTAPES (SYNOPTIQUE) ENREGISTREMENTS QUALITÉ (ERQ) ANNEXE : GÉNÉRALITÉS SUR LE DÉVELOPPEMENT AVEC PROGICIEL Projet d'entreprise et amélioration des processus Analyse des coûts Organisation du projet Gestion de la documentation du projet...20 CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

4 1 - OBJET ET DOMAINE D'APPLICATION La phase de DEVELOPPEMENT-PROGICIEL s applique lors de développements basés sur l'acquisition d'un progiciel de gestion intégré (PGI), avec, le cas échéant, réalisation d adaptations spécifiques qui doivent rester limitées. Elle concerne les activités de choix d'un progiciel, paramétrage et adaptation, mise en œuvre de l application et de ses éléments d accompagnement. Elle se termine lorsque le produit est installé et opérationnel sur les sites des utilisateurs. Ces activités sont mises en œuvre lors du développement initial d un système d information puis certaines, à chaque itération de développement d une nouvelle version en phase de MAINTENANCE/EVOLUTION. version DEFINITION DEVELOPPEMENT PROGICIEL MAINTENANCE / EVOLUTION EXPLOITATION / UTILISATION Le développement avec un progiciel doit faire l'objet d'un véritable projet : il ne faut pas se laisser piéger 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'expérience, notamment pour les progiciels RH, la comptabilité : règles communes, paramétrage, actions d'accompagnement... Ces échanges se font naturellement dans les clubs d'utilisateurs. Le CIGREF permet également aux grandes entreprises de rapprocher leurs expériences. Le développement se déroule de manière ordonnée au cours de cinq étapes : choix de progiciel, étude de distance, réalisation (paramétrage et adaptations), conduite du changement et mise en œuvre. Dans le cas d un système de taille importante, les étapes peuvent être suivies de manière linéaire globale pour le système dans son ensemble ou, de préférence, de manière incrémentale, en décomposant le système en plusieurs ensembles successifs et complémentaires. Généralement le découpage s'effectue en fonction des domaines fonctionnels à couvrir par le système. Le premier domaine pilote doit être "encapsulable" en cas de problème ou de retour en arrière. Cette démarche permet de développer des ensembles plus légers et de les mettre à disposition des utilisateurs de manière échelonnée dans le temps. Une fois le choix du progiciel effectué, les étapes suivies restent les mêmes dans les deux cas. CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

5 Développement progiciel global Choix progiciel Etude de distance Réalisation Conduite du changement Mise en oeuvre logiciel complet Développement progiciel incrémental Choix progiciel Etude de distance Réalisation Conduite du changement Mise en oeuvre domaine 1 Etude de distance Réalisation Conduite du changement Mise en oeuvre domaine DOCUMENTS DE RÉFÉRENCE CIGREF : "Progiciels" - septembre 1996 CIGREF : "Retours d'expérience ERP" - septembre 1999 Schéma stratégique des systèmes d'information et des télécommunications du ministère de l'éducation nationale et du ministère de la recherche - avril 2000 Dossier spécial ERP : L&S 46 Joseph Gabay, Berhanou Gébré : "La conduite des projets d'évolution des systèmes d'information" - InterEditions 1999 Actes de la conférence du 20 juin 2000 à l'insa de Lyon : "Simplifier la mise en œuvre des ERP grâce aux outils de modélisation" Beaucoup de textes du document ont été repris quasiment mot à mot des documents du CIGREF. 3 - ABRÉVIATIONS ET TERMINOLOGIE BPR = Business Process Reengineering, reconfiguration des processus opérationnels. CIGREF = club informatique des grandes entreprises françaises. ERP = Enterprise Resources Planning, "sous-ensemble du système d'information capable de prendre en charge la gestion intégrale de l'entreprise, incluant la gestion comptable et financière, 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) Caractéristiques : gestion effective de plusieurs domaines de l'entreprise (collaboration des processus) référentiel unique de données adaptations rapides aux règles de fonctionnement uniformisation des IHM. CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

6 PGI = Progiciel de Gestion Intégré. "A tort considéré comme la traduction de ERP : rassemble l'ensemble des applicatifs intégrés de gestion couvrant les fonctions horizontales ou verticales (métiers) d'une entreprise. Or les ERP couvrent seulement les fonctions horizontales". (source : CIGREF) Progiciel = "ensemble cohérent et indépendant constitué de programmes, de services, de supports de manipulation ou d'informations (bordereaux, langages) et d'une documentation, conçu pour réaliser des traitements informatiques standards, dont la diffusion revêt un caractère commercial et qu'un usager peut utiliser de façon autonome après une mise en place et une formation limitée". (source : Journal Officiel 1980) 4 - DESCRIPTION DES ÉTAPES (SYNOPTIQUE) Deux démarches de développement sont possibles : la rédaction a priori d un cahier des charges complet sans connaître le progiciel, puis la comparaison avec les fonctionnalités du progiciel ; la rédaction du cahier des charges à partir des fonctionnalités du progiciel (avantage : plus rapide). Le risque possible est d'oublier les fonctionnalités nécessaires à l entreprise mais absentes dans le progiciel, et d'enlever une part du sens critique vis à vis du progiciel. La première démarche est développée ci-après, tout en privilégiant un cahier des charges "minimal", suffisant pour effectuer le bon choix de progiciel et apte à évoluer dans l'objectif d'amélioration des processus de l'entreprise. CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

7 Etape 1 définir 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 générale 7 préparer la réception Réalisation et Conduite du changement 11 réaliser les actions d'accompagnement (fonctionnel et organisationnel) 9 réaliser et tester le paramétrage 12 effectuer la réception interne 10 réaliser et tester les adaptations et compléments Mise en oeuvre et Conduite du changement 13 effectuer la réception externe sur sites pilotes 14 généraliser la diffusion CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

8 1. Définir le cahier des charges : Le "système cible" défini dans le cahier des charges ne doit pas être conçu comme une solution absolue non négociable, sinon le risque est de ne trouver aucun progiciel capable de répondre au cahier des charges. Les éléments du cahier des charges peuvent être pondérés en fonction des besoins des utilisateurs (fonctions jugées indispensables, souhaitables, facultatives, proscrites), ou de la politique générale d'acquisition de progiciels. Le cahier des charges est structuré en plusieurs parties. les besoins : le système cible est défini à partir des besoins des utilisateurs et pas à partir des fonctions d'une solution progiciel. Il est possible de décrire le présent et/ou le futur en tenant compte d'évolutions prévisibles ou souhaitables (mais il faut le préciser). Il ne faut pas nécessairement tout décrire, mais insister sur ce qui est critique ou mal connu. Il faut savoir se limiter à un certain niveau de détail (activités et non tâches élémentaires). Il ne faut pas modéliser les processus connus ou imposés (ex : comptabilité). La prise en compte de l'existant est toujours très importante : il s'agit de ne pas perdre la culture d'entreprise même si tout est loin d'être parfait. Il faut associer étroitement les utilisateurs directs et indirects à l'évolution de cet existant (leur prévoir un temps de disponibilité). Il faut également décrire les aléas, les événements qui perturbent le fonctionnement idéal de l'organisation. - les processus et procédures, - les règles de gestion, - les principes d'organisation (MOT), nombre d'utilisateurs, nombre de responsable des mises à jour, nombre de types de sites, - les données gérées (MCD, volumes traités, interfaçage, volumétrie et format des fichiers, entrées requises, sorties fournies, taille des bases...), - les interfaces : données échangées, fréquence des échanges, volume des données. La définition des interfaces est un choix de conception majeur pour le système d'information de l'entreprise. Les options sont à définir par l'entreprise et non par le fournisseur, les contraintes : - délai de mise en œuvre, - coûts de mise en œuvre (formation, maintenance, assistance, reprise des données, développement, documentation ), - contraintes techniques (compatibilité avec les autres logiciels, systèmes d'exploitation, langages et SGBD, matériels, intégration dans le SI existant, respect de normes internes, appartenance à une liste de produits homologués en interne, fonctionnement en réseau, architecture nécessaire, outils intégrés, intégration dans les systèmes de sécurité, existence des points de reprise en cas de dysfonctionnement, facilité d intégration dans le plan de sauvegarde et d archivage, robustesse du système en cas de défaillance d un sous-système, compatibilité avec les outils d administration, performance, etc ), - ergonomie : l'ergonomie des progiciels diffère souvent de l ergonomie standard des applications de l'entreprise, ce critère ne doit donc pas être trop détaillé. Il peut porter sur le style d'interface (graphique, Web ), le multi-fenêtrage, la possibilité de paramétrer les écrans ou les possibilités d'interrogation multi-critères de la base d'informations, des clauses contractuelles : délai entre la sortie d'une version par le fournisseur et son installation, récupération des sources (en cas de faillite ou abandon du produit) Le cahier des charges est validé formellement par les instances décisionnelles du projet. CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

9 2. Faire l'inventaire des progiciels (2) En parallèle, un inventaire des progiciels existants couvrant tout ou partie du domaine concerné et de leurs fournisseurs est réalisé. Une fois le cahier des charges établi, une première liste de progiciels correspondant "sur le papier" au cahier des charges (environ 6) est sélectionnée. 3. Consulter les fournisseurs Le dossier de consultation est envoyé aux fournisseurs de ces progiciels afin qu'ils explicitent de quelle manière le progiciel répond aux besoins, accompagné d'un questionnaire de prise d'informations concernant des aspects généraux : sur le fournisseur : capital social, groupe d'appartenance, chiffre d affaire, bénéfice, effectif, pourcentage de vente de progiciels sur l activité totale, sur les produits proposés : nom, gamme des produits du fournisseur, taille des équipes de développement et de support technique, versions, modalités de relation (partenariat, club d utilisateurs, etc. ), sur le progiciel: - définition de l offre commerciale, - date de conception, date de commercialisation, date de la dernière version, - nombre d'exemplaires vendus, nombre d utilisateurs en France, - délais de livraison de la version initial et des versions futures, - coûts, - support technique pour l installation, le suivi après installation, - maintenance : couverture, délai d'intervention, périodicité et modalités d'obtention d'une nouvelle version, - formation, - documentation, - environnement technique, - architecture des données et des objets (fichiers, bases de données, modèles conceptuels et physiques), - architecture des traitements et des fonctions (modèle de communication, interfaces, etc. ), - sécurité, - ergonomie, - temps de réponse, - évolutivité du progiciel, capacités de paramétrage du progiciel. A réception des offres des fournisseurs, l'analyse des offres est effectuée pour n'en retenir que Analyser les progiciels retenus Deux solutions peuvent être envisagées pour effectuer le choix : analyser de manière approfondie les 2 ou 3 progiciels retenus, retenir une seul progiciel et l'évaluer, si abandon considérer le prochain sur la liste. Evaluation des progiciels : Elle se fait de différentes manières : vérifier et interroger les références, étudier la documentation, voir fonctionner le progiciel (démonstration avec jeux d'essais du fournisseur, passage de jeux d'essais propres à l'entreprise), CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

10 faire des tests de performance, et comparer par rapport aux performances souhaitées, visiter des sites comparables : afin d'avoir un éclairage sur les difficultés, les moyens nécessaires, les coûts, les délais, la satisfaction des utilisateurs, la qualité de la relation avec le fournisseur, mener une étude de dimensionnement pour le matériel. Les éditeurs sont généralement en partenariat avec des fournisseurs, faire fonctionner le progiciel sur le site de l'entreprise (expérimentations de prototypes intégrant tout ou partie des paramètres propres), avec pour objectifs : - validation des processus essentiels du point de vue "métier", - validation des processus posant le plus de difficultés de faisabilité, - compatibilité technique, - précision des développements complémentaires, - évaluation ergonomique (plus riche que les démonstrations), - présentations aux futurs utilisateurs. Le prototypage aide à la compréhension des besoins et garantit l adéquation de la conception aux besoins. Il permet d acquérir 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 définition et la séquence des tâches de prototypage doivent refléter la logique de paramétrage du progiciel, sur un sous-ensemble représentatif de cas, par exemple : les 20% de cas qui couvrent 80% des volumes, les 20% de cas les plus complexes pour lesquels il faut vérifier la faisabilité. Une formation au progiciel (complète 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 décision d'implémenter le progiciel. Les résultats de cette étude peuvent être utilisées ensuite au cours des premières phases de l'implémentation. L'étude est menée par des consultants, en relation directe avec les dirigeants et les personnes clés des services utilisateurs et informatiques. Le résultat de l'analyse est présenté dans un document détaillant les points suivants : stratégie de mise en œuvre, environnement technique, périmètre préliminaire de la mise en œuvre, fonctions et processus à mettre en place, périmètre organisationnel, durée du projet, organisation du projet, estimation des coûts, résultats attendus et retours pour l'entreprise, écarts fonctionnels entre le progiciel et les besoins, solutions possibles pour réduire de tels écarts, conditions préalables à remplir par l'entreprise, résultats de l'analyse des risques. Notation des progiciels : Chaque progiciel doit être noté sur la base de critères pondérés, en utilisant une grille d évaluation comme outil de réflexion et de mise en lumière des différences et des points importants. Une analyse de sensibilité des critères au choix final peut être effectuée en faisant CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

11 évoluer les pondérations des différents critères, notamment en isolant les critères principaux des critères secondaires. Quelques critères : références, expérience, pérennité, solidité de la société, couverture fonctionnelle et adéquation de celle-ci aux besoins (fonctions, données, règles de gestion). Pour chaque besoin non couvert par le progiciel, il faut vérifier la pertinence du besoin, s'il y a un paramétrage ou une adaptation spécifique possible, s'il existe une solution organisationnelle ou d'utilisation d'un autre produit, couverture organisationnelle (possibilités d'utilisation, types d'utilisateurs), flexibilité (capacité du progiciel à s adapter à différentes organisations) : dépend de son architecture technique et fonctionnelle. Un progiciel très flexible et très adaptable requiert de ce fait même un travail plus long de paramétrage et d adaptation. Un progiciel peu flexible peut conduire l'entreprise à s adapter aux contraintes pour éviter des adaptations trop coûteuses, compatibilité technique avec les choix de l'organisme. La non conformité technique par rapport aux standards de l'organisme a un coût à chiffrer et à mettre en balance avec les points forts du progiciel (périmètre fonctionnel mieux couvert). Si une technique non standard est acceptée, il faudra veiller au support et à la formation des équipes internes (équipes d'exploitation et éventuellement équipes de maintenance), intégration du progiciel dans l architecture fonctionnelle et technique du système d'information (interfaces) cf développé ci-dessous : intégration à l'existant, délais et coûts 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, démarche de mise en œuvre cf développé ci-dessous : préparation de la maintenance, facilités d'évolution : rythme des versions, acquisition de nouveaux modules, portabilité Se méfier des progiciels non totalement opérationnels et à finaliser. Intégration à l'existant : Les coûts et les contraintes d intégration représentent un critère de choix important dans la démarche de recherche de progiciel. L'intégration au système d'information existant entraîne une analyse complexe trop souvent sous estimée. La difficulté réside dans l intégration des bases de données du progiciel dans l'ensemble des bases de données de référence de l'entreprise, surtout si le progiciel doit dialoguer de manière très étroite avec des bases de données existantes n'ayant pas du tout la même structure que les bases de données du progiciel. Les risques (de surcoût, de dérapage de planning, de manque d évolutivité, de dysfonctionnements, etc.) seront d autant plus élevés que le progiciel s'appuiera sur des référentiels de l entreprise. Ils seront diminués si le progiciel a une approche de l interface sous forme de services. L analyste intégrateur devra se poser les questions suivantes : - comment échanger des données entre le nouveau progiciel et les systèmes d information existants? - quels sont les fichiers et les messages qu il faut échanger entre progiciels et systèmes existants? - quelles sont les données conceptuellement partagées par le progiciel et les systèmes existants? - quelles sont les données partagées physiquement? - dans quels fichiers et quelles bases de données se trouvent-ils? - quand il y a redondance d information physique, faut-il laisser cette redondance, et assurer un rapprochement instantané ou différé, ou garder une seule source, et modifier le progiciel ou le système existant en conséquence? Ce choix dépend largement du caractère critique des redondances (est-il dangereux de les laisser exister? combien de CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

12 temps 2 bases de données peuvent-elles rester désynchronisées?) et de l architecture des systèmes d information concernés (progiciel et existant peuvent-ils facilement partager des fichiers qui ont une structure différente et peut-être aussi une méthode d accès ou un SGBD différent?), - dans un environnement décentralisé, faut-il garder une base de données sur le site central? Quel sera le système maître? - quelle sera la fréquence de transmission des données entre les 2 bases? Le choix doit être fait d'une fréquence adaptée au besoin de l'utilisateur. Ce n'est pas nécessairement le temps réel. Bien souvent une transmission asynchrone est suffisante. L'intégration peut entraîner des adaptations coûteuses du progiciel. Le degré d'ouverture du progiciel est un critère de choix important : - il réside tout d'abord dans le type de liaison entre applications prévu par l'éditeur : interfaces standards (Edifact...) ou non standards, - il réside également dans la liberté à accéder aux données du progiciel avec des outils standards du marché. Certains progiciels, en effet, n'acceptent que des requêtes propriétaires. Préparation de la maintenance : Il est préférable de négocier les conditions de maintenance en même temps que l achat du progiciel. L'entreprise doit décider des modalités de maintenance du progiciel, de ses extensions (interfaces spécifiques) et des paramètres qui peuvent être gérés différemment : maintenance et optimisation du produit complètement assurées par l'entreprise, donc connaissance du "noyau" dur progiciel souvent considéré comme "boite noire", avec ses mécanismes généraux et les techniques utilisées pour les points d entrée/sortie, maintenance effectuée par l équipe de l'entreprise, avec l aide éventuelle d experts du fournisseur pour des opérations complexes, maintenance sous-traitée. La maintenance doit gérer 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 intégration dans les versions définitives. On veillera également à la compatibilité ascendante des différentes versions et à la pérennité des interfaces et des développements spécifiques. Il est important de définir le mode de diffusion des versions par le fournisseur dès le stade contractuel (documentation, fréquence, support). Le contrat peut préciser un délai 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 fonctionnalités ne subissent pas de régression. Chaque changement de version doit être accompagné d'un document de l'éditeur recensant les différences de fonctionnalités ou les corrections de dysfonctionnements entre la version nouvelle et l'ancienne. Une version majeure (en terme de conséquence sur les fonctionnalités, de changement d environnement technique) devra être traitée comme un projet de manière à ne pas oublier les impacts sur les interfaces ou sur les fonctionnalités offertes aux utilisateurs. Cela peut être l'occasion à l'issue de l'étude de prendre éventuellement la décision de ne pas migrer. L'entreprise ne doit pas en effet se sentir obligé de changer de version aussi fréquemment que le propose l éditeur. Les risques inhérents à une version majeure doivent être mesurés et mis en balance avec les gains pour l'entreprise. L'entreprise doit rester maître des changements de versions. CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

13 Il est risqué de sauter la mise en œuvre de plusieurs versions d un progiciel, pour plusieurs raisons, notamment les problèmes de compatibilité avec les versions antérieures et la compétence des équipes de support. La qualité du support assuré par le fournisseur est essentielle dans ce type de manipulation. Elle est à intégrer dans les critères 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 décision sur le choix du progiciel. Le contrat est finalisé avec le fournisseur et signé. 5. Prendre en mains le progiciel Avant de définir les options de paramétrage et les adaptations complémentaires à apporter, il est nécessaire d'avoir une connaissance approfondie des possibilités du progiciel. Des formations de l'équipe projet sont organisées et le progiciel est installé dans l'environnement cible. Les environnements (développement-exploitation) sont organisés, serveurs et postes clients. Les principes de gestion de la documentation technique et du paramétrage à usage des utilisateurs doivent être définis. 6. Mener la conception générale Dans cette phase, la démarche globale de mise en œuvre du progiciel est définie : périmètre du projet, personnalisations, planning, scénarios de démarrage. Dès cette phase, il faut s'attacher à favoriser l'adhésion et l'implication des utilisateurs, mobiliser les compétences adaptées au moment voulu. Définition du périmètre : Le périmètre du projet est défini : identification des domaines fonctionnels concernés par la version initiale et leur intégration dans le système d'information existant : le champ d'application du progiciel est réduit pour l'adapter aux processus de gestion spécifiques de l'entreprise. Ceux-ci sont reconfigurés si besoin est (Business Process Reegineering). Les processus sont documentés (modèle conceptuel), le point fondamental de l intégration fonctionnelle est certainement l harmonisation des données et des services communs de l'entreprise. Il ne faut pas hésiter à demander le MCD du progiciel ou à le reconstruire. Il est nécessaire d'étudier rapidement les adaptations nécessaires par rapport aux applications en interface. Personnalisations : Les personnalisations sont identifiées de manière globale. La spécification du paramétrage et des adaptations/compléments est conduite de manière itérative pour obtenir un scénario 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 paramétrage et de mise en œuvre induite. Planification et scénario de démarrage : La planification et les estimations de charges sont précisées. Des jalons de contrôle des objectifs, des budgets et des délais sont positionnés. Des lots sont définis. Le scénario de démarrage est défini. CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

14 Une réunion de lancement en présence des instances décisionnelles entérine les choix effectués en conception générale. 7. Préparer la réception Non détaillé. 8. Concevoir l accompagnement du changement Non détaillé. 9. Réaliser et tester le paramétrage Chacun des lots identifiés en phase précédente est détaillé : personnalisation du dictionnaire des données, maquettes des écrans, règles de gestion, description des différentes fonctionnalités dans le progiciel Les charges sont confirmées. Il faut s orienter vers une approche «maximum de paramétrage/minimum d adaptation». Au départ, il y a un paramétrage de base, qui va concerner par exemple 80% des transactions courantes. Puis sont traités ensuite les 20% restants des processus de gestion, les exceptions. Il faut être vigilant sur les choix structurants de paramétrage : suivre la démarche préconisée par le fournisseur, lui demander des informations, échanger des expériences entre entreprises. Il est important de prendre le temps de prototyper les différentes possibilités de paramétrage pour choisir la meilleure et d'impliquer très tôt les utilisateurs. La confrontation entre les besoins exprimés et les possibilités du progiciel ne peut être effectuée qu avec l aide d experts du progiciel, collaborant de façon étroite avec l équipe projet sur les points délicats d adéquation fonctionnelle. La gestion des écarts doit tenir compte du coût de la solution mais aussi de la complexité engendrée lors d une évolution ou d un changement de version. Le paramétrage du progiciel comprend : le rapprochement des caractéristiques du progiciel avec le cahier des charges initial, et la mise à jour du schéma général de fonctionnement du progiciel : - processus couverts et non couverts, - répartition des processus en modules du progiciel (module principal, secondaire, traitement manuel), échanges inter-modules (interfaces), identification des interdépendances entre le progiciel et le système d'information cible, - le paramétrage du progiciel doit suivre un ordre logique, calé en principe sur la définition des tables de paramétrages de leurs dépendances et les instructions données par l'éditeur, la définition pour chaque module du progiciel : - des procédures requises pour mettre en place les valeurs initiales des paramètres et des tables, - des procédures pour modifier ces valeurs initiales, - des possibilités de personnalisation des interfaces et des formats d édition. Un dossier de paramétrage du progiciel est élaboré : tous les changements ou ajouts au système sont documentés. CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

15 Un prototype est réalisé pour servir de base à des tests de performance et des expérimentations avec les utilisateurs. La démarche est incrémentale. 10. Réaliser et tester les adaptations et compléments Cette étape se déroule le plus tard possible dans le développement, après avoir examiné toutes les possibilités de paramétrage. Il faut impliquer en priorité les compétences du fournisseur "expert progiciel" pour trouver des solutions d'adaptations et extensions dans le produit. A défaut, il faut envisager de traiter le problème dans une autre application ou ne prendre la décision d adapter le progiciel qu en toute dernière extrémité, après avoir évalué l impact du développement par rapport à toute autre solution. Si le paramétrage ne suffit pas pour répondre au besoin de l utilisateur, il faut réétudier le besoin avec l'utilisateur pour essayer de revoir les règles de gestion afin d'éviter les adaptations. Les coûts éventuels liés aux modifications des règles de gestion sont à mettre en balance avec les risques des éventuelles adaptations du progiciel. Il appartiendra aux utilisateurs de rédiger des argumentaires qui seront arbitrés à haut niveau. Pour restreindre les développements spécifiques, faire en sorte que la décision d'allouer des budgets soit prise à très 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 représentent un facteur de risque pour l'intégration : divergence dans le planning initial, non adéquation aux besoins, non fiabilité du progiciel, gestion des nouvelles versions, qualité de la hot line, formation spécifique des utilisateurs... Donc : documenter très précisément 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 démarche de projet standard, spécifier selon les règles de l'art, prototyper les fonctionnalités spécifiques. Le prototype est réalisé pour servir de base à des tests de performance et des expérimentations avec les utilisateurs. La démarche est incrémentale. Au niveau fonctionnel, plusieurs solutions sont envisageables : examiner si une solution organisationnelle conviendrait, utiliser un produit complémentaire, ajouter de nouvelles fonctions, spécifiques à l'entreprise et prises en charge par celui-ci ou par le fournisseur, devenant des nouvelles fonctions du progiciel ou des développements spécifiques, modifier le progiciel, modifier les systèmes existants pour les adapter au progiciel. Au niveau technique, l intégration nécessite aussi souvent quelques modifications du progiciel pour le rendre le plus proche possible des normes d'exploitation de l'entreprise. De plus, il est nécessaire de spécifier les exigences relatives à la sécurité (disponibilité, habilitations, plan de secours). Par contre, des programmes spécifiques sont généralement nécessaires pour les interfaces. CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

16 S il s agit de la migration d un ancien vers un nouveau système, la reprise des données est également spécifiée et développée. Un avantage du progiciel réside dans les outils souvent proposés par le fournisseur pour la reprise des données des anciens systèmes. Ces deux types de développement s'effectuent par contre plus tôt dans le développement. Les tests s'effectuent durant toute la phase, tests de volumétrie et de montée en charge, tests d'intégration pour la reprise des données et les interfaces. 11. Effectuer la réception interne Non détaillé. La recette est généralement plus courte que pour des logiciels spécifiques. Elle est centrée sur les problématiques d'intégration des modules. 12. Réaliser les actions d accompagnement (fonctionnel et organisationnel) Non détaillé. Des formations propres à chaque fonction sont organisées. Il est préférable que les utilisateurs soient formés par des utilisateurs expérimentés de l'organisme (d'où l'organisation préalable de formation de formateurs). 13. Effectuer la réception externe sur sites pilotes Non détaillée Le passage sur sites pilotes permet d expérimenter le système informatique en environnement réel ou quasi-réel d utilisation. L objectif est de s assurer que le système fonctionne de manière opérationnelle et satisfait les utilisateurs. C est une activité incontournable dans le cas d un nouveau progiciel. Les sites pilotes peuvent faire coexister l'ancien système et le nouveau système si c'est possible. Pour les applications stratégiques, il est essentiel de prévoir un fonctionnement en double des 2 systèmes (ancien et nouveau). Toutefois, certaines entreprises excluent la marche en double pour les raisons suivantes : cette démarche représente une charge de travail importante pour les utilisateurs comme pour l'équipe projet ; il est difficile d'imputer les différences soit à des erreurs du nouveau système, soit à des erreurs de l'ancien, soit tout simplement à une façon différente de gérer et de calculer ; dans tous ces cas, la recherche des différences peut aboutir à des charges de travail excessives, des impasses ou des erreurs de jugement ; la charge de travail doit être concentrée sur la mise en oeuvre de la nouvelle solution, le temps passé sur l'ancien système étant réduit au maximum. Généralement, il y a peu d'anomalies détectées mais plutôt des erreurs fonctionnelles. Après correction, il y a généralement peu d'effets de bord, donc peu d'allers-retours nécessaires. Le bilan des sites pilotes est présenté aux instances décisionnelles du projet qui donnent leur avis sur l opportunité de généraliser et la suite à donner aux différents retours obtenus des sites pilotes. CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

17 14. Généraliser la diffusion Non détaillé. Les utilisateurs sont formés à l utilisation de la nouvelle application. Le système informatique est diffusé sur la totalité ou une partie des sites : installation, reprise des données éventuelle, démarrage de l exploitation. Une période de fonctionnement en double entre l ancien et le nouveau système peut être prévue. A la fin de la mise en œuvre, s'effectue le transfert de compétences de l'équipe projet externe vers l'équipe projet interne (utilisateurs et informaticiens). Attention à la perte importante de savoir-faire lors du transfert de compétences au démarrage de la solution. Les inquiétudes en phase de maintenance sont généralement de : assurer la bonne appropriation par les utilisateurs, maintenir la cohérence de la solution initiale, conserver les compétences internes. 5 - ENREGISTREMENTS QUALITÉ (ERQ) Nom de l ERQ Identification du QFE Modalités d identification de l ERQ Durée de conservation Lieu d Archivage Responsable Modalités d élimination QFE : formulaire d enregistrement Qualité 6 - ANNEXE : GÉNÉRALITÉS SUR LE DÉVELOPPEMENT AVEC PROGICIEL 6.1 Projet d'entreprise et amélioration des processus L'utilisation d'un progiciel intégré est un projet d'entreprise nécessitant une implication de la direction générale et une démarche d'accompagnement du changement. Décider 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 spécifications et habitudes des utilisateurs. La mise en place d'un progiciel doit être considérée comme une opportunité pour reconfigurer les processus (Business Process Reengineering). La première étape du développement doit donc être une remise en question des aspects organisationnels clés de la productivité et de l'efficacité de l'entreprise. Adopter un progiciel c'est s'adapter! Cette caractéristique génère par contre un des risques liés à l'emploi de progiciels : l'uniformité pourrait empêcher à l'entreprise d'évoluer tant au plan fonctionnel qu'organisationnel, entraîner une désaffection des informaticiens, voire des utilisateurs qui s'en remettent à une pensée extérieure. Généralement, pour réaliser cette étape, des techniques de modélisation des processus sont utilisées. Les techniques de modélisation utilisent des méthodes descriptives et des outils informatisés qui visent à fournir une aide à la conception, l'analyse et l'optimisation d'organisations. Toutes les méthodes placent la notion de processus opérationnel (business CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

18 process) au cœur de leur démarche, les outils incluant généralement 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 dès le début du projet. La communication doit comporter entres autres les raisons du choix d'un progiciel plutôt qu'une solution interne. Une attention particulière doit être portée aux actions de communication car le changement demandé aux utilisateurs est généralement plus important dans le cadre d un progiciel. Par contre, on constate que le niveau d adhésion des utilisateurs est souvent supérieur avec des progiciels qu avec des développements spécifiques (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 coûts L'analyse des coûts doit prendre en compte tous les coûts d installation et d exploitation, notamment : - coût d'établissement d'un bon contrat, - achat des licences (seulement en moyenne 20% des dépenses), - achats d équipements, matériels, - frais d installation (dont paramétrage, prototypage, sélection des produits ), - formation des informaticiens et des utilisateurs, - maintenance et support fonctionnel et technique, - exploitation et support système, en particulier surcoûts si le progiciel impose des progiciels de base (exemple : un SGBD) que l entreprise n utilisait pas auparavant, - développements spécifiques et interfaces, - coûts de conversion de l ancien au nouveau système, - maintenance de ces développements. Eléments de coûts élaborés par rapport à l'erp de SAP (cabinet Forrester) : "le coût d'acquisition se trouve entre 50 et 150 kf par utilisateur (matériels, logiciels, services). L'externalisation de la maintenance, des travaux liés à l'évolution, à l'euro, la montée de version, l'optimisation : une prise en charge qui correspond à 3 mois, en moyenne, revient à 5 à 10% du coût d'acquisition. Ensuite, en service continu, cela représente 15 à 20% du coût d'acquisition. Une montée de version, c'est également 15 à 20% du coût d'acquisition ou en fonction du nombre de développements spécifiques requis. Le coût d'optimisation peut, pour sa part, atteindre 20% du prix d'acquisition." 6.3 Organisation du projet La structure d une équipe de projet "progiciel" n a pas de caractéristiques particulières sauf que l accompagnement d experts du fournisseur, tant dans le domaine fonctionnel que technique, est indispensable. Relations maîtrise d'oeuvre/maîtrise d'ouvrage : Il n'y a pas de raison majeure pour que la mise en oeuvre d'un progiciel change significativement la relation maîtrise d'oeuvre/maîtrise d'ouvrage. Toutefois, les équipes informatiques doivent gérer la relation avec les divers sous-traitants (fournisseurs de progiciels, SSII, etc.. ), qui devient prépondérante. Ces équipes tiennent alors le rôle de conseil au maître d'ouvrage ou de maître d'oeuvre délégué, en plus de leur fonction de maître d'oeuvre principal. CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

19 La direction des projets ERP est souvent confiée aux équipes de maîtrise d'ouvrage (un tiers seulement aux DSI). Le rôle du service informatique se limite parfois à celui de garant du paramétrage et des mises à jour. Le directeur de projet coordonne la maîtrise d'ouvrage et la maîtrise d'œuvre. Il est souvent assisté de chefs de projets, chargés entres autres : de l'accompagnement du changement, de la conception et du développement des interfaces. Qui dit intégration, dit coordination de plusieurs interlocuteurs, responsables des autres applications. Organisation du maître d'oeuvre : équipe mixte entreprise/fournisseur, dont l avantage réside dans une grande osmose d expériences et la rapidité du paramétrage mais accroît la complexité de l encadrement, équipe de l'entreprise accompagnée d experts 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-traitée ou avec un transfert de connaissance très difficile à l issue du paramétrage. Les ERP nécessitent une évolution des profils et compétences : formation, réaffectations Il est en effet nécessaire d évaluer quel doit être le niveau d expérience des informaticiens. En fonction de l importance que revêt le système d information, il conviendra de décider s il faut former les informaticiens au paramétrage, aux fonctions externes, à l architecture interne du progiciel, et s ils doivent devenir des spécialistes de son emploi ou de sa programmation. Le temps passé en analyse, programmation et tests d un logiciel spécifique leur permet en effet de capitaliser une expérience qui peut s avérer précieuse pour l'entreprise ou, au contraire, les détourner d activités à plus forte valeur ajoutée. Organisation du maître 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 tâches de réalisations, d encadrement et des responsabilités sont à définir dans un contrat. Deux types d intervention sont à prévoir : réalisations pour lesquelles le fournisseur assure la maîtrise d oeuvre, avec un suivi par un responsable de l'entreprise, assistance du fournisseur sur les tâches dont l'entreprise assure la maîtrise d oeuvre. Dans ce cas, la mission du fournisseur consiste à assurer le contrôle qualité et le contrôle de la bonne utilisation technique du produit. La maîtrise d ouvrage assure la responsabilité du pilotage de la conduite du changement qui doit être mise en oeuvre dès le début du projet. Ceci nécessite une bonne connaissance des concepts du progiciel, donc une formation particulière dès le démarrage. En effet les progiciels ont certaines particularités : existence d un processus optimal du mode de fonctionnement, existence de plusieurs solutions techniques pour un pilotage satisfaisant d un processus. Participation des utilisateurs : Il est indispensable de constituer un équipe mixte informaticiens/utilisateurs et de leur apporter une formation initiale commune dès l acquisition du progiciel. Centre de compétences ERP : Il est important de constituer un centre de compétences ERP. Ce centre de compétences s'appuie sur des ressources expertes de l'éditeur ou de la société de services, de la DSI, de représentants de la maîtrise d'ouvrage. Ses missions sont de : capitaliser les compétences acquises au niveau technique, apporter une assistance en gestion et animation des équipes projets, CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20

20 tenir un rôle opérationnel dans les projets (intégration fonctionnelle, gestion documentaire, planning de déploiement, origine de la méthodologie et du vocabulaire commun aux projets, formation), faire de la veille technologique et fonctionnelle (étude des progiciels du marché, des logiciels développés par les autres organismes et les progiciels que ceux-ci utilisent). Le fournisseur : Il faut s assurer que les experts du fournisseur ont une expérience effective du produit et reçoivent un support efficace des équipes de développement et de support technicocommercial. L'entreprise se doit d être exigeante sur le profil du chef de projet fournisseur : il sera expérimenté, aura implanté ce progiciel dans plusieurs sociétés. On peut recommander d évaluer précisément l expérience réelle et la compétence des différents intervenants. Le fournisseur est souvent un intégrateur (société 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 diffusés, des SSII offrent des prestations analogues. L'entreprise doit penser à la formation initiale et à la formation récurrente des utilisateurs. Elle peut donc être conduite à constituer un groupe de formateurs connaissant le progiciel une fois adapté à l'entreprise. L'équipe projet est formée pendant le développement, en plusieurs fois pour les différents niveaux de formation prévus. Paramétrage et adaptations : De même, le paramétrage est une prestation habituelle de l'éditeur. Des SSII peuvent avoir cette expérience et sont parfois plus compétentes. Certaines entreprises peuvent avoir intérêt à disposer de spécialistes internes pour le paramétrage initial et ses évolutions. Plusieurs entreprises conseillent de confier les développements spécifiques à une SSII plutôt qu à l éditeur du progiciel. Cet intégrateur apporte la plupart du temps sa méthode de développement associé au progiciel. 6.4 Gestion de la documentation du projet La documentation habituelle doit être complétée des informations suivantes : paramètres utilisés, valeurs et signification fonctionnelle ou technique, interfaces avec les autres systèmes d information, compléments et modifications apportés au progiciel. La documentation sur le paramétrage doit être effectuée tout au long du projet et d une manière très rigoureuse. Il faut définir dès le début un projet «documentation» : organisation et support de la documentation technique, organisation et support de la documentation du paramétrage à usage des utilisateurs. CNRS/DSI/conduite-projet/developpement/proc-developpement-PGI 11 avril / 20