トピック5.4 — エンタープライズ・リソース・プランニング（ERP）

一文で言うと： エンタープライズ・リソース・プランニングは、財務、人事、給与、調達、サプライチェーンという、統合されたバックオフィスのシステムであり、お金、人、在庫についての組織の記録システムとして機能し、本書のほとんどあらゆる働き方を、静かに支えています。

医療・ケアにおいてなぜ重要か#

医療・ケアにおけるデジタル変革は、臨床システム、つまり電子患者記録、共有ケア記録、患者向けアプリから、注目を集めます。しかし、そのどれも、その下にある地味なバックオフィスなしには動きません。職員は採用され、勤務を割り当てられ、給与を支払われなければならず、サプライヤーは契約され、決済されなければならず、薬、機器、消耗品は発注され、追跡されなければならず、すべてのポンドは、厳しく制約された公的な予算に対して会計処理されなければなりません。ERPは、それが行われる場所であり、失敗すれば、その帰結は即座です。支払われない職員、止まる調達、照合されない勘定、そして盲目的に飛ぶ財務の機能。

その規模は巨大です。2004年に作られた合弁事業であるNHS Shared Business Services（NHS SBS）は、何百万もの請求書を処理し、100を超えるNHSの組織のNHS支出総額のきわめて大きな割合を扱う、OracleベースのNHS全国の財務・調達のプラットフォームを運営しています（主要な情報源参照）。したがって、ERPの判断は、ニッチな財務の関心事ではありません。それは、労働力の管理、公金の統制、そしてあらゆる下流の分析が依存するデータ品質を形づくります。取締役にとって、ERPは、基盤となる実現手段であると同時に、組織がこれまでに試みる、最もリスクの高いプログラムの一つです。

中核概念#

ERPとは何か。 一つのデータベースと一組のマスターデータを共有するモジュールからなる、単一の統合されたERPスイートで、企業の中核の管理プロセスをカバーします。総勘定元帳と財務会計、買掛金と売掛金、人事と労働力の管理、給与、調達（購買から支払いまで）、在庫とサプライチェーン、そしてますます、計画とアナリティクス（FP&A — 財務計画と分析）。「統合」の要点は、発注書、入荷、請求書が、三つのコピーではなく同じデータであるため、自動的に照合されることです。

記録システム。 ERPは、財務と資源のデータの権威ある情報源であり、監査人が信頼する元帳と、職員が給与を支払われる給与のもとです。他のシステムは運用上のコピーを保持しうるものの、ERPは、お金についての、そしてしばしば、実質的な人事記録についての、真実のバージョンです。

マスターデータ。 他のすべてが依存する、共有の参照データです。勘定科目表、コストセンター、サプライヤーの記録、品目カタログ、従業員の記録。マスターデータは、ERPの成功を静かに決める要因です。汚れた、重複した、あるいは一貫しないマスターデータは、報告を損ない、照合を壊し、その上に築かれたあらゆるプロセスを損ないます。

医療と公共部門の一般的なプラットフォーム。 NHSと、より広い英国の公共部門では、主なERPのプラットフォームは、Oracle（主にNHS SBSとNEPなどのコンソーシアムを通じて支配的）、SAP、Unit4（トラスト、大学、地方自治体に広く選ばれる）、Microsoft Dynamics 365です。成人社会的ケアを提供する地方自治体は、財務と調達について、同じ種類のシステムを運用しています。現代の進む方向は、オンプレミスの導入ではなく、クラウドERP（SaaS）です。

共有サービス。 あらゆる組織が自前のERPを運用する代わりに、多くが、共通のプラットフォームと共通のバックオフィスの運営を共有します。NHS SBSのモデルと、テンプレート化されたOracle Cloudのインスタンスを運営するNHSのコンソーシアムです。共有サービスは、ローカルの柔軟性の一部と引き換えに、標準化、規模の経済、そしてより小さな集団的な導入・サポートの負担を得ます。

ベストプラクティス#

1. マスターデータを、後回しではなく、基盤として扱う。 移行の前に、勘定科目表、サプライヤーの記録、品目カタログ、従業員のデータをクレンジングして重複を排除し、継続的なデータガバナンスの所有を整えます。最も損害の大きいERPの失敗は、どれだけ良いソフトウェアでも直せない、悪いマスターデータにたどり着きます。データ品質の作業の流れは、任意ではありません。

