业务支撑系统标准化研究.ppt

中国移动集团级重点研发项目结题汇报报告,2011年12月1日,项目名称：业务支撑系统标准化研究,一.课题目标实现情况,目 录,二、主要研究成果（整合后）,2,1.1 研究背景及目标（开题报告）-背景简介1/4,业务支撑系统的标准化要求及规划规范体系,业务支撑系统的新业务支撑方案体系,1,2,3,1.1 研究背景及目标（开题报告）-背景简介2/4,不同的业务有不同的订购模式,不同业务的接口和流程异常处理不同,3,4,4,1.1 研究背景及目标（开题报告）-背景简介3/4,需要统一的、模板化的新业务支撑技术方案,完善业务网元与业支系统的规范方案体系,5,6,5,1.1 研究背景及目标（开题报告）-背景简介4/4,省业务支撑系统支持全产品运营的必要性,7,6,1.1 研究背景及目标（开题报告）-研究目标,业务支撑系统的标准化包括很多方面，但本课题着眼于业务支撑系统与业务网元之间的接口流程标准化、模板化以及业务支撑系统内部产品管理标准化,本项目2011年的工作主要着重在于完成以下几个接口的标准化研究工作以及标准化技术方案的制定：计费接口开通接口客服接口数据一致性接口全产品支撑管理,产品管理及服务,7,1.2 主要研究内容（开题报告）-业务支撑系统与业务网元接口与流程标准化,业务支撑系统与业务网元接口与流程标准化,计费接口及流程标准化,开通接口及流程标准化,客服接口及流程标准化,数据一致性接口及流程标准化,8,1.2 主要研究内容（开题报告）全产品支撑标准化能力和架构,重点研究全业务环境下，产品管理和开通流程对支撑能力标准化的要求，依据集团规范，运用SOA方法，构建一个对外能力标准化、内部结构标准化的全产品管理运营平台。,9,1.3 目标完成情况总结研究成果,均按计划完成,原计划34本，超计划完成,原无专利计划，超计划完成,10,在该项目工作中1）解决了xx项公司在市场发展和生产运营中存在的关键问题（如何解决，解决到了什么程度）现网新业务规范制定时计费、开通、客服、新产品支撑方案都是逐个的讨论，没有统一的原则参照，导致新业务支撑时间长，新业务上线初期支撑不够配套。本项目研究解决了上述问题，加快了新业务相关规范以及配套业务支撑方案制定的速度。2）挖掘了国内专利申请1项 一种实现实时消费提醒的装置和方法3）输出企业标准21个，形成企标初稿25个4）初步估计对企业绩效的贡献情况为（开放式回答）。提出了业务平台与业支系统之间的接口和流程通用要求，对所有业务平台和业务支撑方案提出统一模板化要求，更进一步完善业务网元与业支系统的规范方案体系，探索包括产品管理标准化、对外接口标准化、服务能力标准化以及基础平台标准化等支撑技术，提高新业务支撑需求响应速度。,1.3 目标完成情况总结,项目对企业绩效贡献的量化路径图,1.4 项目企业绩效贡献和特征指标,12,1.4 项目企业绩效贡献和特征指标,项目特征指标的年度预期数值表,13,一.课题目标实现情况,目 录,二、主要研究成果（整合后）,14,目录,开通部分,2,1,计费部分,客服部分,3,国际标准情况概览现网业务计费要求概览业务网元与业务支撑系统计费接口要求,数据一致性部分,4,全产品管理部分,5,15,3GPP中定义的计费标准体系,32.240：3GPP中纲领性的计费规范，定义了总体框架和原则32.250/32.251/32.260/32.270/32.271/32.272/32.273/32.274/32.275：定义了CS域、PS域、WLAN域、IMS子系统、MMS业务、LCS业务、PoC业务、MBMS业务、SMS业务、MMTel业务的计费框架、原则、流程和信息字段32.280：定义了GSM、IMS中计费通知业务的框架、原则、流程和信息字段32.295：定义了CDR文件传输的框架、原则、流程和信息字段32.296：定义了OCS系统的应用和接口32.297：定义了CDR文件的格式和传输要求32.298：定义了上述各类业务的CDR文件中包含的字段描述32.299：定义了基于Diameter的计费应用,16,32.240计费总体架构和原则要求,32.240对计费的总体架构和原则进行了定义，包括离线计费和在线计费,同时，从以下4个方面描述了计费原则：计费数据产生和配额监控计费数据传送，包括分割话单的合并处理要求计费数据关联原则计费数据处理原则,17,3GPP中各业务计费要求分册,3GPP中针对每个业务定义的计费标准主要包含以下4个部分，完整的定义了一个业务的离线和在线计费要求，非常值得借鉴,Architecture Considerations定义该业务的计费总体框架，包括该业务的网络图以及与计费系统的连接关系，包括了对离线计费和在线计费的描述Charging Principles定义该业务的计费总体原则，包括计费关联、主要计费要素、计费规则等Charging Scenarios描述计费场景和计费流程，针对该业务中的用户使用流程，定义相应的计费流程，包括离线计费在什么时候产生话单、在线计费在什么时候进行触发等Definition of charging information定义该业务中的计费信息字段，包括离线计费信息和在线计费信息,18,32.297通用CDR文件格式定义,32.297中定义了所有3GPP业务通用的CDR文件格式，包括CDR文件格式、CDR文件头格式、CDR记录头格式等，以及定义了CDR文件命名规则，还定义了对于CDR文件的处理规则，如大小、关闭时间等,CDR文件格式,CDR文件头格式,CDR记录头格式,19,32.298所有3GPP中各业务的CDR定义,32.298中定义了3GPP中各业务的CDR格式，详细定义了CDR中每个参数的含义，并通过ASN.1语法定义了CDR编码格式以及每个参数的类型、取值等,20,32.296 OCS应用及接口定义/32.299 Diameter计费应用定义,32.296定义了OCS的应用架构及实现流程，详细定义了OCS应用所需的AVP32.299定义了基于Diameter的离线和在线计费应用的网元与计费系统的交互流程，定义了异常处理要求，以及详细定义了Diameter的AVP,21,国际标准中值得借鉴的处理要求,完整的业务计费相关规范体系,业务计费场景和计费流程的详细描述,各业务离线计费和在线计费的统一定义,1,2,3,话单格式的统一定义,Diameter消息各字段的详细定义,4,5,22,目录,开通部分,2,1,计费部分,客服部分,3,国际标准情况概览现网业务计费要求概览业务网元与业务支撑系统计费接口要求,数据一致性部分,4,全产品管理部分,5,23,现网业务各规范中的计费要求,业务资费结构主要由功能费、信息费、通信费组成绝大部分业务平台并未明确业务流程中的计费触发要求，也未明确各种情况下CDR字段填写要求绝大部分业务并未定义在线计费接口,24,计费质量竞赛中发现的问题,网元优化典型问题如下：,25,大部分问题如果定义和测试多种业务场景下的计费正确性情况，则可以避免,那么，新业务规范中应该定义哪些计费相关的内容？入网时到底该进行哪些情况下的计费正确性测试呢？,26,目录,开通部分,2,1,计费部分,客服部分,3,国际标准情况概览现网业务计费要求概览业务网元与业务支撑系统计费接口要求,数据一致性部分,4,全产品管理部分,5,27,建议从以下几个方面对新业务计费进行定义,业务资费描述对业务的资费结构进行描述对资费结构中各种资费项的产生原则进行概述离线计费场景枚举各种业务使用场景下，话单产生的触发点以及话单中各字段的填写要求进行详细描述对业务使用产生异常流程情况下，话单中各字段的填写要求进行详细描述对于基于会话类的计费，对话单拆分要求进行详细描述在线计费场景枚举各种业务使用场景下，DCC消息产生的触发点以及DCC消息中各字段的填写要求进行详细描述对业务使用产生异常流程情况下，DCC消息中的字段填写要求进行详细描述离线计费话单定义依据统一的话单模板格式要求，定义CDR的各字段，并对其取值类型、范围进行描述对于离线计费话单产生原则、命名、传送要求等进行描述在线计费DCC消息字段定义定义业务专用的DCC消息字段，对其中各字段的取值类型、范围进行描述,28,离线计费要求场景概览,基于事件的离线计费流程参考,1,基于会话的离线计费流程参考,2,29,在线计费要求场景概览,直接扣取的基于事件的在线计费流程参考,1,配额保留的基于事件的在线计费流程参考,2,配额保留的基于会话的在线计费流程参考,3,30,目录,开通部分,2,1,计费部分,客服部分,3,国际标准情况概览现网业务开通流程概览业务网元与业务支撑系统开通接口要求,数据一致性部分,4,全产品管理部分,5,31,3GPP中的业务开通标准体系,3GPP SuM主要关注：3GPP中所定义的业务、资源的配置与激活，而对于3GPP范围外的新业务、客户订单请求、合作伙伴的同步处理等并未关注,32,OSS/J中定义的开通标准,OSS/J的开通标准使用UML的方式将工单受理的角色和流程、以及相互之间的消息接口清楚、准确的表示出来，使用UML的方式将工单相关的类图以及类与类之间的关系清楚、准确的表示出来,33,国际标准中值得借鉴的处理要求,统一的业务开通处理流程,详细定义的开通处理接口,详细定义的开通处理信息,1,2,3,34,目录,开通部分,2,1,计费部分,客服部分,3,国际标准情况概览现网业务开通流程概览业务网元与业务支撑系统开通接口要求,数据一致性部分,4,全产品管理部分,5,35,大纲现网业务开通流程概览,业务平台侧渠道受理客户的业务开通请求,1,业务平台侧渠道受理客户的业务开通需要二次确认时业务支撑系统向业务平台同步流程,2,业务支撑系统侧渠道受理客户的业务开通请求,3,业务支撑系统侧渠道根据用户状态变化自动向业务平台同步流程,4,36,业务平台侧渠道受理业务开通请求总体概况,19个全网业务平台中，仅BlackBerry不支持用户通过业务平台侧渠道进行业务开通支持业务平台侧渠道开通的18个业务平台中，仅宜居通业务只支持通过业务平台侧退订，其它业务均支持通过业务平台侧渠道进行订购、退订等完整的操作,37,业务平台侧渠道受理业务开通请求交易类型分析,支持业务平台侧渠道开通的18个业务平台中，业务平台侧渠道受理业务开通共存在3类流程：一个大圈类流程、两个大圈类流程、两个通知类流程,一个大圈类流程：视频会议业务、农信通业务、游戏业务、12580业务、手机导航业务、手机支付业务、VideoShare业务、多媒体彩铃业务、视频留言业务、MDO业务、彩像业务、手机动漫业务、宜居通业务、中央音乐业务,两个大圈类流程：CMMB业务,两个通知类流程：VGOP、VGOP-手机阅读业务,某个业务选择三种交易类型之一的依据是什么？,1,一个流程还是两个流程并不完全与是否需要二次确认相关，即使不需要二次确认，也采用两个流程的原因是什么？,2,38,业务平台侧渠道受理业务开通请求交易冲正、对账分析,支持业务平台侧渠道开通的18个业务平台中，规范中未明确是否需要冲正的有3个业务平台，其它15个业务平台在规范中明确不需要冲正上述18个业务平台中，业务平台侧发起的业务受理请求，均需要进行对账,规范明确不需要冲正：农信通业务、游戏业务、12580业务、手机导航业务、手机支付业务、多媒体彩铃业务、MDO业务、彩像业务、手机动漫业务、宜居通业务、CMMB业务、中央音乐业务、VGOP平台、VGOP-手机阅读业务,规范未明确是否需要冲正：视频会议业务、VideoShare业务、视频留言业务,基本上所有业务平台侧的业务受理请求均不需要冲正，那么在消息交互出现问题时，如何保障双方的数据一致性？,1,所有业务平台侧的业务受理请求均需要进行对账，目前的对账机制无法保障双方的数据一致性,2,39,大纲现网业务开通流程概览,业务平台侧渠道受理客户的业务开通请求,1,业务平台侧渠道受理客户的业务开通需要二次确认时业务支撑系统向业务平台同步流程,2,业务支撑系统侧渠道受理客户的业务开通请求,3,业务支撑系统侧渠道根据用户状态变化自动向业务平台同步流程,4,40,业务平台侧渠道受理业务开通需要二次确认时业务支撑系统向业务平台同步流程总体概况,共11个业务平台侧的短信渠道开通需要业务支撑系统与用户进行二次确认，业务支撑系统与用户进行二次确认后，业务支撑系统向业务平台同步业务受理信息,41,业务平台侧渠道受理业务开通需要二次确认时业务支撑系统向业务平台同步流程交易类型分析,在11个业务平台中，业务支撑系统向业务平台同步共存在3类流程：一个大圈类流程、一个通知类流程、两个通知类流程,一个通知类流程：农信通业务、中央音乐业务、VGOP平台、VGOP-手机阅读业务,两个通知类流程：游戏业务、12580业务、手机导航业务、MDO业务、彩像业务、手机动漫业务,一个大圈类流程：CMMB业务,某个业务选择三种交易类型之一的依据是什么？,1,同样是通知类的接口，为什么有的业务的第一条通知消息需要第二条通知消息的确认，而有的则不需要？,2,如果业务平台在同步确认结果中回复失败，那么省业务支撑系统是否回滚？,3,42,业务平台侧渠道受理业务开通需要二次确认时业务支撑系统向业务平台同步流程交易冲正、对账分析,在11个业务平台中，所有业务支撑系统向业务平台发起同步的流程，均不需要冲正上述18个业务平台中，业务平台侧发起的业务受理请求，9个业务的同步交易需要进行对账，2个业务的同步交易不需要进行对账,参与对账：农信通业务、游戏业务、12580业务、手机导航业务、MDO业务、彩像业务、手机动漫业务、CMMB业务、中央音乐业务,不参与对账：VGOP平台、VGOP手机阅读业务,基本上所有业务平台侧的业务受理请求均不需要冲正，那么在消息交互出现问题时，如何保障双方的数据一致性？,1,“是否需要对账”与“是否需要冲正”一般保持一种，但大部分业务平台未保持一致。目前的对账机制无法保障双方的数据一致性,3,同样的业务支撑系统向业务平台进行同步的交易，为什么其它业务均需要进行对账，而VGOP的明确不需要进行对账？,2,43,大纲现网业务开通流程概览,业务平台侧渠道受理客户的业务开通请求,1,业务平台侧渠道受理客户的业务开通需要二次确认时业务支撑系统向业务平台同步流程,2,业务支撑系统侧渠道受理客户的业务开通请求,3,业务支撑系统侧渠道根据用户状态变化自动向业务平台同步流程,4,44,业务支撑系统侧渠道受理业务开通请求总体概况,18个全网业务平台中，均支持从业务支撑系统侧渠道发起业务开通类请求18个业务平台中，仅手机支付业务支持从业务支撑系统侧渠道发起用户销户请求，其它业务平台均支持发起订购、退订等完整的开通类请求,45,业务支撑系统侧渠道受理业务开通请求消息处理方式分析,业务支撑系统侧渠道受理业务开通类请求，有三种消息处理方式：（1）采用业务平台向业务支撑系统发送的相同的消息方式进行处理；（2）单独定义了业务支撑系统向业务平台发送单独的消息方式；（3）以上两者同时具备,仅采用与业务平台侧相同的消息方式：视频会议业务、手机支付业务、VideoShare业务、多媒体彩铃业务、视频留言业务、,单独定义了与业务平台侧不同的消息方式：BlackBerry业务、农信通业务、手机导航业务、MDO业务、彩像业务、手机动漫业务、宜居通业务、CMMB业务、VGOP、VGOP-手机阅读业务,同时采用了两种消息方式：游戏业务、12580业务、中央音乐业务,某个业务选择三种消息处理方式之一的依据是什么？还是在不同的场景下使用不同的消息？在规范中并未明确,1,46,业务支撑系统侧渠道受理业务开通请求消息处理方式分析,消息处理方式1分析：在8个采用与业务平台侧相同的消息方式的业务开通请求的业务中，均采用大圈类的交易流程其中有5个明确不需要冲正，有三个规范中未明确所有的请求均参与对账,规范明确不需要冲正：游戏业务、12580业务、手机支付业务、多媒体彩铃业务、中央音乐业务,规范未明确是否需要冲正：视频会议业务、VideoShare业务、视频留言业务,消息处理方式2分析：在14个单独定义了消息方式的业务中，采用了一个大圈类、一个通知类、两个通知类三种交易流程只有BlackBerry业务的“一个大圈类”流程需要进行冲正，其它均不需要进行冲正所有的交易均参与对账,两个通知类流程：游戏业务、12580业务、手机导航业务、MDO业务、彩像业务、手机动漫业务、宜居通业务、VGOP平台、VGOP-手机阅读业务,一个大圈类流程：BlackBerry业务、CMMB业务,一个通知类流程：农信通业务、中央音乐业务,规范明确需要冲正：BlackBerry业务,规范明确不需要冲正：其它业务,一个大圈类流程：视频会议业务、VideoShare业务、视频留言业务、游戏业务、12580业务、手机支付业务、多媒体彩铃业务、中央音乐业务,47,业务支撑系统侧渠道受理业务开通请求主要问题,某个业务选择三种消息处理方式之一的依据是什么？还是在不同的场景下使用不同的消息？在规范中并未明确,1,“是否需要对账”与“是否需要冲正”一般保持一种，但大部分业务平台未保持一致。目前的对账机制无法保障双方的数据一致性,3,同样的业务支撑系统侧单独定义的受理用户请求的消息方式，存在一个大圈类、一个通知类、两个通知类流程，选择使用的依据是什么？,2,48,大纲现网业务开通流程概览,业务平台侧渠道受理客户的业务开通请求,1,业务平台侧渠道受理客户的业务开通需要二次确认时业务支撑系统向业务平台同步流程,2,业务支撑系统侧渠道受理客户的业务开通请求,3,业务支撑系统侧渠道根据用户状态变化自动向业务平台同步流程,4,49,业务支撑系统侧渠道根据用户状态变化自动向业务平台同步流程,所有18个全网业务平台均定义了业务支撑系统侧根据用户状态变化，自动向业务平台同步的流程和接口在所有具备前述方式2的14个业务平台中，只有CMMB采取了与方式2不同的消息方式（方式2采用一个大圈类流程、本同步采用两个通知类流程），其它的业务均采取了与方式2相同的消息方式在其它不具备前述方式2的5个业务平台中，同样定义了业务支撑系统侧根据用户状态变化自动向业务平台同步的流程和接口，只有手机支付平台采取了一个通知类流程，其它的均采取了两个通知类流程,50,目录,开通部分,2,1,计费部分,客服部分,3,国际标准情况概览现网业务开通流程概览业务网元与业务支撑系统开通接口要求,数据一致性部分,4,全产品管理部分,5,51,业务平台分类别统一业务开通流程,为每类业务平台定义统一的业务开通流程,52,业务开通接口要求,统一启用冲正机制由于订购关系决定着用户是否能够正常使用业务以及对用户的计费是否正确，因此，应该启用冲正机制明确定义在各种网络和流程异常情况下业务平台与业务支撑系统的处理要求在遇到网络故障、对方系统异常等各种情况下，明确系统对订购关系的回退机制、重发机制等增加在系统失效时的人工干预机制在系统无法自动处理失败时，增加人工干预机制,53,目录,开通部分,2,1,计费部分,客服部分,3,国际标准情况概览现网业务客服流程概览业务网元与业务支撑系统客服接口要求,数据一致性部分,4,全产品管理部分,5,54,OSS/J中定义的客服标准,OSS/J的客服标准主要聚焦于投诉工单的处理流程和接口定义。使用UML的方式将工单受理的角色和流程、以及相互之间的消息接口清楚、准确的表示出来，使用UML的方式将工单相关的类图以及类与类之间的关系清楚、准确的表示出来,55,国际标准中值得借鉴的处理要求,统一的客户投诉处理流程,详细定义的客户投诉处理接口,详细定义的客户投诉处理信息,1,2,3,56,目录,开通部分,2,1,计费部分,客服部分,3,国际标准情况概览现网业务客服流程概览业务网元与业务支撑系统客服接口要求,数据一致性部分,4,全产品管理部分,5,57,现网业务各规范中的客服要求,绝大部分业务平台未对客服功能模块提出详细的功能要求游戏、12580手机支付、MDO、手机动漫等对客服要求稍详细，但是仍然不够系统,58,客户投诉受理流程,各类业务的客服受理流程不完全相同，并未在相关规范中体现出来,省内投诉流程,跨省投诉流程,对SP投诉流程,59,目录,开通部分,2,1,计费部分,客服部分,3,国际标准情况概览现网业务客服流程概览业务网元与业务支撑系统客服接口要求,数据一致性部分,4,全产品管理部分,5,60,建议从以下几个方面对新业务客服进行定义,业务平台客服功能要求主要从客服投诉处理、客服工单处理、呼叫中心功能等三大部分功能进行描述客户服务流程描述对各类业务平台的客服受理流程进行详细的描述。业务平台的分类可能有本地业务平台、全网业务平台、网络部维护业务平台、基地维护业务平台、具备二线客服的业务平台、具备合作伙伴的业务平台等等纬度进行业务平台支持客服功能要求详细说明针对业务平台的不同分类，业务平台需要具备不同的客户服务支撑功能，以支持客服实现,61,业务平台客服功能要求1,由网络部维护的业务平台，系统维护人员从EOMS系统中获取用户投诉工单，并通过业务平台的客服投诉处理模块提供对客服功能模块的支撑,62,业务平台客服功能要求2,与客服系统之间存在投诉派发等接口的业务平台，需要支持工单处理模块，工单处理模块由系统维护人员操作，支持客服工单的受理、退回、投诉升级、投诉查询等操作,63,业务平台客服功能要求3,具备二线客服人员的业务平台，需要具备呼叫中心模块，接受客户呼叫或者从一线客服转过来的呼叫，客服人员使用工单处理模块记录客户服务请求,64,业务平台客服功能要求4,对于具备第三方合作伙伴提供业务或者内容的业务平台，其工单处理模块需要具备向第三方合作伙伴客服人员开放权限与操作的功能，供第三方合作伙伴客服人员处理客户投诉,65,目录,开通部分,2,1,计费部分,客服部分,3,数据一致性部分,4,全产品管理部分,5,66,数据一致性,在对数据一致性规范总册的基础之上，进行了局数据一致性、物联网PBOSS数据一致性等研究和技术方案的编写,67,目录,开通部分,2,1,计费部分,客服部分,3,数据一致性部分,4,全产品管理部分,5,68,重点研究全产品运营环境下，产品管理和开通流程对支撑能力标准化的要求，依据集团规范，运用SOA方法，构建一个对外能力标准化、内部结构标准化的全产品管理运营平台。,全产品支撑研究框架,69,难点及解决方案,在现有各业务平台上管理和销售的产品差异很大，将分散在各个平台上产品整合起来统一管理，产品模型标准化难度很大,构建标准的产品模型，将产品的资费和服务内容分离。资费由产品运营管理中心统一管理，服务内容由业务平台将其业务能力抽象为标准化服务，注册到产品运营管理中心，产品中心对不同平台上的服务可以执行相同的操作。,为了实现标准化产品的统一管理、统一销售和统一开通，需要在配置产品时使用标准的开通环节灵活组合开通流程。如何实现开通环节标准化和开通流程的灵活组合是主要困难。,屏蔽不同业务对平台（网元）的操作差异，按照业务口径将与一个业务相关的一个或多个平台操作，封装成某服务的开通、取消、暂停、恢复和属性变更这5个标准开通环节。将产品的开通流程和流程节点操作分离，在定义产品时只定义流程节点的施工顺序，流程节点的具体操作由代码固化。,70,全产品支撑技术方案和关键技术,以产品管理、销售和开通流程为核心，将产品管理、销售、开通和客户服务功能进行服务化改造，重构成产品配置服务中心，订单与销售中心、客户与订购关系中心；产品配置与服务中心：实现全业务、全渠道的产品管理；对各渠道提供一致的产品目录订单与销售中心：统一各渠道的订购和开通流程，实现一站式订购与退订客户与订购关系管理中心：负责统一订购关系管理，实现全渠道全业务的一站式查询,71,全产品支撑之服务化流程,实现一个完整的、独立的业务处理逻辑即为一个服务，人与系统间的一次交互、系统与系统之间的一次交互、系统内部功能域之间的一次交互作都可以为一个服务实现一个完整的、独立的的程序处理逻辑即为一个方法一组功能相近的方法围绕一个核心实体聚合成为一个组件,72,服务流程标准化方案,服务在服务注册管理平台上注册；服务的调用先从服务注册管理平台上进行寻址外部渠道通过接口平台进行适配，直接调用相应的服务营业前台界面通过页面适配框架匹配到服务，再调用相应服务流程引擎根据流程定义模板启动流程实例，调用流程中各节点对应的的服务,73,基于集团规范的设计思想，通过识别核心业务实体和实体间关系，产生概念模型。进一步分析构建数据实体，数据实体和数据属性形成逻辑模型，再进行物理模型设计。业务场景验证信息模型各阶段设计的完整性和正确性，不断迭代，以确保对现有业务的良好支撑,信息模型标准化流程,74,标准产品开通流程,产品开通流程也称为订单施工流程，包括4个子流程：订单分解、订单行分解、工单施工、订单竣工。1、订单分解流程将订单分解为订单行。2、订单行分解流程将订单行分解为工单。3、工单施工流程将工单按照平台施工协议组装成施工报文发送到各平台施工。4、订单竣工流程监控工单施工结果，以结束订单施工流程订单分解服务：订单分解服务是产品开通流程的起点，在产品订购流程的最后一个环节触发，其作用是将已生成的订单分解为订单行。订单行分解调度：订单行分解是指将订单行进一步分解为施工单。工单生成服务：根据待处理订单行的产品编码获得产品对应服务，通过服务和操作类型获取工单模板，生成工单信息。根据工单参数定义、数据项定义和取数SQL获得工单参数数据，经过字典转换后生成工单参数信息。工单施工调度：工单施工调度是对工单施工过程中可能发生的依赖施工、紧急施工等情况进行统一的调度，保证工单施工的准确性和及时性。工单发送服务：根据订单行号获得订单行下可发送的工单和工单参数，通过平台类型按照对应平台接口协议组装报文送平台施工，对于同步接口需等待处理结果。（异步接口见施工结果反馈服务）施工结果反馈服务：对于异步施工接口，等待施工平台处理完成后回调该服务向CRM反馈处理结果，根据反馈处理结果修改工单状态，部分特殊工单还需将结果登记到订单产品属性中。失败补偿机制：当工单施工失败或超时无反馈时，工单调度程序尝试重送工单施工。若重送次数达到设定阀值（默认3次或6次，可配置），则停止重送，放入失败工单表，等待人工干预。人工干预工单施工：当工单施工的失败补偿机制仍无法让施工成功时，需要人工介入干预工单施工过程。CRM前台提供了相应的订单监控、工单参数修改、工单重送等人工干预功能。工单重送服务：工单可重送次数加1，并调用工单发送服务进行工单重送。订单竣工调度：扫描订单行状态为处理中的记录，若订单行下所有工单都已施工完成则调用订单行竣工服务，然后判断相同施工序号的订单行是否均以竣工，若是则将下一个施工序号的订单行修改为待处理。若当前订单所有订单行均以竣工，则订单竣工，修改订单状态为已完成。订单行竣工服务：通过订单行号调用客户服务的资料归档服务，修改订购关系信息，同时修改订单行状态并迁移到订单行表。,75,产品订购标准流程,流程说明：使用鉴权号码进行鉴权：鉴权则做普通的记名产品订购退订，不鉴权则做不记名商品销售，其后流程一致；打开产品订购退订页面，页面的展示涉及组件：操作员权限检查：判断操作员是否有权限操作此菜单；业务规则检查：主要检查受理号码能否办理“产品订购退订业务”，例如用户停机不能办理产品订购普通产品目录树查询：用于展示页面左上边的普通产品目录树，例如商品目录、普通产品、数据业务产品；特色目录查询：用于展示页面左下边的特色产品目录树，例如新上线产品、热点产品；订购关系查询：用于展示页面右边中间的用户的已订购列表；用户信息查询：用于展示顶部的用户信息，例如品牌、号码等信息；在查询框输入产品名称，查询用户要订购的产品，涉及组件：用户可订购产品查询：根据用户输入的产品名称，模糊查询产品列表信息，判断搜索的产品是否上架到用户所属的主体产品上，如果有上架则允许订购，否则不允许订购，不展示在查询结果列表；点击可选产品列表中想要订购的产品前面的订购图标，将产品加入页面右边下面的购物车中，涉及组件：创建购物车：创建购物车；把订购的产品，放入购物车中保存；购物车更新：更新购物车中订购的列表及产品信息；点击下一步算费，将购物车提交，转到算费页面，并将订购的产品送予算费组件算费，将结果信息显示在算费页面，涉及组件：产品有效期计算：对订购的产品计算开始时间和结束时间，对退订的产品计算结束时间；产品订购约束检查：即分别对该产品做渠道类型检查、渠道编码(单位编码)检查、操作员检查、客户群检查、适用业务检查、禁止业务检查、号码模式检查等，检查该产品能否订购；产品算费：将订购产品信息送予订单费用计算组件以便该组件组装iLog算费所需入参信息，并将订单费用计算组件返回的算费结果信息返回算费页面；根据算费页面显示的费用信息，包括一次性营业费和月租费信息；向用户收取费用，支持现金、POS、积分单个或多个方式混合支付；打印受理单，客户签字确认办理此业务；之后点击业务提交按钮提交订购信息，涉及组件：订单提交：将订购的产品信息送予后台cics，后台预生成订购关系及生成订单对于需要占用资源的产品，调用资源售出或资源退还如果订购的的产品有需要立即扣取月租费的计费ID，则调用账务实时扣费接口，把对应余额扣减掉；如果前台使用支付支付，则调用账务积分变更接口，扣减客户积分；如果订购的产品需要冻结话费（例如订购打折打包的SP产品），则调用账务的冻结话费接口；打印票据，对于需要打印发票或收据的订单，调用票据打印组件，完成打印。,76,项目总结与展望,77,本项目就业务平台与业务支撑系统之间的接口与流程标准化（包括计费、开通、客服、数据一致性）以及全产品支撑方案进行了深入的研究，降低新业务需求出现时case-by-case的讨论支撑方案的缺点，提高新业务支撑需求响应速度,未来展望：基于本期业务平台与业务支撑系统接口与流程标准化模板的基础之上，未来对新业务的业务规范、总体技术要求、设备规范以及业务支撑技术方案均参照本模板进行接口与流程的制定在本项目的延续之后，基于通用的业务平台与业务支撑系统接口与流程制定细致的测试方案，并作为新业务平台实验室测试时的必选项目，从而保证新业务平台与业务支撑系统在实验室中就可以进行对接测试，保障上网之后的服务质量建议在全网范围内，集中制定核心业务能力标准化服务,结束,谢谢大家！,1.3 目标完成情况总结研究成果,研究报告,形成的软硬件平台,79,1.3 目标完成情况总结企业标准,80,1.3 目标完成情况总结企业标准,81,1.3 目标完成情况总结企业标准,82,1.3 目标完成情况总结企业标准,83,