2002年初该系统中心服务器发生重大故障，由于系统采用了集中处理的体系结构，全部网点均陷于瘫痪。
监理公司立即督促工程总指挥部启动了紧急故障处理程序，成立了由各开发商参加的紧急故障处理小组，并由其对故障及时进行排查，分析和处理。但由于事故责任重大，各开发商为保护自己，在现场发生了激烈争执，故障处理小组工作陷于停滞。
由于该系统关系着百姓利益，每拖延一天都会给政府和社会造成巨大的损害。为此，监理公司在征得工程总指挥部的同意后，出面保留了事故现场的数据，中止了纷争，并督促、协调各开发商及时将系统恢复。
系统运行正常后，监理方认为隐患尚未排除，系统仍然可能随时出事，一方面督促工程总指挥部加大对系统的监控力度与快速反应能力、提前开始防灾中心与备用系统的建设，一方面先后多次召集各开发商与设备供应商HP、Oracle对故障原因进行分析、排查，最终几个月后Oracle公司公布了其OPS系统的一个Bug与相应的Patch，问题得以最终排除。
几个月后，系统再次出现故障，两个业务量最大的分中心业务长达一周无法正常运行。开发方坚持认为不是软件失误产生的问题，而是业务人员的操作问题，具体原因可能包括操作员对电脑的使用水平较低、对政策实施办法的理解不到位、操作前的培训不够、时间紧工作量大情况下而出现疏漏等。并同时声称使系统恢复正常难度较大，需要花费大量人力物力。
监理方立即从公司总部借调了技术专家进行实地调研，结果发现，每季度末系统均有一次大规模的汇总工作，但该模块一直不稳定，前几次均是有开发方人员现场支持下完成，这次故障正是由于开发方停止了技术支持服务以至于业务人员操作失误所造成。最终，在经过用户方领导、监理方的积极协调后，开发方技术人员只花了1个小时即将故障排除。
该事件发生的背景原因是：开发方为进入此工程，在一期投标中不惜亏本压低价格并最终获得开发与维护两个合同，但由于有消息传言此项目二期将改换为其他公司，故此开发方用此下策以要挟用户。
尽管项目失控的原因多种多样,但可以明确的是，用户本身需要在项目中肩负判断取舍的责任，不论是在事前的项目规划和咨询，还是在项目实施之中的细节。但这往往是用户方之力所不能及。
在本案例中，主要由政府官员组成的工程总指挥部显然并不能完全承担这一任务，尤其当多家开发方为逃避责任就技术细节各执一词、互不相让时。同时因为涉及到很多复杂的项目背景情况与大量的业务知识，项目外部的计算机专家一时之间也无法发挥作用。
此时，监理方由于具备丰富的工程管理经验、相当的技术能力，加之熟悉项目的背景情况与业务流程，从而发挥了关键性的作用。
此文章共有5页 上一页 1 2 3 4 5 下一页
文章来源：中国项目管理资源网
 IT服务及集成项目管理培训课程方案
|
Leadge.com首页 > 知识库 
