第五代呼叫中心之SOA（六）
北京商路通信息技术有限公司 黄河
2009/11/30
第五代呼叫中心之SOA（一）
第五代呼叫中心之SOA（二）
第五代呼叫中心之SOA（三）
第五代呼叫中心之SOA（四）
第五代呼叫中心之SOA（五）
这一章我们看看坐席业务软件的故事，这一章，我们只说一个故事。
坐席业务软件一直是呼叫中心中需求最为复杂的一部分软件。坐席业务软件为了方便坐席的管理，经常呼叫中心的各个业务软件的信息集成在一起，方便坐席的操作和自我管理。
坐席业务软件的形式我举一个复杂的实例大家看一看。
我们现在对这个坐席业务软件的实现上看一看它和几个软件进行整合。
多复杂的一个网状的连接关系，这时，我们对这个复杂的连接关系做一个分析。
一 回避
这样复杂的坐席业务软件，很多呼叫中心的建设者都试图回避这种复杂性，回避的手段很多，总结下来有以下几种手段。
回避手段一：精简整合的服务器
很多集成商或业务软件开发商认为这种结构过于复杂，而他们自身往往提供“整体解决方案”，即所有的服务器软件基本上都是自己的，根据客户的要求修改即可。例如，客户关系管理、知识库、投诉管理、OA、订单管理以及坐席软电话、ADS服务器、IVR服务器、ACC服务器、ICC服务器、ACD服务器、录音服务器、传真服务器、报表服务器、实时统计服务器都是自己来做，那么对于很多接口环节都可以节省了。
业务软件开发商经常会说，客户关系管理、知识库、投诉管理、OA这几个部分，在系统中就是数据库中的表的设计，一个数据库、几张表、一套业务软件、一个应用服务器即可。对于功能需求非常简单、需求变化很小的呼叫中心系统来说没有问题。然而，一个功能复杂、需求变化频繁的呼叫中心，这种设计方式，简直就是灾难。
我们就拿知识库系统来说，一个简单的知识库，知识可以根据关键词进行搜索、分类查找即可，而真正复杂的知识库包含很多功能（作为一个外行，我就知道很多方面的要求），包括知识的录入、知识的审核、知识的发布、权限管理、知识更新、知识的生命周期管理、知识分类、全文检索等等，还有一方面就是知识库系统与其他系统的交互。
知识库的故事
我关系很好的一个客户就是这样的，我去过很多次，这个客户有四套知识库系统，分别用于电话呼叫中心、ICC呼叫中心、连锁机构分支知识库、网站相关信息知识库，四个知识库都是按照刚才说的方式，都是不同系统中的一个部分，基本上是一个系统中的几张表、几个软件模块，做得粗糙简陋。当然，更有意思的是他们之间根本无法整合在一起，坐席人员在4个知识库系统之间不停的切换，操作效率之低令人惊叹。和他们的主管交流，主管说，他们已经花了很长时间、很大的投资试图将这几部分整合在一起，觉得离整合的一天遥遥无期。
总之，精简整合的服务器手段是行不通的，需要各个部分专业化，最好是使用专业的软件，最起码，要进行分离，保证和独立升级，不断优化。
回避手段二：限制客户需求
限制客户需求是一个最好的办法，很多集成商的言论。
我引用业内资深专家李宝民的一个数据：“呼叫中心75%的成本是人力成本”，呼叫中心的运营管理者在“努力地、不停地”通过IT手段降低运营成本、提高运营收益，集成商能逃得了吗？
为了提高运营管理水平，运营管理者往往在几个方面对坐席业务软件要求：
- 操作整合：坐席可以在一个界面中快速查到所有的信息、快速填写所有表单；
- 流程合理：坐席可以简单、规范的处理流程的一个环节，流程要可以适合业务而且适应业务的变化；
- 坐席考核：坐席将报告所有的信息到运营主管那里，以便主管可以进行考核；
- 现场管理：坐席实时报告各种数据，以便运营主管“现场指挥”；
- 智能策略：坐席要与ACD、外拨系统交互，以便将提高效率的智能策略执行下去；
- 自我管理：坐席可以通过报表、录音、实时统计对自身的工作进行自我管理；
- ........
一个好的呼叫中心主管，就是通过这些不断优化，每一个季度降低人员成本，提高收益。如果集成商拒绝这些需求的变化，或者对需求变化提出的报价过高，就会面临项目失败。
回避手段三：购买现成的软件
购买现成的软件是一个听起来很好的办法，可以花很多钱买很高级的成品软件。
我们可以购买最好的交换机、最好的坐席业务软件，坐席业务软件包含了最适合客户使用的CTI、IVR、录音、OA、CRM、工作流系统，这件事情好像就可以了。然而，这个中手段是较好的一种回避手段，但是采用这种手段最容易忽视业务的特点和业务的变化。
一个好的软件系统，需要在三个方面帮助客户，第一，软件本身带着成熟的管理思路；第二，软件可以帮助客户在运营中不断发现问题，总结分析；第三，软件可以将客户发现的问题进行弥补，不断优化。
而客户往往只看重第一个方面，那么离失败就不远了。
客户初期购买一个软件的时候，尤其在试用的时候，觉得什么都好，能够从中学到很多很多东西，指导他们进行呼叫中心运营，可是，经过一段时间的运营后，发现了很多“不对劲儿”的地方，可是，不知道如何去分析出“不对劲儿”的原因，经过很大的努力，找到了问题所在，试图修改操作方式、流程、组织结构，这是，他们找到当初让他们万分信赖的软件厂商，软件厂商的答复往往是两种结果：第一，不可以修改；第二，可以修改，价格是原系统的几倍。最终，双方不欢而散。这个呼叫中心要么病态运行着，要么推翻重建。
回避手段四：用中间件、开发平台
长期进行SOA思想熏陶的软件开发公司，回选择一个好的中间件或开发平台，包括IBM、微软、BEA、普元等等，认为这样就可以将问题解决了，实际上，还是不行。
呼叫中心有其特殊性，前面我们已经谈到了，大家可以参考一下前面的章节。
这里再重复说明一下，就是实时性的问题。
录音的启动和停止是实时的；
IVR的转接是实时的；
ACD的分配是实时的；
.....
二 SOA架构的解决办法
前面的回避手段的举例和分析之后，解决办法基本有了线索了。
解决办法就是先分析实时性。
下面就是我分析的坐席业务软件与其他系统的交互中，存在实时性要求的部分。
实时性要求较高的部分用红线标记。
对于实时性要求不高的部分，采用业务相关的中间件或开发平台，遵循SOA架构，采用WebService接口即可，这是很多集成商已经着手走的路。
实时性要求比较高的部分，我建议各个服务器提供合理的服务接口，包括以下两点：
第一，服务内容合理，颗粒度划分合理、功能全面；
第二，接口形式合理，建议采用的形式包括：
- 采用格式紧凑的TCP基础上的传输形式；
- 对外调用接口尽量丰富，包括Dll、Ocx；
- 为了B/S调用方便，最好直接提供封装AJAX的Java Script对象。
分析完成后，还是觉得实时性要求比较高的部分太复杂，开发成本太高，我们对架构进行修订，可以极大的降低复杂度。
这是，坐席业务软件的复杂度降低很多，它对于实时性要求较高的部分，可以只与软电话发生交互。
我们应该为这个方案喝彩！很好，业务软件开发商成本降低了太多了，以前的问题全部解决了。
可是，软电话的提供者非常难受了，交互过于复杂了。
我们再次修订架构，引入实时服务总线的概念，结构变得真正合理了。
通过实时服务总线，将各个实时性要求比较高的部分组织起来，这是目前最合理的架构。
第五代呼叫中心之SOA(七)
第五代呼叫中心之SOA(八)
第五代呼叫中心之SOA(九)
CTI论坛编辑
相关阅读: