第3章〓项目准备


思维导图


在售前人员完成签单后，实施人员就要着手准备启动项目了。

在项目启动之前，需要从售前工作开始对项目的背景有个全面的了解，了解合同、协议的所有条款，了解售前人员是如何跟甲方沟通的，给甲方作了什么口头承诺，以及可能给当前项目挖的坑。

在启动项目之前还需要做好一些必不可少的准备工作，包括了解客户行业背景，跟这个项目相关的业务知识，熟悉对接人员等。

3.1了解售前工作
3.1.1研读售前文档

在售前工作过程中，甲乙双方会生成大量的文档，如立项报告、产品介绍材料、解决方案、报价单、招标书、投标书、合同、协议、调研报告、服务承诺、各种备忘录等。为了保证项目的大方向不会走偏，在项目启动之前，实施者需要积极地与售前人员做好沟通，尽可能了解售前的工作过程与成果，将售前文档搜集齐全，仔细研读，对这个项目的售前工作有个清晰的理解，从而为实施工作奠定良好的基础。

1. 项目背景

项目背景一般包括： 甲方为什么会发起这个项目，他们遇到了什么问题，想从这个项目中获得什么，等等。甲方在启动项目之前，对未来多少总有些展望，例如，如何建立数字化管理体系，如何解决当前存在的管理问题，考察系统对当前工作的影响，等等。这种展望可能很具体，也可能很模糊，可能跟乙方的展望基本一致，也可能天差地别。通过对项目背景的了解，实施者需要尽可能感受甲方的展望，做到“知己知彼，百战不殆”，如果甲方的展望跟乙方差别很大，就需要提前做好准备，在实施过程中，要么想办法逐渐改变甲方的期望，要么将项目引入一个可以满足甲方期望的方向。

2. 解决思路

条条大路通罗马，解决同一个问题，实现同一个目标，可以采用很多不同的方式和解决思路。售前人员在跟甲方交流时，一定已经给出了某种解决问题的思路，这个思路或具体，或粗略，可能容易实现，也可能困难重重，但不管怎么样，最后成交签约一定是围绕这个思路进行的。不得不说，站在实施的角度，这个思路确实不一定是最优的，有时候甚至会让实施者哭笑不得。然而，不管售前的解决思路如何，实施者一定要知道“先入为主”的力量，售前人员已经让甲方接受这个思路了，在后来的实施工作中，如果解决思路跟售前的思路不同，必然会面临甲方的责难。

因此，在启动项目之前，实施者需要通过研读售前文档，了解售前人员提出的解决思路，不管自己是不是接受这个思路，至少要知道这是一种甲方可以接受的思路，如果违背它你就要做好充分的准备。

3. 核心需求

售前人员在洽谈业务时，免不了要跟甲方谈到一些需求，如功能需求、性能需求、硬件需求等，有些是甲方自己提出来的，有些是售前人员通过引导激发出来的。

实施者通过对售前文档的研读，可以了解甲方大概需要系统提供什么功能，如果售前人员编写了规范的售前调研文档，实施者也许还可以弄清楚这些功能是由哪些部门与人员提出来的，这样可以为接下来的需求调研工作提供有效的工作指导。

要注意的是，售前文档中写下来的需求，只是甲方或者售前人员的认定，他们认为可以通过这些需求实现某种目标，不管是否真能实现，实施者需要自己做出判断。






4. 其他

售前工作非常复杂，留下来的售前文档必定多种多样，实施者可以从中获得非常多的有用信息，远不止上面提到的几种。例如： 

 通过售前人员跟甲方的沟通记录，了解甲方的主要联系人与核心成员，以及每个核心成员的想法与期望。

 通过功能报价单，了解不同功能在甲方或售前人员心目中的权重，以便在设计功能逻辑时对复杂程度有个提前预判。当然，这个预判不一定准确。

 通过会议纪要，了解甲方高层(特别是一把手)对项目的重视程度。如果项目规模庞大、牵涉岗位众多，没有高层重视，项目走向会很危险。

3.1.2理解各种协议条款

在所有售前工作的交付物中，对实施影响最大的自然是各种协议及合同了。原因很简单，其他的材料只是宣传或引导用的，协议才具有法律效力。实施是项目的售中过程，是履行协议的过程，因此，在实施过程中，实施者要非常熟悉这个项目的协议，要深刻理解那些跟实施有关的条款。

一般来说，跟实施密切相关的条款包括： 采购需求、项目交期、价格、支付条件、验收方式、关系方、其他等。

1. 采购需求

对于一个规范的项目，甲乙双方总要在签订的协议中写下甲方的采购需求，也就是甲方对准备采购的产品及服务的具体要求。

由于IT项目服务内容的不确定性，系统最后交付时，不大可能完全符合协议中描述的采购需求。但实施者必须知道，协议中的采购需求是甲方对这个项目的基本要求，如果项目成果跟这个不一致，一定要有充分的理由，并做好应付甲方核查的准备，否则可能会给项目验收带来很大的麻烦，后面讲验收时还会探讨这个问题。

