Avaya与Genesys产品及方案对比Word文档下载推荐.docx

Avaya与Genesys产品及方案对比Word文档下载推荐.docx

《Avaya与Genesys产品及方案对比Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《Avaya与Genesys产品及方案对比Word文档下载推荐.docx（20页珍藏版）》请在冰豆网上搜索。

作为CallCenter市场的高端厂商，Avaya与Genesys都可以提供针对高端CTI市场的产品及解决方案。

但是，纵观Avaya的整个CRM产品线，结合AIC，Avaya已经可以提供包括Voice，VoIP，Outbound，Email，Web，Fax等多种接入渠道的MultimediaContactCenter，同时面对客户不同的要求，有BCMR，OA，和CMS不同级别的报表系统可供选择，此外，Avaya更提供了PBX，IPTelephony，IVR，PDS，Recording等其它稳定可靠的CallCenter相关产品及解决方案。

然而，Genesys作为独立的CTI厂商，无法提供完整的CRM解决方案，仅局限于CTI产品。

由此可见，Avaya并非只是提供单一的CTI产品，而是专注于为客户提供CallCenter系统的整体解决方案。

处于业界的领先地位的Avaya提供了一整套综合的、完整的、十分具有竞争力的CRM解决方案，而Genesys仅仅在CTI市场上与AIC处于同一竞争位置。

2系统兼容性

对于CallCenter系统来说，系统状况比较复杂，平台结构也不尽相同，这就要求CTI软件具有足够的兼容性，能够支持不同的操作系统、数据库、Web服务器等。

AvayaIC是建立在CORBA结构基础上的，具有很好的支持异构系统的能力。

CORBA（CommonObjectRequestBrokerArchitecture）是一种开放的、独立于厂商的、用于网络上的计算机底层应用结构，任何基于CORBA的应用均能协同工作。

目前，AIC可以很好的支持主流操作系统（Microsoft、AIX、Solaris）和数据库（Oracle、DB2、SQLServer）。

Genesys的底层平台为Framework，底层通讯主要基于Socket套接口，其上分为ERS、NRS、ICS、OCS、WFM和Workflow六个模块。

其中只有Framework和ERS两个模块可以运行在多种不同的操作系统和数据库上，而其他4个应用模块只能运行在Windows平台之上。

当建立一个真正的多媒体客户服务中心时，一旦客户选定了Unix服务器，AIC的核心应用只需要运行在一台高性能的Unix服务器上即可；

而Genesys还需要单独配置Windows操作系统的PCServer来运行Outbound和ICS等多媒体接入模块。

同样，数据库也会存在同样的问题，对于Outbound和ICS模块，只能选用SQLServer，因此客户和集成商只能花费额外的财力和人力，来弥补Genesys的产品缺陷，并且为今后的安全性留下了隐患。

3安全稳定性

客服中心在不间断的服务，系统的稳定性和可靠性是考察性能的重要指标。

这要求CTI系统必须具有处理大容量话务的能力，并且其系统结构应支持多种备份及负载平衡、高可用策略，系统平台稳定、可靠、处理能力强。

AvayaIC利用CORBA提供的容错机制，不仅能实现负载均衡，还能使每一个对象同时在两个或多个服务器上运行，当其中的一个出现故障时，系统能自动切换到另一个服务器。

具体做法是，在AIC中，所有的服务进程和座席都会属于某个域，在这个域中的应用缺省会使用属于这个域里的服务资源，如TS，ADU，EDU，Workflow等，如果该域无法提供所需的服务资源，系统会根据预先定义的Failover策略，利用其他域内的资源来提供服务。

这样的机制保证了CTI系统拥有很高的稳定性。

Genesys一般在部署时采用两种冗余机制，一种是依赖于操作系统级的备份方案如HACMP；

另一种方案是通过HAProxy，这只是针对T-Server的备份方案，通过连接多个CTI-Link来达到高可靠性的目的，这样才能确保主T-Server和备T-Server能够从交换机接收到同样的信息。

通过实验证明，AvayaIC可以达到最高级别的备份，即在硬件系统备份的基础上，对IC的所有应用进行多个备份，这样做的好处是，可以最大限度的降低运营风险，同时也提高了维护人员的工作效率。

Genesys虽然也提供了不错的冗余方案，但只是应用在关键的部分组件上，对于除了T-Server以外的其他服务来说，并没有完全做到高可靠性的要求，因此就无法保证系统的整体高可用性要求。

4统一排队与路由

