SP が Peppol ネットワークに参加する際には、
Onboarding and Accreditation of Peppol Service Providers が中核手順になる。

この手順では、流れは概ね次のように整理されている。

責任分担を表にすると次のとおりである。

ここでのポイントは、OpenPeppol が中央 testbed と PKI 手続を握り、PA が法域内の認定と契約を担い、SP が試験実施主体である という点である。

SP が本番運用に入った後の最低サービス品質は、Peppol Service Level Requirements で定義される。

この文書は、Peppol Service Provider Agreement に基づく最低要件として位置づけられている。

SLA 文書と explanatory note を読むと、SP に求められる主要責務は次のように整理できる。

SLA の本体は要件表であり、explanatory note は、
「どの時間区間を timeout や unavailable と測るか」
「backup and recovery の時間範囲をどう解釈するか」
を補足している。

したがって、日常運用の主体は SP だが、
その運用品質は Agreement + SLA + explanatory note という組合せで拘束される構造になっている。

Issue Reporting and Management は、
障害、相互運用問題、セキュリティ事故、情報漏えい、中央基盤障害などを扱う手順である。

この文書を運用フローとして読み直すと、報告経路は次のようになる。

ただし、SP は次のような場合には PA を経ずに直接 OpenPeppol へ行くことが認められている。

役割分担は次の表が分かりやすい。

ここでの要点は、PA は一次支援と一次判断を担うが、ネットワーク全体に関わる問題は OpenPeppol が二次対応する ことである。

Non-compliance Management は、
障害対応とは別に「ルール違反・契約違反・準拠違反」を扱う手順である。

これは運用上とても重要で、Issue Management が
「まずサービスを復旧・解決する」ことに重心があるのに対し、
Non-compliance Management は
「違反かどうかを認定し、是正させ、必要なら制裁する」ことに重心がある。

この手順を段階で並べると、おおむね次の順序になる。

責任分担を整理すると、次のようになる。

この構造から分かるのは、PA / Compliance Team が判断主体、OO が実行・公開主体 であることだ。
特に証明書停止やアクセス除去のような技術的実施は OO が担う。

Change Management は、Peppol Interoperability Framework の変更を扱う。
対象は、

の3群である。

サービス運用管理の観点で重要なのは、
OO が RFC の受付・登録・初期分析・割当を担い、CMB が評価し、MC や PAs が決定する という多段構造である。

特に agreements の変更では、
PA や SP も RFC 提出者になり得る。
一方、OO 自身も compliance activities、issue management、operational activities から改善点を見つけて RFC を起票できる。

また、変更管理は単に承認で終わらず、Migration Plan が重要である。
新旧 artefact の切替時期、必須化時期、旧版廃止時期、影響先、必要支援まで計画に入る。
そして OO は、その計画に従って artefact 公表、メール通知、移行支援の実務を担う。

これは、OpenPeppol が単なる「仕様の掲示板」ではなく、
運用移行まで含めた変更統制機能 を持っていることを示している。

PIF 総合ページで特に重要なのが PASR である。
ページでは、
新しい PIF の下では PASR が、当該 PA の管轄に所在する sender / receiver 顧客を持つ SP に自動適用されると説明されている。

OP - Peppol Authority Specific Requirements を読むと、
PASR の導入は自由放任ではなく、次の統制を受ける。

つまり PASR は、各国が好き勝手に追加条件を課す仕組みではなく、
各 PA のローカル要件を、OpenPeppol 全体の整合性の中で審査し公開する仕組み である。

さらにテンプレートを見ると、PASR の対象は単なる法的要件だけではない。

といった項目が並んでいる。

これは、PA が自国ルールを追加できる領域が、
識別、セキュリティ、報告、SLA、認定 まで及ぶことを意味する。

Extended Use は、既存の global Service Domain を越えて、
ローカル extension や Local Service Domain を導入する手順である。

ここでも主導権は PA にある。
PA が RFC を起票し、OO が Extended Use Register に登録し、
影響評価・関係者 consultation・推薦・MC 決定・公表へ進む。

この手順は、技術仕様の新規導入そのものというより、
ローカルな業務領域や文書拡張を、Peppol 全体の運用秩序の中で認める手続 である。

運用管理上の意味は明快で、
「ローカル拡張はできるが、勝手に network 外延を広げるのではなく、OO と MC が全体整合を確認する」
という統制になっている。

報告の観点で最も明示的なのが、End User Statistics Reporting である。

Peppol End User Statistics Reporting Process は、
SP が Reporting Period ごとに End User Statistics Report を OpenPeppol へ送る仕様を定めている。
このページによれば、SP は次を行う。

一方、OO は次を行う。

ここに、OpenPeppol と PA の関係が非常によく表れている。

つまり、中央集約報告 + 法域監督 の二層構造である。

この報告の特徴を整理すると次のようになる。

この仕組みは、Peppol が単なるメッセージ配送網ではなく、
ネットワーク運営のための中央モニタリング機能 を持つことを示している。

OpenPeppol は、単なる「標準化団体」ではなく、
中央基盤・中央登録・中央手続・中央公開・中央モニタリング を担う運営主体である。

特に OO は、

を担っており、実務上はかなり強い運営機能を持つ。

PA は、各法域での 契約・認定・監督・一次支援 を担う。

つまり PA は、単にローカル事情を主張する組織ではなく、

であり、法域内の運用管理責任者 に近い。

SP は、単なる接続事業者ではなく、

まで含めて責任を負う。

したがって、Peppol の SP は「AS4 でつなぐだけの事業者」ではなく、
ガバナンス文書に組み込まれた運用責任主体 である。

上記 Peppol Interoperability Framework B4. Operational Procedures より