本文中认为，一种共同参与的模式很重要；我们还探讨了一些切合实际的想法，IT部门可以运用这些想法，改善与业务部门之间的关系，并且介绍了适用于服务生命周期不同阶段（从战略、实施到交付）的不同策略。

　　IT部门是为了支持业务部门而存在的。对此，业务主管和IT主管都很明白，因而继续投入于IT组织和基础架构。然而，随着你开始往组织结构图的下面移动，将IT视作战略性资产的这种观点随之发生变化。

　　对业务部门的大多数用户来说，IT常常是绊脚石，而不是助推器。IT部门经常被视作对创新想法说“不”的部门，是承诺过多、兑现过少的部门。这种批评大体上有失公允，根源于对技术实施和日常管理的复杂性缺乏深入了解。不过，这种批评也有其一定的道理。在每一家企业，项目拖延、没有获得预期的效益、技术根本满足不了用户的需求，这样的例子数不胜数。

　　如果IT部门要改善与业务部门之间的关系，那么它在业务部门眼里必须是值得信赖的技术合作伙伴。IT主管必须努力解决这些问题，为此需要在IT部门与业务部门之间建立一种稳定、直观的共同参与模式，并且明确定义角色和职责、明确约定战略和范围以及严格遵守优先事项和时间表。我们在本文的其余部分将其中一些策略运用于标准的服务生命周期。

　　战略：深入了解业务战略，确保IT部门全力支持业务战略。

　　根据我们的经验，在大多数企业，IT部门很清楚业务战略的大致细节。然而，IT部门对于业务部门对IT部门的预期要求：支持业务战略的顺利执行却常常缺乏深入的了解和认识。之所以会出现这种情况，是由于业务部门在制定战略的过程中很少让IT部门参与进来。相反，业务部门制定一项战略后，然后就撒手不管，扔给IT部门去“实施”。IT部门开始实施解决方案时，并不是非常清楚为什么要实施这项战略，因而缺乏正确的认识。这恰恰破坏了要求IT部门支持的业务战略。

　　学习要点：制定战略过程中的参与对象必须包括业务部门和IT部门的所有相关人员。

　　设计：在设计决策过程中让业务部门参与进来。

　　这一点说起来比做起来要容易得多，因为大多数业务部门的用户认为设计是一项技术活，自己基本上帮不上什么忙。不过根据我们的经验，导致IT项目失败的最大一个根源恰恰是设计决策存在缺陷。

　　让业务部门参与设计过程的一个办法就是，讨论时摈弃技术术语，从业务的角度来谈论设计决策。这不仅可以确保业务部门的相关人员能够积极参与讨论、献计献策，还可以帮助IT部门更深入地了解自己支持的业务部门。

　　让IT部门和业务部门说同一种语言，这有助于弥合横在业务部门与IT部门之间的那条历史鸿沟，而且对于改变企业针对IT的观念大有帮助。业务部门的用户往往有非常明确的想法，清楚自己想要什么样的解决方案和服务，却不是很明白其中的技术复杂性或实现其要求的成本。这就导致在无数情况下，“被高昂的成本吓一跳”，以及经常推脱“我们的IT部门太会烧钱了，要是请外面的承包商只需要一半成本”，或者是“解决方案供应商说，该解决方案的成本只需要IT部门所说的一半就够了。”

　　在这两种情况下，最常见的原因是对于解决方案的总体拥有成本缺乏了解。如果IT部门在设计决策过程中让业务部门积极参与进来，就能帮助对方更好地了解技术复杂性以及与任何解决方案或服务有关的总体拥有成本。针对项目采取关卡式方法有助于确保合适的信息在合适的时间得到准备和审查。这可以避免常见的“扔给对方”做法：这种情形下，运营团队只好收拾残局，以便提供可持续的服务。

　　IT部门在描述解决方案时既要尽量避免使用复杂的术语，还要用业务措辞和度量标准来描述价值，比如工资单服务的最终结果是收款人数量/开出的薪金支票，而不是99.99％的服务器可用性。相比之下，业务部门要明白一点：IT部门既要考虑所需的功效或功能，还要考虑解决方案在可用性、容量、连续性和安全性等方面的要求；而这些要求会提高总体拥有成本。

