中国电信光进铜退环境下服务开通系统的挑战与建设方案 · Oracle Approach: Product Model Concepts. 1.Commercial Offers, Bundles and Products mastered in a Product

第 0 页© 2010 Oracle 版权所有

<Insert Picture Here>

中国电信光进铜退环境下

服务开通系统的挑战与建设方案

2010年10月


提纲

• 中国电信光进铜退对IT支撑带来的挑战

• 服务开通系统改造的难点分析

• Oracle OSM 7 核心特点介绍

• 建设方案与演进思路

• 总结


中国电信光进铜退对IT支撑带来的挑战


光进铜退是传统网络向下一代网络演进中的一个环节


• 产品与接入方式的耦合度问题

• 多业务承载带来的订单拆分问题

• 多业务承载带来的流程组合几何级数增长问题

• 多业务承载带来的流程协同问题

• 多流程，多系统协同带来的在途变更的高复杂度

• 多业务承载带来的网络激活的协同问题

• 智能终端的管理问题

• FTTx相关的跨专业网络的资源设计问题

• FTTx资源管理与管线GIS以及ERP的关系问题

• 飞行中更换引擎 – 复杂环境下的系统演进问题

几大关键问题


服务开通系统改造的难点分析


多业务承载带来的订单拆分问题1

如今的业务开通过程

随着电信业务的发展，特别是小灵通、宽带、3G业务出现之后，以客户为中心的

运营理念的形成，带来对业务开通过程的挑战。

产品概念:电信提供的产品越来越丰富，提出销售品的概念，打包销售成为一

种必然。销售品是由产品包装而成，一个销售品可以包含多个产品。

业务受理:以客户为中心的受理模式，按销售品进行资费套餐等信息的采集，

按产品展开产品属性信息的采集。业务受理后形成一个客户订单，可能涉及多

个产品实例，延续“九七”的单一产品开通模式，就出现一个销售品、一个客

户订单、多个产品、多个定单的要求，也带来了订单分解。

开通流程:按产品进行流程设计，服务定单贯穿开通过程，服务开通间协同调

度

产品

订单

定单

1:1

1:1

1:1

销售品

产品

客户订单

服务定单

1:N

1:1

1:N

1:1

“九七”时代的业务开通过程

产品概念:电信提供的产品比较单一，以产品为中心的营销模式，没有销

售品的概念。

业务受理:业务受理过程主要是客户信息、产品信息(用户)、帐户信息的

采集过程。

受理完成形成一个客户订单，开通过程中称为定单，形成一个客户订单、

一个产品、一个定单的认识。

开通流程:按产品进行流程设计，订单(定单)贯穿开通过程

典型流程：受理配线配号配设备号施工竣工


多业务承载带来的订单拆分问题 – （续1）

• 订单拆分后移后：

• 产品定义的同步

• 订单的识别与验证问题：

• 订单的格式转换问题：

• 订单拆分的本质是：要找到产品定义与服务的映射。那么，与什么服务进行映射？资源服务吗？

• 如何定义产品之间的依赖关系：同样两个产品，在不同的场景中，依赖是不同的。例如，新装与拆机；或在不同的产品套餐中

1



• 来看一下TMF的SID对产品/服务/资源的关系的定义(CustomerFacingService的真正意义是什么)

1

Resource Domain

Product Domain

Service Domain

ComponentProduct Bundle

Logical

Marketing & Offer ManagementProduct & Offer Development

Service Development & ManagementService Management & OperationsService ConfigurationService Activation

Resource Development & ManagementResource Management & OperationsResource Provisioning

Physical

Customer DomainCustomer Relationship ManagementOrder Handling

Customer Facing Service

Product

Customer

Service Configuration

Resource

Service



• CustomerFacingService：• 面向网络的服务能力的封装：资源配置能力，网络激活

能力，安装能力，计费能力。这些能力可以是多个不同系统提供的。只有具备了这些能力，才能面对客户提供业务

• CustomerFacingService的封装过程是通过流程（或者称为类流程，排程）‘使能’的：仅仅选取所需的网络能力是不够的，这些能力的提供是有依赖以及顺序的。

• CustomerFacingService的封装过程是一个Central order management的过程，它起到承前启后的作用，一方面

接收前台订单，完成订单的校验和转换，另一方面组合并排程各个面向网络的能力。它与传统的开通流程系统是有区别的。我们传统的开通过程缺少这个重要的层次

1


多业务承载带来的流程组合几何级数增长问题

Service Plans Tariff Plans

