由於中後台系統開發成本高，但是通用性較強，因此對於大部分企業來說，採購成熟商業套件進行實施，從成本和時間上都更為合算。即便是某些一線網際網路企業，他們早期的後台系統也採用了Oracle這樣的商業化套件。
但是，相對於自研，外采系統往往潛藏著更大的風險。特別是網際網路企業，由於業務調整迅速，組織集權度低，用戶體驗要求高，外采系統的風險遠高於傳統企業。因此，網際網路公司外采項目的實施管理，是一個頗有挑戰性的課題。
01 外采項目的風險
外采項目的風險主要體現在兩個方面。一是自研系統往往是小步快跑，從核心功能出發，再不斷進行疊代。而外采系統則追求一步到位，需要在相對短的周期，一次性形成相對完整的解決方案，系統交付的範圍往往較大。另一方面，由於外部系統和外部團隊等不可控因素，也使得外采系統的實施雪上加霜
1、舊城改造不容易
為了降低交付成本，商業化軟體必須追求產品的標準化。在信息化時代，SAP、Oracle都是用一套產品實現多個行業的解決方案，這除了導致產品複雜度的大大增加，用戶體驗也受到較大影響。到了數字化時代，SaaS廠家往往專注於少數行業，這使得行業貼合度和用戶體驗有了大幅度提高，但是軟體的二次開發能力也受到了很大限制，導致用戶的個性化訴求無法得到有效滿足。
網際網路公司自研的產品在設計之初就是為企業貼身定製的，其後又不斷進行疊代，其業務切合度和用戶體驗都是商業化軟體所難以比擬的。因此，商業化軟體的二次開發難以避免。但是，由於商業化軟體的固有架構和封閉性，使得其改造難度和成本都遠大於自研系統。
曾經有一家國外企業想要優化實施系統的用戶體驗，最後發現必須對所有介面都進行重新開發，可以想像這樣的工作量有多麼巨大。
2、可怕的60分原則
實施公司的目標是盈利。這就意味著，在合同金額確定的前提下，如何控制成本和風險是實施公司的管理重點。
實施項目是一個「需求逐步明晰化」的過程，因此也無法通過合同條款明確所有細節的要求，這就導致交付團隊所認為「應交付的內容」，往往小於甲方所認為「應交付的內容」。
同時，反正只要項目能夠交付，合同金額都是確定的，這也導致交付團隊「多一事不如少一事」，這就是所謂的「60分原則」。
60分原則的危害性很大，很容易導致風險被遺留到項目後期。經歷過實施項目的小夥伴可能都有這樣的經歷：一個實施方自己很容易發現的問題，但是一直拖到上線前用戶抱怨，實施方都沒有主動提出來。但是，這是實施類項目所固有的風險，我們只能選擇去面對，想辦法去規避。
3、不可控的團隊
外采項目難度大風險多，對團隊的要求也是很高的。除了個人能力，團隊協作和緊張的氛圍也是必不可少的。
由於實施團隊屬於外部團隊，我們並不具備人事權和賞罰權，也就意味著沒有辦法按照我們的要求去管理團隊。
曾經在一個項目中，實施團隊的一個核心骨幹因為各種個人理由不斷請假。後來我才得知，一部分請假其實是支援其他項目。毫無疑問，這種行為都是實施公司授意的，但是作為甲方，也很難抓住他們的把柄。
4、風險轉移漏斗
從合同簽署的那一刻起，風險就開始像漏斗一樣，從實施團隊的一端轉移到甲方項目組團隊。
因為一旦項目啟動，甲方項目組團隊就有責任推動項目成功上線。即便項目後期出現重大風險，為了項目成功，甲方項目組團隊也只能選擇去承擔和解決。這就是所謂的風險轉移漏斗。
風險轉移漏斗可能導致實施團隊存在僥倖心理，拖延問題的發現和解決，最終影響項目的交付質量。
5、跨部門協作的陷阱
大型實施項目往往需要多個部門的協作。
在傳統企業，會從各部門抽調核心骨幹脫產投入項目，這在很大程度上解決了跨部門協作的問題。
在網際網路公司，各個部門都有苛刻的業務KPI指標，每個核心骨幹的工作量都是飽和的，這就決定了讓他們脫產幾乎是不可能的。另外，由於項目工作會占用較多資源，影響到他們自身KPI的達成，也增加了跨部門協作的難度。
在曾經的一個數據中台項目中，需要各業務系統配合改造並接入數據中台。我們投入了大量時間進行協調，最後請CTO幫助每周review各個團隊的改造進度，才保證了項目的按時推進。
02 實施項目的管理重點
實施項目的諸多風險，決定了我們需要在各個階段重點部署，並從制度和機制上防範風險。
1、項目立項
- 項目價值與風險明確
實施項目最大的風險，來自於高層不切實際的期望。
由於外部公司專業售前的早期介入，很容易將高層對項目的期望值抬高，而一旦項目達不到預期，最終受傷害的可能是內部團隊。比如，高層可能很期待項目的管理諮詢效果，同時默認系統的用戶體驗是網際網路級別的。但實際上優秀又懂特定行業的管理諮詢顧問其實是非常稀缺的。而實施項目是舊城改造，用戶體驗很難在短期得到根本性改善。
在這個階段，建議通過安排投標方講解具體諮詢案例、演示系統操作等環節，幫助高層獲取更多有價值的信息，從而做出更合理的決策。
- 項目團隊與機制準備
網際網路公司的工作節奏都很緊張，考慮到實施項目的諸多潛在風險，必須要建立一支高效的項目團隊。在這支團隊中，除了項目經理，還有幾個關鍵角色是必須要存在的。
項目總監：甲乙方項目經理在項目推進過程中，難免會出現推進困難；雙方在協作過程中，也可能會出現工作矛盾。為了不影響項目進度和質量，當出現超出項目經理能力的情況時，需要項目總監出面協調解決。同時，項目經理也需要定期向項目總監匯報工作，以確保項目方向符合公司期望。
項目指導委員會：項目是為公司目標服務的，涉及很多重大決策。因此，需要有項目指導委員會在項目各階段進行把關，避免項目方向的錯誤；同時，項目組也需要指導委員會幫助解決跨部門協調問題和決策重大問題等。
小組組長：雖然無法讓業務骨幹脫產，但是仍然應該把他們納入項目組，同時指定其部門領導擔任組長。這樣，當出現資源協調等問題時，組長可以幫助解決。
當然，僅僅設立角色並分配職責是不夠的，必須通過項目機制讓各角色主動承擔起責任。常見的項目機制包括項目例會、專項匯報、月度優秀小組/成員評選、優秀項目評選等。
值得一提的是，項目組不能把會議和匯報當做負擔，而應該當做防範項目風險、推進項目的工具。比如，階段性向項目指導委員會匯報工作時，可以讓各小組組長來進行匯報，從而增強他們的主動性和緊迫感。
- 提前梳理需求
在立項的同時，就要開始著手梳理詳細的需求。
需求是項目的基礎，很多項目出問題，都是源於一開始的需求不夠完整和明確。建議可以開一個預啟動會，把項目團隊召集起來，正式安排需求梳理的任務。
2、選型階段
選型階段的工作主要包括產品選型、實施方選型和合同談判三個部分。
- 產品選型
網際網路公司對軟體的要求很高，因此產品選型也需要比傳統企業更加嚴格。
除了常規的重點方案講解、同行業標杆案例講解和系統演示之外，建議對軟體的用戶體驗、開放性和靈活性進行重點考察。需要強調的是如何應對組織架構的頻繁、快速調整，特別是涉及業財一體化時，如何應對組織架構快速調整是一個不小的挑戰。
另外，需要注意的一點是，要讓高層充分認識到軟體的優劣勢，否則可能就會面臨項目上線成功但「項目不成功」的局面。可以安排一些關鍵流程的高層演示，並且內部出具評估報告給到高層。
- 實施方選擇
三分產品七分實施，放在網際網路公司身上仍然適用。
同一套產品不同的實施團隊來負責，結果肯定是有差異的。實施團隊的選擇又分為諮詢公司選擇、項目經理選擇和實施顧問選擇三個方面。
相對而言，項目經理和實施顧問的項目經驗比公司案例更加重要，在這方面要重點考察和把關。甲乙方項目經理要多溝通，確保大家在項目管理方面的理念和習慣是相對一致的。至於諮詢公司，一分價錢一分貨，抱著合理的期望，選擇合適自己的最重要。
- 合同談判
合同談判可能是一個比較艱苦的環節，除了合同金額，條款的談判可能更加困難。因為實施方實際上是合同驅動的，或者更直白的說，他們只會遵循合同裡面明確了的規則。
因此合同談判階段必須要把控住關鍵條款。比如，在項目階段對應的付款比例方面，我們要確保在每一個關鍵的階段都有一定比例的付款，這樣才能持續激勵實施方保持高效的狀態。同時，考慮到風險轉移漏斗，前期的付款比例應該儘量控制得小一些。另外，需求列表也非常重要，梳理好的需求範圍一定要寫進合同，否則就有可能會扯皮。
3、項目計劃
從某種角度來說，項目計劃決定項目成敗。
項目計劃分為兩種，一種是整體計劃，項目經理需要考慮每個階段的重難點，合理分配時間和資源；一種是每月、每周和每天的計劃，項目經理要根據實際情況，充分評估項目風險，再靈活調整計劃。這種日常性計劃其實是屬於項目機制的部分。
項目管理是一個苦活，因為對於參與項目的大部分人來說，項目工作與日常工作是脫節的，有時候甚至是矛盾的，優先級並不高。項目經理實際上是一個沒有實權的崗位，他必須更多依賴別人去完成工作，這就意味著大量的協調。只有做好了項目計劃，提前考慮各種風險，項目經理才能協調好資源，維護自己的影響力，減少工作的難度。
由於乙方項目經理負責交付資源的管理，甲方則需要負責內部資源的協調。因此，甲乙方項目經理必須充分溝通，對項目計劃和項目機制達成一致。
4、項目啟動會
召開一個成功的啟動會，可以「秀出項目組的肌肉」，讓相關部門看到公司對項目組的重視。同時，在啟動會上讓項目干係人登台、發言，實質上是讓他們做出了一個正式的承諾，不失為一種有用的激勵方式。
項目啟動會可能牽涉到眾多部門，涉及甲乙方高層。因此，準備一定要細緻，並且做好排練。
5、調研與需求梳理
調研階段實際上包含了兩塊重要的工作。
其一是實施團隊詳細了解企業的業務與需求，並且與系統的標準功能進行匹配，差異的部分將作為方案編制的重點；其二是業務方詳細了解系統的標準功能，並且與企業的業務需求進行匹配，差異的部分也將作為項目的重點。
兩塊工作看起來是重複的，但是實際上是從各自熟悉的領域出發，相當於優勢互補，因此都不可或缺。
在這個階段，項目經理要參與到最關鍵的業務討論中，充分發掘和討論差異。事實上，在這個階段能否充分挖掘差異，很大程度決定了項目後期的風險嚴重程度。
6、方案編制
方案編制階段可能會遇到很多困難。對於某些大型項目，項目組面對的可能是企業長期以來存在的問題，但是需要在短短2個月內拿出具體的落地解決方案。
在這個階段需要頻繁的組織會議討論，項目經理要親自參與到最重要的方案討論中去。老實說，在這個時候也很考驗項目經理的專業能力，因為如果方案達不成一致，這個階段就無法順利完成。項目經理必須兼顧方案質量和項目進度。
某些關鍵的問題在執行層可能無法得到答案，項目組要及時向項目指導委員會匯報，讓高層來對關鍵問題決策。
在討論的過程中，要組織多次沙盤演練。只有看到具象化的操作流程，業務方才能更容易發現方案存在的問題。
最終，整體方案形成後，要進行一次正式的高層匯報，只有高層認可的方案，才能投入大量資源進行開發和配置工作。
7、開發與配置
某種程度上來說，實施項目是創新型的工作，因此項目管理的過程其實就是風險控制的過程。
由於項目進度可能比較緊張，新開發的功能往往存在bug，或者不滿足業務方的訴求。這一方面要求項目組制定好項目規範，比如產品設計需要業務方簽字確認，另一方面也要做好單點測試和驗收工作，儘可能提前暴露和解決問題。
8、集成測試
當所有的核心功能都開發完成了，要適時的組織集成測試，以確保單點功能有效的串聯起來，支撐解決方案的落地。
集成測試完成後，上線的核心條件就基本滿足了。因此，集成測試階段是一個非常重要的里程碑，需要組織一次演示，讓各組組長代表業務部門進行確認驗收。
最後，需要給高層做一個匯報，主要是匯報項目進度和各業務部門驗收情況，同時確認項目上線時間等。
9、上線準備
截止到上線前，項目組更多是小團隊、內部的工作模式。這就意味著項目還並沒有經歷全員級的用戶考驗。因此，上線準備工作需要細緻籌劃，確保一次性成功。具體來說，有以下幾個方面的工作需要重點關註：
- 上線策略
所謂廟算多者勝，上線策略需要提前考慮上線可能會遇到的問題，從而提前進行梳理，確保上線步驟、資源安排等工作準備妥當。
- 最終用戶驗收測試
我們要記住一個原則：風險恆在原則。
實施項目往往範圍廣、難度大、周期長，風險本來就容易被遺漏，同時由於存在風險轉移漏斗，即便到了上線前，風險仍然是很多的。
因此，有必要在上線前通過真實、相對完整的數據進行一次或多次最終用戶驗收。通過實際業務來檢驗系統的可用性。
對於有條件的項目，強烈建議進行一次模擬上線。我的實踐證明，經歷過模擬上線以後，實際上線的壓力會大大降低。
- 最終用戶培訓
對於最終用戶培訓，需要補充的一點是，培訓的內容不僅僅是系統操作，也包括上線作戰方案，即項目上線的計劃，以及上線問題的提報和解決途徑。
上線期間容易集中爆發問題，因此提前做好最終用戶的安撫工作，可以減輕上線期間項目組的壓力。
- 上線宣傳準備
對於涉及全員的系統，做好上線宣傳也是有必要的。一方面，可以散播系統上線的信息，減少上線期間的混亂；另一方面，也可以宣傳系統的價值，為項目組營造好的輿論環境。在某些時候，會說和會做一樣重要。
10、切換與支持階段
終於到了正式上線的階段。對於沒有進行過模擬上線的項目組來說，這是整個項目最有壓力的一個階段。不過，如果我們做好了上線策略，在這個階段應該就是累並快樂著的。
這個階段可以補充兩點。其一是如果項目經理對項目風險沒有把握，一定要提前準備好額外資源和應急機制。到了臨近成功的時候，相信甲乙雙方的高層都願意助項目組一臂之力。其二是要做好問題跟蹤，一份統一的問題跟蹤列表是有必要的。上線過程中，對於問題要確保日清日結，不能積壓；上線完成後，也要繼續跟蹤問題列表，直至項目達到預期目標。
03 總結
項目管理是成為管理者的踏腳石。
尤其是網際網路公司的實施項目，要求高難度大，能很好鍛鍊項目經理的管理協調能力。作為一個產品經理，如果我們需要接手公司的實施項目，一定要提前籌劃，建立好項目機制，把控好各個階段的項目風險，相信你一定可以在項目中有所收穫。
作者：王戴明 ToB產品江湖廝混十幾年。