客服中心已经不仅仅是通过电话方式接入，结合多种联络渠道以处理问题的能力是必要的，这正是人们互动的方式，因此最终要与其它电子渠道进行整合，形成一个统一的客户接入平台。

这就要求CTI系统应提供真正的多渠道统一排队机制，能够对开放的多媒体渠道统一接管、多渠道互动、集成各种与用户的接触点，进而成为一种真正融合的联系中心。

AvayaIC能够在众多沟通渠道上对客户互动进行路由和管理，包括对Voice、E-Mail、Chat、Callback、WebCollaboration、VoIP以及电子商务系统等，无论客户选择那种沟通渠道，AvayaOperationalAnalyst也可以跟踪和报告所有的互动记录。

AIC特有的电子数据单元（EDU）能为所有的企业应用提供一个全面的、定制的实时数据库，从而向业务代表提供最及时、最相关和最富个性化的信息资源，供处理交易使用；

另外，一个独立于媒介的工作流引擎WorkFlow，允许每个客户交互被独立地路由，并基于不同的业务规则和以往的客户信息实现个性化，因而，企业可以利用每个渠道的特点，提供更有针对性和更有效的客户服务。

AVAYAIC部署了两种多媒体联络路由机制。

1）混合排队方式。

这种方式下AVAYAIC支持两套资源管理系统：

外部的ICHardACD用于语音排队/分发，IC内嵌的名为WebACD的SoftACD则用于电子邮件和Web排队/分发。

在所有媒体渠道中，工作流程服务都可以用于指导路由策略。

为实现横跨两种不同资源管理系统的业务代表状态控制，AVAYAIC采用了Blender服务来调用工作流，查询ADU服务器及相应的系统资源的状态，从而跨所有媒体渠道跟踪业务代表状态。

2）通用排队方式。

这种方式下AVAYAIC支持一套资源管理系统用于所有媒体渠道。

它包含在名为BusinessAdvocate的服务器内。

所有联络都在BusinessAdvocate的组件逻辑资源管理器（LRM）中进行排队。

LRM包括用以支持业务代表和联络的匹配的所有逻辑。

它的作用是，将排队的联络同空闲业务代表进行比较，找出最佳匹配组合。

本质上，ICBusinessAdvocate是一种SoftACD。

资格判定和等待选择处理是通过语音通信服务适配器（用于语音联络）和WebAdvocate适配器（用于电子邮件和Web联络）、调用适当的工作流来实现的。

这两种适配器可在LRM、工作流和WebACD与TS接口之间进行仲裁。

Genesys同样部署了两种多媒体联络路由机制。

这两种机制都采用同样的组件，但其各自的功用根据采用方式的不同而分别不同。

Genesys支持两套资源管理系统：

外部的HardACD用于语音排队/分发，Genesys配置服务器中内嵌的SoftACD则用于电子邮件和Web排队/分发。

在所有媒体渠道中，交互路由器都可以用于指导路由策略。

横跨所有渠道的状态控制可通过状态服务器实现，状态服务器通过语音通信服务器记录语音业务代表状态信息，同时通过IS语音通信服务器记录电子邮件/Web业务代表状态信息。

这种方式只支持一套资源管理系统用于所有媒体渠道，这套资源管理系统包含在配置服务器内，体现为SoftACD形式。

Genesys系统通过附属路由请求接收HardACD通知，然后等待规定的VDN，直到收到Genesys交互路由器服务器的通知，了解呼叫应予传输的目的地。

Genesys系统在配置服务器内部建立联络队列，利用状态服务器作为横跨所有渠道跟踪业务代表状态的手段。

交互路由器服务器将用一组统计参数（也即最空闲、技能等）来查询状态服务器，从而将联络转接给选定的业务代表。

SoftACD模式下的Genesys不使用HardACD进行排队，但会用它来实现业务代表登入/登出就绪/未就绪激活等功能。

AVAYA和Genesys在多媒体路由领域提供了同等强劲的中间件产品，在市场和分析家当中都屡获好评。

但是这里有一个由Genesys的市场宣传所巧妙造成的普遍误解，就是，客户互动平台表现为真正的SoftACD形式，因此致使HardACD被废弃。

而事实上，SoftACD模式下的Genesys（见上文所述的Genesys通用排队方式）的确需要HardACD（大多数情况下）来完成登入/登出和最终呼叫传递。

在平台/应用发生故障，Genesys要求业务代表必须登出系统并重新登录，以便通过第三方控制来恢复服务的时候，它也需要依赖于HardACD。

