政府 ERP の導入: セキュリティ クリアランスとコンプライアンス

政府機関による ERP の導入は、大規模な企業導入による運用の複雑さと、商業的な導入では直面しない規制上の制約、政治的責任、およびセキュリティ要件を組み合わせています。 ERP を実装する機関は、構成を 1 行書く前に、競争調達ルール (実装自体が競争的に受注される必要がある)、FISMA セキュリティ要件、潜在的な FedRAMP 認可要件、監察総監の監視、および立法の予算承認サイクルを通過する必要があります。

このガイドでは、公共部門の導入と民間部門の導入を区別するセキュリティ、コンプライアンス、ガバナンスの要件に特に注意を払い、政府 ERP 導入のための実務者レベルのフレームワークを提供します。

重要なポイント

• 政府 ERP の調達自体が競争入札要件に準拠する必要がある - 導入開始前に調達に 12 ～ 18 か月の予算を立てる
• FISMA に準拠するには、運用環境で政府データを処理する前に正式な運用許可 (ATO) が必要です
• FedRAMP 認可 (連邦政府機関向け) または同等の州の要件によりクラウド ベンダーの選択が制約される
• 実装担当者のセキュリティ クリアランス要件により、ベンダーの人員配置のオプションが制限される可能性がある
• 法律による予算割り当てにより実装予算が制限され、大規模な IT 投資については別途認可が必要となる場合があります
• 監察総監と GAO による主要な IT プロジェクトの監督には、事前の文書化と透明性が必要です
• 政府のデータ分類要件は、アーキテクチャ、アクセス制御、監査ログ構成に影響を与えます
• 公務員環境における変更管理には組合との協議と正式な労働力移行計画が必要

---

実装前: 調達と法的認可

政府による ERP の調達自体は、導入を開始する前に完了する必要がある主要プロジェクトです。主要政府機関向け ERP の調達プロセスは、通常、要件定義から契約締結まで 12 ～ 24 か月かかります。

要件開発

政府調達法では、政府機関が提案を求める前に要件を定義することが求められています。政府機関は最初にベンダーを選択し、選択したベンダーの機能に基づいて要件を定義することはできません。要件の開発には次のことが含まれます。

• 現状の評価: 既存のシステム、その使用年数、機能のギャップ、およびそれらを維持するための推定コストを文書化します。
• ビジネス要件: 必要な特定の機能能力をモジュール (財務、調達、人事、助成金、市民サービス) ごとに整理して文書化します。
• 技術要件: 統合要件、データ量要件、パフォーマンス要件、セキュリティ要件 (FISMA レベル)、および相互運用性標準を指定します。
• 評価基準: 公募を発行する前に、割り当てられた重みを使用して提案を評価する基準を定義します。

要件文書は公的記録の一部となり、特定の製品を支持しているように見える場合、失敗したベンダーによる調達抗議の対象となります。要件はパフォーマンスベースであり、可能な限りテクノロジーに依存しないものでなければなりません。

競争的調達

政府 ERP の調達は通常、次の 2 つの手段のいずれかを通じて行われます。

• 完全かつオープンな競争: 公開広告、ベンダーの回答、技術評価、および最高価値の賞の決定を含む完全な提案依頼書 (RFP)
• 既存の政府契約手段: 多くの政府機関は、既に競争的な契約プロセスを完了した確立された複数の契約手段 (GSA スケジュール、SEWP、BPA ホルダー) を通じて ERP を調達しています。

既存の契約車両を使用すると、完全な競争と比較して調達時間を 12 ～ 18 か月短縮できます。ただし、代理店は、契約ビークルに必要な製品とサービスが含まれていること、およびビークル内でのタスク順序の競争が適切に競争されていることを確認する必要があります。

予算と立法上の認可

政府による大規模な IT 投資 (通常、定義されたしきい値を超える投資) には、別途立法上の認可が必要です。一部の管轄区域では、しきい値を超える資本 IT プロジェクトには、政府機関の営業予算とは別に、特定の予算項目の承認が必要です。この承認を取得すると、実装前のタイムラインに別のサイクルが追加されます。

政府機関は、主要な ERP の 24 ～ 36 か月の導入前期間 (初期計画から契約締結および法的認可まで) を計画し、このタイムラインをプロジェクト全体のスケジュールに組み込む必要があります。

---

FISMA への準拠と運用の認可

連邦情報セキュリティ管理法 (FISMA) では、すべての連邦情報システムが政府情報を処理、保存、送信する前に正式な運用許可 (ATO) を受け取ることが求められています。 ATO プロセスには、運用展開前に完了する必要がある包括的なセキュリティ評価が含まれます。

FISMA セキュリティ カテゴリ

FISMA では、情報システムを、機密性、完全性、可用性に対するセキュリティ侵害の潜在的な影響によって、各次元で低、中、高に分類することを要求しています。システム全体の分類により、NIST Special Publication 800-53 に基づいて必要なセキュリティ制御が決定されます。

