客户接触管理系统项目总结

议程
项目总体情况
经典业务场景推介
项目组成员与职责分工
项目进度情况与工作量统计分析
项目大事记
与公司其它部门配合情况
项目风险管理
项目管理经验教训
项目可共享技术与模块

 

项目总体情况
系统业务：
通过渠道协同业务模式的建立，把现有的用户接触的各种渠道资源整合起来，利用营销活动和提高服务质量等方式，把客服中心从传统的成本中心向能够间接产生经营效益的虚拟利润中心进行全面的转变。
系统功能：
建立一个客户接触数据的统一存储平台。
建立一套基于规则的频次管理、渠道布放、信息Push的规则引擎平台，使得传统的手工（半自动）分析及营销控制向自动化方向转变。
建立各渠道间联动的统一界面平台，使得各渠道通过统一的界面和客户进行接触。
建立比较完善的分析应用平台。
客户组成&特点：
一线客服代表:
使用营销客户端，对客户进行产品营销、信息收集、问卷调查等。
科室班组管理人员:
使用后台系统，通过对一线客服代表的营销监视，制定控制阀值来控制营销的客服代表人数。实现闲时做营销，忙时做服务的工作模式。
分析人员和数据管理人员:
使用后台系统，通过对执行项目收集的业务数据进行分析，生产自定义的报表，同时设置客户信息方便客服代表进行营销和提高营销成功率。
系统管理人员:
使用后台系统，管理系统运行参数和系统用户等。

经典业务场景推介
产品营销
假如客服中心需要进行产品营销活动。那么可以通过系统在后台制定活动内容之后，并触发上线，这样客服代表接触到目标客户来电后根据一定的控制阀即可进行相应的产品营销，活动过程中随时可以查询客服代表的营销明细和统计该活动的相关报表，包括对客服代表的考核报表、项目资源报表等。
信息收集&问卷调查
假如客服中心的各个科室需要分别地进行客户信息收集（/问卷调查）活动。那么可以通过系统在后台制定活动内容之后，并触发上线，这样客服代表接触到目标客户来电后即可进行信息的收集（/问卷的调查），活动过程中随时可以查询客服代表的工作明细和统计该活动的相关报表，包括对客服代表的考核报表等。

 

项目组成员与职责分工
zhxx：
项目骨干成员，主要负责大模块开发、现场维护、用户培训和接口联调工作，协助参与项目例会，需求调研等客户沟通工作。
wxx： （后期加入）
项目骨干成员，负责大模块开发，文档编写工作。
zxx： （后期加入）
项目成员，负责小模块开发，协助完善相关文档。
Lxx：
项目经理，技术经理，适当担当模块开发等工作。

       目前的职责分工严格来说并不十分合理，前期人力资源未能及时到位，故项目经理也担当了部分编码工作。

 

项目进度情况
项目进度：
（延迟）需求调研阶段（项目进度的第五周），开始出现10个工作日的延迟，原因是报表功能的需求客户方一直无法达成一致意见，对个别字段的定义无法解释清楚。
（延迟）需求实现阶段（项目进度的第十二周），开始出现5个工作日的延迟，原因是由于报表的实现方式比原计划的方案较为复杂，实现难度较高。
（提前）需求实现阶段（项目进度的第六周），由于部分需求的调研工作暂时无法进行下去，故提前一周的时间进入编码实现阶段。
      
       虽然出现过15个工作日的偏差，但是经过项目组成员的努力，整体上来说，项目进度基本按照原计划执行，并没有出现大幅度偏差；对此，项目组成员也出现特定时段加班比较严重的现象。

 

工作量统计分析工作量统计：

     至项目初验为止，项目总耗工作量为2477人时，占考核工作量的78％； 

     总体来说，项目工作量控制的还是比较好的。我觉得主要原因有：

1、项目组成员的工作效率有所提高，不论是对编码实现，还是故障修复，完成的时效还是比较高的。同时实现代码的反工比较少。

2、需求调研准备工作比较充分，与客户沟通需求比较全面。

3、项目组成员消耗的无用工比较少。

4、项目组成员的配合度较高，工作热情饱满。

     比较欠缺的也有如下情况：