否则系统将导致运行冲突和报告错误，因为HardACD和SoftACD将会竞争系统资源。

尽管如此，SoftACD作为完善的基于资源的路由内部联络排队方式，其价值仍是不容置疑的。

就这个方面来比较AVAYA和GenesysSoftACD，可以注意到AVAYA的IC算法的优越性源自于现有的专利智能路由方案，以及Genesys管理控制台内部的无懈可击的外观表现。

通常，人们会发现，尽管Genesys对自己的SoftACD功能推崇备至，但其项目实施中，同更为直观的混合排队方式相比，只有大约30%是以这种方式为基础的。

导致这一选择的主要原因之一，在于Genesys舍弃交换机的已有智能，试图取而代之所带来的复杂性。

由此，用户必须亲自定义和管理所有呼叫中心组件——交换机、中间件、业务代表等。

从理论/架构的观点看来，这一特质可能好像非常完美，但实际上所有此类软件对象和特性的维护方面的突出困难，使得这种实施工作（Genesys通常会遭遇的问题）变得成本高昂，风险重重。

5座席应用

完整的呼叫中心是一套客户化的应用系统，其中包括座席应用子系统、数据库子系统等，并且还要与后台业务系统、CRM系统等进行整合。

这就要求CTI应该提供友好的、完善的座席界面，足够开放的开发接口，和方便的应用开发工具，以利于各种应用平台的开发与整合。

AIC现在国内销售最新的版本7.1，可以提供C/S结构的AvayaAgent，和基于纯B/S结构的WebAgent，这两种都是统一的后台应用，提供了对所有渠道的支持，而且可以通过修改数据库脚本快速简易的定制布局和配置。

考虑实际运行环境中的需求，它还提供了一个学习工具，可以培训新进人员并且提高工作效率，座席还可以通过选择应答条件和内容，快速准确的回复交易问题。

为了方便二次开发和集成，Avaya还提供了.NET和Java的API接口，可以很好的满足业务需求。

更加贴切中国市场的是，所有的座席界面和应用都有完整的汉化版本，减少了本地化带来的工作量。

Genesys提供了两种座席界面，一种只是简单的软电话功能，如左下图，需要很多客户化的工作，提供ActiveX和Java的开发接口；

另一种是处理Internet的座席界面，如右下图，只提供ActiveX的开发接口。

GenesysSoftphoneGenesysInternetAgent

此后，为了适应市场需要，Genesys开发了ContactNavigator的统一座席界面，并提供Java的开发接口，但是这个座席和开发包都是需要额外支付费用的，并且没有进行汉化。

GenesysContactNavigator

AvayaIC的用户界面先进、直观，基于环境，使用户可以对所有媒体类型一目了然（不会受限于界面），适用于通过密集和瘦客户端设备，满足联络中心业务代表的视觉和行为需要。

6报表系统

一个功能强大的呼叫中心支持系统，应能实时提供呼叫中心各种运行信息，让管理人员可以监控一些控制因素，统计报表系统的功能是对服务中心的各种数据按照不同的要求进行全面的统计，并以各种图表的方式表示出来，以便为呼叫中心运管人员提供决策分析的依据。

这就要求CTI能够支持开放的、分布式、多平台的架构，和比较强的扩展性，并且能够自动结合完整的多渠道数据，以进行数据分析。

AvayaOperationalAnalyst提供了基于B/S结构的实时报表、历史报表和高级报表系统，可以运行在不同的操作系统上，而且提供了丰富的数据接口，除了能够出具所有与CTI相关的报表，更集成了优秀的Cognos软件形成了完整的多样的报表视图。

对于高要求的客服中心来说，OA还可以采集和分析AvayaCMS的数据，并产生高级报表。

实际上，OA可以满足目前CallCenter的所有报表需求。

AVAYAOA是一种支持多家ACD厂商的报告平台。

所有联络相关事件和相关数据都可以通过AVAYAICADU数据容器得到跟踪和记录。

这个容器由AVAYAIC流程事件采集器加以监视。

事件采集器将数据传输到AVAYA的OA数据管理器，随后在TimesTen实时数据库内把输入的事件转换成摘要数据项，以便最大限度提高报告的效率。

在每一个时间间隔的最后，摘要数据可用于被称为转发器的AVAYAOA流程，转发器通过其姐妹流程记录器将实时摘要存档到AVAYAOA历史数据库中，以供AVAYAOA历史报告客户端的进一步使用。

AVAYAOA实时报告客户端经由报告数据服务器流程，直接从TimesTen实时数据库接收信息。