ほとんどの政府金融システムは、3 つの側面すべてにおいて「中程度の影響」に分類されており、NIST 800-53 カタログにある約 300 のセキュリティ制御の実装が必要です。影響の大きいシステム (金融 ERP では一般的ではありません) には、追加の制御が必要です。

システムセキュリティプラン

FISMA の主要文書はシステム セキュリティ プラン (SSP) で、以下の内容が文書化されています。

• システム境界（認可境界にどのコンポーネントが含まれるか）
• システムによって処理されるデータの種類とその機密レベル
• 実装されているセキュリティ管理と、それが NIST 800-53 要件をどのように満たしているか
• ホスティング環境から継承したコントロール（共通コントロール）
• システム所有者の責任となる制御 (システム固有の制御)

複雑な ERP 実装用に SSP を準備すること自体が重要なプロジェクトであり、通常、経験豊富なセキュリティ専門家による文書化作業に 3 ～ 6 か月かかります。

セキュリティの評価と認可

SSP が完了すると、独立した評価チーム (認可された第三者、または実装チームとは別の内部評価チーム) がセキュリティ管理をテストし、文書どおりに機能することを確認します。評価により、結果を文書化したセキュリティ評価レポート (SAR) が生成されます。

認可担当官 (AO) は SSP と SAR をレビューし、ATO を付与するか、必要な是正を伴う条件付き ATO を発行するか、認可を拒否するかの認可決定を行います。 ATO は通常 3 年間発行され、その後は再評価が必要になります。

---

クラウド ERP の FedRAMP 認証

クラウド ホスト型 ERP を使用している連邦政府機関の場合、クラウド サービス プロバイダーは、適切な影響レベル (低、中、または高) で FedRAMP 承認を維持する必要があります。 FedRAMP 認定は、FedRAMP プログラムによって認定された第三者評価機関 (3PAO) によるクラウド プラットフォームのセキュリティ管理の正式な評価です。

ベンダー選択への影響

FedRAMP 認証要件は、クラウド ERP ベンダーの選択を大きく制限します。すべての商用 ERP ベンダーが、特に高影響レベルで FedRAMP 認可を取得しているわけではありません。政府機関は調達中に FedRAMP 承認ステータスを確認する必要があります。FedRAMP マーケットプレイス (marketplace.fedramp.gov) が信頼できる情報源です。

継承されたコントロール

FedRAMP 認定のクラウド プラットフォームを使用する大きな利点は、クラウド環境から共通のセキュリティ制御を継承できることです。物理的セキュリティ、環境制御、および一部の ID 管理機能に関連する制御は、クラウド プロバイダーの FedRAMP 認証パッケージに文書化されており、プラットフォームを使用して政府機関のシステムに継承できます。これにより、政府機関の ATO のセキュリティ文書作成の負担が軽減されます。

---

セキュリティクリアランス要件

政府機関の ERP 実装には、影響レベルの高い機密システムや機密だが機密ではない情報が含まれる場合、実装担当者にセキュリティ クリアランスが必要になる場合があります。この要件は、実装チームの構成とスケジュールに大きな影響を与える可能性があります。

人員安全調査プロセス

セキュリティクリアランスに必要な身元調査は、クリアランスレベルと個人の背景の複雑さに応じて、通常、完了までに3〜18か月かかります。導入ベンダーは、最も経験豊富なコンサルタントが必要な許可を取得していない場合、または取得できない場合、そのコンサルタントを割り当てることができない場合があります。

クリアランス制約の緩和

政府機関は次の方法でクリアランスの制約を緩和できます。

• 計画の早い段階で認可要件を特定し、契約締結前に主要な実装担当者向けの認可プロセスを開始する
• 機密データへのアクセスを必要とする ERP 設定作業に資格を持った担当者がさらされることを最小限に抑えるように実装を設計する
• 政府が提供する明確な技術アドバイザーを使用して、認可に敏感な構成作業を管理し、実装ベンダーが下位の分類レベルで機能に関する専門知識を提供します。

---

データの分類と処理

政府データは、ERP での処理方法に影響する複数のカテゴリに分類されます。

管理された非機密情報 (CUI)

CUI は、法律、規制、または政府全体の政策に基づく保護を必要とする政府情報の広範なカテゴリですが、機密レベルには達しません。財務 ERP には通常、従業員や請負業者の個人識別情報 (PII)、政府プログラムに関する財務情報、調達に関わる機密情報などの CUI が含まれています。

CUI 処理要件には、システム アクセス制御、監査ログ、転送制限、廃棄要件が含まれます。 ERP 構成では、CUI として指定された情報に対してデータ要素レベルで CUI 制御を強制する必要があります。

プライバシー法記録

