关于运营商支撑系统建设流程的思考

2011-07-27宋齐军中讯邮电咨询设计院有限公司北京100048

邮电设计技术 2011年8期

梅斌，汤泳，宋齐军（中讯邮电咨询设计院有限公司，北京100048）

0 前言

伴随国内电信运营市场的改革、重组和不断优化，以及计算机及互联网应用技术的驱动，运营商支撑信息系统的概念在20世纪末被提出并不断明晰。经过10余年的建设、发展和演变，支撑系统的构成越来越庞大，支撑的流程和功能越来越复杂，支撑系统也已成为企业的管理和运行、业务的运营等方面的重要基础设施、手段，企业对其的依赖性不言而喻，就如同通信网络是运营商在电信业务和服务能力方面的基础设施一样。支撑系统也是企业核心竞争力的重要因素之一。

运营商支撑系统通常包含了管理支撑系统域（MSS）、业务运营支撑系统域（BSS）、网络运维支撑系统域（OSS）3个组成部分，各运营商在系统名称上的叫法不同或界面划分略有差异。

长期以来，运营商支撑系统的建设管理参照通信网络工程的模式，而对于支撑系统建设的特殊性未予充分关注或重视，主要原因也包括在运营商的基建中通信网络建设投资占绝对的主导地位。但是，随着企业对支撑系统的期望越来越高、依赖性越来越大，加之系统越来越复杂等原因，现行的支撑系统建设管理模式和流程的不适应性的相关矛盾日益凸显。本文旨在对这一问题进行讨论，也是笔者的一些思考，更是希望起到抛砖引玉的作用。

1 支撑系统建设的相关特点

相对通信网络工程建设而言，支撑系统建设项目有其特殊性，主要表现在以下几个方面。

a）支撑系统的定制开发特性。通信网络广泛互联的需要决定了其设备组件的标准化和产品化基础很成熟，通信网络工程的主要任务是根据运营商自身的网络规划和设计（也包括相关企业级标准）选择合适的产品设备来构建或扩充电信网络。而支撑系统建设中，基本上不太可能在市场上选到即买即用的产品，而需要进行应用系统的定制开发。事实上，支撑系统建设的使命在于：要通过支撑系统构筑运营商企业内部的管理、运行、运营等方面的逻辑或关系。而不同企业内部的这些逻辑、关系不可能都一样，因此支撑系统需要进行定制开发。

b）支撑系统的标准化基本限于企业级，且待深化。运营商在支撑系统的标准化方面正做着不懈的努力，企业级的标准体系初步形成，但显然不尽完善，不尽人意。目前的现状主要表现为：关注系统应具备的功能，关注并能及时解决系统之间的接口问题（无论付出多大代价），标准的指导性强于约束性（即标准研究制定过程中的对相关方面的指导性更有效），而标准在对系统内部（例如信息模型/数据结构）的约束、模块化、组件化、系统的可扩展性、可维护性、质量和性能等方面的要求较弱。当然，也还达不到产品级约束的程度。

c）工程建设周期客观上较长。支撑系统的一个建设项目通常就是一个软件工程周期，其中需求分析与设计、系统概要设计、详细设计、软件编制与调试、验证与测试等都需要合理的周期，因此较复杂的工程项目基本上不可能在一年内完成真正意义上的竣工验收。而且，基于现在的资源条件，建设单位很难很好地主导项目周期中的一些重要环节，而更多的自主权掌握在开发厂家方面。

d）由分散、多级到统一规划设计、集中化管控的趋势。对于运营商而言，支撑系统的集中化管控应该是一种趋势，包括规划、建设乃至运行和维护。这主要是由多方面因素决定的，例如企业跨地域的一体化运营管理方面的要求、支撑系统自身越来越庞大和复杂的互联关系、应用技术上也基本不存在障碍。集中化管控对于集中管理者在业务和技术方面提出了更高的要求和挑战。

e）支撑系统建设管控的有效性主要取决于运营商自身的管控能力，这种管控能力包括企业是否有明确并可落地的IT规划、发展和建设节奏的掌控以及具体建设项目的掌控等。而管控能力的有效性需要由相应的机制和技术资源予以保障。

总之，相对通信网络工程而言，支撑系统建设项目中对运营商自身的要求更高，提出的挑战更多。而且，关于支撑系统建设投资的评价也不应简单地以投入产出为原则，而是取决于运营商自身的总体IT战略和发展规划，因为支撑系统建设所追求的目标是支持企业运营和管理上的降本增效、以及运行上的高效，而不是直接形成某种电信业务层面的生产力。

2 支撑系统建设管理模式的基本现状

目前支撑系统建设项目的管理流程与通信网络工程基本类似，主要包括三年的建设滚动规划、年度建设计划、工程可研、厂家开发、工程设计、实施及调试、工程验收等。以下仅就几个方面予以分析。

a）滚动规划及年度计划。在IT战略规划薄弱或者规划落地性不强的情况下，滚动规划和年度项目计划安排缺乏足够的输入和依据，往往基于对现状改造方面的需求、业务经营发展方面的支撑需求等因素，而在前瞻性、有序发展方面不够充分。进而导致年度计划中的安排可能被打乱或做较大调整。