　　学习要点：在设计决策阶段投入一些时间和精力会带来回报：可以减少代价高昂的错误，这些错误可能只有在开发和测试解决方案后才可能被发现。

　　过渡：在新的解决方案“投入使用”之前，IT部门一定要对会受到最大影响的用户进行培训。

　　在任何解决方案向实际投入使用过渡的期间，来自业务部门的最大抱怨之一是，IT部门的认识和计划有缺陷，因而导致过渡不是非常平稳、顺畅。对于业务部门的大多数最终用户来说，过渡阶段的测试部分是他们第一次就新实施的系统（无论实施的系统是产品、平台还是服务）与IT部门进行接触；过渡阶段的任何问题只会留下负面印象，这种印象会在之后很长的一段时间挥之不去。

　　如果IT部门在详细的过渡规划阶段中让业务部门的相关人员参与进来，就能解决过渡阶段的潜在问题。IT部门必须确保计划切合现实，并考虑到业务部门关注的问题，旨在使小幅改动直到大型部署的整套方法都实现标准化，从而确保进行了相应的尽职调查。

　　在整个过渡期间，IT部门和业务部门需要协同工作，为此既要提供最初试运行时期的支持，又要为最终用户提供培训。谨慎的风险管理方法在这种情况下也非常有用，那样万一风险转变成问题，就有可以迅速启动的计划来缓解风险。

　　学习要点：针对变更进行规划、确定优先级以及测试需要业务部门和IT部门付出极大努力和积极参与。

　　运营：一旦解决方案和服务投入使用，业务部门面临的一个常见问题就是服务级别不一致。

　　IT部门可以通过这个方法来缓解该问题：采取一种共同参与的模式，这种模式要基于服务级别协议（SLA）。IT部门需要与业务主管密切合作，了解服务的相对优先级别，并且制定体现业务优先事项的服务级别协议。

　　一旦与业务部门一起定义和约定了服务级别，就要密切跟踪遵守这些服务级别的情况，并制定一项非常显眼的计划，解决任何不足之处。业务部门通常低估维护工作的重要性，但是这项工作在IT运营团队的工作量中常常占有很大的比重。IT部门清楚地表明这些工作在有助于确保可持续服务级别方面带来的价值，这点很重要。

　　学习要点：正式的共同参与模式可以在设计阶段确定这些服务级别要求，那样在解决方案创造价值之前，就能清楚地了解这些要求，以便运营团队可以致力于管理服务。当然，共同参与模式还需要IT部门和业务部门定期审查服务。

　　治理：要取得成功，拥有一套有效的治理框架以涵盖企业内部所有相关层面的决策机制，绝对至关重要。

　　根据我们的经验，要是业务部门和IT部门任由自己为争夺预算和资源而“内讧”，治理模式就会变得毫无效果。在这种情况下，业务部门的代表只是借助IT治理论坛，竭力争取更多的资源和预算，以支持自己的优先项目，而IT对于其宝贵资源如何分配失去了控制。

　　可能会出现这种情况：IT部门不得不开展一个项目——比如堵住安全漏洞，他们肯定能够借助治理论坛来讨论这个优先项目。为了避免这种结局，IT部门必须让企业领导层参与正式的治理结构，并且定义明确的共同参与规则以及确定请求优先级和分配预算的机制。这有助于确保业务部门的代表对整个企业有一个全面的认识，而不是只对自己的地盘有一个狭隘的认识。

　　IT部门还必须运用其对业务战略和市场上技术创新的知识，帮助为企业内部的技术确定时间表。这并不意味着纯粹为了技术而追求技术，也不意味着预算浪费在了没完没了地追求下一个新技术上。相反，IT主管能够以一种务实的眼光，弄清楚如何充分利用最有效的技术来满足战略要求，并将这些方案展示给高层领导。

　　学习要点：IT部门通过定义明确的共同参与规则，帮助业务部门制定有助于满足战略要求的技术时间表，就能帮助建立一种有效的治理机制，以便统一管理企业的技术决策。

　　总之，改变企业针对IT的观念是可以做到的，但是这需要业务部门和IT部门两方面的共同努力。两者都需要改变。只要在服务生命周期的整个过程（从战略、设计、过渡直到运营）中作出我们建议的改变，那么IT部门在有效治理的支持下，就为业务部门充当高效的合作伙伴，并且帮助改变企业原有的观念。