政府職員および請負業者の記録は、プライバシー法の要件の対象となります。これにより、記録を説明する記録システム通知 (SORN) の維持、許可された目的への開示の制限、個人自身に関する記録へのアクセスの提供、および正確な記録の維持が義務付けられます。 ERP の実装には、プライバシー法の影響分析と、プライバシー法が適用される記録を維持するすべてのシステムに対する適切な管理を含める必要があります。

---

政府向けの実装段階

政府 ERP の導入には、会計年度の予算サイクル、法的監視、政府機関の運営カレンダーを考慮した段階的な実施が必要です。

フェーズ 1: 基礎と財務 (1 年目)

財務実装は、後続のすべてのモジュールが依存する資金会計構造を確立します。このフェーズには以下が含まれます。

• GASB のファンド構造に合わせた勘定科目表の設計
• 期首残高の移行と調整
• 予算の統合と予算引当会計の構成
• GAAP および GASB 財務諸表テンプレートの開発
• 年末決算プロセスの設計とテスト

会計年度は政府財政の自然な実行単位です。新しいシステムは、運用開始前に会計年度全体を最初から最後まで処理できるように準備されている必要があります。

フェーズ 2: 調達と契約管理 (2 年目、第 1 四半期～第 2 四半期)

調達トランザクションは総勘定元帳に転記されるため、調達の実行は財務に続きます。このフェーズには以下が含まれます。

• ベンダー データベースの移行と SAM.gov の統合
• 入札しきい値の設定とワークフロー
• 注文書と請求書のワークフロー
• 契約管理の設定
• MWBE 追跡設定

フェーズ 3: 人事および給与 (2 年目、第 3 四半期～第 4 四半期)

政府の人事および給与計算は、職位分類システム、労働組合契約、年金統合のため、実装が最も複雑なモジュールの 1 つです。このフェーズでは以下が必要です。

• ポジション分類スケジュール設定
• 給与水準と昇進ルール
• 交渉単位による組合契約期間の履行
• 特典管理設定
• 年金拠出金の計算設定

フェーズ 4: 補助金管理 (3 年目)

助成金管理は、GL財団の設立後に実施できます。このフェーズには以下が含まれます。

• 連邦特典のセットアップと追跡構成
• プログラムによる許容原価ルールの設定
• コスト配分方法の設定
• サブ受信者管理ワークフロー
• 連邦報告テンプレート構成 (SF-425、SF-270 など)

---

公務員環境における変更管理

政府機関の変更管理は、商業環境には存在しないいくつかの制約に直面しています。

組合協議の要件

労働組合が組織されている代理店では、ERP の導入を含む作業プロセスの大幅な変更により、労働協約に基づく交渉義務が生じる可能性があります。労働組合の契約では、多くの場合、政府機関が導入前に労働組合に通知し、技術変更が交渉部門の従業員に及ぼす影響について交渉することが求められます。

労働組合の代表者と早期に連携し、導入スケジュール、予想されるワークフローの変更、労働力の移行支援に対する政府機関の取り組みを説明することで、変更管理を成功させるために必要な協力関係を構築します。 ERP 導入中の敵対的な組合関係は、導入率の低下と苦情の増加に関連しています。

ポジション分類の影響

ERP の導入により、特定のポジションの性質が変化する可能性があります。つまり、一部の役割の複雑さは (自動化により) 軽減され、他の役割の複雑さは (新しいシステム管理責任により) 増加する可能性があります。職位分類システムでは、影響を受ける職位の正式な再分類が必要となる場合があり、これ自体が文書化、監督者のレビュー、場合によっては組合との協議を必要とします。

政府の学習環境でのトレーニング

政府の訓練プログラムは多くの場合、特定の要件に準拠する必要があります。民間機関は必須の学習管理システム (連邦機関向けの USA Learning など) を使用する場合があり、訓練は第 508 条に基づいて障害のある従業員が利用できるものでなければならず、訓練文書は必要な保存期間維持する必要があります。

---

監察官と監督の関与

政府の主要な IT プロジェクト、特に予算が 1,000 万ドルを超えるプロジェクトは、定期的に監察総局、立法監査機関 (GAO、州立法監査機関)、および立法監視委員会から監視の注目を集めています。監督機関との積極的な関与により、有害な所見が生じるリスクが軽減されます。

プロジェクト憲章とガバナンスに関する文書

プロジェクトガバナンスの包括的な文書を維持します。プロジェクト憲章、運営委員会憲章、重要な決定事項を文書化した会議議事録、正式なリスク登録簿などです。監督機関は、実装の成功の先行指標としてプロジェクト ガバナンスの質を評価します。

四半期ごとのステータスレポート

