Sujet 5.4 — Planification des ressources d'entreprise (ERP)

En une phrase : La planification des ressources d'entreprise est le système d'arrière-guichet intégré — finance, ressources humaines, paie, achats, et chaîne d'approvisionnement — qui agit comme le système d'enregistrement de l'organisation pour l'argent, les personnes, et le stock, et sous-tend discrètement presque chaque façon de travailler dans ce livre.

Pourquoi c'est important dans la santé et l'action sociale#

La transformation numérique dans la santé et l'action sociale obtient son attention des systèmes cliniques — le dossier de santé électronique, le dossier de soins partagé, l'application patient. Mais aucun de ceux-ci ne fonctionne sans l'arrière-guichet peu glamour en dessous. Le personnel doit être recruté, planifié, et payé ; les fournisseurs doivent être contractés et réglés ; les médicaments, dispositifs, et consommables doivent être commandés et suivis ; et chaque livre sterling doit être comptabilisée contre des budgets publics étroitement contraints. L'ERP est là où cela se passe, et quand il échoue, les conséquences sont immédiates : personnel non payé, achats bloqués, comptes non réconciliés, et une fonction finance volant à l'aveugle.

L'échelle est énorme. NHS Shared Business Services (NHS SBS), une coentreprise créée en 2004, exploite une plateforme nationale de finance et d'achats basée sur Oracle qui traite des millions de factures et gère une très grande part de la dépense totale du NHS pour plus de cent organisations du NHS (voir Sources clés). Les décisions ERP ne sont donc pas une préoccupation financière de niche — elles façonnent la gestion de la main-d'œuvre, le contrôle de l'argent public, et la qualité des données dont dépend chaque analyse en aval. Pour un dirigeant, l'ERP est à la fois un habilitant fondamental et l'un des programmes les plus risqués qu'une organisation tentera jamais.

Concepts fondamentaux#

Ce qu'est l'ERP. Une suite unique et intégrée de modules de planification des ressources d'entreprise partageant une base de données et un ensemble de données de référence, couvrant les processus administratifs centraux de l'entreprise : grand livre et comptabilité financière, comptes fournisseurs et clients, administration RH et main-d'œuvre, paie, achats (purchase-to-pay), inventaire et chaîne d'approvisionnement, et de plus en plus planification et analytique (FP&A — planification et analyse financière). Le point de « l'intégration » est qu'un bon de commande, un accusé de réception de marchandises, et une facture se réconcilient automatiquement car ce sont les mêmes données, pas trois copies.

Système d'enregistrement. L'ERP est la source faisant autorité pour les données financières et de ressources — le grand livre auquel les auditeurs font confiance et la paie dont le personnel est payé. D'autres systèmes peuvent détenir des copies opérationnelles, mais l'ERP est la version de vérité pour l'argent et, souvent, pour le dossier RH substantiel.

Données de référence. Les données de référence partagées dont tout le reste dépend : le plan comptable, les centres de coûts, les dossiers fournisseurs, le catalogue d'articles, et les dossiers d'employés. Les données de référence sont le déterminant silencieux du succès ERP — des données de référence sales, dupliquées, ou incohérentes corrompent le reporting, cassent la réconciliation, et sapent chaque processus construit dessus.

Plateformes communes dans la santé et le secteur public. Dans le NHS et le secteur public britannique plus large, les principales plateformes ERP sont Oracle (dominant, largement via NHS SBS et des consortiums tels que NEP), SAP, Unit4 (largement choisi par les trusts, universités, et autorités locales), et Microsoft Dynamics 365. Les autorités locales livrant l'action sociale pour adultes exploitent la même classe de systèmes pour leur finance et achats. La direction moderne du voyage est l'ERP cloud (logiciel en tant que service) plutôt que les installations sur site.

Services partagés. Plutôt que chaque organisation exploitant son propre ERP, de nombreuses partagent une plateforme commune et une opération d'arrière-guichet commune — le modèle NHS SBS, et les consortiums NHS exploitant des instances Oracle Cloud modélisées. Les services partagés échangent une certaine flexibilité locale contre la standardisation, les économies d'échelle, et un fardeau d'implémentation et de support collectif plus léger.

Bonnes pratiques#

