小贾是研发PLM（产品生命周期管理系统）项目的实施经理，最近正面临项目实施以来最大的困难：项目进度已明显落后于计划，按照当初确定的需求开发出来的模块却因不符合实际业务情况而不得不一遍遍地返工，当初并没有进入开发序列的需求正源源不断地涌现出来，项目边界再次变得不清晰，阶段验收无限期后延，更要命的是业务部门还撤走了之前协商好的资源……小贾觉得仿佛陷入了泥潭，项目似乎已经失控了，他不明白为什么项目会进展到如此境地，为什么业务部门会如此不重视、甚至不接受这个看似很有价值的IT 系统，对于如何解决这些问题，他束手无策。

其实小贾遇到的问题是IT 项目实施过程中最典型的问题之一：IT部门与业务部门之间发生冲突导致项目执行困难。要解决好这个问题，首先需要了解冲突从何而来。造成冲突的原因可能有很多，这里谈两个主因。

（1）战时一个小分队和另一个小分队不能好好合作打仗的最可能的原因是什么？是目标不一致。正所谓“道不同不相为谋”，如果IT部门的业绩目标是完成某某系统上线，而业务部门是完成某某新产品研发（以研发部门为例），那么业务部门不情愿支持IT 部门是很正常的行为，即使是自上而下的行政指令也未必可以确保获得业务部门真正的支持，因此导致冲突的深层次问题首先是“利益分歧”。

（2）冲突还有可能来源于“沟通障碍”，如果在目标一致的情况下，两个分队仍不能好好合作去打仗的根本原因则可能是：合作双方不能就目标、计划、标准、指标、资源配置，以及实现目标的行为和方式进行充分的沟通，彼此又不能很好地取长补短，或者互换角度理解问题和挑战，那么最后激发矛盾造成冲突是必然的。

冲突一旦发生，无论其源于利益分歧还是沟通障碍，都必须尽快解决，以免拖延下来造成整个项目的延误甚至失败。因此IT 项目经理或者CIO 需要及时识别冲突，充分挖掘其背后的原因，想办法把冲突转化为解决问题的突破口，弱化甚至终结冲突，最终实现双赢。解决冲突最有效的手段是：想方设法成为业务部门的合作伙伴（partner）。其核心理念就是：真正了解业务部门（职责范围、KPI、目前业务现状、业务改善需求），了解你能为客户提供什么，最后是切实可行地帮助客户，令他们觉得你与其共处一条船，风险同担、利益共享。

具体可以参照以下三步法进行。

Step1：识别冲突当IT 部门发现项目整体推动变得缓慢下来，业务部门表面上表示积极支持项目，但实际上各项任务的及时关闭率和完成质量都在下降，不再或非常困难从业务部门及时获取所需资源和响应，业务部门不再关注项目进度及指标完成情况，不情愿派人参加例会，或者每次参会都指派不同的人前来参加，会后很难或者根本无法从参会人员那里获得应有的反馈和支持，那么造成这种冲突的幕后推手很可能就是IT 部门和业务部门之间存在的“利益分歧”。 而沟通障碍引起的冲突主要表现在：

双方的工作目标一致没有分歧，甚至头顶共同的KPI 指标，但项目实际上却推进缓慢，出现这样那样的问题及抱怨，如双方都认为自己应该是项目的引领者，各自强调各自的意志，不能形成优势互补、能力互补和良好的配合，最终导致单方面意志左右了业务需求，结果与业务部门的预期造成了较大偏差；双方抱怨对方参与度不够，主动性不足，双方缺乏高效沟通机制，导致问题和风险没有得到有效追踪和关闭，等等。

Step2：制定解决方案定位了冲突来源，接下来便着手制订解决方案。此时，小贾可以做一次专门针对业务部门的问卷调查，为了确保较高的问卷回收率，可以适当采取有偿方式来激励相关部门更好地参与，这一招往往屡试不爽。充分了解业务人员的所思所想对制订下一步的对策非常有帮助，问卷内容包括但不限于如下。

您对 XX 系统（目前正在调研 / 实施 / 试运行）了解吗？
它的功能是什么？
您认为 XX 系统能够解决什么业务问题？
实际情况和您的理解相符吗？
您认为 XX 系统将在多大程度上或哪方面帮助到您？
或者您的期望是什么？
如果 XX 系统将改变您的工作方式，您认为这些变化是否超出了承受范围？
您认为 XX 系统带来了哪些变化是您不可接受的？
您认为 XX 系统提高了您的工作效率？
或者提高了经济效率？
操作更方便吗？
您认为 XX 系统还需要在哪些方面进行完善？
您认为公司真正需要 XX系统吗？
您个人期盼它上线吗？