Total 236

Total 99

23,364Variations!

Source: KTF Korea, 2007 Survey

2


Huge amount of Process！

Product Packages

Decommission

New

change

Suspend/resume

Move

FulfillmentMode

In-flightchange

X

Product bundle

多业务承载带来的流程组合几何级数增长问题-续12


If you have multiple separated system !!




• 解决的方法：

• 必须采用数据驱动的动态流程组装！

• 对于装拆移改等不同的动作，应能纳入统一的流程组装框架中

• 需要适应多个子流程由不同系统实现的模式，以实现灵活的系统架构和演进模式


3 多业务承载带来的流程协同问题

• 问题：

• 同一订单内不同产品开通的流程协同

• 不同订单之间的产品开通流程协同

• 跨产品的现场施工、报竣等环节的综合实施/操作


多流程，多系统协同带来的在途变更的高复杂度4

• 两种在途变更：

• 前端发起：修改单和退单等；

• 后端提出的异常（内部修改单）

• 多流程，多系统协同带来的在途变更的高复杂度：

• 回滚以及补偿的判断必须能够跨产品进行

• 回滚以及补偿的判断必须能够跨系统进行

• 同一个产品的在途变更，在不同的场景中可能是不同的，不能把变更流程固定死（必须是数据驱动的）


多业务承载带来的网络激活的协同问题

• 网络激活动作不再是单独的动作，它们是服务相关的。一个定单的开通可能涉及跨多个网络的激活动作

• 在途变更情况下，网络激活动作的回滚和补偿关系复杂

• 批量激活时，如何协调跨网络激活动作（例如需要挂起和resume的时候）

5


飞行中更换引擎 – 复杂环境下的系统演进问题

• 严酷的竞争环境下，业务不能等。光进铜退是关系中国电信未来发展的关键网络和业务演进

• 多个关联系统需要同步改造

• 数据驱动和动态流程，与传统的开通流程系统在概念上需要大的突破

6


飞行中更换引擎 – 复杂环境下的系统演进问题 – 续6

服务定单处理模块（传统意义上的服务定单处理流程）

中央定单排程模块（订单接收，转换，动态排程，系统交互）

CRM系统其他定单源

语音服务开通系统

视频服务开通系统

无线服务开通系统

IP服务开通系统

DSL服务开通系统

OM OM OM OM OM

如果我们能够有这样一个服务开通平台首先引入一个中央定单排程模块，实现传统开通系统难以实现的订单接收，转换，动态排程等

分散的服务定单处理流程可以根据需要逐步迁移到这个系统的服务定单处理模块

多个分散的系统可以实现有计划的逐步改造或者整合


Oracle OSM 7 核心特点介绍

1. 数据驱动的动态排程（Orchestration）

2. 数据驱动的智能在途变更处理

3. 数据驱动的动态页面生成技术

3.完备的系统整合框架


• 实现从前台系统获取服务定单

• 跨系统和人员协作实现服务定单

• 管理及协调整个服务开通过程

• 保证定单处理过程的可见性

• 智能化管理“在途变更”

• 支持人工及自动的工单处理

• 支持“fast time-to-market”的快速业务部署

OSM——定单协调与管理的中枢

BillingCRMCRM

Central Order Management

CRM Billing WFM Other

Service Order Management

Inventory Activation Other


OSM系统功能

Order and Service Management

基础功能Processes, Workflow, Tasks, Rules, Workgroups, Worklists etc.

订单支持Order Lifecycle Support, Order Editing, Order Tracking, Order Priorities, etc.

自动服务开通System integration, Performance,XQuery Plugin, JDBC, XSLT, Email

人工服务开通Human Interaction, Intelligent Order Editing,Views, Workstreams, User Assignment etc.

通用定单管理功能装、拆、移、改、挂起、恢复

在途订单变更

Cartridges

Platform

Monitoring

Reporting

Environment

CartridgesCartridges

报表

Design Studio

ProvisioningCartridges

PlatformEnablers

Valu

e

高级订单管理功能订单接收，订单分解，动态排程，订单关联,

后续订单, 计划订单, PoNR, 状态管理，Fallout Management

OrchestrationCartridges

Web UI

Provisioning

AIA COMM IntegrationOrder-To-Activate, Order-To-Bill,

Product Launch

Product MasterIntegration

用户管理

Orchestration

XQuery Plugin

Siebel CRMBRM

Order Delivery

Trouble Ticketing

Clustering


Oracle OSM 7 核心特点之一：