1. Traitez les données de référence comme la fondation, pas une réflexion après coup. Nettoyez et dédupliquez le plan comptable, les dossiers fournisseurs, le catalogue d'articles, et les données d'employés avant la migration, et mettez en place une propriété de gouvernance de données continue. Les échecs ERP les plus dommageables remontent à de mauvaises données de référence qu'aucune quantité de bon logiciel ne peut corriger ; un flux de travail de qualité de données n'est pas optionnel.

2. Adoptez le standard ; minimisez la personnalisation. Configurez l'ERP selon le modèle standard du fournisseur ou consortium partout où le processus est véritablement de commodité, et réservez le changement sur mesure pour le rare véritable différenciateur. Une personnalisation lourde gonfle le coût, ruine la mise à niveau, et réimporte le désordre local que vous essayiez d'échapper — l'ERP cloud en particulier punit l'instinct de « le faire ressembler à notre ancien système ».

3. Concevez les intégrations délibérément. L'ERP ne se tient pas seul : il doit échanger des données avec les systèmes de main-d'œuvre et de planification électronique, les systèmes cliniques et de pharmacie (pour le stock et l'établissement des coûts), la banque, et l'analytique. Cartographiez chaque interface, possédez les contrats de données, et testez-les de bout en bout — une paie alimentée par un flux de planification cassé paie mal les gens, et c'est un échec destructeur de confiance.

4. Exploitez le remplacement ERP comme un programme majeur, avec la gestion du changement en son cœur. Une implémentation ERP est un programme de changement métier qui implique par hasard du logiciel, pas un projet informatique. Dotez-le en ressources avec discipline de programme (voir Sujet 5.2 — Gestion de programme) et un véritable effort de gestion du changement (voir Sujet 8.1 — Gestion du changement), car la plupart de la douleur ERP concerne les gens et le processus, pas la technologie.

5. Soyez honnête sur le risque de programme ERP. Les grandes implémentations ERP ont une réputation bien méritée de dépassement de temps et de coût et de sous-livraison de bénéfice ; la littérature d'échec est extensive et transectorielle. Intégrez une contingence, évitez une mise en production big-bang là où une approche échelonnée est faisable, et ne laissez jamais un calendrier optimiste outrepasser la préparation — une date glissée est récupérable, une bascule de paie ou de grand livre ratée ne l'est pas.

6. Protégez la mise en production et la période après. Planifiez la bascule de données, le fonctionnement parallèle, la réconciliation, et le support hypercare en détail, et résistez à la pression de les raccourcir. Les semaines autour de la mise en production sont quand les fournisseurs ne sont pas payés et que la fin de mois se casse ; une période de stabilisation bien dotée en personnel est la différence entre un début difficile et une crise publique.

7. Utilisez l'ERP comme le système d'enregistrement de gestion des ressources — et concevez des façons de travailler autour de lui. Laissez l'ERP être la source unique pour les centres de coûts, budgets, approbations d'achats, et effectif de main-d'œuvre, et alignez vos processus opérationnels dessus plutôt que de maintenir des feuilles de calcul fantômes. Les systèmes fantômes réintroduisent la fragmentation que l'ERP existe pour supprimer et pourrissent discrètement la qualité des données.

8. Pesez les services partagés et l'ERP cloud sur leurs véritables compromis. Les plateformes partagées (NHS SBS, consortiums de style NEP) et l'ERP cloud offrent la standardisation, l'échelle, les mises à niveau continues, et un fardeau local plus léger, au coût d'une certaine flexibilité locale et d'une dépendance envers le fournisseur. Choisissez délibérément : pour la plupart des organisations, le gain de standardisation dépasse la flexibilité perdue, mais la décision devrait être prise les yeux ouverts, pas par défaut.

Questions à discuter avec votre équipe#

1. À quel point sommes-nous confiants — avec des preuves, pas une assurance — sur la qualité des données de référence que nous porterions dans un nouvel ERP, et qui les possède après la mise en production ? Les données de référence sont le déterminant silencieux du succès ERP, pourtant elles sont routinièrement traitées comme une tâche ménagère de migration plutôt que la fondation qu'elles sont, donc cette question teste si l'équipe a regardé attentivement le plan comptable, les dossiers fournisseurs, le catalogue d'articles, et la référence d'employés ou espère simplement qu'ils sont propres. Dans un contexte de santé et d'action sociale, les enjeux sont concrets : des dossiers fournisseurs dupliqués cassent la réconciliation purchase-to-pay, une référence d'employé qui est en désaccord avec ESR paie mal les gens, et un plan comptable incohérent corrompt chaque rapport financier en aval sur lequel le conseil d'administration et les auditeurs s'appuient. La tension qui vaut la peine d'être débattue est l'attraction de migrer en bloc pour atteindre une date versus les mois de nettoyage et déduplication peu glamour que la bonne pratique exige, et si quelqu'un de senior est disposé à financer un flux de travail de qualité de données qui ne montre aucun produit visible. Une réponse forte cite de véritables comptes — combien de fournisseurs dupliqués, combien de dossiers d'employés non réconciliés — plutôt qu'un sens général que « les données sont majoritairement correctes ». Elle devrait aussi nommer la personne et le mécanisme de gouvernance responsable de la qualité des données de référence après la mise en production, car des données nettoyées une fois puis laissées non gouvernées dérivent simplement vers le désordre.

2. Où sommes-nous véritablement tentés de personnaliser l'ERP pour préserver un processus familier, et cette différence est-elle un véritable différenciateur ou simplement l'ancien désordre que nous essayons d'échapper ? La personnalisation lourde est le piège classique de l'ERP d'entreprise : elle gonfle le coût, ruine la mise à niveau, et réimporte la fragmentation locale même que le programme était censé supprimer, et l'ERP cloud en particulier punit l'instinct de « le faire ressembler à notre ancien système ». Cette question demande à l'équipe d'être spécifique sur quels processus elle insistera pour plier le logiciel à correspondre, et de justifier chacun contre un test dur de si c'est un véritable différenciateur ou simplement une habitude confortable. Le débat compte car dans la santé et l'action sociale, presque chaque processus d'arrière-guichet — grand livre, approbations d'achats, administration de paie — est véritablement de commodité, donc le défaut honnête devrait être d'adopter le modèle standard du fournisseur ou consortium et changer le processus, pas le logiciel. Les angles concrets incluent lister chaque personnalisation demandée et demander qui en bénéficie, quel coût de mise à niveau elle verrouille, et si un trust voisin sur le même modèle se débrouille sans elle. Une bonne réponse distingue la rare exception légitime des nombreuses demandes pilotées par l'aversion au changement, et reconnaît qu'adopter le standard est un problème de gestion du changement et de leadership, pas technique. Elle devrait aussi confronter le coût à long terme : chaque changement sur mesure est une taxe payée à chaque future version cloud.

3. Avons-nous honnêtement doté en ressources le côté humain et de processus de ce changement ERP — bascule, fonctionnement parallèle, hypercare, formation, et test d'intégration — ou l'exploitons-nous discrètement comme un projet informatique ? La littérature d'échec est sans ambiguïté que la plupart de la douleur ERP est des gens et du processus plutôt que de la technologie, donc cette question expose si le programme est véritablement un effort de changement métier ou un échange informatique portant des habits de programme. La période autour de la mise en production est quand les fournisseurs ne sont pas payés, la fin de mois se casse, et le personnel est payé en retard, et chacun de ceux-ci dans un organisme de santé publique n'est pas un début difficile mais un échec destructeur de confiance et potentiellement médiatisé. La tension à débattre est la pression constante de raccourcir le fonctionnement parallèle, amincir l'équipe hypercare, et compresser le calendrier pour atteindre une date imposée, contre la réalité qu'une date glissée est récupérable tandis qu'une bascule de paie ou de grand livre ratée ne l'est pas. Les angles utiles incluent passer en revue chaque intégration — planification électronique, ESR, stock de pharmacie, banque, analytique — et demander lesquelles ont été testées de bout en bout versus supposées, et si les propriétaires de processus en finance, achats, et RH ont réellement été détachés pour reconcevoir leurs flux de travail. Une réponse honnête montre une ressource nommée de gestion du changement, de formation, et de réconciliation dans le plan plutôt qu'une ligne qui dit « l'IT s'en occupera », et est disposée à échelonner la mise en production là où une bascule big-bang ajoute un risque évitable. Elle devrait aussi reconnaître que la préparation, pas le calendrier, doit gouverner la décision de procéder.

4. Sur la question des services partagés et de l'ERP cloud, avons-nous pesé la standardisation que nous gagnerions contre la flexibilité locale que nous abandonnerions — et fait cet appel délibérément plutôt que par défaut ? Les plateformes partagées telles que NHS SBS et les instances Oracle Cloud de consortium, et l'ERP cloud plus largement, offrent de véritables prix — économies d'échelle, mises à niveau continues, un fardeau d'implémentation et de support local plus léger — mais elles achètent cela avec une véritable perte de contrôle local et une dépendance dure envers la feuille de route et cadence de version du fournisseur. Cette question force l'équipe à nommer quelle flexibilité compte réellement pour elle et tester si elle vaut le coût d'exploiter, corriger, et soutenir séparément son propre arrière-guichet. La tension dans un contexte de santé et d'action sociale est accentuée par le fait que la plupart du processus d'arrière-guichet est de commodité, donc le gain de standardisation dépasse habituellement la flexibilité perdue — mais « habituellement » n'est pas « toujours », et dériver vers une plateforme partagée sans examiner le compromis est comment les organisations finissent par ressentir un modèle qu'elles n'ont jamais consciemment choisi. Les angles concrets incluent demander quels processus locaux l'équipe combattrait pour garder et pourquoi, ce qui se passe quand le consortium change le modèle sous elle, et si les termes de sortie et de portabilité des données sont compris avant de signer. Une réponse forte traite cela comme un choix stratégique fait les yeux ouverts, pesant la dépendance fournisseur et le risque de feuille de route contre le soulagement d'échelle et de mise à niveau, plutôt que soit de défaulter vers l'option partagée car elle est à la mode soit de s'accrocher à une plateforme sur mesure par habitude.

5. Quel est notre plan honnête pour arrêter les feuilles de calcul fantômes et solutions de contournement locales de réémerger après la mise en production, afin que l'ERP reste le système d'enregistrement unique plutôt qu'une source parmi beaucoup ? Tout le point d'un ERP intégré est de supprimer la fragmentation que les systèmes fantômes créent, pourtant les feuilles de calcul locales ont une façon de survivre à une mise en production et de refragmenter discrètement les données que le programme était censé unifier. Cette question teste si l'équipe a pensé au-delà de la bascule vers la discipline opérationnelle durable qui garde les centres de coûts, budgets, approbations d'achats, et effectif de main-d'œuvre vivant dans l'ERP plutôt que dans le classeur privé de quelqu'un. Cela compte dans la santé et l'action sociale car une feuille de calcul d'effectif fantôme qui est en désaccord avec la paie, ou un suivi d'achats hors système, pourrit silencieusement la qualité des données dont dépendent le rapport au conseil d'administration et l'audit, et le fait précisément car c'est commode pour la personne qui le maintient. La tension qui vaut la peine d'être mise en évidence est que les systèmes fantômes existent habituellement pour une raison — le processus ERP semblait plus lent, ou un véritable écart n'a jamais été fermé — donc simplement les interdire échoue à moins que le besoin sous-jacent ne soit adressé. Les angles utiles incluent demander quelles feuilles de calcul actuelles devraient mourir à la mise en production, pourquoi chacune existe, et quelle capacité en système ou changement de processus supprimerait la tentation de la reconstruire. Une réponse honnête associe une attente claire que l'ERP fait autorité avec un plan pour corriger les écarts qui poussent les gens hors système, et nomme qui remarquera et contestera un système fantôme quand il réapparaît.

6. Sommes-nous véritablement honnêtes sur le risque de programme ERP — le bilan du secteur de dépassement et sous-livraison — et avons-nous construit notre calendrier, contingence, et approche de mise en production autour de cette réalité plutôt qu'un plan optimiste ? Les grandes implémentations ERP ont une réputation bien méritée et transectorielle de dépassement de temps et de coût et de sous-livraison de bénéfice, et cette question demande si l'équipe a intériorisé cette littérature d'échec ou suppose discrètement qu'elle sera l'exception. Les enjeux dans un organisme de santé publique sont impitoyables : une date glissée est récupérable, mais une bascule de paie ou de grand livre ratée est un événement médiatisé et destructeur de confiance avec des conséquences parlementaires et de presse, donc l'optimisme qui outrepasse la préparation n'est pas du courage mais de l'imprudence. La tension à débattre est la pression constante — venant de dates imposées, coûts irrécupérables, et le souhait de montrer du progrès — de compresser le calendrier, amincir la contingence, et préférer une mise en production big-bang à une échelonnée qui serait plus sûre mais plus lente. Les angles concrets incluent demander ce que le plan suppose se passer bien, où se situe réellement la contingence, si une bascule échelonnée est faisable, et quels sont les critères explicites pour retarder la mise en production si la préparation n'est pas là. Une bonne réponse nomme les risques spécifiques que ce programme porte plutôt que de gesticuler vers le risque ERP en général, intègre une véritable contingence et une décision de phasage défendable, et traite un « pas encore » fondé sur les données comme un résultat légitime et attendu plutôt qu'un échec de courage.

En pratique : un exemple de santé et d'action sociale#

Un trust de soins aigus du NHS exploite un système de finance et achats sur site vieux de quinze ans que son fournisseur cessera bientôt de supporter. Le reporting prend des jours, le purchase-to-pay est fortement manuel, et l'effectif de main-d'œuvre vit dans un enchevêtrement de feuilles de calcul qui ne correspond jamais tout à fait à la paie. Le trust décide de se déplacer vers un ERP cloud livré via l'instance Oracle Cloud modélisée d'un consortium NHS régional, aux côtés de prestataires voisins.

Le directeur financier résiste à la tentation de traiter cela comme un échange informatique. Un programme est mis en place avec un sponsor exécutif, un chef de programme à temps plein, et — crucialement — un flux de travail de qualité de données qui passe des mois à nettoyer le plan comptable, dédupliquer douze mille dossiers fournisseurs, et réconcilier la référence d'employé contre ESR (le dossier de personnel électronique du NHS) avant toute migration. Les propriétaires de processus en finance, achats, et RH sont détachés pour reconcevoir leurs flux de travail selon le modèle du consortium plutôt que de répliquer l'ancien système.

Le trust choisit une mise en production échelonnée : finance et achats d'abord, main-d'œuvre et reporting dans une vague ultérieure, avec un fonctionnement parallèle à travers deux fins de mois et une équipe hypercare bien dotée en personnel en attente. Les intégrations vers la planification électronique, la banque, et l'entrepôt analytique sont cartographiées et testées de bout en bout. La mise en production n'est pas sans douleur — un arriéré de paiement fournisseur se construit la première semaine et prend une quinzaine à se résorber — mais parce que la réconciliation et l'hypercare étaient correctement dotées en ressources, aucun personnel n'est payé en retard et la fin de mois se clôt à temps.

Un an plus tard, le trust clôt ses comptes en jours plutôt qu'en semaines, les approbations d'achats sont appliquées en système, et l'effectif se réconcilie enfin avec la paie. La plateforme de consortium partagée signifie aussi que la prochaine mise à niveau arrive comme une version cloud routinière plutôt qu'un autre projet pluriannuel.

Angles sectoriels#

Startup#

Une startup de santé numérique exploite rarement un ERP complet ; elle assemble des outils SaaS cloud — un package de comptabilité léger, une application RH-et-paie, quelques feuilles de calcul — car une suite intégrée lourde est disproportionnée pour une équipe de trente. La discipline de système d'enregistrement compte toujours, cependant : même au stade de graine, un plan comptable propre et une source de paie unique et faisant autorité préviennent le chaos de réconciliation qui effraie les investisseurs pendant la due diligence. Le bon mouvement est de garder la pile simple, intégrable, et bien gouvernée, et de reporter un « véritable » ERP jusqu'à ce que l'échelle l'exige véritablement. Le risque de la startup est l'image miroir de celui de l'entreprise — pas la sur-personnalisation, mais l'étalement : une douzaine d'applications déconnectées sans propriétaire de données de référence et personne responsable des chiffres.

Petite entreprise#

Un prestataire établi de petite taille — un cabinet de médecins généralistes, une pharmacie communautaire, une maison de retraite, une agence de soins à domicile, ou une clinique monosite — porte le poids complet des obligations financières, de paie, et d'achats avec presque aucune capacité financière ou informatique dédiée, donc un ERP lourd est hors de portée mais la discipline de système d'enregistrement ne l'est pas. La réponse pratique est un petit ensemble bien intégré de packages cloud — comptabilité, paie, et stock — choisi afin qu'un plan comptable et une source de paie faisant autorité tiennent, car une maison de retraite qui paie le personnel en retard ou une pharmacie dont le stock et le grand livre sont en désaccord fait face aux mêmes conséquences réglementaires et de trésorerie qu'un grand trust mais sans équipe d'arrière-guichet pour les absorber. La tentation de faire fonctionner l'entreprise sur la feuille de calcul d'un fondateur est la plus forte et la plus dangereuse ici, car il y a rarement quelqu'un pour remarquer quand les chiffres dérivent. Là où un organisme professionnel, une franchise, ou un réseau local offre une plateforme financière partagée ou standardisée, l'adopter est habituellement le mouvement avisé : elle achète la standardisation et le support que l'organisation ne peut pas se doter elle-même. La discipline est de garder la pile simple et gouvernée par qui possède l'argent, et de résister aux solutions de contournement sur mesure que seule cette personne comprend.

Entreprise#

Un grand trust ou une entreprise de health-tech exploite un ERP entièrement intégré comme un système d'enregistrement critique pour la mission, et le remplacer est l'un des programmes les plus risqués qu'il tentera jamais. La tentation d'entreprise est la personnalisation lourde pour préserver les processus hérités familiers ; la discipline est d'adopter le modèle standard, doter en ressources un véritable flux de travail de qualité de données, et exécuter la mise en production avec un fonctionnement parallèle et une période hypercare bien dotée en personnel. Les intégrations se multiplient — planification électronique, ESR, stock de pharmacie, banque, analytique — et chacune est un échec destructeur de confiance si elle casse silencieusement la paie ou la réconciliation de fin de mois. Parce que la plupart de la douleur est des gens et du processus plutôt que de la technologie, la gestion du changement (voir Sujet 8.1 — Gestion du changement) est là où le programme d'entreprise se gagne ou se perd. La responsabilité envers un conseil d'administration et des auditeurs fait d'une bascule de grand livre ou de paie ratée un incident de gouvernance, pas seulement un revers informatique.

Gouvernement#

À l'échelle nationale et de service partagé, l'ERP est un instrument de standardisation : NHS Shared Business Services et les instances Oracle Cloud de consortium existent pour donner à de nombreuses organisations une plateforme modélisée unique, échangeant la flexibilité locale contre les économies d'échelle et les mises à niveau continues. La responsabilité gouvernementale ajoute un examen minutieux d'achat public (cadres compétitifs, assurance de rapport qualité-prix) à chaque décision ERP majeure, et un échec de bascule national a des conséquences parlementaires et de presse. Le véritable levier du centre est de convoquer — mandater ou inciter des plateformes partagées afin que des dizaines de trusts et autorités locales n'exploitent, corrigent, et n'échouent pas chacun séparément leur propre arrière-guichet. La tension définissante est entre la standardisation nationale et l'autonomie locale : pousser le modèle trop fort et l'adoption stagne dans le ressentiment ; trop doucement et la fragmentation que l'ERP existe pour supprimer persiste discrètement.

Modes d'échec courants#

• Données de référence sales migrées en bloc. D'anciens doublons et incohérences sont portés dans le nouveau système, corrompant le reporting dès le premier jour. Correctif : nettoyer et gouverner les données de référence avant migration, et les posséder ensuite.
• Personnaliser pour répliquer l'ancien système. Des changements sur mesure faits pour éviter le changement de processus gonflent le coût et détruisent la mise à niveau. Correctif : adopter le modèle standard ; changer le processus, pas le logiciel.
• ERP exploité comme un projet informatique. Le traiter comme un échange technologique affame le changement, la formation, et l'effort de reconception de processus. Correctif : l'exploiter comme un programme de changement métier avec une véritable gestion du changement (Sujet 8.1).
• Mise en production big-bang optimiste. Des calendriers compressés et une seule bascule transforment des problèmes ordinaires en crises publiques. Correctif : échelonner là où faisable, et ne jamais échanger la préparation contre une date.
• Intégrations cassées. Un flux de planification-vers-paie ou d'achats-vers-grand-livre non testé paie mal les gens ou casse la réconciliation. Correctif : cartographier, posséder, et tester de bout en bout chaque interface.
• Les feuilles de calcul fantômes survivent. Les solutions de contournement locales persistent aux côtés de l'ERP, refragmentant les données. Correctif : faire de l'ERP le système d'enregistrement unique et retirer les fantômes.

Modèle de maturité#

Liste de contrôle#

• Le plan comptable, les données de référence fournisseur, article, et employé sont nettoyés et dédupliqués avant migration.
• La propriété et gouvernance continues des données de référence sont assignées et financées.
• L'implémentation est cadrée et dotée en ressources comme un programme de changement métier, pas un projet informatique.
• La personnalisation est minimisée ; le modèle standard du fournisseur ou consortium est adopté pour les processus de commodité.
• Chaque intégration (planification, paie/ESR, clinique/pharmacie, banque, analytique) est cartographiée, possédée, et testée de bout en bout.
• L'approche de mise en production (échelonnée vs. big-bang) est choisie selon la préparation, pas une date imposée.
• La bascule de données, le fonctionnement parallèle, la réconciliation, et une période hypercare sont planifiés et dotés en personnel.
• La gestion du changement, la formation, et la reconception de processus sont explicitement dotées en ressources (voir Sujet 8.1).
• Les options de services partagés et d'ERP cloud sont évaluées sur leurs véritables compromis standardisation-versus-flexibilité.
• L'ERP est établi comme le système d'enregistrement unique, et les feuilles de calcul fantômes sont retirées.

Sources clés#

• NHS Shared Business Services (NHS SBS) — the national Oracle-based finance and procurement shared service for NHS organisations. https://www.sbs.nhs.uk/
• Oracle, NHS Shared Business Services with Oracle Fusion Cloud Applications — scale of the national NHS finance platform. https://www.oracle.com/uk/
• NHS North of England Commissioning / NEP consortium — templated Oracle Cloud ERP for NHS members. https://nepcloud.nhs.uk/
• Unit4, Public sector and healthcare ERP — ERP for NHS trusts, local authorities, and universities. https://www.unit4.com/industries/public-sector-software
• HFMA (Healthcare Financial Management Association), Introductory Guide to NHS Finance — finance processes ERP underpins. https://www.hfma.org.uk/
• NHS Electronic Staff Record (ESR) — the NHS workforce and payroll system ERP must integrate with. https://www.electronicstaffrecord.nhs.uk/
• See also Sujet 5.2 — Programme Management, Sujet 5.3 — Enterprise Project Portfolio Management, and Sujet 8.1 — Change Management.

Références#

1. Enterprise resource planning — Wikipédia — https://en.wikipedia.org/wiki/Enterprise_resource_planning
2. System of record — Wikipédia — https://en.wikipedia.org/wiki/System_of_record
3. Master data management — Wikipédia — https://en.wikipedia.org/wiki/Master_data_management
4. Chart of accounts — Wikipédia — https://en.wikipedia.org/wiki/Chart_of_accounts
5. Payroll — Wikipédia — https://en.wikipedia.org/wiki/Payroll
6. Procure-to-pay — Wikipédia — https://en.wikipedia.org/wiki/Procure-to-pay
7. Software as a service — Wikipédia — https://en.wikipedia.org/wiki/Software_as_a_service
8. Shared services — Wikipédia — https://en.wikipedia.org/wiki/Shared_services
9. Data migration — Wikipédia — https://en.wikipedia.org/wiki/Data_migration
10. Change management — Wikipédia — https://en.wikipedia.org/wiki/Change_management
11. Business process re-engineering — Wikipédia — https://en.wikipedia.org/wiki/Business_process_re-engineering
12. Electronic health record — Wikipédia — https://en.wikipedia.org/wiki/Electronic_health_record
13. NHS Shared Business Services — Wikipédia — https://en.wikipedia.org/wiki/NHS_Shared_Business_Services
14. NHS Shared Business Services — the national Oracle-based finance and procurement shared service for NHS organisations — https://www.sbs.nhs.uk/
15. NHS Shared Business Services with Oracle Fusion Cloud Applications — Oracle — https://www.oracle.com/uk/
16. Public sector and healthcare ERP — Unit4 — https://www.unit4.com/industries/public-sector-software
17. Introductory Guide to NHS Finance — HFMA — https://www.hfma.org.uk/
18. NHS Electronic Staff Record (ESR) — the NHS workforce and payroll system ERP must integrate with — https://www.electronicstaffrecord.nhs.uk/