2. 標準を採用し、カスタマイズを最小化する。 プロセスが本当にコモディティであるところでは、ERPをベンダーやコンソーシアムの標準テンプレートに合わせて設定し、特注の変更は、まれな真の差別化要因のために取っておきます。重いカスタマイズはコストを膨らませ、アップグレードのしやすさを壊し、逃れようとしていたローカルな混乱を再び持ち込みます。特にクラウドERPは、「古いシステムのように見せたい」という本能を罰します。

3. 連携を意図して設計する。 ERPは単独では立ちません。労働力とeロスタリングのシステム、臨床と薬局のシステム（在庫とコスト計算のため）、銀行、アナリティクスとデータを交換しなければなりません。あらゆるインターフェースを描き出し、データの契約を所有し、端から端までテストします。壊れたロスタリングのフィードから給与を支払うと、人々に誤って支払うことになり、それは信頼を損なう失敗です。

4. ERPの置き換えを、チェンジマネジメントを中核に据えた、主要なプログラムとして運営する。 ERPの導入は、たまたまソフトウェアを伴う、ビジネス変革のプログラムであり、ITプロジェクトではありません。プログラムの規律（トピック5.2 — プログラム主導の仕事参照）と、本物のチェンジマネジメントの取り組み（トピック8.1 — チェンジマネジメント参照）で資源を与えてください。ERPの苦痛のほとんどは、技術ではなく、人とプロセスだからです。

5. ERPプログラムのリスクについて誠実になる。 大規模なERPの導入は、時間とコストで超過し、便益で期待を下回るという、当然の評判を得ており、失敗についての文献は広範で、セクターをまたぎます。予備費を組み込み、段階的なアプローチが可能なところではビッグバンの稼働を避け、楽観的なスケジュールに準備状況を覆させてはなりません。遅れた日付は取り戻せますが、失敗した給与や元帳の切り替えは取り戻せません。

6. 稼働と、その後の期間を守る。 データの切り替え、並行稼働、照合、ハイパーケアのサポートを詳細に計画し、それらを短縮する圧力に抵抗します。稼働前後の数週間は、サプライヤーへの支払いが滞り、月末が壊れるときです。十分な人員を配置した安定化の期間が、粗い始まりと、公的な危機の違いです。

7. ERPを、資源管理の記録システムとして使い、それを軸に働き方を設計する。 ERPを、コストセンター、予算、調達の承認、労働力の定員の単一の情報源とし、影の表計算を維持するのではなく、運営のプロセスをそれに整合させます。影のシステムは、ERPが取り除くために存在する断片化を再び持ち込み、データ品質を静かに腐らせます。

8. 共有サービスとクラウドERPを、その実際のトレードオフで比較考量する。 共有のプラットフォーム（NHS SBS、NEP型のコンソーシアム）とクラウドERPは、標準化、規模、継続的なアップグレード、より軽いローカルの負担を提供しますが、ローカルの柔軟性の一部と、提供者への依存という代償を伴います。意図して選んでください。ほとんどの組織では、標準化の利得が失われる柔軟性を上回りますが、その判断は、既定ではなく、目を見開いて行われるべきです。

チームで話し合うための問い#

1. 新しいERPに持ち込むマスターデータの品質について、保証ではなくエビデンスで、どれだけ自信があるか。そして、稼働後、誰がそれを所有するか。 マスターデータは、ERPの成功を静かに決める要因ですが、基盤であるにもかかわらず、日常的に移行の雑務として扱われます。そのため、この問いは、チームが、勘定科目表、サプライヤーの記録、品目カタログ、従業員マスターを、本気で調べたのか、単にそれらがきれいであることを願っているのかを試します。医療・ケアの現場では、賭け金は具体的です。重複したサプライヤーの記録は、購買から支払いまでの照合を壊し、ESRと一致しない従業員マスターは、人々に誤って支払い、一貫しない勘定科目表は、取締役会と監査人が頼るあらゆる下流の財務報告を損ないます。議論に値する緊張は、日付を守るために一括で移行する引力と、良い実践が求める、何か月にもわたる地味なクレンジングと重複排除、そして見える成果物のないデータ品質の作業の流れに、誰か上級の人が資金を出す意思があるかです。強い答えは、「データはほぼ問題ない」という漠然とした感覚ではなく、実際の数、つまり重複するサプライヤーがいくつ、照合されない従業員の記録がいくつあるかを挙げます。また、稼働の後のマスターデータの品質に説明責任を負う人とガバナンスの仕組みを名指しすべきです。一度クレンジングされ、そのあと統治されないデータは、単に無秩序へ戻っていくからです。

