亲身经历谈流程管理

第一篇，什么是流程？

但是也存在很多为流程叫好的案例，广为人知的就是华为引入IBM的做法，引入IPD（产品集成开发Integrated Product Development）、LTC（线索到现金Leads To Cash）、ITR（问题到解决issue to resolution）三大流程。

这三大流程拉通产品、销售、售后三个领域，实现产品从无到有，从有到售，从售到优的演进，为华为铸就今日的辉煌成绩提供了稳固的基石。

那么，为什么会有这种差别呢？为什么有人感觉极度不适应不喜欢流程，有些企业确要致力于打造流程化组织并从中获利？流程的本质是什么？
我认为，流程是企业优秀作业实践的总结和沉淀，通过固化流程实现成功的可复制性。因此，流程的出发点是好的，目的是为了使不同的人员在做同一件事情时，能够少走弯路，直接利用成功经验。

虽然流程的出发点是好的，但不意味着流程一定是好的。什么样的流程是好的呢？越符合业务的流程越好！
业务是利润中心，是企业赖以活下去的粮食，业务的实现关键依赖于两点，一个是组织能力，一个是业务流程。组织能力包括人员能力和产品能力，这自不用说其对业务的重要性。

而流程决定了这些有能力的人和良好的产品将如何组合、协作，如何发挥其最大的作用，实现业务成功。
好的流程随业务流而建立、而改进，既不缺失关键的节点，也不设置冗余审批人员，可控性和自由度把握得刚刚好；

不好的流程要么是走向形式主义，层层审批，实际无用，要么是漏洞太多，关键环节设置缺失，正是关键人没有发言权，无关的人定下生死，真正问题来了的时候，没一个能打的。

俗话说的好，免费没有好东西。既然好的流程对公司如此重要，那肯定不是说建就能建好，一日就能建成华为流程体系。几乎所有的公司在构建流程体系时，都会经历新建、拆解、优化、打破、重建的过程。

而好的流程推动企业更进一步的发展，坏的流程把企业拖到臭水沟，到了最后，成王败寇，盈利能力强的企业冲进世界五百强，大家都知道了企业的名字，流程是不会有姓名的。

第二篇，如何制定好流程？

在讨论如何建立好流程之前，我们需要先给好流程画个像，否则就会陷入没有目标、为了建流程而建流程的无用工作之中。

首先，流程的核心是反映业务本质。因此，符合业务流是对流程的最基础要求。然而这个基础要求的实现并不那么容易，

因为非成熟企业的业务尚处于摸索中，当业务成熟，又需要跟随市场、科技、社会环境的变化持续改进、甚至变革。要建好流程就要找到真实的业务流、并随业务流变化而动态更新。

其次，好流程是集成的、连贯的，这一点非常重要。假如把流程比作河道，上游河道和下游河道各自建设，互不关注，那么就会在河道交界口出现问题。

上道流程和下道流程各自为政，互不关注，就会在流程交界口出现断层，流程断层了，数据也就断层了。

最后，好流程是客户化的。流程的客户是使用者，建设流程需要考虑使用者的感受，精简易用、无重复节点是大部分客户的诉求。

理清楚了好流程的特点，下面我们一一对标，如何建立好流程。

1.找到真实的业务流
流程的核心是反映业务本质，那么我们就要找到真实的业务流，然后围绕业务客观地建设流程。业务是利润中心，业务流就是企业如何实现价值创造的过程。

从获取客户需求为开始，到获取客户订单，再到向客户交付产品及服务、获取客户满意，以及在这个过程中实现企业自身价值，这就是业务流。

大部分企业的业务流框架类似，但又因业务的不同千差万别，即使业务相同，又因企业战略和愿景不同而使企业和企业之间的流程千差万别。

谁来识别真实业务流？业务owner。

很多企业设立了流程部门，这个部门专门负责流程建设，但由于这个部门并不是最贴近业务的，所设的流程必然与真实业务流之间存在缝隙，就导致流程设定以后，使用者这个说流程不适用，那个说太复杂，耽误效率，这个流程建的就很心累、不讨好。

因此，最懂业务的人——业务owner必须参与到流程的建设中，并且成为流程的负责人，流程owner将既是建设者，又是使用者，他可以从建设者和使用者两个角度来考虑流程，识别业务中关键节点是什么，关键决策人有谁，哪些节点是虚设、可去掉。