报告数据服务器可以查询实时数据库，从而定期性的更新自己的数据集合，并将所有已改变的数据主动推入到AVAYAOA实时报告客户端。

针对详细联络信息，AVAYAIC采用了一种称为报告引擎的数据回收流程，它能够过滤EDU中记录的所有数据，或是一部分感兴趣的数据。

随后，被选定的信息将通过AVAYAIC数据服务器，在AVAYAOA历史数据库内直接收回，以便进行逐次联络分析。

这个过程和Genesys集中器非常相似，但AVAYAIC报告/数据服务器流程支持多种不同渠道（相对于只支持语音的Genesys集中器），可以同IC框架相集成（相对于需要单独付费购买的Genesys集中器）。

AVAYA同Genesys报告架构的主要区别之一，在于实际的数据库模型。

AVAYAOA模型涵盖丰富，由近100个预先定义的数据结构支持，充分体现了AVAYA对联络中心数据组织需求的深刻理解。

AVAYAIC/OA由图形化的数据库模型AVAYAIC数据库设计工具支持。

IC数据库设计工具能够在现有的数据结构内添加全新数据结构和全新数据域，同时支持第三方数据库，将它们整合成为一个联合逻辑数据库。

所有此类操作都可以用图形化方式完成，无需任何数据库编程。

AVAYAOA报告架构的优势之一，它不仅不会干扰CMS系统作为运营报告平台的正常职能，还可以充分利用AVAYAOA的多渠道企业级分析功能对其加以补充。

AVAYACMS借助于CMS转发器组件，利用它将语音呼叫特定信息传输到AVAYAOA报告平台，这个过程与AVAYAIC的事件采集器相类似（多媒体数据抽取和转发组件）。

在这种方式下，AVAYAOA可以采集最多240个CMS外部呼叫历史（ECH）信息馈入的历史时间间隔数据。

同纯AVAYA环境内的其它报告平台、如Genesys相比，CMS同AVAYAOA的集成是其主要的与众不同之处。

基本上，Genesys的报告引擎是由STAT服务器所驱动的。

STAT服务器汇集来自不同接口（用于语音通信的T-Server和用于电子邮件、Web的T-Server变型）的信息，并在服务器的内存缓冲内部编译统计数据。

随后，相关客户端即可查询STAT服务器，实现路由、报告和员工管理等功用。

Genesys解决方案报告包括两个产品，分别是ContactCenterPulse+（CCPulse+）和ContactCenterAnalyzer（CCAnalyzer）。

它们采用相同的基础数据源和后端数据处理服务，但是其数据传输和提交功能有所不同。

CCPulse+是一种桌面级Win32报告应用，可提供实时与历史报告（此前只在pre7.0版的CCAnalyzer中能够实现）。

CCPulse+能够定义复杂的基于规则的统计数据、限制和基本算法算子（此前同样只在CCAnalyzer中实现）。

CCPulse+旨在简化日常资源管理任务，实现对状态和过往联络中心绩效的概括性评估。

CCPulse+不提供基于浏览器的客户端，对远程地点的运营决策制订者来说，同AVAYAOA基于浏览器的实时报告功能相比，这是一个重大的缺陷。

CCAnalyzer则是一种企业级的历史报告解决方案，以报告开发工具、按需与计划报告生成功能、以及跨企业内联网的报告传输手段为特色。

这些先进的报告功能由HyperionSolutions公司（前身为Brio）开发的商务智能应用、或其它第三方报告工具负责支持。

CCPulse+和CCAnalyzer都是基于对象的报告。

在Genesys报告生成过程中主要需要注意的问题，是在Genesys配置管理器内部定义和配置这些对象所花费的大量时间。

另一种Genesys报告组件名为呼叫集中器（CallConcentrator）。

呼叫集中器直接同Genesys框架组件如T-Server和配置服务器等相集成，用以采集和记录呼叫数据，提供基于呼叫的报告。

呼叫集中器是一种独立许可组件，脱离Genesys解决方案报告平台（CCPulse+、CCAnalyzer）单独销售。

它支持特殊呼叫过程的跟踪，可采集相关数据，最后创建OLAP报告（利用HyperionSolutions[前身为Brio]产品）。

与之相比，CCPulse+和CCAnalyzer主要用于提供基于对象的总计报告。

目前，呼叫集中器只支持语音数据。

因此对于多渠道实时和历史报告，用户仍将不得不诉诸于CCPulse+和CCAnalyzer报告工具。