2. 馴染みのあるプロセスを守るために、ERPをカスタマイズしたくなるのは、どこか。そして、その違いは、本物の差別化要因か。それとも、逃れようとしている昔の混乱にすぎないか。 重いカスタマイズは、古典的な大企業のERPの罠です。コストを膨らませ、アップグレードのしやすさを壊し、プログラムが取り除くはずだった、まさにそのローカルな断片化を再び持ち込みます。特にクラウドERPは、「古いシステムのように見せたい」という本能を罰します。この問いは、チームに、どのプロセスにソフトウェアを曲げて合わせさせると主張するのかを具体的にし、それぞれを、真の差別化要因なのか、単に心地よい習慣なのかという厳しい試験に照らして正当化するよう求めます。この議論が重要なのは、医療・ケアでは、ほぼあらゆるバックオフィスのプロセス、つまり総勘定元帳、調達の承認、給与の管理が、本当にコモディティだからで、誠実な既定は、ベンダーやコンソーシアムの標準テンプレートを採用し、ソフトウェアではなくプロセスを変えることであるはずです。具体的な切り口には、求められたカスタマイズのすべてを列挙し、誰が利益を得るか、どんなアップグレードのコストをロックインするか、同じテンプレートの上にある隣のトラストが、それなしでやっていけているかを問うことが含まれます。良い答えは、まれな正当な例外を、変化への嫌悪に駆られた多くの要求から区別し、標準を採用することが、技術ではなく、チェンジマネジメントとリーダーシップの問題であることを認識します。長期的なコストにも向き合うべきです。特注の変更はすべて、将来のあらゆるクラウドのリリースで支払われる税です。

3. このERPの変更の、人とプロセスの側面、つまり切り替え、並行稼働、ハイパーケア、研修、連携テストに、誠実に資源を与えたか。それとも、静かにITプロジェクトとして運営しているか。 失敗についての文献は、ERPの苦痛のほとんどが、技術ではなく、人とプロセスであることに疑いを残しません。そのため、この問いは、プログラムが、本当にビジネス変革の取り組みなのか、プログラムの装いをしたITの入れ替えなのかを露わにします。稼働前後の期間は、サプライヤーへの支払いが滞り、月末が壊れ、職員の給与が遅れるときであり、公的な保健機関では、そのどれもが、粗い始まりではなく、信頼を損なう、ニュースになりうる失敗です。議論すべき緊張は、並行稼働を短縮し、ハイパーケアのチームを薄くし、押しつけられた日付に合わせてスケジュールを圧縮する絶え間ない圧力と、遅れた日付は取り戻せても、失敗した給与や元帳の切り替えは取り戻せないという現実の間にあります。有用な切り口には、あらゆる連携、つまりeロスタリング、ESR、薬局の在庫、銀行、アナリティクスをたどり、どれが端から端までテストされ、どれが想定されているだけかを問い、財務、調達、人事のプロセスの所有者が、ワークフローを再設計するために実際に出向していたかを問うことが含まれます。誠実な答えは、「ITが対応します」という一行ではなく、計画に、名前のあるチェンジマネジメント、研修、照合の資源を示し、ビッグバンの切り替えが回避可能なリスクを加えるところでは、進んで稼働を段階化します。進むかどうかの判断を統べるのは、カレンダーではなく、準備状況でなければならないことも認めるべきです。

4. 共有サービスとクラウドERPの問いについて、得られる標準化と、手放すローカルの柔軟性を比較考量したか。そして、既定ではなく、意図してその判断を下したか。 NHS SBSやコンソーシアムのOracle Cloudのインスタンスのような共有のプラットフォーム、そしてより広くクラウドERPは、規模の経済、継続的なアップグレード、より軽いローカルの導入とサポートの負担という、本物の賞を提供しますが、それらを、ローカルの統制の本物の喪失と、提供者のロードマップとリリースのリズムへの強い依存で買います。この問いは、チームに、自分たちにとって実際にどの柔軟性が重要かを名指しさせ、自前のバックオフィスを運営し、パッチを当て、別個にサポートするコストに値するかを試させます。医療・ケアの現場での緊張は、ほとんどのバックオフィスのプロセスがコモディティであるという事実によって鋭くなり、標準化の利得は、通常、失われる柔軟性を上回ります。しかし「通常」は「常に」ではなく、トレードオフを検討せずに共有のプラットフォームに流れていくことが、組織が、自分たちが意識的に選んだことのないテンプレートを恨む理由です。具体的な切り口には、チームがどのローカルなプロセスを守るために闘うのか、なぜか、コンソーシアムが足元でテンプレートを変えたら何が起きるか、そして署名する前に、退出とデータのポータビリティの条件が理解されているかを問うことが含まれます。強い答えは、これを、目を見開いて下す戦略的な選択として扱い、提供者への依存とロードマップのリスクを、規模とアップグレードの負担軽減と比較考量し、流行だから共有の選択肢に流れるのでも、習慣から特注のプラットフォームにしがみつくのでもありません。