2. 项目交期

实施者作为项目推进人员，关注交期是不言而喻的职业素养，因此在着手启动项目之前，一定要弄清楚甲方对这个项目的交期的具体要求。

大部分项目协议都会有明确的交期要求，不过要注意的是，不同协议对交期的定义可能是不同的： 一是系统上线日期，二是系统验收通过的日期。前者指系统开发完成部署，可以供甲方使用的日期，后者指系统满足了甲方的要求，通过甲方验收的日期。

对于乙方来说，通过验收的难度要远远大于系统上线的难度，上线只是开发、部署、安装完成，通过验收才算是得到了甲方的认可。做项目实施的都知道，这两者之间的差别是巨大的。

3. 价格

IT项目的价格一般包括硬件、软件、服务的价格。本书重点讲述软件实施，所以就不讨论硬件了。

协议中的价格可能包括很多价格元素，如功能、任务、工作量等，如果将项目价格看作一个函数，项目总价是因变量，这些价格元素是自变量。

1) 软件功能

有些费用是根据功能收取的，也就是将软件开发工作拆分成若干功能，然后在协议中写明每个功能多少钱。例如某ERP系统，总共包括采购、销售、库存、计划、生产、质量、财务等多个模块，乙方在销售系统时，让甲方选择使用哪些模块，每个模块都有固定的价格，甲方要买的模块越多，价格就越高。

一般在以定制开发为主的项目中，功能决定价格是很常见的，因为定制开发的成本跟功能的复杂程度息息相关，根据功能来收费显得非常合理。

2) 任务

有些费用是根据完成的任务收取的，例如，实施、数据迁移、上门服务等。

3) 工作量

有些费用是根据乙方投入的工作量收取的。在项目协议中，如果出现跟工作量相关的价格因素，一般会根据“人·月”(或“人·日”)计算，例如，开发需要投入10个人·月，每个人·月单价30 000元，那么根据工作量就需要收取300 000元。





“人·月”或“人·日”是IT行业常用的工作量计量单位，一个“人·月”指一个人工作一个月，一个“人·日”指一个人工作一天。


4) 用户数

有些费用是根据用户数收取的，也就是根据甲方需要使用系统的用户人数确定价格。用户数一般分两种： 一种是总用户数，就是甲方使用系统的总人数； 另一种是并发用户数，就是可以同时使用系统的用户数。

5) 服务时长

有些费用是根据乙方提供服务的时间长度收取的。例如，很多SaaS软件平台，客户可以“租用”软件系统，用一个月就付一个月的钱，用一年就付一年的钱。再比如，大部分软件项目，当乙方需要收取维护费时，都会根据服务时间收取，如“每年收取项目总额的15%作为年维护费”。


例如，某项目合同的价格条款如表31所示。


表31某项目合同中的价格条款



费 用 类 别费项金额/元备注


平台搭建费20 000包括平台搭建，基础功能部署等

功能费
个人办公25 000
内部审批12 000
公文管理38 000
知识管理20 000
办公物品管理15 000
图书管理5 000
档案管理20 000

项目实施费30 000根据实施顾问上门服务天数计算，2 000元/人·日，预计需要15人·日，超过部分由乙方自理
数据迁移费10 000将甲方原来管理系统中的档案记录、公文记录迁移到本系统
用户使用费0允许300个用户使用系统，超过部分，每年收取200元/人的用户使用费
维护费40 000提供三年的系统维护支持。验收后免费维护一年，免费维护期满后每年收取20 000元维护费

合计235 000


实施者在面对项目的价格时，比较容易犯两种常见的错误，在工作过程中要注意避免。

（1) 不关心价格。

实施者不关心价格，觉得自己的任务就是将项目实施完成通过验收。他们通常认为，既然价格多少都不会左右自己为甲方做好服务的心，为什么要去关心价格呢？还有些实施者认为，公司每个月给自己发固定工资，至于项目款金额多少，回款情况如何，跟自己的收入完全无关。

实施者要时刻保持清醒的头脑： 自己辛辛苦苦到甲方做项目，是为了给公司挣钱的，做好项目只是你为公司挣钱的手段。明白了这个道理，自然就知道不关心价格是多么不明智了，你的工作目标就是为了完成销售实现回款，怎么能无视协议中的价格条款呢？很多时候，实施者的工作安排应该紧扣价格条款。例如前面案例中的“根据实施顾问上门服务天数计算，2 000元/（人·日），预计需要15人·日，超过部分由乙方自理”，实施者看到这个条款后，就应该根据它安排自己的行程，如果在甲方那边工作超过15天了，那就尽量远程解决问题，毕竟超过15天后，甲方是不会再追加实施费的，能远程解决的问题就没必要上门服务了，何必将时间浪费在路上。