数据驱动的动态排程（Orchestration）


• Orchestration的英文翻译：（1）管弦乐（2）精心的安排

• Orchestration 在服务开通中的定义是：协调多个系统与人共同完成开通工作

• 动态排程与普通流程的区别是：

• 是以功能组件（或者称为服务，能力）为单位进行动态组装的

• 这些功能组件（或者称为服务，能力）可以由多个系统提供

• 动态排程还需要包括：

• 定单处理过程可见性

• 跨系统自动在途变更处理

• 人工与自动任务支持

在订单受理系统与多个定单执行系统之间协调

什么是动态排程（orchestration）


Oracle Approach: Product Model Concepts

1. Commercial Offers, Bundles and Products mastered in a Product Master

2. Commercial Products are associated with a Product Class in CRM

3. OSM synchronize product class definition from CRM

4. OSM define mapping between Products and Product Specifications

5. 0..n classes map to 1 product specification

6. In the Service Fulfillment Layer a Product Spec can map to one or more Technical Services and vice-versa

7. A Technical Service is composed of one or more Technical Services and Resources

Oracle Approach

Com

mer

cial

Off

erin

gsC

usto

mer

Ord

erFu

lfill

men

tSe

rvic

e O

rder

Fulf

illm

ent

Commercial Bundle

Commercial Offer

Technical Service

Resource

Commercial Product

ProductSpecification

Product Model

Com

mer

cial

Off

erin

gsC

usto

mer

Ord

erFu

lfill

men

tSe

rvic

e O

rder

Fulf

illm

ent

产品包(Product Bundle)

商品（Commercial offer)

技术服务（Technical Service)

资源(Resource)

产品（product)

产品规格（product Sepcification

Product Model

以不变应万变


Mapping between Product class and Product specification

Product Class Product Specfication

Standard_Internet_Class Internet_Service

HighSpeed_Internet_Class

Standard_PCS_Class PCS_Service

XXX

Standard_TV_Class TV_Service

XXX

Standard_VoIP_Class VoIP_Service

XXX


Order DeliverySolution Approach

Identification: Order ID; Order Number + Revision

Fulfillment ModeOrder PriorityOrder JobParent Order. . .

Identification: Order Line IDAction CodeFulfillment Item CodeProduct Type CodeBilling Type. . .

Order Header

Order Lines

Identification: Order Line IDAction CodeFulfillment Item CodeProduct Type CodeBilling Type. . .

. . .

Order Fulfillment Design Time Metadata

ProductSpec

Deliver

Qualify

ProductSpec

Deliver

Qualify

ProvisionOrder

Fulfill Billing

ShipOrder

FulfillBilling

PONRInitiateBilling

PONR

SyncCustomer

SyncCustomer

…

…

Key Take Away•Design decouples fulfillment flows from Commercial Offerings for:

• Significantly fewer fulfillment flows supporting a variety of commercial offerings and products specs

• Simple order line to fulfillment flow mapping• Launch more-of-the-same commercial offerings with

zero time spent on amending fulfillment flows• Support multiple order types (Deliver, Qualify, ..) to

match business needs


OSM Product Details: Generating an Orchestration Plan

Sales Order

Decomposition

Orchestration Plan

2. Determine Target Systems

3. Determine Processing Granularity

4. Generate Orchestration Plan from executable order

components and Product Spec dependencies

5. Determine Start Date/Time

Executable Order Components

1. Determine Fulfillment Functions


Oracle OSM 7 核心特点之二：

数据驱动的智能在途变更


2. 在执行定单过程中，OSM保留流程及所有定单数据的详细历史记录

OSM智能变更处理机制

以上情况也称为外部修改单。还有一种内部修改单的情况，是在流程的中间环节处，由于前面节点的输出不正确等情况而内部提出的异常

。

Fulfillment Processes

OrderChurn

(追单、撤单)

OriginalOrder

OrderData

Orders+

Changes

FulfillmentHistory

AnalyzeOptimize

Compensate

智能化定单变更处理

4. OSM分析原始定单和所有后续追单/撤单之间的差别，决定对所有变更的

最佳处理，并实时自动修订流程

1. 从原始定单中，OSM理解定单数据

3. 当定单在途过程中，一个或者多个追单或撤单提交时

＝》定单变更


OSM智能变更处理机制（续1）

竣工

交换维护中心施工

创建定单测量室施工

外线施工

派线派号

未执行执行成功图例：重新执行执行失败

数据创建定单派线派号测量施工交换施工外线施工完工

