前面谈了很多SOA的基本概念，但是，作为呼叫中心的研发人员来说，我们关心的是SOA概念如何在呼叫中心中建立，而第五代呼叫中心中的SOA主要解决的问题就是这个。

　　回顾一下前面所说的SOA的基本概念，第五代呼叫中心如何建立SOA，难点还是在如何提供合理的服务。合理的服务必须适合呼叫中心系统建设的要求。在这方面，目前还没有国际标准，一个公司的产品需要根据自身产品的功能和特点规划服务。

　　我根据自己在呼叫中心领域研发的经验，对呼叫中心服务的规划提出自己的分析，和大家一起分享。

呼叫中心系统难点分析

我认为只有一个，稳定性和灵活性的矛盾。

　　呼叫中心系统提供商往往分成两类，第一类是系统非常稳定，但是，很多地方不满足客户需求，而且绝对”不可以修改；第二类是系统非常灵活很满足客户需求，但是，稳定性一般，而且，当为满足客户需求做了修改后，系统就突然变得非常不稳定了。

一 稳定性

　　呼叫中心的一般组成部分，PBX、CTI、ACD、IVR（包含传真）、ADS（自动外拨系统）、ACC（短信、邮件等异步通信方式的呼叫中心）、ICC（Internet呼叫中心）、录音服务器、录音调听软件、坐席软电话、坐席业务软件、报表和实时统计。

　　稳定性的要求体现在两个方面，即不间断运行的要求和性能的要求。

(一)不间断运行的要求

　　很多呼叫中心，都是要求7*24小时不间断运行的，要求呼叫中心系统的稳定性很高，任何一个功能极大丰富的呼叫中心，只要稳定性不够，都不能让客户满意。呼叫中心中很多部分的稳定性要求很高，包括以下部分：

PBX：如果发生故障，电话无法打进呼叫中心；

CTI：如果发生故障，所有电话相关的软件无法工作；

ACD：如果发生故障，所有电话无法分配到坐席，也就是客户无法和坐席通话；

IVR：如果发生故障，所有电话进入呼叫中心后，无法听到自动语音，想和坐席通话也不可能；

ACC：如果发生故障，所有客户的邮件、短信、传真都无法让坐席处理；

ICC：如果发生故障，所有客户都无法通过Internet联系到坐席；
录音服务器：如果发生故障，所有电话录音都没有了，对于电话营销的公司，录音丢失意味着销售成果的丢失；

坐席软电话：如果发生故障，无法接听电话，无法进行坐席业务软件的操作，无法外拨电话；

ADS：如果发生故障，外拨数量大量减少，例如，ADS一天外拨5000个电话，不用ADS，只能外拨2000个电话甚至更少，导致很大的经济损失。

(二)性能的要求

　　呼叫中心中，交换机有成熟的性能指标，例如HBCC值，而软件系统往往借鉴交换机的性能指标。在电信的较大规模的呼叫中心中，性能测试往往用专用的工具，例如呼叫发生器，每小时产生几十万个呼叫，测试呼叫中心的性能。

　　有些呼叫中心，则采用人工呼叫的方式进行。一个电视购物的呼叫中心的项目中，用户就采用了这种方法，300个坐席人员在呼叫中心外呼叫新建设的呼叫中心，呼叫动作在同一秒做出，新建的呼叫中心在1秒内接收了300个呼叫，那么BHCC=300*3600=1080000，即每小时这个呼叫中心要承接108万个呼叫。测试的结果是交换机、ACD、业务软件、录音同时发生性能问题。

　　刚才说的情况是一个极限测试，实际情况是不会发生的。但是，在BHCC值达到交换机极限的时候，往往很多软件就出现性能问题，例如，CPU占用达到99%，或者处理延迟达到几十分钟，最终导致系统宕机。

　　设想一下，屏幕弹出是要在坐席电话振铃一秒以内完成，如果性能出现问题，可能客户挂机后屏幕才能弹出。

(三)实现稳定性的方法.