（2) 过于关心价格。

实施者过于关心价格，干什么都要围绕价格展开，将价格条款作为自己的指路明灯，对价格太过偏执。

其实在很多情况下，售前在进行报价时是有很多策略的，重要的是项目款总金额，至于具体采用哪些价格元素，要根据甲方和项目的具体情况见机行事，关键看甲方能不能接受。报价是个心理战，售前自然希望报价方式符合甲方的期望，这样才更有可能成交，如果报价方式不对，再便宜人家也未必会买。例如，有些甲方只认工作成果，按照工作量报价，人家就不会认可； 有些甲方只关心如何建立一个综合的数字化管理体系，按照功能报价，对方肯定也不能接受。

所以，实施者如果偏执地对待每一项价格元素，而不去关心售前如此报价的真正原因，有可能会弄巧成拙。

项目实施经理赵峰最近有点烦。

他在甲方那里做一个OA项目，其中有个用户权限角色管理的功能。甲方提出要将岗位与角色关联，岗位很多信息的变化，需要同时反映到角色以及跟角色相关联的用户中，这显然会带来很多额外的开发工作量。

赵峰查看了合同，发现售前在报价时，岗位管理功能只报了600元，角色管理功能一分钱都没有报。这让他很恼火，拿着合同跟甲方对接人沟通： “王总，您看看，这两个功能我们一共才收了600块钱，让我们干这么多工作，我们要赔死啊。”

王总： “这我不管，这个项目可不是我跟你们售前人员谈的价钱，我只负责跟你对接公司的OA需求。”

赵峰回来找售前老李。

老李说： “其实吧，在售前的时候我就知道他们需要做这种开发，但我还是决定将这两个功能的价格压得很低。”

赵峰气愤地说： “傻啊，反正不用你开发是吧？”

老李拍拍他的肩膀说： “别急别急，听我跟你说说道理。”

赵峰： “你说！你说！”

老李： “这是个以定制为主的项目，我们的成本主要是开发费用，所以我报价的时候主要根据工作量。”

赵峰： “那你还报个600块钱！你说说600块钱够开发什么？”

老李： “但你要知道，售前人员工作的重点是打动甲方，从各方面打动甲方，报价是其中非常重要的一环。对售前人员来说，某个功能实际值多少钱，其实远远不如甲方觉得它值多少钱来得重要。”

赵峰若有所悟。

老李继续说： “你看这种岗位管理、角色管理、用户管理、系统登录之类的功能，甲方在很多系统都见过，都大同小异。在甲方的心目中，这种功能每个软件公司都应该有现成的代码，根本不需要开发，你要报多了他们绝对无法接受，这生意也谈不成了。为了一点蝇头小利牺牲一个单子，不值得吧？”

赵峰点点头，沉默了一会： “就算这些功能都是我们现成的功能，可以不收钱，但是你收的这600块钱，显然也不够定制开发的啊。”

老李： “这个就牵涉报价心理了。你想想，对于他们的需求，你们一个程序员2天可以干完吧？”

赵峰： “嗯，大概是这个工作量。”

老李： “一个初级程序员，一天工资300块钱够了吧？”

赵峰： “这不对吧？账可不是这么个算法！事情又不是仅靠程序员就能做完的，还有实施、需求、测试、美工、管理人员，等等，还有社保、管理费用，这些不需要钱吗？”

老李： “是的，这些道理我很明白，但甲方看工作量时一般才不会考虑这些，他们只看到程序员的工资。”

赵峰有些困惑。

老李： “这是个非常清楚的需求，大概多少工作量甲乙双方都心中有数。可是还有很多别的不清楚的需求，究竟会产生多少工作量，甲方心中根本没底。如果你来报价，你会如何报？”

赵峰想了一会，恍然大悟道： “好家伙，够贼啊，大家都清楚工作量的需求，就将价格压得低一点，让甲方在心理上觉得我们的价格是非常实在的，然后将牺牲的价格在甲方不清楚工作量的需求上弥补回来。我说呢，怎么一个集成的工作流引擎报得那么贵。唉，我还想通过功能价格来控制需求，看来是有些幼稚了。”

4. 支付条件

支付条件就是当满足什么条件时甲方才会付款。一般项目协议中都有关于支付条件的表述，例如合同签订后支付多少钱，验收后支付多少钱之类。根据支付条件不同，可以将项目款分成几部分： 

1) 预付款

在项目启动之前，甲方需要支付的款项。例如，某项目协议规定： “在协议签订5个工作日内，甲方需要向乙方支付项目总额的30%作为预付款。”

2) 进度款

项目进行过程中，甲方根据项目进度向乙方支付的款项。一般来说，有进度款的项目都是规模较大、持续时间较长的项目，甲方如果不在项目进行的过程中支付进度款，就会给乙方带来较大的风险与资金压力。

3) 结算款