流程建设不再只是流程部门的事情，而是业务owner和流程部门共同的事情，甚至业务owner更重要些，配合流程部门担负起流程建设的职责。

当业务发生变化时，业务owner及时识别流程与业务不适应的地方，并予以调整，确保流程紧跟业务流。

只有跟紧了真实业务流，流程的大方向才不会出错。

2.组织重视流程

当企业发展到一定规模时，需要构建流程化的组织。华为在发展过程中就提出“企业发展的最高目标是建设流程化组织”，以流程确定角色，组织承载角色，流程与组织匹配。

但是建设流程过程中，很多人会习惯性地认为，控制点加上去、管理加上去，是为了防止风险，效率就一定会下降，不利于市场拓展、公司效率。

但实际上，如果流程真实反映了业务流，并动态维护流程与业务流的一致性，这个时候，流程是一点都不会拖累业务的，反倒会成为业务的强大支撑。

流程建设需要取得组织的重视和共识，才能让大家心往一处想，劲往一处使。

通常，企业会设立一个专职或兼职流程管理的部门，比如流程与IT部专职，或PMO兼职。流程管理部门由于不能贴近所有业务流，所以设置的流程与真实业务流不一定贴合。

在第一点中，我们强调必须让业务owner参与进来，并成为主要责任人，这样就能够实现好流程的第一个特点——“反映业务本质”。

但这时候会出现第二个问题：每段业务流对应的流程都是合理的，每个业务owner都建好了自己的流程，但到了端到端交界的地方，发现口子对不上。

你需要的我没有，我关注的你无法提供。这是因为每个人都只身处在一段业务中，没有办法也没有精力窥得业务流全貌，因此业务全流程被认为割裂成好几段，各自为战，各显神通。流程不集成，不连贯，你用你的，我用我的。

要解决这个问题，需要组织从顶层系统去架构流程建设，要系统完整地反应业务本质，这是一个体系，是集成的，连贯的，不重不漏的。是端到端的，不是段到段的。

这个架构性的事情，只有领导可以做，也只有领导可以推动，因为类似于企业制宪，非常重要，并且涉及跨部门。小兵小将，一来视角不够，二来推动太难。

流程与效率的关系，就好比好比质量和成本的关系，有人觉得搞了质量，成本就高了，但其实把质量管理好了，找到失误的原因，在流程上把会导致不良产品的源头干掉，不返工，不窝工，成本是最低的，效率也是最高的。

企业必须重视流程建设，使流程反应业务，组织与流程匹配，三者互促，推动企业快速向前发展。

3.动态刷新，持续改进
罗马非一日建成，流程非一蹴而就。流程一来要随业务流的变化动态刷新，二来要在企业实践过程中进行优化和改进。

通常的优化点概括起来就是——“精简”。

用任正非的话说就是“不产粮食的流程是多余流程”，所有重复的、开发出来使用率不高的、多余的流程都会增加复杂性、造成人力浪费、增加成本，这些流程都应逐步被简化。

在改进的过程中，需要注意两点：a.改进的持续性，b.不能忽视小改进。

a.改进的持续性
流程在设置好以后，并不是一劳永逸。随着企业发展阶段的不同，流程应跟随改进。在企业较小、人员不多的时候，流程少一些、人为控制多一些还可行。

随着企业规模变大，部门越来越多，人为控制存在太多的不确定性，必须要以流程消除人为的不确定性，以规则的确定性应对结果的不确定性。

同时，在企业规模不大的时候，大部分事情都由领导审批也还可行，但当企业规模上去，领导应该腾出精力做更重要的事情，这个时候就需要授权，同时要在流程增加控制点以确保可控。

b.不能忽视小改进
华为有这样一个故事，一个新员工，刚到华为时，就公司的经营战略问题，写了一封“万言书”给任正非，任正非批复：“此人如果有精神病，建议送医院治疗；如果没病，建议辞退。”注解：“小改进，大奖励；大建议，只鼓励”。

任正非之所以如此回复是因为小改进体现的是踏踏实实的作风，是能落地的，而宏伟蓝图则不是一下子能被验证并实践的，常常为空。看起来无关轻重的小改进，非常影响流程上的客户体验，非常重要，不能忽视。