　　实现较高的稳定性，需要很多的技术手段，但是有一个核心的要求，就是开发成本的投入要求到位，其中包括开发周期要足够长，而且对于稳定性要求高的软件，测试成本占的比例会很高，大大超过了代码编写的成本。

　　对于稳定性要求很高的软件，测试成本往往占到整体开发成本的60%-70%。

(四)灵活性对稳定性的挑战.

　　如果一个软件，它为不同的项目进行修改，那么它的研发成本就会攀升，如果研发成本不够，稳定性自然会下降。而灵活性是稳定性的杀手。

　　还是以A公司的SomeThing软件为例，A公司为开发SomeThing软件投入了5个人1年的成本，开发成本为100万元，其中测试成本为60万（我认为这个比例偏低，姑且这样计算），稳定性为1年宕机10小时，计划售价10万元/套，1年销售10套，一年收回成本（为了方便，其他成本不计算）。

　　我们看看为了保证SomeThing的稳定性，A公司一年需要的投入：

　　我们可以看到，一年运营下来，软件的稳定性没有下降，每个项目宕机总时长都是10小时，每个项目的BHCC值都是30万，但是企业只有10万元的利润，离预期100万元的收益很远。

　　还有一个隐藏很深，但是致命的问题，就是人员不够了，需要扩招研发人员。为什么呢？因为软件开发了一年，10%的修改需要的时间是1.2个月，只要发生两个项目并行，就会出现人员不够的情况，只能扩招1个研发人员，那么，一年运营下来，血本无归。

国内大部分公司选择的方案是如下的：

　　一年运营下来，企业只有64万元的利润，收益大幅提高，而且不需要扩招人员，可怕，稳定性降低很多很多，一年宕机到330小时，可能是每天宕机一次。BHCC值逐步下降到5万。

　　还有一个隐藏很深，但是致命的问题，就是稳定性的问题是经常是乘法关系，即多个不稳定因素会关联在一起，导致系统更加不稳定，因此一年宕机330小时的估算是非常保守的。

　　而对于客户来说，导致众多运营上技术问题的核心都在于软件公司将测试成本省去，因为软件公司可能活不下去。

二 灵活性

　　技术上问题的核心在于稳定性和灵活性的矛盾，即需求的满足和变化的适应需要灵活性。现在再看看呼叫中心的灵活性产生的原因，灵活性有多么大，多么可怕。

呼叫中心系统灵活性产生的原因我认为有以下几个方面：

- 新的通信方式的不断产生；

- 新的行业不断扩展；

- 新的计算机软件技术的不断发展；

- 新的业务模式的不断创新；

- 新的管理方式的不断深化；

　　从技术上来说，灵活性产生的原因是两个方面，第一，整合的要求，第二，策略变化的要求。

(一)整合的要求

　　呼叫中心系统是一个全方位整合的系统，这一点我们很容易理解。

　　有一个上海的合作伙伴，我在和他的CTO聊天的时候，双方都是感慨万千。CTO说，他们是在语音板卡上开发的呼叫中心，做电视购物呼叫中心系统，有这样一个问题：客户提出了业务软件的一个修改，他认为工作量不大，但具体做业务软件的时候，发现需要修改坐席业务软件，具体做坐席业务软件的时候，发现需要修改软电话…….最后，需要修改对语音卡的控制，总计需要修改7-8个模块，而销售只谈了2万元，而且这种事在他们公司经常发生。

　　对于很多的客户，在系统整合的要求方面，他们确实要求很高，例如，在录音调听软件中，需要整合各种监控信息、报表信息、客户信息等等。甚至有的客户认为呼叫中心的所有管理软件应该按照Portal的概念组织。

　　呼叫中心的各个组成部分。PBX、CTI、ACD、IVR（包含传真）、ADS（自动外拨系统）、ACC（短信、邮件等异步通信方式的呼叫中心）、ICC（Internet呼叫中心）、录音服务器、录音调听软件、坐席软电话、坐席业务软件、业务软件，报表和实时统计，这些部分虽然数量不多，但是每一部分和其他交互很多，下面，我们分析一下交互，这种分析不是根据一个项目的需求分析的，而是大量项目的总结，也就是说如果你要想做一个可以在大量项目中复用的软件，那么这些交互你必须都要想到，否则，你的软件只能在少量的项目中使用。

