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

l 研发项目结题报告项目名称及编号业务支撑系统标准化研究主要研究单位及负责人（联系方式）其他研究单位及负责人（联系方式）是否集团级重点项目(是/否)否是否联合研发项目（是/否）； 是项目经费（万元）0项目起止时间2011年5月 2011年12月专业类别业务支撑研究类别现有业务优化关键词索引（35个）业务平台与业务支撑系统接口标准化 业务标准化 服务标准化该项目在研究单位内部的评审结果优秀该项目在研究单位内部的评审意见：描述评审专家组对该项目在技术先进性，创新性，取得的总体效益，可推广性等方面的评价。（1）该项目的子项目业务支撑系统与业务网元接口流程标准化研究在研究院内的评审意见为：该项目对现网近20个业务平台与业务支撑系统之间的接口、流程进行了仔细的分析，就业务平台的计费、开通、客服、数据一致性等四个重要方面进行了深入的研究，提出了业务平台与业支系统之间的接口和流程通用要求，对所有业务平台和业务支撑方案提出统一模板化要求，更进一步完善业务网元与业支系统的规范方案体系，促进业务网元与业支系统的的接口与流程模板化、标准化。该项目的成果可以指导业务支撑系统与业务平台采取公共的机制进行交互、并在公共机制的基础上针对业务进行个性化定制，降低新业务需求出现时case-by-case的讨论支撑方案的缺点，提高新业务支撑需求响应速度，对未来新业务平台的业务规范、总体技术要求、设备规范中的业务支撑相关部分以及相应的业务支撑技术方案的制定，有很好的模板参考意义。（2）该项目的子项目全产品支撑标准化能力和架构研究在广东公司内的评审意见为：该项目依据集团关于业务支撑标准化的相关规范和指导意见，借鉴业界先进的系统架构和分析方法论，对广东移动的CRM/BOSS支撑范围内对业务能力和系统架构、开发过程进行标准化研究，包括产品管理标准化、对外接口标准化、服务能力标准化以及基础平台标准化等研究。该项目立足现有业务支撑体系，探索大规模集中化支撑体系建设经验，通过从业务到基础设施平台的研究和分析，为大规模集中化业务支撑体系建设提供建设经验，为集中化建设提供业务、技术以及管理思路。项目研究成果简介：1、简要总结该项目的目的和意义，解决的问题、解决方案、项目研究成果、专利、标准、新技术试验等方面目标及其承担单位的完成情况。2、若项目输出无软件成果，则填“无”；若有软件成果，则填写软件名称，并对软件总体情况、软件版权归属情况、软件版权登记号、后续推广对象（不限于公司内部）、应用前景等情况予以说明。本项目的目的是是针对此项需求研究制定业务网元与业支系统之间的接口和流程通用要求，对所有业务网元和业务支撑方案提出统一模板化要求，在业务规范制定初期即套用该模板中的各类接口流程要求，在业务支撑方案制定时，主要的工作简化为以模板为基础、根据业务个性化定制。本项目的研究的意义也在于完善了业务支撑系统与业务网元之间相互接口与流程的规范体系，传统的业务网元以客户为中心，从“网元侧业务订购、业务使用”角度出发，设计、完善相关业务流程，传统的业务支撑系统也是以客户为中心，从“支撑侧业务开通、业务计费、客户服务”角度出发，设计、完善相关业务流程。但是两者之间需要紧密交互的接口、流程没有被充分重视。本项目的研究可以更进一步完善业务网元与业支系统的规范方案体系，促进业务网元与业支系统的的接口与流程模板化、标准化。本项目还重点研究了全产品运营环境下，产品管理和开通流程对支撑能力标准化的要求，依据集团规范，运用SOA方法，构建一个对外能力标准化、内部结构标准化的全产品管理运营平台。通过产品管理标准化、全产品统一管理、全渠道统一运营是全业务运营的基础，因此需要将分散在CRM、ADC、DSMP、彩铃平台以及其他业务平台上的产品进行整合，将网络侧的能力抽象为服务，将市场侧的规则抽象为协议和资费，构建统一的产品管理平台，支持全渠道、全产品运营。通过对外接口标准化，将按照系统来分别制定接口改为按业务能力制定接口，同一业务或系统服务能力对不同外围系统统一接口协议、统一接入。基于服务能力标准化，将系统提供的处理能力封装成服务，每个服务实现一个原子的业务逻辑，通过服务组合来灵活构建业务应用，服务注册在服务管理平台上，供支持域内各个系统共用。基于业务和技术发展趋势，探索基础平台标准化，研究将系统中经常变化的流程、规则、接口等内容的标准化实现方式，将动作和规则剥离，构建支撑域内共用的规则处理平台、统一开通平台、流程处理平台和认证授权平台。本项目的研究成果包括：业务平台与业务支撑系统接口与流程标准化研究报告共6份：业务支撑系统与业务平台计费接口与流程相关标准化研究报告、业务支撑系统与业务平台计费接口与流程标准化技术方案、业务支撑系统与业务平台开通接口与流程相关标准化研究报告、业务支撑系统与业务平台开通接口与流程标准化技术方案、业务支撑系统与业务平台客服接口与流程相关标准化研究报告、业务支撑系统与业务平台客服接口与流程标准化技术方案。全产品运营管理中心技术方案共5份：全产品运营管理中心-总体技术方案、全产品运营管理中心-应用系统服务研究报告、全产品运营管理中心-信息模型说明、全产品运营管理中心-服务开通标准化方案、全产品运营管理中心-产品发布与销售标准化方案。全产品运营管理3个应用系统：全产品运营管理中心（应用系统）、业务支撑统一接口处理平台（应用系统）、业务支撑服务注册管理平台（应用系统）。本项目完成的企标包括：已经报批的企标21本：业务平台与业务支撑系统数据一致性管理接口规范总册V2.0.0、业务平台与业务支撑系统数据一致性管理接口规范139邮箱平台分册V2.0.0、业务平台与业务支撑系统数据一致性管理接口规范中央音乐平台分册V2.0.0、业务平台与业务支撑系统数据一致性管理接口规范飞信平台分册V2.0.0、业务平台与业务支撑系统数据一致性管理接口规范农信通平台分册V2.0.0、业务平台与业务支撑系统数据一致性管理接口规范游戏平台分册V2.0.0、业务平台与业务支撑系统数据一致性管理接口规范彩铃平台分册V2.0.0、业务平台与业务支撑系统数据一致性管理接口规范手机动漫平台分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范12580平台分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范手机电视平台分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范手机银行卡平台分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范手机导航平台分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范手机支付平台分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范BlackBerry分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范视频会议分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范手机阅读分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范彩像平台分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范视频共享分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范MDO平台分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范宜居通平台分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范WLAN业务分册V1.0.0。已经完成初稿的企标25本：业务平台与业务支撑系统数据一致性管理接口规范手机支付平台分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范BlackBerry分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范ADC分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范IMS多媒体彩铃分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范MAS管理平台分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范财信通平台分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范车务通分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范会议电话分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范企业飞信分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范网信平台分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范行业网关A模块分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范一卡通分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范移动400分册V1.0.0、业务平台与业务支撑系统数据一致性管理接口规范-MM平台与中央SIMS MM业务局数据比对分册、业务平台与业务支撑系统数据一致性管理接口规范-中央SIMS与业务支撑系统MM业务局数据比对分册、业务平台与业务支撑系统数据一致性管理接口规范-游戏平台与中央SIMS 游戏业务局数据比对分册、中央SIMS与业务支撑系统比对业务局数据技术方案、业务平台与业务支撑系统数据一致性管理接口规范-浦发银行平台分册、业务平台与业务支撑系统数据一致性管理接口规范手机冲浪业务分册、局数据中心一致性管理接口规范、业务平台与业务支撑系统数据一致性管理接口规范物联网PBOSS分册、业务平台与业务支撑系统数据一致性管理接口规范物联网PBOSS与物联网业务网关比对分册、业务平台与业务支撑系统数据一致性管理接口规范物联网PBOSS与物联网一类业务平台比对分册、业务平台与业务支撑系统数据一致性管理接口规范物联网PBOSS与全网运营管理平台分册、业务平台与业务支撑系统数据一致性管理接口规范物联网PBOSS与一级BBOSS比对分册。本项目完成的专利有1个：一种实现实时消费提醒的装置和方法，目前已经通过专利评审。该项目的专利情况：1、没有的话填“无”，有的话填写专利名称及申请号或授权号。2、对于我公司自有专利，请对专利的应用价值及应用前景予以说明。如：（1）对外许可的可能性及潜在的许可对象；（2）在保障公司业务正常开展方面及增强公司选择供应商/合作商自主性方面的具体作用。3、对该项目涉及领域的专利风险予以介绍。并对项目实施过程中为降低专利侵权风险采取的必要措施予以介绍（如，因专利风险或其他相关知识产权问题已进行的方案调整或规避设计、重要讨论会结论、合作方承诺等）。本项目完成的专利有1个：一种实现实时消费提醒的装置和方法，目前已经通过专利评审。该项目研究中发现的问题及今后工作建议：如研究中发现的新问题、对现有企业标准规范的符合度，即在现有的企业标准（企业标准的名称和编号）基础上所需新增的功能要求（如业务流程的改变、设备新增的功能要求等）。1、基于本期业务平台与业务支撑系统接口与流程标准化模板的基础之上，未来对新业务的业务规范、总体技术要求、设备规范以及业务支撑技术方案均参照本模板进行接口与流程的制定；2、在本项目的延续之后，基于通用的业务平台与业务支撑系统接口与流程制定细致的测试方案，并作为新业务平台实验室测试时的必选项目，从而保证新业务平台与业务支撑系统在实验室中就可以进行对接测试，保障上网之后的服务质量。3、建议在全网范围内，集中制定核心业务能力标准化服务。项目研究成果的主体内容（3000字以上，可附在表格后）：1、研究成果主体内容：2、请项目负责人填写“项目对企业绩效贡献的量化路径图”和“项目特征指标的年度预期数值表”：1）项目对企业绩效贡献的量化路径图项目特征指标（PAV）指标名称项目应用前指标现状值：PAVc项目应用1年后指标预期值：PAVe1此项目带来的指标变动量：PAV新业务支撑方案制定时间3个月-半年1个月-3个月2-3个月企业特征指标网络及生产类（EAV-PS）指标名称项目应用前指标现状值（EAVc）项目应用1年后指标预期值（EAVe）此项目应用带来的指标变动量（EAV）企业特征指标市场及财务类（EAV-MF）指标名称项目应用前指标现状值（EAVc）项目应用1年后指标预期值（EAVe）此项目应用带来的指标变动量（EAV）企业绩效指标（EPV）指标名称项目应用前指标现状值：EAVc项目应用1年后指标预期值：EAVe此项目应用带来的指标变动量：EAV营运收入营运支出资本开支注：1） 填写各项指标数值时，请在数值后一并填写指标数值的度量单位（如RMB万元、万人、%等）和指标数值对应的应用范围（如XX地市、X省全省、31省全网等）。2） 项目特征指标是本项目应用后产生的主要可量化成效，最多不超过3个。如传输灾难性设备故障抢修系统项目应用的可量化直接成效表现为“缩短故障处理时间”，此即项目特征指标。其EAVc为××小时，其EAVe为××分钟，其EAV=EAVe EAVc。3） 企业特征指标是本项目应用后对企业生产（产品及服务）和经营（市场及财务）带来的可量化成效，分为“网络及生产类（EAV-PS）”和“市场及财务类（EAV-MF）”，指标清单请见本模板附件1。如传输灾难性设备故障抢修系统通过缩短故障定位时间，使“客户网络类投诉解决及时率”从×小时降低到×小时，使设备故障抢修时间缩短，由原来需要投入×人耗时×小时降低为×人耗时×小时，全省每年节省人工成本××万元。其中“客户网络类投诉解决及时率”为EAV-PS指标，“人工成本”就属于EAV-MF指标。4） 以上指标中，项目特征指标和企业特征指标的名称和数值都为必填项。企业绩效指标为选填项。建议项目经理尽量填全以更好地体现本项目对企业的贡献。2）项目特征指标的年度预期数值表项目特征指标（PAV）的名称：项目应用前指标现状值：PAVc项目应用1年后指标预期值：PAVe1项目应用2年后指标预期值：PAVe2项目应用3年后指标预期值：PAVe3项目应用4年后指标预期值：PAVe4项目应用5年后指标预期值：PAVe5项目应用6年后指标预期值：PAVe6项目应用7年后指标预期值：PAVe7项目应用8年后指标预期值：PAVe8项目应用9年后指标预期值：PAVe9项目应用10年后指标预期值：PAVe10注：1） 填写以上项目特征指标数值时，请在数值后一并填写指标数值的度量单位（如RMB万元、万人、%等）和指标数值对应的应用范围（如XX地市、X省全省、31省全网等）。2） 对于某些项目，若项目成果所依附的业务或网络在若干年后将退网，则请在预计的退网年度予以注明。如：应用于TDM交换机的某项目成果，预计该TDM交换机在X年后退网，则请在“项目应用X年后指标预期值”中填上“退网”。附：研究成果主体内容：附1：业务支撑系统与业务平台接口流程标准化研究附1.1 业务及功能简介业务支撑系统与业务平台接口及流程标准化研究主要从计费接口、开通接口、客服接口、数据一致性接口出发，提出了业务平台与业支系统之间的接口和流程通用要求，对所有业务平台和业务支撑方案提出统一模板化要求，更进一步完善业务网元与业支系统的规范方案体系，促进业务网元与业支系统的的接口与流程模板化、标准化。在计费接口与流程标准化部分：研究业务支撑系统与业务网元之间的计费接口和流程，包括离线计费/在线计费、以及业务网元的业务使用流程和计费点要求以及异常处理要求。在开通接口与流程标准化部分：研究业务支撑系统与业务网元之间的开通接口和流程，包括大圈交易、通知交易、批量开通等，以及各种开通流程中业支系统与业务网元各自的功能环节要求、异常处理要求。在客服接口与流程标准化部分：研究业务支撑系统与业务网元之间的客服接口和流程，包括对自有业务、SP业务、基地业务等等客服处理流程、一级客服系统的功能扩展、业务平台需要支持客服的功能等。在数据一致性接口与流程标准化部分：研究业支系统与业务网元的实时交互流程中如何更好的保证数据一致性，以及通过离线方式保证数据一致性的业务平台企标分册。附1.2 现有业务存在的问题本项目对涉及计费、开通、客服、数据一致性的以下两个方面进行深入分析和研究：（1） 相关的国际标准中的可借鉴的内容，相关国际标准包括3GPP、eTOM、SID、OSS/J等。（2） 现网近20个全网业务平台的业务规范、总体技术要求、设备规范以及业务支撑技术方案，分析总结出目前规范体系尚待完善的内容。在计费部分，通过对国际标准中对计费部分定义的分析，可以有如下借鉴：l 完整的业务计费相关规范体系；l 业务计费场景和计费流程的详细描述；l 各业务离线计费和在线计费的统一定义；l 话单格式的统一定义；l Diameter消息各字段的详细定义。尤其是3GPP针对每个业务从以下方面定义了详细的计费场景：l Architecture Considerations：定义该业务的计费总体框架，包括该业务的网络图以及与计费系统的连接关系，包括了对离线计费和在线计费的描述l Charging Principles定义该业务的计费总体原则，包括计费关联、主要计费要素、计费规则等l Charging Scenarios描述计费场景和计费流程，针对该业务中的用户使用流程，定义相应的计费流程，包括离线计费在什么时候产生话单、在线计费在什么时候进行触发等l Definition of charging information定义该业务中的计费信息字段，包括离线计费信息和在线计费信息而通过对现有业务规范体系中计费部分的分析，可以看到现有规范体系有待完善：l 绝大部分业务平台并未明确业务流程中的计费触发要求，也未明确各种情况下CDR字段填写要求；l 绝大部分业务并未定义在线计费接口。而通过对2010年计费质量竞赛中所发现问题的分析，很多问题产生的原因在于规范定义不够明确和细致，而只要规范进行了明确、细致的定义，并且在实验室测试的时候针对各种场景进行了测试，则绝大部分问题都可以被测试所发现和解决。在开通部分，通过对国际标准中对客服部分定义的分析，可以有如下借鉴：l 统一的业务开通处理流程；l 详细定义的开通处理接口；l 详细定义的开通处理信息。而通过对现有业务规范体系中开通的分析，可以看到现有规范体系有待完善：l 不同业务的开通流程选择的交易类型不同，在一个大圈类、两个大圈类、一个通知类、两个通知类之间没有选择的依据和原则；l 基本上所有业务平台侧的业务受理请求均不需要冲正，那么在消息交互出现问题时，无法保障双方的开通数据一致性；l 同样是通知类的接口，有的业务的第一条通知消息需要第二条通知消息的确认，而有的则不需要，新业务没有选择的依据；l 针对异常处理情况下，业务平台是否需要回滚、业务支撑系统是否需要回滚等处理要求在规范中没有明确。在客服部分，通过对国际标准中对客服部分定义的分析，可以有如下借鉴：l 统一的客户投诉处理流程；l 详细定义的客户投诉处理接口；l 详细定义的客户投诉处理信息。而通过对现有业务规范体系中客服部分的分析，可以看到现有规范体系有待完善：l 绝大部分业务平台未对客服功能模块提出详细的功能要求；l 游戏、12580手机支付、MDO、手机动漫等对客服要求稍详细，但是仍然不够系统；l 各类业务的客服受理流程不完全相同，并未在相关规范中体现出来。附1.3 优化后的方案在计费部分，对业务平台统一的提出了如下的架构要求：并从以下部分对新业务的计费要求进行了明确：l 业务资费描述Ø 对业务的资费结构进行描述Ø 对资费结构中各种资费项的产生原则进行概述l 离线计费场景Ø 枚举各种业务使用场景下，话单产生的触发点以及话单中各字段的填写要求进行详细描述Ø 对业务使用产生异常流程情况下，话单中各字段的填写要求进行详细描述Ø 对于基于会话类的计费，对话单拆分要求进行详细描述l 在线计费场景Ø 枚举各种业务使用场景下，DCC消息产生的触发点以及DCC消息中各字段的填写要求进行详细描述Ø 对业务使用产生异常流程情况下，DCC消息中的字段填写要求进行详细描述l 离线计费话单定义Ø 依据统一的话单模板格式要求，定义CDR的各字段，并对其取值类型、范围进行描述Ø 对于离线计费话单产生原则、命名、传送要求等进行描述l 在线计费DCC消息字段定义Ø 定义业务专用的DCC消息字段，对其中各字段的取值类型、范围进行描述在开通部分，对业务平台统一的提出了如下的架构要求：并从以下部分对新业务的开通要求进行了明确：l 统一启用冲正机制Ø 由于订购关系决定着用户是否能够正常使用业务以及对用户的计费是否正确，因此，应该启用冲正机制l 明确定义在各种网络和流程异常情况下业务平台与业务支撑系统的处理要求Ø 在遇到网络故障、对方系统异常等各种情况下，明确系统对订购关系的回退机制、重发机制等l 增加在系统失效时的人工干预机制Ø 在系统无法自动处理失败时，增加人工干预机制在客服部分，根据业务平台的4种不同类型对业务平台统一的提出了如下的架构要求：l 类型1：由网络部维护的业务平台，系统维护人员从EOMS系统中获取用户投诉工单，并通过业务平台的客服投诉处理模块提供对客服功能模块的支撑l 类型2：与客服系统之间存在投诉派发等接口的业务平台，需要支持工单处理模块，工单处理模块由系统维护人员操作，支持客服工单的受理、退回、投诉升级、投诉查询等操作l 类型3：具备二线客服人员的业务平台，需要具备呼叫中心模块，接受客户呼叫或者从一线客服转过来的呼叫，客服人员使用工单处理模块记录客户服务请求l 类型4：对于具备第三方合作伙伴提供业务或者内容的业务平台，其工单处理模块需要具备向第三方合作伙伴客服人员开放权限与操作的功能，供第三方合作伙伴客服人员处理客户投诉并从以下部分对新业务的客服要求进行了明确：l 业务平台客服功能要求Ø 主要从客服投诉处理、客服工单处理、呼叫中心功能等三大部分功能进行描述l 客户服务流程描述Ø 对各类业务平台的客服受理流程进行详细的描述。业务平台的分类可能有本地业务平台、全网业务平台、网络部维护业务平台、基地维护业务平台、具备二线客服的业务平台、具备合作伙伴的业务平台等等纬度进行l 业务平台支持客服功能要求详细说明Ø 针对业务平台的不同分类，业务平台需要具备不同的客户服务支撑功能，以支持客服实现附1.4 优化后的效果该项目的成果可以指导业务支撑系统与业务平台采取公共的机制进行交互、并在公共机制的基础上针对业务进行个性化定制，降低新业务需求出现时case-by-case的讨论支撑方案的缺点，提高新业务支撑需求响应速度，对未来新业务平台的业务规范、总体技术要求、设备规范中的业务支撑相关部分以及相应的业务支撑技术方案的制定，有很好的模板参考意义。附2：全产品支撑标准化能力和架构研究附2.1 业务及功能简介在全产品运营环境下，要求产品能快速开发、销售，因此需要构建基于标准化架构、标准化流程和部件的系统；通过对标准化能力进行快速组合来支持新业务的快速上线。集团公司对于支撑系统标准化有明确的要求，每年通过NG-BOSS/CRM/PBOSS业务、技术规范来指导省公司的支撑系统研发。同时要求“研究全业务环境下业务支撑系统综合受理、统一的业务管理、产品管理、客户管理、资源管理等能力”，“探索在系统架构、系统接口、数据结构、信息展现等多层面的标准化实现，助力业务标准化、服务标准化及管理标准化。” 依据集团关于业务支撑标准化的相关规范和指导意见，借鉴业界先进的系统架构和分析方法论，对广东移动的CRM/BOSS支撑范围内对业务能力和系统架构、开发过程进行标准化研究。具体内容包括：n 产品管理标准化，全产品统一管理、全渠道统一运营是全业务运营的基础，因此需要将分散在CRM、ADC、DSMP、彩铃平台以及其他业务平台上的产品进行整合，将网络侧的能力抽象为服务，将市场侧的规则抽象为协议和资费，构建统一的产品管理平台，支持全渠道、全产品运营n 对外接口标准化，将按照系统来分别制定接口改为按业务能力制定接口，同一业务或系统服务能力对不同外围系统统一接口协议、统一接入n 服务能力标准化，将系统提供的处理能力封装成服务，每个服务实现一个原子的业务逻辑，通过服务组合来灵活构建业务应用，服务注册在服务管理平台上，供支持域内各个系统共用。n 基础平台标准化，研究将系统中经常变化的流程、规则、接口等内容的标准化实现方式，将动作和规则剥离，构建支撑域内共用的规则处理平台、统一开通平台、流程处理平台和认证授权平台附2.2 现有业务存在的问题广东公司在支撑系统研发过程中遇到了：1)新产品快速推出，但各产品销售量很小，但由于后端的承载平台不同，导致后续的管理和开通流程完全不同，而支撑系统必须原封不同的支持这些不同，导致开发资源的浪费和实现时间不能满足业务要求2)支撑系统现有软件资产很多，新业务需要的系统功能，在不同系统中可能已经基本实现，但是缺乏标准化，无法实现快速重用，新业务依然需要代码开发3)在现有各业务平台上管理和销售的产品差异很大，将分散在各个平台上产品整合起来统一管理，产品模型标准化难度很大为了实现标准化产品的统一管理、统一销售和统一开通，需要在配置产品时使用标准的开通环节灵活组合开通流程。如何实现开通环节标准化和开通流程的灵活组合是主要困难。因此需要建设系统时对业务支撑能力和系统部件标准化进行统一规划，对应用系统架构、系统接口、数据结构、信息展现的标准化实践方面进行研究，并探索使用标准化系统部件来构建应用的方法和流程。 附2.3 业务实现流程以产品管理、销售和开通流程为核心，将产品管理、销售、开通和客户服务功能进行服务化改造，重构成产品配置服务中心，订单与销售中心、客户与订购关系中心；l 产品配置与服务中心：实现全业务、全渠道的产品管理；对各渠道提供一致的产品目录l 订单与销售中心：统一各渠道的订购和开通流程，实现一站式订购与退订l 客户与订购关系管理中心：负责统一订购关系管理，实现全渠道全业务的一站式查询附2.4 优化后的方案/流程构建标准的产品模型，将产品的资费和服务内容分离。资费由产品运营管理中心统一管理，服务内容由业务平台将其业务能力抽象为标准化服务，注册到产品运营管理中心，产品中心对不同平台上的服务可以执行相同的操作。屏蔽不同业务对平台（网元）的操作差异，按照业务口径将与一个业务相关的一个或多个平台操作，封装成某服务的开通、取消、暂停、恢复和属性变更这5个标准开通环节。将产品的开通流程和流程节点操作分离，在定义产品时只定义流程节点的施工顺序，流程节点的具体操作由代码固化。附2.5 优化后达到的效果，产生的经济效益整合了分散在各平台、各渠道的产品管理、销售和开通能力，构建了全业务环境下的具有统一产品管理、统一业务管理能力，对外接口统一的基础业务平台基于SOA技术实现应用系统的能力封装，通过统一服务注册管理，实现了系统能力在企业内的共享，为业务标准化、服务标准化及管理标准化提供了基础的IT资源对外接口标准化，将过去产品销售和开通相关的十余套接口协议，按能力重构并进行命令字的标准化整合，并以服务的形式提供接口，统一了渠道的业务能力和处理流程构建流程管理平台，通过流程定制，直接复用已有系统能力，来快速支持新业务完成了统一产品模型的设计和验证，使用新模型验证了CRM/BOSS、ADC、12580、139、彩铃等平台上的60多个典型产品。完成了接口协议标准化的整合，将于10086、网站、短信营业厅、自助终端等渠道平台和BOSS、ADC、DSMP、139等业务平台的协议统一整合成业务受理和服务开通两个协议梳理了与产品管理、销售、开通相关161个服务，已基本完成开发，并发布到服务注册管理平台，供各渠道系统使用。“研发项目结题报告”的填写说明：1、“项目专业类别”指：无线、传输、IP、核心网、网管、业务支撑、管理信息系统、市场研究、通信电源、数据业务、终端和卡、总体、其他。2、“项目研究类别”指：超前研究、相关网络解决方案、新产品开发、现有业务优化、其他。3、“研究单位内部评审结果”指：优秀、通过。4、“文章主体”：根据不同研发项目的研究类别实施不同的主体要求，具体如下：1）超前研究类项目主体包括：ü 背景情况ü 技术特点分析ü 标准化情况ü 其他运营商应用情况（可选）ü 技术发展趋势ü 引入策略分析ü 其他补充说明2）相关网络解决方案类项目主体包括：ü 背景情况ü 技术方案：概述、网络解决方案（如果涉及到网络方面的改造，信令改造，路由改造等，应有详细的描述）、设备及系统改造/建设要求、码号资源需求ü 效果（解决了哪些问题）ü 本省应用推广情况ü 其他补充说明3）新产品开发类项目主体包括：ü 业务及功能简介：业务概述、业务主要功能介绍ü 技术实现方案：包括业务实现组网结构图、相关系统（平台、终端）功能和要求、业务实现流程、码号要求等ü 业务申请和开通：包括用户范围及业务使用范围、业务申请与注销等ü 业务商务模式及资费：包括商务模式、业务资费模式、业务收费方式等ü 市场前景分析ü 其他补充说明4）现有业务优化类项目主体包括：ü 业务及功能简介：业务概述、业务主要功能介绍ü 现有业务存在的问题：现有缺陷分析、解决问题的思路ü 原有业务方案/流程：业务实现组网结构图、相关系统（平台、终端）功能和要求、业务实现流程 ü 优化后的方案/流程：业务实现组网结构图、相关系统（平台、终端）功能和要求、业务实现流程ü 优化后达到的效果，产生的经济效益ü 其他补充说明 5）其他类项目主体，参考1）4）的项目主体要求，阐述清楚项目背景、实现方案、解决的问题、取得的社会和经济效益等。