笔者在全国知名快消品黄埔军校集团本部任职近6年，接触和管理了诸多IT项目，现在就SFA项目做一些泣血经验之谈。每个项目的成功都是团队的心血，祝愿每个项目上的人都能不开心过后是开心！
第一章 SFA系统概况
本章主要介绍笔者所谓的SFA系统是什么？以及它的作用是什么？旨在通过本章的描述，使读者对SFA系统有一个初步的认知。笔者资历经验有限，并不能像教科书一样严谨，来龙去脉广义狭义详细列举；更不能像专业书籍那样详实，对系统好处从国家战略到公司到个人的作用一一列举。笔者只是站在一个曾经管理过SFA系统的普通职员的角度，粗陋的谈及一下在系统管理中所遇所见所想，不足之处还请各位读者海涵。
第1节 SFA系统的背景
快消行业是一个万亿级的市场，市场体量非常庞大。快消品牌日趋增多，就单一品类内的快消品牌就难以计数，市场饱和，行业竞争日趋惨烈。快消行业内的竞争由品牌竞争逐渐延伸到通路上的经销商压货，零售店抢货架等实战竞争。
而公司对于市场战况的把握，尤其是终端一线市场，公司的总部总会出现偏差。
一、公司总部和一线终端的距离太远
公司总部与终端一线市场的距离不是指空间距离，而是管理距离。并不是所有老板都像娃哈哈的宗庆后一样一年花200多天时间泡在市场上，但总部起码要真心关注终端一线市场。大部分的管理层的特点是老板关心什么，管理层就重点汇报什么，其余工作先放一放、缓一缓。老板长期对终端一线市场不过问细节，管理层就不会拿终端一线市场的事去惹老板烦。即使管理层关注终端一线市场，但是是否是看到的真实的终端一线市场，还是粉饰过的‘天下太平’，也不可而知。不知道大家是否听说过‘观光线’一词，就是基层管理者为了应付总部管理层而设置的专人服务的线路，线路内的终端门店的客情、产品的市占率、产品的新鲜度都是好到让你惊讶。
近几年管理手法中，通路扁平化是常用手段，公司总部似乎离终端更近了，但现实可能恰恰相反。在通路扁平化的同时，企业内部的管理层却增加了。以前营销系统只有1-2个管理层，现在却普遍有3-4个管理层。终端一线市场的基层十万火急请求支援，经过3-4层管理选择性汇报结果可能变成了市场一切良好，下月再争新高！
二、公司总部对‘放权’的管控难把握
中国市场之大，区域市场差异之大，远远超过了整天坐在办公室的总部管理人员的想象。可是，大多数总部人员仍然坐在办公室，凭想象指挥一线营销人员，即我们常说的‘拍脑门’。
公司总部一般不敢放权给分公司，因为‘一放就乱’是不争的事实，因此，总部集权是必要的。但是，集权并不能成为总部要求终端一线人员“使命必达”完成总部指令的借口。
公司总部对分公司有两种典型做法：一种是总部拿出一个“统一方案”，然后要求各分公司‘使命必达’；另一种是由于公司总部不了解区域市场的状况，拿不出具体的政策，因此只讲原则，具体执行策略和方式交给分公司经理。但是，总部对各分公司经理的方案又不放心，于是，总部就开始开始讲原则大放权后期扣细节要结果。总部对各分公司的策略也是来回纠结，放权了地方乱了，不放权机会错过了。因此，往往丧失做市场的时机和力度。
以上简单列举两点问题无所谓是公司总部的问题还是地方分公司的问题，大家的目的是一致的：把货卖出去，把钱收回来。但是沟通是选择性的，选择性的信息的不对称是导致上述两个问题的一个关键因素。如何把最真实，最全面的市场信息，客观的，简约而不简单的展现在公司总部和各分公司面前，就成为一个迫切需要解决的问题。
近几年伴随智能设备的出现和普及，以及互联网应用行业的发展，SFA系统解决方案应运而生，成为各快消品公司最青睐的有力武器。营业系统也不负所望，协助多家各行业龙头企业集团总部和各分公司掌控了最全面最真实的终端一线市场动态。
在SFA系统对公司管理的利好作用下，各个快消公司都积极的投入巨资引入SFA系统管理营业团队，各个公司也给自己的系统取了响亮的名字，笔者不在这里赘述，本节笔者主要给大家介绍下各公司这些系统的原始版本：移动访销系统（SFA），旨在帮助读者了解这套系统的大致情况。
移动访销系统
业内常称为SFA系统，即Sales Force Automation，直译为销售能力自动化。
SFA是在市场实际销售过程中，针对每个客户、每次销售动作对销售人员行为进行科学、量化的管理；可以有效支持销售团队对客户的管理、对销售机会的跟踪和对竞品动态的掌握；可以有效规范销售动作、实现团队协作、资源合理调配。
SFA在欧美地区已有10多年的应用历史，是企业销售管理的基本工具。
做一个比喻，SFA系统就像一架望远镜，让公司总部在办公室就能获取最全面最新鲜的终端一线市场信息；营业系统也像一架显微镜，让公司的管理层能细微的看到每个终端小门店的实际情况。
既然SFA系统具有如此强大的功能，解决了公司总部和地方分公司沟通之间的痛点，那该如何有效管理使之发挥出巨大的作用呢？在后面的章节，笔者会从甲乙双方对SFA系统的管理，以及系统管理常见误区等方面详细介绍。本书的所有观点，均是笔者拙见，不代表任何公司和组织的看法。因笔者资历尚浅，见解难免有偏颇疏漏之处，还请各位读者海涵。
2 SFA系统的作用
笔者不止一次的被快消圈内的朋友问到，SFA系统到底有什么作用？从客观来讲，一个系统的作用并不是全部决定于系统本身，就像电子产品的电池续航能力一样，通常说的多少小时的续航能力都是实验室的数据，而具体实际你能用多久要看每次具体的使用环境。所以SFA系统的作用也是随着使用公司的文化和管理团队的管理方式不同而呈现出一个系统不同效果的结果。
我们抛开系统厂商所说的美好方案，从笔者有限的管理经验来看，SFA系统具有超高沟通效率，超快的分析结算，完整的指标收集，极大的节约人力等作用，这些作用环环相扣，形成了一个良性循环，对企业营业行为的管理起到了积极的作用。下面笔者将这些作用展开介绍下。
一、超高沟通效率
相信大家对租房不陌生，辛苦几天，跟着中介跑遍几个小区，价格谈了多次，最后等你下定决心，跟中介说我定了的时候，中介告诉你，对不起，这套房已经签了。想哭有没有？
这个例子主要是说明信息不畅导致的时间和投入资源的浪费，同样的情况，照样会发生在营业作业上。业务人员顶风冒雨去和客户协商拿回来的订单，销售支持或工厂可能一句话某某产品缺货或价格问题，就把业务人员的一天辛苦付诸东流。
同样的销售过程的信息不畅不仅发生在产品库存上，还会发生在产品更新调整，产品价格变动，促销活动变化等。可以总结性的说，只要需要业务人员知道的事情，都有可能因为不同部门和管理层级的信息流通环节的误差而导致业务人员该知道的而不知道。简单说，你允不允许销售支持请假，你允不允许业务人员报错产品，你允不允许业务主管把促销的方式搞错，你允不允许库管人员盘点出错。好像笔者说的这几个问题不存在允不允许，应该是肯定存在的事情。
SFA系统的作用就是将这些信息的不畅解决掉，使所有信息都快速传输并准确的展现在需要的人面前。重新回到上文业务人员因缺货而不能出货的订单，营业系统是可以将可用的实时库存准确的推送到业务人员眼前（可能是手机端app，或是微信端，下文详细介绍），在和客户沟通中，业务人员就已经看到公司的可用库存，进而进行准确的销售。
同样的公司产品调整，SFA系统会将整个调整的始末及时发送到营业人员眼前，使业务人员及时的调整销售策略，协助新品或重点品项的销售。SFA系统对促销活动的作用更大，因为公司往往不是单一的促销活动，而且不停的应对市场，应对公司策略，应对竞争对手，促销层出不穷，搞出错的情况经常出现，不是业务自己买单就是经销商买单，反正公司不负责。SFA系统会将促销信息准确、适时的展现在业务人员眼前，甚至可以在业务人员下单时，智能提醒此单有可用的促销模式，SFA系统智能管控促销的时间，促销的产品，促销的力度，比人脑计算，要快的多而且准确得多。
以上只是列举了营业系统在可用库存，产品管理，促销信息的部分场景下的应用，大家已经看出了SFA系统的强大能力，下面我们看看SFA系统在分析结算上面的应用。
二、超快的分析结算
分析结算不一定指的是很长的日期，而是指的一定时间，可以是半天结算，可以使日结，周结，月结，对于SFA系统来说，都是一样的工作。
举个例子，新的业务独自去拜访客户了，业务主管十分不放心。跟着去吧，新人可能有压力，自己无法发挥，限制成长；不跟着去吧，新人遇到问题会不会求助自己呢？最重要的是出去一天，订单能不能拿回来。这个问题可以通过SFA系统的分析结算看出来。如果系统设定每半天结算一次业务人员的拿单数据给主管看，那中午的时候，主管就可以看到新人的拿单具体情况，通过拿单的明细，主管就可以判断新人拜访客户的一个大致情况，再决定下午要不要去协访新人。
再举一个例子，主管都想看到当日的业绩成果，但是业务人员限制于客户时间，路途时间等因素，不能准确的将主管关心的数据提交上来。常见的做法是利用及时通讯工具，微信、QQ这一类软件，业务人员向销售支持口头报告自己一天的业绩，然后销售支持再汇总，交给主管。销售支持沟通汇总，需要一段时间；业务人员和销售支持没完成工作，主管也不好意思提前走。问题来了，大家除了工作还有家庭，除了家庭还有生活好不好，每天汇总到很晚，还要不要出去high了。SFA系统这时就可以通过设定，在下班时间段，每隔一段时间跑一次当日业绩数据，然后推送到销售支持和主管眼前，这是不是就很便捷，大家该下班下班，当日业绩当日看，完全不耽误。
三、完整的指标收集
在日常的管理中，有很多指标需要业务人员去一线收集，比如竞品的动态，公司产品的陈列占比等信息。这些指标通常都是没有固定格式的，不像订货单那样整齐划一，打印出来填写，姑且不说成本，就数据是否是真实填写的，填写回来歪歪扭扭的字迹销售支持能不能有小学老师的辨字功力，这都是不可知的，而且非常难管控。主管口头询问，业务人员的表达是否准确是未知的；请业务人员拍照带回，一张张拷贝到电脑里再查看，主管有心，销售支持无力啊。SFA系统可以通过指标的灵活配置，请业务人员在一线访店的时候就输入简单的数据，随手完成；主管可以通过系统分析汇整梳理，及时看到指标数据，完全不需要再有人员干预。目前的SFA系统可以支持单选、多选、数字输入、汉字输入、日期输入、拍照上传等多种设置，丰富度满足日常指标管理需求。
四、精准度数据传递
业务人员的奖金设置，假设公司设置为订单销售达成和指标达成两大部分。订单销售是日常紧紧追踪的项目，出错率很低，但是不代表不出错。密密麻麻的出货单，急匆匆写下的销售单据，每日的大量客户拜访，可能业务人员转录出错，业务人员到月底结算才发现转录错了，然后销售支持去好厚一大摞单子中去找出错的单据。再有就是指标数据，很难做到手工精准统计，订货单上写的又缺乏辨识度，搞错非常容易。这些都导致了业务人员的数据到公司支持人员那里发生了变化，不能说一定是谁对谁错，但是给公司的管理产生了不良影响。SFA系统是系统作业，处理数据能力极强，从前端的数据采集开始，就保持数据的准确性和纯净度，直到存储起来，数据都不会因为人员的干涉而改变。这就保证了业务人员自己录入的数据就是最后奖金核算的直接依据，没有人去转录，没有人有机会去把数据搞错。
五、极大的节约人力
公司在市场投入大量的业务人员掌控市场，同时需要投入支持人员来协助业务团队，比如上文提到的订单转录，促销的规划，订单价格的审核，奖金的结算。这些功能需要架设相应的组织比如订单组，促规组，营会组，人资组，最终形成了业务人员一千，业务支持八百的格局。通过上文的介绍，大家可以清晰的看到，SFA系统可以准确的完成订单转录，系统对库存数据的检索要比人工检索快得多也准确的多，这样就为公司节约了大量的人力成本，而目前的企业成本很大一部分来源于人力成本。
举个简单的例子，订单转录的岗位没有很大的技术含量，就是重复的操作，所以薪资很低，很少有人会踏下心来一直做这个岗位，所以会出现不停离职入职的事情。从公司角度讲，就增加了培训成本，人力成本，一个岗位一年交了12+份保险，还不能增加订单转录效率，减少订单出错。总结一句话就是钱花了事没办了。如果使用SFA系统，只需要一个人，维护系统数据，协调解决下系统逻辑和业务逻辑的冲突，重复性的工作交给SFA系统去完成，公司就不需要那么多人力，自然也不需要因人多流失率高而产生的其他功能人员。
综上所述，SFA系统对于公司的营业端形成了高效率、低投入、极准确的良性循环，对于公司业务团队的扩大建设和对市场的深度掌控都起到了积极的作用。正如古人所说：工欲善其事，必先利其器，SFA系统就是这个神兵利器。同样古人也说：磨刀不误砍柴工。公司有了神兵利器，如果管理使之发挥最优的功效，披荆斩棘，所向披靡，成为了一个值得各公司深思的课题。笔者结合浅陋的资历和管理经验，在下文会从SFA系统管理中甲乙双方层面谈及这个课题，不当之处，还请各位读者海涵。
第二章 甲方SFA系统管理
第二章 甲方SFA系统管理
本章从甲方的角度给予读者一些实际操作中的实战经验，这些经验谈不上方针策略，但是能从执行中避免系统管理“大风大浪闯过过来了，小河沟翻船了”，起到防微杜渐的作用，避免千里之堤毁于蚁穴。
1系统评估
SFA系统国内市场解决方案已经很成熟，各大第三方厂商的系统布局从各自拿手的平台也逐渐扩散到整个营业体系的系统性方案。
每一家看似给出的都是完整性的方案，甚至有的厂商会抛出“用我的系统，某某银行可以依靠流水数据给予免抵押低息贷款”此种具有诱惑力的条件。厂商的报告和承诺都是完美主义，那么客户该如何去评估厂商是否最适合公司呢？
系统评估的第一招：系统的稳定性
系统UI的美不美，系统功能的完整性都是可以去忍耐和后期弥补的，唯有稳定性是不可弥补的，历史是不可以重来，宕机1秒钟就会产生1秒钟的历史数据空白，所以系统的第一考量因素绝对是稳定性。
笔者曾经亲自管理过一个SFA系统，这个系统出了名的烂，每个月不宕机一次这个月肯定过不去。系统宕机之后呢，大家也是非常痛苦的，400热线打爆了，销售助理的电话被打爆了，月底人资结算奖金时候，电话也被打爆了。为此，管理部门还特意制作了一套表格，供宕机的时候由销售助理填写因宕机产生的差异，然后一层层逐级上报至管理部门，管理部门审批后，销售助理和人资在核算奖金时做参考依据。大家是不是觉得不可思议，但是整个公司都用这个方法，从上到下超过1万直接人力参与！（笔者如何处理这个问题的后文会有详细介绍）
评估系统稳定性最有效的方法就是考察厂商合作过的客户以及项目，一般来说合作的客户越大，系统稳定性越高，合作的项目的时间越久，稳定性越高。这也是目前很多拿到风投资金的互联网企业，疯狂的不计成本的想要和一些世界500强之内的企业合作的原因，甚至有些厂商还成立专门团队来配合大客户，用以打磨产品，保证产品的稳定性。
系统评估的第二招：系统的延展性
厂商为适应不同客户的需求，会有标准SAAS产品供客户参考，基本涵盖了行业内的标准作业模式和功能需求。但每个客户的企业文化是不同的，管理思维是不同的，不同时期的管理重点也是不同的，所以对系统的需求也会在不同时期呈现不同的要求。这就要求系统具有延展性，可以在现有的架构上增加客制化的模块功能，实现系统功能与客户的需求高度匹配。简单来说就是接到客户的需求，厂商不能说这个功能不能实现，因为系统架构不可以。
评估系统延展性最有效的方法就是查看2个厂商合作的差异性大客户（别找同产品线的，比如卖饮料的基本都是一个管理模式）的系统设计和标准产品三者之间的差异。如果只是UI不同，整体结构，系统流程完全相同，基本说明厂商的客制化延展性很低；反之如系统在标准产品上延展了很多产业内重点关注目标，比如饮料行业会提供精细化的冰箱资产管理流程，奶粉行业提供一罐一码的追踪管理流程，这就说明系统的延展性很高。
系统评估的第三招：系统的应变性
面对日益繁杂的市场情况，区域内市场行情的剧烈波动，使公司层面的步调一致大步向前已经很难取得良好的效果，这就需要系统具有良好的应变性。良好的应变性可以使管理层在最短的时间内获取市场最新动态，保证对市场行情的实时追踪，为市场行情的应变提供可靠即时的数据情报，使管理层的决策有据可依。应变性的需求大多来自外部的因素，比如区域内竞品的大力度促销，行业内价格的调整，民生问题的突发处理（洪灾、地震）等等，这些不在公司日常作业之中，但是情况发生时需要管理层对现场情况有较充分和准确的判断，以此给予最优的政策指导和资源配置。
评估系统的应变性最有效的方法是系统的灵活配置性和生效方式：包含系统流程的临时配置，系统字段的临时配置，系统功能模块的临时配置；这些配置的生效方式也包含立即生效、约定时间生效和升级版本生效。系统应变性的优良要根据自己公司的管理模式和业务实际综合评估，不一定立即生效的就好，也许管理权限不到位，立即生效的搞得一线业务鸡飞狗跳。也不一定升级版本生效的不好，比如增加字段会营销数据结构，会影响报表功能，如果可以随意增加，系统内非法数据管理就会让人头疼。
系统评估的第四招：厂商团队资质
IT行业最忌讳的是项目经理跳槽，因为每个项目经理都是按照自己的方式管理项目，包含了项目经理惯性思维方式和个性化的处理问题的方式。厂商频繁的更换项目经理会使项目存在不可预见性的隐患，司空见惯的例子就是厂商换了几个项目经理之后，客户把厂商换掉了。
评估厂商团队资质最有效的方法就是查看厂商团队人员的简历。一般来说核心开发人员在公司会被老板当珍珠一样捧在手里，稳定性比较好；项目经理主要看在职年限和项目更换频次，每个项目带一段时间的项目经理肯定不行；最后还要看测试人员，项目经理在项目稳定后大多会放松对产品交付的管理，这时候的测试人员就很关键，一个稳定的默契度高的测试人员能帮甲方节省大部分的啰嗦时间。
系统评估的第五招：系统性价比
一分价钱一分货，买系统也切记图便宜。一个合理的价格会使厂商有合理的利润空间，厂商就不会在新功能的调整和后续的运维上过分为难客户。限制于预算，大部分客户都想花小钱办大事，厂商也会顺着客户的套钻，前期赔钱做，拼命往项目上堆资源，等客户用习惯了，出数据了，系统稳定了，厂商开始收钱了，对，这时候的客户已成砧板上的鱼肉，待宰的羔羊。
笔者听说过调一个系统参数甲方出30万的，也听说过出一张报表25万的，还听说过调整一个小功能要10万的，一开始心想这个还算良心，后面再细问，支付单位是美元，原来宰的是欧美企业。
第2节 系统培训
本节主要介绍甲方在系统上线初期和系统运维过程中的人员培训。系统培训在很多时候会被大部分甲方忽略，甲方认为系统部署完毕，初期做了启动式培训就可以了，只要基层使用人员入门了，自然而然会学习使用系统并不断进步。这种想法其实和扔给你一台单反相机一样，对焦按快门，大部分人都会，然后看着那300页的使用说明书你就能成为摄影高手吗？
一、系统上线初期的入门培训
基层使用人由一个小白变成一个熟练的使用者，需要甲方培训人员给予使用层整体性的全面培训，这包含了使用系统的意义和作用，如何正确使用系统，系统问题如何处理。
1.使用系统的意义和作用
众所周知，有理解才有认同，有认同才有执行，所以让使用层深刻的认知使用系统的意义和作用起到了重要的启蒙作用，对使用层日后正确使用系统具有决定性的意义。
举个例子，SFA系统中普遍有的地图定位功能，绝大部分的使用者都非常抵触，认为定位是为了监视使用者的一举一动，让使用者有一种赤裸裸暴露自己的感觉，彻底打碎了使用者和基层管理者的模糊信任感。其实站在管理者的角度讲，属下的一举一动早就看在眼里，如果一个基层领导都不知道谁爱偷懒，可以肯定负责的告诉你，这个基层领导不出3个月就会被下属挤兑走。所以基层使用者大可不必为这些担心，而且地图定位的功能根本不是为了查你的出勤和勤劳度，如果基层使用者每个月都超百完成业绩，没有人再会费心去分析你的出勤和勤劳度。
SFA地图功能的重要作用是包含指引新的使用者门店的位置，避免绕弯路和迷路；也包含协助使用者自我分析和反省店内时间和产出，如果一个产出效益很小的点你总是花费较多时间，而潜在效益点却花费较少时间，这时候就要调配自己的时间了，一般这种行为需要经验的积累，但是透过地图定位配合时间管理，新任的使用者也可以透过报表分析轻松的掌握并快速调整自己的时间分配；地图定位还可以快速获取同事或主管的协助，调整自己的拜访顺序，使每天在路上风吹日晒的时间最短，在有效益的店停留更长时间，达到最大化的产出，拿到更多的奖金。
在初期的培训中，内训师要透过正确、正向的培训话术引导使用者正确的认识和理解系统的优势和对工作的帮助，并用生动的案例帮助使用者解开心中的问题和怀疑，让使用者真正的接纳系统。
2.如何正确的使用系统
根据笔者的经验，如何使用系统的手册一般会由两种单位出：
第一种是乙方人员编写，系统使用手册的编写非常有逻辑性，非常具有IT专业性，手册是足足几十上百页的文档，但是说实话，这种手册连甲方自己都很难认真的全部看一遍，更别说基层的使用者了，没人去耐心的看，而且基层使用者的文化程度普遍不是很高，对于这么专业的IT说明文档也读不懂。
第二种是甲方系统管理人员编写，这种内训手册大部分的误区在于办公室职员是从系统需求调研，客制化修正，上线测试一路走来，对系统的难点和重点以及易错点都已经非常了解，这种文档都是站在办公室职员的角度在向使用者灌输知识点，搞得使用者云里雾里。这就像大学老师授课，按照自己的备课讲义讲，不会理会学生哪里不明白，哪里没记住。
优秀的培训手册应该具备至少3点：①培训目的明确②以使用者角度编写③与使用者充分互动
3.系统问题如何处理
甲方管理团队和乙方运维团队最不愿意见到的就是有人提问题，这包含了咨询类问题，初级系统使用性问题，系统BUG问题和需求类问题。这其实是个矛盾点，因为使用者也不想提问题，但是出了问题就要有人处理。什么样的问题由谁来处理，最后的处理结果如何回馈提报者和公布，都是必不可少的管理环节，其重要程度不亚于系统的正确使用。
系统问题的处理一定要制定标准的流程化管理，要设置提报和回馈的机制，让提报者知道自己的提报的问题有人在处理，处理到什么程度，什么时候能得到确切结果。问题处理流程切忌不能散，涣散的问题处理方式会让管理团队大费精力，而且提报者得不到满意的答复，整个系统项目会越做越没信心，越来越不愿投入精力和资源去提升系统，最后大家会惊人一致的得到一个结论：系统真烂！
笔者前期接触一个系统管理项目，管理团队为了服务近8000的一线营业人员，特意设置5个座席的400热线，就是可同时处理5个人的问题提报，但是问题处理效果并不理想，为什么？因为甲方管理团队同时还接受邮件提报问题，电话提报问题，这些邮件和电话提报的问题会被甲方转发给乙方运维团队，再傻的乙方团队都会优先处理甲方团队邮件转来的问题，这种问题的处理机制导致的结果就是400热线闲的不行（100万/年基本打水漂），甲方管理团队忙的不行（最多加到7个人），乙方运维团队乱的不行（不知道先处理谁的问题了），一线使用者愁的不行（提的问题总是得不到答复）。（笔者解决此问题的方法在后文会详细介绍）
二、系统运维过程的循环培训
因为系统功能的迭代升级和新需求的不断加入，加之基层管理者和基层使用者的持续汰换，系统运维过程中要不断的进行循环培训，保证基层管理者和基层使用者对系统始终保持较高的熟悉度。对于循环培训来说，固定时期的培训和不定期的沟通相结合效果尤佳。
1.固定时期的培训
系统在运维期间，因甲方公司为适应管理而提出的系统新功能的需求，还有因乙方自身的系统升级会产生迭代的变化，都会引起系统的调整另使用者慌乱。即使通过手册的学习和口口相传的询问能够正常使用系统，但对于系统变化的意义和作用，升级后系统所新增的优势以及后续系统问题的异常处理都缺乏培训的深入指导，这样就会使系统升级的使用效果大打折扣。
固定时期培训的培训可以依照公司条件和升级迭代内容量而定，举个例子，笔者曾经的一个系统管理项目，销售支持遍布全国，全部人员培训2天合计成本到达20万，上线初期的升级内容频繁，定为每年举行一次全国性的培训，各区域分公司每个季度举行一次区域内培训会；系统运行稳定后，功能齐全后，取消各区域的季度培训会，改为每年一次的全国培训会。
2.不定期的沟通
定期的培训并不能保证全部人员对系统的深入理解和认可，所以可采用不定期的沟通来即时弥补部分人员的认知不足。这需要甲方的管理团队投入更多的精力，保持对区域支持人员的实时关注，平时多电话互动，有事没事微信骚扰几句，保持双方的顺畅及时沟通。
如果甲方团队有月度问题提报汇总机制，还可以参考问题提报量的多少，问题提报的频次的高低，提报问题时常的长短来判断区域支持人员对系统的理解的差异，以便及时给予沟通培训和答疑解惑。
第3节 系统上线
系统在上线推广中的常用的两种典型方法：多团队平铺法和种子扩散法。两种方法各有千秋，主要针对公司系统管理项目上线时期不同人力配置情况和可调配的资源情况而衍生的。
营业系统的上线推广，公司高层可能会要求比测试修正更短的期限，以期望在最短的时间内看到巨额投入的产出效果。在如此短的期限内，让所有系统使用者熟悉并熟练使用系统，是比较困难的。下面主要介绍下两种常见的上线推广方法和推广中注意的重要节点。
第一种：多团队平铺法
这种方法适合甲方管理团队和乙方实施团队人员较多的情况，可以短时间内分出3-5个小组。每组由甲方带队，乙方实施培训，甲乙双方共同追踪培训效果，地方各分公司营业单位配合组织落实执行。
这种方法的优势是专业的营业系统管理团队直接面对面给予最权威、最具体的培训讲解，给予各分公司营业单位最完整的营业知识和技术知识的支持，没有中间人的二次传递，使营业系统后续的日常使用和维护有质也有量。
千万不要忽略系统上线质量的问题，因为很多的区域营业单位都有很多事要忙，对于新的事物的反感和排斥是最原始的反应，他们不希望再有事情来打扰他们，在本来忙碌的工作中再增加负累。基于这种情况，大部分的基层使用者会应付甚至敷衍的上报上线进度，而忽略上线质量，为以后的系统使用埋下隐患。
多团队平铺法的缺点也是显而意见的，就是甲方没有这么多的人力配合分组，乙方一般都是集中力量做一个项目，甚至可以把测试人员调动出来配合甲方，但甲方很难抽调人力。基于这种情况，举出如下方法。
第二种：种子扩散法
这种方法适合甲方不能投入过多人力来进行系统上线，甲方人员将上线任务分配给区域内指定人员，由区域内指定人员完成上线推广。如乙方可以调配人力，可以与甲方区域内指定人员组合成推广小队。
这种方法的优势是甲方投入人力少，并且能保证短期内上线完成。
同时这种方法的缺点也是显而易见，因为从甲方到基层使用者，中间隔了区域内指定人员，这个区域内指定人员的业务能力、工作态度将决定区域内的上线效果，甚至会影响区域内的系统使用质量，造成严重的后果。
举个例子，营业系统为满足系统的复杂性，会设置很多灵活的功能，比如常见的采集指标配置。在上线初期，所有地方使用层对系统不熟悉，会严格依照培训讲述的方法方式去操作，这些方法都是甲乙双方的管理团队反复测试过的，出问题的概率极低。系统上线后，使用层一方面对系统越来越熟悉，会放松错误警惕，另一方面会发现系统的逻辑小漏洞，这里所说的漏洞不是指的系统BUG，而且一些业务逻辑和系统设计逻辑下的不吻合，系统设计很严谨，讲究1234的逻辑性，但是业务操作更具有目的性，一步到位是最完美的。系统灵活性和使用者走捷径就会导致系统的数据分析无法顺畅，影响系统上线质量。
第4节 系统维护
俗话说打江山容易守江山难，系统日常维护比系统上线推广更为重要。系统日常维护不单单指保证系统的稳定可用，还包括系统的迭代更新和区域内新需求的更新以及主数据纯净度的维护。
一、系统迭代更新
系统的迭代更新是指因乙方技术的更新而更新系统的架构、流程或优化已有功能项目，使系统保持同行业内的技术同步更新。这种迭代的频次比较低，尤其是客制化内容过多的系统，迭代可能会引发整体系统的崩溃，影响甲方的实际使用。哪怕只有1秒钟的崩溃，也会产生1秒钟的历史数据空白，系统的稳定比系统进步更重要。基于此，大部分的乙方和甲方其实并不愿意使用频繁迭代来提升系统的整体性能。
二、新需求的调整
区域内新需求的更新是一直持续的工作，伴随着市场环境的变换，任何系统都会产生部分功能不能搭配业务模式或实际市场情况，没有一个系统是一直完美的。
如何保持系统与业务模式和市场情况的匹配度，甲方可以从2方面入手：
1.每月保持一次实际业务的实地跟访，从最一线的使用者口中得知的消息是最准确最真实的，
从而实地跟访能保证甲方获得最有力的系统修正理由和修正的方式。
甲方的跟访不仅要停留在新需求的访谈收集，已有功能的使用性修正需求收集，更为要注意的是系统的‘体验性’，符合逻辑的流程并不代表具有很好的使用者体验性。
笔者曾经管理的一个SFA项目中，软件端展示当日订单信息，还能够展示过去14天的订单，并且筛选条件有商圈、路线、客户名称，设计上逻辑清晰，但一线使用者只关心某产品今天卖了几家店，卖了多少，今天一共卖了多少，给他们展示这些就够了。系统的设计和使用者的需求偏差的太多了。
2.甲方项目经理是最重要反而最容易忽视的一环
甲方项目经理一方面承接着营业端的需求，一方面给予乙方项目经理（或开发测试人员）最专业的业务逻辑讲解和系统流程设计和UI指导。
如果甲方项目经理能力稍弱，乙方项目经理可以代写项目报告，可以直接和营业一线使用层接触了解需求，这么做运维基本不会出大问题，但是乙方项目经理很难透彻了解甲方的公司文化，很难了解甲方的公司策略，会在系统功能设计上把握不住方向而偏向于使用层。
举个例子，甲方为争夺市场，会研发很多产品，单个一线营业人员的分销产品多达几十个，而产品价位只有几个特定的价格段。使用层的想法就偏向于按照同一价格段写出货订单，这样简单，每张订单的行数不超过价格段的数量，而按照产品写，就要写产品明细，甚至整张订单会有几十行；如果乙方项目经理这样开发了系统，甲方后期的数据分析就会发现，完全看不到每个店的销售品项和销售数量，铺货率，渗透率完全无从谈起。花费上百万的系统只是取代了纸质订单，仅此而已。
甲方项目经理的资质要求一定要严格，最基本要具有快消行业经验，比如家庭背景是经销商或批发商或零售店，这样环境下成长的人，对销售的理解融入血液，对系统设计的应用背景有深入的理解。
同时甲方项目经理还要具有IT相关知识，比如所学专业是计算机或数学等相关专业，或者在IT公司有过相关从业经历。这些经验会协助甲方项目经理有效判断项目的时间进度和成本费用，避免乙方无故拖延进度和漫天要价。
再者甲方项目经理要有较强的思维逻辑性。一个思维混乱的人很难有效调动周边资源，尤其是乙方的资源。一天一个想法或者根本没有想法会挑刺的项目经理，再耐心的乙方也能学会先冷一阵，让甲方自己先捋清思路，因为乙方项目经理盲目顺着甲方的混乱思维走，即使自己受得了，也会被产品经理、开发人员和测试人员警告：放学等我们，别走！！
最后甲方的项目经理要有很高的情商和协调能力。要能hold住一线，调的动乙方，托的住领导。没有高情商和协调能力，一味地用职位去行使权力，最终的结果很容易变成一线使用层骂你系统垃圾进而拒绝使用，乙方项目经理嫌弃你事情多拎不清而故意拖延进度或拒绝掉合理的需求，领导怪你做事没进度没绩效。
三、主数据的纯净度
系统从上线使用后，系统管理者不会一成不变，人事流动是很平常的事。人事流动对系统的最致命的创伤就是降低系统的数据纯净度。
系统管理者可能是临时调任顶岗的，对系统的管理会疏于形式，造成系统主数据的混乱。反正后面有人来接，我做好做差没太大关系啦，大部分的临时顶岗都会存在这种心理。这样的管理对组织的运营没有太大的影响，但是对系统的运行是有致命的伤害的，因为系统的历史不可以重写，IT部门也不会允许去数据库调整数据，所以系统一天内产生的问题，即使被立即修正，但仍在周数据，月数据，年度数据，下一年的同比分析等方面被反复提及，给高层决策带来困扰。
笔者曾经亲自听一位副总裁说，公司上线3年的SFA系统现在就是瘫在那里。为什么会瘫呢？简单四个字，积重难返！主数据管理从上线开始就没做好，没有严格的输入管控，没有后期的严格审核，没有差异的及时纠正，问题会逐步积累，积累到了修正问题还不如推倒重来痛快的程度，公司各层都失去了信心，系统自然瘫掉了。
那么如何管控好主数据的纯净度呢？
1.输入上管控系统主数据。
首先，能从公司主系统（如SAP）对接的主数据就尽量做对接，这样能保证两套系统主数据的一致性和同步性，一改都改。保持主数据纯净度的同时，还能降低人力劳动量。
再者，一定要批输入的主数据，要设置批输入的限制和错误提醒。批输入数据时多利用excel表格的强大功能，包括限制输入字符的格式，限制输入字符的长短，限制输入字符的有效性序列，这些基础的设置都能使主数据提报人员更清楚的知道应该如何正确填写准数据，并自动校正主数据，减少后续工作人员的工作量。
最后，需要批输入的主数据一定要单独机构审核。单独的审核机构能公平公正负责的对主数据进行审核，保证数据的高纯净度。主数据的提报、审核、核决如果在一个体系内，极容易导致疏于管理产生脏字符或垃圾数据。
笔者曾经管理一个SFA项目，主数据的批输入是地方公司自行审核和批输入，因为人员流失，作业时间紧凑，管理疏松等原因，审核和核决逐渐流于形式，脏数据占主数据整体的30%以上。试问这样的数据呈现出来能有参考意义吗？这样的数据能被管理者认可吗？
2.工作过程中不断地巡检主数据
对主数据的巡检工作分为主动和被动。主动巡检是调配人力资源定时或不定时的抽检地方的主数据；被动巡检是通过日常报表的分析，数据的展示，发现主数据的问题。
主动巡检需要关注管理较疏松的单位，或者基层数据管理者能力薄弱的单位，这样既节省人力又能杜绝绝大部分的主数据问题。
被动巡检主要注意设立沟通渠道，任何单位和个人发现问题后，首先要知道去提报给谁，然后再由统一的管理单位解决主数据的问题。
3.系统采集数据的设置
系统采集的数据，各大厂商对输入字符格式都会有一定的限制，比如输入文字，数字，日期。但是这些是远远不够的，要从数据分析的角度出发设计数据采集的方式，如果采集的数据有具体规范，比如只需要采集货架组数1或2或3或4，那单纯的管控数字并不能保证数据的纯净度，因为营业人员可能会输入5或6或20等等。
笔者曾经听过一个好笑的例子，管理者需要在客户主数据中加入老板生日，提醒营业一线人员在老板生日的时候着重做好客情，但是因为疏于管理，几乎所有客户的默认生日都是系统默认日期1970年1月1日。这里的错误就是只做了日期格式的管控，而没有做更细致的可调整性和调整范围的管控，使系统设计的亮点反而成了笑话和鸡肋。
第三章 乙方系统管理
正所谓想成事，哪个码头拜不好也不行！乙方项目经理想象中的理所当然，笔者可以负责任的说一句：不存在。一切理论假设的成功基本最后能成功都是偶然，失败才是水到渠成。
虽然项目很难做，但是还是可以从很多方面来躲避一些坑，不保证成功，但能减少失败。
第1节 甲方的组织分层
本节主要讲述针对系统管理甲方的组织分层，各层的主要作用和相互关系，以及各层对乙方项目的重要影响。
甲方的组织分层基本都可以归为四层，战略层，决策层，执行层，使用层。虽然各公司的组织架构不尽相同，但乙方要首先搞清各层的人员分布，非常有必要搞清第一战略人，第二战略人，甚至是各层的辅助人。
一、战略层：公司的绝对高层
战略层：字面意思，做战略决策的人，做个比喻就是决定大家朝哪里走的人。
战略层的决定往往依托于行业趋势，咨询报告，内部报告。根据管理模式不同，这三种借鉴资料的比重不同，比如在日式管理模式的公司，行业趋势和咨询报告占绝大比重，内部报告大部分是陈述承接怎么去执行，能不能执行基本闭口不谈；而欧美式管理借鉴内部报告多一些，管理层会优先考虑公司有没有人才能做，团队的配合能不能给予项目足够的支撑。
在甲乙双方的初步接洽中，乙方会着重的迎合甲方战略层，包括给战略层讲述完美的系统架构，完美的系统发展方向，完美的数据分析结果，完美的决策数据支持，完美的开发管理支持团队和完美的系统运维。注意我这里用了很多完美的，是的，因为梦想总是美好的。报告里忽略了太多客观的假设，这些被忽略的“理想人假设”常常导致听起来很完美的战略规划最后做出来完全体现不出当时的承诺的效果。
战略层会很苦恼，为什么这么顺理成章，这么水到渠成的事情，最后竟然给不出结果甚至不了了之呢？想知道为什么请您接着往下看。
二、决策层：公司的高层
决策层：主要负责执行战略，分解战略的人，做个比喻就是决定大家是用走的还是开车走的人。
甲乙双方的战略层合作，往往是行业趋势推动，大家的利益分配是明面的互赢互利，而到了决策层这一层，事情就变得复杂了。决策层是拿薪水的，要养家糊口的。此处省略1万字，是什么自己想。所以决策层只要事情做的合情合理就万事大吉。
对上面策略层，决策层有ABC等几个厂家的候选，对下面执行层，决策层有123等要求，甚至有内部标准评估结构体系，这绝对是天衣无缝的管理安排。
问题出在哪里呢？出在报告的评审和日常的资源支持上。举个简单的例子：一个项目有AB两家竞争，决策层因为你们都知道的原因想用A，但是不能直说啊，怎么办呢？通常做法就是两种：1对AB的报告给予截然不同的态度，甚至有将B报告的优势提前告知A的；2对B给予较少的关注和资源投入，执行层配合B的时候，安排点别的活，执行层协助B的时候，撤走部分资源，公司事多，大家都忙，情有可原对吧。
决策层通过这样的各种合情合理的操作，就会把自己想要的A成功的通过评估的各项指标达成的方式展现在战略层眼前，战略层自然同意A的方案。那您问战略层也可以找执行层了解啊，怎么可能毫不知情呢？想知道为什么请您接着往下看。
三、执行层：公司的中基层
执行层：配合决策层完成分解战略的推动的人，做个比喻就是决定大家谁开车，谁坐车的人。
俗话说不平凡的人有各自的不平凡，而平庸的人都是一样的平庸。公司高层的管理还可以说是大治以德，但对于人数众多、流动量大的中基层来说，制度的标准管理远比以德服人来得有效。管理模式下复刻出来的执行层最大的优点就是听话，绝对服从，因为你不服从，领导随时换掉你啊，所以察言观色就是执行层的日常工作必备技能。
执行层对于决策层的态度是极为敏感的，反应也是最迅速的，也因为执行层不是决策层，不用为执行结果付较大的责任，所以基本是照搬照抄决策层的决策结果，甚至会火上浇油的扩大来凸显自己的绩效，使好的事情越好坏的事情越坏。
举个笔者听说过的真实案例：AB两厂商竞争，决策层倾向于A厂商，于是在B的报告中会对优势嗤之以鼻，而对于A不及B的地方，会及时的加以提醒。最后执行层得出的结果是戏剧性的，A以100%超高指标通过评估测试，而B以12.5%的评估结果，与A有巨大差距丢失了这个机会。戏剧性的还在后面，A只是从B家挖了两个程序员过去，临时组建了团队，从系统适应性和团队配合度来讲A比B差了很大一截。
因公司架构不同，如果策略层和决策层都比较公平公正，那就轮到执行层出问题了。不过这种机会比较少，因为执行层人员略多，一个人的倾向对于项目整体方向的左右毕竟有限，但也不是没有操作空间。
还是举个笔者听说过的真实案例：AB两厂商竞争，执行层因为你们都知道的原因倾向于A，于是就把人力资源全部布置到A上，办公室的人力协调调度，多余的人力出差协助A测试；这样就没有多余人力支援B的评估测试，B只能干等。大家都知道上层布置的事情不是无限期执行的，都有最后期限，到了最后期限，B还没有被评估或测试进展明显落后于A。结果大家都知道啦，A会以团队已磨合和技术已接洽等绝对优势被选择，因为甲方已经没有时间再和B做漫长的评估了。
四、使用层：公司基层或基层管理者
使用层：最基础最前沿的系统使用者，就是开车和坐车的人，战略层/决策层/执行层运筹帷幄之中，使用层的使用效果才是决胜千里之外的关键。
从策略层的支持，决策层的资源配置，执行层的精力投入，项目的成功本来是顺理成章的事情，不过通过上面您读到的内容，您应该清晰的感受到了，使用层可能最终变成了受害者或者那个坏事的’临时工‘。策略层的行业趋势没有错，决策层的标准评估没有错，执行层的精准执行也没有错，错在哪里了呢？这个问题留给看到这里的乙方项目经理吧。
第2节 系统演示和测试
在标准系统的演示和测试中，甲乙双方的关注点和思考点并不相同，乙方应该注意甲方关心的点，避免造成我有心问，你无心答，双方错失合作机会。
一、演示要弄清甲方的系统诉求
乙方需要弄清甲方组织分层的同时，也需要搞清甲方的系统诉求。这可能需要乙方有优秀的客户经理来沟通甲方人员，在演示之前保证演示的系统产品能够满足甲方的系统诉求，并给予甲方最优的系统解决方案。笔者并不认为这是不正当竞争，反而这是一种积极合作的表现。因为每个甲方的情况并不一样，而乙方的标准产品可能具有很系统性的解决方案，谁也没有办法在一个简短的会议中展示出全部系统功能，所以直中诉求的演示，才是对甲乙双方负责任的表现。
乙方的客户经理的时间并不多，可能从双方接洽开始就需要着手准备这些事情，包括认清甲方的目前问题和最终诉求。客户经理可以从认识的人或接洽的人展开，然后逐步接触到项目的核心人物去了解甲方的诉求。最近网络一句名言说得好：没有什么事情是一顿火锅解决不了的，如果有，就两顿。
其实并不是单单只有乙方是想将系统方案靠近甲方的诉求，甲方是需求方，更希望乙方给自己一个100%贴合的方案，拿过来直接上线，有比这种方式更简单的吗？但是如果甲方给予乙方过多的指导，就有泄密或利益交换的嫌疑，所以大家场面说话都是七七八八始终不能坦诚相见。
笔者曾经评估一个系统方案，AB两个厂家都是行业的先锋，旗鼓相当，但是提交了两轮报告，每家的报告都是几十页，还连夜修改，却不达重点，完全不能给予我们明确的方向和执行措施。在第三次汇报之前，笔者实在忍无可忍，给双方的项目经理致电，告知报告不要再写几十页，简单几页说明这阶段需要的123就好。
二、测试要保证系统贴合业务模式
乙方介绍完完美的解决方案之后，甲方会请乙方提供测试系统已证明完美的方案所言非虚。
这时候乙方常常因时间紧张而准备不充分，比如系统搭建不完整，权限配置不完整，产品数据不充分，客户资料不充分，数据展示有逻辑错误。这些都是乙方情有可原的不足，但是却是甲方非常关注的地方。测试时乙方给甲方展示的一定要是逻辑完善的系统，没有一个甲方会相信乙方承诺上线后会修正，签约后会调整。这些承诺往往都伴随着紧张的上线而稀里糊涂的过去了，或者在后续的运维中让甲方无比头痛。
当然不是所有的乙方都会漫天承诺，即使自己做不到的也是事前承诺。但是大部分甲方肯定会有过这样的经历，没有人会善良到让谎言再来一次。所以一个完整的测试系统的演示，是乙方负责严谨的工作态度，也是甲方完善的系统方案的保证。
三、做好甲方项目团队的顾问
测试环节单纯依靠客户经理拉客情就不能解决全部问题了，项目经理必须跟上进度，准确把握项目进展，提前部署，走在客户的前面。天天等甲方来叫的乙方，首先给予甲方的感觉是配合的积极性有问题，未签约尚且如此，钱到手是不是就找不到人了？再者可以给予甲方不专业的行业形象，不能布局在甲方前面给予顾问式的建议，而是单纯的做一个接收者。
甲方的项目管理不一定是标准的周会才需要了解进度，乙方的项目经理和客户经理最好有新的进度和项目变化及时告知甲方相干关系人，如果认为自己不能做好节点管控，那就事无巨细的咨询甲方，乙方这时候切莫以为甲方会觉得你很烦，其实恰恰相反，甲方会认为你在全力以赴，他的担子就轻了，谁不愿意有空坐下来喝杯茶水呢。
第3节 系统功能优化
系统上线初期，因为甲方对各厂商的系统的综合性考量和评估，最后选择的乙方的系统方案是比较合适的解决方案。
但随着技术的发展，乙方产品的迭代升级和一些辅助性工具的技术升级，使甲方使用的系统变得落后以及相对的低效率，甲方会渴望不断优化自身系统，提高工作效率。但乙方对于系统升级这事的态度比较微妙，下面简单说明下系统优化过程中乙方的表现。
一、多一事不如少一事
即使乙方取得了技术的升级，通过迭代升级可以提高系统的整体性能，也不一定会积极部署到甲方的生产机系统上，尤其是在甲方本地部署的系统。
乙方如果提供免费升级，要提供人力和资源测试系统兼容性稳定性等一堆指标，搞得不好宕机了，罪责可大了。如果不提供免费升级呢，甲方也照常使用，也不会出问题。所以从乙方的角度出发，多一事必然不如少一事，还是维持原系统更好。
笔者曾经管理的一个手机端定位功能，13年上线的时候，定位偏差达到400米，到16年底，还是维持着400米的偏差水平，上线3年从未更新过。而大家知道13年的导航水平很差，路线总是偏离，但到了16年，滴滴打车这些软件已经能把位置定的很精准了。经笔者强烈要求更新后，乙方在一个月内升级了定位功能，定位精准度提高了，能给予一线使用者更优的拜访路线规划，也能给予一线新人最精准的门店导航。
二、要优化就得收钱
乙方通常会利用甲方IT技术薄弱而虚报系统优化项目。乙方可能将公司技术的迭代升级说成新的技术功能而卖给甲方，也可能会将甲方的优化需求扩展为功能需求而卖给甲方。这些是乙方利用甲方的弱势而刻意曲解甲方需求进行销售的行为，这也是乙方前期要价过低而后期追回利润的惯用手法。
笔者曾经协同管理的一个项目，因公司策略调整，需要在主数据中启用一个备用字段。因笔者在出差，同事直接接洽乙方项目经理谈需求，结果硬生生的将一个字段需求谈成了一个2个月后交付的新增功能需求。
除了上面谈到的乙方对于系统优化的态度方面，乙方对系统优化所交付的质量也至关重要。
三、系统优化不见成效
甲方可能乐于督促乙方提供新的系统技术来提升系统的性能或给予营业使用者更优的系统，甲方的市场营业部门和IT部门合作，确定乙方可提供的技术优化，乙方依据甲方提供的优化指标进行系统优化。乙方优化后系统没有体现出更优的性能，使用者没有感受到更优的使用体验，这会影响甲方对乙方产品优化的信心，对乙方的专业度产生质疑。
四、一优化就出问题
如果乙方优化升级经常导致系统出现问题，甲方会比乙方更担心系统优化。如果甲方因系统优化而宕机产生的指责大于绩效，那甲方宁愿选择可以升级而不升级。这样系统迟迟得不到优化升级，在IT技术飞速发展下，很快就会被新的解决方案所超越，甲方也很容易选择新的解决方案。
综上所述，乙方在系统优化升级中的态度和质量对甲乙双方的合作都起到了很重要的作用。完美的方案是可以想象的，高超的技术是可以复制的，但是乙方的态度和质量是环境的综合结果，应当引起注意。
第4节 系统运维管理
乙方的项目运维方式依照甲方的项目级别来设置。如果甲方的预算能达到一定量级，乙方就会投入专门的人员来运维，保证全天候的系统维护；如果甲方的预算达不到乙方的期望值，乙方通常会将甲方的运维分解给公司各团队，大家都分担一点，使甲方看似是有个团队在做运维。总言之是看利润来进行人员和资源配置。
如果甲方每年有充足的预算，运维过程中系统也会适应公司策略和市场环境的变化而改变。但是这种模式下，甲方的人力投入和资金投入是非常巨大的，一般的公司很难承受这样的成本压力。
对于更多的甲方，系统上线后，功能趋于稳定和成熟，不需要再投入巨额开发费用，只需要维持系统稳定和些许的功能优化和升级就好。乙方在这种情况下很难再赚取高额利润，转而将人力投入到新的项目中。
在如上的背景下，大部分的甲方系统的运维就变成了多个甲方对应乙方多人的模式。甲方自身是否还有专业的人员去管理暂且不论，乙方是肯定没有专门的团队去管理了，最多一个挂名的窗口人。这就是乙方常说的开发团队即运维团队模式。
我们来假设几个情景，不需要过多牵强的假设，我们就会看到这样的管理模式对于系统的影响。
第一个情景是最常见的乙方项目经理离职。甲方的客制化需求越多，乙方项目经理个人想法和思维习惯对于系统的影响就会越大，甚至系统的整体设计规划都带有明显的项目经理个人色彩。这样的项目在运维过程中，因项目经理的离职，很难有熟悉的项目经理能顺利接手。新的项目经理看到的只是一个最后的结果，很难去理顺系统设计的思路和系统设计中规避的问题，造成走一步一个坑的尴尬处境，然后被甲方病垢，甚至造成项目的流失。
第二个场景是项目经理带过多的项目。目前大多的甲方公司并没有注重培养自己的项目经理，就像笔者一个乙方朋友所说：甲方项目经理好的留不住，留下的混事的多。乙方项目经理在工作中承担了过多甲方项目经理应该执行的事情，甚至甲方向自己上司报告的PPT都是乙方项目经理代写的，在这种强度的工作下，一个已经成功上线，并且进入运维阶段的系统，能够受到多大的关注？站在一个合情合理的角度去看待此问题，乙方项目经理也会选择优先照顾当前开发的项目，利润更高，业绩更高，奖金更高！吃青春饭的行业，有几个想着拉回头客。
对于甲方无项目经理可用，乙方项目经理无时间的情况下，如何做好系统的运维保证系统的正常运转呢？笔者给出一些拙见供读者参考，且并不过深的涉入乙方的内部管理。
一、文档的完整性
乙方开发过程中，开发文档的归集工作都会安排，但是很难强硬的贯彻执行。一方面是项目经理任务繁重，能忽略的资料就尽量忽略，能不更新的资料就暂不更新；另一方面是过程中的资料比较混乱，很容易暴露项目经理的自身问题。文档不完整，接手人很难看到系统的全貌，对系统的理解不透彻，运维工作很难顺利开展。
二、文档的过程性
乙方项目经理迫于管理压力，会后补文档。这种后补的文档基本是照着结果编过程，对于接手的人完全没有借鉴意义。文档所展现的阶段性过程，记录的开发过程中的弯路，才是接手人需要汲取的宝贵经验。宝贵的开发经验可以避免接手人把开发过程中的弯路在运维阶段再走一遍。
第四章 甲乙双方管理常见误区
第1节 合同款项支付
甲方管理团队上班是为了领薪水挣钱，乙方团队做项目也是为了领薪水挣钱，所以甲乙双方的关系除了系统本身外一个重要的制约因素就是合同款项支付。合同款项的支付是甲乙双方博弈的一个重要棋子，运用的好大家其乐融融，运用不好很容易陷入系统管理的泥潭，互相埋怨。
甲方团队最容易的误区就是我是客户，我是出钱的，我是上帝，凡事听我的。一般去了饭店，一招手对着服务员大喊：‘服务员，过来！’都是这个心理倾向。对系统项目的管理，甲方同样会保持这种态度，随时召唤乙方项目经理或高层，随时安排不计工时的工作让乙方尽快完成。如果乙方不满足甲方的随叫随到，就拖延合同款项付款期，延误乙方的应收款，理由嘛，哪个系统是完美的呢，莫须有的理由也是比比皆是。
甲方除了我出钱我是上帝的心理外，还有一个就是空手套白狼的心理，花小钱办大事，又想马儿跑的好又不给马儿吃草。厂商有意向合作之后，客户打着测试系统的旗号，不顾乙方资源投入的成本，在测试阶段就按照自己的客制化需求要求厂商配合自己大改，能改的厂商就留下，不配合的厂商就是能力不足，技术实力不足。甲方在系统评估阶段就做完了部分签约后客制化开发的工作，自认为没花钱就把需求做好了，赚了大便宜。
合同款项延期支付，最倒霉的还是乙方。人力成本、时间成本已经投入了，甚至有的集团合作项目人力投入6个月以上，客户都没和厂商签约，连最基本的甲方乙方都不算。项目经理为了服务好客户拿下项目，天天喊着客户又有新需求，我需要开发，我需要测试，我需要设计。这时候乙方高层很为难，给这个项目资源吧，项目做不成钱收不回来，老板不愿意啊；不给这个项目资源吧，客户不满意了，项目直接跟掉了中发现还有没考虑到的，公司高层又指点了一下，需求变成了AB；需求变成AB之后又会牵扯出C；需求变成了ABC，远超最原始的需求A，但是合约付款还是按照A的付款，乙方利润被进一步压缩。
从上面的具体描述中，不难看出这是一个怪圈，一个恶性循环。甲方想空手套白狼，乙方也不傻，不给足够的资源配置。最终就这样：甲方没钱--乙方没人--甲方有需求--乙方没成果--甲方拿不到成果不付钱--乙方更不敢给资源--双方合作意愿下降--甩锅大战--各回各家，各找各妈。
想要跳出怪圈就需要双方都具有契约精神，尊重合约的条款约束。甲方做好系统发展规划，就像在第二章第4节所述一样，要求甲方的项目经理要有足够的规划协调能力，依照既定合约要求乙方按时按质完成项目交付，并完成付款，保证乙方可以按时完成业绩。乙方要负责的告诉甲方具体开发行事历并及时通知甲方开发进度的变化，保证甲方的项目进度，甲方才可以有据可依的按时付款。甲乙双方要把丑话说在前面而且要多沟通勤沟通，有些话提前说出来的确不好听，但是绝对好用！
第2节 双方权责不清
甲乙双方的权责不清主要体现在项目的运维管理中，也有甲方会在项目初期过分依赖乙方，这两种情况都会导致项目不顺，问题归属不清，后续处理自然无法顺畅，最后的系统问题的苦果，还是大家来承担。所以对于项目管理的甲乙双方，还是前期将项目管理中的权责划分清楚为好。
系统上线后，甲乙双方都希望系统能够正常稳定运行，但是往往事与愿违，运维中出现问题的概率比上线时出现问题的概率还会大。笔者听过甲方管理团队发自肺腑的感慨：‘他怎么可以犯这种错误，用脚后跟想一下都不会犯这种错误！’
一、甲方作为营业端和乙方之间的桥梁，起着至关重要的翻译、统筹和协调作用。
1.营业端的需求问题需要甲方转换为乙方可接受的具体说明类语言。
举个例子，营业端反馈：系统登录太慢了，我出门都到店了，还不能进店。甲方转换为乙方可以接受的语言就是：系统数据同步时间过长，影响营业人员做拜访前准备和及时拜访门店，请将同步时间保证在3分钟之内。
上述例子中，甲方就做到了翻译营业端需求，并给予乙方明确的问题说明和修正要求，乙方承接问题也会顺畅的调配资源去验证并给出解决方案。如果甲方直接将此问题原封不动的扔给乙方项目经理，项目经理就会从多方面去考虑了，网络问题，手机兼容问题，服务器问题，最后是系统问题，可能要花费较多时间才找到是同步的问题，浪费了乙方项目经理的时间，也挫伤了乙方项目经理的积极性。
2.甲方需要统筹资源为乙方项目经理开展工作提供支持。
举个例子，乙方上线营业系统，甲方需要提前组织内部沟通此事，并将项目背景，项目目标等信息准确的告知基层团队，获取基层团队的理解和配合以及支持。这样甲方为乙方调配好资源，乙方只要进行专业的技术实施，就能完成系统上线。如果甲方直接将上线名单扔给乙方，乙方去部署上线，甲方的基层完全懵了，不了解背景，不了解真实目的，唯一敢做的可能就是明着接受暗着阻止。
请注意，以上不是笔者假设的案例，这是真实的案例！
3.甲方还需要协调乙方处理营业端的需求和问题的进度。
甲乙双方是合作关系，但是当营业端的需求和问题暴雨般袭来的时候，甲方不能仅仅是站在甲方的角度思考自身绩效的问题，而是要综合考量整体项目的管理，甚至包含乙方内部的管理，甚至要‘站错队’的充当乙方的保护伞。
营业策略变化和系统升级之后是营业端提报需求和问题的高发期，营业端对系统给予厚望，希望系统能协助工作，如果甲方同样将所有需求都一股脑的扔给乙方并勒令一定期限内完成，笔者相信乙方项目经理想死的心都有了，而且也很难按照甲方要求完成。甲方要协调需求和问题的轻重缓急，进行分类，并结合乙方的资源配置，给予需求和问题提报方回馈，协调最优的处理和改善进度。
二、乙方作为系统开发测试的负责人，对系统的稳定性和友好实用性起到关键作用。
1.乙方要保证自己充分了解甲方提报的问题和需求的适用场景和目的，设计调整系统对营业作业产生良性的正面辅助。大部分的乙方项目经理会管理多个甲方的项目，而且营业体系的了解浮在表面，没有深入了解，所以对甲方提供的系统问题和需求，会产生了解不到位和设计不到位的问题，可能造成系统成为业务人员作业负担的尴尬处境。
举个例子，甲方因为业务的不断开展，对系统的要求不断精进有A,B,C的要求，那乙方的的项目经理应该深入考虑甲方ABC三个需求的目的和截至当前的甲方营业人员的使用现状，并考虑三项功能是否可以合并或调整页面进行优化显示。
2.乙方要保证系统迭代更新、需求升级和问题修复升级后，系统不会再出现新的衍生问题。
乙方不论甲方提出的要求有多不合理，既然要交付项目，必须保证项目的可靠性。大多数情况下乙方的工作比较紧张，会对甲方的单个要求尽量压缩投入的精力，甚至会忽略品质而盲目追求完成工作时间要求，即使有问题也是上线交付之后的事，先过交付这关。
乙方这种过一关是一关的游戏模式，实际中并不会再给乙方重开一局的机会，甲方和甲方使用者会对系统失去信心，甲方不敢再试用新功能或提出新需求，乙方也就无法取得新的合约和款项。
第3节 甲方团队内乱
堡垒要从内部攻破，甲方的内乱总是造成系统项目失败的一个重要因素。甲方的内乱一般分为小管理团队的内斗和管理模式的混乱。其实这都是大家司空见惯的事情，但是今天笔者分析下甲方内乱对于系统的管理有着多大的伤害。（避免内乱的有效管理方式第5章会详细介绍）
一、管理团队的内斗
如果说集团内派系斗争还是讲究一个动态平衡，管理团队的斗争就是你死我活的兵刃相见了。尤其是一个项目管理中有几个人的时候，斗争更加惨烈。
最标准的项目管理方式，甲负责A部分，乙负责B部分，丙负责C部分。
如果甲和乙很合拍，但是两人和丙不合拍，从工作配合可以看出来，怎么看呢？这时候会呈现这样一个趋势：A和B的部分衔接的很顺畅，不需要领导者出面调停或安排具体事项，但是A和C的配合，B和C的配合就不那么顺畅，一些很小的决定性的东西，都需要领导出来拍板做决定，也就是一些常说的微权利下的决定也需要领导来做。这就耽误了系统的整体进度，同时法不责众，领导在这种情况下也不好挨个批评。
这还是算和谐的团队了，如果在斗争激烈点，甲和乙会故意在A和B上留下弊端，导致系统项目一到C部分就卡壳。假如甲和乙发现了C部分的问题，也不会提出来，就等着C部分卡壳，然后丙被领导批评。套用朋友的一句经典名言：有时候置人于死地，只需要保持沉默。
上面描述的故事大家已经看出来了，甲方管理团队的内部斗争已经严重的干扰了系统项目的正常进度和发展，造成了‘明明都知道问题在这，但是就是没人提出来修正’的尴尬局面。
管理团队的斗争对系统的管理是致命的，因为你永远不知道谁会在哪里布置什么样的陷阱。
二、管理模式的混乱
甲方管理模式的混乱主要体现在对于系统管理有规划但是不执行或不严格执行。最终形成会哭的孩子有奶吃，朝中有人好办事的官僚气氛，另使用者失去对系统的信心，然后逐步的管理层和使用层划清界限，阻碍系统的良性发展。
1.甲方工作责任不清楚，几个人负责同一件事，没有主次之分，容易出现混乱。这种事情往往不是主管规划不清楚，而是工作进行中的因为时间节奏或人员效率等原因，不同的人对工作不停的交接和协助，导致工作责任混乱。
2.问题处理管理混乱，任意形式的问题都接受，然后以随意的形式转给乙方。这样的管理模式会加重甲方对问题的处理汇总难度以及追踪难度，总是每月例会前将所有问题汇总起来才发现，有问题可以处理却没有被及时处理，对使用者造成了较长时间的困扰。同样的问题，会困扰乙方，漫天的问题和要求，工作计划随之慌乱。
综上所述，大家已经意识到甲方的内乱对系统的管理造成了诸多的问题，也造成了使用者对系统的抵触心理，所以甲方需要建立内部明确高效垂直的管理模式，以避免内乱对系统管理的伤害。
第4节 乙方团队滞后
有个比较生动的比喻是这么说的，乙方的产品经理是系统的亲妈，项目经理是系统的奶妈。简单一个称谓，却是道出了精髓。与甲方接触最多的项目经理，他的工作态度和行为风格对系统的良性发展起着决定性的作用。尤其是乙方项目经理对项目交付和运维处理的滞后，会让整个项目管理陷入泥潭。
1.项目交付滞后
乙方项目交付滞后的原因有很多，总体来看主要分为乙方项目经理手上项目过多，甲方提报问题过于集中，甲方提报需求不清晰这三类。
乙方项目经理一般都不会只带一个项目，所以各项目间的冲突是很平常的事情，能否有效协调项目间的冲突也是考量项目经理能力的重要指标。项目需求的协调考量的因素很多，大家容易理解的是每个项目经理的风格不同，有爱说的有稍微闷点的，有条理清晰地有小糊涂点的，有耳根子软的有原则性强的；加之甲方的管理风格也是不同的，有事无巨细的有不管不问的，有风风火火的有火烧眉毛不着急的；再者就是项目的进展程度不同，上线初期、运维阶段、续约时期双方的环境处境都不同。以上这些都是项目经理要考量和协调的，最后再考量项目功能自身的作用和影响以及上线时间要求，乙方项目经理排完计划后，必然就造成了一些项目优先执行，一些项目的滞后交付。所以项目交付的滞后是每个项目管理中必然存在的事情。
再者，甲方需求得集中提报也会造成乙方项目交付滞后。因为甲方经营策略的调整或行业内出现的新的走向趋势，系统要随之改变以适应营业需求。如果甲方是引导性的改变，乙方可以逐步修正，但大部分情况是甲方被动改变，看到竞争对手的变化而奋起直追，这时候就出现了大批量的需求而且领导层给的时间也是有限的，因为领导层要看到数据结果并参考进行决策。乙方项目经理因为这样的‘爆量’而往往很难调配到足够的支持资源，就势必导致项目难以在规定时间内交付，造成名义上的交付滞后。
最后再看看甲方提报需求不清晰造成的项目交付滞后，这类问题应该归属于项目管理沟通问题。众所周知乙方项目经理会全心全意配合甲方，甚至会承担部分甲方自身的工作以获取甲方的支持和给予的便利。所以乙方项目经理在‘自身明白’的情况下很少会再次询问甲方更多的问题，至少可以避免甲方烦感和不屑。而甲方的项目管理团队是否真的理解了领导层的真实意图和目的也是一个未知的事情，相信很少有甲方的管理层会在会后再找到领导层问问领导这句话是什么意思。所以新的需求可能在最开始的时候就没有被完整的规划和反复推敲，乙方项目经理再以IT思维去处理这样不禁推敲的需求，最后的结果可能就与领导层想要的差之十万八千里。领导层的批评指点后，项目还要再次返工修复，以致延误上线日期，最后导致项目的交付滞后。
2.运维问题处理滞后
乙方项目经理在系统上线完成之后，会立即转去新的项目，虽然已上线的项目仍旧管理，但精力和时间的投入比系统上线时期肯定是大打折扣。
再者运维时期大多厂商采用的是团队管理的方式，虽然指定了窗口人，但只是一个沟通协调的窗口，运维中的问题还是需要窗口人后面的支持团队来配合完成。能不能及时的争取到足够的人力来解决甲方的运维问题就是问题处理效率的关键性因素。
虽然乙方项目经理或窗口人有自己的难处，但是对于系统运维的质量是必须要保证的。系统运维问题处理的滞后一方面是影响甲乙双方的合作，最大的影响是挫伤营业使用者的使用热情。换位思考下，如果读者是一位一线的使用者，每天工作很辛苦，系统有问题，提报了但是迟迟没有答复，或者是有答复却迟迟没有的到有效处理，一次这样可以理解，两次这样可以谅解，三次这样基本也就放弃提报了。一旦一线使用者放弃使用的信心，管理团队收到的就是无尽的指责而缺少良性的建议和意见，这种情况下系统管理怎么可能会取得良好的绩效？
第五章 SFA系统的运维
系统上线时期甲乙双方都会对系统又寄予厚望并投入较多的人力和资源，系统上线后进入运维阶段，甲方会逐步放松对系统的运维管理并减少资源投入，这导致原本很超前的系统被逐步落后以至于积重难返被淘汰。所以管理层对系统持续性的关注和适当的调整是运维时期的关键点。本章主要介绍系统管理过程中运维的处理，从运维问题处理的机制，问题的梳理，时效性管理，交付和验收等五方面逐步介绍。
第1节 问题处理机制
系统运维时期的系统问题处理机制，是甲方应该持续关注的部分。问题处理机制是否有序运行关系到整个系统的稳定，用一句中医理论讲就是：通则不痛，痛则不通。
系统问题管理是项目管理的一部分，在项目管理学中是需要在项目规划初期就要设计和规划的项目管理职能。大部分的项目管理团队都会依据所学设置问题处理机制，但是多限于一句话或者简短几行：问题出现由谁谁处理。实际运作中，当问题真正出现的时候，基本还是谁能处理谁处理的混沌管理模式。
依旧重现上文提到的某个SFA系统，这个系统每个月不宕机一次这个月肯定过不去。系统宕机之后，5席的400咨询热线打爆了，每个营业部销售助理的电话被打爆了，月底人资结算奖金时候，电话也被打爆了。为此，管理团队还特意制作了一套表格，供宕机的时候，由销售助理人员填写因宕机产生的差异，然后一层层逐级上报至管理团队，管理团队审批后，销售助理和人资在核算奖金时做调整参考依据。整个公司都用这个方法，从上到下超过1万直接人力参与！
笔者接手之后首先找到宕机问题的症结：甲方需求变化快且说明不充分，乙方开发测试人力紧张。合着甲方乙方都是稀里糊涂，就营业一线团队和销售助理、人资单位锱铢必较，因为他们要核算业绩要发工资啊。
为了保证系统不再宕机，笔者无缝衔接乙方项目经理和测试人员，并且带乙方项目经理走到一线，了解公司的一线营业人员每天在做什么，需要的系统支持是什么，以及为什么需要这些系统支持。在反复教导学习下，保证乙方项目经理充分认识到需求的目的和作用后，笔者再单独联系乙方测试人员，讲解系统层面的需求以及目的，保证需求后期测试的完整性。笔者同时申请上级给予更多时间，将系统任务分解，给予乙方充足的开发测试时间，以保证需求上线系统稳定。
同时公司的项目管理团队由5人逐步缩减为笔者自己，如果依照之前的运作模式，单纯的靠一个人做规划，培训，后期运维，不被累死也会被骂死。所以笔者第一步就是梳理系统问题的整个处理流程，从提报到处理完成的回馈重新梳理。在要求乙方项目按时按质的交付后，要求并强化统一由400咨询热线提报问题的机制，所有使用者的问题必须拨打400热线，由400客服人员记录和继续提报后续处理人，同时400客服负责追踪处理结果。这样笔者从邮件、电话、QQ、微信等杂乱的问题形式中解脱出来，同时使用者也明确知晓了有问题该提报给400热线，并且400热线也会及时告知问题提报人问题的处理进度。
笔者要求400热线要起到问题处理枢纽作用，甲方乙方所有团队接受400客服人员调动，包含笔者自己。400热线一方面要承接营业使用层的问题提报，然后分类整理后递交后续处理人，另一方面要及时提醒后续处理人处理问题并追踪处理结果。同时笔者要求400热线做到提报问题无论处理结果如何，当天内必须进行电话回访问题提报者，告知问题提报者问题处理的最新进度。同时400热线要提交日报、周报、月报，保证系统管理团队对系统的动态监控和问题的趋势判断。
利用如上的管理机制，系统由每月一次宕机变为始终未宕机，稳定程度超过同期宕机一次的SAP系统。400热线的问题提报量从之前的5000-7000通/月变为700通/月上下（700通还包含咨询类、数据查询类提报），得到公司高层的认可。
综上所述，对于系统运维时期的问题和需求的处理，明确高效垂直的管理机制是非常必要的。
所谓明确，就是人员职责分工要明确，产生的问题要有明确的处理方向，明确的处理人和处理时间，任何项目管理团队里的人都知道某类问题的归属和后续处理人。
所谓高效，就是系统管理的工作效率要高，提报的问题要按照岗位权责按时按质完成，不能无故拖延。确实不能完成要提前沟通，不能等项目交付时提出许多看似合理的理由。
所谓垂直，就是要减少管理团队的决策传递过程。管理团队做好系统管理，将细致工作分配至其他功能或助理岗位，并且有权限直接调度协调相关资源，不能出现一个问题，还要再签几个主管再做行动。
第2节 营业问题梳理
本节主要介绍营业问题的分类和相应的问题处理方式。明确的问题分类，有助于甲乙管理团队迅速的确定问题；明确的处理方式则有助于提升问题解决效率，减少问题的爆发式提问，降低系统的宕机风险。
一、系统问题分级
依照运维对系统问题的定义，一般将问题分为4级。
第一级：对正常的业务操作可能产生严重后果的非常紧急的问题，比如：生产系统宕机。
第二级：可能引起业务操作无法在生产机上进行的紧急问题。
第三级：影响业务操作的重要问题。一般这类问题都是由不正确的操作或者新的开发配置引起的。
第四级：对正常的业务操作影响不大的问题。这类问题一般只涉及一些偶尔使用的功能或开发配置需求。
同时甲乙双方会对分级的问题进行首次响应时间的约定，例如：第一级非常紧急1小时内响应；第二级紧急2小时内响应；第三级重要4小时内响应；第四级正常8小时内响应。
首次响应时间只是乙方项目经理或窗口人给予应答的时间，具体问题的判断要甲乙双方协调配合商讨，以确定后续问题的解决方案。
二、系统问题分类设计
甲乙双方从上线到运维，会遇到很多营业提的问题，这些问题有些是个人的问题，但大部分是很多人的共性问题，这些共性问题在解决后，可以记录成册。一者可以给后续的系统项目管理做参考，二者可以给系统管理内流动的人员做学习材料，再者问题手册系统上线和运维的宝贵知识财富，应该给予尊重和传承。
营业系统问题可以按照多种维度分类，比如按照平台分类：手机端软件和后台；也可以按照使用者分类：管理员、主管、业务代表等。分类没有好与不好，只有合适不合适，各位读者依据自己公司文化风格自定。笔者建议分类不宜超过5类，这样手册使用者能很快记住分类并快速使用手册；有些问题并没有很明显的分类界限，分类过多过细也会导致问题归属的混乱，使用者不容查找到相关问题。
问题大类分好后，还要细分小类，然后再逐渐细分到具体问题。这种树状结构的分类层级尽量保持在4层之内。大类下存在一个层级的小类，然后是具体问题，是最优的；这样能使使用者在3步之内找到问题和相关答案，步骤再增加会增加使用者的烦躁程度，影响手册的使用体验。字典大家都用过，没人会质疑字典的权威性和专业性，但是大家很不喜欢用，因为查找起来太费劲了，单单翻到检索页都不止3步。
三、系统问题展示的用户体验
营业系统的梳理除了侧重问题的记录外，还要注重用户体验，力争在3步之内找到使用者想要查找的问题，最多不得超过5步。
举个例子，目前微信公众号流行，各大银行相继推出公众号。有一类公众号的客户互动是非常让人反感的，就是需要客户输入代码然后回复客户相应的业务请。比如请你先输入个位数，然后再输入十几的两位数，然后输入二十几的两位数，不知道这个设计者自己是否体验过，谁有时间和心情在想寻求答案的时候玩数字游戏呢？
如果乙方提供知识库功能，可以借助知识库分类设置和快速搜索功能让使用者快速找到问题及答案。同样搜索条件不宜超过3项，并一定要支持模糊搜索和拼音搜索。模糊搜索用于使用者不能明确问题的具体描述和分类情况下使用，拼音搜索用于使用者对打字不熟悉或者在陌生环境不方便打字情况下使用。
如果甲方自建问题手册，可以使用word的强大文本编辑功能。使用word要注意一定要显示大纲，使用者可以在大纲内筛选问题明细。自建手册同时建议增加工具类信息，比如系统常用的网址，一些系统常显示的英文语句的翻译。
第3节 问题处理时效
问题处理时效是一个综合性的问题，这里只说下具体的处理时效的界定和要求。
如第1节所讲，问题的分类不同，响应时间不同，但规范的也只是响应时间，就是乙方工程师接受这个问题了，开始处理了。至于这个问题什么时候能处理好，系统恢复正常使用，就是问题处理时效应该界定和要求的事情。
1.立即处理的问题
宕机的问题影响到所有营业段的人员工作效率，这个是毋庸置疑的具有优先最高级处理，这种问题基本是要调动所有能调动的人员连夜加班也要处理完毕的，这种问题的处理时效就是从接受问题开始处理，基本就不要停，直到处理完毕。
2.可以延缓的问题
系统内部的模块和功能很多，如果出现问题的功能涉及一小部分人员和流程，问题处理就可以稍微放慢。甲方尽力协调乙方项目内人员，并尽量不影响双方的工作计划。这个尺度的把握就要看甲方和乙方的合作关系和出问题的功能模块，根据情况再具体分析。这个处理过程甲方切记不要强压乙方立即处理，甚至一个电话直接打到乙方老板那里去。为什么这样提醒，请甲方项目经理自己思考。
3.可以考虑的问题
这部分问题严格上说不能算是问题，属于需求类，但是因为提出的人不同会有不同程度的处理要求。总裁提出来的需求或优化，必须优先完成！最好下次迭代升级时候就看到效果，所谓做事不由东累死也无功。通过走访一线或者基层管理人员提出的需求或优化，要根据预算和年度计划合理展开，同时适当拒绝部分不合理的需求或区域性需求。
第4节 运维问题交付
笔者一直认为，潮水褪去才能知道谁在裸泳。项目上线初期，甲乙双方高层都极度关注，人力资源和其他资源也是玩命的堆加，项目想做烂都难。但是项目进入运维期，双方的关注度都降低了，甚至不再关注，这时候能够妥善处理问题并且完美交付的团队，一定是很棒的！
运维问题的交付是乙方应该着重注意的问题，主要涉及两个方面：1.已有系统维护的质量是考虑未来是否继续合作的重要指标；2.系统维护的质量也间接决定了行业内的口碑。
目前因为乙方需要业绩，需要不断寻找新的客户，然后人力资源和其他资源大部分铺到新的项目上，已经做好的项目的运维就着实的差了一大截，再加上双方已经有了合作，关系比较近，即使完不成运维问题的交付，甲方也不会轻易翻脸摊牌，乙方一句认错或者正在抓紧修复，就可以平息此事。
甲方在运维合约中一定要明确问题的分类标准和相关的处理要求，重点是惩罚条款。合同才是保护甲方自己的有效武器，如果可以接受，甲方不惩罚，如果不可以接受，就按照条款进行惩罚，有理有据。
惩罚的目的不是为了惩罚，而是为了要求乙方更好的处理运维的问题，给予更好的交付质量，保证系统的稳定使用。
第六章 SFA系统的成功之道
每个乙方厂商开发的营业系统不同，使用技术、系统架构、数据结构等等都不同。每个甲方要求的系统功能也不同，精准的日式管理，粗放的欧美管理。不管是哪个厂家开发的什么管理模式下的营业系统，如果想做好，让营业人员愿意用，管理层愿意投入资源用，都应该具备业务模式吻合度高、友好性高、响应速度快、兼容性强的特点，这些特点构成了做好营业系统的关键基础，失败的系统基本也都失败于这几点。
第1节 业务模式吻合度高
首先强调下一个认知的问题，营业系统是一个系统，是一个管理工具，不是管理的手段。营业端的问题可以通过系统去显露出来，但是并不能透过系统去直接管理，工具不能代替管理人员。
既然系统是一个工具，是营业一线人员使用的工具，系统的设计就必须吻合业务模式。业务模式都是几辈营业人员在实际经验中摸爬滚打总结出来的最佳模式，在市场大环境不变的情况下，具有绝对的权威性，是不能因为系统架构或乙方技术实力而随意改变的，工具必须服务于业务模式。
通路常用的拜访步骤中，业务人员拜访门店之前，都要对门店信息进行大致的了解。这个门店的老板姓名、门店的月均销量等基础信息，产品的陈列和竞品趋势等市场信息，上次拜访时间和拜访遗留事项等拜访信息。这些信息都要透过工具准确的展现给业务人员。优秀的业务人员会透过这些信息的展示来推荐老板下单，增加销售业绩。
举个例子，上周业务人员拜访某店，老板反馈部分产品新鲜度较差，请业务人员协助尽快销售以避免过期。业务人员答应下次拜访携带部分促销品进行绑赠促销，但因为过于忙碌，业务人员忘记此事。首先有损失的是店老板，产品过期了，如果不小心卖给顾客麻烦更大，第二损失的是店老板对业务人员的信任，店老板不会再给业务人员第二次失言的机会，这样的合作氛围会影响后续双方的合作。
营业系统作为工具，如何协助业务人员处理这种事呢？如何贴合业务模式呢？
营业系统首先在业务人员拜访的时候，提醒业务人员在拜访离店时填写此次拜访的遗留事项，留下协助业务人员的具体内容。系统其次在业务人员拜访该门店的前一日作为提醒事项告知业务人员次日拜访客户应注意事项，提前做好应对准备。系统最后在业务人员拜访该客户的当天早晨，继续提醒业务人员拜访客户应注意事项，提前做好应对准备。
如何提炼公司内部的业务模式，并通过营业系统给予足够的系统支持以提升业务绩效，是甲方项目经理的重要作用之一。
目前大多数的甲方没有给予甲方项目经理足够的重视。部分公司将此岗位置于营业市场部门，导致此岗位熟悉营业而不动系统，盲目的用业务模式去硬生生的套在IT技术之上，而没有顺应IT技术，扬其长避其短。也有部分公司将此岗位设置于IT部门，导致此岗位熟悉IT技术而不懂营业技巧，产品明显带有办公室逻辑性严谨的风格，而忽略了务实且实用的营业想法。
所以说甲方的项目经理不是一个单纯的营业市场岗位或者IT技术人员，而是一个懂市场知IT的复合型人才，既要了解业务的运作模式、技巧甚至阴暗面，又要懂得IT技术的优势、技术概况、发展方向等信息。只有这样的复合型人才，才能将业务运作模式高度抽象提炼，汇整成营业系统的改进方向，使营业系统既能服务好业务人员日常作业，又能保证系统的最优化运行。