项目完成后，根据项目的实际情况，结合价格条款计算出的甲方应该支付的项目余款。大部分情况下会约定在项目通过验收后支付。

4) 质保款

为了保证乙方可以提供良好的持续服务，可能会留下一小部分款项(一般为5%~10%，延迟1~2年)，等质保期满支付。

某项目协议中的支付条款


本项目总额120万元。

项目合同签订后10个工作日内，甲方支付项目总额的30%作为预付款，即360 000元，大写叁拾陆万元整。(预付款)

乙方完成需求分析、原型设计，得到甲方的书面确认后，甲方需要在5个工作日内支付项目总额的20%，即240 000元，大写贰拾肆万元整。(进度款)

系统上线并验收通过，双方签署项目验收单后，甲方需要在5个工作日内支付项目总额的40%，即480 000元，大写肆拾捌万元整。如果在项目实施过程中，发生需求变更、功能增减等影响项目金额的事项，凭双方签字确认的单据一起结算。(结算款)

系统验收后进入维护期，维护期满一年后，甲方需要在5个工作日内支付项目尾款，即120 000元，大写壹拾贰万元整。(质保款)

5. 验收方法

很多项目会在协议中写明最终如何验收项目，如何组建验收团队，要不要分初验、过程验收、终验等步骤，验收的流程是什么，采用什么标准验收，填写什么验收单据，等等。一般协议中规定验收方法的项目都是比较规范的项目。

对实施者来说，有明确的验收方法，会大大降低项目的实施难度。相信做过项目的读者都清楚，项目验收是一道难关，最麻烦的是不知道应该做成什么样子才能通过验收。如果有明确的验收方法，事情就容易多了，因为有了明确的标杆，项目是不是满足要求，只看是不是符合这个标杆。甲方要是不同意验收，至少要说出乙方做出来的成果跟这个标杆的差别在哪，整改起来就可以有的放矢。

当然，也有很多奇怪的项目，明明协议中规定了验收方法，但真正到验收时，还是甲方相关人员一句话的事情，才不管协议中的什么验收标准、验收流程呢。这种没有契约精神的甲方，会让实施者非常头痛，后文讲验收时还会讲到，这里就不多说了。

6. 关系方

很多项目，签订协议的不止甲方、乙方，还有跟这个项目相关的第三方(一般称为“丙方”)，甚至还有可能存在第四方或第五方。如果第三方跟这个项目只是商务关系，对项目的实施过程没有实质性的影响，那么对实施者的工作影响不大，例如，某运营商与乙方一起，跟甲方签了个三方协议，运营商负责提供网络支持，乙方负责软件开发。在这种情况下，实施者只要关注网络通不通就行了，其他事情基本就不需要考虑第三方的事情。但有的时候，第三方跟项目实施关系密切，需要深度合作才能把项目做好，例如，某物联网项目，乙、丙双方跟甲方签订了一份三方合同，乙方负责软件，丙方负责物联网感应器集成，这种项目就需要双方精诚合作，随时保持沟通才能做好，如果不注意协作，只是闷头干自己的事情，很可能会给项目带来意想不到的风险。

7. 其他

当然，实施者需要关注的协议条款并不仅仅包括上面这些，还有很多其他可能会对实施工作产生影响的条款。例如，是不是有关于现场服务的强制要求，差旅费由谁承担，是不是对数据保密有特殊要求，是不是需要甲方提供办公场所，是不是需要什么特殊的设备，是不是需要提供特殊的交付物，等等。

3.1.3了解售前可能挖下的坑

售前不是搞实施的，对项目实施的理解未必跟实施者一样，他们在跟甲方进行沟通的过程中，难免会犯一些错误，说错一些话，提供一些错误的建议等。有些错误很小，只要跟甲方稍加沟通，一笑置之就算了； 而有些错误可能会对项目实施产生重大影响，可能会让实施者头痛不已。另外，售前人员为了签下订单完成业绩，有时候不得不说些大话，承诺一些很难实现的功能，这些都有可能给项目实施带来风险。

实施者在项目启动前应该跟售前人员做深入沟通，尽可能了解售前人员给项目实施造成的潜在隐患，提前做好准备，有目的地采取一些措施，不至于让甲方产生强烈的失望情绪，最终导致项目失败。下面列举了一些常见的售前陷阱，都是笔者在工作过程中遇到过的，希望能对实施者有一定的警醒作用。

1. 让甲方怀着不切实际的幻想

售前人员在工作过程中，一般都需要跟甲方描绘使用系统后的美妙场景： 能给甲方带来什么收益，可以解决什么问题，可以打造什么核心竞争力，等等。为了吸引甲方，为了强调自己优于其他竞争对手，售前人员往往会夸大其词，采用一些充满诱惑力的语句。清醒的甲方自然也知道，售前只是宣传而已，宣传跟真正实现之间是有差距的，不能太较真。但有的时候，某些售前人员确实太过分，信口开河，吹牛吹过了头。

