Livre Blanc SAP au sein du Service Public

Livre Blanc SAP au sein du Service Public

Livre Blanc SAP au sein du Service Public

Date de création : 31/12/2013

Catégorie(s) :
Livres Blancs

Dernière version : 16/02/2016 15h12

Accès au document réservé aux membres de la commission.
Connectez-vous !

Retours d'expérience, guide pratique et facteurs clés de succès Les dix bonnes pratiques clés pour réussir un projet SAP dans le secteur public 1 • PGI et secteur public ne sont pas incompatibles Même s'il reste encore plusieurs points d'amélioration, un Progiciel de Gestion Intégré (PGI, ERP en anglais) comme SAP sait clairement répondre à une bonne partie des problématiques du secteur public. Le nombre d'implémentations réussies de SAP au sein du secteur public, tant français que dans le monde, est là pour le démontrer. Si un travail d'harmonisation des processus est effectué et que l'organisation essaie de respecter autant que possible le standard de SAP, alors les projets deviennent plus aisément réalisables, SAP intégrant depuis de nombreuses années de plus en plus de bonnes pratiques du secteur public. SAP peut même être déployé en environnement Open Source, mais il faut toutefois être conscient que cela nécessite alors un investissement supplémentaire de la part de l'organisation qui ferait un tel choix (ne pas confondre Open Source et gratuité). 2 • Un sponsor au plus haut niveau La mise en place d'un progiciel de gestion intégré est un choix très structurant pour une organisation, qui nécessite une réflexion stratégique au plus haut niveau de gouvernance. Le projet doit donc être soutenu par les plus hautes instances de décision de l'organisation publique concernée, y compris, si nécessaire, par le niveau politique. 3 • Un projet SAP n'est pas un projet informatique : c'est un projet d'organisation La mise en place de SAP et, plus globalement, de tout PGI, est d'abord et avant tout une problématique organisationnelle. Un tel projet ne doit surtout pas être abordé comme un projet informatique. Rentrer dans la logique d'un PGI comme SAP impose une réflexion approfondie sur les processus existants et leur réingénierie afin de bénéficier réellement des bonnes pratiques et des gains apportés par une telle solution. Des changements dans l'organisation, parfois de la réglementation, sont nécessaires pour bénéficier de la valeur ajoutée apportée par SAP. Refuser par avance tout changement de cet ordre conduit à multiplier les développements spécifiques, et par conséquent à perdre les avantages d'une solution intégrée comme SAP Si les aspects stratégiques de tels projets doivent être pensés par les sponsors, la maîtrise d'ouvrage doit être très étroitement associée en amont à cette réflexion organisationnelle. 4 • Bien réfléchir en amont avant de lancer l'appel d'offres La partie contractuelle est fondamentale, elle conditionne le bon déroulement du projet. De ce fait, le choix d'un PGI comme SAP doit être pensé très en amont. Un tel projet nécessite d'anticiper le plus possible les futurs besoins fonctionnels, mais aussi les transferts de compétences des intégrateurs vers les équipes internes à l'administration ou bien encore la phase d'exploitation, y compris la mise en place ou non, au moins dans les grandes lignes, d'un futur centre de compétences SAP. Tous ces éléments doivent être pris en compte ou au minimum avoir été cadrés et anticipés, dès le Cahier des Clauses Techniques Particulières (CCTP). En fait, cela revient à définir une véritable stratégie contractuelle, fort de tous ces éléments de réflexion. 5 • Mener une politique RH adaptée, aussi bien en amont qu'en aval du projet La mise en place de SAP nécessite des compétences spécifiques, aussi bien fonctionnelles que techniques, que ce soit pendant le projet ou en phase d'exploitation. En interne, il est essentiel de trouver (ou de recruter, si cela est possible) les bons profils et de les fidéliser, un enjeu sans aucun doute plus complexe au sein du secteur public. En outre, il faut anticiper les transferts de compétences afin de disposer de ressources suffisantes au moment adéquat. Les organisations peuvent également avoir besoin de faire appel à des compétences externes sur certains sujets qui nécessitent une expertise complémentaire de celle de l'intégrateur principal : conseil proposé par l'éditeur, consultants indépendants, etc. Ces besoins doivent être anticipés et budgétés. 6 • Une direction de projet interne pour piloter la relation avec les intégrateurs Le projet doit impérativement rester sous le contrôle de l'organisation publique, il ne faut pas s'en remettre aveuglément, et sans contrôle, aux intégrateurs. Une organisation projet doit être ainsi mise en place dès le début du projet pour suivre et pour réellement piloter le déroulement du projet SAP. Cette organisation doit être, soit rattachée et pilotée par la maîtrise d'ouvrage, soit au minimum, y associer très étroitement cette maîtrise d'ouvrage. L'organisation publique doit être capable de comprendre, dans le détail, le travail et les choix des intégrateurs, par exemple pour les paramétrages effectués. Pour cela, soit elle dispose de ressources compétentes en interne, soit elle peut faire appel à une expertise externe tierce (éditeur SAP lui-même, assistance à maîtrise d'ouvrage, consultants indépendants spécialisés...). La meilleure option est de prévoir une enveloppe contractuelle autonome, indépendante de l'intégrateur, voire de séparer les marchés publics entre un marché éditeur (incluant ce type de prestation) et un marché intégrateur. En particulier, les développements spécifiques proposés par les intégrateurs devront être particulièrement contrôlés et soumis à l'acceptation éclairée et formelle de la direction de projet interne (sujet à anticiper dès le CCTP). 7 • Prendre en compte autant que possible le coût complet et comparer ce qui est comparable Il est important de prendre en compte, autant que possible, le coût complet de la mise en place de SAP, c'est-à-dire, au minimum, à la fois les coûts d'investissement et les coûts d'exploitation, même si certains coûts sont difficilement chiffrables, par exemple, la valorisation du temps passé sur le projet par les maîtrises d'ouvrage. Ces coûts doivent toutefois être mis en perspective à la fois avec d'autres projets qui impactent moins ou peu l'organisation et avec des applications anciennes que SAP vient généralement remplacer. Il ne faut jamais perdre de vue que la mise en place d'un PGI comme SAP est avant tout un projet organisationnel. L'erreur serait donc de le comparer avec des projets purement informatiques. 8 • Le retour sur investissement d'un projet SAP ne doit pas se limiter aux seuls aspects financiers L'analyse de la valeur, du Retour sur Investissement (RSI ou ROI en anglais) n'est plus un sujet tabou dans le secteur public. Dans le secteur public, la mise en place d'un PGI est presque toujours associée à deux types de gains : une hausse de la productivité grâce à l'automatisation et à l'optimisation des processus, ainsi qu'une transparence accrue grâce à la traçabilité des différentes actions effectuées dans le PGI. Il existe néanmoins une fourchette de bénéfices potentiels bien plus large, qui varie selon le type d'organisation (administrations centrales, collectivités locales, établissements publics...) et le contexte. Car dans le secteur public, sans doute plus qu'ailleurs, le retour sur investissement n'est pas uniquement à appréhender sous l'angle financier. La notion de service rendu, de productivité, d'efficience, de transparence et de traçabilité, de fluidité des processus, de qualité de la relation citoyen et des gains qualitatifs doivent donc également être pris en considération pour évaluer la valeur réelle de tels projets. 9 • Bien penser la conduite du changement La conduite du changement d'un projet PGI doit être vue comme un véritable « projet dans le projet », qui doit se préparer très en amont. La conduite du changement ne se limite surtout pas à la formation à l'outil, mais doit également inclure une formation aux nouveaux processus, une stratégie de communication adaptée tout au long du projet ainsi qu'une valorisation des personnels directement touchés par le projet. Même si la résistance au changement est davantage liée à la culture des pays qu'aux spécificités du secteur public par rapport au secteur privé, les organisations publiques présentent plusieurs facteurs spécifiques qui contribuent à rendre encore plus délicate cette gestion du changement. Lorsqu'un projet PGI connaît des difficultés, l'un des réflexes consiste à accuser l'outil, que les utilisateurs ne se seraient pas appropriés comme prévu, alors qu'en réalité, c'est bien souvent une gestion du changement déficiente qui est avant tout en cause. 10 • Communiquer et partager Particularité de certaines administrations, la communication reste parfois un tabou, notamment quand la mise en place de SAP a de fortes conséquences organisationnelles et donc potentiellement des impacts politiques et sociaux. Pourtant, il ne faut pas avoir peur de communiquer, en interne au sein de l'administration concernée aussi bien qu'en externe. Si on ne communique pas, d'autres le feront à notre place, et rarement en notre faveur. Une communication maîtrisée est très largement préférable. Les méthodes et les outils existent, ils sont suffisamment diversifiés pour s'adapter à chaque contexte. De nombreux exemples sont là pour le prouver. La communication permet en plus de valoriser les équipes chargées du projet. Par ailleurs, comme il existe plus d'une cinquantaine de références SAP au sein du secteur public français, les échanges, les partages et les retours d'expériences entre pairs sont irremplaçables et ont une grande valeur. Ils sont à développer très largement. Note : au fil des pages de ce livre blanc, vous trouverez des cas concrets d'acteurs du secteur public qui ont mis en oeuvre chacun de ces 10 points. CHAP 1 • La constitution des marchés et des appels d'offres Le découpage du marché - Faut-il découper le marché entre éditeur et intégrateur ? - Editeur ou intégrateur : principaux critères de choix - Quels lots faut-il prévoir ? L'élaboration de l'appel d'offres - Comment établir le périmètre du projet ? - Quel accompagnement ? - Comment élaborer le CCTP ? Les différents types de procédures - Le dialogue compétitif - L'accord-cadre mono titulaire La gestion des contentieux CHAP 2 • La gouvernance et l'organisation d'un projet SAP Les sponsors du projet - A quel niveau faire remonter la gouvernance ? - La gouvernance côté technique ou côté fonctionnel : où placer le curseur ? - Quelles spécificités pour le secteur public ? - Transversalité des projets PGI : comment affirmer la légitimité et l'autorité du sponsor ? Les instances de pilotage - Attention à la « comitologie » - Prise de décision : quel est le niveau le plus pertinent ? - L'importance du pilotage contractuel La gouvernance des ressources - Comment envisager l'après projet ? - Comment prévenir la fuite des compétences ? - La sous-traitance : un remède ? La gouvernance des processus et des données - Qui est propriétaire des processus ? - Qu'en est-il des données ? La gouvernance de la sécurité - Quand définir la politique de sécurité ? - « Trop de sécurité tue la sécurité » La gouvernance des tests et l'assurance qualité - Faut-il impliquer les utilisateurs dans la gestion des tests ? CHAP 3 • La conduite du changement Les sources de la résistance au changement Les spécificités du secteur public Les dix bonnes pratiques de la gestion du changement - Considérer la gestion du changement sur le long terme - Ne pas se limiter à la formation à l'outil - Associer des compétences techniques et fonctionnelles - Rechercher un appui de la direction générale - Veiller à la qualité des acteurs de la gestion du changement - Utiliser les techniques efficaces de communication - Intégrer toutes les facettes de la communication - Analyser les informations du terrain - Modéliser tous les processus - Mesurer le retour sur investissement CHAP 4 • Les modalités de travail avec l'éditeur et les intégrateurs Les relations avec l'éditeur Travailler avec plusieurs intégrateurs - Que faire quand plusieurs intégrateurs travaillent en même temps sur les applicatifs SAP ? - Comment répartir les rôles et les responsabilités entre les intégrateurs ? - Sous-traitance ou co-traitance ? - Que faire face aux sous-traitants faisant eux-mêmes appel à des sous-traitants ? La place des intégrateurs dans les instances de gouvernance - Gestion du suivi contractuel - Quel rôle pour les intégrateurs dans les comités de gouvernance ? - Quelle autonomie faut-il laisser à l'intégrateur ? Quels types de relations avec les intégrateurs ? - Anticiper le transfert de compétences - Faut-il privilégier une relation de type « partenaires » ou de type « client-fournisseur»? - Faut-il un comité d'arbitrage sur les développements spécifiques ? - Mieux encadrer les développements spécifiques CHAP 5 • SAP et l'Open Source, l'expérience de la Gendarmerie Nationale SAP sur le poste de travail - Une migration du poste client vers l'Open Source - SAP sur le poste client Open Source - Le portail web Java - Editions OpenOffice - Client lourd SAPGUII SAP JAVAGUI - En résumé SAP sur Linux CHAP 6 • SAP pour le secteur public SAP Business Suite pour le secteur public - Administration publique - Défense et sécurité publique - Enseignement supérieur et Recherche - Santé publique - Les nouveautés de la version 7 Zoom sur quelques fonctionnalités - Modules d'intégration - Processus unifiés - Procurement for Public Sector (PPS) - Financial Supply Chain Management (FSCM) - SAP Financial Closing cockpit - Master Data Management for Financials - Gestion des talents SAP et le secteur public français - Comment gérer la séparation de l'ordonnateur et du comptable ? - Les PGI sont-ils adaptés au secteur public ? CHAP 7 • La dématéralisation La dématérialisation dans le projet CHORUS - Le projet en bref - Les bénéfices de la dématérialisation - La démarche retenue - Quelques exemples - Les états de frais - Les pièces justificatives des marchés - Les cartes achats - La dématérialisation fiscale des factures fournisseurs - Les subventions - Une dynamique à créer La dématérialisation au Ministère de la Défense La dématérialisation à l'UGAP - Minimiser le taux de rejet L'initiative Peppol (Pan-European Public Procurement Online) La dématérialisation à la Ville de Paris - Dématérialisation : trois questions-clés Les différentes formes de dématérialisation proposées par SAP - Les flux EDI - La dématérialisation des flux papier - Le traitement des factures fournisseurs - Les formulaires interactifs En résumé... CHAP 8. La mise en place d'un centre de compétences et la tierce maintenance applicative Gérer la transition du mode projet vers le mode exploitation - A partir de quand le passage en mode exploitation est-il envisageable ? Mettre en place un centre de compétences - Comment dimensionner les effectifs du support ? - Quels profils choisir pour le centre de compétences ? page 93 - A qui rattacher le centre de compétences ? - Quels outils utiliser pour piloter un centre de compétences ? - Avec quels outils équiper les centres ? - Comment concilier des garanties fournies par des tiers avec le centre de compétences ? Comment organiser le support pour les métiers ? - Le modèle des utilisateurs relais - Les contrats de services Quand recourir à l'externalisation ? - Externaliser l'exploitation - Externaliser la TMA - L'offshore est-il envisageable pour l'exploitation et la maintenance ? CHAP 9 • La signification du RSI et le calcul de la valeur d'un projet SAP Identifier les gains - Des gains pour qui ? - Estimer les gains La notion de retour sur investissement - Comment calculer un RSI ? - Existe-t-il des méthodes pour estimer un RSI ? - Sur quelle période évaluer le RSI ? Quels indicateurs mettre en place ? - Les indicateurs de comparaison - Quelques sources d'écarts lors de l'estimation des coûts Annexes Carte blanche laissée à l'éditeur SAP Présentation de l'USF