b）具体工程项目的可行性研究。具体项目的可行性研究主要解决工程方案、并回答投资额及工程周期等问题，从而作为决策的参考依据。限于客观条件（例如可行性研究的费用、报告文本提交周期等），可研工作的视野往往局限于怎么最好地实施好工程，即工程项目本身，同时尽可能细地对工程量（包括对相关联系统的影响）予以评估。而运营商有时候关注的项目上的必要性、合理性，则应该是在规划层面或年度计划安排层面予以解决。这种纠结往往会成为一个死循环。

c）厂家开发。运营商提出的业务支撑需求更多地限于业务规则和业务流程层面，而结合潜在需求、结合系统现状等的系统需求分析与设计的工作开展得不够充分，系统开发（包括升级改造）的主动权主要掌握在厂家方面，虽然运营商提出的业务功能需求可能得到很好的满足。

d）产品测试与验证。厂家开发的系统产品在被测试时，更多地是在业务功能或功能概念层面、以及系统之间的接口层面，而其他方面往往被忽略，这与运营商支撑系统的标准的现状也基本一致。由于对系统产品内部（结构设计、模型设计、质量、性能等）掌握不够，这很可能导致后续系统升级、扩充、或与外部互联时的改造不易评估，尽管本期完成的系统很好地实现了当前提出的功能要求。

总体上看，在支撑系统的建设和发展过程中，运营商自身的掌控力度还不够充分。原因主要是运营商与厂家之间在资源和能力上不对等，而显然双方在利益上追求最大化方面本身就是一对矛盾。具体地讲，运营商缺乏的资源可能包括：企业关于支撑系统的明确发展规划及持续的调整机制较弱、缺乏系统规划设计和需求分析设计方面的技术资源、相关的企业级技术标准有待深化（包括相应的机制和资源）等等。

3 支撑系统建设管理流程优化的设想

基于上述的相关分析和思考，对支撑系统建设管理流程的优化提出如图1所示的设想。

图1 支撑系统规划及建设流程设想示意图

对于支撑系统建设流程优化的设想，主要是强调了现行流程中有些环节的增强或增加，主要包括以下几个方面。

a）支撑系统规划设计及持续的优化、深化及调整。系统规划设计不仅要解决系统的整体架构及系统组成、流程及集成关系等，也要落实系统有序建设发展的策略和节奏，确保可落地、可执行。在此基础上，结合业务支撑需求、系统现状等因素，可靠的年度建设项目计划应该可以很好安排。

b）加强业务支撑需求分析与设计、系统建设需求分析等相关的技术工作。运营商在这方面的工作目前可能比较薄弱，但这是运营商增强对建设项目和系统的掌控力度的基础，应逐步加强。

c）加强验证测试工作。这方面包括：对运营商制定的技术标准进行验证、对厂家开发的系统产品进行测试和验证等，以逐步确保系统与企业标准的一致性。上述几个方面在客观上都要求运营商要加强自身相应的技术资源队伍的建设，而不太可能主要依靠厂家来达到目的。运营商应通过建立相应的团队来形成这些工作的常态机制，从而在实质上逐步加强对系统的掌握和管控。

4 支撑系统建设管理的症结探寻

支撑系统的建设管理从本质上看也是一种工程管理，可为什么经过这么多年的实践，从事这项工作的人仍然觉得一言难尽呢？最根本的原因在于三点：一个是系统功能标准化不足，一个是系统间缺乏清晰的界限和稳定的接口标准，另一个是新需求提出缺乏可控的模板。

系统功能标准化不足的具体表现为：系统功能描述停留在笼统的功能说明层面，未对功能实现的具体环境、条件限制和输出结果进行准确的定义，导致功能开发和最终验收很大程度上依靠主观标准来判断功能实现与否；功能要求中忽略细节，整体看各种功能均已实现，具体使用时细节表现难以让人满意。

系统间缺乏清晰的可分割的界限和接口标准表现为：系统间功能替换时理不清两者间的关系，很多功能实现隐含在代码中，割接后发现原有功能缺失；系统实现过程中，迁就原有系统的能力或开发厂商，无原则划定功能的责任系统；接口标准没有延续性，信息的变动未做到有效的隔离，通过接口传递到后续系统时，引发关联系统的接口变化。

新需求提出缺乏可控模板的表现为：业务部门和技术部门定义需求时，没有需求量化的标准模板，缺乏需求定义的参考约束，高估软件实现的灵活性，导致不同时期或不同人员的需求定义结果差别较大，很容易超出应用系统自身架构设计的能力边界。

系统功能标准化不足和接口标准不稳定的直接后果就是支撑系统工程管理中对功能或性能不佳的模块难以找到可替换品，已经很完备的功能在后续割接中不能延续，难以打破软件工程重复造轮子的怪圈。在系统不断的升级割接过程中，原有功能不断面临被重写的命运，而新写的模块通常也很难注意到在原模块生命周期内不断夹杂进去的“私货”。

新需求提出缺乏可控的模板带来的后果是新需求可能对系统架构造成冲击，为完成需求必须对现有软件系统架构进行改造或打补丁，使得健壮的系统架构逐渐处于崩溃的边缘，工程建设管理陷于“救火队”的角色。