地址输出输入输入输入

MDF编号输出输入输入

MDF直列位置输出输入输入

线路局向输出输入输入

交接箱输出输入输入

分接箱输出输入输入

电话号码输出输入输入

设备号输出输入输入

MDF横列位置输出输入输入


采用OSM自动变更处理之前采用OSM自动变更处理之后

• 流程异常复杂

• 需大量代码进行定单匹配、差别分析和补偿分析

• 很难修改、重用和维护

• 永远无法满足所有场景

• 开发和维护成本高

• Slow-to-Market

• 流程简洁

• 预建的定单匹配、差别分析和补偿计划

• 易于修改，高度重用

• 可以满足目前和将来的服务场景

• 开发和维护成本低

• Fast-to-Market

OSM智能变更处理机制（续2）


Oracle OSM 7 核心特点之三：

数据驱动的动态页面生成技术


OSM动态页面生成技术View Framework

• View Framework 的特点：

• 数据驱动的动态页面生成

• 动态从外部系统获取数据

• 执行数据的运算 / 限制输入数据值的范围 / 提供栏目的缺省值等

• 提供多种与外部系统交互的 plug-ins:• SOAP Adapter

• XML File Adapter

• Database Adapter

• Order adapter

• XML Attachment Adapter


Relevant Rule Example

A Relevant Rule 可以根据定单中其他参数决定某个或者某些数据显示与否

当支付方式改变时，响应区域的详细信息会相应改变。这些无须编程或者通过多个页面来实现，而是完全数据驱动


Oracle OSM 7 核心特点之四：

完备的系统整合框架


OSM完备的系统整合框架

OSM WS API

OSMCore

AutomatedOrder Operations

Automated Tasks and

Notifications

Retrieve Data Dynamically into

Web Client(for Manual Tasks)

Order Source BOrder Source A

Activation

Inventory

CRM

Fulfillment System X

Fulfillment System Y

CRM


与第三方系统通过基于消息的机制进行系统整合

外部系统

Computational Plug-in 可以用于扩展OSM的功能，

例如增加用户自定义的业务逻辑 (分析、计算等)

JMS

/ E

AI /

ES

B

OSM

任务自动化定单流程

Task Event

Task A

Task B

Task D

Task C

Computational

Plug-in

Automation Plug-in Styles

Task Event

XSLT SenderPlug-in

JMS Message Queues

XSLT ReceiverPlug-in

ExternalDB

DBPlug-in

Task Event也提供直接数据的

接口方式

OSM完备的系统整合框架 – 续1

http://images.google.ca/imgres?imgurl=www.angolan.org/images/gear.gif&imgrefurl=http://www.angolan.org/economy1.html&h=179&w=261&prev=/images?q=gear&svnum=10&hl=en&lr=&ie=UTF-8&oe=UTF-8&sa=N�


AutomationPlugin

AutomationPlugin

AutomationPlugin

0 50 100

Prov'gtime

Fallout

OpEx

Revenue

System System

System

OSM完备的系统整合框架 – 续2 —— 持续渐进自动化支持

OSM

Deg

ree

of A

utom

atio

n

Ope

ratio

nal E

xper

tise

Req

uire

d fo

r Ser

vice

Del

iver

y

Service Deployment Maturity

Tria

ls

IncubateAdapt &Stabilize Optimize

Com

mer

cial

Laun

ch

Wid

e-sc

ale

Rol

l-out

Consumer ServicesBusiness Services

Mostly Manual

Proc

ess

Mat

urity

Mostly Manual

Semi-Automated

Semi-Automated

Full Flow-through Automation

Optimized Semi-Automation

ExcellenceInefficient Operational Efficiency

Carrier-Grade OSS

BT MOI

AT&TWiMAX

2/2.5G Mobile

TDM Voice

AT&TAVPN

Bell CdaIPTV

BTV21

BTVSERVE

Mobile

TelstraVoIPBT

ICT

A5 (ASAP)

A5 (IPSA)

TTM OSS

Gre

ates

tLe

ast

Deg

ree

of A

utom

atio

n

Ope

ratio

nal E

xper

tise

Req

uire

d fo

r Ser

vice

Del

iver

y


Tria

ls


Com

mer

cial

Laun

ch

Wid

e-sc

ale

Rol

l-out


Mostly Manual

Proc

ess

Mat

urity

Mostly Manual

Semi-Automated

Semi-Automated




Carrier-Grade OSS

BT MOI

AT&TWiMAX

2/2.5G Mobile

