Le livre blanc de l’USF sur « SAP au sein du service public : retours d’expériences, guide pratique et facteurs clés de succès » propose dix bonnes pratiques pour les décideurs publics (et les autres) qui mettent en œuvre SAP dans leurs organisations. Et remet en question certaines idées reçues. Extraits.
ERP et secteur public ne sont pas incompatibles
Même s’il reste encore plusieurs points d’amélioration, un progiciel de gestion intégrée comme celui de 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 en France que dans le monde, est là pour le démontrer.
Si un travail d’harmonisation des processus est effectué et que l’organisation essaye 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é).
Un parrainage au plus haut niveau
La mise en place d’un progiciel de gestion intégrée 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, au niveau politique.
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. Entrer dans la logique d’un PGI comme celui de 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 à conséquent de perdre les avantages d’une solution intégrée comme celle de SAP.
Si les aspects stratégiques de tels projets doivent être pensés par les responsables du projet, la maîtrise d’ouvrage doit être très étroitement associée en amont à cette réflexion organisationnelle.
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 celui de 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 minium avoir été cadrés et anticipés, dès le cahier des clauses techniques particulières (CCTP). En fait, cela revient, fort de tous ces éléments de réflexion, à définir une véritable stratégie contractuelle.
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.
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 être très étroitement associée. 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).
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 celui de SAP est avant tout un projet organisationnel. L’erreur serait donc de le comparer avec des projets purement informatiques.
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 à appréhender uniquement sous l’angle financier.
Les notions 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 estimer la valeur réelle de tels projets.
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, un des réflexes consiste à accuser l’outil, que les utilisateurs ne se seraient pas approprié comme prévu, alors qu’en réalité, c’est bien souvent une gestion du changement déficiente qui est avant tout en cause.
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 nous ne communiquons 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 on recense déjà plus d’une cinquantaine d’expériences sur SAP dans le secteur public rien qu’en France, 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.