主题 5.4 — 企业资源计划（ERP）

一句话概括： 企业资源计划是集成化的后台系统——财务、人力资源、薪酬、采购和供应链——它充当机构在资金、人员和库存方面的记录系统，并悄悄支撑着本书中几乎每一种工作方式。

为什么这在卫生与照护中至关重要#

卫生与照护中的数字化转型，其关注点来自临床系统——电子病历（Electronic health record）、共享照护记录、患者应用程序。但这些系统若没有其下方不起眼的后台支撑，就都无法运行。必须招募、排班并支付员工薪酬；必须签订供应商合同并结算款项；药品、设备和耗材必须被订购和跟踪；每一英镑都必须依照极为紧张的公共预算进行核算。ERP 正是这一切发生的地方，一旦它出故障，后果立即显现：员工薪酬拖欠、采购停滞、账目无法核对，以及财务职能陷入盲目状态。

其规模是巨大的。NHS 共享商业服务（NHS Shared Business Services，NHS SBS）是一家成立于 2004 年的合资企业，运行着一个基于 Oracle 的国家级财务和采购平台，为一百多家 NHS 机构处理数百万张发票，并处理 NHS 总支出中相当大的份额（参见"关键资料来源"）。因此，ERP 决策并非一个小众的财务问题——它塑造着人力资源管理、公共资金的控制，以及每一项下游分析所依赖的数据质量。对一位主管而言，ERP 既是一项基础性的赋能因素，也是一个机构将会尝试的风险最高的项目之一。

核心概念#

什么是 ERP。 一套单一的、集成化的企业资源计划（Enterprise resource planning）模块套件，共享同一个数据库和同一套主数据，涵盖企业的核心行政流程：总账和财务会计、应付账款和应收账款、人力资源和人事行政、薪酬（Payroll）、采购（采购到付款（Purchase-to-pay））、库存和供应链，以及日益增多的规划与分析（FP&A——财务规划与分析）。"集成"的意义在于，一份采购订单、一次货物收货和一张发票能够自动核对一致，因为它们是同一份数据，而不是三份副本。

记录系统（System of record）。 ERP 是财务和资源数据的权威来源——是审计人员信赖的总账，也是员工据以领取薪酬的薪资系统。其他系统可能持有运营副本，但对于资金而言，ERP 是真相的那个版本，对实质性的人力资源记录也往往如此。

主数据（Master data）。 其他一切都依赖的共享参考数据：会计科目表（Chart of accounts）、成本中心、供应商记录、物料目录，以及员工记录。主数据是 ERP 成功与否的隐性决定因素——脏乱、重复，或不一致的主数据会破坏报告、破坏核对，并削弱建立在其之上的每一个流程。

卫生和公共部门中常见的平台。 在 NHS 和更广泛的英国公共部门中，主要的 ERP 平台是 Oracle（占主导地位，主要通过 NHS SBS 和 NEP 等联合体）、SAP、Unit4（被信托机构、大学和地方当局广泛选用），以及 Microsoft Dynamics 365。提供成人社会照护的地方当局，在其财务和采购方面运行着同一类系统。现代的发展方向是云 ERP（软件即服务（Software-as-a-service）），而不是本地部署安装。

共享服务（Shared services）。 与其让每个机构各自运行自己的 ERP，许多机构共享一个共同的平台和一套共同的后台运营——即 NHS SBS 模式，以及运行模板化 Oracle Cloud 实例的 NHS 联合体。共享服务以牺牲一些本地灵活性为代价，换取标准化、规模经济，以及更轻的集体实施和支持负担。

最佳实践#

1. 把主数据当作基础，而不是事后补充来对待。 在迁移（Data migration）之前清理和去重会计科目表、供应商记录、物料目录和员工数据，并建立持续的数据治理所有权。最具破坏性的 ERP 失败，可追溯到再好的软件也无法修复的糟糕主数据；数据质量工作流不是可选项。

