CRM系統：CRM項目管理中的長通路與短通路

在渠道管理中，如果只經過一個經銷商，稱之為短通路;經過兩個或者兩個以上經銷商的，則稱為長通路。經營者需要對營銷通道是長的好還是短的好，做出慎重的選擇。因為兩者各有利弊。從節約成本、降低費用的角度考慮，經營者最好利用短路，但是，從長遠發展考慮，則應該考慮長的渠道，利用別人來幫你賺錢。 　　其實，不僅在渠道管理中，有長通路與短通路的抉擇，在CRM項目，也有類似的考慮。 　　如我們在實施CRM項目的時候，項目負責是是直接對每個員工負責，跟每個CRM系統操作員面對面;還是直接對每個部門經理負責，讓他們去面對他們手下的員工?其實，這就是一個長通路與短通路的問題。若我們項目小組負責人直接對每位員工負責，那么我們可以收集到一線的信息，而且，這些信息不經過部門經理傳達，則可能更能夠反映員工的實際意圖。但是，這么做的話，企業也是需要付出代價的。如我們要依次向員工索取需求，則需要花費我們比較多的時間;而且，我們還需要對這些信息的價值進行刷選，因為有些可能只是代表員工自己的意見，而不是這個部門的整體價值的體現。而若我們在項目的實施過程中，選擇常痛錄，即我們只對部門經理負責，然后部門經理再在部門內部推廣CRM項目，一級一級的推廣下去。如此的好處，就是我們項目負責人不用勞神去收集各個部門的需求，而可以抽出時間來想想解決方案。不利之處就是通過長通到獲取的需求是經過部門經理處理過的，有時會出于表達方面等的原因，我們得到的需求可能已經變味了，或者不能夠真實反映業務的實際情況。不過這兩者之間還有一個最大的差異，就是若通過“短通路”的話，一個CRM項目結束后，可能各個部門的負責人在我們顧問離去后，仍然不能擔負起系統完善的重任，因為他們不知道如何去收集需求、如何改善系統;而若采用“長通路”的話，則就是給各個部門負責人一個鍛煉的機會，讓他們能夠成本自己部門模塊的負責人，給了他們一個需求收集、項目推動、員工培訓的鍛煉機會，如此的話，項目上線后，即使我們實施顧問離去了，則他們仍然能夠承擔起系統完善的任務。因為經過項目實施的歷練，在我們實施顧問的指導下，他們已經學會了一些系統完善的技巧。所以，若從企業長遠發展的角度看，從系統持續完善的角度考慮，則很明顯，采取“長通路”的項目實施方法，更有利于企業發發展。 所以，筆者認為，在CRM項目實施過程中，要采用“長通路”為主，“短通路”為輔的策略。具體的來說，筆者可以給大家提如下的一些建議。 　　1、利用“長通路”，為企業培養出幾個內部項目實施顧問。我們都知道，CRM項目實施的話，一般只有短短的幾個月。CRM項目上線后，項目是否就結束了呢?其實不然。CRM項目上線后，項目只是取得了暫時的順利。CRM系統的后續完善，才是CMR項目的重頭戲，這個系統的完善，可能會伴隨企業發展的下半輩子。而系統的完善，基本上是CRM實施顧問離開后的事情，也就是說，此時，企業需要自己進行CRM項目的持續改善工作，實施顧問只能做一些偶爾的指導。所以，利用長通路的實施方法，在企業內部培養出幾個實施顧問，讓他們在實施顧問離去后承擔項目改善的重任。只有如此，企業的CRM項目才能夠良性的發展下去。 　　2、長通路，可以利用部門經理的經驗，先過濾一遍需求。企業員工的需求，哪些是急需的，哪些可以暫時放一放;哪些是共性問題，而哪些又是個別現象;在系統中需要實現哪些需求，不需要實現哪些需求，等等。這些內容的話，我們實施顧問都不能夠替企業決定。而若我們現在不是自己去向員工去收集需求，而是借部門經理的手，去向員工收集需求的話，則部門經理就會事先把需求過濾一遍，從而得出的需求質量會高一點。同時，我們可以給部門經理提出一個要求，讓他們在每個需求前面標上序號，表示需求的重要性與實現順序。顯然，這些工作的話，都需要部門經理完成，我們實施顧問不能越俎代包。 　　不過利用“長通路”實施方法有一點不好，即需求通過部門經理來進行傳達的話，有時他們傳達的需求可能跟實施上有比較大的差距。筆者在CRM項目實施過程中，遇到過多次了。如部門經理反映的需求是要能夠統計客戶投訴的處理效率，要有一張報表能夠反映出客戶投訴處理了哪些，以及是否在規定的時間內處理完成。但是，后來在項目實施的過程中，部門經理幾次修改需求，原來這個需求跟他下面員工的實際需求差別比較大。下面的員工希望是能夠通過報表自動統計投訴處理的客戶滿意度、相關的責任人等信息。后來還是筆者跟實際的操作人進行面對面的交流，才了解員工真正的需求。 　　1、當一些需求表達不清楚的時候，最好能夠讓用戶提供他們所期望的表單或者報表格式。有時候，我們實施顧問可以要求企業用戶提供相關的報表格式，并注明各個字段的含義。若有相關計算的，則還需要列出計算公式。如此的話，就有助于我們了解用戶的真正需求，這也可以有效避免部門經理傳達需求時所產生的口誤。而且，有了這些單據的話，我們也可以事先在系統中配置出來。從來理論上來說，只要系統中有的數據，我們都可以在報表中體現出來。不過用戶在設計報表的時候，也必須考慮邏輯性與實用性。也就是說，用戶在整理報表或者表單的時候，最好是在現有的表單基礎上，進行適當的修改。而不失從零開始，根據自己的想象進行重新設計。根據筆者的經驗，如此設計出來的報表往往過于“完美”，而在實際工作中，用處不是很大。 　　2、對于意思模糊的需求，我們不要盲目在系統中實現，以免做無用功。當用戶的需求比較模糊時，而系統中又沒有對應的功能，一般需要通過二次開發實現。碰到這種情況，無論是我們實施顧問，還是企業用戶都不要急著實現這個需求。而是需要先向用戶了解清楚需求的內容。一般來說，這個需求模糊的原因，可能有兩種情況。一是部門經理也不是真正的需求人，所以，他可能描述不清楚具體的內容。此時，我們實施顧問就需要走“短通路”，讓部門經理找來當事人，面對面的進行交流，往往能夠取得不錯的效果。還有一種原因就是企業員工自己都不知道需要什么。他們可能在以前的公司中遇到過類似的報表或者功能，但是，若讓他自己描述的話，就描述不清楚了。此時，按照我的意見，就是先把這個需求放一放，讓用戶仔細想一想，然后設計出一個管理模型出來，然后我們實施顧問給與優化。當然在這個管理模型的設計過程中，用戶也可以跟我們實施顧問保持聯系，聽聽我們對于這個模型的建議。總之，對于模糊的需求，筆者的建議是，要到弄清楚才能夠實現，而不能在模模糊糊的情況下，配置系統。 　　3、某個需求實現后，就要馬上交給用戶進行測試，看看是否跟他們的期望一樣。其實，就是溝通的最好，由于文化背景、工作經驗的差異等等，難免有誤差。所以，筆者認為，根據用戶的需求配置好系統后，我們要及時把結果反饋給用戶，讓他們來判斷這個功能跟他們想象中的是否一樣。但是，有些軟件公司或者實施顧問，希望把所有需求都實現后，再把結果反饋給用戶。這么做得話，有一個最大的缺陷就是，企業用戶不能夠一一判斷需求是否滿足他們的要求，但是為了趕項目的進度，就匆匆忙忙上線了。結構在上線的過程中，才發現企業員工、部門經理、實施顧問三者之間存在著比較大的認識差異。此時，就不得不再對系統進行開發、配置、調試，這對CRM項目的影響是很大的。 　　長通路與短通路，這是我在渠道管理培訓上學到的內容，筆者發現這跟我們項目實施具有共同之處，所以在這里就發表一些感想。大家若有什么不同的意見，歡迎大家交流，共同進步。