下面我想给大家分享一个亲身经历的案例。

我们公司有一段技术评审的流程，需要由售前经理提交技术协议；然后由项目经理评审技术协议，并返回意见给售前经理；售前经理根据项目经理意见进行修改，二次提交修改后的版本；项目经理确认后定稿交给业务员，一共4个节点。

看起来很合理，但随着售前经理和项目经理的配合度提高，很多情况下，项目经理对售前经理提交的技术协议无意见，这个时候，仍然需要售前提交修改后的版本，项目经理二次确认。这就是重复，就是多余流程。

在收到一线人员关于重复操作的意见后，经过沟通，我们做出了如下改进：在售前首次提交技术协议后，给项目经理增加一个判断条件，如果无修改意见，则直接作为定稿交给业务员，否则流程同原来流程。

这样一来，通常情况下的技术评审环节就由原来4个节点，减少到2个节点，效率必然提高，获得一线人员好评。

流程需要不断优化，企业才能走向未来。

好流程就要：不多不少，够用就行。

4.工具化：IT支撑

IT给世界带来的变化自不必说，IT技术将人从重复劳动中解放，去从事能创造更多价值的工作。在建设了能反应业务流的流程后，必须以技术手段将流程固化下来，以IT来承载流程，实际上就是以IT来承载业务流。

如果说流程是企业优秀实践的总结，以规则的确定性来实现成功的可复制性，那么IT就是在此基础上对可复制性的进一步加固，以技术手段消除人为的不确定性，即使是一个新手站在这个流程之上，只需要经过少量培训，就能知道做什么可以确保业务成功。

IT化的另一个作用是承载数据。企业用数据说话，群众看数据投票。一个企业的数据来源于业务，收入、成本、预算、核算，如果没有IT，这将是庞大的工作量，并且要实现准确计算很难。

只有流程IT化，才能把这些业务数据实时收集起来，真实反应业务开展情况。数据还有一个隐藏的作用是会反向驱动流程建设的完整性。

因为如果一个作业活动没有输出下游所需要的数据，那么这个活动就相当于白做了，因为它没有达到要求。下游为了补救它，需要花费更大的代价。

流程描述业务流，IT承载流程，也就是承载业务流，业务流的信息反应在IT系统，这样就实现了业务流的闭环。流程IT化建设应成为所有企业的共识，也是流程化组织建设的一个关键建设点。

总结来说，好流程具有能反映真实业务流、集成性、客户特点，要建成这样的好流程，需要由业务owner识别真实业务流，并作为流程负责人建设流程。

而每段流程都建设好还远远不够，企业需要重视流程建设重要性，系统架构，建设流程体系。建成后的流程需要跟随业务流的变化动态刷新以及持续改进，并通过流程IT化消除不确定性、承载业务流信息。

流程需要共建，流程要做到每个人用起来很爽是不可能的，只有当大家主动建设流程，优化和推行，才能不断逼近更优解。

这个时候，企业是流程的主人，而不是流程的奴隶。

第三篇，用好流程，有哪些好处？

用好流程，我认为说的是流程能带来的增值部分，也就是流程除了把业务流走通了，还能发挥什么作用？

这部分内容本来准备放到最后，在我们了解了好流程长啥样、通用的IPD、LTC、ITR是什么，建好了适用于公司的流程之后，再来讲这部分。

但我转念一想，如果能提前把这些增值点嵌入流程，一来能让使用者尽快get到流程的价值，二来减少事后补建流程的成本。

不知诸位是否还记得前文中的一个比喻：我们把流程比作河道，流程的端到端交接就类似河道交界。

而能否成功交接的关键在于，我需要的你刚好有，你给我的刚好是我所需，什么能验证交接成功呢——数据和控制点，数据正是河道中流动的信息，控制点正是河道监测点。

用好流程带来真实数据，数据驱动运营决策

数据分析驱动运营决策，而数据来源于流程。这些过程数据包括经营数据、技术数据、质量数据等，财经数据比如市场前期投入成本、合同收入、研发成本、合同执行成本等等。

质量数据比如缺陷率，有效性，需求完成率，返修率等等，技术数据就不说了。有数据就有价值，有了数据，我们就可以进行利润分析、质量分析，驱动经营决策。

