多数呼叫中心项目之所以会失败，问题往往出在人员和企业文化方面，而不是出在技术方面。呼叫中心项目失败的根源出在哪里？根本原因是在人员自身!但为什么人们会一再地在呼叫中心方面犯错呢？背后的原因很值得分析。

    失败一：业务价值不清

    IT人员最常犯的一个错误就是，纯粹从技术的角度来对待呼叫中心。他们把过多的时间花在了架构、治理和厂商评估上。尽管这些方面是很重要，但他们忽视了一个问题，那就是“呼叫中心需要解决实实在在的业务问题”。他们把大量的时间和资金用在了扩建架构上，结果却发现一旦完成了工作，却没有一个业务人员明白呼叫中心能实现什么样的效益，长此下去他们也就慢慢地对这项技术失去了兴趣。

    建议：按照第五代呼叫中心的SOA规范策略性的构建呼叫中心，首先要着眼于实实在在的业务问题。先要向业务部门证明呼叫中心会解决哪些业务问题，然后再着手处理技术问题。这也就是为什么说业务流程管理（BPM）是SOA的“杀手级应用”，BPM可以解决很多业务问题。因为它能改善业务流程，并使之实现自动化；它提供了可见性，可以掌握运营业绩；增强敏捷性，让业务部门可以动态改变流程，而不需要IT部门的干预；减少了浪费，从而降低成本。

    失败二：随意组织变革

    与任何一项转型计划一样，抵制变革会导致项目失败。呼叫中心会给企业的组织带来重大变化，如果企业没有落实精心制订的组织架构，失败那就更加不可避免。 人们担心未知因素是抵制变革的最主要原因，人们需要明白自己能从中得到什么样的好处，并且明白为什么改变工作方式对自己和公司都有利。然而事实上，难就难在组织内部各个级别的人员往往会受到不同的影响，每个级别的业务人员都担心各自的问题，逐个解决比较麻烦。

    建议：制订组织变革管理（OCM）计划，从外部聘请OCM专家帮助呼叫中心项目的领导团队应对变革。例如哈佛大学商学院的John Kotter教授所提出的一套方法，就包括了成功变革的八个步骤。

    失败三：没有关键领导支持

    要是没有呼叫中心项目执行发起人的强有力支持，呼叫中心项目实现目标的可能性就微乎其微。呼叫中心涉及多个部门、多个系统，属于重大项目。因此需要强有力的执行发起人，而且他要有一定的影响力，能让项目顺利开展下去，并且消除一路上可能出现的障碍。但光有影响力还不够。这个人还要有足够时间致力于呼叫中心项目，以便大家始终保持一种高度的紧迫感。

    建议：如果呼叫中心项目牵涉几个关键的业务驱动因素，执行发起人应当是能够从项目实施中受益匪浅的高层业务主管，让他来掌管及推行驱动呼叫中心路线图的一系列项目。在技术公司中，充当执行发起人的极有可能是CEO、CIO、CTO或者首席架构师。无论选择了谁，这个人必须能力排众议，还应当在领导能力方面有着骄人记录。

    失败四：贪便宜

    呼叫中心不是只是买来的“产品”，而是要去实施的。有些公司明明预算有限，还试图上马呼叫中心项目。因为除了需要的第五代呼叫中心中间件外，治理工具、人员培训、基础设施和安全工作等方面也需要巨额投资。 由于第五代呼叫中心具有分布、松散耦合的性质，所以管理生产环境下的呼叫中心具有很大难度。不要在生命周期管理工具方面敷衍了事，不然故障排除起来就好比大海捞针，毫无目标可言。有些公司试图在没有任何外界帮助的情况下开展呼叫中心项目，以便省下聘请顾问的高昂费用。除非这家公司不乏呼叫中心方面经验丰富的员工，否则为了省钱而在没有外界帮助的情况下试图开展呼叫中心项目，只会招致灾难性的结果。

    建议：制订一份第五代呼叫中心部署路线图，列出一系列项目以及呼叫中心会给公司带来的长远效益。从经济层面证明实施整个呼叫中心项目的必要性，并且让管理班子看到投资回报、净现值、内部收益率或者对公司来说最重要的其他任何财务指标。如果拿出的方案有足够充分的理由，应当能获得足够资金来保障这个项目。另外，还可以使用几款优秀的开源产品，能够大大减少实施呼叫中心项目的总成本。

    失败五：缺技能

    在现实中，很多企业本身可能缺乏所需要的许多专业人员和技能组合。而事实上，呼叫中心架构师、业务流程建模师、相关工具管理员、数据架构师及拥有其他许多技能的人员是必不可少的。在呼叫中心方面没有任何经验的情况下试图实施呼叫中心，这是一大错误。因为呼叫中心影响到各IT部门，包括测试、基础设施和安全等部门。这比派几名开发人员去上几堂培训课复杂多了。更不能忘了业务部门这一块，业务人员需要流程改进方面的培训，甚至可能还需要BPM工具方面的培训。

    建议：制订一项全面的培训和资源计划，将该计划列为初期资金申请环节的一部分。尽量减少申请资金的次数，争取尽可能多的先期资金。不然，管理人员可能会觉得呼叫中心项目在没完没了地消耗资金。

    失败六：缺项目管理 呼叫中心项目经理们必须管理项目范围、化解风险、让每个人跟上进度，并且与各个级别的人员进行相应的沟通。征集需求非常重要，必须避免分析麻痹（指项目的分析阶段付出的努力太少）。如果一个公司连一般项目的交付都成问题，那么成功实施呼叫中心项目的难度更会加倍。

    建议：把最好的项目管理资源用到呼叫中心项目上。或者从外面请来一两名明星级的人物来帮助领导这个项目。不管从外面选择谁，对方在交付重大转型项目方面最好要有成功记录。另外，这个人还要有足够扎实的技术功底，能够从概念层面理解呼叫中心。

    失败七：认识错误

    许多公司很幼稚，以为实施呼叫中心只是实施一个IT项目而已。其实，呼叫中心是一种软件架构，只有企业遵守了面向服务的核心原则，并且确保可交付成果与架构目标和路线图相一致，才能获得所需的效益。呼叫中心需要专业人员，包括业务服务需要借助呼叫中心架构师、开发人员、数据架构师、网络架构师和安全专家的共同努力才能构建而成。一个IT人员身兼多职的日子已一去不复返了。呼叫中心的每个层面都需要专业人员，要有用户界面设计师、业务流程建模师、数据服务专家、业务规则专家和企业服务总线（ESB）专家之类的人员。所有这些专家可能同时致力于同样的服务，这需要高度协作。

    建议：标准的IT团队结构对呼叫中心来说这毫无成效，所以要另辟蹊径。矩阵式组织（matrix organization）和相互协作的会议室环境值得考虑。拆掉小隔间，设立开放工作场所，以便这些专家可以密切合作。另外也有必要让业务人员和测试人员同处一室。到处挂上白板，尽量减少项目进度会议，而是选择更注重协作的手段。

    失败八：低估了复杂性

    从概念上来说，呼叫中心仅仅是IT人员多年来一直在构建的系统的下一个发展阶段。这个概念理解起来并不难，要正确实施却很难。呼叫中心和BPM的魅力在于它们给最终用户带来了简洁性，因为可以集成各个不同的后端系统，以便它们在用户眼里就像是一个组合式应用系统。第五代呼叫中心的使用的SOA技术的缺点在于，它大大增加了构建及管理软件的复杂性。构建呼叫中心是一项软件工程任务，这不是什么拖放开发工作，许多开发人员需要为顺利完成这种转变而努力。呼叫中心需要遵守相关标准和最佳实践（治理），还需要懂得复杂概念的专业IT人员，才有可能获得预期效益。 实施呼叫中心时需要做太多的事情，结果往往事后才想到安全。所以，及早征集安全需求很重要，那样底层架构才会一开始就获得安全支持。不然，如果以后着手处理安全问题，架构方面极有可能需要重大变动。

    建议：不管企业有多么保守，都要考虑到呼叫中心进展中会遇到各种各样的技术障碍。要留出足够的时间，因为可能会遇到各种各样的集成问题，有些问题是由代码引起的，有些问题是由工具本身引起的。厂商的产品还远远谈不上成熟，可能会出现各种设想不到的问题。要设定切合实际的预期目标，别试图一下子完成太多的事情。从小处着手，经常提供成果，然后不断扩大。将安全问题从“头”抓到“尾”。

    失败九：没有治理机制

    治理对许多人来说是个忌讳字眼。治理是一种SOA管理，要是少了它，就无法保证SOA项目取得成功。

     不管怎样，要获得呼叫中心的效益（可重复使用、灵活性和敏捷性等），项目团队就必须遵守公司采用的架构指导准则。这就是所谓的设计时治理。要是没有设计时治理，到头来面临的可能只是一大堆Web服务。要是出现这种情况，也就别指望什么投资回报了，因为很有可能最后一切都是从头构建。如果实施得当，随着时间的推移，SOA会逐渐变得具有成本效益。最终，开发工作将从构建服务变成使用服务。SynRoute公司的Jacky Huang称之为引爆点（tipping point），到时呼叫中心就会开始获得敏捷性和灵活性的效益。

    另外就是运行时治理。这时候，用户可能需要积极主动地管理呼叫中心生产环境的运行状况。运行时治理可以查看使用了哪些服务、执行策略和服务级别协议（SLA）、检测及排除故障、分析性能以及管理所有资产。但是不要以为一旦部署了运行时治理，就大功告成了。

    建议：把治理当成资金到位、与呼叫中心项目同时开展的一个项目来看待。应当专门设立一支队伍（通常隶属企业架构部门），要有自己的路线图和长远目标。别指望一夜之间就能实施好治理。这是一个漫长过程；需要好几年才能达到高度成熟的阶段。治理机制不断成熟时，呼叫中心也会随之成熟。

    失败十：任由厂商驱动架构

    SynRoute公司的ASCENT创造了厂商驱动架构（VDA）这个词语。过分依赖厂商会带来灾难。厂商的目的是把尽可能多的产品卖给用户，而用户的目标是成功实施SOA，并利用最少的成本为自己的公司提供最大的效益。看到其中的利益冲突了吗？

    另外， 厂商经常会承诺如果从它一家那里买来所有产品， 就能实现无缝集成。可事实上，厂商的产品有好多也是从其他公司那里买来的，结果其产品提供的集成比你从多个厂商那里 买来工具进行集成好不到哪里去。

    建议：弄清楚自己需要什么，再跟厂商谈判也不迟。 对厂商要进行非常全面的评估。如 果把范围缩小到几家厂商，就要请他们上门， 证明一下概念，看看能否满足种种要求。要认真盯着对方的一举一动，这时候，厂商再也无法隐藏在那些花哨的，这样可以防止犯下重大错误。

    要做好必要的准备工作，阅读其他实施人员所写的博客，请教使用相关工具的咨询公司。另外， 找已实施第五代呼叫中心的其他公司或厂商推荐的有关方 谈一谈。别指望有何捷径，一定要面对自己做出的审慎的决策。