通信 ERP の導入: BSS、OSS、請求の統合

通信 ERP の導入は、ビジネス プロセス管理と技術的な通信インフラストラクチャの交差点に位置します。 ERP 導入に主にビジネス プロセスの変更が伴うほとんどの業界とは異なり、通信 ERP の導入には、独自の技術標準、データ モデル、リアルタイム パフォーマンス要件を持つ、プロビジョニング プラットフォーム、調停システム、請求エンジン、相互接続決済システムなどの特殊な通信システムとの統合が必要です。

このガイドでは、通信実装と商用実装を区別する BSS/OSS 統合アーキテクチャ、課金システムの移行、および加入者データ移行の課題に特に注意を払い、通信 ERP 実装のための実務者レベルのフレームワークを提供します。

重要なポイント

• BSS/OSS 統合アーキテクチャは実装を開始する前に設計する必要があります — レガシー システムの API 機能評価により統合アプローチが決定されます
• 請求の移行は最もリスクの高いコンポーネントです。請求システムのエラーはすべての加入者に同時に影響します
• 加入者データの移行には、カットオーバーの前に広範な重複排除とアカウント残高の調整が必要です
• 番号インベントリの移行には、番号ポータビリティ コンプライアンスのための完全な移行履歴を含める必要があります
• リアルタイム プロビジョニングの統合は、運用開始前に実稼働規模でテストする必要があります
• 従来の請求を廃止する前に、収益保証コントロールを使用量と請求額の完全な比較で検証する必要がある
• 規制報告書 (FCC Form 477、CPNI) は、最初の規制期限までに新しいシステムで検証される必要があります
• 通信税エンジンの統合は、すべてのサービス タイプ、管轄区域、および顧客タイプに対してテストする必要があります

---

実装前: BSS/OSS アーキテクチャの評価

ERP の導入を計画する前に、既存の BSS/OSS アーキテクチャの包括的な評価を実施します。この評価により、どのシステムが ERP 機能に置き換えられるか、どのシステムが ERP に統合されるか、どのシステムが別個のシステムとして残るかが決まります。

システムインベントリ

一般的な地域通信 BSS/OSS スタックには次のものが含まれます。

API 機能の評価

最も重要な技術的評価は、各レガシー システムの API 機能です。十分に文書化された REST API を備えたシステムは、リアルタイム統合をサポートします。古い W​​eb サービスまたは独自の API を使用するシステムにはミドルウェアが必要です。 API 機能のないシステムではバッチ ファイルの統合が必要となり、遅延と複雑さが生じます。

プロビジョニング システム (ほぼリアルタイムでサービスをアクティブ化する必要がある) では、API 統合の品質が重要です。バッチ ファイルの統合を必要とするプロビジョニング システムは、同日のサービス アクティベーションをサポートできません。これは、顧客エクスペリエンスの重大な欠点です。

---

フェーズ 1: 財務および人事基盤 (1 ～ 4 か月目)

財務と人事の実装は、通信固有の勘定科目表構成を使用して、他の業界の実装と同様に進められます。

電気通信勘定科目表

電気通信勘定科目表は、サービス タイプ別 (音声、データ、ビデオ、エンタープライズ)、顧客セグメント別 (家庭、中小企業、企業、卸売)、および地域別の収益認識をサポートする必要があります。相互接続の収益と費用は、小売収益とは別に追跡する必要があります。 FCC および州の報告のために、規制手数料と税金を種類ごとに追跡する必要があります。

規制報告の枠組み

FCC の報告要件（年次フォーム 477 ブロードバンド導入国勢調査や四半期ごとのフォーム 499 ユニバーサル サービス基金拠出者データなど）では、請求および顧客管理システムからの特定のデータが必要です。最初のレポート期間から ERP から規制レポートを生成できるように、財務モジュールは初日から必要なデータ要素を取得するように構成する必要があります。

---

フェーズ 2: 製品カタログとサービス プランの管理 (3 ～ 7 か月目)

製品カタログは、請求とプロビジョニングの両方を推進する中心的な構成要素です。注文できるすべてのサービス (すべてのプラン、すべてのアドオン、すべてのデバイスの分割払いオプション) は、請求やプロビジョニングが正しく機能する前に、製品カタログで定義する必要があります。

製品カタログの構成

通信製品カタログの構成は、製品定義とネットワーク プロビジョニング パラメータの関係により、ほとんどの業界よりも複雑です。

