一、背景
我是在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的本質，其實還是一個協同的問題，當然這個協同是需要解決流程層面的協同。然后這種協同的機制，如何通過崗位和角色來解決，以及我們的信息系統怎么去協同，保障我們在不同的環節時，相應的信息能夠流入對應的崗位和部門，以啟動相關的工作，這就尤為重要。
現(xian)在很多公(gong)司的信息化建(jian)設(she)里面，都包含像CRM系統(tong)(tong)，PLM系統(tong)(tong)，ERP系統(tong)(tong)，SM系統(tong)(tong)等等。但(dan)是很少有(you)公(gong)司能夠(gou)去解(jie)決前(qian)端的
轉載：//citymember.cn/zixun_detail/109195.html