如果这些数据不从流程中来，那么企业就需要进行大量的数据收集工作以进行数据分析，并且数据还不准确。

所以说流程的增值部分是数据，他能实时、快速、准确地为企业数据分析提供数据来源。

用好流程凸显控制点，实现业务受控

那么，控制点是什么呢？控制意味着有要求、要达标，控制一般是授权控制和质量控制。

授权分为两个维度，一个是给予经营组织的划分进行业务流的授权，另一个是给予专业领域的划分，对各职能组织的授权。

授权到哪个人，哪个组织，哪一层级，授权者就是这件事情的主要负责人。

质量控制是企业标准的具象，不管是产品质量还是管理质量。

把控制点构筑于流程中，是将企业标准和制度融于流程，使制度规则可执行，就像是交叉路口设置了交通指示灯和道路上安装了摄像头，这些控制点对车辆遵守道路交通规则有导向和监控作用。

总的来说，数据是精益管理的基础，数据收集的颗粒度和应与管理颗粒度相匹配。管理颗粒度越细，一般来讲管理成本更高，但是如果颗粒度太粗，又会导致漏洞太多，成本也高。

还是那句话，不多不少，够用就好。关键数据必须有，非关键数据可以不设。

但是从长远来看，如果某些数据是以后管理需要的，就可以利用IT系统先把数据收集起来，供后续分析使用，这些数据将会发挥巨大价值。

把控制点设置于流程中，可以让流程上的每一个人非常快速地知道什么是合规的，什么是合格的，并按要求去做，就可以实现成功的复制。

同时，在内置控制点到流程中的过程中，端到端其实会发生很多交流和冲突，这个过程是一个对齐目标的过程，推动跨职能跨专业达成共识，成为利益一致的共同体。

当我们把质量、运营、授权、财经等要素嵌入流程，流程就不单单是一个流程，而成了一个体系，成了公司的运营系统，企业向流程化组织的方向又往前迈了一大步！

第四篇，神奇的IPD、LTC、ITR流程究竟是什么？

大部分人最初认识IPD、LTC、ITR三大流程可能是从华为知道的，华为认为，从公司层面看，IPD、LTC、ITR是为客户创造价值的主业务流。这三大流程贯穿了从客户需求到产品研发、从市场线索到回款、从客户问题到问题解决，正是从客户需求出发，到达客户满意终点，实现企业价值。

经过华为和其他很多公司的管理验证，大部分企业都可以参照这三大业务流，并按照第二篇（插入第二篇链接）如何建立好流程的方法，梳理出适合于自己公司的流程。在此基础上，把质量、财经、内控控制点内嵌于流程，组织适配流程，利用IT方式固化流程，这就是流程化组织的建设和运行！

那么，传说中的IPD、LTC、ITR流程究竟是什么呢？其实并没有那么难理解，今天我们一起来简单交流下。

IPD流程

IPD，integrated product development， 中文叫集成产品开发，讲的是把产品开发出来的全流程，是产品开发的模式、理念和方案，适用于企业的研发管理体系。

IPD为什么能获得如此好评？它与传统开发流程的区别是什么呢？

——IPD是以市场需求为出发点，把产品开发当做是一项投资去做。那么，既然是投资就要求有效益，这些效益就体现在IPD帮助企业对准市场、提高效率、降低成本，也就是所谓的准、快、低。准，指的是开发满足细分市场客户需求的产品；快：指的是向市场快速提供成功的产品；低：指的是实现低成本的产品开发及低成本的产品设计。

相应的企业要做什么呢？

准，要求进行需求管理，跨部门协同，需求不断对齐；
快：要求结构化开发流程，跨部门协作，项目化管理；
低：要求复用，也就是建立公共基础模块。我们知道，可复用可以提高效率，降低成本，这也是流程的特点之一。

在研发体系内，根据需求来源的不同走不同的开发流程。通常需求来源于两种，一种是产品规划内的需求，一类是客户定制化需求。

1）产品规划内的需求是内部需求，是企业根据商业战略进行战略规划和分解而制定的，走产品开发流程，包括概念、计划、开发、验证、发布和生命周期管理6个阶段；

2）定制项目的需求来源于外部，具有临时性和紧急性，一般是商务人员在与客户沟通中搜集到的，需要经过项目论证、商务交流、计划及合同、开发、验证、售后服务6个阶段；

