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