《微软关于联想CallCenter三期方案建议书.doc》由会员分享，可在线阅读，更多相关《微软关于联想CallCenter三期方案建议书.doc（30页珍藏版）》请在三一办公上搜索。
1、联想Call Center系统实施方案To:LegendFrom:Microsoft (China)Date:2003.6.10目录1.需求分析部分31.1业务背景介绍31.2项目目标31.3项目范围31.4业务流程分析31.5应用场景分析31.6用户类型和特点31.7系统运行环境31.8系统功能需求31.9系统性能要求31.10系统稳定性要求31.11系统安全性要求31.12系统可维护性要求31.13系统可扩展性要求31.14用户界面要求31.15与相关系统集成要求32.方案总体设计部分42.1系统总体架构42.1.1软件设计总体架构42.1.2系统部署设计总体架构62.1.3现行系统设计与
2、原有系统的比较72.2系统功能设计92.2.1业务主模块92.2.2知识库模块102.2.3统计报表分析模块132.3数据流程图设计172.4本系统与相关系统的集成/互连172.5软、硬件分析选型（软件、服务器、网络）182.5.1软件选型分析182.5.2硬件选型建议202.6性能、稳定性、可扩展性设计212.7项目投入、产出分析212.7.1软、硬件投入212.7.2人力资源投入222.7.3微软技术支持服务：护航计划242.8项目技术风险分析252.9系统布署252.10运营维护（备份、恢复、清理等）设计252.10.1备份、恢复策略252.1系统升级办法/方案291. 需求分析部分1.
3、1 业务背景介绍1.2 项目目标1.3 项目范围1.4 业务流程分析1.5 应用场景分析1.6 用户类型和特点1.7 系统运行环境1.8 系统功能需求1.9 系统性能要求1.10 系统稳定性要求1.11 系统安全性要求1.12 系统可维护性要求1.13 系统可扩展性要求1.14 用户界面要求1.15 与相关系统集成要求2. 方案总体设计部分2.1 系统总体架构2.1.1 软件设计总体架构联想Call Center 的现行的应用模型采用C/S和B/S并行的结构（如下图），大部分工程师使用VB 客户端程序连接后台Oracle 数据库，Web 用户使用浏览器通过中间层ASP及DLL访问数据。后台数据
4、库也是两个节点OP1和OP2并行（非Cluster）。从目前的情况来看，OP1主要负责支持VB Client的访问，高峰期并发量为235 Connections; OP2负责所有的Web 访问及部分VB Client和其他应用, 高峰期总体并发量为161 Connections，其中Web 访问的并发量存在明显的瓶颈，40 Connections以上，响应性能明显下降。由于现行Call Center整体设计架构为C/S和B/S混杂，管理比较困难。C/S架构在部署及程序升级时带来很多额外工作量，同时应用范围也有限。 建议实现坐席人员操作页面WEB化，将目前系统的C/S与B/S结构统一整合为B/S
5、结构。 B/S程序可以将联想的业务系统使用可以延伸到公司内部的坐席、工程师、公司其他人员甚至于联想的代理商和维修站或最终用户，大大提高系统的易用性和可拓展性。建议联想Call Center未来架构设计在整合后采用B/S多层架构体系。所谓B/S多层架构如下图所示，分为Presentation, Business Logic, Data：1. Web表现层 表现层是直接和使用用户进行交互的部分，通过可视化的用户界面表示信息和收集数据并响应用户请求，是用户使用应用系统的接口。在联想Call Center架构设计中，表现层将使用通用IE浏览器作为各类用户的统一界面，取代原来的VB客户端与Web访问并行
6、的模式，在提升界面统一性、友好性、易用性的同时，也使未来应用的部署升级更加便利。服务器端的Web服务器负责向终端用户显示业务信息，收集业务数据，同时处理客户通过Internet或Intranet发出的各种请求，并调用后台COM+中的业务处理或数据处理组件完成相应工作。表现层的主要开发技术: ASP.Net: Web 表单，组件, HTML, DHTML, 脚本 Win forms Win32 API 和组件 Mobile Internet Tool Kit 开发移动设备应用2. 业务层 业务层是实际业务规则以及数据处理的执行部分。业务层通过将正规的过程和业务规则应用于相关数据来实现客户通过表示
7、层发出的业务请求。在Windows DNA框架中，业务层使用COM+技术，将复杂的业务规则和数据处理操作封装在一个或几个COM组件中，通过Windows Component Service向外提供服务。Web服务器端应用程序使用这些COM+提供的接口进行业务操作。使用COM+会在中间业务逻辑层带来很多相应的好处，如保证事务处理的一致性、利用对象池技术提升系统处理性能、加强组件访问的安全性等等。同时，基于COM+的组件式开发为系统的整体架构和扩展性也带来了很多好处，任何业务流程的改变将只需要通过增加中间层业务组件或接口方法即可实现，不会导致对系统整体架构作大规模的改动。中间层的主要应用技术 .N
8、et Assembly, Serviced Components Web Services Database Connectivity (ADO.Net) Transaction services Queued component services3. 数据层 数据层是业务数据的存放地。通常数据层使用一个关系型数据库（如SQL Server）来实现数据的存储，并集中管理这些数据，实现企业业务数据的完整性、安全性和灾难防护。u 数据层技术 OLE DB, ADO, ODBC ADO.NET XML软件设计总体架构具体在微软平台上进行开发的模式类似下图：2.1.2 系统部署设计总体架构这样Call
9、 Center的系统架构将最终整合成为下图所示：设计要点如下：1. Web UI Tieri. 统一Web 访问接口，所有用户均通过IE浏览器在不同的客户端对业务系统，报表系统，知识库进行访问。Web访问安全性将在中间层加以控制。ii. Web UI将采用ASP.Net实现，性能较原有ASP或JSP有大幅度的提升，同时更加便于开发调试，页面展示也更加灵活。2. Business Tieri. 中间层的扩展性，IIS与Application均运行在App Server上，两个Application Server并行作NLB负载均衡，单一节点Down 机不会造成业务系统的瘫痪。未来中间层系统需要扩
10、展时，只需复制添加节点即可。ii. 对于系统3大模块（业务主模块、知识库管理模块、统计报表模块）中所有业务组件、数据访问组件将部署在中间层App Server上，中间层的性能可以根据具体业务流量，通过配置负载均衡而获得很大的拓展空间。3. Data Tieri. 两台SQL OLTP数据库服务器在Window2003上构建Cluster实现业务系统备份。ii. 为了确保数据查询性能的提高，在SQL OLTP数据服务器上在考虑数据表整合、切分，添加适量数据冗余，构建有效的索引，同时可能需要设计一些Stored Procedure以获得更好的性能。iii. 数据仓库所需的数据同步的任务将通过DTS
11、定期自动完成，以增量更新的方式更新数据报表。由于数据仓库的运算量很大，将占用相当多的CPU资源，因此建议将数据仓库单独一台机器存放，同时定期备份。2.1.3 现行系统设计与原有系统的比较目前新系统的设计可以较好的解决原有系统中存在的问题，我们可以从功能、性能、稳定性、扩展性、可管理性等5个方面来进行比较：原有系统新系统功能1. 是基于Call Based的系统，无法完成对问题的跟踪统计2. 原有系统业务流程设计老化、不能满足新增的业务需求。3. 系统设计较乱，难以二次开发4. 没有完善的知识库和报表分析功能1. 借鉴微软全球Call Center实践经验，实现基于Case Based的系统2.
12、 重新设计整合系统业务流程，能够满足目前新增的业务需求。3. 提供二次开发接口，方便日后升级扩展4. 加入完善的知识库和报表分析功能性能1. 系统并发响应能力较差，在业务处理高峰期无法胜任Call Center 日益增长的业务流量，主要原因是重要模块代码质量存在严重设计问题，由于架构设计时没有考虑足够的扩展性，导致应用模块难于改进。l 中间层应用程序设计不合理，导致通过Web并发访问数据库的性能较差。尤其是程序中数据访问相关的模块，缺乏对Connection的有效管理、Transaction的滥用、盲目使用COM+技术等等。l 数据库设计比较散乱，数据表过多，使程序中不得不生成很多复杂的SQL
13、语句进行跨表查询，严重影响性能。没有使用Stored Procedure来提升数据访问性能。l 系统使用NT4.0 + IIS3.0+Oracle8i1. 能够提供较好的系统响应性能，满足Call Center未来规划的业务流量l 重新设计中间层及数据访问模块，正确使用COM+, Transaction，保证系统的并发性能l 为了确保数据查询性能的提高，必须优化数据库设计。在SQL OLTP数据服务器上在考虑数据表整合、切分，添加适量数据冗余，构建有效的索引，同时可能需要设计一些Stored Procedure以获得更好的性能。l 使用Win2003+IIS6.0+SQL2000，系统性能将会
14、有较大的提升。（如Win2000的整体性能要比NT4.0高出30%, 而SQL2000较Oracle8i在Win2000上快30%左右）稳定性1. 没有完善的系统保障体系和故障恢复机制，无法有效保证业务系统的不间断运转2. 由于没有热备机制，服务器OP1和OP2任何一台机器Crash，都会造成部分业务的瘫痪。3. 操作系统老化，NT4.0目前的两台数据库服务器均运行在NT4.0上。目前的Win2000和2003无论是性能、扩展性还是稳定性都要比NT4.0强很多。1. 有完善的系统保障体系和故障恢复机制，能够保证业务系统的不间断运转2. 有热备机制，两台OLTP服务器单一台节点Crash，都不会
15、造成业务系统的瘫痪。3. 使用目前最先进的Win2003+IIS6.0，系统性能、稳定性和扩展性较NT4.0+IIS6.0均有相当大的提高。扩展性1. 硬件扩展性方面，目前使用的NT4.0 Enterprise 版最多支持4CPU+4GB Mem。2. 软件扩展性方面，没有考虑使用B/S 架构和Network Load Balance 来提高Web Server和整个业务系统的负载能力。3. 业务扩展性方面，由于原有程序设计不尽合理，没有预留开发接口，造成二次开发困难，对进一步改进业务流程造成一定障碍。1. 硬件扩展性方面， Win2000/2003 Advanced Server 支持到8
16、CPU、8 GB Memory。2. 软件扩展性方面，使用B/S 架构和Network Load Balance 来提高Web Server和整个Application Server的负载能力。3. 业务扩展性方面，预留二次开发接口，支持进一步改进业务流程。可管理性1. 现行设计架构为C/S和B/S混杂，管理比较困难。C/S架构在部署及程序升级时带来很多额外工作量，而Call Center 中B/S应用目前的主要问题是由于设计问题导致并发响应性能较差。1. 统一在B/S架构下，中心部署、远程访问。更加便于管理。2. 提供业务主系统、知识库、统计报表的管理模块2.2 系统功能设计根据联想Call
17、 Center的实际需求， CC三期系统可以分为3大模块：业务主模块、知识库模块、报表分析模块。这3大模块在实施阶段具有不同的侧重点：2.2.1 业务主模块业务主模块未来的主要工作如下：1. 全面改造原有业务系统，在实现原有业务流程的同时，需要整合目前新的业务需求，实现从Call Based系统向Case Based系统的转换。核心在于完善的数据库设计，实现Call 和 Case之间多对多的对应关系，实现Case的升级流程，实现对Case跟踪解决。目前联想Call Center的业务模式还是一个Call Based的系统，比较注重对客户问题的直接响应能力，但在后台对同一问题的连续跟踪的能力相对
18、缺乏。我们希望借鉴微软全球支持中心的经验，在未来的Call Center系统中实现 Case Based。这样，可以使每个问题的解决过程，都形成完整的生命周期，方便对问题的跟踪、统计以及相关的处理操作（如提升入知识库、Labor Log的统计、问题的升级、客户满意度调查等）。2. 将目前系统的C/S与B/S混杂的结构，统一整合为B/S结构。将联想的业务系统延伸到公司内部的坐席、工程师、公司其他人员以及联想的代理商和维修站或最终用户，提高系统的易用性和可拓展性。3. 解决好原有系统中存在的设计问题，如中间层架构，性能、并发访问、数据一致性、业务间关联整合等问题。我们将对所有的业务流程进行全面的分
19、析，从系统总体架构进行考虑，力争将这些流程有机的整合在一起，任何对业务流程中实体的抽象都将作为数据实体反映到数据库当中，争取在数据层设计时保证后台数据的一致性，避免人工干预。同时做好业务公用模块的抽取、业务之间通信等设计问题，保证整体架构设计的一致性和扩展性。4. 解决好和其他系统之间的接口（详细需求待明确）Call Center中普通业务流程的实现没有任何技术实现障碍，通过ASP.Net + SQL的方式均可实现。l 对于这些流程中的业务逻辑，我们将统一考虑把它们封装到中间层COM组件当中去。在前端ASP.Net中调用这些组件暴露出来的接口和方法，业务组件再调用数据处理组件实现对后台数据的存
20、取。任何未来流程的改变或增加，将只影响到中间层的部分业务组件接口。2.2.2 知识库模块知识库作为Call Center的重要模块，实际上是Call Center的内部知识积累体系。通过逐步积累复杂问题的解决方案，为Call Center的咨询人员提供强大的技术资源支持，加快问题解决速度，提高工作人员的技术水平。我们将充分借鉴微软内部知识库体系，为联想Call Center建立一个完善的知识库体系，知识库服务器构架在Windows 2003 + IIS 6.0 + SQL 2000 + ASP.NET的平台上，使用目前最先进的数据库和开发技术，为稳定性、高可用性奠定基础。以下是对知识库模块的功
21、能设计介绍和技术难点分析。2.2.2.1 知识库文档的来源1. 业务技术经验总结a) 当技术人员觉得某一个业务或技术问题有值得别人借鉴的地方，它可以把这问题以及解决的方法写成个“想法”并提交，由知识库管理人员进行规范整理。b) 技术人员可以把别人公共的想法或者自己的私人想法撰写成一知识库文档，提交进入审阅流程。2. 权威技术文档a) 知识库管理人员可以将公开的权威文档按照知识库文档的规范进行整理入库。3. 历史支持事件a) 所有的支持事件都将复制到知识库的数据库中，有价值的Case可以经审批后正式发布。支持工程师可以搜索以前的支持事件以获得以前工程师的经验，即便以前的问题没有被解决。4. 服务
22、政策信息和产品信息（如产品配置、报价、条码、驱动程序链接）a) 知识库管理人员可以公司内部的服务政策信息按照知识库文档的规范进行整理入库。5. 其它信息a) 对于需要外挂的其他信息，需要按照知识库文档规范整理对应的链接文档，以便于日后查询，或将其他信息导入到知识库当中。2.2.2.2 知识库文档的编辑规范1. 文档命名规范知识文档的命名必须按照严格要求命名：问题ID + 问题属性关键字+问题描述关键字（通过这些关键字可以了解问题的大致内容），如l Q: 问题l HowTo:如何做l Info: 信息2. 文档内容格式模板针对不同属性的知识库文档需要有确定的模版，如以下是问题文档的模版。标题ID
23、 + 创建时间保密级别 （Public, Internal Only, Confidential）应用范畴问题概述问题复现步骤解决方案相关链接作者 3. 文档内容需要使用规范的语法、词汇、句法，同时对专业词汇标准用法根据企业自身业务应用的特点应有明确的指导。2.2.2.3 知识库文档审批流程知识库文档在提交到知识库管理系统后，需要进行多层审核以确保文档的完整和正确：1. 技术审核专门技术审核人员检查所有待审核的文档。技术审核包括： 是否技术正确、完整 是否有价值 是否重复如果技术审核通过，就提交。不通过，就返回给作者。2. 编辑审核专门的编辑人员检查： 语法、词汇、句法 专业词汇标准用法 格式
24、编排如果编辑审核通过，就提交。有问题，就咨询作者。3. 文档的发布审核编辑审核通过，技术文档经理发布文档： 确认发布级别（公开、合作伙伴、内部） 确认没有商业、法律问题内容2.2.2.4 知识库的管理体系1. 知识库文档的存储l 文档的内容、及其他文档属性将统一存放在数据库当中。2. 知识库文档的级别、属性、分类、IDl 文档可以有多种分类的级别，按照保密程度(Public、Internal、Confidential)、按照技术深度(High, Media, Low)3. 知识库文档的版本更新l 当文档发布后，会有一些考虑不够全面的地方以及错误的地方。文档需要有被更新的可能。问题发现的可能有：
25、i. 最终用户发现问题，在网上提交建议ii. 通过邮件提交建议iii. 内部员工发现问题。l 知识库文档的版本更新需要由具备权限的管理员进行操作，在原有文档仍然生效的情况下，不建议覆盖原有文档，一般采用生成新文档的方式，在文档内部加入相关文档的引用链接。4. 知识库文档的引用分析l 知识库文档的引用次数将作为文档价值的重要参考指标，可以导入到数据仓库当中进行进一步分析，5. 知识库的权限管理建立知识库的安全管理机制，对于管理员、审核员、用户等若干角色的权限需要进行明确的划分。可以考虑结合Win2000 AD进行统一帐号管理和权限控制。如果没有Windows AD的配合，那么对于这些用户的管理将
26、通过数据库来进行。l 使用者的功能局限于对知识库的查询、技术文档和反馈的提交l 管理者（包括管理员、审核员）将能够对文档进行审批、修改入库，管理员还能够对知识库进行全面的操作。管理者的操作将记入日志。2.2.2.5 对知识库的查询引用1. 知识库查询和内容展示界面将统一在Web框架内，所有人员均可通过浏览器进行远程查询。2. 查询方式可以按标题、内容、类别、属性、ID等进行查找，支持组合查询。对于返回结果集较大时，将通过分页显示。3. 后台基于SQL2000的全文检索功能，可以实现自动按RANK排序，增量更新，无需复杂人工维护工作。2.2.2.6 基于知识库的故障树的技术实现我们将提供管理界面
27、供管理人员在后台生成故障树，前端用户通过浏览器在故障树中漫游。故障树的实现是知识库中的一个技术难点，既要考虑编辑的方便、易用，各个结点内容的灵活表述，又要考虑树型数据和二维表数据之间转换时的性能问题。故障树的结构如下图：在数据库中将存储为二维父子表的方式，下图为意会图：IDParentIDContentRootNullOption1RootOption2RootOption3RootAnswer1Option1Answer2Option1EndAnswer1.若要每次从数据库父子表中动态生成树型XML，其性能将非常低下。为此我们考虑将采用XML缓存的方式，每次在故障树编辑好之后，在将步骤存入数
28、据库的同时，缓存一份对应的XML，这样可以大大提高故障树显示的性能。XML 在存储数据量过大时仍然存在性能问题，因此在XML文档中我们仅缓存ID，对于每个节点的具体内容将从数据库中抽取，这种设计方案将极大的减少XML数据量，提高分析查询性能。2.2.3 统计报表分析模块2.2.3.1 综述统计报表模块将是展示分析Call Center业务系统运行情况的窗口，除了对现有数据进行业务分析、人员评估之外，也为将来的进一步的决策及业务调整提供一定的数据支持。整体架构仍然采用B/S 架构设计：l 后端用以作统计分析的数据将从基于SQL2000 OLAP从关系型数据库和其他数据源中抽取构建l 前端展示将使
29、用OWC中的PivotTable数据透视表在浏览器中予以展现。l 通过对浏览用户的角色定义及权限分级，实现对不同级别用户的统计报告展示。具体实现目标是通过分阶段的开发，逐步实现对整个Call Center系统的运维情况的统计汇总，其中比较典型的是：l 业务相关报表1. 对团队及人员工作量以及效率报表2. 客户满意度的评估报表3. 对产品问题反馈的统计4. 对客户地域行业的分析报表5. 业务流量分析6. 外拨问卷结果统计报表7. 维修单满意度回访统计报表8. 重复来电统计报表等等l 知识库相关报表a) 知识库维护及时性报表、常用问题报表b) 文章作者统计报表（可以得到个人发表文章数量、质量评价、
30、星级评价、信息利用率等）l 质量监控与绩效信息报表l 话务相关报表a) 队列（SESSION）报表、队列（SEGEMENT）报表b) 话务代表接话量和工作效率报表c) IVR调查满意度报表d) IVR放弃率统计报表e) IVR节点分析统计报表2.2.3.2 技术实现技术实现分为3个步骤：1. 分析联想Call Center业务统计查询需求，构建核心数据仓库，具体数据将可以通过SQL DTS从各种异类数据源的导入(如SQLSERVER，Oracle, DB2, Infomix, Sybase，ACCESS，EXCEL，文本文件等)。DTS在数据传输过程中，支持数据的过滤、转换和数据整合。在转换过
31、程中消除数据冗余，保证数据一致性。同时DTS支持图形化设计、编程、定时触发等多种功能。2. 基于SQL OLAP数据仓库，设计构建相应的Cube，并定期进行增量更新3. 通过 Web客户端OWC控件展示基于后台数据生成的各种统计报表4. 可以通过Excel 直接联接OLAP数据仓库生成报表，并进行发送。2.2.3.3 技术平台技术平台将采用SQL2000中提供的Analysis Service。在前端浏览器中嵌入PivotTable(数据透视表)进行数据报表展示、同时允许用户通过Excel 直接编辑特定报表。u 在SQL 2000中已经直接集成了微软数据仓库软件，无需单独购买。同时微软的数据仓
32、库具备很强的技术优势。u 性能优越：世界上最大的数据仓库之一T3（1200GB数据量），就是基于SQL2000来构建的 T3 模型环境(1200 GB 数据) SQL Server 2000 Microsoft Windows 2000 Data Center Unisys ES7000 servers(32 PIII Xeon 700MHz processors) EMC Enterprise Storage T3性能指标 微软通过商业数据提供商获取了40GB的数据，这些数据是716，252种产品、133，003种品牌在全球71个市场的5年的销售数据。 在这40GB数据的基础上，我们派生出了
33、1.2TB的数据。存放在微软数据仓库中，共有77亿条记录。 为了作进一步的数据分析，我们创建了一个471GB的聚合立方体。(77亿条记录第一次全部生成立方体需要53 小时，平均4万条记录/每秒)。 性能测试结果：基于50个并发用户，每个用户发出27条各不相同的查询语句。这样每次共有1350条完全不同的查询。每条查询在Warm Cache的平均响应时间为0.02秒，在Cold Cache的平均响应时间为0.08秒u 提供目前世界上最强大的数据收集传输工具DTS 支持各种异类数据源的导入(如Oracle, DB2, Infomix, Sybase等等，甚至是文本文件的数据都可以通过DTS导入到SQ
34、L2000当中)。提供100%的数据源支持。 数据转换、整合功能强大n 在数据传输过程中，支持数据的过滤、转换、和数据整合。在转换过程中消除数据冗余，保证数据一致性。n 对于用户的特定需求，如复杂逻辑的数据转换规则，可以在DTS中嵌入ActiveX Script实现这些需求。 操作管理方便易行，通过一次性定制DTS Package， 通过SQL Agent 可以定期执行，实现了自动化管理，避免了大量的手工操作。u 可以根据用户的需要，提供3种灵活的数据存储和管理方式MOLAP，HOLAP，ROLAP。帮助用户在性能和存储量之间找到平衡点 熟悉了解OLAP的人都知道，如何平衡数据存储空间和查询效
35、率是一般的数据仓库非常头疼的问题。原始数据加载到数据仓库的同时需要做一定的优化，这会降低一些存储量。而在数据仓库中的数据由于需要作一定的聚合，聚合产生的立方体会占用相当的存储空间。一般情况下，聚合度越高占用空间越多，而查询性能越好，两者成反比。但这仅仅是相对而言的，随着聚合立方体的不断加大，对于它的处理时间也会变长而影响性能。因此，凡事有度，聚合度的大小需要有适当的比例，过多的聚合可能不仅对查询没有帮助，反而会降低查询性能。 而在这一点上，微软恰恰提供了很好的估算工具和最为灵活的存储方式。20%的聚合提供80%的性能，用户可以根据自己的应用灵活定制采用MOLAP, HOLAP 还是ROLAP。
36、u 提供目前同类产品中最为强大的图表功能 与Office 紧密集成，通过Pivot Table Service直接可以把数据报表导出到Excel中生成直观图表。 通过Office OWC控件可以将这些复杂的数据报表方便地嵌入到浏览器中，实现Web 查询。u 对于雪花型维表设计的支持 大家知道一般数据仓库设计都推荐采用星型结构来设计OLAP数据库，不推荐雪花型结构。原因主要是雪花型数据仓库的查询经常需要大量的跨表查询，性能比较低下。 但是现实并非如此理想，许多用户的应用非常复杂，无法抽象成简单的星型结构，而只能采用雪花型结构。 采用微软的数据仓库可以有效的解决上述矛盾。由于MOLAP的特殊存储结
37、构，它可以有效的支持雪花型结构的维表设计而不会像普通数据仓库那样影响性能。在满足用户的设计需求的情况下，保证查询效率。u 自动化处理过程，可以定制数据传输，Cube 生成的全过程，利用SQL Agent可以实现完全自动化的流程操作u 提供行之有效的数据挖掘方法，不仅可以通过界面操作实现，还可以通过对DSO对象的调用在程序中快捷实现 MS Clustering MS Decision Treeu 支持企业级的大型数据仓库应用 支持分布式分区Cube，提高查询效率 对于特殊维表设计的支持，如对父子结构，结构残缺的等不规则维的支持等等。 对于大型维表(超过1千万行的维表)的支持和优化 支持虚拟维，虚
38、拟Cube，有效降低数据存储量的同时，增加了用户应用的灵活性。 支持Calculated Member， 方便计算百分比、换算率等OLAP常用应用。 具备相应的安全性，访问角色的管理。u 提供MDX多维查询语言支持对多维数据的查询和分析u 便利的开发接口和控件 微软数据仓库所提供的开发接口和控件是目前业界所用数据仓库产品当中最全面和最方便的。几乎所有的图形管理界面功能都可以通过调用相应控件在程序中快捷实现。同时，用户可以通过Pivottable，或DSO以及ADOMD迅速实现对数据的抽取和挖掘。u 安装维护非常方便 简单方便的图形界面安装和管理 提供有效的数据备份恢复机制2.3 数据流程图设计
39、2.4 本系统与相关系统的集成/互连根据目前联想CC三期的业务需求，需要和多个内部系统（如话务系统、录音监控系统、传真发送系统、邮件系统、短信平台等）进行集成互连。集成方式主要有数据集成和消息传送两种：1. 数据集成a) 数据收集数据收集方式主要通过SQL DTS收集各种异类数据，主要工作在于分析其他系统的数据结构，按照自身系统的需求设计数据传输流程，做好数据整合、确保数据一致性。b) 数据共享对于业务主系统中的数据可以通过数据共享或复制的方式提供给其它系统。2. 消息传送a) 按照其他系统需求生成数据消息，提供给其他系统（如邮件、传真、短信）具体需要参考各个相关系统的实际情况进行设计。1.
40、与呼叫中心话务系统的集成i. 呼叫中心话务系统目前采用CTI系统（APROPOS 5.0产品），该产品提供了外部开发接口，可以通过该接口的开发，实现CC业务系统和话务系统的集成，保证既有各类电话功能及CTI系统功能，并且不影响CALLCENTER 话务系统的性能和稳定性。ii. 如果需要将话务系统的数据信息的集成到数据仓库中进行整合，需要对CTI系统（APROPOS产品）数据库进行分析，在确保明确CTI系统内部数据结构后再进行。2. 与录音监控系统的集成i. 要实现和录音监控系统集成，保证录音监控功能以及质量监控流程的实现, 需要分析录音监控系统的数据结构，并进一步明确详细需求。3. 与传真发
41、送系统的集成i. 通过传真方式实现系统中若干通知功能（如维修单通知功能），系统可以参考目前业务系统已实现的功能，进行进一步集成迁移。4. 与公司邮件系统的集成i. 在该系统中需要使用到邮件通知功能（如维修单通知功能、升级问题邮件通知功能等）。因此该系统需要与公司邮件系统实现全面无缝集成，保证邮件通知功能实现。具体实现在Server端实现消息触发，之后按照生成邮件发送到公司的Notes邮件系统。5. 与短信信息平台的集成i. 在该项目中如果要建立短信信息服务平台，实现短信的收发功能（如实现维修单短信通知功能），需要有额外的设计开发工作量。具体需要按照电信互联网短信网关接口协议2.0标准进行开发，
42、在Call Center业务系统中实现短信编辑，通过短信网关接口发送。ii. 联想需要和相关电信部门达成建设短信平台的协议。6. 与公司其他系统的接口i. 对于与公司其他系统的接口，（如公司产品信息（装箱单和BOM信息）的集成，与联想商机报备系统、CRM、ERP、SCM、PDM、销售电子商务、维修费结算系统、站端MIS），需要分析明确实际需求后再行估算设计开发工作量，目前无法尚计入项目开发进度。2.5 软、硬件分析选型（软件、服务器、网络）2.5.1 软件选型分析总体软件方案将采用Win2003+SQL2000+IIS6.0的方式1. Web 表现层Web表现层具体开发将采用ASP.Net取代
43、原有的ASP Script开发方式，动态Web页面的开发效率、灵活性、友好性也会有很大的提高。同时Web页面在编译后性能较ASP可以提高3倍以上。具体性能指标如下：同时ASP.Net 在与JSP的比较当中，实现相同的功能ASP.Net只需要1/3左右的代码量，大大降低了开发工作量。根据MiddleWare的Benchmark测试结果，.Net在并发访问，系统总体响应能力等关键性能指标上全面胜出。（具体可以参见http:/www.middleware-2. 中间层采用.Net Serviced Component 开发中间层业务组件，在Win2003中的Application Sever当中提供
44、的IIS, COM+, UDDI, MSMQ系列服务能够较好的支持企业级应用对Transaction、Pooling、Messaging的支持。3. 数据层针对联想Call Center数据库设计比较散乱、数据表过多等实际情况。我们将在明确业务流程和需求之后，对数据库结构进行重新设计。从系统性能、可维护性、成本以及架构设计角度考虑，我们建议使用Win2003+SQL2000替代目前的WinNT4.0 + Oracle 8i的解决方案。主要原因如下：l 在Win2000平台上同样硬件环境下的性能测试表明SQL2000要比Oracle8i快30%左右。采用Win2003+SQL2000可以获得更好
45、的系统性能。l 目前联想Call Center方案中虽然是双节点运行，但是通过Oracle OPS并没有实现业务系统备份方案，任何一个节点的Down机都会造成部分业务系统的瘫痪。使用SQL2000在Win2003上构建Cluster可以实现对业务系统的备份及负载均衡。l 考虑到联想Call Center 要实现统计报表的功能，由于对实时数据库进行统计分析会占用非常多的系统资源，影响系统性能。建议最好采用数据仓库技术，而SQL2000中已经带有数据仓库的功能，不再需要额外的投资购买。l 考虑到对于CC三期当中知识库中的全文检索，我们可以充分利用SQL 2000自带的FullText Search
46、功能直接集成，无需另行购买全文检索引擎。l 从架构设计角度考虑，由于中间层和Web Server运行在Win2003服务器上，采用ASP.Net开发，数据库采用微软产品的可以获得更好的兼容性和性能。l Oracle升级成本比较昂贵，比较之下SQL2000的成本要少一些。可以说SQL在性能价格比上占有一定的优势。l 从实现角度考虑，微软开发人员对SQL 非常熟悉，可以利用其中很多设计技巧提高系统整体性能。由于原有系统的数据库中没有使用Stored Procedure，所以数据库迁移非常方便。2.5.2 硬件选型建议l 系统网络结构拓扑l 机型建议l 机器配置建议服务器名称数量CPU配置内存配置硬盘配置NLB/应用服务器22 CPU 1G+ Hz1G40GOLTP服务器28 CPU 1.6G+ Hz8GRAID 40GX5OLAP服务器14 CPU 1.6G+ Hz2