3）此外，还会因在产品规划或定制项目中发现了无法攻克的技术难题而走技术预研项目流程，通常流程是立项、开发、验证、发布及成果化4个阶段。

产品开发流程的不同阶段对应不同的交付物，通过关键节点决策评审把关输出，确保“产品开发”这项投资交付的是有用、有价值的东西。比如，在概念阶段要进行概念决策评审。决策的依据是什么呢？——假设和验证。

这个过程需要产品、解决方案、研发项目经理跨部门协同，共同协作，通过分析市场机会、财务结果、成功的理由说明做这个产品或项目是有价值的、值得投资的，常见的文档载体有商业论证和产品需求分析说明书。

这时我们就看到，IPD流程相比于传统研发流程的优势之一在于，它关注的是整体而不是局部。研发只是IPD的一环，研发过程也不是研发部门埋头苦干就可以，研发也要“以客户为中心”，要和内部客户打交道，要跨部门协同，研发是业务价值驱动的。

当然，IPD虽好，也不能套死，需要企业根据实际情况程进行设定、持续改进，不断提高研发效率，实现持续“准、快、低”交付产品！

LTC流程

华为三大业务流程体系IPD/LTC/ITR（内部剧透）.ppt​mp.weixin.qq.com/s/tADIBwTZ-8iighO4-9eRKQ​编辑

LTC，lead to cash，中文叫从线索到回款，讲的是从商务发现线索到现金回笼的全流程，LTC流程集成了销售、工程、服务、财务等业务流程，正是把IPD流程产出变现的过程。

LTC与我们常说的客户关系管理、商机管理不同，它是横向贯通、端到端的项目运作。LTC流程一般包括线索、机会点、合同、交付、现金五大阶段，每个阶段有不同的负责人、不同的控制点，最终实现利润、收入、回款，也就是企业经营的主要目的。

在线索阶段，主要责任人是销售经理，负责收集和生成线索、验证线索、培育线索；

在机会点阶段，销售经理和解决方案经理双剑合璧，评估商机是否值得做，进行投入产出分析，如果经过验证值得做，继续投入，如果方向与公司战略偏离，就可以停手，及时止血，不能沉浸在沉没成本中拔不出来；

对于值得继续投入的商机，引导客户标书制作和评标标准，制定并提交标书；
当然，我们的最终目标不是中标，而是签约。

在机会点和合同这两个阶段，是我方与竞争对手、客户在信息和时间上的赛跑，只要还没签合同，即使中标了也不能放松警惕。

在合同阶段，销售经理、解决案、交付经理三人应形成铁三角，目标对齐，持续协作，拿下优质合同。有人可能不解，为什么合同还没签，交付经理就要参与？因为合同签订后活是要交付团队干的，身经百战的交付经理能够对项目交付进行准确评估，并且提前进行工作计划安排和人力规划，这也是为什么现在大部分项目要求交付经理参与前移的原因。

签订合同后，就进入了交付阶段，交付阶段的第一件事就是项目交底会，会上项目指挥权由销售经理转到交付经理。在这一阶段，销售、交付项目组、财务应形成良好联动，交付组将项目进展及时与销售经理沟通，销售经理按项目进度促成回款，财务确认回款情况。

请永远记住，拿到手里的才是真金白银，合同额还只是字面数字。

项目验收后，转入售后，各位销售经理，别忘了还有一笔难以收回的质保金。

传统的销售流程经常是销售签回合同就完事儿了，财务与销售直接的关联只在回款和发票。那么在LTC流程中，财务的角色可不仅仅是回款确认和开发票，财务在LTC全过程的参与重点在四点：

一是在管理机会点阶段需要概算，作为报价参考和投出产出分析参考，一般来说，销售团队应培养基础财务能力，尽量由销售经理自行负责概算；
二是合同签订时的预算，作为合同执行的成本基准；
三是合同交付阶段的核算，即实时的账务处理；
最后是决算，一般是年度或半年度，当然也可以在合同执行结束后对项目进行决算。

在LTC流程中，财务参与了业务，所以财务更懂业务，企业能够实现业财融合。

我们说一家公司的价值在两方面体现，一方面是业务盈利，另一方面是人力资源。而归到底，做什么样的产品、培养什么样的员工都是为了盈利，盈利能力就是检验公司价值的试金石。