• 各サービス プランには、データ速度層、音声時間の割り当て、SMS の許容量、ローミング許可などのネットワーク パラメーターのセットがあります。
• 顧客がプランをアクティブ化するとき、それらのパラメータをプロビジョニング システムに送信する必要があります。
• 顧客がプランをアップグレードまたはダウングレードする場合、プロビジョニングの変更をリアルタイムで送信する必要があります

ERP 製品カタログは、これらのプロビジョニング属性を各製品定義に埋め込んで設計する必要があります。請求システムがプラン変更を生成すると、関連するプロビジョニング パラメータが、プロビジョニング システムに送信される変更要求に自動的に含まれます。

プロモーションとバンドル管理

電気通信のプロモーション (割引、バンドル価格、ロイヤルティ オファー) は頻繁かつ複雑です。携帯電話会社は、特定の適格性基準、期間、および価値を備えた 20 以上のプロモーション オファーを同時に実行することがあります。製品カタログは、それぞれに個別の請求システム構成を必要とせずに、これらのプロモーションをすべてサポートする必要があります。

---

フェーズ 3: 請求システムの移行または統合 (5 ～ 12 か月目)

請求の移行は、通信 ERP 導入の中で技術的に最も複雑で、運用上のリスクが高いコンポーネントです。すべての加入者に影響を与える請求エラーは、顧客サービス量の急増、規制上の苦情、収益への影響を同時に引き起こします。

置換か統合かの決定

MVNO および小規模事業者 (加入者数 100,000 人未満) の場合、従来の請求システムを ER​​P ネイティブの請求、または ERP と統合されたクラウド請求プラットフォームに置き換えることは、通常、正しい決定です。小規模事業者の従来の請求システムは、多くの場合、高額なサポート コストを伴う高価なライセンス プラットフォームです。それを最新の代替品に置き換えることで、コスト削減と機能の向上の両方が生まれます。

大規模な通信事業者 (加入者数 500,000 人以上) の場合、従来の請求システムには通常、通信事業者の特定の製品やプロモーションを処理するために長年にわたってカスタマイズされた複雑な評価ロジックが組み込まれています。このシステムを置き換えるには、このロジックをすべて新しいプラットフォームで再作成する必要がありますが、これはリスクの高い作業です。統合 - 格付けのための従来の請求システムを維持し、財務報告と顧客管理のための ERP の使用 - は、よりリスクの低いアプローチです。

請求データの移行

加入者カットオーバーのための請求データの移行には、以下が必要です。

1. アカウント残高の移行: すべての加入者の現在の残高 (発生したがまだ請求されていない料金、適用されたクレジット、受け取った支払い) を正確に移行する必要があります。加入者のアカウントで 1 ドルの残高エラーが発生すると、カスタマー サービスの連絡先が生成されます。

2. 請求サイクルの割り当て: 各加入者には毎月の請求サイクル、つまり請求書が生成される暦日があります。移行では、1 か月に 2 つの請求書が生成されたり、一部の加入者の請求書がスキップされたりすることを避けるために、既存の請求サイクルの割り当てを保持する必要があります。

3. 支払い方法の移行: Autopay 加入者には、支払い方法 (クレジット カード、銀行口座) が登録されています。これらの支払いトークンは、通常は支払いプロセッサによるトークン化転送を通じて、新しい請求システムに移行する必要があります。

4. 請求履歴の移行: 24 か月の請求履歴により、請求に関する紛争に十分なサポートが提供されます。より長い履歴は、移行されずにアーカイブされる場合があります。

請求の並行操作

請求の並行操作期間は、請求サイクル日ごとに少なくとも 1 つの完全な請求サイクルをカバーする必要があります (通常は丸 1 暦月が必要です)。並行運用中、従来の請求システムと新しい ERP 請求システムの両方が独立して請求書を生成します。結果は加入者ごとに比較され、不一致が特定されます。

並列動作を開始する前に、許容可能な許容しきい値を定義する必要があります。四捨五入による 0.01 ドルの差は許容されます。 10.00 ドルの差がある場合は、稼働前に調査が必要です。

---

フェーズ 4: プロビジョニング統合 (6 ～ 10 か月目)

プロビジョニング統合は、リアルタイムのミッションクリティカルな統合であり、ERP が加入者のライフサイクル イベントを管理できるようにするには、正しく機能する必要があります。