TDM Voice

AT&TAVPN

Bell CdaIPTV

BTV21

BTVSERVE

Mobile

TelstraVoIPBT

ICT

A5 (ASAP)

A5 (IPSA)

BT MOI

AT&TWiMAX

2/2.5G Mobile

TDM Voice

AT&TAVPN

Bell CdaIPTV

BTV21

BTVSERVE

Mobile

TelstraVoIPBT

ICT

A5 (ASAP)

A5 (IPSA)

TTM OSS

Gre

ates

tLe

ast


OSM

AutomationPlugins

AutomationPlugins

AutomationPlugins

AutomationPlugins

AutomationPlugins

AutomationPlugins

AutomationPlugins

0 50 100

Prov'gtime

Fallout

OpEx

Revenue

System System

System

System

SystemSystem

System

System

System

AutomationPlugin

AutomationPlugins

OSM完备的系统整合框架 – 续2 —— 持续渐进自动化支持

Deg

ree

of A

utom

atio

n

Ope

ratio

nal E

xper

tise

Req

uire

d fo

r Ser

vice

Del

iver

y


Tria

ls


Com

mer

cial

Laun

ch

Wid

e-sc

ale

Rol

l-out


Mostly Manual

Proc

ess

Mat

urity

Mostly Manual

Semi-Automated

Semi-Automated




Carrier-Grade OSS

BT MOI

AT&TWiMAX

2/2.5G Mobile

TDM Voice

AT&TAVPN

Bell CdaIPTV

BTV21

BTVSERVE

Mobile

TelstraVoIPBT

ICT

A5 (ASAP)

A5 (IPSA)

TTM OSS

Gre

ates

tLe

ast

Deg

ree

of A

utom

atio

n

Ope

ratio

nal E

xper

tise

Req

uire

d fo

r Ser

vice

Del

iver

y


Tria

ls


Com

mer

cial

Laun

ch

Wid

e-sc

ale

Rol

l-out


Mostly Manual

Proc

ess

Mat

urity

Mostly Manual

Semi-Automated

Semi-Automated




Carrier-Grade OSS

BT MOI

AT&TWiMAX

2/2.5G Mobile

TDM Voice

AT&TAVPN

Bell CdaIPTV

BTV21

BTVSERVE

Mobile

TelstraVoIPBT

ICT

A5 (ASAP)

A5 (IPSA)

BT MOI

AT&TWiMAX

2/2.5G Mobile

TDM Voice

AT&TAVPN

Bell CdaIPTV

BTV21

BTVSERVE

Mobile

TelstraVoIPBT

ICT

A5 (ASAP)

A5 (IPSA)

TTM OSS

Gre

ates

tLe

ast


建设方案与演进思路


建设方案需要考虑的因素

• 数据驱动与动态流程是解决多业务承载环境下诸多问题的必然选择

• 但是，数据驱动与动态流程在概念与架构上与传统开通系统有较大差别，较难实现一步到位的改造

• 各省/地区的IT架构有差别，较难要求统一的系统架构

• 市场压力大，业务支撑要求高，需要后端的快速响应


销售订单

排程

映射与转换

分解

系统建设方案 – 将整个服务开通过程分为两个层次建设

TV

服务定单

Voice

计费系统服务开通

发货

Internet Access

中央订单管理

服务定单管理(


系统演进策略

服务定单处理模块（传统意义上的服务定单处理流程）

中央定单排程模块（订单接收，转换，动态排程，系统交互）

CRM系统其他定单源

语音服务开通系统

视频服务开通系统

无线服务开通系统

IP服务开通系统

DSL服务开通系统

OM OM OM OM OM

首先引入一个中央定单排程模块，实现传统开通系统难以实现的订单接收，转换，动态排程等

分散的服务定单处理流程可以根据需要逐步迁移到这个系统的服务定单处理模块

多个分散的系统可以实现有计划的逐步改造或者整合。老系统的非数据驱动和非动态流程特性不影响整体的数据驱动和动态排程的改造


Q&A

第 45 页© 2010 Oracle 版权所有© 2009 Oracle Corporation – Proprietary and Confidential 45

Documents

中国电信光进铜退环境下 服务开通系统的挑战与建设方案 · Oracle Approach: Product Model Concepts. 1.Commercial Offers, Bundles and Products mastered in a Product

中国电信光进铜退环境下服务开通系统的挑战与建设方案 · Oracle Approach: Product Model Concepts. 1.Commercial Offers, Bundles and Products mastered in a Product