LTC流程打通外部客户和内部各业务部门，通过向客户交付服务、向客户回款，实现公司盈利。LTC流程，是业务主流程。

ITR流程

只有上帝做的东西才没问题。现在没问题，时间长了也可能有问题。有问题，公司就要解决、关闭，这就是ITR。ITR ，issue to resolved，中文叫从问题到解决，是面向所有客户服务请求的端到端流程。

相比IPD和LTC流程，ITR流程会简单一些。ITR流程包括技术服务请求受理、处理、关闭三个阶段，该流程的关键在于：

1. 满足售后服务关键需求；2.建立关键流程活动规则；3.建立与IPD和LTC流程的接口。

其中，第1点是ITR流程的基本目的，自不用说。第2点和第3点是什么意思呢？

首先讲第2点 建立关键流程活动规则。有规则，才有方圆。举个例子，比如技术服务请求受理阶段，首先要接受服务请求。但是不能说所有的请求都接吧，那是极大的资源滥用，那么就要建立规则。规定技术服务请求要按什么模板描述、包含哪些关键事项，什么情况下接受请求，什么情况下可以让客户自查。这就是规则，规则讲清楚、讲明白，按着套路来，效率就提高了。

第3点 建立与IPD和LTC流程的接口又是指什么呢？在技术服务过程中可能会产生二次订单，及时识别机会，进入LTC流程；也可能挖到客户需求，则进入IPD流程。

技术服务完成后，事情就结束了吗？NONO，请一定不要忘记我方客方双方互动，通过客户回访，了解客户反馈，尽力促成二次订单，接上LTC流程。
互动结束后，技术服务请求关闭。

以上就是创造价值的三大主业务流IPD、LTC、ITR，贯穿客户与公司交界面之间端到端的流程，帮助企业实现从客户需求出发，到达客户满意终点。

这三大流程经过很多优秀企业的实践验证，也让很多企业尝到了管理红利。

因此，可作为每个公司的流程体系构建参考。但千万不要生搬硬套，否则很有可能削足适履。构建流程型组织，找到公司真实的业务流，理清流程之间的逻辑关系，持续优化改进，才是硬道理！

第五篇，从线索到合同

合同的全生命周期

想要清楚自己将去往何方，必须先清楚自己身在何处。所以首先我们来看合同全生命周期，以便你心中有一张地图，能更清晰地定位现在工作所处阶段。通常来说，合同分为售前阶段、合同签订阶段、合同履行阶段三个阶段，每个阶段末有一个里程碑事件，每个里程碑意味着上一阶段的结束，同时也是下一阶段的开始。

• 售前阶段包括的工作有：线索管理、客户管理、获取商机、需求调研、撰写方案、投标报价，相应地，输出的文档包括：线索跟进记录、客户跟进记录、调研报告、技术方案、投标报价相关文件，这个阶段的里程碑事件就是客户宣布投标结果，如果我方未中标，则这个项目就止步于此了，如果我方中标，那么恭喜你，进入合同签订阶段；
• 合同签订阶段包括的工作有：需求调研、撰写技术协议、双方商务谈判、合同评审、签署合同、合同归档，输出的文档包括技术协议和商务合同，以及合同评审记录，这个阶段的里程碑事件就是合同生效，生效后就进入合同履行阶段；
• 合同履行阶段包括的工作主要包括两方面，一方面是我方项目组实现可交付成果，由客户验收，另一方面是我方销售按合同回款条款向客户收取回款，项目通过验收，回款完毕意味着双方责任完成，合同履行完毕。

通常，对于销售来说，最重要的事情就是签单和回款，签单是在售前阶段和合同签订阶段完成，回款在合同履行阶段完成。
以上便是一个合同的生命周期，看起来似乎三句话就把一个合同完成了，但其实这只是框架，具体如何执行光了解框架还远远不够，不具有指导意义。进一步地，我们需要知道大流程下一级的子流程是怎样的，子流程下的任务是什么样的，知道了骨架里的肉是怎么长的，才能画出骨肉全貌，才能指导业务部门具体工作，实现跨部门协同。

从线索到合同

接下来我将结合我的亲身经历，分别描述三个阶段的具体流程。本篇主要描述售前阶段和合同签订阶段两个阶段的工作流程，也就是为了实现签单的主要流程，合同履行阶段将在下一篇中与大家分享。

