电信 ERP 实施：BSS、OSS 和计费集成

电信 ERP 实施位于业务流程管理和技术电信基础设施的交叉点。与大多数行业的 ERP 实施主要涉及业务流程变更不同，电信 ERP 实施需要与专门的电信系统（供应平台、中介系统、计费引擎和互连结算系统）集成，这些系统有自己的技术标准、数据模型和实时性能要求。

本指南提供了电信 ERP 实施的从业者级框架，特别关注 BSS/OSS 集成架构、计费系统迁移和用户数据迁移挑战，这些挑战是电信实施与商业实施的区别。

要点

• BSS/OSS集成架构必须在实施开始之前设计——遗留系统的API能力评估决定集成方式
• 计费迁移是风险最高的部分 - 计费系统错误会同时影响所有订阅者
• 订阅者数据迁移需要在切换之前进行大量重复数据删除和帐户余额核对
• 号码清单迁移必须包括完整的携号转网历史记录，以确保号码可携性合规性
• 实时配置集成必须在上线前进行生产规模测试
• 在旧计费退役之前，必须通过完整的使用情况与账单比较来验证收入保证控制
• 监管报告（FCC 表 477、CPNI）必须在第一个监管截止日期之前在新系统中进行验证
• 必须针对所有服务类型、司法管辖区和客户类型测试电信税务引擎集成

---

实施前：BSS/OSS 架构评估

在规划ERP实施之前，对现有的BSS/OSS架构进行全面评估。该评估确定哪些系统将被 ERP 功能取代、哪些系统将与 ERP 集成、哪些系统将保留为单独的系统。

系统库存

典型的区域电信 BSS/OSS 堆栈包括：

API能力评估

最重要的技术评估是每个遗留系统的API能力。具有详细记录的 REST API 的系统支持实时集成。具有较旧 Web 服务或专有 API 的系统需要中间件。没有 API 功能的系统需要批处理文件集成 - 引入延迟和复杂性。

对于供应系统（必须近乎实时地激活服务），API 集成质量至关重要。需要批处理文件集成的供应系统无法支持当天的服务激活——这是一个重大的客户体验劣势。

---

第 1 阶段：财务和人力资源基础（第 1-4 个月）

财务和人力资源实施的过程与其他行业实施类似，具有电信特定的会计科目表配置。

电信会计科目表

电信会计科目表必须支持按服务类型（语音、数据、视频、企业）、客户群（住宅、中小企业、企业、批发）和地理位置进行收入确认。互连收入和支出必须与零售收入分开跟踪。必须按类型跟踪监管费用和税费，以供 FCC 和州报告。

监管报告框架

FCC 报告要求（包括年度 477 表格宽带部署普查和季度 499 表格普遍服务基金贡献者数据）需要来自计费和客户管理系统的特定数据。财务模块必须配置为从第一天起就捕获必要的数据元素，以便从第一个报告期起就可以从 ERP 生成监管报告。

---

第 2 阶段：产品目录和服务计划管理（第 3-7 个月）

产品目录是驱动计费和配置的中央配置元素。每项可订购的服务（每个计划、每个附加组件、每个设备安装选项）都必须在产品目录中定义，然后计费或配置才能正常运行。

产品目录配置

由于产品定义和网络配置参数之间的关系，电信产品目录配置比大多数行业更复杂：

• 每个服务计划都有一组网络参数：数据速度等级、语音分钟分配、短信限额、漫游权限
• 当客户激活计划时，这些参数必须传输到供应系统
• 当客户升级或降级其计划时，配置更改必须实时传输

ERP 产品目录的设计必须将这些供应属性嵌入到每个产品定义中。当计费系统生成计划变更时，相关的供应参数会自动包含在传输到供应系统的变更单中。

促销和捆绑管理

电信促销活动——折扣、捆绑定价、忠诚度优惠——频繁且复杂。移动运营商可以在任何给定时间同时提供 20 多个促销优惠，每个促销优惠都有特定的资格标准、持续时间和价值。产品目录必须支持所有这些促销活动，而不需要为每一项促销活动单独配置计费系统。

---

第 3 阶段：计费系统迁移或集成（第 5-12 个月）

计费迁移是电信 ERP 实施中技术最复杂、运营风险最高的部分。影响所有订户的计费错误会同时导致客户服务量激增、监管投诉和收入影响。

替换与集成决策

对于 MVNO 和小型运营商（订阅用户数低于 100,000 名）来说，用 ERP 原生计费或与 ERP 集成的云计费平台替换传统计费系统通常是正确的决定。小型运营商的传统计费系统通常是昂贵的许可平台，支持成本很高；用现代替代品替换它既可以节省成本，又可以提高性能。

对于大型运营商（超过 500,000 名用户），传统计费系统通常具有复杂的评级逻辑​​，这些逻辑经过多年定制，可以处理运营商的特定产品和促销活动。更换这个系统需要在新平台中重新创建所有这些逻辑——这是一项高风险的工作。集成——维护遗留计费系统进行评级并使用 ERP 进行财务报告和客户管理——是风险较低的方法。

计费数据迁移

用户割接的计费数据迁移需要：

1. 帐户余额迁移：每个订户的当前余额（应计但尚未计费的费用、已应用的积分、收到的付款）必须准确迁移。订户帐户中 1 美元的余额错误会生成客户服务联系人。

2. 账单周期分配：每个订阅者都有一个每月账单周期 - 生成发票的日历日。迁移必须保留现有的账单周期分配，以避免在一个月内生成两张账单或跳过某些订阅者的账单。

3. 付款方式迁移：自动转账订阅者已存档付款方式（信用卡、银行账户）。这些支付令牌必须迁移到新的计费系统，通常通过支付处理器进行令牌化传输。

4、账单历史迁移：24个月的账单历史为账单争议提供了充足的支撑；较长的历史记录可以存档而不是迁移。

计费并行操作

计费并行操作期间应至少涵盖每个计费周期日期的一个完整计费周期（通常需要一个完整的日历月）。在并行操作过程中，旧的计费系统和新的 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（客户专有网络信息）合规性要求对客户使用数据的访问仅限于授权目的，并且客户能够选择退出某些营销用途。在 ERP 与客户数据一起上线之前，必须配置访问控制以符合 CPNI 规则，必须迁移旧系统中的退出首选项，并且必须记录新系统的年度 CPNI 认证流程。 FCC 年度 CPNI 认证截止日期为 3 月 1 日 - 计划 ERP 上线，以便在下一个认证截止日期之前至少留出 60 天的时间。

我们如何管理配置集成延迟要求？

实时配置更改（计划激活、暂停、恢复）通常必须在 60-120 秒内完成，以满足客户和监管机构的期望。设计配置 API 集成时必须考虑到这种延迟要求：异步处理应用于批量操作（批量计划迁移），而同步 API 调用则处理客户期望立即生效的各个订阅者事件。

---

后续步骤

规划 ERP 现代化的电信公司应从 BSS/OSS 架构评估和 API 功能审查开始，以确定每个现有系统的集成方法。 ECOSIRE 的实施实践提供了与供应系统、计费平台和监管报告系统集成的电信 ERP 部署。

探索 ECOSIRE 的 Odoo ERP 实施服务，了解我们的结构化方法如何解决电信 ERP 实施中独特的集成和数据迁移挑战。