2. 采用标准，最小化定制。 只要流程真正属于通用型，就依据供应商或联合体的标准模板进行配置，把定制变更留给那些真正稀有的真实差异化因素。大量定制会抬高成本、破坏可升级性，并把你原本想要摆脱的本地混乱重新带回来——云 ERP 尤其会惩罚"让它看起来像我们的旧系统"这种本能。

3. 有意识地设计集成。 ERP 不能独立存在：它必须与人力资源和电子排班系统、临床和药房系统（用于库存和成本核算）、银行以及分析平台交换数据。绘制每一个接口，拥有数据契约的所有权，并进行端到端测试——由一个损坏的排班数据流所驱动的薪酬发放，会付错薪酬，那是一次摧毁信任的失败。

4. 将 ERP 替换当作一个重大项目群来运行，把变革管理置于其核心。 ERP 实施是一个恰好涉及软件的业务变革项目群，而不是一个 IT 项目。以项目群纪律（参见主题 5.2——项目群管理）和真正的变革管理（Change management）努力（参见主题 8.1——变革管理）为其配备资源，因为大多数 ERP 的痛点在于人和流程，而不是技术。

5. 对 ERP 项目群风险保持诚实。 大型 ERP 实施因超时超支、收益交付不足而有着咎由自取的名声；关于其失败的文献广泛且跨行业。要建立应急余地，在可行的情况下避免大爆炸式上线，绝不让乐观的时间表凌驾于准备就绪之上——一个延迟的日期是可以挽回的，一次搞砸的薪酬或总账切换则不然。

6. 保护上线及其之后的一段时期。 详细规划数据切换、并行运行、核对和超密切支持（hypercare），并抵制缩短这些环节的压力。上线前后的几周，正是供应商付款拖欠、月末结账崩溃的时候；一个配备充足人手的稳定期，是一个艰难开局与一场公开危机之间的区别。

7. 将 ERP 作为资源管理的记录系统来使用——并围绕它设计工作方式。 让 ERP 成为成本中心、预算、采购审批和人员编制的单一来源，并让你的运营流程与它对齐，而不是维护影子电子表格。影子系统会重新引入 ERP 本应消除的碎片化，并悄悄腐蚀数据质量。

8. 依据真实的权衡来权衡共享服务和云 ERP。 共享平台（NHS SBS、NEP 式联合体）和云 ERP 提供标准化、规模、持续升级和更轻的本地负担，代价是一些本地灵活性和对供应商的依赖。要有意识地做出选择：对大多数机构而言，标准化的收益超过灵活性的损失，但这个决定应该是睁大眼睛做出的，而不是默认发生的。

与团队讨论的问题#

1. 对于我们将带入一个新 ERP 的主数据质量，我们有多大信心——依据的是证据、而不是保证——上线之后谁拥有它？ 主数据是 ERP 成功与否的隐性决定因素，然而它常常被当作一项迁移的家务事，而不是它本应是的基础，因此这个问题检验的是团队是否认真审视过会计科目表、供应商记录、物料目录和员工主数据，还是仅仅寄望于它们是干净的。在一个卫生与照护环境中，利害关系是具体的：重复的供应商记录会破坏采购到付款的核对，一份与 ESR 不一致的员工主数据会付错薪酬，一份不一致的会计科目表会腐蚀董事会和审计人员所依赖的每一份下游财务报告。值得辩论的张力是，为了赶上一个日期而整体迁移的拉力，与良好实践所要求的数月不起眼的清理和去重工作之间的张力，以及是否有高层人士愿意资助一个看不到明显产出的数据质量工作流。一个有力的答案会引用实际的计数——有多少重复的供应商、有多少未核对的员工记录——而不是一种"数据基本没问题"的泛泛感觉。它还应指明在上线之后对主数据质量负责的人和治理机制，因为清理一次却之后无人治理的数据，只会悄悄漂回混乱。