大部分甲方并没有雇佣很厉害的IT专业人士，所以对IT系统的理解并不深刻，很难搞清楚售前人员的描述中哪些是可以真正实现的，哪些是不可能实现的。越是不懂行的甲方，越容易被那些梦幻般的言辞所吸引，最终签单的乙方很可能是最会吹牛的供应商。

在这种情况下去实施项目，无论乙方怎么努力，甲方都不会开心，因为梦幻总是非常容易被现实击碎。如果实施者发现甲方对项目的认知确实存在某种不切实际的幻想，就需要提前做好准备，在工作中一有机会就要不遗余力地给甲方灌输正确的理念，让甲方逐步接受现实，放弃幻想。

2. 提供错误的解决思路

售前工作总要阐述如何帮甲方解决问题，提供解决各种问题的思路。当然，售前工作的重点是说服甲方相信乙方可以帮他们解决问题，因此，这些思路是不是正确，对于售前来说并不重要，重要的是能不能打动甲方，能不能赢得甲方的信任。

有经验的售前人员心中都非常清楚： 我只是想增强甲方的信任感，而不是让团队真去这样解决问题。因此，售前高手在谈到如何解决问题时，在某些不能肯定的关键点，一般会使用一些含糊的措辞，给实施留下足够的发挥空间。如果售前人员不明白这个道理，随便提供一些错误的思路，就会给项目实施带来麻烦。甲方有时并不计较，只要能解决问题就行，怎么干不重要，但有时甲方就会较真，甚至甲方被售前的错误思路所误导，提前布局，弄得实施人员没法收场。

项目实施经理赵峰在某工厂实施一款生产管理系统。他研究了车间的工作方式后，决定根据操作台的位置设置多个数据采集点，这样操作人员可以就近使用系统，录入数据也会更及时。

但没想到，甲方项目经理说道： “你们的售前人员小张让我们在车间专门开辟一个玻璃隔间做数据统计室，我们都装修完了，工位都排好了，你现在又让我们这么搞，什么意思啊？这说不过去吧？”

赵峰的内心是崩溃的： 是有些说不过去，容我回去把小张撕碎了再来谈这个事情。

3. 引向团队不希望的方向

有些售前人员对本公司的技术、团队、优劣势等没有清楚的认知，跟甲方沟通时只会根据自己有限的经验随意发挥，给甲方留下错误的认知，给自己团队制造障碍。例如，团队研发是用.NET开发的，却告诉甲方可以支持Java； 数据库只支持SQL Server，却告诉甲方可以支持MySQL； 团队研发人员根本抽不开身，却告诉甲方可以驻场开发，等等。

售前人员小张刚入职不久，公司最近售前太忙抽不出人手来，有个重要的项目需要售前人员支持，就派小张去了。

交流的时候，甲方某个技术人员问乙方的服务端程序是用什么开发的，小张随口说Python，一来觉得这门语言现在很热门，说出来很有些面子，二来觉得这事情不重要，到时候反正给你上软件，你管我是用什么语言写的呢，所以也没有跟研发团队确认。

项目实施经理赵峰并不知道售前人员跟对方说过这个(说实话，简直做梦都想不到售前人员会这么跟人家胡说，因为自家公司可从来没有用过Python做开发)，自然不会提前做这方面的应对工作。直到系统上线验收的时候，甲方却拒绝验收，因为乙方提交的软件代码是用Java写的。甲方说，当初你们说用Python开发，我们为了这个系统，特意让我们的程序员学了好几个月的Python，现在你们给我们用Java写的程序，实在不能接受。

4. 签下无法做到的条款

售前为了能打动甲方，往往会夸大系统带来的效果，例如，能够带来多少销售收入，能够将成本降低多少，能够减少多少积压资金，能够提高多少工作效率，能够节省多少资源，等等。类似的描述几乎每个供应商都会说几句的。没办法，你不说你就第一个被淘汰。一般来说甲方也不会太当真，大家都心知肚明，所谓系统带来的效果，只能说是系统对目标实现有一定的帮助，究竟能不能实现，涉及的因素太多，远远不是乙方能够完全左右的。

售前人员也许会在口头上大胆许诺，答应甲方一些不切实际的要求，但一般不会将这种许诺写在协议里。因为只要出现在协议条款中，就意味着乙方需要对其负全部责任。如果最终不能实现，甲方就有充分的理由不验收、不付款。不过售前人员有时也会犯错误，签下一些乙方无法履行的条款。

对实施者来说，在项目启动前就应该认真研读协议中的每项条款。对于那些可能不受乙方控制的条款，要及时甄别，提前做好预案。甚至有些条款是注定不可能实现的，对此实施者要尽力做通甲方工作，让甲方接受现实。

在某个项目中，售前人员李明是个人才。在跟甲方沟通的过程中，他凭着自己流利的口才、快速的反应能力、出色的解决问题的能力赢得了甲方的尊重，深得甲方老板赏识。