1、存在编写无用、专业性不够的文档情况。

2、协助客户方处理事务的效率不够理想。（原因是客户方的准备工作不到位）  

 

项目大事记

1、方案实现方式的变更：

系统报表页面展示方式原来考虑的是各个报表以分开的页面来独自实现，在给客户展示之后，客户强烈要求做成自定义的形式（报表的字段、类型、统计维度等均可自行定义），考虑到在原计划的进度上无法完成报表功能，我们尽最大的努力去说服客户以原来的方案实现，无法说服后，也为了提高客户的满意度，在我们跟客户做了充分的沟通，使之理解因此会延迟项目进度时间后，最后实现了功能。

     客户对此的实现效果也很满意。从而也进一步肯定了我们的工作。   

 

2、给客户分配任务，增加客户对项目的压力：

在报表，报告等需求调研过程中，客户曾以自己事务比较繁忙为由要求项目组先提供一个需求。针对这种情况，我们委婉拒绝外并解释清楚拒绝的原由，同时明确该事情对项目的影响，提高客户对项目的参与度和积极性，适当增加客户的压力。 

     适当地增加客户的压力，否则，你不给客户压力，客户就给你压力；你不给客户分配任务，客户就指示你做事噢。

 

3、给客户解释风险：

在系统策划阶段，当提到项目的风险时，客户有些茫然，并且提问“风险”的概念，愕然之后详细地对客户做了“风险”定义和风险内容解释，客户方才理解过来，在之后的工作中，当风险成为问题时，客户也清楚是怎么回事，也积极地采取措施。    

    从对客户解释风险之后的工作效果来看，我觉得是很有成效的。一来提高了客户对整个项目的把握度；二来也增强了客户对我们项目组的信心；三来也提示了客户可能需要做到的工作。      

4、编写代码方式差点失去控制： 因为系统使用的框架比较繁琐，生成的代码文件也比较多，为了实现小功能，也是需要操作多个文件。在代码的Review中，发现了部分成员（包括原有项目成员）的编写代码有些不遵照编码要求来编写代码，最后造成的局面是代码混乱，不容易维护。发现之后，同项目成员员进行一番讨论，要求大家后续的开发遵照要求来编写自己的代码，不恰当的方式需要坚决地修改过来。

     不论是从维护的成本，还是从美观的角度来看，项目 编码之前，项目组成员的编码风格培训是必不可少的。良好的统一的编码风格应该也是项目组追求的目标。 

 

与公司其它部门配合情况

市场业务部

协助市场部与客户沟通项目进展情况。 

测试部 进行内部的系统测试，并未提交测试部测试。

 

 

项目管理经验教训

任务分配：

      能者多劳，自由选取为原则，关键功能以指定人员或自己担当为手段。（项目经理担当编码工作的分配方案并非最优策略，需要慎重考虑）

项目沟通：

      每周与客户进行例会，每周与项目成员进行WPS Review 、进度Review或者项目存在问题Review 与探讨等小型会议。定期发送项目报告文档。

人员培养：

      告知项目使用到的相关技术，探讨项目遇到问题时的解决思路，在容许的时间范围内要求成员独立思考并解决问题。

进度控制：

      准备评估成员能力，及时提醒其进度要求；建议与成员做好解决思路的探讨。避免其走弯路。 发现对进度有可能延迟的，应与之沟通，并提供有效的解决方案，同时应考虑是否需要与其一起解决问题。 对进度提前完成的，探讨其原因，并共享其工作方式。

质量管理：

      提高项目成员的质量意识，多次进行内部测试。  •  

 

      项目管理的基本目标是三个提高，一是提高项目组的生产效率、二是提高客户的满意度、三是提高项目成员的技能。因为提高了项目组的整体生产效率，才能更好地完成项目进度；因为提高了客户满意度，才能更好地提高项目组乃至公司的声誉，才能为公司挖掘更多潜在的市场。因为提高了项目成员的技能，才能更好地提高项目组的战斗力。 •      

      为了达到上述的目的，项目经理需要细心负责地管理项目的各个阶段，需要激发项目组成员的热情。

 

 

项目风险管理

可共享技术&模块