2. 我们在哪些地方真的被诱惑去定制 ERP 以保留一个熟悉的流程，那种差异是一个真正的差异化因素，还是我们正试图摆脱的旧混乱？ 大量定制是典型的企业级 ERP 陷阱：它抬高成本，破坏可升级性，并把项目本应消除的那种本地碎片化重新带回来，云 ERP 尤其会惩罚"让它看起来像我们的旧系统"这种本能。这个问题要求团队具体说明他们会坚持要求软件迁就哪些流程，并针对"这是一个真正的差异化因素，还是仅仅是舒适的习惯"这一硬性测试逐一证明其合理性。这场辩论很重要，因为在卫生与照护中，几乎每一个后台流程——总账、采购审批、薪酬管理——都真正属于通用型，因此诚实的默认做法应该是采用供应商或联合体的标准模板，改变流程，而不是改变软件。具体的切入点包括列出每一项被要求的定制，并问谁从中受益、它锁定了多少升级成本，以及使用同一模板的邻近信托机构是否没有它也能运作。一个好的答案会把罕见的合理例外，与由变革厌恶所驱动的众多请求区分开来，并认识到采用标准是一个变革管理和领导力问题，而不是一个技术问题。它还应正视长期成本：每一项定制变更都是在未来每次云端发布时都要缴纳的一笔税。

3. 我们是否诚实地为这次 ERP 变革的人和流程方面——切换、并行运行、超密切支持、培训和集成测试——配备了资源，还是在悄悄地把它当作一个 IT 项目来运行？ 失败文献明确指出，大多数 ERP 的痛点在于人和流程，而不是技术，因此这个问题揭示的是，这个项目群究竟是一次真正的业务变革努力，还是一次披着项目群外衣的 IT 替换。上线前后那段时期，正是供应商付款拖欠、月末结账崩溃、员工薪酬延迟发放的时候，在一个公共卫生机构中，这些每一项都不是一个艰难的开局，而是一次摧毁信任、可能成为新闻头条的失败。要辩论的张力是，缩短并行运行、削减超密切支持团队、压缩时间表以赶上一个被强加的日期这一持续压力，与"一个延迟的日期是可以挽回的，而一次搞砸的薪酬或总账切换则不然"这一现实之间的张力。有用的切入点包括逐一审视每一个集成——电子排班、ESR、药房库存、银行、分析——并问哪些已经过端到端测试、哪些只是被假设可行，以及财务、采购和人力资源方面的流程所有者是否真的被借调去重新设计他们的工作流程。一个诚实的答案会在计划中展示具名的变革管理、培训和核对资源，而不是一句"IT 会处理"，并愿意在大爆炸式切换会增加可避免风险的地方分阶段上线。它还应承认，是准备就绪程度、而不是日历，必须主导继续推进的决定。

4. 在共享服务和云 ERP 的问题上，我们是否权衡过将获得的标准化与将放弃的本地灵活性——并且是有意识地、而不是默认地做出这个决定的？ 诸如 NHS SBS 和联合体 Oracle Cloud 实例这样的共享平台，以及更广泛意义上的云 ERP，提供了真实的好处——规模经济、持续升级、更轻的本地实施和支持负担——但它们是以真正丧失本地控制权和对供应商路线图与发布节奏的硬性依赖为代价换来的。这个问题迫使团队说明对他们而言真正重要的灵活性是什么，并检验它是否值得为运行、打补丁和单独支持自己后台的成本买单。在一个卫生与照护环境中，这种张力因大多数后台流程都属于通用型这一事实而更加尖锐，因此标准化的收益通常超过灵活性的损失——但"通常"不等于"总是"，不经审视权衡就漂向一个共享平台，正是机构最终怨恨一个自己从未有意识选择过的模板的原因。具体的切入点包括问团队会为保留哪些本地流程而抗争、为什么，当联合体改变了他们所依赖的模板底层时会发生什么，以及在签约之前是否理解退出和数据可携带性条款。一个有力的答案会把这当作一个睁大眼睛做出的战略选择，权衡供应商依赖和路线图风险与规模和升级减负之间的关系，而不是因为时髦就默认选择共享选项，或出于习惯而固守一个定制平台。