プロビジョニング API 統合

プロビジョニング統合では、すべての加入者のライフサイクル イベントを処理する必要があります。

• 新規加入者のアクティベーション: サービス プランのパラメータ、電話番号の割り当て、SIM の登録
• 計画変更: データと音声パラメータをリアルタイムで更新
• アドオンのアクティベーション: 加入者のプロフィールに追加された追加機能 (国際ローミング、プレミアム データ)
• 一時停止: 料金未払いによる一時停止 - 音声およびデータ サービスは緊急通話を維持したまま停止する必要があります。
• 再アクティブ化: 支払いが受領されると完全なサービスが再開されます。
• 終了: すべてのサービスを完全に無効化し、番号を在庫に戻します。

これらの各イベントは、運用展開の前にプロビジョニング システムのテスト環境でテストする必要があります。

プロビジョニング エラーの処理

プロビジョニングの失敗 (プロビジョニング コマンドがネットワークに送信されたものの実行に失敗する状況) は、通信運用ではよく発生します。 ERP はプロビジョニングの失敗を適切に処理する必要があります。

• プロビジョニング システムからのエラー コードを使用して失敗を記録します。
• 運用チームにアラートを生成します
• 一時的なエラーの場合はプロビジョニング コマンドを自動的に再試行します
• 永続的な障害については手動介入にエスカレーションします

適切なエラー処理がなければ、プロビジョニングが失敗すると、加入者はアクセスできないサービスに対して料金を請求されることになり、顧客からのエスカレーションや規制上の苦情への近道となります。

---

フェーズ 5: 数値在庫の移行 (4 ～ 8 か月目)

電話番号のインベントリ管理（どの番号が割り当てられているか、どの番号が利用可能であるか、および各番号の移植履歴を追跡する）は、通信固有の要件です。

在庫データ数

ERP 番号インベントリ モジュールは以下を維持する必要があります。

• オペレーターの在庫内のすべての番号と現在のステータス (利用可能、割り当て済み、移植中、移植中、予約済み、期限切れ)
• 各番号の加入者割り当て履歴
• トランザクション履歴の移植 — 番号が移植されるたびに、日付、受信キャリア、トランザクション ID が記録されます。
• 地理的指定 (各番号に関連付けられた料金中心地と州)

LNP コンプライアンス

ローカル番号ポータビリティ準拠では、オペレータは FCC が義務付けた期限内にポーティング要求を処理する必要があります。 ERP 移植ワークフローは次のことを行う必要があります。

• 送信後数分以内に通信事業者からの移植リクエストを受け入れる
• 番号とアカウント情報がオペレーターの記録と一致することを検証します。
• 必要な期間内に有効な移植リクエストを NPAC に送信します。
• 特定の拒否コードを使用して無効なリクエストを拒否します

リサイクル管理の数値

移植または放棄された番号は、新しい加入者に再割り当てされる前に「エージング」する必要があります。業界の慣例では、以前の加入者宛ての通話が新しい加入者に届く可能性を減らすために、解放された番号を再割り当て前に 90 ～ 180 日間エージングします。

---

フェーズ 6: 収益保証の統合 (8 ～ 14 か月目)

収益保証の統合により、利用されたすべてのサービスが正しく請求されることが保証されます。この統合により、ネットワーク使用量データと請求データが比較され、不一致が特定されます。

使用状況データの調整

収益保証の統合では、以下を調整する必要があります。

• 請求された使用量に対するネットワーク使用量記録 (仲介システムから)
• アクティブな料金プランに対して (プロビジョニング システムから) プロビジョニングされたサービス
• 資格基準に基づいて適用される割引とクレジット

不一致はタイプごとに分類され、調査のために適切な運用チームに送られます。大きな値の不一致 (しきい値を超える潜在的な漏洩) は直ちにエスカレーションされます。

---

通信 ERP の変更管理

カスタマーサービス担当者のトレーニング

CSR は、通信 ERP 導入にとって最も重要なユーザー グループです。彼らは、請求に関する問い合わせ、サービスの変更、苦情など、大量の顧客との連絡を処理しており、その効率は顧客満足度と運用コストに直接影響します。

CSR トレーニングは、集中的かつ実践的なものである必要があります。一般的な苦情の種類 (請求に関する紛争、サービスの問題、アップグレード要求) や、あまり一般的ではないが影響の大きいシナリオ (アカウント侵害、死亡した加入者、ビジネス アカウントの管理) など、実際のシステム シナリオでロール プレイを行います。