整合产生的灵活性要求举例：

1、PBX：这是整合要求最少、灵活性要求最低的。

　　它只和CTI整合，很庆幸，ITU、ECMA和微软等等公司做了很多标准，我们按照标准做就行了，但是，还是有个别PBX厂商对标准支持的不好，需要CTI软件去适应；

2、CTI：整合要求最多、灵活性要求最高，这部分是大家比较熟悉的：

　　a)ACD需要从CTI获取交换机各种来电信息并通过CTI需要进行呼叫路由；

　　b)IVR需要从CTI获取交换机各种来电信息并通过CTI需要进行呼叫控制；

　　c)ADS需要通过CTI需要进行外拨并从CTI获取呼叫外拨结果；

　　d)录音服务器需要从CTI获取交换机各种呼叫信息形成相关的录音记录；

　　e)坐席软电话需要通过CTI进行全方位的坐席电话操作和信息显示；

　　f)报表需要从CTI获取中继、分机等呼叫信息并形成历史报表数据；

　　g)实时统计需要实时从CTI获取中继、分机等呼叫信息并形成实时统计数据；

3、ACD：应该说整合要求很多、灵活性要求很高，这部分大家应该非常陌生：

　　a)IVR，分成三个方面，第一，ACD系统需要根据客户来电在IVR输入的信息，如业务分类，账号等等信息来进行呼叫路由；第二，ACD系统在很多情况下是将呼叫物理驻留在IVR上，控制IVR进行排队音乐和提示的播报和转接操作；第三，ACD系统可能将呼叫路由到IVR，如在电话刚刚进入呼叫中心的时候，或者在做呼叫溢出的时候，这是ACD需要IVR占用情况的实时统计和命令IVR进入哪一个语音流程；

　　b)ADS，ADS对ACD的需要也全面，大体分成三个方面：第一，ADS外拨电话接通后，需要将呼叫通知ACD，让ACD分配到一个最适合的坐席；第二，ADS在执行外拨算法的时候，需要根据ACD提供的历史统计数据和实时统计数据，如每一个坐席或坐席组的历史平均通话时长和当前每一个坐席的占用状态；第三，ADS需要ACD配合呼入电话的需求，进行混合（Call Blending）；

　　c)ACC，ACC的短信、邮件、传真的请求需要ACD进行统一排队和分配；

　　d)ICC，ICC的文本交谈、电子白板、文件传输、护航浏览的请求需要ACD进行统一排队和分配；

　　e)录音服务器，录音服务器需要对ACD的信息进行记录，如坐席相关的信息，坐席姓名、工号、排队情况、技能组等等；

　　f)坐席软电话，软电话需要和ACD系统进行交互，主要是坐席状态管理、技能管理、分组管理等等，并且ACD要根据软电话的状态进行呼叫路由和分配；

　　g)报表，ACD需要产生大量的报表数据以供运营分析和辅助决策，如呼叫排队情况、呼叫分配情况、坐席状态的统计、坐席工作量统计等等；

　　h)实时统计，ACD需要以实时统计的形式提供现场管理的手段；

4、ADS（自动外拨系统）：

　　a)ACC（短信、邮件等异步通信方式的呼叫中心），ACC同样需要主动发起，需要ADS统一管理；

　　b)录音服务器，需要记录外拨特有的录音信息，如外拨时长，还需要录制客户应答之前的声音；

　　c)坐席软电话，屏幕弹出等操作需要和ADS进行配合；

　　d)业务软件，需要对外拨的任务管理、外拨客户资料管理方面与ADS交互；

　　e)报表，需要形成ADS相关的各种报表，以便调整外拨策略；