5. 我们有没有一个诚实的计划，防止影子电子表格和本地变通做法在上线之后重新出现，使 ERP 保持为单一的记录系统，而不是众多来源之一？ 一个集成 ERP 的全部意义，就在于消除影子系统所造成的碎片化，然而本地电子表格总有办法在上线后存活下来，悄悄地把项目本应统一起来的数据重新碎片化。这个问题检验的是，团队是否已经想到了切换之后的持久运营纪律——使成本中心、预算、采购审批和人员编制继续存在于 ERP 中，而不是某人的私人工作簿里。这在卫生与照护中很重要，因为一份与薪酬不一致的影子人员编制表，或一个系统外的采购跟踪表，会悄悄腐蚀董事会报告和审计所依赖的数据质量，而这恰恰是因为它对维护它的那个人来说很方便。值得揭示的张力是，影子系统通常是有原因才存在的——ERP 流程感觉更慢，或者一个真正的缺口从未被弥合——因此仅仅禁止它们，除非解决了根本需求，否则是行不通的。有用的切入点包括问当前哪些电子表格必须在上线时消亡、每一个存在的原因是什么，以及系统内的什么能力或流程变更会消除重建它的冲动。一个诚实的答案会把"ERP 是权威来源"这一明确期望，与修复驱使人们脱离系统的那些缺口的计划配对，并指明谁会在一个影子系统重新出现时注意到并质疑它。

6. 我们是否真正诚实地对待 ERP 项目群风险——该行业超支和交付不足的记录——我们的时间表、应急余地和上线方法是否围绕这一现实、而不是一份乐观的计划来构建的？ 大型 ERP 实施因超时超支、收益交付不足而有着咎由自取的跨行业名声，这个问题问的是团队是否已经内化了那些失败文献，还是悄悄地假设自己会是例外。一个公共卫生机构所面临的利害关系是不留情面的：一个延迟的日期是可以挽回的，但一次搞砸的薪酬或总账切换是一个会登上新闻、摧毁信任的事件，带有议会和媒体的后果，因此凌驾于准备就绪之上的乐观主义不是勇气，而是鲁莽。要辩论的张力是，来自被强加的日期、沉没成本和展示进展的愿望的持续压力，去压缩时间表、削减应急余地，并偏好一次大爆炸式上线，而不是一次更安全但更慢的分阶段上线。具体的切入点包括问计划假设哪些事情会顺利进行、应急余地究竟在哪里、分阶段切换是否可行，以及如果准备工作不到位，延迟上线的明确标准是什么。一个好的答案会指明这个项目群所承担的具体风险，而不是泛泛地提及 ERP 风险，建立真正的应急余地和一个站得住脚的分阶段决策，并将一个基于数据的"暂时不行"视为一个合理且预期的结果，而不是缺乏胆识。

实践中：一个卫生与照护案例#

一家急症 NHS 信托机构正在运行一套已有十五年历史的本地部署财务和采购系统，其供应商即将停止支持。报告需要数天时间，采购到付款大量依赖人工，人员编制存在于一堆永远与薪酬对不上的电子表格中。该信托机构决定迁移到一个通过区域性 NHS 联合体的模板化 Oracle Cloud 实例交付的云 ERP，与邻近的服务提供者一起。

财务总监抵制了将其当作一次 IT 替换来对待的诱惑。一个项目群被建立起来，配有一位高管赞助人、一位全职项目群经理，以及——至关重要的——一个数据质量工作流，在任何迁移之前花费数月时间清理会计科目表、为一万两千条供应商记录去重，并将员工主数据与 ESR（NHS 电子员工记录）进行核对。财务、采购和人力资源方面的流程所有者被借调去按照联合体模板重新设计他们的工作流程（Business process re-engineering），而不是照搬旧系统。

该信托机构选择了分阶段上线：财务和采购先行，人力资源和报告在后续波次，跨越两个月末进行并行运行，并配备了人手充足的超密切支持团队待命。到电子排班、银行和分析数据仓库的集成被绘制并进行了端到端测试。上线并非毫无痛苦——第一周出现了供应商付款积压，花了两周才清理完——但因为核对和超密切支持得到了适当的资源配置，没有员工被延迟发薪，月末结账也按时完成。