售前阶段

售前阶段是从线索到项目中标之间的阶段。
通常，随着项目朝着签单的方向推进，线索会被逐渐筛选，无效的线索被放弃，有效的线索会继续跟进最终转化成合同，这样就形成一个销售漏斗。很多公司按照这个流程，形成一整套的销售方法论，并制定相应规则以帮助业务人员增加销售成功率。

1.线索阶段：首先，线索的来源有哪些呢？通常来说，线索来源包括市场活动推广、渠道商、销售自身、运营等等，不同的线索在收集到之后处理方式不同，销售自身引流和渠道引流往往是销售人员的私域流量，市场活动推广、运营带来的往往还没有主人，需要销售运营人员进行线索分配分配到具体销售人员身上，在线索明确主人以后，就要尽快跟进，了解线索情况，是真是假，是虚是实，尽快转化为商机。
2.商机阶段：当有实质性机会时，进入商机阶段，商机意味者客户内部立项，有预算，我们经过客户拜访了解到了客户需求。在这个阶段要经历需求调研——>方案设计——>招投标——>中标四个子阶段。商机阶段通常是最关键也是耗时最久的阶段，大的项目可以要花上几年才能实现转化为合同。要了解项目中客户需求、客户人物关系、项目信息，包括客户预算、竞争对手，其中关键人物是非常重要的，找不到决策关键人物，可能都在白费功夫，所以需要一个商机决策关系图来推演谁到底是决策人。有一个有趣的事情是，往往在桌面上说“这事儿我说了算”的人，通常都不能做主。
企业可以借助客户关系管理系统CRM进行管理，并设置一些规则，比如销售员获取线索后X天没有跟进可以回收以便督促销售人员推进，不要浪费机会，或者是商机多久没跟进则提醒销售跟进。目前市场上知名的CRM系统有，国外的salesforce，国内销售易、纷享销客都是做的不错的厂商。
线索阶段往往是销售一个人去探虚实，与线索阶段不同，在商机阶段，项目协同非常重要，需要售前人员支持、撰写技术方案、报价评审等等跨部门协作，如果公司规模小，销售一个电话过去，可能就能获得支持，但如果企业规模大，就需要通过流程将这种跨部门协作机制固化，否则容易产生职责不清、分工不明、销售人员无从下手的情况，进而耽误时机。
以下是几个常用的协作流程：
1.售前技术支持

特别强调两点：

第一、在销售发起申请时要将所了解的项目信息进行说明，比如项目需求、竞争对手、客户人物、前期进展等，不要光一个客户名字丢过去就让支持，不便于领导判断是否值得投入，售前人员也要重复沟通，增加了沟通成本；

第二、售前支持是要投入成本的，所以调用售前的力量要有所衡量，是否确实需要，自己能不能干，能不能后面培养，现在销售发展的大方向是技术型销售，销售员需要逐渐提高自己的技术水平增加不可替代性。

2.报价评审

报价评审中最重要的是两点：技术方案和利润核算。
一、技术方案要判断能不能实现、如何实现客户需求，主责在技术部门。
二、销售人员综合考虑制造部门或生产部门评估的成本、公司的利润要求、竞争对手情况制定报价方案，公司要按照合同利润模型进行核算。利润核算需要第三方来执行和监控，要么是合同管理员，要么是系统自动计算。
内部报价评审通过之后，销售就要揣着这一整套方案，如同上战场战士的拿了武器一样，去进行投标或者与客户谈判。投标的流程和操作比较复杂，耗时耗力，一般非国企、小项目不会专门设投标流程。如果有幸，你的方案被选中了，那么恭喜进入下一个阶段；如果不幸，也没有关系，收拾情绪，转战下一场，商场如战场，胜败乃兵家常事。不管项目成功还是失败，我都建议要做一件事——复盘，沉淀经验，整体提升。

合同签订阶段

