《03 中国移动业务支撑系统现状V0.2.ppt》由会员分享，可在线阅读，更多相关《03 中国移动业务支撑系统现状V0.2.ppt（325页珍藏版）》请在三一办公上搜索。
1、中国移动通信有限公司NGBOSS业务和技术环境分析 中国移动业务支撑系统现状2006年5月,中国惠普有限公司企业计算及专业服务集团,2,文件变更记录,3,索引,一、业务支撑网架构与功能/业务组织架构现状 4北京移动 20上海移动 56江苏移动 74广东移动 100湖北移动 135 吉林移动 161MISC 183二、四省一市业务支撑网现状调研情况 208调研目标、范围 209调研成果总结 213调研成果汇编 219各省经典案例汇总 293三、集团公司访谈情况 296访谈目标和方法 297访谈成果总结 300访谈成果汇编 302四、中国移动业务支撑现状问题分析 306,4,一、业务支撑网架构与功
2、能/业务组织架构现状（一）北京移动（二）上海移动（三）江苏移动（四）广东移动（五）湖北移动（六）吉林移动（七）MISC二、四省一市业务支撑网现状调研情况三、集团公司访谈情况四、中国移动业务支撑现状问题分析,目录,5,典型省市业务支撑体系扫描总结 五年发展，成就显著,迅速建立了省级业务支撑体系和核心团队支持各省业务高速发展逐步获得业务部门认可，努力成为业务部门的业务支撑顾问超越竞争对手，形成独特的业务支撑核心竞争力优势，竞争对手纷纷效仿却难以迅速赶上。,6,典型省市业务支撑体系扫描总结 发展中的问题必须用发展的办法来解决,3个落脚点：组织职能：缺少管理职能和长期规划职能，在规划职能不到位的情况下
3、，还是作了BOSS BASS，BOSS NM等规划和建设，而且还开展了很多的管理职能的工作。但是，由于机制、组织、资源没有保障，长期来看，无法满足公司的对业务支撑工作的战略定位。需求：需求管理，缺少需求管理的职能，没有统一归口，缺少流程。满足了需求，适应了企业高速发展带来的需求多变性。由于缺乏规划统一，需求差异大，成本高。集成商：过度依赖集成商打造业务支撑系统，由集成商来负责需求规划、架构规划、系统建设、后期维护。在BOSS内涵和外延比较小时能够很好的适应。但是业务支撑网的内涵在不断扩大，业务种类、功能极大丰富，集成商已经难以驾驭。需求管理混乱缺少中长期整体规划,7,业务支撑网现状扫描总体结论
4、,组织和人员计费中心定位为生产单位，总体上缺少管理和规划职能。已经组建了一支以“项目建设、业务操作、系统维护”三大能力为核心的管理和技术团队，但是缺少明确的技术专家职业发展路线相应的人才培养体系，不利于长期发展。需求管理系统功能和架构功能实现受到本公司的业务流程、管理体制影响巨大，业务支撑系统之间功能差异大固化和加剧了省之间运营管理的差异性，导致客户体验差异大、全网型业务难以快速统一实现。各业务支撑系统技术架构差异大，外部系统边界、内部子系统划分、子系统的应用架构均呈现较大的差异性，将阻碍业务支撑能力的整体演进和提升。省级业务支撑能力较强，跨省业务支撑能力较弱。实时性系统非实时导致欠费。网络化
5、孤立，系统分割。开放性、规范性差异大、系统划分不一致、接口不标准。多业务融合欠缺，单一业务发展。业务支撑网发展业务支撑网的演进模式是“需求驱动项目”的模式，而不是“总体规划和架构”驱动，项目之间的边界重叠或边界空白大大影响业务支撑系统的外部能力展现和使用者体验。业务支撑网的建设和提升过程过度依赖系统集成商，中国移动自身逐渐失去对需求和架构的掌控，业务支撑网进一步演进的风险逐步提升。业务规划的不确定性，导致业务支撑网的建设难以实现提前规划、提前建设。,8,需要用整体规划和需求管理作为纽带将业务发展和业务支撑有机联系起来,整体规划需求管理,业务支撑系统建设,业务发展规划,9,业务发展战略和业务支撑
6、发展战略,业务发展战略,业务支撑网发展战略,需求管理项目管理变更管理,业务系统网整体架构规划,创新研发重点方向,人才培养机制,构建方式：自建还是购买,组织架构,支撑网运营管理流程,业务支撑能力体系及演进,10,业务支撑系统建设有待进入良性循环,业务发展战略规划,执行举措运营流程,支撑网系统建设和运营,支撑网总体规划,分解落实,提出具体需求,分解落实,提出总体目标和挑战,业务支撑网演进缺少总体规划，直接采用“规范项目”的方式驱动系统建设，导致业务支撑网中的各个系统之间、支撑网系统与外部系统之间存在系统边界不清、重复建设、缺少互动、难以集成等问题,总部业务支撑系统部缺少对各省业务支撑系统的“规范实
7、现”强有力的过程控制，难以控制业务支撑网系统实现的差异性。,业务支撑系统建设和运营团队之间缺少横向沟通和集中控制，加剧了系统之间整合的难度。实施团队驻地开发的模式，更加剧了各省业务支撑系统能力和架构的差异性。,业务部门和支撑部门都未有效管理需求：1.缺少需求管理机制和组织2.缺少需求管理框架，包括需求定义（清晰、正确、完整），变更管理（可回溯、可控制），验收和反馈机制,各省组织架构、战略执行举措和运营流程差异很大，具体需求差异很大。,总部级的业务发展战略，比较宏观，缺少对运营和执行的指导性，缺少对各省分解执行的强力控制。,各省对业务发展战略规划基于自身市场环境和运营流程，这个过程缺少总部的指导
8、。,11,业务支撑网现状扫描组织架构关键发现点,北京：业务运营中心是有生产职能，缺少管理职能和规划职能，虽然有一个人负责IT系统的规划，缺少权威性，资源严重不足，无法真正实现业务支撑网的中长期规划。业务支撑中心和信息技术中心按照项目进行组织，缺少横向沟通和统一的需求管理、架构控制，导致系统之间的边界不清，集成难度加大。上海：信息系统部和计费中心是2个平行组织。信息系统部有管理和规划职能，负责整个IT系统架构规划和控制，致力于企业管理系统、业务支撑系统内部和外部的系统分界清晰和有效集成。但是无法掌控网络运营支撑系统（OSS）和业务网系统（IN和MISC）的需求和架构。在专业管理上不与集团公司业务
9、支撑系统部衔接。负责本企业内部的需求跟踪和管控计费中心只有业务支撑系统的生产、运维、建设职能，没有管理和规划职能，专业管理上对应集团公司业务支撑系统部，按照BOSS规范等进行建设，但是在架构上服从信息系统部的总体规划和设计。江苏：业务运营中心是有生产职能，缺少管理职能和规划职能，虽然有一个人负责IT系统的规划，缺少权威性，资源严重不足，无法真正实现业务支撑网的中长期规划。业务支撑中心和信息技术中心按照项目进行组织，缺少横向沟通和统一的需求管理、架构控制，导致系统之间的边界不清，集成难度加大。广东：没有统一的IT系统规划机构。湖北：BASS系统维护开发管理相对独立，与BOSS系统互动不足。缺乏统
10、一规划设计部门以及职责。吉林：缺少规划职能，对业务支撑网前瞻性规划能力弱。缺少统一需求管理。由不同部门管理不同系统。MISC：卓望公司组织架构是面向全网MISC建设和运营，在统一规划、统一建设实施上，能做到有效的全网资源协调和全网协作一致，保证了低成本高效率和快速抢占市场先机。,12,业务支撑网现状扫描业务支撑网概貌关键发现点（一）,北京：各个专业子系统各司其职，由EAI进行企业内部集成。上海：1、需要解决计费系统的及时性和准确性问题，如何在井喷式的3G数据业务场景下控制欠费，是业务稳健发展的关键。需要参考IN-GATEWAY的经验教训。2、需要加强对SP的监控，3G业务的发展必然经历从不成熟
11、到成熟的演进过程。如何减少过程中的客户损失和移动公司的损失，降低3G业务投诉，提高服务形象，是下阶段面临的一大课题。3、需要进一步考虑业务支撑系统建设与移动总ONE CM规划之间的关系，尤其需要重新思考DSMP、CBOSS、集团客户管理的全局业务原则和系统架构的问题。4、确定系统边界：3G业务网元模糊了业务支撑网与通讯网的边界，需要界定业务网的边界。5、设计规划体制上的两头蛇问题：3G业务的发展锐化了数据中心和计费中心在新兴的边缘业务上的系统设计冲突，架构设计的裁判权需要界定。江苏：按地区划分存储客户信息。广东：系统分散、业务逻辑不集中。快速业务支撑能力差。,13,业务支撑网现状扫描业务支撑网
12、概貌关键发现点（二）,湖北：BOSS系统目前主要支撑了业务受理和计费，对于营销管理支撑不足对于地市支撑能力不足客户接触一致性体验不足缺乏统一接口管理平台，系统接口繁多吉林：业务网网元和支撑网接口越来越多系统全省集中，未下放到地市系统高度紧耦合，营帐、大客户、集团客户、渠道等使用同一数据库MISC：业务支撑能力仅限于管理和运营控制能力，缺少面向用户和合作伙伴的服务支撑能力，例如营销、品牌、集团业务,14,业务支撑网现状扫描主要问题关键发现点（一）,北京：业务需求变化过于频繁对系统稳定性带来极大挑战支撑网边界模糊问题（与业务网、核心网等）COTS产品在本土化应用中灵活性欠缺COTS产品对集成商能力
13、要求较高，系统集成风险提高上海：缺乏对非即开即通流程的支持对不断发展的多样化的业务无法进行完全配置，导致二次编码过多，bug也容易出现缺乏面向内容的计费能力出账流程外挂平台过多核心业务实体缺乏统一的数据定义,现有数据结构与eTOM/SID国际电信行业先进标准相比存在差距客户，产品资费等缺乏完整统一信息模型,数据处理尚缺乏统一的原则和规范。系统结构过于紧耦合，不利于独立部署和扩展。功能定义划分不清晰，没有统一的PORTAL界面缺乏规范的容错管理江苏：需要考虑业务逻辑的重用，避免系统中存在多处重复的逻辑；业务逻辑层可以进一步细分为原子逻辑层和过程逻辑层，过程逻辑层通过调用原子逻辑层完成相应的过程逻
14、辑，且过程逻辑层可配置，以满足业务逻辑的灵活变更。通过业务逻辑层的细分也可以进一步分解原业务逻辑层的压力，提高系统的稳定性需要考虑批量处理与联机处理功能的分离，批量处理容易对系统造成持续的高压力，严重时会影响联机交易的处理，可以将这两种交易实现分离，可以对批量交易进行有效的控制和调节，以提高系统的健壮性和稳定性,15,业务支撑网现状扫描主要问题关键发现点（二）,广东：系统分散、业务逻辑不集中快速业务支撑能力差湖北：营业、帐务存在两套资料，相互之间依靠数据库触发器进行同步，很难保证资料的准确帐务系统只有简单的根据时间判断生效失效，没有复杂的资费、产品依赖、互斥等判断逻辑，所有关系依靠营业判断，容
15、易出现问题吉林：由于缺少规划职能，企业级IT系统建设各自为政，造成资源浪费，整合系统难度大缺少统一需求管理、分析职能，对业务需求分析、理解能力不足，项目开发周期无法保证地市个性化支撑能力不足，影响地市业务发展积极性、对地市营销和服务支撑能力弱业务支撑系统架构不合理，无法快速、灵活支撑新业务开发MISC：规划与执行不一致的问题，执行过程中会偏离规划的思想MISC的建设与市场部、集团客户部接口脱节，这些部门的需求下达不顺畅,16,业务支撑网现状扫描05/06年对业务支撑网的改造关键发现点,北京：通过专业COTS产品的实施，结合端到端业务流程下的系统分工和整合，接管旧BOSS系统的计费、采集和开通模
16、块，以及相应的数据和流程，建立面向3G的一体化BOSS系统。上海业务优先（市场驱动）、架构优化（管理驱动）江苏开始集中客户接触界面广东地域集中、开发商集中、系统集中优化需求处理流程加强数据业务计费支撑，提供3G计费能力，提高计费实时性，降低计费差错加强客户需求识别能力，实施精细营销，将精细化营销的工作落实到系统加强经营分析应用推广湖北：各系统独立发展，缺乏统一的规划部署策略系统间数据割裂，数据共享不足，互动能力不足吉林：项目建设按照集团公司要求开展，同时每年进行扩容以满足用户、业务发展需求。MISC：系统建设应该分阶段实施，每个阶段的目标和重点都不同，逐步向成熟优化的系统靠拢。,17,业务支撑
17、网现状扫描关键集成商状况关键发现点,北京：多个COTS产品对集成商要求很高上海：移动主导规划和测试的动作，包括需求分析，架构设计，甚至表结构设计江苏：移动统一管理需求，在需求细化过程中，引入集成商广东：集成商规模小，技术水平差，不能成为战略合作伙伴过分注重自身发展规划：承诺不能及时兑现湖北：集成商的行业资源积累速度难以满足行业市场扩张需求，各省系统个性化业务需求不统一的情况下，存在资源竞争同一厂商的系统版本不统一，难以实现资源共享吉林：业务支撑系统需求频繁，集成商忙于满足需求，无提高、发展能力总部人员长期出差、待遇一般，造成核心人员流动，本地人员感觉工作不稳定，发展前景不明朗，流动性高。MIS
18、C：卓望公司实现了中国移动在数据业务领域的集成能力，使移动在把握核心技术的同时也掌握了价值链上的主动权。集中统一建设对承担统一建设者的能力要求很高,18,业务支撑网现状扫描新业务开发流程关键发现点,北京：前期需求变化过于频繁导致周期延长上海：只记录需求确认后相应的开发时间，与需求要求上线时间，实际完成时间，没有相应的需求提出单位初次提出需求并协商的时间记录。没有记录相应的需求的撤消比例等。江苏：内部文件进行需求控制广东：前期需求变化过于频繁导致周期延长湖北：目前数据业务应用开发和传统语音业务开发管理归属不同部门缺乏企业高度统一的需求管理部门和系统架构规划设计部门需求开发环节对厂商的依赖性较大吉
19、林：业务部门提出需求到规范后的需求正式提交项目开发管理平台，这段期间工作无法有效管理。部分项目集成商需要总部统一开发、本地测试，影响项目开发进度。项目开发管理平台和测试平台无接口，未能有效互动，对集成商提交产品测试情况无直接体现。MISC：CCB角色能有效控制需求变更和优先级。集团和省公司在向卓望提需求前缺少协调沟通的流程。,19,业务支撑网现状扫描关键集成商状况情况汇总,20,一、业务支撑网架构与功能/业务组织架构现状（一）北京移动（二）上海移动（三）江苏移动（四）广东移动（五）湖北移动（六）吉林移动（七）MISC二、四省一市业务支撑网现状调研情况三、集团公司访谈情况四、中国移动业务支撑现状
20、问题分析,目录,21,一、业务支撑网架构与功能/业务组织架构现状（一）北京移动（二）上海移动（三）江苏移动（四）广东移动（五）湖北移动（六）吉林移动（七）MISC二、四省一市业务支撑网现状调研情况三、集团公司访谈情况四、中国移动业务支撑现状问题分析,目录,组织架构业务支撑网概貌业务支撑网存在的主要问题05/06年对业务支撑网的改造关键集成商状况新业务开发流程关键发现,22,BMCC业务支撑网现状扫描组织架构,关键发现业务运营中心是有生产职能，缺少管理职能和规划职能，虽然有一个人负责IT系统的规划，缺少权威性，资源严重不足，无法真正实现业务支撑网的中长期规划。业务支撑中心和信息技术中心按照项目进
21、行组织，缺少横向沟通和统一的需求管理、架构控制，导致系统之间的边界不清，集成难度加大。,业务运营中心,业务支撑中心,信息技术中心,业务运行中心,系统维护中心,综合部,帐务组,报表组,热线组,BOSS应用维护,BOSS,CRM,BI,OA组,网络组,主机组,综合事务组,流程质量控制小组,ITNMS 项目组,USD 项目组,MIS 项目组,KM 项目组,EPM 项目组,23,一、业务支撑网架构与功能/业务组织架构现状（一）北京移动（二）上海移动（三）江苏移动（四）广东移动（五）湖北移动（六）吉林移动（七）MISC二、四省一市业务支撑网现状调研情况三、集团公司访谈情况四、中国移动业务支撑现状问题分析
22、,目录,组织架构业务支撑网概貌业务支撑网存在的主要问题05/06年对业务支撑网的改造关键集成商状况新业务开发流程关键发现,24,BMCC省业务支撑网现状扫描业务支撑网概貌,关键发现各个专业子系统各司其职，由EAI进行企业内部集成。,25,BMCC省业务支撑网现状扫描业务支撑网概貌,后台支撑系统,网络服务接口层,26,业务支撑网内部分工界面的工作原则,工作原则：从北京移动未来业务支撑系统的整体发展出发专业化分工合作的原则，明确每个系统的专业化定位，充分发挥专业系统的优势和北京移动特定业务环境结合，特别是数据、功能和业务流程的紧耦合和松耦合关系适当结合所应用的COTS软件的功能和能力分工界面定义中
23、应回答：数据分工功能分工端到端流程的验证初步的接口方式,CRM、BOSS3、CMOD、ODS、综合结算和BOSS网管，上述六个系统在BOSS三期上线时，将共同和完整的覆盖现有BOSS的数据和功能，以及BOSS1.5规范的要求，形成对北京移动业务流程的端到端支撑。,27,业务支撑网内部分工界面的工作方法,28,北京移动业务支撑网组成和系统定位,29,数据分布和集成的总体原则,OCRM,融合计费帐务,统一采集平台,统一开通平台,CMOD,ODS,BOSS网管,综合结算,每类业务数据实体有且仅有一个所有者（Owner），零个或多个消费者（Consumer）；对数据的维护必须通过所有者进行，消费者对数
24、据只有只读功能；如果消费者需要对数据进行维护，必须调用所有者的数据维护服务 必须明确Data Placement和Common Data Model。,有哪些数据实体需要分布，有哪些系统需要参与分布,30,北京移动关键数据实体分布规划,31,CRMBOSS3分工原则1：CRM3负责统一的客户服务接入功能，BOSS3提供统一帐务接口服务,CRM作为北京移动面向客户的统一接入渠道，前台营业、1860客服、IVR接入、短信接入、网站等多种接入方式都需通过统一的CRM接口访问Billing系统的服务，因此：现有BOSS的短信网关受理功能（12580、1866）将逐步迁移到CRM系统中现有BOSS和IV
25、R、网站接口将取消，将统一到CRM接口充值和银行作为受理渠道完成的业务受理，将通过充值/银行网关上发到CRM完成相应的业务受理，如彩铃充值卡，通过银行申请“预存600，返360”业务。CRM作为面向客户和市场营销部门的统一客服接入界面，将涵盖现有BOSS的所有前台界面，特别是对于缴费和帐务管理的前台功能，将由CRM提供前台功能，后台BOSS通过相关接口提供缴费等后台相关的数据访问服务。有关前台缴帐单、发票和日终统计的分工原则：前台缴费，CRM负责所有的前台界面，调用BOSS的帐单查询、帐单缴费服务接口，Billing生成发票数据，提供给CRM打印所有的发票数据由Billing管理，Billin
26、g负责发票数据的生成，提供前台打印日终费用厅台统计时，CRM提交统计条件，Billing系统根据统计条件从发票数据中生成日终统计数据，提供给CRM打印日终统计报表；一次性费用计算的分工原则CRM负责前台一次性费用的计算，在成功提交后，向Billing提交一次性缴费数据，由Billing生成发票数据给CRM，CRM完成发票打印；,32,CRMBOSS3分工原则2：业务受理流程的分工,CRM负责管理客户关系管理，是三户数据和三户状态属性的master系统，因此所有与客户数据、三户关系和三户状态的变更请求都应由CRM发起。CRM是订购关系（客户订购BMCC产品）的master系统，所有的产品订购由C
27、RM发起。业务受理流程的分工原则：CRM负责完整的业务受理逻辑，如产品互斥规则、受理条件的判断，然后将提交的订单分别、先后发送给Provisioning系统和Billing系统；某些受理条件需要依据Billing系统数据进行判断的，则Billing开放相应的数据查询接口，如积分查询和缴费状态查询；CRM系统负责保证业务受理交易的交易一致性，如果其中一个系统回退，则CRM有责任通知其他系统对相关交易进行回退。客户协议管理：由CRM进行客户协议的统一管理，对于协议到期的自动协议终止，和因欠费停机/申停而造成的协议终止，由CRM统一触发，向Billing或开通系统发送协议终止订单 CRM-Billi
28、ng间的产品生效管理:CRM在客户申请时向Billing系统发送订单，订单中包括产品生效日期和失效日期，对非立即生效的产品定购情况，Billing系统将根据生效日期，在将来的某时刻自动触发“产品生效”和“产品失效”；,33,CRMBOSS3分工原则3：产品映射规则,CRM、Billing间的产品映射基本原则：CRM和Billing间各自维护自己的产品结构，在EAI平台上根据产品映射表完成CRM到Billing系统的产品映射，并生成产品定购订单。在产品定义时，CRM和Billing各自对自己产品目录进行更新，并同时更新EAI上的产品映射表。CRM和Billing间不进行自动产品数据同步。产品映射
29、样例：,34,CRM、Billing和开通系统间的关系所有的开通订单都将从CRM到开通系统，Billing系统没有和开通系统间的直接开通接口;Billing系统因欠费、充值、缴费产生的开通操作，都由Billing向CRM发起请求，由CRM向开通系统发送开通操作；CRM和开通系统间的分工原则：CRM受理客户订单（BWO），负责根据产品间关系和客户的定购关系进行开通服务的关联性判断，将一个客户订单中分解为多个面向开通的服务订单（PO），并和客户订单打包发给开通系统；开通系统负责服务订单到网元的工单分解，到网元进行开通；同时开通系统负责对客户订单的交易完整性，如果其中任何一个服务订单失败，开通系统将
30、负责统一回退。CRM需确保开通服务订单在一个客户订单中是没有重复；CRM-开通系统间的产品生效管理:对于开通订单，CRM系统在生效时向开通发送订单，开通系统不缓存滞后生效的订单（如下月生效）；如果开通和Billing分别生效，由CRM统一在生效日期分别到开通和Billing系统进行开通，以确保交易一致性，避免开通系统开通失败，但向客户收费的情况。,CRMBOSS3分工原则4：和开通系统简单的分工,35,停开机管理原则：CRM作为停开机状态的统一管理者，完成统一的开机逻辑判断、向开通系统发送停开机指令、和向相关系统发布停开机状态；Billing系统产生的任何停开机请求，需向CRM进行申请，到CR
31、M发布的最新停开机状态后，才可进行后续业务处理；人工催缴（目前话费管理中心的功能）的分工人工催缴属于前台CRM功能，Billing系统生成人工催缴报告给CRM系统对于普通黑名单管理的分工原则：CRM是黑名单数据的Master，并根据黑名单数据进行前台业务受理条件的判断；后台BOSS在客户欠费达到销户条件后，通知CRM进行触发进行欠费销户处理，CRM负责生成欠费黑名单；欠费销户的客户缴清欠费后，后台BOSS通知CRM进行欠费黑名单解除操作；对于“催U黑名单”、“担保人黑名单”由于完全是因为前台业务办理条件审核发现问题进行的黑名单处理，应由CRM负责管理。,CRMBOSS3分工原则5：停开机管理、
32、催缴和黑名单,36,CRMBOSS3分工原则6：和业务平台间的接口分工原则,37,短信通知分工原则：CRM负责和产品受理、客户服务、产品促销相关的短信发送；同时CRM作为集成的受理渠道负责所有的短信业务受理、短信查询服务的接入BOSS三期负责和用户帐户相关短信发送，如帐户余额变更、缴费提醒、欠费停机提醒、充值提醒等。智能网网关(INGW)的接口分工BOSS三期负责完成720万神州行的非实时业务批价，并将扣费文件送智能网网关。CRM负责和智能网网关间的反向状态同步接口，同步720万神州行用户状态，并发布给相关业务平台，包括神州行激活状态、有效期和保留期间的状态转换、冷冻期等；开通平台负责到智能网
33、网关的开通接口，即所有720万神州行的业务受理和开通，将通过CRM开通平台智能网。彩铃卡将作为一种彩铃优惠定购关系，由CRM负责管理其产品有效期，并通知BOSS三期，BOSS三期负责根据彩铃优惠产品进行计费。,CRMBOSS3分工原则7：外部接口分工,38,从现有BOSS的功能被全覆盖视角，验证CRM、新BOSS的分工规划,39,CRM-BOSS和CMOD系统间的分工原则,CMOD系统定位：提供对所有渠道的详单和帐单查询：渠道包括：CRM前台、网站、1860查询帐单、1861短信查询帐单查询内容：到前一日的详单和费用累计查询，帐单查询，但不包括实时详单和实时费用查询。负责帐单的个性化展现、格式
34、化、帐单打印和邮寄数据提供功能。BOSS三期系统：提供批价后详单提供出帐后的用户级消费账单，包括优惠前费用和优惠费用提供出帐后的帐户级的帐单数据。负责重批价后、调账后的详单、账单数据提供积分数据。CRM系统：负责提供客户信息、帐户信息和帐单个性化信息给CMOD,40,BOSS3和BI系统间的分工原则,BI系统：负责除日终费用统计外的所有统计报表功能。负责数据格式转换。负责和MIS系统的数据接口。BOSS三期系统：根据BI的接口要求，按时提供足够粒度的原始数据。BOSS三期系统负责提供的数据包括：原始话单、详单、帐单、缴费数据、欠费数据和积分数据。负责日终费用统计CRM系统：客户信息由CRM系统
35、提供，包括客户、用户、帐户、定购关系数据、客户交互历史。,41,BOSS3和结算系统间的分工原则,BOSS三期：BOSS3采集系统，负责面向网元的统一采集，将结算原始话单送结算系统。BOSS3计费系统定位是面向本地用户的计费和帐务处理的系统，满足本地市场的灵活计费需求。BOSS负责：北京移动本地客户的计费和帐务处理，包括国内/国际漫游出访计费、北京移动客户的SP业务计费和帐务。综合结算系统：综合结算系统的定位：是面向其他运营商、合作伙伴、集团和其他省公司的综合结算系统，应包括灵活的结算预处理、结算批价和结算出帐和对帐功能；满足各种合作伙伴的结算需求、实时结算需求。综合结算系统负责：网间结算的批
36、价和对帐漫游来访用户的批价和对帐和集团公司间的漫游对帐接口SP的业务结算和对帐,42,全国结算中心,BOSS3和结算系统间的分工漫游结算的流程分工,Mediation,Billing,综合结算,BOSS三期,漫游结算,网间结算,漫游上传模块,1.漫游下传数据流程,2.漫游上传数据流程,43,BOSS三期的应用架构图,44,BOSS三期的外部接口电路图(1),45,BOSS三期的外部接口电路图(2),46,一、业务支撑网架构与功能/业务组织架构现状（一）北京移动（二）上海移动（三）江苏移动（四）广东移动（五）湖北移动（六）吉林移动（七）MISC二、四省一市业务支撑网现状调研情况三、集团公司访谈情
37、况四、中国移动业务支撑现状问题分析,目录,组织架构业务支撑网概貌业务支撑网存在的主要问题05/06年对业务支撑网的改造关键集成商状况新业务开发流程关键发现,47,BMCC业务支撑网现状扫描业务支撑网存在的主要问题,业务需求变化过于频繁对系统稳定性带来极大挑战支撑网边界模糊问题（与业务网、核心网等）COTS产品在本土化应用中灵活性欠缺COTS产品对集成商能力要求较高，系统集成风险提高,48,一、业务支撑网架构与功能/业务组织架构现状（一）北京移动（二）上海移动（三）江苏移动（四）广东移动（五）湖北移动（六）吉林移动（七）MISC二、四省一市业务支撑网现状调研情况三、集团公司访谈情况四、中国移动业
38、务支撑现状问题分析,目录,组织架构业务支撑网概貌业务支撑网存在的主要问题05/06年对业务支撑网的改造关键集成商状况新业务开发流程关键发现,49,BMCC业务支撑网现状扫描05/06年对业务支撑网的改造,04年启动了BOSS系统速赢方案，对影响北京移动BOSS系统的稳定性、性能、扩展性等各方面的问题进行全面分析，05年根据速赢方案建议进行有效整改。04年CRM系统一期上线，其中整合了客服应用和网站自助部分；05年二期功能上线，包括现有BOSS前台营业厅功能，电子渠道建设、大客户推广、代销商管理等。梳理了促销活动管理、销售活动管理、客户服务管理这三个关键业务流程并进行有效推广。06年进行CRM3
39、期建设。05年开始启动BOSS3期建设项目，从可扩展性、管理维护、性能、稳定性等方面解决旧BOSS系统的问题，在前瞻和统一的业务支撑网规划原则指导下，建立面向3G的一体化BOSS系统。,关键发现通过专业COTS产品的实施，结合端到端业务流程下的系统分工和整合，接管旧BOSS系统的计费、采集和开通模块，以及相应的数据和流程，建立面向3G的一体化BOSS系统。,50,一、业务支撑网架构与功能/业务组织架构现状（一）北京移动（二）上海移动（三）江苏移动（四）广东移动（五）湖北移动（六）吉林移动（七）MISC二、四省一市业务支撑网现状调研情况三、集团公司访谈情况四、中国移动业务支撑现状问题分析,目录,
40、组织架构业务支撑网概貌业务支撑网存在的主要问题05/06年对业务支撑网的改造关键集成商状况新业务开发流程关键发现,51,BMCC业务支撑网现状扫描关键集成商状况,HP:50多人需求管理：BMCC提出需求，HP分析需求，一部分自己配置，一部分给厂商配置，然后连调测试，BMCC负责UAT测试，最后上线。评价：建议加强集成能力开发方式：驻地成效：一般困境：人员集成能力亚信：45人（其中8人外聘）需求管理：BMCC提出需求，亚信分析需求，安排自己配置、接口开发、联调测试，BMCC参与UAT测试，最后上线开发方式：驻地成效：一般困境：财务和人员上均存在较大压力，目前逐步缓解。,关键发现多个COTS产品对
41、集成商要求很高,52,一、业务支撑网架构与功能/业务组织架构现状（一）北京移动（二）上海移动（三）江苏移动（四）广东移动（五）湖北移动（六）吉林移动（七）MISC二、四省一市业务支撑网现状调研情况三、集团公司访谈情况四、中国移动业务支撑现状问题分析,目录,组织架构业务支撑网概貌业务支撑网存在的主要问题05/06年对业务支撑网的改造关键集成商状况新业务开发流程关键发现,53,BMCC业务支撑网现状扫描新业务开发流程,54,一、业务支撑网架构与功能/业务组织架构现状（一）北京移动（二）上海移动（三）江苏移动（四）广东移动（五）湖北移动（六）吉林移动（七）MISC二、四省一市业务支撑网现状调研情况三
42、、集团公司访谈情况四、中国移动业务支撑现状问题分析,目录,组织架构业务支撑网概貌业务支撑网存在的主要问题05/06年对业务支撑网的改造关键集成商状况新业务开发流程关键发现,55,北京移动业务支撑网现状扫描关键发现汇总,业务运营中心是有生产职能，缺少管理职能和规划职能，虽然有一个人负责IT系统的规划，缺少权威性，资源严重不足，无法真正实现业务支撑网的中长期规划。业务支撑中心和信息技术中心按照项目进行组织，缺少横向沟通和统一的需求管理、架构控制，导致系统之间的边界不清，集成难度加大。各个专业子系统各司其职，由EAI进行企业内部集成。业务需求变化过于频繁对系统稳定性带来极大挑战。支撑网边界模糊问题（
43、与业务网、核心网等）。COTS产品在本土化应用中灵活性欠缺。COTS产品对集成商能力要求较高，系统集成风险提高。通过专业COTS产品的实施，结合端到端业务流程下的系统分工和整合，接管旧BOSS系统的计费、采集和开通模块，以及相应的数据和流程，建立面向3G的一体化BOSS系统。COTS软件的集成对集成商提出了更高的要求。前期需求变化过于频繁导致周期延长。,56,一、业务支撑网架构与功能/业务组织架构现状（一）北京移动（二）上海移动（三）江苏移动（四）广东移动（五）湖北移动（六）吉林移动（七）MISC二、四省一市业务支撑网现状调研情况三、集团公司访谈情况四、中国移动业务支撑现状问题分析,目录,57
44、,一、业务支撑网架构与功能/业务组织架构现状（一）北京移动（二）上海移动（三）江苏移动（四）广东移动（五）湖北移动（六）吉林移动（七）MISC二、四省一市业务支撑网现状调研情况三、集团公司访谈情况四、中国移动业务支撑现状问题分析,目录,组织架构业务支撑网概貌业务支撑网存在的主要问题05/06年对业务支撑网的改造关键集成商状况新业务开发流程关键发现,58,上海市业务支撑网现状扫描组织架构,信息系统部,系统架构部,应用管理部,运行管理部,整个IT系统架构规划设计,新业务管理、需求跟踪管控,IT系统运维质量监控、投诉分析,计费中心,服务支撑部,应用开发部,运行维护部,系统报障处理,新业务、新项目开发
45、,系统运维处理,帐务处理部,帐务催欠、帐务调整,集团公司业务支撑系统部,专业管理,关键发现信息系统部和计费中心是2个平行组织信息系统部有管理和规划职能，负责整个IT系统架构规划和控制，致力于企业管理系统、业务支撑系统内部和外部的系统分界清晰和有效集成。但是无法掌控网络运营支撑系统（OSS）和业务网系统（IN和MISC）的需求和架构。在专业管理上不与集团公司业务支撑系统部衔接。负责本企业内部的需求跟踪和管控计费中心只有业务支撑系统的生产、运维、建设职能，没有管理和规划职能，专业管理上对应集团公司业务支撑系统部，按照BOSS规范等进行建设，但是在架构上服从信息系统部的总体规划和设计。,59,一、业
46、务支撑网架构与功能/业务组织架构现状（一）北京移动（二）上海移动（三）江苏移动（四）广东移动（五）湖北移动（六）吉林移动（七）MISC二、四省一市业务支撑网现状调研情况三、集团公司访谈情况四、中国移动业务支撑现状问题分析,目录,组织架构业务支撑网概貌业务支撑网存在的主要问题05/06年对业务支撑网的改造关键集成商状况新业务开发流程关键发现,60,上海市业务支撑网现状扫描业务支撑网概貌,关键发现1、需要解决计费系统的及时性和准确性问题，如何在井喷式的3G数据业务场景下控制欠费，是业务稳健发展的关键。需要参考IN-GATEWAY的经验教训。2、需要加强对SP的监控，3G业务的发展必然经历从不成熟到
47、成熟的演进过程。如何减少过程中的客户损失和移动公司的损失，降低3G业务投诉，提高服务形象，是下阶段面临的一大课题。3、需要进一步考虑业务支撑系统建设与移动总ONECM规划之间的关系，尤其需要重新思考DSMP、CBOSS、集团客户管理的全局业务原则和系统架构的问题。4、确定系统边界：3G业务网元模糊了业务支撑网与通讯网的边界，需要界定业务网的边界。5、设计规划体制上的两头蛇问题：3G业务的发展锐化了数据中心和计费中心在新兴的边缘业务上的系统设计冲突，架构设计的裁判权需要界定。,61,上海移动数据域说明,62,上海移动现有系统技术架构,63,上海移动CCS/BBOSS系统目前的架构,64,一、业务
48、支撑网架构与功能/业务组织架构现状（一）北京移动（二）上海移动（三）江苏移动（四）广东移动（五）湖北移动（六）吉林移动（七）MISC二、四省一市业务支撑网现状调研情况三、集团公司访谈情况四、中国移动业务支撑现状问题分析,目录,组织架构业务支撑网概貌业务支撑网存在的主要问题05/06年对业务支撑网的改造关键集成商状况新业务开发流程关键发现,65,上海市业务支撑网现状扫描业务支撑网存在的主要问题,1.缺乏对非即开即通流程的支持2.对不断发展的多样化的业务无法进行完全配置，导致二次编码过多，bug也容易出现3.缺乏面向内容的计费能力4.出账流程外挂平台过多5.核心业务实体缺乏统一的数据定义,现有数据
49、结构与eTOM/SID国际电信行业先进标准相比存在差距客户，产品资费等缺乏完整统一信息模型,数据处理尚缺乏统一的原则和规范。6.系统结构过于紧耦合，不利于独立部署和扩展。7.功能定义划分不清晰，没有同一的PORTAL界面。8.缺乏规范的容错管理。BASS：数据仓库中最重要的DW层的设计过于明细，接近于ODS层，综合程度低。在此基础上做应用的代价较高，相当于从底层重新汇总，长此以往，不仅会增加机器负荷，还会增加开发的难度和工作量,66,一、业务支撑网架构与功能/业务组织架构现状（一）北京移动（二）上海移动（三）江苏移动（四）广东移动（五）湖北移动（六）吉林移动（七）MISC二、四省一市业务支撑网
50、现状调研情况三、集团公司访谈情况四、中国移动业务支撑现状问题分析,目录,组织架构业务支撑网概貌业务支撑网存在的主要问题05/06年对业务支撑网的改造关键集成商状况新业务开发流程关键发现,67,上海市业务支撑网现状扫描05/06年对业务支撑网的改造,业务支撑的优先级：业务优先（市场驱动）、架构优化（管理驱动）。当业务紧迫度和架构优化的时间发生冲突的时候，首先满足业务需要，然后再进行架构的优化。2004，业务支持。扩展业务支撑范围，填补业务空白。2005，系统整合。整合外挂，整合系统，梳理支撑系统之间的关系。2006，拆分BOSS。主要解决系统稳定性和灵活性的矛盾，目前尚未涉及到如何解决计费系统的
