<p style=margin: 0px; padding: 0px; max-width: 100%; clear: both; min-height: 1em; color: rgb(62, 62, 62); font-family: -apple-system-font, bl<x>inkMacSystemFont, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif; font-size: 16px; letter-spacing: 0.544px; text-align: justify; box-sizing: border-box !important; overflow-wrap: break-word !important;>一、背景
我是在05、06年的时候在华为从事流程管理的工作，有接触过LTC的相关的内容。在那个时候LTC的概念并没有提出，这个时期曾经有一个项目叫E2E，即端到端项目，解决的就是从前端的销售到合约，以及交付整个过程的流程的梳理工作。我曾有幸参与这个项目的部分工作，并作为推行小组的组长派往独联体去做这个流程推行和落地的工作。
后来在这个项目的基础上，我作为这个采购流程管理的负责人，又主导了另外一个项目，也跟着一个端到端项目有相类似的特点。当时我们起名为叫外配套采购优化项目，就是在海外的工程项目的交付过程当中，除了自主生产的设备的这一部分交付之外，那还有一部分涉及到铁塔、油机、空调，还有海外工程等类似这些方面所涉及的物资，所需要的采购交付。
当时所面临的问题呢，跟现在LTC目前当前所存在的问题是非常匹配的。因为我们当时在分析这个流程的时候发现，前端在投标的时候以及这个合同评审的环节过程当中，压根就没有这个采购相关角色的参与，导致在后端工程交付以及配套采购交互的环节当中，后端业务部门非常的被动。
所以外配套采购优化项目重点要解决的，就是在工程项目、在签署合同以及在这个交互过程当中，如何配套以及匹配和协同项目交付的整个流程协同。
之后从17年开始，又接触比较多这方面的需求，如17年参与了某家建筑五金工程公司整个LTC解决方案的一个整个研讨和梳理。这家公司主要是为水立方、鸟巢等大型的工程建筑提供五金产品，设计多样化的五金产品，也提供有定制，涉及多个门类多个产品的统一交付和配套交付的问题。那么在这个交互的过程当中，他们和发现前端的销售跟后端的设计，以及后端的生产采购，存在很多的这种脱节和不协同的问题。
现在我们在这个项目里面来讲的重点也在解决这个前后协同和衔接的问题。从去年开始到现在，我还一直在为一家提供服务解决方案的公司做相应的管理咨询项目，包括前后一体化的流程体系、组织体系、相应的IT解决方案，来解决前后衔接和这个业务匹配的问题。所以通过这一些相关的案例，或者说一些咨询的经历呢，那我对LTC的业务有一定的理解，也有自己的体验和感悟。
今天就先跟各位就LTC做一个概要性的分享。因为LG里面所涉及的内容非常庞大，基本上把公司的所有业务部门都卷入进来。所以一些很详细的内容，或者说一些运行的机制，今天很难一下子分享完。
另外，我们所做的管理咨询的业务，也是一个典型的LTC项目。在跟客户沟通的时候，经常会听见这样的要求。就是客户会问，在后面的实施里面还是你做吗？因为在原来很多的咨询公司呢，也会面临的一个问题，就是前端的销售很强，等到了后段实施的时候，派出的顾问团队跟前端的授权的团队不一致，导致对象目的理解、项目的解决方案以及项目能力不能匹配。其实这也是LTC当中所面临的一个典型的问题。
二、什么是LTC
从这个角度来讲，我们需要理解什么是LTC；LTC背后的本质是什么；针对我们的业务来讲，是否适合采用LTC的方案来解决；以及LTC体系建设，需要哪些基础和前置条件。这些就是我今天要想跟大家分享的内容。
LTC，leads to cash，就是从线索到现金到回款整个全流程。也就是说从我们最开始获得销售机会，销售线索，到提供解决方案以及商务合同，再到项目的交付或者合同的交付以及回款整个全流程。
如图是华为对LTC的全流程的分解和它的主流程。从这个LTC的主流程可以看出，LTC所关注的是端到端、关注前后衔接等相关问题。之所以会有这样的一个解决方案，是因为在很多的企业业务当中都会面临着以下几个问题。
一是前后方案不一致的问题，因为针对定制化的，或者是这个工程性的这个解决方案的业务，前端是由销售，或者说解决方案团队去提供解决方案，但是合同签署完成之后，相关的授权团队或者是销售人员抽出，变成后端的交付经理。这就变成了另外一个团队在做相应的交付。
第二个就是前端所确定的需求，在后端没有得到有效的传递，导致后端在理解需求和确定需求时，需要重新去做识别和相应的解决方案。
第三个从管控的角度来讲，前端确定了相应的销售方案，但在后端实施或交付的时候，需要对方案再做相应的审批、确认等管控。这就导致，对于相同的事情在前后要做多次的管控。
这些问题我认为来讲有两个方面的核心影响，一个是在客户界面来讲，会让客户感受到公司业务在前后的这种不一致，还有一个是会带来相应的这种质量和需求匹配等等这些细节的问题。
还有就是内部效率的问题，比如说后端部门在前端没有介入，后端环节前端也不参与。这就导致信息不通，信息脱节，而影响我们整个沟通和交流的效率。这样的话不仅影响我们的运行成本，还会拉长我们整个交付的周期。
我记得在华为的时候，当时面临一个非常典型的一个问题，就是在这个工程交付的过程当中，自有的设备交付，提前两个月到了现场，但是海外配套采购的业务，可能在两个月之后才完成交付。我们的设备在这一个站点呆两个月，风吹雨淋的，可能带来很多的这种质量方面和交互方面的问题。这个问题其实是涉及到我们在合同签订，甚至包括在前端解决方案的过程当中，采购如何提前介入的问题，以及我们项目交付协同的问题。
三、LTC的本质
所以呢，从类似这些问题角度来考虑，我理解LTC的本质，其实是解决业务协同的问题，当然这个业务协同呢，会比我们之前所谈到的这个IPD会更加广泛。也正因为如此，华为在LTC这块的建设前后花了将近七年的时间，到最后七年的结束还是以勉强合格的方式来做的项目的结束。
LTC的本质就是解决业务协同的问题，但这个业务协同需要放到一个更大的层面上来考虑和解决。如图是我在一家公司提供的LTC解决方案。
图中将我们的整个过程，即从线索到最后的交付以及回款，整个过程的流程做了一个完整概要展示。另外在这个过程当中，我们所涉及到的不同的业务角色，包括前端的销售，中间的产品经理以及开发，后端的这个交付、以及采购，甚至包括我们的公益计划，生产等等，在整个全流程里面不同的环节所需要做的工作也有展示。
举个例子，某家给地铁做屏蔽门的公司。在他的体系里面，我们发现，在前期投标的这一个解决方案中，销售以及做解决方案的项目经理就直接指定了相应的供应商。但是，在后端的采购压根就不了解他的解决方案所标注的内容。这导致在前端的报价里面所列出来的价格，以及供应商的供货能力没有得到有效的确认，就直接按照市场所获得的初步的信息给客户做方案承诺。再后来真正到了这个项目的交付过程，采购才开始去了解标书的要求，发现其中有指定供应商，还有价格限定，结果发现压根就没办法按照标书或者说合同的要求去履行。
这个问题其实就是LTC当中最为典型的一种业务场景。比如说在技术方案阶段，除了我们的产品经理获得销售所需要做的工作之外，那么比如说采购，在这个环节，如何提供供应商信息以及提供价格信息，如何启动供应商的认证等，这些相关的工作，就显得非常有必要。甚至在投标中，就需要确定供应商，以及与供应商签订联合投标的类似协议。这就会使我们的投标、合同以及后面的交付非常顺畅，不会出现前面所提到的类似问题。
类似这些协同，除了刚才提到的采购，其实包括我们的研发、工艺其实都是关联的。所以，我理解LTC的本质，其实还是一个协同的问题，当然这个协同是需要解决流程层面的协同。然后这种协同的机制，如何通过岗位和角色来解决，以及我们的信息系统怎么去协同，保障我们在不同的环节时，相应的信息能够流入对应的岗位和部门，以启动相关的工作，这就尤为重要。
现在很多公司的信息化建设里面，都包含像CRM系统，PLM系统，ERP系统，SM系统等等。但是很少有公司能够去解决前端的