5. 稼働後に、影の表計算とローカルな回避策が再び現れるのを止める、誠実な計画は何か。そうして、ERPが、多くの中の一つの情報源ではなく、単一の記録システムであり続けるように。 統合されたERPの要点は、影のシステムが生む断片化を取り除くことですが、ローカルな表計算は、稼働を生き延び、プログラムが統一するはずだったデータを静かに再び断片化する力を持っています。この問いは、チームが、切り替えの先、つまり、コストセンター、予算、調達の承認、労働力の定員が、誰かの私的なワークブックではなくERPの中に生きる、持続的な運用の規律まで考えたかを試します。これが医療・ケアで重要なのは、給与と一致しない影の定員の表計算や、システム外の調達の追跡表が、取締役会への報告と監査が依拠するデータ品質を静かに腐らせ、それがまさに、それを維持する人にとって便利だからです。表に出す価値のある緊張は、影のシステムには通常、理由があるということです。ERPのプロセスが遅く感じられた、あるいは本物のギャップが埋められなかった。したがって、単にそれを禁止しても、根底のニーズに対処しなければ失敗します。有用な切り口には、現在のどの表計算が稼働時に死ななければならないか、それぞれがなぜ存在するか、そしてどんなシステム内の能力やプロセスの変更が、それを再び作る誘惑を取り除くかを問うことが含まれます。誠実な答えは、ERPが権威あるものだという明確な期待を、人々をシステムの外へ追いやるギャップを直す計画と組み合わせ、影のシステムが再び現れたとき、誰がそれに気づいて異議を唱えるかを挙げます。

6. ERPプログラムのリスク、つまりセクターの超過と期待外れの実績について、本当に誠実か。そして、スケジュール、予備費、稼働のアプローチを、楽観的な計画ではなく、その現実に基づいて築いたか。 大規模なERPの導入は、時間とコストで超過し、便益で期待を下回るという、当然で、セクターをまたぐ評判を得ており、この問いは、チームがその失敗の文献を内面化したのか、自分たちはその例外だと静かに想定しているのかを問います。公的な保健機関での賭け金は容赦がありません。遅れた日付は取り戻せても、失敗した給与や元帳の切り替えは、議会と報道への帰結を伴う、ニュースになる、信頼を損なう出来事であり、準備状況を覆す楽観は、勇気ではなく無謀です。議論すべき緊張は、押しつけられた日付、サンクコスト、進捗を示したい願いからの、スケジュールを圧縮し、予備費を薄くし、より安全だがより遅い段階的な稼働よりも、ビッグバンの稼働を好む、絶え間ない圧力です。具体的な切り口には、計画が何がうまくいくと想定しているか、予備費が実際にどこにあるか、段階的な切り替えが可能か、そして準備ができていない場合に稼働を遅らせる、明示的な基準は何かを問うことが含まれます。良い答えは、ERPのリスクを一般論で示唆するのではなく、このプログラムが抱える具体的なリスクを挙げ、本物の予備費と擁護可能な段階化の判断を組み込み、データに基づく「まだです」を、気力の欠如ではなく、正当で想定される結果として扱います。

実践例：医療・ケアの事例#

あるNHSの急性期トラストは、ベンダーがまもなくサポートを打ち切る、15年ものオンプレミスの財務・調達システムを運用しています。報告には数日かかり、購買から支払いまでは手作業が多く、労働力の定員は、給与とどうしても一致しない表計算のもつれの中にあります。トラストは、近隣の提供者とともに、地域のNHSコンソーシアムのテンプレート化されたOracle Cloudのインスタンスを通じて提供される、クラウドERPへ移ることを決めます。

財務取締役は、これをITの入れ替えとして扱う誘惑に抵抗します。エグゼクティブの後援者、専任のプログラムマネージャー、そして決定的に、移行の前に、何か月もかけて勘定科目表をクレンジングし、1万2千のサプライヤーの記録を重複排除し、従業員マスターをESR（NHSの電子職員記録）と照合する、データ品質の作業の流れを伴うプログラムが立ち上げられます。財務、調達、人事のプロセスの所有者は、古いシステムを複製するのではなく、コンソーシアムのテンプレートに合わせて、ワークフローを再設計するために出向させられます。

