系统实施客户沟通环节经验评估报告.doc

H:\精品资料\建筑精品网原稿ok（删除公文）\建筑精品网5未上传百度

项目客户沟通环节经验调研评估报告
1. 概述:
公司自从转型以来, 已经经历了大约一年的时间, 在这一年中, 我们共实施了几十个项目/产品, 从中积累了大量的项目经验, 不过, 这些经验都是存在于和客户直接沟通的项目经理、 咨询工程师以及实施人员的头脑中, 而随着项目的增多, 这些人员也非常忙, 很少有机会能进行系统的总结。而在这公司过程体系中, 却一直是一个弱项。因此我们决定做一次这方面的调查, 目的是将大家的经验和教训都积累起来, 在组织内部共享。
我们调查时主要采用访谈的方式, 在访谈时, 为了让大家畅所欲言, 事先约定对访谈的内容保密, 而且确定在最终的评估报告中, 不会涉及到任何一个项目以及人员。在访谈中我们发现, 每个人员都积累了相当丰富的经验, 可是几乎每个人的经验都是不一样的; 而且发现有一部分同样的问题, 会在不同的项目中出现, 因此我们也强列感觉到共同总结共同提高的必要性。从结果来看, 基本上得到了我们需要的信息, 成为我们下一步改进的基础。
1.1 调查目的
经过对于客户直接沟通环节的调查, 进行经验总结、 积累和共享。根据最佳实践改进现有过程。
1.2 调查范围
阶段: 关注于项目的售前和售后, 主要包括: 商务谈判及合同签订、 需求获取、 项目沟通、 部署、 验收、 维护等环节。
人员: 公司内项目经理、 咨询工程师、 开发经理、 部署实施人员
1.3 调查方法:
主要采用人员访谈的方式, 事先准备被调查问卷及调查计划。对每一位被访谈者进行独立访谈。提取经验和教训, 总结出评估报告。
1.4 调查统计:
当前有与客户沟通经验的人员总部为: 16人, 实际调查人数: 11人, 覆盖率: 69%。
在实际调查人员中, 项目经理/咨询工程师6人, 占55%, 开发经理3人, 占27%, 实施工程师2人, 占18%。
覆盖事业部: 4个
2. 经验总结:
2.1 商务谈判及合同签订
2.1.1 存在问题
为了签单, 随便给客户进行承诺, 开空头支票, 结果会影响到客户的满意度降低, 这种情况在商务人员中比较多。
在签订合同的时候, 没有进行充分的估计, 往往对公司的能力估计过强。在签订合同的时候, 要确定合适的项目目标, 并估计公司的实际能力。
根据用户方的进度要求来压缩项目的合同工期, 而不考虑项目的实际能力, 方案不成熟的时候这样做风险很大, 实际的工期往往相差很大。
项目范围不明确, 导致后期需求的范围无限扩大, 得不到控制, 在被调查的项目中, 最求变更大的达到了60%以上, 变更最小的也达到了10－20%, 项目的需求变更成了家常便饭。
高级经理或者渠道直接签单, 与事业部沟通不足。
2.1.2 签约技巧及经验:
当前大家对于签约的认识已经得到了显著的提高, 在访谈的过程中, 已经没有人会认为合同签订是一个无关紧要的过程了, 绝大部分人员已经认识到签约的重要性, 对于条款的严肃性也有了充分的认识。在现有已签约项目中, 后期合同的签订就比前期好了很多, 这是一个不断完善的过程。
由于签单时需要考虑竞争、 以及用户对需求的不明确等因素, 因此在合同签订的时候风险是必然会存在的, 可是应该在合同签订的时候就考虑相应的风险处理策略, 并对风险进行管理和控制, 在风险较大的情况下, 考虑暂时不签或创造条件后再签。
项目范围确定是合同中一个非常重要的部分, 签约早期, 项目的需求越明确则项目风险就越小, 如果需要在签单后的进行调研, 能够在需求调研完成后将经双方确认的文档作为合同的附件, 而且需要将变更控制办法放到合同条款中, 和用户约定把每次变更作为合同附件保留。在合同中确定验收的条款也是非常必要的。
合同条款方面, 考虑对我方很不利的情况, 尽可能与用户沟通避免。而且在签订合同及合同附件的时候, 对于不宜直接表示的观点, 能够换一种合适的方式与用户沟通。
在和用户进行商务谈判的时候, 需要考虑已有系统的成熟度和项目的赢利值, 引导用户把需求范围靠近我们能实现的程度, 寻找双方折中点, 保证项目利润。
签约时事业部项目经理、 咨询工程师的参与是必须的, 越早介入风险越低, 成功率越高。是否签约以及项目范围的决定权最好在事业部。总部人员参与项当前期商务谈判的优势是: 对系统较了解; 与开发员沟通较多, 能反馈开发员的意见; 了解系统不能实现的功能, 从而引导用户, 从用户的利益上说服用户放弃技术上实现困难的要求等等。
2.2 项目沟通
2.2.1 客户沟通
2.2.1.1 准备
在访谈时, 有部分项目在与客户进行面对面沟通之前, 往往是临时性、 突发性的, 事前没有准备, 这种情况所造成的结果是千里迢迢到客户那里时, 才发现客户有其它的事情, 忙别的去了, 或者是找到了客户, 而客户由于事前没有准备而得不到我们想要的结果。往往白跑一趟都是有可能的。客户不会在乎, 因为反正差旅费和住宿费都是公司掏, 还需要加上伙食和出差补助。
口头的沟通也是常见的办法, 这种方法直接而有效, 缺点是随意性变动性较大。
客户的沟通计划是必要的, 各个阶段的沟通如有计划会加强客户的认知以及配合程度, 这包括需求调研计划、 部署计划( 培训计划) 以及验收计划。计划应是正式的, 并与客户沟通确认, 使客户方做好相应的人员、 时间、 设备、 资料的安排; 提高我方的工作效率, 降低成本。
在准备时, 仅有计划是不够的, 还需要准备好相关的材料, 这些材料根据任务的不同而不同, 材料准备能够是沟通计划的一部分。另外确定沟通的办法、 熟悉客户使用的方法和工具、 系统的试运行状态、 准备问题以及应对措施、 培训演练等等, 都是准备的内容之一。
2.2.1.2 客户关系
与客户建立信任的关系是非常重要的, 这方面在项当前期能够采用让客户来参观公司、 推广公司品牌的知名度等措施来实现, 后期则需要建立在产品以及服务的品质上了。
在项目实施过程中, 与用户建立良好的伙伴关系, 这是一个双赢的局面, 也是做客户关系的较高境界, 只有客户的成功才是我们的成功。
有关客户沟通的层面上, 前期商务谈判时确定利益约定; 对于决策层的沟通一定是充分而必要的, 这关系到整个项目能否签订、 如期完成、 验收以及收款等一系列关键步骤, 可是同时一定不要忽视与底层也建立良好的关系, 当与用户要求很难统一的时候, 必要时需要采取非正常手段( 如, 请客) 。
在部分项目实施过程中, 遇到了由于客户内部矛盾导致项目受阻的情况发生, 因此我们在处理客户关系的时候, 需要尽量避免卷入客户内部的矛盾之中, 这里面的解决方法可能是在签约时就确定项目负责人, 统一项目出口和入口, 引导用户负责人理解系统, 培养用户负责人理解和支持系统, 进行必要的风险管理和控制等。
2.2.1.3 沟通人员
在访谈中发现, 当前项目中有沟通人员不确定的情况存在, 用户沟经过程当中, 参与的人员较多, 容易造成项目信息沟通瓶颈以及信息壁垒, 这里需要有一个沟通的规划。
需要对目标客户进行细分, 针对不同客户采取相应措施, 对成熟度低的客户, 进行软件开发过程的培训有助于进行客户沟通和项目实施。
2.2.2 与分支机构的协作
大部分项目认为分支机构的支持力度应该加大, 而且认为需要加强与分公司的协作, 特别是后期的协作。分公司应该更多地参与到项目实施、 培训和维护工作, 建立良好的客户伙伴关系等活动中去。
分公司对于系统的了解程度对系统成功开发有很大影响, 应该加大对于分公司人员的培训。
分公司对于项目的风险规避太少, 与事业部的利益分享有冲突, 这样在早期就引入了较大的项目风险, 取决于公司的营销政策, 公司需要在政策上进行利益分享的引导, 明确各方的责权利。建议商务与项目相结合, 建立利益共同体。
2.2.3 内部协作
有一个良好的计划是内部协作的前提, 与内部项目组成员进行充分沟通是非常必要的。做项目计划并达成共识非常重要, 当前组内共识的达成较为容易, 项目经理跨部门协调能力较弱。当前由于部分项目没有计划, 导致实施工程师对于用户反馈的问题的解决和时间安排不协调, 系统测试不充分影响用户满意度; 而开发组也需要实施人员准确的提前提出用户请求, 安排相应的开发和测试工作。这里有关责任机制也需要明确。
在内部遇到问题, 能够内部进行解决, 对于客户而言则是一个整体, 不应将内部的协作问题暴露在客户面前。
开发团队内的充分沟通交流非常重要, 团队中直接交流和沟通是最有效的, 需要经常及时对工作成果进行讨论。
开发过程中人员的稳定、 成员的能力和团队的合作、 平等交流的气氛是项目成功的重要因素。
2.3 需求获取
2.3.1 调研时间建议:
前期调研需要充分, 时间不应太短, 时间太仓促会影响到需求获取的质量和粒度, 很难挖掘到客户真正的需求。由于充分了解客户需求后, 后期的变更会相应降低, 从而减少了由于返工而造成项目的拖延, 在开发工期方面往往不会造成太大的影响。
2.3.2 界面原型:
界面原型是项目需求获取的较好的方式, 业务模型的分析能力有助于系统的需求把握和实现。成熟度高的客户需求范围较容易早期就确定; 对于成熟度低的客户, 需求范围的前期确定较困难, 有界面原型会更好, 需要在后期加强沟通, 对用户进行说服。没有界面原型对于需求获取是一个风险。
2.3.3 获取客户真正的需求:
在需求获取的过程中, 进行具体客户分析, 采取不同的策略。用户期望、 业务实现、 易用性是需要主要考虑的因素。在调研的时候需要找到关键用户人员, 要明确需求的层次, 决策层的需求是最重要的, 可是也不能忽视底层的需求。
在用户需求挖掘的时候, 要注意用户隐藏需求的挖掘
开发过程中非功能性需求往往被忽略, 可是这类需求有决定性作用, 要求在需求获取的过程中注意这类需求的收集和确认; 不同的项目这类需求会不一样, 和事业部的具体方案特性有关
在调研的时候, 如子系统较多, 需要考虑整体性和相关的接口需求。
在需求分析时, 用户方参与会较好, 另外在需求调研时, 事业部直接介入能引导用户取出核心需求, 成功率更高。
客户需求在收集回来之后, 一定需要和开发组达成共识, 当前事业部制之后, 该问题已基本解决, 大部分情况都是事业部内咨询工程师与开发工程师结合共同进行需求获取, 取得了较好的效果。
2.3.4 需求范围控制
从商务的角度出发, 我们也需要尽量去控制需求的范围; 如果在早期这样做有难度, 则必须对于主流业务进行确认;
挖掘用户的真正需求, 给用户想象的空间, 并考虑用户使用系统时候的感受, 同时考虑现有系统实现的平衡, 控制需求, 和商务活动相联系, 这里面有一些技巧是: 谈的时候能够什么都谈, 但记录的时候要进行需求过滤。将我们做不到的或者不容易实现对客户又不太重要的需求过滤掉。而且对于不能做的需求, 不能直接回绝用户的, 要采用一些技巧来处理。如: 和用户沟通, 给用户一个印象, 软件制作是费时的, 引导用户在功能和工期上做平衡, 取消要求的需求。
前期调研期间需要和客户形成一个对于系统的认识方面的共识。
在项当前期需求调研的时候, 对用户进行计算机和软件工程方面的知识培训, 有利于和客户沟通, 让客户站在我方的角度考虑问题
尽量引导用户的需求, 降低用户需求与现有系统间的差异。站在对方的角度说服用户, 节约开发成本。
高层对于项目需求的范围不要轻易表态, 把需求收集和范围确定的权力交给项目经理
2.3.5 需求变更控制
对于需求的变更需要进行控制, 前期的商务谈判、 需求获取时均需要考虑后期需求变更控制的因素。
对需求的变更越早发现越好, 原则是把开发的精力投入最有价值的需求, 及早实现最重要的需求。对于项目的核心模块是必须实现的
对于发生的变更需要分析原因, 并确定解决的方法, 并与开发组、 用户对变更的结果进行沟通。对于变更与客户达成共识也是非常关键的。其中也需要做好变更的配置管理。
业务本身的成熟度对系统的需求稳定性有很大的影响。
2.3.6 调研方式:
调研的时候争取用户的配合, 与用户面对面的沟通是必要的, 后期再进行电话沟通会更顺利
当前采用的调研方式大部分是: 了解关键客户需求, 在根据客户具体情况逐个部分访谈, 记录整理需求, 和用户确认达成共识。总结需求调研的步骤则是: 调研计划――系统概要的介绍－－详细的部分沟通调研－－总结调研结果－－和用户确认。
2.3.7 需求记录与确认
用户确认的记录是非常必要的, 并在实施的过程中一定要想办法让客户确认。这是项目成功实施以及今后验收的基础。这里面的原则是用户的签字确认不是最重要的, 最重要的是正确的理解用户需要, 为了对双方均造成约束和承诺, 防止随意变更, 需要用书面的形式确定下来――用户签字。因此在调研结束后, 确定备忘录时, 考虑作为合同附件的约束性, 需要慎重处理备忘录中的需求条款, 并双方认可。
实施工程师在现场部署过程中获取的用户要求, 能够以邮件和文档的方式反馈回事业部的开发组, 在返回之前也需要和用户确认。
2.3.8 其它
当前公司项目对于第三方产品的管控能力较弱, 还有很多工作要加强。在使用第三方软件的时候要慎重, 要结合用户的需求进行深入的评估。
解决用户问题要有时间计划, 调研人员来回的需求需与开发人员确认是否可行, 然后何时解决, 并给客户明确反馈。给客户的承诺要争取按时完成, 如有变化要及时沟通。
在项目进度紧的情况下会采取极端编程的方式, 提供给客户界面原型和现有系统进行试用来收集需求, 文档较少, 相关的沟通采用讨论会, 要把用户纳入项目, 这时候项目经理对需求的理解和把握成为关键瓶颈。
2.4 部署
2.4.1 存在问题
部署时经常碰到的问题是软件本身的问题, 软件功能不完善、 软件的易用性、 稳定性存在缺陷, 对于培训不够重视, 现场环境复杂、 客户配合度不高等等。
开发人员在现场部署时会导致现场修改。这对系统稳定性以及今后的维护工作造成了一定隐患, 当前不提倡这样做。
部署人员、 实施人员在与用户沟通的时候商务意识不够, 造成系统变更、 范围扩大等。
项目初始化工作是项目的难点, 直接关系到系统的使用, 需要考虑用户原有的系统, 并考虑我们系统与原有系统的衔接, 耗费工作量较大。
部分部署活动无计划, 部署成本增加, 事前准备不够充分。部分项目较随意
2.4.2 部署计划
部署的任务主要包括系统安装和培训, 以及用户关系沟通。项目部署前, 向用户提供文档化的部署计划会更正式( 参见2.2.1.1) , 但需要项目的项目经理提供项目计划, 便于部署工程师安排相应的部署工作, 避免经常出现突发的部署要求, 导致现场部署工作仓促进行, 效果不好。
在部署之前, 估计可能遇到的问题, 以及解决的方法, 会有利于部署
2.4.3 现场步署
部署前要对用户的资料和数据先进行备份, 保证用户资料的安全。
系统测试完成后, 部署工程师在部署前, 在内部需要自己对部署程序进行一次安装测试, 并准备培训大纲、 文档等相关资料。在现场部署完后, 先进行测试, 再交付给客户使用, 层层把关以保证系统质量。
部署之前和之后都进行用户环境的了解对部署工作的开展都很有好处。在项当前期帮助用户搭建和确定系统环境, 有利于系统测试环境的确定。
对于用户反馈的缺陷要进行分析。
在现场部署时, 由于客户环境等各种现场因素, 可能会出现很多意想不到的问题, 这时候需要部署工程师妥善处理并记录。这要求部署工程师具有良好的心理素质以及经验。
2.4.4 用户培训
当前项目的培训工作开展时, 都没有系统化的培训资料, 建议对于经常重复使用的用户培训资料进行固化, 并进行维护, 也是提高用户服务质量的好方法
用户的系统管理员是今后客户方承接系统的管理者, 对于用户系统管理员的培训要做到充分和细致, 能够大大降低项目的维护费用。
在用户培训的时候能够向用户介绍系统的设计思路
在培训的时候提高用户的兴趣, 改变用户原有的工作方式, 体现系统的价值, 也是很不错的方法。
根据对客户的层次分析, 不同的客户需要不同, 因此需要对不同的客户层进行不同的培训, 均是针对客户需要进行。
2.4.5 部署总结
大部分被访谈者认为项目部署总结是很有必要的, 能及时的进行经验积累和提高。可是当前基本没有进行总结工作, 只有出差总结是不够的。
在部署回来后, 对用户部署环境相关的资料进行文档化备份, 能够提高远程维护的能力; 同时, 在现场能够帮助用户安装相关的工具。
2.4.6 系统测试的影响
大部分成员对系统测试的作用认识比较到位, 认为系统测试在没有经过的情况下会对部署造成严重影响, 直接造成满意度下降
当前大部分项目存在测试不充分的现象, 由于进度的压力, 测试时间不足, 这需要在签约时就进行项目估计, 充分预留测试时间。解决的方法可能是: 1、 预留测试时间; 安排测试人员; 2、 时间紧的情况下先给用户部署, 并说明情况, 内部加紧测试, 迅速提供新版本; 3、 正式给用户的版本的系统测试的优先级较高, 在资源分配上需要考虑。4、 在进度紧的时候, 给用户提交的版本按照需求的优先级分次实现, 保证经过系统测试, 给用户分期部署稳定的版本。
2.4.7 配置管理
被访谈者均认为良好的配置管理是重要的, 版本控制的意识在加强。可是现有部分项目中出现过多次部署版本不兼容、 无法回溯, 找不到已有版本等情况, 造成了严重影响。当前主要问题是公司级配置资源不足、 项目组内配置人员能力有待提高等。对于项目组成员配置管理意识还是需要进一步加强, 并需要了解配置管理方法等。
2.4.8 对现有部署流程的认知
没有看过的占多数, 大部分成员按照自己的经验在摸索, 看过并使用本流程的项目反映部分认为不错, 有较强的指导意义, 另外一些人认为现有流程比较繁琐。当前对于此流程需要加强流程的优化和贯彻实施。
2.5 验收
验收的时候, 客户满意度是关键, 反而对合同条款关注较少, 只有在不满意的时候, 才会拿出合同条款; 一些商务利益手段的使用是必要的。项当前期对用户的承诺不能实现的话, 直接影响项目的验收。加强用户沟通, 促进用户在系统部署后及时使用系统并反馈问题, 能有利的推动项目的后期验收工作。
商务活动、 科研成果汇报、 发表论文、 在行业内进行有影响的宣传对于项目的最终验收有促进作用。
客户没有正常验收的原因: 需求挖掘不到位, 调研人员未将实际的需求反馈给开发组, 用户的交互没有做好, 部署时培训不到位等等。导致用户不满而不进行验收或推迟验收。
较少情况是用户资金情况也会影响到验收的进度。
2.6 项目维护
2.6.1 存在问题
当前对于维护的问题会越来越突出; 主观原因是用户需求的不断变更, 项当前期工作不到位; 系统的问题; 文档不可用; 系统易用性不好, 不稳定; 事业部对系统升级的精力不够; 系统存在不可解决的问题; 客观原因是: 用户经常换负责人, 水平低; 与用户信息化的背景有关等等。从维护资源上来看, 当前如果不是现有项目人员进行维护, 维护工作很难开展, 分公司渠道没有项目的维护能力, 也没有激励措施, 致使事业部要做好维护, 就需要有大量的人力物力投入, 而且到客户现场维护的成本极高, 而对于有偿服务的机制还不够完善, 导致维护费用高起不下。项目售后服务工作困难较多。
在第三方软件的维护问题上, 当前公司对于第三方产品的管控能力较弱, 还有很多工作要加强。在使用第三方软件的时候要慎重, 要结合用户的需求进行评估。否则, 在维护阶段这部分工作会成为难点。
项目维护工作如果处理不好的话, 带来的影响是: 维护成本太大, 无法支撑正常运营、 无法收到项目的尾款, 客户满意度大幅降低, 品牌受损、 被客户抛弃等严重后果。
2.6.2 维护方法
和部署一样, 维护时遇到的问题并非是这个阶段才有的, 而是在项目一开始的时候就一直积累的问题, 因此降低维护成本的最根本的方法是改进软件生产过程, 制造出满足客户需求、 低缺陷、 高扩展性的产品。在操作层面, 各项目均积累了一些经验:
项目进入维护期前, 给用户正式发送《项目完工通知单》双方确定验收维护的界限和相关维护工作是必要的。便于维护期的界定, 以及后期维护费用的收取。
在进入维护阶段时, 与用户确定《维护计划》, 确定维护的周期、 维护工作量, 使维护成本可控。
在项目进入维护时要和用户签订《维护协议》, 渠道进行维护工作, 明确维护利益。
对客户系统管理员的强化培训能够提高用户自我维护能力, 从而降低维护成本。
维护阶段需要明确分配维护的资源, 在项目维护方面, 一定要考虑协作的方式来解决, 事业部人手不足, 而分支机构和客服在售后服务方面有较大的优势, 良好的利用能够降低成本, 对分支机构及客服的工程师加强方案项目的培训, 利用分支机构的地域优势、 客服的专业优势进行后期维护工作。
维护工作能够采用一些技术人员现场蹲点指导的方式, 让用户尽快把系统使用起来。在合同中明确指出项目的维护方式和费用等协议。
尽可能采用远程维护的方式
周期性的维护也是一个很好的方法
2.7 客户满意度
2.7.1.1 用户满意的关键是:
良好的能满足用户真实需求的系统;
系统的稳定性和易用性较好;
服务的态度能够弥补产品的功能缺陷, 响应速度, 和是否能够实现的及时反馈;
建立良好的用户关系是必不可少的
正式的计划能够提高满意度, 及时和用户沟通项目的进展
2.7.1.2 客户不满意的主要原因:
系统功能达不到客户要求;
系统不稳定, 经常出现大量的bug;
新增的需求得不到控制, 双方都不满意;
项目没有完整的计划等等。
在访谈过程中, 由于基本上都能够在客户要求的时间内提交版本, 对于项目延期不是非常敏感。
2.8 其它
2.8.1 需要得到的支持
对于业务人员的能力亟需加强, 需要公司提供系统的多方面的培训: 业务知识、 沟通能力、 计算机和网络知识等。
开发人员对项目问题的响应速度需要进一步提高。
分支机构的支持: 渠道要有较强的业务能力, 以担负前期需求确定以及维护的任务。
QA和CM人员的流程支持, 提醒和监督是必要的
事业部资源的支持: 在项目开发实施过程中, 应该保证项目资源稳定。人员的变动对项目会造成很大的不良影响。
2.8.2 交流平台
和公司范围以外的实施和商务经验的交流; 面对面方式的交流会更好, 往往不愿意用正式的方式进行交流。
大家乐意接受的经验交流方式是: 角色扮演, 经验传授, 内部学习、 公司提供coffee time等等。
2.8.3 其它改进点
项目需要确定明确的项目负责人, 直接负责项目的需求核实和用户沟通, 职责不明确会对项目的顺利进展造成重大的影响
项当前期, 由项目经理牵头, QA辅助, 明确项目的过程约定和沟通机制, 有利于项目开发实施过程中的沟通和问题处理。
建议: 在部署程序文件中总结出一个简单的记录, 每次与用户沟通时使用一两张, 不要太烦琐。需求备忘录和实施单需要用户的确认
建议: 在用户需求的确认方面, 一定要坚持让用户签字认可; 在某些用户顾虑的方面要小心谨慎的处理, 对于要与客户确认的记录, 要考虑使用时的友好性, 对于《阶段成功确认单》需要修改文档名称
项目要有计划、 改进客户关系、 加强文档能力和技术方面的能力
当前做产品和做项目销售, 项目款项大易完成任务, 而产品的回款较快。在公司的政策上, 对于这两项会出现的问题应进行考虑。平衡分支机构人员对项目的贡献和不利影响。