案例讨论：业务部门与 IT 部门关系影响项目成败

Tomac

現實中一些項目的運作方式，資源擁有者授權部分的權力給項目經理，而項目推動者必須明白，項目成功或者失敗取決于資源擁有者，資源的授予是動態而變化的。對于企業中的情況而言，項目的成功或者失敗，并非所有成員的唯一目的。通過一些項目的結果，達成一個企業各流程環節人員的平衡，在有時候也是一個結果。

我們無法脫離企業管理的大環境來純粹討論項目管理。

susan_huangyong

原帖由 张恂 于 2009-9-2 10:04 发表

我的建议是：

尽量说服你们的 CIO (VP) 尽快成立一个负责企业业务流程全局规划的部门（或协调小组、委员会等），人员可以来自现有的业务经理、IT 经理。招募、培养这样的人：

“对整个业务都精通的人，他可以迅速找出当前状况下最需要改进的点，也能够规划出借助IT系统来改进管理。”

以后 IT/软件项目的需求都应该来自该规划部门，这样可以避免很多需求管理上的问题。

这方面我可无能为力，而且，这个部门的成立也不是一两天能够完成的。
从我这方面来说，有什么可以建议的？难道真要成为一个多面手，什么角色都承担吗？这样能保证项目的三要素吗？

susan_huangyong

原帖由 张恂 于 2009-9-2 10:47 发表

“公司副总（分管IT）：应该是IT主导业务，帮助业务部门重组不成熟的业务流程，有效控制变更。”

感觉你们的 VP 还是很有想法的，但“IT 主导业务”的提法有点超前，业务部门的领导（VPs）听了可能就不干了，他们还想业务主导 IT 呢。最好是 Business-IT Alignment，不要谁主导谁，否则容易引起利益之争。

个人认为，IT和业务部门的能力是一个此消彼长的态热。
业务的能力强，就可以主导IT建立系统，充当BA角色，业务能力强，系统就可以做为业务部门强有力的支持，真正提升管理水平。
业务能力弱，IT就必须站出来，或是寻找行业知名的咨询，或是提出方案引导业务部门规划流程，从而主导业务来进行系统实施，进而促进业务流程的优化。

susan_huangyong

原帖由 Tomac 于 2009-9-2 16:44 发表
這樣的項目組織程現實中具有普遍性。 建議CIO (VP) 尽快成立一个负责企业业务流程全局规划的部门，對于當事人而言，似乎勉為其難。能否成行也是看CIO所處的權力環境而定。一個必須的條件是需要獲得最高領導者CEO的支持。

同意

susan_huangyong

原帖由 Tomac 于 2009-9-2 16:51 发表


我們無法脫離企業管理的大環境來純粹討論項目管理。

确实有些无奈，一方面我们希望项目成功给企业的管理带来提升，另一方面感觉心有余而力不足，项目总不令人满意，深感内疚

原帖由 Tomac 于 2009-9-2 16:51 发表
現實中一些項目的運作方式，資源擁有者授權部分的權力給項目經理，而項目推動者必須明白，項目成功或者失敗取決于資源擁有者，資源的授予是動態而變化的。對于企業中的情況而言，項目的成功或者失敗，并非所有成員的唯一目的。通過一些項目的結果，達成一個企業各流程環節人員的平衡，在有時候也是一個結果。

通过项目的结果，能让高层管理人员深入思考原因，也算并非全无用处了，只不过，这个代价有点大。

Tomac

原帖由 susan_huangyong 于 2009-9-2 22:28 发表


确实有些无奈，一方面我们希望项目成功给企业的管理带来提升，另一方面感觉心有余而力不足，项目总不令人满意，深感内疚




通过项目的结果，能让高层管理人员深入思考原因，也算并非全无用处了，只不过，这个代价有点大。

反過來想，項目的結果，是高層管理人員，讓其他人員思考自己定位和水準的一個方式。至于代價的多少，相對而言。

张恂

原帖由 susan_huangyong 于 2009-9-2 22:16 发表

4、项目联系人：IT部门拿到批准的立项报告，指定一名IT项目管理人员着手准备（看清楚了，只有一名），我们称为IT项目负责人。我就是这个角色。承担部分BA任务，承担QA角色，承担配置管理任务，承担QC任务，碰到项目实施能力弱的乙方团队，还要承担部分SA的任务。自问没这个能力。

从我这方面来说，有什么可以建议的？难道真要成为一个多面手，什么角色都承担吗？这样能保证项目的三要素吗？

通常情况下，一个IT 经理/项目负责人承担这么多的角色，显然是不合理的。你是否分析过造成这个现象的原因？

领导指定？

缺人/人手不够？那可能一时难以缓解。

...

对于个人来说，成为多面手，未必是件坏事。

另外，你们 IT 部门的项目管理流程也有改进的必要。