トラストは、トラスト全体の単一のビッグバンではなく、段階的な稼働を選びます。財務と調達が最初、労働力と報告が後のウェーブで、二回の月末にわたる並行稼働と、待機する十分な人員のハイパーケアのチームを伴います。eロスタリング、銀行、アナリティクスのウェアハウスへの連携は、描き出され、端から端までテストされます。稼働は苦痛なしではありません。第1週にサプライヤーへの支払いのバックログが積み上がり、解消に2週間かかります。しかし、照合とハイパーケアに適切に資源が与えられたため、職員の給与が遅れることはなく、月末は期限どおりに締まります。

1年後、トラストは、帳簿を数週間ではなく数日で締め、調達の承認はシステム内で徹底され、定員はようやく給与と一致します。共有のコンソーシアムのプラットフォームは、次のアップグレードが、また複数年にわたるプロジェクトではなく、日常的なクラウドのリリースとして届くことも意味します。

セクター別の視点#

スタートアップ#

デジタルヘルスのスタートアップが、完全なERPを運営することはまれです。30人のチームには、重量級の統合スイートは不釣り合いなため、クラウドのSaaSツール、つまり軽量な会計パッケージ、人事・給与のアプリ、いくつかの表計算を縫い合わせます。それでも記録システムの規律は重要です。シード段階でも、一つのきれいな勘定科目表と、単一の権威ある給与のもとが、デューデリジェンスで投資家を遠ざける、照合の混乱を防ぎます。正しい動きは、スタックをシンプルで、連携でき、よく統治されたものに保ち、規模が本当にそれを求めるまで、「本物の」ERPを先送りすることです。スタートアップのリスクは、大企業の裏返しです。過剰なカスタマイズではなく、乱立です。マスターデータの所有者もなく、数字に責任を負う人もいない、十数の切り離されたアプリ。

小規模事業者#

確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設、訪問介護事業所、単独拠点のクリニックは、専任の財務やITの能力がほとんどないまま、財務、給与、調達の義務の全重量を負います。そのため、重量級のERPには手が届きませんが、記録システムの規律は任意ではありません。実践的な答えは、会計、給与、在庫という、小さく、よく連携されたクラウドのパッケージの組み合わせで、一つの勘定科目表と、単一の権威ある給与のもとが保たれるよう選ぶことです。職員に給与を遅れて支払う介護施設や、在庫と元帳が一致しない薬局は、大きなトラストと同じ規制上・資金上の帰結に直面しますが、それを吸収するバックオフィスのチームがないからです。創業者の表計算で事業を運営する誘惑は、ここで最も強く、最も危険です。数字がずれたとき、気づく人がほとんどいないからです。専門団体、フランチャイズ、地域のネットワークが、共有または標準化された財務のプラットフォームを提供している場合、それを採用することは、通常、賢明な動きです。組織が自分では資源を与えられない、標準化とサポートを買うのです。規律は、スタックをシンプルに保ち、お金を所有する人が統治し、その一人しか理解しない特注の回避策に抵抗することです。

大企業#

大規模なトラストやヘルステック企業は、完全な統合ERPを、ミッションクリティカルな記録システムとして運用しており、その置き換えは、試みる中で最もリスクの高いプログラムの一つです。大企業の誘惑は、馴染みのあるレガシーのプロセスを守るための重いカスタマイズです。規律は、標準テンプレートを採用し、本格的なデータ品質の作業の流れに資源を与え、並行稼働と十分な人員のハイパーケアの期間を伴って稼働させることです。連携は増えます。eロスタリング、ESR、薬局の在庫、銀行、アナリティクス。そしてそれぞれが、給与や月末の照合を静かに壊せば、信頼を損なう失敗になります。苦痛のほとんどが技術ではなく人とプロセスであるため、チェンジマネジメント（トピック8.1 — チェンジマネジメント参照）は、大企業のプログラムの勝敗が決まる場所です。取締役会と監査人への説明責任は、失敗した元帳や給与の切り替えを、単なるITの後退ではなく、ガバナンス上のインシデントにします。

政府#