到了商务谈判阶段，甲方老板要求李明自己来实施项目。李明知道自己的强项在于搞售前工作，实施并非所长，而且公司现在正缺人手做售前呢，只好婉拒甲方。但甲方老板非常坚持，说跟李明有眼缘，除非他自己来实施，否则项目免谈，宁愿跟他们的竞争对手C公司签约。

李明跟公司领导请示，领导明知这样不妥，但为了能拿下单子，就同意了，计划到时候派其他实施经理跟李明一起去启动项目，在甲方那边作为李明名义上的助手，一旦项目启动后，就把李明撤回来做售前，工作还是由实施经理负责，李明只做个挂名项目经理。

签合同时，甲方老板坚持要把“由李明来实施项目”的要求写到合同中去。李明想反正自己是真打算来的，无所谓，写就写吧。

然而，签完合同不久，李明跟公司领导不知道什么原因闹崩了，愤然辞职，跑到竞争对手C公司去了。

公司只好派赵峰去实施项目，当他看到合同中有“本项目需要由李明担任项目经理”这个条款时，知道麻烦来了。

5. 随意做出口头承诺

售前随便许诺，哪怕没有写到协议条款中，也可能会给项目实施带来麻烦，因为当甲方最终发现项目的实际效果跟售前人员的描述天差地别时，会产生强烈的失望情绪，这种情绪会让项目验收极其困难。

因此，实施者在项目启动前，应该跟售前人员沟通交流，尽量了解售前跟甲方是如何沟通的，有没有做出过什么不切实际的口头承诺，提前做好应对准备。当然，售前人员很可能会因为担心被领导批评，被同事指责，未必会好好配合。

6. 过度迷恋商务关系

有些售前人员跟甲方建立了一种密切的商务关系，甚至可能跟相关决策者有利益往来，所以在跟甲方沟通的过程中并不真正关心项目要实现什么，也不认真商谈、推敲合同、协议条款，总觉得反正跟甲方关系好，到时候凭私人感情就能把验收的事情搞定。

说实话，对实施者来说，实施这种项目相对要容易一些，毕竟验收的时候甲方不会要求太严，只要大概过得去，不给相关领导丢人就行。然而，这种项目却有一个巨大的风险，就是乙方搞关系的售前人员可能会离职，或者被乙方搞定的某个甲方人员会离职(也可能因为工作调动的原因不负责这件事了)。这样就非常麻烦了，由于当初在售前的时候，双方并没有好好做方案，并没有认真在合同中界定工作内容、付款方式等，一旦没有了商务关系支持，实施工作自然就会非常被动了。

7. 不讲职业道德

有些售前人员，可以为了一己私利，签一些几乎不可能成功实施的项目合同，缺少基本的职业道德。例如，年底为了完成业绩指标，在某个关系好的甲方人员配合下，签一个不是为了做项目而只是为了凑数字的合同； 明知是自己公司不接的项目，还是坚持跟甲方签合同； 明知这个项目是团队做不了的，只想骗点预付款回来，等等。

3.2了解甲乙双方

实施者在启动项目之前，需要尽可能了解甲乙双方跟本项目相关的信息，例如，甲方相关领域的业务知识、甲方相关领域进行数字化管理的特点、甲方的管理特点、乙方做项目是不是还有赚钱之外的目标等。

3.2.1了解甲方

实施者在准备启动项目之前，需要尽自己所能充分了解甲方的相关信息，如组织规模、业界地位、行业业务知识、经营管理特点等。对甲方了解得越多，沟通起来就越容易。这样做有几个好处： 首先，不会被甲方的各种术语弄糊涂； 其次，可以更容易理解甲方的想法； 最后，树立自己“懂行”的良好形象，可以提升自己的威望。如果实施者对甲方一无所知，业务不熟悉，术语听不懂，管理不清楚，人员不认识，就贸然跑过去启动项目，风险是很大的。更为重要的是，会让甲方失去对实施者的尊重。原因很简单，换位思考下，如果你是甲方人员，看到来了个小白，什么都要问，什么都不懂，一问三不知，你还会尊重他吗？作为实施者，建立自己在甲方心目中的威望是非常重要的(后文会详细讨论这个问题)，如果给甲方留下糟糕的第一印象，后面想翻身的难度就大了。

1. 了解甲方的行业特点

了解甲方，先从了解甲方所处的行业开始。要到某工厂实施MES项目，如果对相关领域的加工制造流程不了解，简直寸步难行； 到政府部门实施电子政务系统，如果对政府机构的工作流程和工作习惯一无所知，就会步步荆棘； 到医院实施HIS系统，如果对医院的业务知识知之甚少，甚至从来没有到医院正经地看过病，恐怕很难实施成功……因此，无论实施什么项目，了解跟项目相关的业务知识都是非常重要的。