一年后，该信托机构能在几天内、而不是几周内结账，采购审批在系统内被强制执行，人员编制终于与薪酬一致。共享的联合体平台还意味着下一次升级将作为一次常规的云端发布到来，而不是又一个多年期项目。

行业视角#

初创企业#

一家数字健康初创企业很少运行完整的 ERP；它把云端 SaaS 工具拼接在一起——一个轻量级会计软件包、一个人力资源与薪酬应用程序，加上几份电子表格——因为一套重量级的集成套件对一个三十人的团队而言不成比例。不过，记录系统的纪律仍然重要：即使在种子阶段，一份干净的会计科目表和一个单一的权威薪酬来源，也能防止在尽职调查期间吓跑投资者的核对混乱。正确的做法是让技术栈保持简单、可集成、治理良好，并将"真正的"ERP 推迟到规模真正需要它的时候。初创企业的风险与大型机构的风险正好相反——不是过度定制，而是蔓延：十几个互不连接的应用程序，没有主数据所有者，也没有人对这些数字负责。

小型企业#

一家成熟的小型服务提供者——一家全科诊所、一家社区药房、一家养老院、一家居家照护机构，或一家单点诊所——承担着财务、薪酬和采购职责的全部重量，却几乎没有专职的财务或 IT 能力，因此一套重量级 ERP 遥不可及，但记录系统的纪律并非可选项。务实的答案是一小套集成良好的云端软件包——会计、薪酬和库存——选择它们是为了让一份会计科目表和一个权威薪酬来源能够成立，因为一家延迟支付员工薪酬的养老院，或一家库存和账目对不上的药房，面临着与一家大型信托机构相同的监管和现金后果，却没有后台团队来吸收它们。在这里，用创始人的电子表格来经营企业的诱惑最强，也最危险，因为几乎没有人能在数字出现偏差时注意到。如果一个专业机构、连锁经营方或本地网络提供一个共享或标准化的财务平台，采用它通常是明智之举：它买来了机构自身无法配备的标准化和支持。这里的纪律是让技术栈保持简单，并由资金的所有者来治理，同时抵制只有那一个人才懂的定制变通做法。

大型机构#

一家大型信托机构或健康科技公司将一套完整的集成 ERP 作为一个关键任务的记录系统来运行，替换它是它将尝试过的风险最高的项目群之一。大型机构的诱惑是大量定制以保留熟悉的遗留流程；纪律则是采用标准模板、为一个认真的数据质量工作流配备资源，并以并行运行和人手充足的超密切支持期来运行上线。集成的数量在成倍增加——电子排班、ESR、药房库存、银行、分析——如果其中任何一个悄悄破坏了薪酬或月末核对，都是一次摧毁信任的失败。因为大多数痛点在于人和流程而不是技术，变革管理（参见主题 8.1——变革管理）正是大型机构项目群成败的关键所在。向董事会和审计人员承担的问责，使得一次搞砸的总账或薪酬切换成为一次治理事件，而不仅仅是一次 IT 挫折。

政府#

在国家和共享服务规模上，ERP 是一种标准化工具：NHS 共享商业服务和联合体 Oracle Cloud 实例的存在，是为了让许多机构使用同一个模板化平台，以本地灵活性换取规模经济和持续升级。政府问责为每一项重大 ERP 决策增加了公共采购审查（竞争性框架、物有所值保证），而一次国家级切换失败会带来议会和媒体后果。中央真正的杠杆在于召集——强制或激励各方采用共享平台，从而使数十家信托机构和地方当局不必各自运行、打补丁，并各自单独地搞砸自己的后台。这里定义性的张力，存在于国家标准化和地方自治之间：模板推得太紧，采纳就会在怨恨中停滞；推得太松，ERP 本应消除的碎片化就会悄悄持续存在。

常见失败模式#