国と共有サービスの規模では、ERPは標準化の手段です。NHS Shared Business ServicesとコンソーシアムのOracle Cloudのインスタンスは、多くの組織に一つのテンプレート化されたプラットフォームを与えるために存在し、ローカルの柔軟性を、規模の経済と継続的なアップグレードと引き換えにします。政府の説明責任は、あらゆる主要なERPの判断に、公共調達の精査（競争的なフレームワーク、費用対効果の保証）を加え、国の切り替えの失敗は、議会と報道への帰結を伴います。中央の本当の梃子は、招集することです。何十ものトラストと地方自治体が、それぞれ自前のバックオフィスを運営し、パッチを当て、別々に失敗しないよう、共有のプラットフォームを義務づけるか、奨励します。決定的な緊張は、国の標準化とローカルの自律の間にあります。テンプレートを強く押しすぎれば、採用は恨みの中で停滞し、弱すぎれば、ERPが取り除くために存在する断片化が、静かに残ります。

よくある失敗パターン#

• 汚れたマスターデータの一括移行。 古い重複と不一致が新しいシステムに持ち込まれ、初日から報告を損なう。対策：移行の前にマスターデータをクレンジングして統治し、その後も所有する。
• 古いシステムを複製するためのカスタマイズ。 プロセスの変更を避けるために行われる特注の変更は、コストを膨らませ、アップグレードのしやすさを壊す。対策：標準テンプレートを採用し、ソフトウェアではなくプロセスを変える。
• ITプロジェクトとして運営されるERP。 技術の入れ替えとして扱うと、変革、研修、プロセスの再設計の取り組みが飢える。対策：本物のチェンジマネジメント（トピック8.1）を伴う、ビジネス変革のプログラムとして運営する。
• 楽観的なビッグバンの稼働。 圧縮されたスケジュールと単一の切り替えが、通常の問題を公的な危機に変える。対策：可能なところでは段階化し、準備状況を日付と引き換えにしない。
• 壊れた連携。 テストされていないロスタリングから給与、調達から元帳へのフィードが、人々に誤って支払い、照合を壊す。対策：あらゆるインターフェースを描き、所有し、端から端までテストする。
• 影の表計算が生き延びる。 ローカルな回避策がERPと並んで存続し、データを再び断片化する。対策：ERPを単一の記録システムとし、影を廃止する。

成熟度モデル#

チェックリスト#

• 勘定科目表、サプライヤー、品目、従業員のマスターデータが、移行の前にクレンジングされ、重複排除されている。
• 継続的なマスターデータの所有とガバナンスが、割り当てられ、資金が出ている。
• 導入が、ITプロジェクトではなく、ビジネス変革のプログラムとして、範囲を定められ、資源を与えられている。
• カスタマイズが最小化され、コモディティのプロセスには、標準のベンダーまたはコンソーシアムのテンプレートが採用されている。
• あらゆる連携（ロスタリング、給与／ESR、臨床／薬局、銀行、アナリティクス）が、描かれ、所有され、端から端までテストされている。
• 稼働のアプローチ（ビッグバンか段階的か）が、押しつけられた日付ではなく、準備状況に基づいて選ばれている。
• データの切り替え、並行稼働、照合、ハイパーケアの期間が、計画され、人員が配置されている。
• チェンジマネジメント、研修、プロセスの再設計に、明示的に資源が与えられている（トピック8.1参照）。
• 共有サービスとクラウドERPの選択肢が、標準化と柔軟性の実際のトレードオフで評価されている。
• ERPが単一の記録システムとして確立され、影の表計算が廃止されている。

主要な情報源#

• NHS Shared Business Services (NHS SBS) — NHS組織のための、OracleベースのNHS全国の財務・調達の共有サービス。https://www.sbs.nhs.uk/
• Oracle, NHS Shared Business Services with Oracle Fusion Cloud Applications — NHS全国の財務プラットフォームの規模。https://www.oracle.com/uk/
• NHS North of England Commissioning / NEP consortium — NHSのメンバー向けの、テンプレート化されたOracle CloudのERP。https://nepcloud.nhs.uk/
• Unit4, Public sector and healthcare ERP — NHSトラスト、地方自治体、大学のためのERP。https://www.unit4.com/industries/public-sector-software
• HFMA (Healthcare Financial Management Association), Introductory Guide to NHS Finance — ERPが支える財務のプロセス。https://www.hfma.org.uk/
• NHS Electronic Staff Record (ESR) — ERPが連携しなければならない、NHSの労働力と給与のシステム。https://www.electronicstaffrecord.nhs.uk/
• トピック5.2 — プログラム主導の仕事、トピック5.3 — エンタープライズ・プロジェクト・ポートフォリオマネジメント（EPPM）、トピック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/