上述问题的统计结果可以清晰勾勒出业务部门对XX 系统的认识程度，以及有效帮助IT 部门了解自己心目中的系统与业务部门之间的理解是否存在较大差异，差异往往是产生歧义的根源。如果差异较大，则说明IT 部门在前期阶段，即在调研、交流、需求分析上不够充分，整个系统的设计有硬伤，需要实施针对性的补救措施。如能及时发现差异并刹车，则能够很大程度上挽回损失，避免进一步的失败。业务部门是用户，只有用户说好才是真的好。如果上述问题的结果显示差异不大，那么IT 部门需要进一步了解及考虑：

业务部门年度 KPI 指标是什么？
是否与 IT 部门存在共有指标，如果没有，则想办法找出间接关联的指标。当前业务部门的业绩如何？
如果业绩好，那么 XX 系统如何才能加速业务部门的成长；如果业绩不好，那么XX 系统如何才能帮助业务部门渡过难关？
当前业务部门面临哪些问题和挑战（人、财、物），IT 部门以及XX 系统能帮助他们做什么？
如何改善他们的工作，解决他们的问题？

获得上述问题答案的核心目的是：通过充分理解业务部门的状况，从如何帮助对方的角度，找到双方的利益共同点，敲开业务部门紧闭的大门，令其愿意与IT 部门合作。一旦业务部门了解到XX 系统将带给他们的不仅仅是新的工作方式，同时还有传统或旧模式无法给予的收益，那么他们不再仅仅认为XX 系统成功上线只是IT 部门的荣耀，也将是他们业务部门振兴的新起点，那么欣然接受XX 系统、配置资源、提升优先等级，都将顺理成章。反之，如果业务部门认识不到与IT 部门的利益共同点，新系统上线只是意味着工作方式改变，传统习惯被打破，任务执行过程突然间被透明化监控，一下子来了很多工作量但收入没有提升，绩效评价趋于透明和严格，工作效率短时期内不升反降，经济效益暂时显现不出，种种不适应扑面而来，培训和推广又没有及时跟上，IT 部门怎么看都像是站在对面虎视眈眈的监工……当面临这些情形时，业务部门无论如何都是很难接受新系统的，而不配合，甚至私下里拆台、打小报告都是有可能的。合作的前提是妥协，在不放弃原则的情况下，以妥协换取合作，以空间换时间，不失为明智有效的选择。要想让业务部门和你坐一条船，那么你就需要明白地告诉他们：“兄弟！咱们是风险共担、利益共享的合作伙伴。

”Step3：实施及跟踪有了解决问题的思路和方案后，IT 部门需要和业务部门进行彻彻底底的沟通。沟通的基础是尊重，IT 部门必须尊重业务部门的现状及其对业务的理解，千万不要觉得自己懂行业最佳解决方案，懂如何运用新技术，就可以抛开业务部门引领所谓的变革了，业务部门的核心价值在于他们懂业务里真正的问题是什么，懂得为什么会是这样而不是那样。简而言之，他们懂企业的历史，如果没有业务部门的参与和支持，是不可能做好一个真正有用的IT 系统的，不接地气的系统最终必然会被业务部门所抛弃。IT 部门需要通过沟通让业务部门了解到系统的价值所在，以及即将给他们带来的利益，这个过程可能需要反复多轮进行，在此期间，IT 团队需要更多的耐心和信心。 沟通的办法有很多：例会、简报、问题及风险CheckList、面谈、阶段报告及评审、WorkOut，等等。

重大决策会议的会前沟通非常重要，会议之前最好通过各种沟通方式获得多数关键人员的支持，这样当正式会议表决时，一些本就摇摆不定的人员会因为关键人物的表态而转向支持。另外，部门之间的WorkOut 或者Team Building 也是很好的沟通及联络手段，还有一定要充分发挥例会的作用，令其定期追踪问题和风险，让事情可控可追溯。此外，取得阶段性成果不要忘了宣传业务部门的贡献，以及适当地为业务部门申请奖励，这样能够很好地激励业务部门。最重要的是，当业务部门遇到困难时，别忘了从IT 的角度呼吁公司上层予以重视和解决。如果这些IT 部门都做到了，那么还有什么样的冲突是不可化解和终结的呢？

最后，IT 部门一定要抛弃一个想法：“这是我的项目”，而应该说：“这是我们的项目，一荣俱荣，一损俱损， 让我们和业务部门共同成长吧！”

作者介绍：

屈晓娟，原国电联合动力技术有限公司技术管理部副经理，工学硕士，高级工程师，北京大学CIO 信息总监班学员；多年来一直服务于能源行业，曾经就职于北京四方继保自动化有限公司、GE 中国研发中心以及丹麦维斯塔斯风能系统公司，从事产品研发、技术支持及研发管理工作；先后主导或参与了多个电力系统控制及信息化管理系统的开发、实施以及产品运营等工作，与此同时，参与了多个国家级、省部级、国电集团等风能类项目的研究开发工作；目前着力于企业产品研发管理体系的信息化升级的研究及实施。！