呼叫中心新平台项目进度计划研究.docx

目 录引 言11 项目概述21.1 项目简介21.2 需求阐述21.3 开发技术概述31.4 本文的组织安排32 项目进度计划42.1 项目工期42.2 项目计划分析42.2.1 工程师进场42.2.2 平台搭建42.2.3 先期商定的需求开发42.2.4 剩余需求开发42.2.5 ob组使用培训42.2.6 ob组进入商路通平台测试42.2.7 网订组使用培训52.2.8 网订组进入商路通平台测试52.2.9 测试组数据校对52.2.10 ib组使用培训52.2.11 sbd分批迁入商路通新平台52.2.12 sbd部门级报表数据校对52.2.13 contract商路通平台使用培训、迁入52.2.14 gov及其他剩余部门商路通平台使用培训、迁入52.2.15 所有部门报表数据校对52.2.16 报表校对完成，软件功能确认，验收52.3 项目资源在整体进度中的职责63 实施过程中遇到的问题分析73.1 对于商路通方面的控制73.2 对于业务部门需求量和软件上线后bug量估计的不足73.2.1 对于业务部门需求调研的不彻底73.2.2 对于商路通软件和报表的bug量估计不足73.3 对于报表校对以及修改时间的估计的不足73.3.1 报表列项目与业务部门自身要求不符73.3.2 报表算法规则与业务部门要求不符83.3.3 后期修改报表，重新验证数据准确性时间的估计不足83.4 对于后期软件实施、安装、培训耗时上估计的不足83.5 项目进度延期点83.5.1 剩余需求开发（延期1周）83.5.2 测试组数据校对及修改、重新校准报表（延期1周）83.5.3 部门级报表数据校对（延期1周）83.5.4 contract部门迁入新平台（延期1周）83.5.5 所有报表数据校对、软件功能确认（延期4周）84 结合课程和实际思考如何优化进度94.1 基于项目不确定性对于项目总体工期的合理预估94.2 项目管理的3个目标在此次项目中的体现和缺失94.3 项目计划94.4 项目的检测和控制95 项目总结11参考文献12引 言随着本公司（staples以下简称史泰博）业务的日渐增长，在2006年上线的老的呼叫中心cti，录音，报表系统已经无法满足如：sbd（small and medium department，中小客户部）、contract（合约企业客户部）、as（after-sales售后服务部）等等各个部门的需求，日益增长的呼叫量对系统产生的压力越来越高，同时并发的录音数量也在增多，相应的报表的计算量也有很大的提升，由上海ds通信技术有限公司设计的呼叫中心系统已经无法满足这些底层需求。所以在公司clt（china leader team中国领导团队）的授意下，it部门会同几个呼叫中心使用人数最多的业务部门开始进行了新呼叫中心系统的选择、实施计划。新的呼叫中心必须满足更大的同时在线呼叫处理，更大的并发录音通道数，更好的稳定性，更加准确的数据记录和报表统计等需求。在此基础上，经过多方比较，以及基于预算控制的需要，公司最终选择了北京商路通信息技术有限公司的hi-link呼叫中心系统为新平台来运行呼叫中心业务。本文旨在就合同签订后开始筹划项目到项目收尾，验收过程中产生的一些关于项目资源，需求，进度方面的问题展开讨论，结合课程所学知识，以期找到解决问题的一些新方法。121 项目概述1.1 项目简介本项目期望在不影响现有老呼叫中心平台（以下简称ds平台）的基础上，成功搭建新呼叫中心平台（以下简称商路通平台），并且将在ds平台上的话务人员逐步按批次地迁移至商路通平台上，继续保留ds平台至业务部门无数据方面的调取要求为止。本项目参与人员有：本人（以下简称z），商路通工程师（以下简称g），it部维护员l和r，以及业务部门对口人w和s。1.2 需求阐述a) 需要实现的基本功能1. 基本电话功能2. 数据和报表3. 录音4. 监控、监听、组长控制5. 权限控制6. 数据冗余7. cti双机热备8. 报表自定义修改9. 深圳呼叫中心作为远端模块，上海作为数据和管理中心10. 售后服务b) 需要实现的进阶功能1. 其他关键服务器和硬件的冷备2. 预留与salesforce的crm软件整合的能力与相应功能c) 经过和业务部门确认的新增需求1. 软电话客户端朝指定本机端口发送来电号码以供查询客户信息2. 软电话界面上作未接电话列表显示3. 通过语音宣告板引导客户进入的电话详细信息出报表4. 系统看护告警，看护程序重启了服务之后，通过邮件方式自动发送到指定人员5. 根据预定的模板定时自动生成报表，然后通过邮件的方式发送到指定人员。6. 按照主叫号码分配电话到不同的坐席7. 关于商路通软电话登陆和使用中的问题1.3 开发技术概述商路通平台基于.net 2005环境开发，数据库基于sql2005，实施较为简便。1.4 本文的组织安排为了阐明软件开发的过程中的主要问题，本论文分为五章，分别简要介绍如下：(1)介绍本项目的目的，参与人员，以及需求。(2) 介绍本项目的计划制定内容。(3) 介绍了本项目进行过程中遇到的问题。(4) 结合课程思考如何优化进度，避免项目延期。(5) 结论。(6) 参考文献。2 项目进度计划2.1 项目工期由于此项目合同签订时间为2011.7.6，所以实际的项目开始时间点为2011.7.11下面是实际项目工期表：2.2 项目计划分析2.2.1 工程师进场此项目的合同签订双方staples办公地点在上海，商路通公司总部和开发工程师都在北京，上海这边有实施，维护，售后工程师常驻，所以此项目留有1周的时间来给供应商指定项目经理，派出人员到达staples。2.2.2 平台搭建考虑到北京到上海的方式大多为飞机，所以在第一周的时间内，根据商路通工程师前期对于平台搭建时间的估算，将平台搭建的时间也包含在了其中，并且一直延续到了项目第六周。2.2.3 先期商定的需求开发从第一周到第三周，是合同中确定的需求文档的a和b的开发时间，在这个周期内将大多数基础需求根据本公司业务部门的需求开发测试完毕。2.2.4 剩余需求开发从第四周到第七周，是剩余的需求的开发时间，在这个周期内将剩余部分的需求根据本公司业务部门的需求开发测试完毕。2.2.5 ob组使用培训根据项目实际测试需要，需要先行迁入一个小组进行实际测试，本公司ob（out bound呼出）团队的每个小组都独立核算业绩和报表，小组人数也不多（一般在10人以内），符合实际测试的风险、安全性要求，而ib（in bound呼入）团队由于人数多，一旦出现问题无法及时迁移回ds平台，所以不符合测试需要。2.2.6 ob组进入商路通平台测试通过这个测试过程，发现一些软件在呼出功能使用上的问题和不足，供商路通开发人员及时修改代码，优化软件，修正报表。2.2.7 网订组使用培训由于ob团队已经有一个小组先期进入测试了这个平台呼出方面的功能，下面就需要有一个团队来测试呼入功能，网订团队人数也在10人左右，符合风险控制和安全性的需要。2.2.8 网订组进入商路通平台测试通过这个测试过程，发现一些软件在呼入功能使用上的问题和不足，供商路通开发人员及时修改代码，优化软件，修正报表。2.2.9 测试组数据校对经过先期测试，已经积累了大量的测试数据，在先期测试过程中，要求两个测试组均在呼入呼出过程中将来电号码，时间等关键信息手工记录下来，在六到七周的周期内，将手工记录的报表和系统记录的明细进行比对，修正报表相关数据。2.2.10 ib组使用培训在先期两个测试组进入测试以及完善软件功能和校准了数据之后，可以让ib团队进入进行大规模呼入测试。2.2.11 sbd分批迁入商路通新平台由于sbd部门除了ib，ob，网订团队之外，还有其他很多团队，所以必须分批迁入以分散风险，便于在发生意外时回退。2.2.12 sbd部门级报表数据校对在sbd整个部门迁入并且使用一段时间之后，将核对整个部门的报表计算规则和报表数据的准确性，因为个人统计，组统计，部门统计并不是简单的累计过程，由个人到组，组到部门的统计换算规则非常复杂，这个将在随后的章节中详细讨论，因为这一点对项目进度的影响尤其大。2.2.13 contract商路通平台使用培训、迁入在sbd整个部门测试完成后，将轮到contract部门整体分批迁入。2.2.14 gov及其他剩余部门商路通平台使用培训、迁入在contract整个部门测试完成后，将轮到gov和其他剩余部门整体分批迁入。2.2.15 所有部门报表数据校对在所有部门迁入并且使用一段时间之后，将收集数据进行报表的校对。2.2.16 报表校对完成，软件功能确认，验收在报表项目，数据校对无误，软件功能确认后，进行项目的验收工作。2.3 项目资源在整体进度中的职责(1) 作为史泰博方项目经理，z将全程参与整个项目，并且随时更新项目信息到项目组成员，并且向it总监和个部门总监定期约会报告项目情况。(2) 作为商路通方项目经理，工程师g也将全程参与项目，并且会同z和业务部门对口人在项目过程中确认需求，修改软件和报表以达到业务部门要求。(3) 作为项目对口人，s和w将负责收集部门中的小组和个人在测试过程中发现的问题和对软件改进的需求，整理后交由z来集体讨论决定是否反映到开发人员处修改。(4) it部l和r将协助z和g，在业务部门迁入商路通平台时，在业务话务员电脑上安装新的软电话系统客户端和报表、监控程序。3 实施过程中遇到的问题分析3.1 对于商路通方面的控制(1) 对于商路通工程师g以及开发人员的控制由于z自身需要处理日常工作以及公司内部其他的事务，所以导致不能完全投入在此项目中全程监控g和开发人员的行为。(2) 和商路通北京开发总部的沟通问题由于商路通北京开发总部的理念问题，坚持在报表系统结构和算法原理，数据库，表结构，存储过程上的自我标准，导致无法适应本公司的业务部门需求。3.2 对于业务部门需求量和软件上线后bug量估计的不足3.2.1 对于业务部门需求调研的不彻底由于业务部门并没有使用过商路通新平台，所以无法在使用后提出相应的需求变更，导致合同签订时确认的需求量和后期实际需求量大相径庭。3.2.2 对于商路通软件和报表的bug量估计不足由于对于商路通软件和报表系统的不熟悉，导致在软件落地的过程中产生了诸多由于需求不够明确带来的问题。 3.3 对于报表校对以及修改时间的估计的不足3.3.1 报表列项目与业务部门自身要求不符在先期需求确认过程中，各个业务部门都是在基于ds平台的报表功能的基础上提出的需求，这些需求并不是完全和商路通平台的报表系统契合，可能有些想法完全不同，导致一些具体需求无法实现，在沟通上花去了很多时间，例如月度报表的统计，老的平台是利用每天的数据生成中间结转表，当客户需要统计月度数据时，系统自动根据开始结束日期统计中间表得出结果，这个方式较直接从明细表中统计整月数据快得多，而且对系统资源消耗也少得多，但是老平台这种算法存在一定的漏洞，月度报表的数据准确性得不到保障，而新的平台虽然数据准确性没有问题，但是很有可能因为数据量太大而在导出一个月的报表过程中sql time out导致出错，无法显示月度报表。3.3.2 报表算法规则与业务部门要求不符由于业务部门已经长期使用老系统，所以各种报表统计规则都是在老系统的基础上给出的，而商路通平台报表系统是一套成熟的解决方案，在应用到我公司的环境时，由于呼叫中心结构的大不相同，导致一些行业默认的报表算法在我公司无法得到业务部门的认同，无法作为kpi的依据。例如对于组内转接，行业认定的算法是不管产生多少次转接，对于此组来说都算是一次呼叫，而业务部门却要求将其按照转接次数来统计到组应答数上，这就要求商路通在首先对呼叫明细进行一次统计后，算出组的去重应答数，再加上所有的转接数，得出提交到管理层审阅的组应答数。3.3.3 后期修改报表，重新验证数据准确性时间的估计不足由于报表结构和内容定义不是很符合业务部门需求，修改上花去了太多的时间，二次验证花费的时间要远超预期。3.4 对于后期软件实施、安装、培训耗时上估计的不足由于内部使用新系统人员并不仅仅是常驻公司的话务人员，同时也有很多销售人员，他们大多使用的是笔记本，而且经常外出，这就对批量迁入，使用新系统的总时间造成了一定的影响。而且由于部分笔记本购买时未经分区，只有一个c分区，无法安装默认到d分区的软电话客户端，这一批人的电脑增加分区也花了相当长的时间。3.5 项目进度延期点3.5.1 剩余需求开发（延期1周）3.5.2 测试组数据校对及修改、重新校准报表（延期1周）3.5.3 部门级报表数据校对（延期1周）3.5.4 contract部门迁入新平台（延期1周）3.5.5 所有报表数据校对、软件功能确认（延期4周）l 项目总体延期：2月l 项目实际验收日期：2012年1月6日4 结合课程和实际思考如何优化进度4.1 基于项目不确定性对于项目总体工期的合理预估根据这次项目的经验，我了解到，多种环境变量，客户的反复无常，项目是否能达到预期效果，这些都是项目中的不确定因素，尽管我们可以采取一些行动来减少不确定性，但是这是无论如何也无法彻底消除的，所以在项目工期预估的时候必须充分考虑到这些情况，在合理的范围内，给项目各个节点留出合理的时间，以避免实际完工日期和理论估计相差太大的情况。4.2 项目管理的3个目标在此次项目中的体现和缺失在项目的执行过程中，要时刻用3个目标来衡量，是否按时，或者提前完成？是否高于或者低于预算？是否符合预先约定的要求？在此次项目中，每一个环节都最好要安排一个确认点来检查项目是否按时完成，如果没有，是什么原因导致的，然后及时总结以反馈到下一个环节中去，不断地动态的调整以达到合理进度，在合同商定时，应该于业务部门确认需求变更的范围和时间点，以避免重复不断地需求变更和范围扩大导致的项目延期，并且在资源分配上充分考虑到各个环节的空闲和忙的时间，合理调配，达到统筹规划的效果，避免发生一个环节卡住导致后续无法进行的情况。4.3 项目计划在制定项目计划的过程中，要充分考虑到项目的可行性，发生意外的处理方案，以及沟通方式和项目的9个要素，在我这次项目中，对潜在问题的准备不足，目标说明不够清楚，导致发生延期后相关后续活动停止，进入等待状态，而且在发生需求冲突，需求变更时，由于合同中确立的需求内容与实际相差较远，导致后期花了大量时间在修改软件和报表上，所以需求的准确性直接影响到了项目整体规划和后期实施的进度，在以后的项目中，先期需求的准确性将是我特别需要注重的。同时，可以利用微软的project软件来进行项目管控，以达到按期交付。4.4 项目的检测和控制管理一个项目包括不间断的对需要做的工作进行计划，检查进度，将进度与计划进行比较，采取纠偏措施使进度与计划保持一致，如果与实际不符，还要重新计划，在此次项目中，我并没有做到随时检查项目进度，而是每隔1周检查一次，这样没有及时地采取纠偏措施，让项目因为一个个问题导致延期时间越来越长，我过多的把时间投入在了项目的需求重新确认、实施上，而忽略了进度检测，所以可以利用msp的甘特图来监测项目进展，在项目发生变更后，跟踪甘特图以更新，以反映变更的情况。从而及时地采取措施。而在项目进行中，合理的控制业务部门的需求量也是我这次项目的一个不足之处，项目控制的目的就是减少计划和实际之间的差异，在大型项目中，如果没有好的控制流程，很容易就会让项目慢慢失去控制，在公司不断发展、在