[ 本帖最后由 张恂 于 2009-9-3 21:38 编辑 ]

张恂

原帖由 susan_huangyong 于 2009-9-2 22:28 发表

确实有些无奈，一方面我们希望项目成功给企业的管理带来提升，另一方面感觉心有余而力不足，项目总不令人满意，深感内疚

你们是否仔细分析过造成“项目总不令人满意”的原因？最好列举一下。

从你提供的信息看，我觉得至少有一个主要原因是：

业务-IT 的关系有点僵。

susan_huangyong

原帖由 张恂 于 2009-9-3 21:43 发表



你们是否仔细分析过造成“项目总不令人满意”的原因？最好列举一下。

从你提供的信息看，我觉得至少有一个主要原因是：

业务-IT 的关系有点僵。

我试着列举一下，还真没有总结过：

1、系统设计不够灵活。用户提出的变更可能涉及伤筋动骨的变化
2、系统质量有待提高。正式上线了还会出现一些低级的缺陷，明明是测过多遍的，为什么还有问题？感觉是配置管理做得不到位。甲方有权要求参与乙方的配置管理吗？感觉乙方控制不力，但对我们又是黑盒操作，不便于管理。要求乙方拿出测试用例吧，也拿不出像样的东西，很难真正全面的测试系统。
3、花很大精力为用户做出来一些变更，用户却不使用，当初可是强烈要求要做变更的，甚至提升到影响业务的高度。功能也不存在操作性不强，或者有任何问题，可用户就是使用率不高，很郁闷
4、系统部分功能的使用率低。和业务部门的关系确实不够好，但是变更是涉及到费用的，如果用户所有要求都满足，谁来实施变更啊？其实用户也很容易沟通的，有时候讲讲道理，将变更放至下期，用户还是能够欣然接受的，而有些变更我们认为有必要的，可能不待用户提出，都会主动要求。因此，也不能说完全的对立关系。
5、部门领导的支持力度不够。总是权力下放，没有真正把系统提升到一个高度，没有意识到系统是可以促进一些业务流程的优化的，是可以完善一些制度的，是可以帮助分析数据的。领导的态度也会影响到下属员工的态度。这也可能是我们没有和部门领导建立良好的沟通渠道的问题，总一厢情愿的认为领导们没有时间去推进系统。这也是今后改进的一个方向。


唉，越说心里越难受，还是一个合格的PM吗

张恂

原帖由 susan_huangyong 于 2009-9-5 11:09 发表

我试着列举一下，还真没有总结过：

1、系统设计不够灵活。用户提出的变更可能涉及伤筋动骨的变化

2、系统质量有待提高。正式上线了还会出现一些低级的缺陷，明明是测过多遍的，为什么还有问题？感觉是配置管理做得不到位。甲方有权要求参与乙方的配置管理吗？感觉乙方控制不力，但对我们又是黑盒操作，不便于管理。要求乙方拿出测试用例吧，也拿不出像样的东西，很难真正全面的测试系统。

3、花很大精力为用户做出来一些变更，用户却不使用，当初可是强烈要求要做变更的，甚至提升到影响业务的高度。功能也不存在操作性不强，或者有任何问题，可用户就是使用率不高，很郁闷

4、系统部分功能的使用率低。和业务部门的关系确实不够好，但是变更是涉及到费用的，如果用户所有要求都满足，谁来实施变更啊？其实用户也很容易沟通的，有时候讲讲道理，将变更放至下期，用户还是能够欣然接受的，而有些变更我们认为有必要的，可能不待用户提出，都会主动要求。因此，也不能说完全的对立关系。

5、部门领导的支持力度不够。总是权力下放，没有真正把系统提升到一个高度，没有意识到系统是可以促进一些业务流程的优化的，是可以完善一些制度的，是可以帮助分析数据的。领导的态度也会影响到下属员工的态度。这也可能是我们没有和部门领导建立良好的沟通渠道的问题，总一厢情愿的认为领导们没有时间去推进系统。这也是今后改进的一个方向。

唉，越说心里越难受，还是一个合格的PM吗

Susan，你总结得很好！不用跟自己过不去，每个人都有自己的弱点和盲点。我看出来，你各方面能力都很强，思维敏捷，观察细致

你提出的这些问题在国内具有一定的普遍性，很多 PM 也处理不好。而你已经明确意识到这些问题，已经成功一半了。

我建议多从 process 方面找原因，这些问题仅仅从个人能力的角度很难真正解决，它涉及到组织的管理文化和制度，大家一起做事的方式。

从你总结的这 5 个问题看，先不提业务部门的业务流程改进，我觉得你们公司 IT 部门的开发和管理流程改进就有很大的空间。

[ 本帖最后由 张恂 于 2009-9-8 17:12 编辑 ]