将业务和网络分离业务类项目建设流程现存问题及改进建议.docx
《将业务和网络分离业务类项目建设流程现存问题及改进建议.docx》由会员分享，可在线阅读，更多相关《将业务和网络分离业务类项目建设流程现存问题及改进建议.docx（10页珍藏版）》请在冰豆网上搜索。
将业务和网络分离业务类项目建设流程现存问题及改进建议
将业务和网络分离
－业务类项目建设流程现存问题及改进建议
张雄飞
工程建设中心计划调度中心
摘要：
随着新业务研发、支撑类系统对于塑造企业核心竞争力作用的不断加深以及3G时代的到来，公司核心网类项目中，越来越多的出现业务占主导地位的项目，包括现行定义中的新技术新业务和支撑网类项目。
如何理顺这类项目的建设流程，规避风险，促进业务拓展，以便应对未来公司发展和市场竞争的挑战成为一个重要的课题。
作者结合近年来这方面的工作经验，对于上述问题进行了总结、归纳，并提出了一些建议。
本文通过分析当前业务类项目的特点、建设过程中存在的问题，藉由几个新提出的概念，希望能对业务类项目管理的完善发挥积极的作用。
关键词：
业务网络分离流程建议
I.引言
1、问题的提出
作者入职五年多来主要负责我公司绝大部分支撑网系统、信息系统、客服网络建设项目，及部分网管类项目、数据业务部发起的新技术新业务类项目的实施、项目管理、配合等。
问题的初始提出是作者工作中发现这些项目在建设流程中出现了一系列问题，主要由于当前的项目管理分工不明确导致的。
在过往集团公司召开的工作会议上，绝大多数兄弟公司也提到了此类问题。
为此，计划建设部也出台过弱矩阵项目管理体系，但效果并不好。
经过仔细的分析、交流，个人认为问题出现在对当前项目的分类以及管理思路套用上。
同时和业务部门同事交流时，也经常提及此类问题，甚至07年几个数据业务部同事的对于离职原因的调查，也不约而同的提到了业务流程不畅的问题。
综合个人的工作经验、思考、当前的发展趋势等，本文提出“将业务与网络分离”的核心思想，并对当前此类项目特点及存在的主要问题进行归纳，深入分析其影响，从而从执行细节上对业务类项目建设流程改进提出建议，并提炼出几个新的概念抛砖引玉。
为此，引言中先将公司的建设项目重新分类。
2、当前公司核心网建设项目默认的分类
当前核心网项目分类思路主要是按技术用途分类：
交换网（G网/TD）项目
信令网项目
传输网项目
业务支撑系统（BOSS、经营支撑系统、CRM等）项目
网络支撑系统（网管系统、信令网）项目
新技术新业务项目（CMNET、GPRS/WAP、短信/彩信、智能网、数据部立项的项目）
企业管理信息系统（MIS、OA、KM）项目
客服网络、12580呼叫系统、小交换机等项目
上述分类源于传统电信行业中的技术类别划分，尤其对于新兴的IT类项目（如支撑类）、数据业务类项目沿用传统电信行业中对IT等新技术的直观技术分类方式，但随着网络融合趋势的发展，技术的不断更新，这种分类方式已经明显具有局限性。
3、新的建设项目分类
根据当前项目的实际特点、实施方式等，本文将公司的项目划分为两大类：
业务类项目和网络类项目，并分别重新进行定义。
业务类项目：
包括现有的业务支撑系统、网络支撑系统、企业管理信息系统、新技术新业务项目中数据部立项的项目等系统建设项目
其共同的特点是：
1）、业务居于主导地位，网络建设为业务实现底层服务，业务开通才可投入使用，同属于业务与网络可以分离建设的系统，
2）、通常有专门的部门负责业务设计、实现，如：
信息系统部、数据部、网运中心网管网支撑中心等
3）、建设规模参差不齐，视业务系统重要性而不同
4）、系统关注点在于业务是否适用，软件部署和应用是业务实现关键。
网络类项目：
包括交换网、信令网、智能网、CMNET、GPRS/WAP、短信/彩信、传输网、客服网络等系统建设项目
其共同的特点是：
1）、网络建设居主导地位，业务固化或者可以看成业务与网络合一，基本上网络建成、开通即可投入使用
2）、项目立项一般由公司根据市场容量变化而设计、实现
3）、建设规模一般较大
4）、系统关注点在网络容量和处理能力，硬件、网络建设是项目实现关键
这里对GPRS/WAP、CMNET、短信/彩信类项目进行一下特别解释，传统认为这类项目属于新业务，这是早期针对交换网络而言的。
但就运营商来讲，这类项目最重要的是搭建平台，只是技术上与交换网络有区别而已，其真正对应业务类项目的业务开发、推广工作是由数据业务部主导，SP、合作伙伴在建设过程之外完成的。
所以本文将其纳入网络类项目。
网络类项目建设流程在公司已经非常成熟，应用的也比较好，不再赘述。
下文将着重讲述对业务类项目的流程现状的汇总、归纳、分析，以及改进建议。
II.业务类项目建设流程现状及存在的问题
1、业务类项目的特点
1、此类项目投资日益增多，总投资额占全部投资的额度逐渐加大
从统计看，近几年比前两年业务类系统竣工值占公司CAPEX项目（除传输网工程外）总竣工值比例明显提高，超过50％。
目标系统的投资明显提高，工作量大幅增加。
2、此类项目的发展正走向成熟，由功能单一、松散向统一化、集成化、模块化、持续化方向发展
这个特点尤其体现在业务支撑系统建设中。
2004年以来MDCN，统一外联网关，集团业务统一管理平台等多个集成项目都是将已有的业务系统整合，实现统一管理、统一出口等功能。
BOSS、经分、信息系统等都已经形成成熟的体系，不断滚动发展。
3、业务与网络分离，是此类项目的根本特点。
通俗、浅显的讲可以看成是软件与硬件的分离
网络通常依靠硬件及其相关系统软件实现，其中虽然也有软件，但是两者密不可分，甚至可以说软件服务于硬件；业务则更多依靠套装软件、平台软件或者软件开发实现。
此类项目业务的实现也是如此，主要依靠软件应用及开发，硬件上只要能够满足软件核算的处理能力和常见的兼容、安全性等需求，选择什么设备搭建网络并不具备关键意义。
4、此类项目以业务实现为最核心目标，网络建设为业务实现服务
此类项目中软件投资、开发工作往往是项目中关键的要素，对项目完成的质量、进度起着决定作用。
所以，项目管理中软件开发、部署的工作将上升成为和硬件建设同等重要，甚至更为重要的部分，这也决定了此类项目管理的内容与以往的通信网络新建、扩容有着极大的区别。
5、新业务的概念外延不断扩大，内部业务加入后延伸成为泛业务的概念
过去“新业务”的概念是针对交换网提出来的，除了话音业务其他均称为新业务。
本文引言中已对业务类项目重新定义，而这里的业务还可以扩展分为两大类：
外部业务和内部业务。
外部业务由市场需求发起，数据部主导实现、推广；内部业务由企业发展需求产生，多数表现为支撑网或网管网等需求，内部业务部门主导实现、推广，从而形成了一个泛业务的概念。
6、系统完成后，往往存在业务培训、推广的时间和内容
这也是业务类项目的显著特点。
因为此类项目最后多数以形成某业务系统或者扩容该业务系统的功能为结果，如何应用该系统或功能，需要给使用人员（顾客）进行培训和推广，对于系统的应用具有重要关键意义。
这也是业务类项目和网络类项目的重大区别之一。
7、业务类项目所涉及的企业组织结构已经发生变化
近年来，业务类项目所涉及的企业组织结构发生了许多变化：
计费中心、业发中心几经更名，并最终发展成为“部”级单位；数据部的内部分工愈加精细，甚至一个飞信产品就成立了三级部门分管；计划建设部成立了三级部门“业务支撑网规划部”专门负责业务支撑网类、新业务类项目的规划、立项等工作；网运中心内成立了独立的三级部门网管网支撑中心专职负责网管网系统的规划、建设、维护等等，这些都从一个重要的侧面体现了业务系统正日益成为公司中一类重要的组成部分，其项目建设也正在规模化、复杂化和正规化。
2、业务类项目建设流程现状及存在的问题
1、业务类项目建设流程现状
在当前的业务类项目建设流程中，公司并没有明确、独立的分工机制和建设流程。
工建中心是目前公司流程中的项目管理实施部门，故在此类项目实施中，我们采用的是默认的“弹性”的双项目经理操作模式。
原则是以公司利益为主，发挥各部门优势，通力协作，保证项目的顺利实施，而不去过多考虑分工和责任。
现有业务类项目流程主要参考交换网项目建设流程：
工建中心为项目建设的主要责任部门，委派项目经理对项目进度、质量负责；但是业务类项目是以业务实现为主要目标的，所以无论从前期设计还是从项目实施、进度控制等主要过程，业务部门也委派项目经理，并发挥着重要作用甚至主导作用。
所以一般在建设过程中，除了硬件建设外，业务部门实际主导开发、实施等工作，我中心以配合为主。
但业务部门项目经理通常不清楚项目建设的基本流程和资金资产管理流程，交资、验收等工作还会交回我中心主导操作。
这就是前面提到的我中心当前处理此类项目的弹性操作模式，即：
以利于项目进展为根本目标，以公司规定的项目管理流程（核心网项目管理流程）为原则，双方项目经理不对分工做过多纠缠，对于系统实施，业务部门介入较多，我中心就配合业务部门；业务部门不方便或无法操作的事情，我中心就主导操作；对于项目建设的基本流程和资金资产管理流程，我中心全权处理。
2、业务类项目建设流程中常见问题
依据上述模式，我中心项目经理和各业务部门项目经理密切沟通、配合，几年来的项目实施也可以开展，但存在着很多的问题。
归结起来都是一个核心问题造成的：
业务部门与建设部门双项目经理分工不明确。
问题表现在：
（1）、工程类问题：
a）项目前期业务部门以业务设计为基础独自设计网络，与建设部门、维护部门沟通不足。
经常出现设备定制满足业务性能，但不满足机房要求、维护需求，对工期、实施常有较大影响。
b）相关项目实施方案由业务部门负责，从拟定过程到实施过程较倚赖集成厂商，而建设流程要求工程部门委托符合资质的设计人员负责全部方案，设计人员又缺乏能力或者缺乏足够的资源完成设计，使设计流于形式，最终还是依赖于集成商。
既造成了系统设计的责权不明，又加大了项目实施、系统运行的风险。
c）信号线缆布放没有明确定义。
集成商不具备施工资质，但经常由于业务需求的紧急而任意实施布线，施工质量存在极大问题，BOSS三期工程是个明显的例子
d）双项目经理都需要清楚项目全部进度等全方位的情况，增加了和乙方沟通的复杂度，而且双头指挥也给项目相关的各个厂商带来困扰。
（2）、流程类问题：
a）业务部门项目经理往往长于系统实现，但是对于工程建设流程非常陌生，分工不清晰导致其处理的项目流程经常存在不规范、不合规的地方，实际操作中出现过很多影响项目实施的情形，如：
随意安排到货、忽视设计会审、不理解交资流程而随意操作等问题
b）网络割接与业务割接本应分属不同职能部门管理，对应不同中心申请、操作、实施；但双项目经理的分工不明确导致相关管理思路、操作方式没有统一的界定。
c）交维对象一直没有制度性界定，带来很多问题和不必要的频繁沟通、确认。
按目前情况，情况很复杂，数据业务类涉及网运中心的向其维护部门交维；但数据部和信息部则都是向业务部门交维，而从流程及工程实施角度看，实际应该向维护部门交维。
交维对象的含混，在验收过程中会造成意见无法及时传递的情况，更有可能给后期维护带来问题。
（3）、项目管理类问题：
a）工程部门无法前期进入项目，从而对网络、业务设计思路、整体内容了解造成缺失，这对资金资产管理、交付工作，合同申购、交资完成、进度掌控、汇总等等工作带来了相当的困难。
b）业务需求变化较多、较快，网络建设、业务建设、业务维护等各个概念、内容混合交叉，经常对整个项目的完成产生影响，从而影响投资完成度、设备提供商的付款进度、项目进度等多项重要指标。
c）业务建设为项目主要内容，业务项目经理对业务进度、质量等具有实际管理权，但建设流程要求工建中心对上述内容负责，造成权责不清。
d）随着信息系统部组织整合，将项目管理的职能归口管理。
现有客服网络的建设模式也参照业务类项目进行，缺反而不符合项目自身网络层面任务占主导地位的特点，反而影响了项目的顺利进行。
如果以人来类比项目的话，虽然上述风险不致于立刻导致项目失败，但是会形成很多潜在的不确定因素，并很容易导致失败。
就像人处于亚健康状态，虽然并没有处于生病的状态，但是却也不是健康的状态，而且很容易转化为生病的状态。
所以，本文在此提出，以“项目健康度”作为评价项目实施的一个新的标准，这样形象化的精细的把握项目的发展情况，同时反映了现存的、潜在的多种问题。
“项目健康度”的评价细节将单独撰文描述，这里不再赘述。
上述只是现有流程中问题最为突出的部分现象，已经对项目的实施规范性、进度、资金指标的完成、风险管理等等项目管理的重要方面带来的显著的不利影响。
而这些给公司会带来很多潜在的不可控的风险。
3、上述问题给公司层面带来的风险剖析
（1）、影响到工程质量形成系统风险：
上述提及的设计方案的确认、布线工作、交维交接等都将直接影响工程的质量，从而增加系统上线投入使用后的风险。
07年BOSS系统就曾经因为设计方案问题造成了较大的系统故障。
（2）、对公司形象造成不利影响
双项目经理的双头指挥会给合作伙伴带来配合上的较大困扰，给信息交互造成障碍，影响公司的专业形象；工程建设、业务建设的概念模糊造成部分设备类合同无法及时付款，也给公司形象带来不利影响。
（3）、项目管理不规范给公司带来极大风险
双项目经理造成的项目管理规范性的缺失会形成很大风险。
08年公司出现的不签合同而办理借货这类不规范的操作已经实际形成了大量风险，业务类项目应该未雨绸缪，及早预防。
（4）、业务部门项目经理在项目建设流程中牵扯过多精力
作者曾和数据部的同事交流过，数据部的项目经理最希望自己把精力投入到系统端到端的交付中去，从而最终形成收入和利润。
项目建设流程的不明晰，部分制约了业务部门项目经理的精力，未能做到各展所长，协同操作。
尤其在3G牌照已经发放的今天，未来新业务更将成为企业可持续发展的关键，保证新业务的快速、健康、顺畅的交付，将是企业占领市场的重要一环。
综上，目前业务类项目建设流程的现状，即不明确的弹性的双项目经理管理制度具有极大的局限性，上述种种问题都是由于双项目经理分工不明确导致发生，不仅对项目实施过程中带来相当大的困扰，对整个公司的战略和管理带来潜在的较大的风险。
III.对业务类项目建设流程的建议
1、已有的业务类项目建设流程改进方案
计划建设部曾经针对新业务项目、支撑网类项目下发了弱矩阵项目管理体系，主要思想是为了加强业务推广，主要操作模式是成立项目组，竞聘任命项目经理负责实施，曾策划试点，但未能有明确的后续部署。
该体系符合PMP项目管理思路，加强了业务推广力度，设置有其合理性，但从其流程图看，主要建设过程仍然由工建中心负责，只是项目前后期由业务项目经理负责。
其弱矩阵构想的两个维度却是项目管理和行政管理，没有将业务项目管理和网络项目管理分离，故实际操作很可能形成一个三个甚至四个维度的矩阵。
如此，不但未能解决业务类项目管理现状中的问题，反而可能带来更多的交叉和干扰。
2、新的业务类项目建设流程改进建议
针对上述情况，结合已有的弱矩阵项目管理体系，根据现有的实际情况，在不增加管理角色和工作量的基础上，作者建议改进为双项目经理平衡式的二元项目管理模式，关键是要明确业务侧项目经理和网络侧项目经理的分工，以业务和网络分离为最合理的方式，形成一纲双线的二元项目管理模式。
以项目全流程为纲，统一开始，统一结束，双项目经理全程参与，分段一主一辅，最终业务建设对应业务维护，网络建设对应网络维护，完成项目全过程。
当前在我公司，很多部门业务建设与业务维护从人员上采取合二为一的形式，这不影响上述实施模式，故不赘述加以讨论。
1、业务建设部门实施内容
立项时，全面主导整理需求，定义业务流程、管理厂商给出实施方法，完成立项准备各项工作；
项目实施时，配合网络建设，辅助工程部门完成工程建设流程；
同时，主导业务开发进度、监控业务实现质量；
待业务上线后，进行项目业务交维，由业务维护人员接收进入维护周期（业务建设与业务维护可以合并）
具体业务建设过程可以由业务部门加以细化。
2、网络建设部门实施内容
立项时，当业务模型定义清楚后，综合业务建设部门、网络维护部门的意见，委托设计单位进行适当的网络设计。
项目实施时，主导硬件安装、网络开通进度、网络质量等建设工作，按时交付业务部门使用，配合监管业务开发；
网络交维时，向网络维护人员交维进入维护周期
待业务实施完毕，整体项目完成后，处理项目财务相关手续，完善项目档案等后期工作，直至项目结束。
此过程可以完全借鉴现有网络建设流程。
3、业务与网络建设的交汇点及改进流程图
（1）、前期双方共同完成立项建议书和技术建议书；
（2）、以网络建设完成后以加电、网络开通为时间点，以硬件安装验收规范和网络开通报告为生成文档交付业务部门部属业务；
（3）、业务建设以业务完全上线为时间点，软件测试报告为生成文档交付网络建设部门完成整个项目的交资、竣工、初验工作。
并分别交维。
以流程图图示见图1。
图1
此处需要说明的是，本文将关注点放在业务类项目的建设流程执行的改进上，现有职能部门的职责，如立项过程及全过程中计划建设部的组织职能，采购中物资供应部的组织职能，实施过程中网络部的审核职能等均比较完善，这里不再赘述。
4、与当前的建设流程相比的变化
1）在前期网络规划中，网络建设部门、维护部门参与设计、立项过程。
2）项目建设过程中，以业务与网络分工合作的方式，业务建设部门、网络建设部门各自负责相应的进度、质量等项目管理工作，并保持沟通。
3）以里程碑为责权切换时点，双方变换主辅角色，各司其职：
明确以加电、网络开通为时间点，硬件安装验收报告和网络开通报告为生产文档，网络建设部门向业务建设部门交付使用；项目最终验收时，业务建设部门以软件测试、系统上线为时间点，软件测试报告为产生文档，业务建设部门向网络建设部门确认项目具备初验、竣工条件，网络建设部门组织项目收尾过程，完成项目建设。
4）业务流程由业务部门委托集成商牵头结合项目需求，前期调研，综合需求部门、业务部门意见，设计实施方案，业务建设部门主导实施；网络方案由工程部门委托设计单位牵头，根据集成商的业务方案需求，综合业务部门、维护部门设计方案并实施，网络建设部门主导实施。
各方责任明晰，各展所长。
综上所述，对业务类项目建设流程改进建议并没有设立过多新步骤，多数只是将现有默认的过程明确定义，并进一步以业务和网络分离的原则清晰的划分职责，同时进一步加强沟通协调，是完全可行的。
5、此建设流程的优点和不足
如果可以按照此种模式梳理业务类项目建设流程，对于前述提及的问题都会有彻底的解决，有以下几个突出的优点：
（1）、网络建设与业务建设完全分开，由建设相关的部门分别主导，既符合业务类项目的特点和实际实施情况，也符合当前公司各中心组织结构的分工，尤其是绝大多数维护部门设置的原则与模式，更符合建设模式与维护模式的一致性。
（2）、双项目经理全程参与后，都对项目的全部过程了解清晰，有利于后续工作的展开和完善，尤其是有利于申购、交资、交维等等后续对于公司指标有重大影响工作；
（3）、分工明确后，对于项目实际进展的责任落实，配合实施，工作分配，项目进展情况汇总、下达的流程都会有明确的权责界定。
我公司此类项目管理质量将有质的提高；
（4）、人员的培训、职业发展将形成更为明确的思路，对于双方部门人力资源发展都有很大的益处；
（5）、业务类项目的网络建设和业务建设剥离后，其各系统的网络维护纳入正规的交维流程后，可以完全、完整的按照已经十分成熟的交换网络的各种制度实施，真正实现公司的各种网络在维护制度层面的统一，将极大的方便网络管理、考核、提升等。
这里还需要提及的一点就是：
当前集团公司业务支撑网、信息化网络建设虽然尚未明确成文，但也已经采取类似模式进行操作。
此操作模式的不足，主要还是与目前流程存在不同。
首先从项目分类上，定义就不一致，从而造成在统计、管理等很多方面，对于职能部门的统计汇总，以及项目管理模式带来的变化形成一定的影响。
但从长远看，有利于责权的明晰，项目实施的精细化管理。
IV.本文的若干创新点
本文在描述业务类项目现存问题并提出解决方案的同时，提出了几个新的想法，这里以创新点的方式统一将之概括在一起。
1、提出二元项目管理模式
基于国际通用PMP项目管理办法中的矩阵管理模式，结合北京公司的实际，本文针对业务类项目提出：
变弱矩阵项目管理模式为二元项目管理模式。
本着业务与网络分离的原则，既有利于双方项目经理各展所长，又有利于两者的有机连接，为公司业务类项目的管理提出了新的概念。
2、提出项目健康度作为评价项目的新标准
项目健康度作为评价项目的新标准，避免了简单化的是否的两极化评价模式，从项目实施的多个维度考察，尤其针对当前公司现状，加大了对潜在风险的描述和评估，更为科学、合理。
3、提出业务类系统的网络维护与现有网络维护制度的统一
当前业务支撑网、新业务系统与交换网络、数据网络、网管网等虽同属于网络部管理，但基于其特点不同，所属部门不同，管理制度也不尽相同，这其中很大一部门是出于对业务系统掺杂其中的考虑。
将业务建设与网络建设剥离后，网络建设完全采用和现有网络同样的建设流程，则为其和现有网络的维护制度的统一创造了先决条件。
虽然业务网络和以交换网络为代表的大网在系统维护层面仍然有这样那样的不同，但是其维护制度是完全有可能统一，且这个统一必将为公司网络管理效率的提高、成本的降低起到非常重要的积极作用。
V.总结
本文从业务类项目的定义谈起，先描述了当前业务类项目的现状，总结归纳了流程中的若干问题，分析了其可能给公司带来的风险，然后籍由业务与网络分离的思想，对建设流程的改进提出了若干建议，并于最后对于创新点给予了概括总结。
以上只是本人从基层工作中看到的东西，肯定有很多片面、不足的地方，只是希望能给企业的发展贡献自己最大的力量，用自己整理的信息及思考为领导的决策和企业的发展做基础，同时也可以磨练、提高自己的能力，真正实现个人随企业共同实现的企业文化！
最后要感谢各位专家、领导对这篇文章的关注，并请不吝给予指正，谢谢！
升级会员 