记得我在上一篇中讲过，“只要还没签合同，即使中标了也不能放松警惕”，中标后又黄了虽然是小概率事件，但一旦发生影响太大，所以不能掉以轻心。签项目就像打怪升级，一关过了还有下一关。中标后，进入合同签订阶段。
合同签订阶段关注两件事——技术协议和商务合同，要经过两道流程——技术评审和商务评审，关注两拨人——内部和外部。
可能有些人问，售前阶段不是已经制定了技术方案了，为什么还要做技术评审呢？为什么不直接用技术方案呢？实际上，结合你的经验你想一下，在投标阶段，为了获得客户青睐，我们的方案是不是多少有些“吹牛”的成分在，而合同是落到纸上，具有法律约束效力，这个时候项目的范围、可交付成果一定要尽量澄清，千万不要明明干不了，还作下承诺，或者项目范围不明晰、可大可小，给后面合同履行留下隐患，甚至对簿公堂，双输结局。
合同签订的两个流程通常设计如下：

1. 技术评审

2. 商务评审

这些主流程在各个公司大同小异，但正是那些小小的差异点，别处心裁地为使用者考虑，在效率和风控之间权衡，往往决定了这条流程是个平庸的流程，还是好的流程。
在合同评审这个流程上，有三个小建议：

1. 提高连贯性：

提高连贯性的第一点，项目基础信息无需重复填写。一个项目从最开始经历了线索、商机到合同的转化，在这些过程中，项目的信息被不断补充，比如客户名称、项目名称、项目团队人员、行业、地区等等，而每次评审都需要填充这些基础信息以便评审，最好能够借助IT技术手段，保持项目信息的连贯，实现数据无需重复录入；
提高连贯性的第二点是，自动发起。我们看到从报价到技术评审再到商务评审，有三条大流程，每次销售都要提交且发起，销售真的很烦，所以我们进行了一个小的改动，让上一个流程结束后自动发起下一个流程，这样销售会更加无感；

2.总结评审checklist：

每一个评审阶段都有一些常规的评审点，可以整理归纳成一个checklist，供提交人员自查、评审人员参考。通过这种方式实现流程推动业务，实现可复制的成功。

3.合同数据准确

这一点在第三篇提到过，用好流程可以带来真实数据，沉淀下来的数据可以驱动运营决策，所以数据的问题，包括合同基本信息（合同名称、经办人、客户名称、合同类型）、合同额、行业、回款信息、产品组成等等，这都是以后做数据分析的来源和依据。

好了，经过九九八十一难，各种打怪升级，合同终于生效了！

第六篇，从合同签定到下合同任务

从合同签定到下合同任务

通常来讲，业务前端与客户签定的是买卖合同。买卖合同的实质是以等价有偿方式转让标的物的所有权，即我们向客户提供标的物的所有权，客户向我们支付价款。
那么所谓的标的物有哪些类型呢？不同类型的标的物又有什么区别呢？
在交易模式的早期阶段，标的物基本都是有形的，我们日常生活中吃的穿的用的都可以是标的物，比如电脑、水果、家具；后来随着科技发展，软件越来越多，这种无形之物也成为了交易对象，服务也是，因此标的物增加了无形物品、服务的类型。

以上这些标的物，可以这样分类：

1. 可以一次性提供的称之为产品买卖合同，我们只需要按照合同要求，由供应链部门向客户提供合同范围内的物品，因此需要给供应链部门下达任务。
2. 需要提供服务从而达到客户要求的称之为项目交付合同（不同公司有不同叫法），此类合同需要专门的实施/交付部门组建项目组，为客户提供合同范围内的服务，因此需要给实施/交付部门下达任务。

供应链部门或交付部门接受到任务后，开始按合同要求提供标的物。
产品买卖合同通常比较简单，供应链部门向客户发货、客户签收确认，即完成了标的物交付。这里需要注意两点：

1. 第一点关于回款，产品买卖合同一般是一手交钱一手交货，在合同签署时，回款条件可以是先款后货，也可以先货后款，也可以先预付款多少、到货后再付剩余款项。当然，越早付款，作为乙方来讲越有利。通常情况下，公司会要求产品买卖合同必须有预付款。
2. 第二点是关于签收确认，货物不是发出去就完事儿了，必须要有甲方确认签收才可以记为确认收入。确认签收的凭证也有多种，有的需要开箱验收报告，而有的只需要快递物流信息页面显示签收即可。

而项目交付合同相比产品买卖合同而言，具有复杂、周期长、相关干系人多的特点，不管是信息化项目还是建筑项目，都要进行项目管理，涉及到工程、采购、财务、销售、供应链，具体我们在第七篇讨论。