　　f)实时统计，两个方面，一方面ADS需要形成实时统计的数据，以供管理人员进行实时调整干预，另外一方面，外拨算法需要根据实时统计数据执行外拨算法，尤其是在预测外拨的情况下；

5、ACC（短信、邮件等异步通信方式的呼叫中心）：

　　a)录音服务器，短信、邮件等媒体，同样需要进行坐席质量管理；

　　b)录音调听软件，对于短信、邮件等媒体，需要特定的浏览器去显示；

　　c)坐席软电话，在坐席操作界面需要对短信和邮件进行显示和坐席操作，需要配合坐席业务软件进行客户资料管理和知识库调用；

　　d)坐席业务软件，配合实现与电话相同的处理流程；

　　e)业务软件，配合实现与电话相同的处理流程；

　　f)报表，实现与电话相同的历史统计；

　　g)实时统计，实现与电话相同的实时统计来实现现场管理；

6、ICC（Internet呼叫中心）：

　　a)录音服务器，同ACC；

　　b)录音调听软件，同ACC；

　　c)坐席软电话，同ACC；

　　d)坐席业务软件，同ACC；

　　e)业务软件，同ACC；

　　f)报表，同ACC；

　　g)实时统计，同ACC；

7、录音服务器：

　　a)录音调听软件，很自然，录音调听软件和录音服务器进行交互，展示给运营管理者，以便进行质量考核；

　　b) 坐席软电话，录音的启动和停止、录音记录的信息需要软电话提供；

　　c) 坐席业务软件；两个方向，方向一，坐席业务软件可以随时根据权限调听录音服务器中的录音，以便业务关联和信息补充录入，方向二，坐席业务软件需要为录音记录补充需要的信息，如质检人员可以在录音调听软件中看到产品信息和订购信息；

　　d) 业务软件，业务软件的订单、工单信息，经常要直接关联录音文件；

　　e) 实时统计，录音的状态需要实时统计，展现给运营管理者；

8、录音调听软件：

　　a) 坐席业务软件，很多坐席业务软件要求内置录音调听软件；

　　b) 业务软件，很多业务软件要求内置录音调听软件，同时，录音调听软件经常需要同时获取业务软件的数据，以便进行质检；

　　c) 报表和实时统计，很多录音记录的信息需要来源于报表，同时，很多录音调听软件需要内置报表和实时统计，进行统一的显示；

9、坐席软电话

　　a)坐席业务软件，大家很容易理解，这是呼叫中心必须的；

　　b)业务软件，大家很容易理解，坐席业务软件和业务本来就是一体的；

10、坐席业务软件

　　a)报表，坐席自我管理经常需要进行报表的显示，如显示本坐席或本组坐席历史的平均通话时长、平均应答次数、平均转接次数等等；

　　b) 实时统计，坐席自我管理经常需要进行实时统计的显示，如显示本坐席或本组坐席实时的平均通话时长、平均应答次数、平均转接次数等等；

11、业务软件、报表、实时统计

　　很多客户会要求为了运营分析方便，将业务的实时统计信息、业务的历史统计信息、呼叫的实时统计信息、呼叫的历史统计信息在一个软件中显示，有的要求在中间件中显示，有的要求在业务软件中显示。

(二)流程策略的要求

　　和其他的软件一样，呼叫中心软件存在大量的需要随时调整地流程和策略，如IVR流程、呼叫路由流程、呼叫分配策略、外拨策略、报警策略、坐席状态管理策略等。

(三)稳定性和灵活性的矛盾

　　如果没有整合的要求、没有流程策略的不断变化，呼叫中心就可以很稳定，就像我们经常见到的电话交换机、网络交换机、打印机一样；

　　如果没有不间断运行的要求、性能的要求，呼叫中心就可以很灵活，就像我们经常见到的OA软件、CRM和ERP软件一样。

　　呼叫中心就是呼叫中心，需要解决这个矛盾，我们不得不演进到第五代呼叫中心”，下一篇，我们看看一种基于SOA思想的解决方案。