相爱相杀:移动联通IT支撑回忆录五七

发布时间:2022-06-29 01:32:51 来源:火狐体育apo 作者:火狐体育主页

  注:前文说到,BOSS1.0,解决了中国移动省级业务支撑系统的基础问题(详情可查看前文《相爱相杀:移动联通IT支撑回忆录(1-4)》)。经过三年时间,各地陆陆续续完成了省级系统的建设,可接下来该如何走?

  我写的不是小说,而是我的印象和记忆中,移动与联通有关IT支撑的历史往事。

  在十数年间,双方相互学习、相互借鉴,同时又相互竞争、相互敌视,在不同的阶段交替领跑。

  在这些现象背后有什么深层次的原因,又是哪些偶然的因素,造就两家运营商前台营销竞争激烈,后台支撑相爱相杀?

  一般情况下,运营商会选择结构性升级,这种方式从技术角度提出立项的理由,似乎更符合常规的发展模式。

  为此,中国移动支撑系统的规划团队最早完成的BOSS2.0的规划设计方案,提出了将系统分拆解耦,形成后台以计费为核心的BOSS系统,和前台以营业为核心的CRM系统。

  靠一套系统,支撑全省的业务,这在本世纪初可不是容易的事情,技术、业务、管理,诸多方面都尚不成熟。

  由于有时间进度方面的压力,系统建设也基本是赶工状态,有众多技术问题没有处理好。

  在技术、需求都没有完全固化的情况下,立刻进行系统拆分,会给支撑系统带来技术方面的不利。

  其二,完成了一期系统建设后,省公司对系统开发商的能力有了进一步认知,而集成商也认识到了自身的优势和不足,甲乙双方都有人惦记进行调整。

  如果这时推颠覆性的技术方案,就可能让支撑系统这个市场格局陷入混战的格局。刚刚积累起来的人、财、物,也会因为格局的变化,陷入动荡混战,而忽视对现网的服务支撑。

  其三,在BOSS1.0系统的建设过程中,省公司将各地市的业务进行了汇总和梳理,开始考虑平滑过渡,系统对所有的业务都要支持。而等系统上线,业务策略也逐渐清晰,新的业务需求已经逐渐清晰。

  此时,业务部门更需要的,是一个稳定和强大的支撑系统。而如果系统仍主要着眼于升级改造,不利于为业务的发展提供有效支撑,可能错过商机。

  因此,虽然2.0的升级方案已经完成,但经过慎重考虑,移动还是最终选择了1.5的过渡改造方案,以提升系统能力为主要目标,务实地做好对业务的支撑和帮助。

  在移动大发展的那段时间里,业务支撑系统无论是新业务还是套餐,无论是受理客户投诉还是提供服务咨询,无论是一线营销还是后台统计,支撑系统整体表现都比较给力。

  这种以稳定为主、务实保守的方式,也成为之后几次BOSS系统扩容的主线级的升版模式,也成了业务支撑系统的特色。

  毕竟,系统规模庞大功能多,开发商要同时做到成本低、系统稳定、响应速度快、服务态度还好等诸多目标实属不易,即使做到了全面支撑,也难以满足所有的局部需求。

  一种情况,是公司认识到BOSS系统的重要性和价值,对现有厂商能支持未来的信心不足,希望换一个更加稳定、专业、可靠的合作伙伴。

  另一种情况,是公司的主要领导变更,觉得现在的BOSS厂商不合适,希望换一个更顺手的。

  第一类。是经历过BOSS建设之后,认识到自身在技术、资源等方面的不足,或者认为这种项目赚钱太辛苦,希望择机退出。

  第二类,是收到了比较理想的收购要约,连客户带技术团队打包转让,老板自己功成名就。

  第三类,是企业内部管理出现了问题,甚至分崩离析,严重到影响客户利益的程度,要对各方有个交待。

  而此时,也有一些厂商希望扩大客户范围,靠规模去摊薄研发和管理成本,以此带动自身效益增长,比如亚信。

  在中国移动总部来看,技术变强、稳定性变高、管理越来越完善的合作伙伴,是支撑系统开发商的理想发展模式。

  如果,以市场化的方式实现BOSS系统开发商的重组更迭,比硬碰硬死磕更有利于整个专业的发展。

  由此可见,BOSS1.0之后出现的集成商收购重组浪潮,是各方都愿意接受的结果。

  大厂商希望通过收购扩大地盘,提升规模效益;新厂商花钱买市场,一下子越过了高门槛;而小厂商趁着还没被赶走,把客户和技术团队卖个好价钱。

  借助BOSS1.5工程以及后续几次扩容改造,移动的BOSS不仅实现了系统功能和规模容量的扩充,也悄然完成了合作伙伴的更迭。

  在BOSS系统从1.0逐渐升级的同时,移动还做了一项大工程,就是经营分析系统。

  我们先进行计费系统的集中,在此基础上再把营业账务集中了,然后才能进行客服系统的整合。之后,我们就可以基于这些系统的数据建设数据仓库,基于这些系统的应用推进电子商务。这段线说的。

  当时,在和省公司的计费部门座谈交流时,一些同事对实施移动电话省级计费系统集中化心存顾虑,而我则对未来充满了信心。

  前几个步骤,移动扎扎实实地走了过来,尤其是BOSS集中化的实施,全方位地提升了支撑能力。

  如同前几章所言,2001年做完了BOSS规范,启动了工程项目,业界的资源已经聚集在了中国移动周围,我们的判断是,这一仗赢定了,于是转头开始走下一步--建设数据仓库。

  如果不是当年移动刚刚成功地做成了BOSS系统,那么经营分析系统的建设就不可能完成。

  移动的经营分析系统是在规划为主、需求为辅的情况下启动的,如果不是对总部的指挥有信心,恐怕各省没有那么大的决心和动力,花钱建一套技术不成熟、需求不完备、投资相当大,而且当时战略价值不那么突出的系统。

  而BOSS系统完成了系统数据的整合和支撑能力的提升,给数据仓库系统的建设打下了基础;BOSS的成功更树立了IT支撑队伍的信心,以及总部在系统规划层面的威望。

  所以,我经常讲,最强大的执行力不是来自于上对下的权力,而是下级对上级的信任;虽然承担这种信任会有很大压力,但是这种上下同心同德,才是能做成大事的保证。

  话题扯远了,回来再说移动数据仓库系统立项的艰难过程,看如今大数据的火热,难以想象当年做数据仓库系统的艰辛。

  在大多数人看来,BOSS已经是投资巨大的IT支撑系统,有海量的数据,也购买了大量的硬件存储,为什么还要花钱再建一个数据仓库系统,直接在BOSS系统上做分析不行么?

  专业术语很难解释清楚,我们可以用类比的方式来,解释数据仓库系统建设的必要性。

  BOSS系统的数据处理是OLTP,是面向交易的生产系统,就像菜地的设计是为了丰产,要播种、施肥、除草、收获方便,这一垄全是土豆,那一垄都是茄子。而分析师就是大厨,要想做道地三鲜,就需要对地里的蔬菜重新处理。

  原始的方法,是让大厨自己去菜地。农家菜都是这么凑活弄的,种菜、洗菜、炒菜、上菜,端盘子记账洗碗筷一条龙,反正量小,无所谓。

  可是要想做出专业的菜肴,专业厨师的心思应该花在烹饪环节,不可能操心太多原材料的事儿。而且,菜地里一天到晚都是来摘菜的闲杂人等,也影响生产。

  就像在生产系统里总跑大数据量的统计运算,会极大消耗计算机的性能,影响正常业务处理。

  专业协作的模式就不一样了。要把菜地的产品转运到菜市场(数据仓库),放进菜市场之前还对他进行了清洗和简单处理,类比在数据仓库系统里就是ETL的过程。

  菜市场里各种原料的摆放方式和菜地不同,目的不再是为丰产,而是为了取菜的便利和销量(数据利用效率)。厨师可以自己去菜市场买菜,也可以由采买人员拎着菜篮子进菜市场,按照厨师开的单子照需求抓原料。

  所以,建数据仓库系统就相当于盖一个菜市场,让市场人员得以专心去做专业的分析工作,而且不影响生产系统的工作效率。

  如今,大数据的概念风起云涌,到处都有人在忽悠,可在当时,说运营商通过数据分析来发展业务,还是绝对的新鲜事。

  IT人员从发展的角度看,坚持认为建设数据仓库系统是必要的;计划部门秉承通信网络的管理模式,认为需求不足、经济效益评估差就不该立项;这时候业务部门的态度至关重要。

  十几年前,在移动通信大发展的时代,只要网络容量有了,系统能力和号码资源跟得上,市场发展几乎无上限。只要稍微进行一次价格调整,或者推出一款针对性的套餐,用户就哗啦哗啦地进来,数据分析最多是事后的统计,不需要多么专业。

  有幸的是,移动的领导们没有那么短视,业务部门也明白市场不会这么一直舒服下去,应该尽早做好精打细算过日子的准备,因此非常支持数据仓库系统的建设。

  中国移动的数据仓库系统的名字,就叫做经营分析系统,就是为了体现出这一系统和市场业务的紧密关系。

  而为了更好地体现业务需求,支撑部门进行了全国范围的调研,整理出九大类、上百项数据统计分析需求,作为全网建设的业务目标。

  现在看起来,这些需求有的价值不高,在实战中发挥的作用也不大;但靠这些或靠谱、或不靠谱的需求,推动起来的经营分析系统,却为中国移动的发展发挥了越来越重要的作用。

  当时,完成了规划立项,等到真开始动手做技术方案的时候,我们才意识到,经分系统可比做BOSS难多了。

  当时,除了数据仓库的几个基本概念之外,中国移动几乎一无所知,而国内在这一领域的储备、案例也都是少之又少。

  我们从基本概念开始,一边学习一边梳理思路,既要师从国外先进技术,又要考虑国内实际情况,既要借助厂商资源,又要避免过度依赖,这当中经历了很多波折,也发生了很多故事。

  当时的移动,做数据仓库可谓天时地利人和:不仅有足够的资本,还有BOSS一役成功后积累起来的海量数据,更有一批想做事情的IT人。

  我们认为,数据仓库是发展趋势,如果尽早启动数据仓库建设,可以为企业的发展储备数据、积累人才,更是在IT行业发展处于相对低谷的时候,带动其成长的好机会。

  如今,我们可以自豪地说,当年中国移动推进经营分析系统建设,在战略上是成功的,在技术方面承前启后,为后来数据仓库、数据分析,以及当下热门的大数据,立下了汗马功劳。

  各式各样的厂商都在讲啤酒和尿布的案例,都说这是自己的客户,而这个案例是自己产品的功劳;细讨论下去,才知道哪些是报表展示工具,哪些是ETL工具,哪些是做元数据管理的,哪些是建模分析用的。

  对于我们来说,花一些时间搞清楚基本概念是必要的,但最关键的,还是怎么才能把核心数据仓库建起来。

  十几年前,国内关于数据仓库的成功案例太少,有限的一些项目仔细看下来,不过就是个报表系统或者专题分析,鲜有真正搞大规模数据仓库建设的。

  那时,很多公司的技术人员嘴上说的热闹,真问下去也都只是纸上谈兵,其原因也在于根本没有实践机会。

  既然都不知道怎么做,那就摸着石头过河吧。国外的经验可以借鉴,但不能也不会照搬过来。

  如今回头来看,在中国移动的经营分析系统建设中,有很多创新,有很多尝试,当时看起来非常大胆,但核心都是如何围绕中国移动的特点,解决中国移动面临的问题,得出的解决方案。

  最初,几乎所有厂商都认为,中国移动会建一个完整的数据仓库,因为数据越全,数据仓库的价值越高,能做的分析越多,这是数据仓库建设的基本模式。

  当时,中国移动的全网用户已经上亿,全球还没有这么大规模的数据仓库建设案例。

  有一次,一位微软的专家来介绍产品,被我们质疑其产品对大数据量的支持程度,专家急了眼,对我们说:你们总在质疑我们的产品是否支持TB级的数据处理,其实我们很怀疑,你们的数据有没有达到TB级的规模。

  这句话,如今听起来也许觉得可笑,可当时的技术水平确实如此,到了TB规模,很多产品就已经顶不住了。

  于是,我们选择了31+1的模式,就是在31个省里建设省级经营分析系统,同时在总部建一级经营分析系统。省级经分为省公司的营销、服务做数据服务和分析支撑;一级经分为总部的管理和决策做支撑服务。

  这种系统建设模式,既解决了技术约束的问题,也与中国移动的经营管理模式匹配,当时在全球算是独一份了。

  如果把全国全部数据纳入进来,技术方面不支持;但如果只拿汇总数据建库,数据的准确性以及分析的颗粒度等方面受限,一级经分的价值也会降低。

  最终,我们的解决方案里,除了全量的汇总数据之外,移动的一级经分系统还以抽样方式,从省级经分那里获取部分细节数据。

  这些抽样的细节数据,既可以用于某些场景的分析,还能用来对省级系统上传的数据进行验证,在一定程度上限制省公司作假的空间。

  从今天往回看,似乎没有必要在每个省都建一套经分系统。毕竟,各地的竞争情况不一样,有些省公司也反映过,说他们的分析需求并不急迫,建设经分系统带来的投资压力大,对技术的要求也高,对于他们来说过于超前。

  但换个角度看,经分系统的建设和运营也是一种练兵。数据、人才和能力的储备是面向未来的,是需要长期、持续进行的,时至今日,我仍坚持自己的判断--十年前在这方面就开始投入,是值得的。

  第二个问题,是数据仓库建设的技术方案选择,具体来说,就是建什么样的数据仓库。

  一个是以IBM和ORACLE为代表的应用派,技术理念是面向应用进行数据的获取和建模,类似于我们说的数据集市;把一个个数据集市建起来了,也就成了数据仓库。

  另一个流派是以NCR(后来的TARADATA)和SYBASE为代表的,认为要把数据仓库建起来,再根据应用的情况调整分析模型、优化数据仓库结构。

  其一,如前所述,中国移动数据仓库系统的建设,是在业务驱动不足的情况下开展的。如果比较多地依赖应用来推动建设,那么建设周期会比较长,而且建设规模也不一定大,难以达成通过系统建设沉淀数据的目的。

  换句话说,以数据为核心,先建数据仓库再做应用的建设模式,与数据仓库的建设战略规划更匹配。

  其二,在国内外各方均无太多成功经验的情况下,NCR公司展示了他们经过几十年海外客户的经验积累,最终形成的电信行业数据模型。

  如果利用这一模型建设中国移动的数据仓库,无疑是直接站在了巨人的肩膀上,可以极大地减低我们摸索试错的成本,缩短建设周期。

  在中国移动总部编制规范的过程中,NCR立下了汗马功劳;他也因此获得了商业方面的巨大成功。如果说,BEA公司是BOSS时代退信三层架构时的受益者,那么NCR在移动经分系统领域的成功,则是其努力和贡献所收获的成果。

  此外,IBM和ORACLE公司依靠其强大的技术后盾和市场营销能力,也在经分系统建设中分了一杯羹。

  借助合作伙伴的力量,中国移动的数据仓库用了不到五年的时间,就走完了海外三四十年才经历的道路,一举建成了全球规模最大的数据仓库体系。

  然而,随之而来的也有质疑:做项目不能只为了拿奖,搞创新不能只为了作秀,做企业在商言商,更要看IT系统带来多少经济效益。

  高大上的经分系统一度面临巨大的压力,这个压力如何体现,又如何破解?我们下回再说。返回搜狐,查看更多

上一篇:IT支撑系统:是“翅膀”还是“累赘
下一篇:全业务IT:支撑系统进入“后建设时代”