所谓业务知识，就是甲方相关领域的各种专业知识。甲方人员在从事生产、经营、管理、贸易等工作的过程中，每天都在使用行业相关的各种知识，如果没有这些知识，所有的业务都不可能开展下去。实施者在甲方实施项目的过程中，需要跟甲方相关岗位的工作人员沟通交流，围绕他们的工作展开。如果对这个行业不了解，可想而知，这个沟通过程会多么痛苦。你痛苦，因为听不懂，对方痛苦，因为觉得在对牛弹琴。

作为实施者，到甲方来的主要价值就是借助IT技术改善甲方相关领域的管理工作，遇到那种复杂的领域，如果不懂业务，想弄明白人家是如何工作的已经非常艰难了，还怎么帮助别人改善管理呢？

实施者在启动项目之前，如果对甲方的行业不熟悉，对甲方的业务不了解，就需要先做好功课，从各方面搜集资料，向高人咨询请教，不断充实自己，至少做到能够跟甲方人员针对他们的管理工作进行无碍交流，不要让别人觉得你就是个实习生，啥也不懂，跑到这里来不是来帮助我们的，是来偷学的。要注意的是，这里所说的行业、业务，并不一定就是甲方的主营业务，而是跟这个项目相关的领域，例如，到某工厂去实施OA系统，就不需要去了解他们车间的生产知识，到某医院实施人力资源管理系统，就不需要了解太多的医院运作流程。


一般实施者会实施各种不同的项目，会接触各行各业，不可能对每个行业都熟悉，因此需要锻炼出快速学习与理解业务的能力，能够在短时期内了解甲方业务，这样才能适应不同项目的挑战。

随着时间的推移，实施的项目越来越多，实施者所拥有的不同行业的业务知识也会越来越多，这种经验积累，会让自己在相关领域的实施能力得到极大的发展。有些实施者专攻某特定行业的数字化管理，例如，有人专做服装行业，有人专做医疗行业，有人专做汽车行业，等等。对于这类实施者来说，由于长期浸淫在这个行业，经过多年的积累，对于这个行业的了解已经相当深入，实施项目时就会有很大的优势，这也算是这部分实施者的职场核心竞争力。对于有些业务复杂的行业，如果没有长期的经验积累，几乎不能成功实施。


2. 了解甲方行业数字化管理的特点

实施者在了解完甲方相关领域的行业特点后，还要了解在这个行业中进行数字化管理的具体特点，例如，一般会产生哪些业务数据，如何在信息系统中表达业务，有什么难点和风险等。这些知识可以为项目实施提供帮助，少走弯路，少犯错误，增加成功率。当然，这种知识不像业务知识那么容易找到，毕竟这方面的从业人数可能非常有限。实施者需要知道，不管准备实施的项目属于哪个行业，都可以找到很多耕植该领域的前辈，愿意总结经验的大有人在，只要肯检索，肯向前辈请教，总能获得一些有用的信息。

某位长期从事纺织企业信息化管理工作的实施者，对纺织企业库存信息的特点总结如下：

一般对库存信息的管理可以分物料、批次、元件三个层次，仅仅针对物料层次的库存信息管理是远远不能满足纺织企业要求的，一般要管理到批次层次，甚至要管理到元件层次。


物料层次是指对库存物料的信息管理，只要管理到物料品种，而不需要管理入库批次信息。比如对机器零件的管理，针对某一种零件，只要管理到这种零件的仓库库存数量即可，不需要管理到入库批次，因为在工作过程中认为这种零件的每一个体都具有相同的属性(不管是哪一批进货的)，完全可以在机器维修的时候通用。

批次层次是指对库存物料的信息管理，需要管理到物料的不同批次。只有属性完全相同，在生产过程中可以通用的物料才可以算作同一个批次。注意，这里的批次与财务会计中需要采用某种计价方法(如先进先出)而按时间顺序进行的批次管理是有本质区别的。


以纱的管理为例。对纱的库存管理很少仅仅满足于管理到物料品种，即仅仅管理每个纱种的库存情况(例如，可以提供信息“全棉40支单股纱库存量30吨”)，而是至少需要管理到纱的批次，技术人员认为相同批次的纱才可以通用。虽然是相同品种的纱(如全棉40支单股纱)，但不同批次之间可能质量、技术指标差别很大(如强力、条干、实际粗细等)，如果不在IT系统中区分开来，这样的库存数据对生产、计划管理来说作用极其有限。

元件层次是指对库存物料的信息管理，需要精确到每一个体，如一个筒子、一根轴、一匹布卷等，管理中认为这种物料的每一个体都是特别的，有着不同的属性。

3. 了解甲方的管理特点