• 脏主数据被整体迁移。 旧的重复数据和不一致被带入新系统，从第一天起就腐蚀了报告。纠正：在迁移前清理并治理主数据，之后拥有其所有权。
• 为复制旧系统而定制。 为避免流程变革而做出的定制变更，抬高了成本并摧毁了可升级性。纠正：采用标准模板；改变流程，而不是软件。
• 把 ERP 当作一个 IT 项目来运行。 把它当作一次技术替换来对待，会使变革、培训和流程重新设计工作陷入资源匮乏。纠正：把它当作一个配有真正变革管理的业务变革项目群来运行（主题 8.1）。
• 乐观的大爆炸式上线。 压缩的时间表和单一的切换，把普通问题变成了公开危机。纠正：在可行的情况下分阶段进行，绝不以准备就绪程度换取一个日期。
• 损坏的集成。 一个未经测试的从排班到薪酬、或从采购到总账的数据流，会付错薪酬或破坏核对。纠正：绘制、拥有并端到端测试每一个接口。
• 影子电子表格幸存下来。 本地变通做法与 ERP 并存，重新使数据碎片化。纠正：让 ERP 成为单一的记录系统，淘汰影子系统。

成熟度模型#

检查清单#

• 会计科目表、供应商、物料和员工主数据在迁移前已被清理和去重。
• 持续的主数据所有权和治理已被指定并获得资金支持。
• 该实施项目被界定并配备资源为一个业务变革项目群，而不是一个 IT 项目。
• 定制已被最小化；对于通用型流程，采用标准的供应商或联合体模板。
• 每一个集成（排班、薪酬/ESR、临床/药房、银行、分析）都已被绘制、拥有并端到端测试。
• 上线方法（分阶段还是大爆炸式）依据准备就绪程度、而不是一个被强加的日期来选择。
• 数据切换、并行运行、核对和超密切支持期已被规划并配备人手。
• 变革管理、培训和流程重新设计已被明确配备资源（参见主题 8.1）。
• 共享服务和云 ERP 选项已依据其真实的标准化与灵活性权衡进行评估。
• ERP 已被确立为单一的记录系统，影子电子表格已被淘汰。

关键资料来源#

• NHS Shared Business Services（NHS SBS）——为 NHS 机构提供的基于 Oracle 的国家级财务和采购共享服务。https://www.sbs.nhs.uk/
• Oracle，《使用 Oracle Fusion Cloud 应用程序的 NHS 共享商业服务》——国家级 NHS 财务平台的规模。https://www.oracle.com/uk/
• NHS North of England Commissioning / NEP 联合体——面向 NHS 成员的模板化 Oracle Cloud ERP。https://nepcloud.nhs.uk/
• Unit4，《公共部门和卫生保健 ERP》——面向 NHS 信托机构、地方当局和大学的 ERP。https://www.unit4.com/industries/public-sector-software
• HFMA（Healthcare Financial Management Association），《NHS 财务入门指南》——ERP 所支撑的财务流程。https://www.hfma.org.uk/
• NHS 电子员工记录（Electronic Staff Record，ESR）——ERP 必须与之集成的 NHS 人力资源和薪酬系统。https://www.electronicstaffrecord.nhs.uk/
• 另见主题 5.2——项目群管理、主题 5.3——企业级项目组合管理，以及主题 8.1——变革管理。

参考文献#

1. Enterprise resource planning — Wikipedia — https://en.wikipedia.org/wiki/Enterprise_resource_planning
2. System of record — Wikipedia — https://en.wikipedia.org/wiki/System_of_record
3. Master data management — Wikipedia — https://en.wikipedia.org/wiki/Master_data_management
4. Chart of accounts — Wikipedia — https://en.wikipedia.org/wiki/Chart_of_accounts
5. Payroll — Wikipedia — https://en.wikipedia.org/wiki/Payroll
6. Procure-to-pay — Wikipedia — https://en.wikipedia.org/wiki/Procure-to-pay
7. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
8. Shared services — Wikipedia — https://en.wikipedia.org/wiki/Shared_services
9. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
10. Change management — Wikipedia — https://en.wikipedia.org/wiki/Change_management
11. Business process re-engineering — Wikipedia — https://en.wikipedia.org/wiki/Business_process_re-engineering
12. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
13. NHS Shared Business Services — Wikipedia — 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/