監督機関への定期的な状況報告を確立します。四半期ごとに書面による報告書が作成され、主要なマイルストーンでの説明会によって補足されます。ステータスレポートには、コストパフォーマンス（実績対計画）、スケジュールパフォーマンス（実績対計画）、主要なリスクと緩和措置、および今後のマイルストーンを含める必要があります。正確でタイムリーな状況報告は、監督機関との信頼性を築き、予期せぬ発見のリスクを軽減します。

独立した検証と検証

多くの政府機関は、独立した第三者である IV&V 請負業者に委託して、導入プロジェクトを継続的にレビューし、スケジュール、コスト、技術的リスクの客観的な評価を提供しています。 IV&V の関与は、説明責任への取り組みを示し、導入上の問題が危機に陥る前に早期に警​​告を発します。

---

導入後: 継続的なコンプライアンス

導入後、政府機関は FISMA、プライバシー、補助金管理要件への継続的なコンプライアンスを維持する必要があります。

年次セキュリティ評価

FISMA では、認可されたシステムのセキュリティを毎年レビューすることが義務付けられています。これらのレビューでは、セキュリティ管理が効果的に機能し続けていること、新しい脆弱性が特定されて修正されていること、およびシステム境界の文書が正確であることを検証します。

継続的な監視

継続的な監視に関する NIST のガイダンスでは、政府機関が 3 年ごとの再評価時点だけでなく、継続的にセキュリティ管理を監視することを期待しています。 ERP は、政府機関の継続的な監視プログラムに組み込まれる自動セキュリティ監視レポート (システム アクセス レポート、構成変更ログ、異常検出アラート) を生成する必要があります。

---

よくある質問

FedRAMP 認証プロセスにはどのくらい時間がかかりますか?

新しいクラウド サービスの FedRAMP 承認には、プログラムへの最初の関与から承認まで通常 12 ～ 24 か月かかります。政府機関は、FedRAMP Moderate の承認をすでに取得しているクラウド ERP ベンダーを選択することで、このスケジュールを短縮できます。つまり、セキュリティ評価がすでに完了しています。 FedRAMP マーケットプレイスには、現在の承認レベルで承認されたすべてのクラウド サービスがリストされます。

政府 ERP の Authority to Operate (ATO) プロセスのタイムラインとは何ですか?

ATO プロセスは通常、セキュリティ文書の作成の開始から認可の発行まで 6 ～ 12 か月かかります。これには、システム セキュリティ計画の準備に 3 ～ 6 か月、セキュリティ評価に 2 ～ 4 か月、認可担当者のレビューと決定に 1 ～ 2 か月が含まれます。既存の FedRAMP 認証を持つクラウド ERP を使用している政府機関は、継承された制御ドキュメントを活用して、独自の ATO プロセスを大幅に加速できます。

実装中に会計年度間の移行をどのように処理すればよいですか?

最も一般的なアプローチは、新会計年度の開始と同時に新しい ERP を導入し、前年度の期末残高を新システムの期首残高として移行することです。これにより、自然な会計境界に明確な区切りが生まれます。代替案 (年半ばに実施する方法) では、その年の財務データを 2 つのシステムに分割し、年次報告用に結合した結果を調整する必要がありますが、これは非常に複雑です。

政府の IT プロジェクトにおける GAO の高リスク要因は何ですか?

GAO は、失敗した実装の分析に基づいて、政府の IT プロジェクトのいくつかの高リスク要因を特定しました。それは、不透明なビジネス要件、脆弱なプロジェクト ガバナンス、不適切なプログラム管理要員配置、政府の監督が不十分な請負業者への過度の依存、技術的制約ではなく政治的制約による圧縮されたスケジュール、不十分なテスト時間です。これらのリスク要因のそれぞれに明示的に対処する実施計画は、監督機関に対して実施の準備ができていることを示します。

係争中の訴訟がある政府機関のレガシー システム移行をどのように管理すればよいですか?

政府機関では、レガシー システム記録へのアクセスを必要とする係争中の訴訟や行政手続きが頻繁に行われています。政府機関は、レガシー システムを廃止する前に、訴訟ホールドの対象となるすべての記録が法的に防御可能な形式で保存されていることを確認する必要があります。これには、訴訟が進行している間はレガシー システムへの読み取り専用アクセスを維持するか、訴訟関連の記録を保管過程の文書とともに個別に管理されるアーカイブに移行することが必要になる場合があります。

---

次のステップ

ERP の最新化を開始する準備ができている政府機関は、現在のシステム機能、FISMA 分類要件、および調達スケジュールの制約を包括的に評価することから始める必要があります。 ECOSIRE の公共部門の業務は、政府調達要件、FISMA コンプライアンス、および資金会計の実装に関する経験を公共部門の ERP 導入にもたらします。

ECOSIRE の Odoo ERP 導入サービスを探索 して、当社の構造化された方法論と公共部門の専門知識が貴機関の最新化への取り組みをどのように導くことができるかを学びましょう。