在项目启动之前，实施者应该通过各种渠道(如翻阅售前文档、查看甲方官网、咨询熟悉的人员等)了解甲方的管理特点，例如，甲方的组织结构，项目相关的岗位及管理要求，各自的工作职责，等等。当然，在正式进入甲方现场启动项目之前，要获得这类信息是有些难度的，因为项目还没有启动，不大容易找到真正熟悉情况的人跟你讲解。为了尽早了解甲方的管理特点，在项目启动前，可以考虑先做一个调查问卷，让甲方对接人安排相关人员回答。


项目实施经理赵峰准备到甲方实施人力资源管理系统，项目还没有启动，为了提前了解甲方人力资源管理的相关工作，他做了一份调查问卷给甲方的人力资源部经理：

(1) 贵司包括哪些部门？请画出贵司的组织架构图，写明每个部门的主管。

(2) 人力资源部的主要工作内容包括哪些？

(3) 贵司有哪些岗位？每个岗位的职责是什么？

(4) 每个岗位的人数有多少？构成情况如何，比如学历、性别等？

(5) 每个岗位的工作需要什么信息？输出了什么信息？

(6) 每个岗位的工作任务从哪里来？发布任务者通过什么方式发布任务？

(7) 每个岗位完成工作任务时，会有明确的技术要求吗？如果有，这些技术要求是谁给的？怎么给的？

(8) 每个岗位需要对自己的工作完成情况进行汇报吗？如果需要，怎么汇报？什么时候汇报？向谁汇报？

(9) 人力资源部会产生哪些单据？简述这些单据的流动路径。

(10) 简述员工的入职流程，每个节点需要做哪些工作？

(11) 除了基本工资外，员工会有额外的薪酬(如计件工资、绩效工资、奖金、津贴等)吗？这些薪酬发放的根据是什么？如果有计算公式，请列出详细的计算公式。

(12) 贵司有员工考评机制吗？如果有，是怎么处理的？如果有计算公式，请列出详细的计算公式。

(13) 针对员工的奖励机制有哪些？

(14) 针对员工的惩罚机制有哪些？

4. 其他

其实，除了上面说的几点，还有很多跟甲方相关的各种事情需要提前了解。你了解的信息越多，对甲方越熟悉，去启动项目就会越自信，事情就会办得越顺利，例如： 

(1) 甲方规模如何？年营业额大概多少？

(2) 甲方有多少员工？年龄、学历构成如何？

(3) 甲方在本行业中地位如何？市场占有率大概有多少？

(4) 甲方有没有做过类似的项目？

(5) 甲方的信息化程度如何？有哪些在用的IT系统？

(6) 这个系统甲方是第一次做，还是要升级原来的系统？或是要推翻旧系统？

(7) 自己公司是第一次跟甲方做生意，还是有其他项目？如果有，那么其他项目的责任人对甲方有何评价？

(8) 这个项目有没有第三方，第三方跟甲方是什么关系？

(9) 甲方的对接人是谁？具体联系方式和主要负责的工作内容。

(10) 甲方是不是最终客户？也就是说本项目是自己公司直接跟客户签的，还是被自己的甲方转包过来的？

(11) 如果本项目是转包的，发包方跟客户关系如何？对验收有什么影响力？

3.2.2了解乙方

了解乙方，这一点看上去有些奇怪，毕竟实施者是乙方的员工，有可能已经在这个公司待了好多年，还有什么不了解的呢？其实这里想说的是，在实施项目之前要了解乙方领导对这个项目的真实想法，签这个项目的目的是什么，要实现什么目标。

在很多时候，乙方跟甲方签个项目合同，并不仅仅是干活儿挣钱那么简单，有可能有其他更长远的目标，实施者在工作过程中自然不能忽视乙方的长远目标。下面这些情况都是作者在工作中遇到过的，写下来供读者参考： 

(1) 乙方并不想通过这个项目挣钱，只是想通过这个项目打造一款软件产品以占领市场。乙方自己没有这方面的业务专家，借这个项目可以获得用户的真实需求，这种来自一线的需求是一款管理软件产品最核心的生命力。

(2) 甲方在所处的行业(或地域)有不俗的影响力，乙方希望通过这个项目打造典型案例，起到以点带面的作用，从而提高市场占有率。

(3) 甲方是个规模巨大的集团公司，每年有大量的IT项目，乙方希望可以通过这个项目进入甲方的IT供应商行列，建立长久的合作关系，为源源不断的后续订单打下基础。

(4) 乙方跟甲方属于合作关系，双方准备共同打造一款管理软件产品，面向的是最终用户，最终的收益来自这款产品的利润分成。在当前这个合同中，甲方只承担少部分开发成本。

(5) 乙方老板欠着甲方老板的人情，做这个项目只是为了还人情，甚至连个马马虎虎的合同都没有。

(6) 这个项目在某个领域内有很强的代表性，复制性很强，做完后很有推广价值。乙方不看重项目利润，看重的是可以复制推广。

(7) 这个项目完全不在乙方的目标领域中，只是为了带来现金流才签的合同。乙方的目标很明确，希望做一锤子买卖，要想方设法保证这个项目利润的最大化。