項目調研的目的，項目調研的誤區和關鍵點

誤區

??? 誤區1：需求調研是形式

??? 作者曾經參與了一些大型SAP項目，這些SAP項目往往經歷選取幾家單位試點、一期推廣和二期推廣等實施過程。存在一些顧問沒有參加試點，而直接進入推廣 項目。而推廣項目的業務藍圖往往參照試點單位，于是這些推廣項目的需求調研往往會流于形式，試想業務藍圖基本確定了，需求調研在某種意義上變更可有可無 了？這樣就容易認為需求調研就是走走過場。也有一些網友提出：他們企業的需求調研只有一天，就進行了項目實施的后續階段。這些表象，都認為需求調研是不重 要的，顧問負責推廣ERP的標準功能就可以了。
?
??? 誤區2：需求越少越好

??? 有些顧問對自己的技術水平不夠自信,擔心用戶提出比較復雜的需求。所以,在需求調研階段,一些需求故意不去調研,甚至回避用戶的一些需求。需求調研階段, 并非系統實現階段,不需要出具詳細的解決方案。此時的任務是充分了解企業的業務現狀,只有充分了解了需求,識別了重要的需求,才能真正做到日后設計系統方 案時回避需求。
?
關鍵點
??? 以 前的一個項目里,經常會遇到顧問在需求調研階段,問的問題與項目無關,而相關的問題又問得不夠深入。那么怎樣的需求調研才是項目所需的,這里有一個非常重 要的原則:需求調研是與未來ERP系統設計息息相關的,與下階段的業務藍圖設計相關。而未來的系統設計,與業務藍圖大部分是基于系統的標準功能。所以,顧 問要做到對系統的標準功能特別熟悉。簡言之,顧問是帶著"心中的系統功能"去需求調研的。
?? ? ? 也曾發現,在業務藍圖設計階段,顧問與用戶之間又在溝通本應在需求調研階段完成的工作內容,原因就是在于需求調研沒有針對性,沒有透徹性。出現了為需求調 研而調研的現象。這方面,顧問應該下功夫積累經驗,真正掌握系統標準功能,敏感用戶的特殊業務。通過需求調研,顧問應該在腦海里將客戶未來的業務藍圖,未 來的系統功能設計有八成以上的"心中有數"。