Genesys数据库模型支持基于ETL的数据采集和存档流程，同AVAYAIC/OA数据库模型相比要过于简单。

由于报告的信息丰富程度完全取决于数据库本身所包含的数据，因此这种特性成为客户的一个至关重要的基础架构顾虑。

Genesys数据库模型主要由两个表格结构以及一个业务代表/DN状态信息表组成，其中前者包含了全体呼叫详细信息和单个呼叫详细信息。

模型还支持一个用于呼叫所附带的实际数据的表格结构。

Genesys能够扩展数据库模型以覆盖自定义数据，但是采用的方法不够直观，且通过基于文本的配置选项来驱动。

与之相比，AVAYAOA的历史数据库能够借助直观工具轻松得以扩展。

CCPulse

CCAnalyst

AVAYA选择了在路由引擎（AVAYAIC）和报告引擎（AVAYAOA）之间划分开功能与职责。

这样做的主要好处是，分别负责不同事务（路由和报告）的两个组件之间不存在相互冲突。

Genesys则选择在同一框架内混合路由和特别实时/历史报告组件。

乍看起来后者较有吸引力，因为它意味着您可以一步到位，但是，更近距离的考察可以发现，它会对各自的引擎造成不必要的压力。

STAT服务器所担负的职责使Genesys基础架构负担沉重。

它最初旨在作为从T-Server采集到的原始语音通信信息的采集器，现在则是统计信息的主要来源，用以协助Genesys交互路由器（路由引擎）和特别报告引擎（CC-Pulse+和CC-Analyzer）。

随着Genesys框架的扩展，STAT服务器成为大多数功能的根本基础，例如Genesys外拨和员工管理应用。

由于多个源都有此类需求，STAT服务器不再作为“推动器”，而是成为关键任务服务器组件，占用大量系统和网络资源。

Genesys试图让多个STAT例程共存于同一解决方案中，以此减轻STAT服务器的压力。

这种方式可能导致实时报告性能问题，因为更新和检索过程会受到严重影响。

同时，当用户提高系统复杂度，威胁到解决方案稳定性时，也可能会出现配置和维护问题。

AVAYAIC系统将这个过程委托给AVAYAOA报告系统，通过转发概念传递ADU和CMS流程所跟踪的原始信息，从而减轻了路由引擎的负担。

无论ADU还是CMS转发器都不是高强度流程，对系统资源影响很低。

在AVAYA模式内，路由组件和报告组件之间存在着明确的分界线。

用户可以将路由器的作用/职责从报告引擎中割离出来，以此从中明确获益。

从机械角度比喻，这就像是用一根车轴为各个车轮提供独立动力。

因此，如果车轮在冰上行驶，它将减缓速度，而不会影响到其它车轮的速度，车辆仍将保持自己的固有方向。

很明显的，与此相似，如果AVAYA报告引擎遇到问题，它绝不会对路由引擎造成影响，反之亦然。

在Genesys框架中，如果STAT服务器出现问题，报告引擎和路由引擎都会受到影响。

这种相关性更类似于统一车轴。

Genesys不是直接、而是间接的从ACD源获取信息。

这一信息全部来自于ACD，除非Genesys为了打破这种依赖性而致力成为“事实”的ACD，也即所谓的软件ACD。

虽然如此，Genesys软ACD方式并非Genesys首选的市场策略，因为对于Genesys产品是否足够坚固可靠，是否能够成为值得信赖的主要联络分配引擎，业界还存在着一定的顾虑，特别是在涉及到实时、关键任务渠道如语音等时尤其如此。

为此，Genesys的项目实施中只有不到30%是SoftACD，大多数情况下GenesysSoftACD用于支持HardACD，作为故障备用。

因此，Genesys所监视的逐呼叫信息通常反映的是它从硬件ACD接收到的内容。

以AVAYAPBX为例，它的业务代表状态信息就无法简单的用于第三方中间件，这最终影响到了Genesys报告的准确性。

一般来说，Genesys在与第三方ACD整合方面存在着先天缺陷，因为它必须采用最低端的通用协议如CSTA（CSTA并非标准，而是一组建议）。

Genesys报告引擎可监视语音通信事件，AVAYA的报告引擎则用于记录语音通信事件。

记录和监视是截然不同的。

记录意味着跟踪“真正”的实时信息，而监视指依据关联/观察进行测量。

例如，温度计可记录温度，人则利用读数来观察温度。

读数的准确性类似于观察，未必会反映出真正的温度值。