トレーニング指標には、平均処理時間、最初の問い合わせの解決率、エスカレーション率が含まれる必要があります。 ERP の稼働後にこれらの指標が悪化した場合は、トレーニング プログラムを修正する必要があります。

オペレーション センターの準備

ネットワーク オペレーション センター (NOC) は、既存のネットワーク監視の責任と並行して、ERP とプロビジョニングの統合を監視する準備を整える必要があります。統合健全性ダッシュボードは、ネットワーク パフォーマンス ダッシュボードと並んで NOC に表示される必要があります。

---

よくある質問

もう存在しない従来のプランの加入者の請求の移行はどのように処理すればよいですか?

提供されなくなった祖父プランの加入者には、移行の課題が生じます。新しい請求システムには、一致するプラン定義がない可能性があります。オプションは、新しいシステムで一致するプラン定義を作成する (古い価格設定と条件を無期限に維持する)、これらの加入者を最も近い同等の現行プランに移行する (適切な通知と潜在的な規制要件あり)、または自然減で加入者数が減少するまで、これらの加入者に対して読み取り専用モードで従来の請求システムを維持する、です。この決定は、祖父母となった加入者の数と、その特定の条件を移行する複雑さによって異なります。

請求システム移行エラーによる規制上の影響は何ですか?

州公共事業委員会 (PUC) または FCC への顧客からの苦情を引き起こす請求エラーは調査され、罰金、返金命令、および必要なシステム修復が発生する可能性があります。州の PUC 請求ルールは大きく異なります。請求システムを変更する前に顧客への通知を必要とするものや、エラー率の報告を必要とするものもあります。請求移行カットオーバーを実行する前に、顧客にサービスを提供する各州の請求規制を確認してください。

プロビジョニング システム統合中に 911 サービスの継続性を維持するにはどうすればよいですか?

E911 サービスの継続性は規制上の要件であり、安全性が重要な要件です。プロビジョニング統合では、ERP と E911 プロビジョニング システム (または自動位置情報システム) の間の継続的な接続を維持する必要があります。 E911 プロビジョニング パスに影響を与える可能性のある計画されたメンテナンス ウィンドウは、適切な州の E911 当局に事前に通知した場合にのみスケジュールする必要があります。テスト E911 コール (911 自体ではなくテスト番号に対する) は、プロビジョニング統合テスト スクリプトの一部である必要があります。

新しい ERP システムにおける CPNI 準拠のスケジュールはどのようなものですか?

CPNI (Customer Proprietary Network Information) コンプライアンスでは、顧客の使用状況データへのアクセスが許可された目的に制限され、顧客が特定のマーケティング利用をオプトアウトできる必要があります。 ERP が顧客データを使用して稼働する前に、CPNI ルールに準拠するようにアクセス制御を構成し、レガシー システムからオプトアウト設定を移行し、新しいシステム用に年次 CPNI 認定プロセスを文書化する必要があります。 FCC の年次 CPNI 認証の期限は 3 月 1 日です。次の認証期限までに少なくとも 60 日の余裕を持って ERP の稼働を計画してください。

プロビジョニング統合のレイテンシー要件はどのように管理すればよいですか?

リアルタイムのプロビジョニング変更 (プランのアクティブ化、一時停止、復元) は、通常、顧客と規制の期待に応えるために 60 ～ 120 秒以内に完了する必要があります。プロビジョニング API の統合は、このレイテンシー要件を念頭に置いて設計する必要があります。非同期処理は一括操作 (バッチ プランの移行) に使用する必要があり、一方、同期 API 呼び出しは、顧客がすぐに有効になることを期待する個々のサブスクライバー イベントを処理します。

---

次のステップ

ERP の最新化を計画している通信会社は、BSS/OSS アーキテクチャの評価と API 機能のレビューから始めて、既存の各システムの統合アプローチを決定する必要があります。 ECOSIRE の実装プラクティスは、プロビジョニング システム、請求プラットフォーム、規制報告システムと統合された通信 ERP 導入を実現します。

ECOSIRE の Odoo ERP 導入サービスを探索 して、当社の構造化された方法論が通信 ERP 導入特有の統合とデータ移行の課題にどのように対処しているかを学びましょう。