第一篇：SAP調研問卷

SAP調研問卷

SAP調研問卷一.SD模塊調研問卷: 此問卷的目的是了解客戶管理的現狀以及管理水平,發現其中的問題及需改進之處,了解企業對現時管理咨詢的需求,通過問卷的評估,對目前管理各方面作出描述,對客戶需求作出分析,從而為項目實施確定一個系統的完整的業務藍圖.(XX公司調研--彩電業)1.確定銷售機構：銷售公司，銷售部，全國銷售辦事處，銷售組，銷售員等2.銷售的產品類型（產品組）：彩電，空調，VCD等3.銷售方式（渠道）：直銷，分銷，代理等4.成品倉庫組織結構：成品倉庫管理部門，成品分庫及全國成品庫存點5.成品倉庫發運點基礎數據銷售的產品1.銷售產品的類型：成品，半成品，零配件，外購商品，技術服務等2.銷售產品的品種類別，各品種在各倉庫的庫存數量3.成品的管理是否需批次管理或管理到每一產品的序列號銷售的對象-客戶1.客戶的類型：代理商，分銷商，直接用戶，維修站等2.客戶的角色：售達方，運達方，開票方，付款方3.客戶的管理要求銷售價格管理1.公司是否實行產品價格管理2.產品的目錄價3.產品不同渠道的折扣管理4.產品不同客戶的折扣管理5.其他價格管理模式SD的打印輸出文本1.需要SAP打印的文本：銷售訂單，發運單，發票等標準銷售訂單處理1.銷售員如何與客戶簽定銷售合同或訂單2.本部的銷售部如何及時獲得辦事處銷售員的合同，進行處理3.銷售合同或訂單在本部的管理方式：銷售訂單的信息完整性-客戶，產品，數量，交貨期，售價，付款條件，運輸方式等4.發運單的制作及下發5.成品倉庫的庫存管理及根據發運單的發貨6.成品運輸管理7.客戶發票的開具8.客戶的付款方式：預付，現款現貨，分期付款等9.客戶應收帳的管理成品倉庫的管理1.成品倉庫的信息集成

2.成品庫之間的調貨（庫存轉移）

3.成品庫的收貨及發貨管理

4.成品庫的庫位管理

5.成品的庫存報表，信息系統其它業務流程1．銷售員管理/業績評估2．銷售詢價/報價3．銷售框架協議/長期銷售合同5.出口貿易6.產品免費贈送7.產品退貨管理8.外購商品的銷售流程9.客戶寄售管理10．客戶信用管理11．銷售與售后服務的銜接 銷售與分銷報表/信息系統 對售后服務面談的有關問題 功能組織結構

1．售后服務機構：本部/全國辦事處的售后服務機構，維修中心2．特約維修站的類別，數量，管理模式3．最終用戶的信息要求

售后服務的基本流程1.售后服務的流程描述及流程圖2.各功能單位的角色：售后服務管理機構，特約維修站，最終用戶，維修中心3.售后服務的結算4.產品備件的申請，發運，調配，管理，結算5.售后服務業績評估售后服務對象管理1.售后服務對象分析（Material, Equipment, BOM, Functioanl Location）?2.對象的管理要求：分類管理，產品序列號管理基礎數據管理1．物料主數據

2．服務對象主數據

3．服務客戶主數據

4．服務供應商主數據

5．物料分類系統

6．產品序列號管理售后服務保證書管理

1.保證書的形式，內容2.保證書的輸出格式客戶交互中心（CIC）1.未來客戶交互中心的結構/模式2.交互中心的電話處理：熱線電話解答（電話記錄，服務通知，服務完畢），上門/取回維修（電話記錄，服務通知，服務訂單，費用結算），替換備件發貨/結算等3.交互中心的電話服務監控：電話響應時間控制4.交互中心的電話處理與銷售及售后服務模塊的信息集成/共享5.交互中心前端技術：SAP與電話系統的接口

二.MM模塊調研問卷: 此問卷的目的是了解客戶管理的現狀以及管理水平,發現其中的問題及需改進之處,了解企業對現時管理咨詢的需求,通過問卷的評估,對目前管理各方面作出描述,對客戶需求作出分析,從而為項目實施確定一個系統的完整的業務藍圖.1.公司現有多少種物料？2.對物料是怎樣歸類管理的?例：原材料，半成品，成品，備品備件，包裝等。3.目前公司對物料的編碼原則及管理是怎樣要求的？4.有多少供應商提供行政管理（辦公用品）的物料?5.這些供應商的分布地點?6.對供應商有沒有用付款條件（例：到貨付款，15天內付款，30天內付款有1%的折扣等）? 如果有，包括哪些?7.對供應商的付款是否涉及多種貨幣?8.供應商的類型有哪些?

是集團內部的?

是國內的?

是國外的?

供應商中有沒有接受訂單方,供應商付款方,供應商運貨方等供應商合作伙伴?9.采購中是否實施對供應商的評估?

是否有物料的歷史價格?

是否對供應商的行為，價格，數量，運輸和服務等進行評估?10.通過什么方式和供應商簽訂訂單?(傳真，根據采購合同簽訂訂單等等.)

11.采購申請（采購計劃，部門請購單）由誰產生?12.采購申請是否要授權?授權的層次是什么?13.是否需要在系統中自動產生采購申請?14.是否需要在系統中進行報價處理?15.是否需要在系統中自動分析和比較供應商的報價?16.是否需要在系統中自動根據報價選擇供應商?

17.目前和供應商共有多少采購合同?18.由誰創建這些合同?19.這些合同被修改的頻率是多少?20.合同是金額的，數量的，還是有計劃行（有具體的交貨時間，數量等）的等等?21.合同中是否包括運費，運輸，關稅，報關和其他條件的條款?

22.目前采購合同是怎樣進行管理的?23.采購訂單是否是根據采購合同下達? 24.對采購訂單的下達批準是否是根據金額而定為不同的批準人? 25.采購定單是怎樣為資產，庫存，費用?是否有寄存采購（采購入庫的物料不算公司的資產，在物料消耗時才算公司的資產），外協采購和銷售驅動的采購（銷售部門在下達銷售訂單后，采購部門為此銷售物料進行采購）等等。26.在采購訂單上是否包含有運費及關稅？ 27.目前發票的校驗是在哪個部門（財務或采購）進行的?28.運費和關稅是怎樣計算的?29.發票中哪些數據是需要校驗的? 30.目前公司對物料成本核算是采用標準價還是移動平均價?如何使用管理的?31.哪些物料將被包括在庫存管理的系統中?(原材料，半成品，產成品，備品備件，辦公用品等等.)32.是否有零價值庫存物料的管理？ 33.物料管理是否要批次控制? 34.目前公司倉庫的管理是什么結構（如是否存在庫別區域的劃分管理）？

35.對物料的收貨是否全部直接進庫存管理?36.收貨后是否進行質量檢查，物料是否存在由采購部門或收貨部門提出要求質量檢查?37.收貨是否要有進入凍結庫存（即物料由于某些原因，不能進行接收，要將物料進行暫存管理，等待處理）?38.是否有收貨直接作為消耗，即為部門采購，收貨后不作為庫存管理?39.目前是否根據采購訂單收貨?40.是否沒有采購訂單的收貨，原因是什么?41.是否沒有含運費的收貨?

42.是否有對物料預留（事先有計劃的對所需處理的業務如：部門消耗領料進行物料的預分配）的管理?43.是否發貨給成本中心，即部門的非生產領用?44.是否為預留發貨?45.是否從寄存庫存發貨?46.是否為資產發貨，即將庫存物料出庫轉為固定資產?47.是否有退貨給供應商?48.是否有對供應商進行索賠業務的處理？怎樣處理？

49.物料是否從質檢狀態轉移到凍結庫存狀態?50.物料是否從凍結狀態移到合格庫存狀態?51.是否有可返回利用的包裝物?52.是否對外協廠家的庫存進行庫存的管理及盤點?53.對倉庫之間的庫存物料的調撥是否要進行在途庫存的管理?54.是否有對庫存物料編碼進行改變，即A物料變成B物料，為什么?55.目前公司執行盤點的策略是什么，即是普盤還是抽盤，是連續盤點還是周期盤點?56.在執行盤點時，由哪些部門參與，作業流程怎樣? 57.對須進行檢驗的物料是采取普檢還是抽檢？在檢驗中是否存在毀壞性檢驗，對抽檢的物料是否要進行庫存管理？ 三.PP模塊調研問卷:此問卷的目的是了解客戶管理的現狀以及管理水平,發現其中的問題及需改進之處,了解企業對現時管理咨詢的需求,通過問卷的評估,對目前管理各方面作出描述,對客戶需求作出分析,從而為項目實施確定一個系統的完整的業務藍圖.調研內容： 公司目前有實施哪些信息化項目,如ERP,MRP,SCM、PDM、OA等.2 公司目前PMC的組織結構,崗位設置和人員職責如何?3 對與PP來說,目前最主要的問題在哪里?部門內部還是與別部門的溝通?4.是什么樣的生產模式,按訂單,按庫存,還是都有,離散型,可重復生產還是其它?5 目前有幾間工廠,有外包業務嗎?對與外包業務現在是如何處理?6.公司現有人員多少,生產控制部門人員占的比例如何?人員流動大嗎?7.對于生產計劃部分有做月計劃,周計劃還是日生產計劃.8.如何去掌控生產進度,以什么報表體現或是有使用相應生產作業系統9.業務部門是如何把客戶需求給到生產控制部門,生產控制部門又是如何反饋信息給業務部門10.生產產品種類多嗎?生產周期如何,相對應的物料采購周期呢?11.公司BOM完不完整,目前BOM有幾層,是所有物料都有放BOM嗎?還是有些做單獨的安全庫存控制?BOM由誰在完成,以什么方式發放到相關部門?對于版本公司是如何控制的?12.是否所有物料都有給編號,如何定義物料編碼?有分類嗎?目前有分幾大類?13.是否所有工序都有作業指導書,所有產品都有Workflow?14.公司的領料流程是怎樣的?退料呢?對于報廢或損耗部分如何處理?對于替代料呢?是否所有的領料都有領料單?沒有領料單倉庫會發料到生產線嗎?如有,事后又是如何處理?15.公司的物流,倉庫管理狀況如何?如周期,庫存等.16.對于生產線的在制品(WIP),公司是如何控制的?生產線會常待料或堆料嗎?17.公司有IE(工業工程）部門嗎? 有無完整的工時評估體系,目前誰在做標準工時?18.公司目前是怎樣去評估產能,生產過程中瓶頸多嗎?主要是設備還是人力或是其他,那公司是如何去做能力的平衡?19 工程變更頻繁嗎? 變更是否要紀錄?有使用工程變更通知(ECN)嗎? 由誰發出?20.通過何種方式算物料需求,系統還是手工?是否所有的物料都有采購單,需求計劃準確嗎?會不會出現我要的沒有,不要的很多這種狀況?21.目前生產線會有幾種形態,批量生產,樣品,重工(redo)等.22.目前執行生產計劃最困難的是什么?生產計劃能匹配到實際生產嗎?是否會出現客戶

要的沒有,不要的生產了很多這種情況?造成生產不順暢的因素有哪些?23.生產線領料是以什么方式來完成?按訂單.安工序的順序還是所有的一次領完?24.對于客戶財產是如何管理?25.對于出貨公司是如何管理的?26.目前客戶交期率是多少?生產計劃部門是如何提升客戶的交期率的? 四.FI/CO模塊調研問卷: 此問卷的目的是了解客戶管理的現狀以及管理水平,發現其中的問題及需改進之處,了解企業對現時管理咨詢的需求,通過問卷的評估,對目前管理各方面作出描述,對客戶需求作出分析,從而為項目實施確定一個系統的完整的業務藍圖.1.公司目前的會計科目設置原則，應收應付科目下是否設置客戶供應商明細，費用科目是否分細至具體部門，經營費用和管理費用是否在科目中體現？

2.目前公司對科目的編碼原則是什么，是否按照科目分組(如：現金銀行存款類，流動資產，負債類，收入類，費用類)定義編碼規則？3.目前是否存在帳外科目管理？4.目前客戶類型有哪幾類?是否分為國內客戶(按省市細分)，國外客戶，集團類客戶，一次性客戶，客戶中是否存在 既為客戶又是供應商的情況，如存在，是否會進行應收應付的沖銷？5.對客戶數據如何進行控制管理，誰負責創建客戶數據，如何保證客戶數據的唯一性？目前客戶的編碼規則是如何定義的？大致有多少客戶？6.目前對集團內部往來客戶如何進行管理？7.對客戶是否使用付款條件（例：貨到付款，15天內付款有1%的折扣，30天后到期等）?

如果有，包括哪些?8.對客戶是否實行信貸控制？(例：應收帳款余額超過一定限度后停止發貨開發票等）?9.供應商類型有哪幾類?是否分為國內供應商(按省市細分)，國外供應商，集團類供應商，一次性供應商，供應商 中是否存在既為供應商又是客戶的情況，如存在，是否會進行應付應收的沖銷？10.對供應商數據如何進行控制管理，誰負責創建供應商數據，如何保證供應商數據的唯一性？供應商的編碼規則是如何定義的？大致有多少供應商？11.目前公司對集團內部供應商如何進行管理？12.對供應商是否存在付款條件（例：貨到付款，15天內付款，30天內付款有1%的折扣等）?

如果有，包括哪些?13.固定資產類型有哪幾類(如：房地產，機器設備，交通工具等等)，同一類型的固定資產是否使用相同的折舊方法，使用年限是否相同？14.固定資產的編碼規則是如何定義的？目前公司大致有多少固定資產？每月新置固定資產的數量有多少？15.誰負責固定資產主數據的創建，以什么為依據進行創建？(如：以采購部門的請購單為依據創建固定資產，或以收到的供應商發票進行創建）？對于某些高價值固定資產是單獨管 理還是按照組件分為多個資產進行管理？16.目前公司費用是否按部門或個人(例：銷售員或部門經理)進行歸集？部門或個人數據是反映在費用明細科目中還是單獨設置？17.對于某項具體活動是否進行單獨設置，進行相關費用收集？18.目前公司收入是如何進行統計分析的？(例：按照客戶，地區，產品或銷售公司)

19.憑證主要分哪幾類(例：收，付，轉)，日常業務中有幾種外幣?每月的憑證數量大致有多少？憑證的編號規則是如何定義的？是否每月憑證重新編號？20.憑證記帳是否采取審核流程(即：制單人輸入憑證，由復核人審核通過后再記帳)?如采取憑證審核流程，審核人是月末集中審核還是每天審核憑證，未審核的憑證數據如何進行查詢？21.錯誤憑證的沖銷或退貨憑證是否使用紅字沖銷？22.目前公司銀行對帳是手工勾對還是由系統處理？23.目前公司的會計年度如何劃分，一年有幾個會計期間，如何設置起始截止日期？ 24.月末是否進行外匯匯兌損益重估?25.月末是否進行資產負債表調整(例：對于應收貸方余額，應付借方余額或按照帳齡進行重組產生調整憑證，下期沖回)26.目前公司是否生成合并報表，公司間往來業務及內部虛增利潤的抵銷是手工處理還是由系統自動處理？27.目前銷售發票是由財務人員根據發貨單手工輸入還是由銷售單據集成自動生成？每月銷售發票的數量有多少？28.目前對于客戶的應收貨款和應收運費是否進行區分？29.對于客戶的收款是否對應發票進行按單收款，具體有哪些收款方式(現金，銀行存款，匯票)，如對應發票收款，是由客戶指定發票還是財務人員根據相關規則自行選擇？對應 一張發票是否存在多次收款的情況，是否需要記錄收款的歷史記錄？對客戶是否有預收帳 款，預收帳款和正常收款是否區分不同科目？客戶的付款是集中在月末還是按照付款條款到期即付？30.是否根據銷售單及發票的付款條款進行相應的現金預測管理？31.月末是否對客戶進行催款處理，是否按照不同的帳齡和應收帳款金額進行催款？32.目前應付帳款采購發票是由財務人員根據供應商發票手工輸入還是由采購單據集成自動

產生? 33.如何對供應商進行付款？(例：按照付款條款進行付款，或結合制定付款計劃進行處理)，進行付款時是否針對發票進行按單付款，是否存在對一張發票多次付款？對供應商是否存 在預付帳款，預付帳款和正常付款是否區分不同科目？34.目前采購發票中的進項稅款項是否要付款之后才可進行抵扣?35.是否根據采購定單及發票進行相應的現金預測管理？36.目前公司對于員工是如何進行管理的？是采取內部客戶，內部供應商或設置總帳明細科目進行統計？37.目前固定資產購置時是否進行金額檢查(例：價值2,000元以上)？如何區分固定資產購置和原材物料購置？財務人員是根據采購申請創建固定資產還是依據供應商發票創建？38.目前固定資產主要有幾種折舊方法? 對于同一固定資產是否采用多種折舊方法或不同的使用年限統計折舊數據？每月折舊數據如何記帳？39.是否存在不提折舊的帳外資產需要進行管理?40.對于低值易耗品，在建工程是否納入固定資產進行管理？41.是否有固定資產的拆分和重組情況？(例：一個資產分為幾個資產進行管理，折舊方法或使用年限是否改變)42.是否存在資產停用情況(例：機器大修期間停提折舊，恢復使用后開始計提折舊，使用年限可以順延)？43.目前公司對于資產維修升級的投入是如何處理的？是直接增加資產原值還是重估后創建一個新的資產或視投入的規模直接記入費用處理？44.對于資產的報廢是否需要分析每一項資產的報廢情況，進行固定資產清理的結轉？45.目前公司的產品成本是如何進行控制核算的？成本結轉是月末手工結轉還是由系統處理？是月末一次性結轉還是根據每筆業務單獨結轉？46.目前公司如何進行費用的統計控制？是否具體細化到部門或個人？47.對于某項具體活動是否進行單獨費用歸集統計，同時進行費用預算控制？48.目前公司對費用收入如何進行計劃控制？以什么為依據設定計劃數據？(例：以上年各部門的實際費用為參考或根據某些活動所簽定的合同為依據，等等)49.目前公司如何進行費用收入的統計分析？對于利潤分析是否按照產品，地區，客戶或銷售公司進行分類歸集？

第二篇：SAP項目如何做調研

清理電腦,十數年來,無數資料,近來每天抽空好好整理整理, 做IT的特別是整ERP的,四個字形容:命苦可憐.發現本給IT項目經理的好書.內容簡介

這個世界上寫給項目經理的書很多，寫給IT項目經理的書也不少，但寫給從事管理軟件實施的項目管理書籍并不多。

而筆者在從事項目經理工作中感到一個很苦惱的問題是，很多書其實非常經典，但都有一個缺點：理論正確，實戰指導作用不足。

不是親身親歷的人是很難領悟到那些理論的精髓，而每個剛剛入行又立志成為一個IT實施的新人往往不是一開始就能從理論上武裝自己，在他們起步的時候，每天要面臨著各種具體工作任務，例如做調研，寫計劃，寫方案，寫備忘錄，做項目匯報，做演示，這些活動與其說是項目管理發揮作用大，不如說這是具體業務技能的領域。

一個IT人如果沒有經受專業的培訓，在不能掌握這些技能之前，我個人體會是往往是努力的把事情做砸。

目前的IT服務質量更大程度上取決于實施人員個人能力，也許只有有一大批同等質量服務的實施人員涌現，一個公司的才有可能順利推進項目管理的思路。

因此筆者就有一個想法，想把自己在項目實施從售前到售后的體會和經驗總結為一些專項技能，并希望它具有可操作性，和大家一起交流總結，不斷積累并臻于完善。

也希望各位朋友看后多評論，多留言，多給筆者提出改進意見，本人將結合大家意見不斷完善，將大家的想法變成業內智慧的結晶，讓更多的人能在IT實施工作中做到游刃有余

目 錄

前言2 如何做業務調研？ 2.1 調研工作如何組織？

2.2 調研準備階段容易犯哪些錯誤？2.3 調研準備階段容易犯哪些錯誤？)2.4 調研準備階段容易犯哪些錯誤？2.5 現場調研階段容易犯哪些錯誤？2.6 現場調研階段容易犯哪些錯誤？ 2.7 現場調研階段容易犯哪些錯誤？2.8 現場調研階段容易犯哪些錯誤？)2.9 現場調研階段容易犯哪些錯誤？2.10 現場調研階段容易犯哪些錯誤？2.11 調研工作方法推薦2.12 接口調研背景知識(上)2.13 接口調研背景知識(下)2.14 調研后續工作落實階段3 如何寫解決方案？

3.1 解決方案難寫在哪里？(連載十五)3.2 壞的解決方案有哪些特征？(上)(連載十六)3.3 壞的解決方案有哪些特征？(中)(連載十七)3.4 壞的解決方案有哪些特征？(下)(連載十八)3.5 寫好方案心得(上)(連載十九)3.6 寫好方案心得(下)(連載二十)3.7 方案分類及用途(連載二十一)4 如何做產品演示？

4.1 什么是演示？(連載二十二)4.2 演示的目的

4.3 售前演示為什么效果不好？(上)(連載二十三)4.4 售前演示為什么效果不好？(下)(連載二十四)4.5 售前演示工作應如何組織？(上)(連載二十五)4.6 售前演示工作應如何組織？(下)(連載二十六)4.7 如何準備標準演示套路？(上)(連載二十七)4.8 如何準備標準演示套路？(下)(連載二十八)4.9 如何進行現場演示(一)(連載二十九)4.10 如何進行現場演示(二)(連載三十)4.11 如何進行現場演示(三)(連載三十一)4.12 如何進行現場演示(四)(連載三十二)4.13 如何進行現場演示(五)(連載三十三)4.14 如何組織演示后工作(連載三十四)4.15 演示方案準備經常考慮的問題(連載三十五)5 如何做用戶考察？ 5.1 前言(連載三十六)5.2 典型用戶有什么意義？

5.3 典型用戶應如何管理(上)(連載三十七)5.4 典型用戶應如何管理(下)(連載三十八)5.5 用戶現場考察應如何組織？(上)(連載三十九)5.6 用戶現場考察應如何組織？(中)(連載四十)5.7 用戶現場考察應如何組織？(下)(連載四十一)6 如何做公司介紹？ 6.1 前言(連載四十二)6.2 哪些情況下需要公司介紹 6.3 正式陳述時常見錯誤？

6.4 口頭和會面介紹時常見技巧(連載四十三)6.5 在客戶處進行公司介紹三個要點

6.6 如何對在公司考察客戶做介紹(連載四十四)6.7 做好總部公司介紹的三個決竅

6.8 公司總部接待考察客戶要注意的細節

7.1 培訓工作在項目實施中作用(上)(連載四十五)7.2 培訓工作在項目實施中作用(中)(連載四十六)7.3 培訓工作在項目實施中作用(下)(連載四十七)7.4 培訓工作應如何組織？(連載四十八)7.5 培訓注意事項(連載四十九)7.6 總部培訓 如何做現場推廣? 8.1 現場推廣工作可進行條件？(連載五十)8.2 現場推廣工作為什么進展慢？

8.2.2 要推廣的業務流不完整(連載五十一)8.2.4 沒有激發用戶的主動性(連載五十二)8.2.6 邊界總在變更(連載五十三)8.3 現場推廣工作如何才能做好？(連載五十四)9 如何做項目驗收? 9.1 驗收工作應如何組織？(連載五十五)9.1.3 主動溝通(連載五十六)9.1.4 寫好備忘錄(連載五十七)9.2 如何催款？ 如何做項目團隊管理 10.1 前言(連載五十八)10.2 好的項目團隊構建要求

10.3 好團隊的兩個特征(連載五十九)10.4 如何看待項目經理在團隊中作用 10.5 團隊建設心得和誤區(連載六十)1 前言

在IT行業，特別是管理軟件實施行業能夠成為一個成功的項目經理是非常困難的一件事情，一個成功的IT經理，被要求熟悉計算機軟硬件知識，精通企業業務背景，擁有良好的溝通技巧和說服能力，當然在項目團隊中還必須具有威信和執行力，這樣的人才簡直是完人。

一般人即使努力也不可能達到這樣的一個完美的項目經理的境界，如果相信自己努力就可以做到可能是受哪些成功書籍的毒害太深。

更多的項目經理是擁有崗位并非擁有崗位技能，但可笑的是，往往是一個人剛剛被發現具備這樣的潛質就會沒有多少機會實施項目，而是陷入另一種疲于奔命的狀態。

因為一個具有豐富實戰經驗的人對企業最有價值的場合不是深入實施某個具體的項目，而是進入售前。

管理軟件銷售是最合適顧問式銷售技術，但很難想象一個沒有實際實施項目經驗的顧問可以有效把握企業需求和打動對軟件供應商本質上都保持狐疑的潛在客戶，這些都只有通過經驗豐富的項目經理才可以做到。

如果一家軟件公司的問題還是生存的問題，這樣優秀的實施顧問最合理的選擇就是售前咨詢顧問。很多用戶往往在合作后感覺到售前和售后交流時存在巨大落差，就是因為售前你看到的是已經證明過自己的顧問，售后你看到的就是還需要證明自己的顧問。

筆者自己也是走過了這么一條路，所以現在想一想，做項目經理難，做管理軟件的項目經理尤其難，五年下來，忙得不亦樂乎。常常笑言自己是職業“三陪”，陪客戶交流，陪客戶考察，陪客戶吃飯。

不過和大量客戶交流也的確從另一個角度豐富了本人的閱歷，也對整個管理信息化事業的建設從另一個角度(售前)增加了新的認識，在本文本人將自己售前售后一些工作心得分為九種技能(業務調研，解決方案，產品演示，用戶考察，公司介紹，用戶培訓，現場推廣，項目驗收，團隊管理)，分別整理成文，希望能給在這個行業內拼搏的同道一些啟發。如何做業務調研？

2.1 調研工作如何組織？

很多人認為調研工作極難，水平最高的人才能做好一次調研，軟件工程中也強調需求獲取是最難的事情。有的人要么認為不過如此，甚至是一個普通技術支持都可以做的工作。

現在有很多企業上管理軟件之前都希望軟件公司派人來了解情況，提出針對性建議。這其實給很多軟件公司銷售經理出了個難題，自己親自上企業不信任，而且也不專業，請公司派咨詢顧問過來資源難以協調，響應不及時用戶也不滿意，而且貽誤商機，隨便來一個技術支持又不能保證調研質量，在后續工作中也難以讓用戶信服。

其實難和不難，在于是否用正確的方法做事，經常用正確的方法做事人，眼里是沒有難事的。

雖然說調研工作質量和調研個人能力是直接相關的，有豐富經驗的人在很短時間內就可以完成高質量的調研，取得被調研用戶的認可，沒經驗的人花費大量時間在現場了解情況可能還是給用戶一個不懂行的印象。

但最有經驗的人也不可能了解所有的行業，他們對于一些陌生的行業一樣可以將調研工作完成得很好，我發現有經驗的調研人員和沒有經驗調研人員最大的區別是他們是否按照正確的過程組織調研工作，按照正確的方式做事自然會更容易取得成功，有無其它行業經驗只是成功調研的一個積極因素而已。

在一個有調研經驗的業務人員眼里，調研決不是現場調研這么簡單，無論是售前還是售后調研工作本身都可以分為三個階段。

第一個階段叫調研準備階段，這個階段要完成調研計劃的確認，調研背景資料的準備兩方面的工作。這個階段工作質量將對能否順利開展調研工作起到關鍵保障作用。

第二個階段就是現場調研階段，根據調研計劃完成各項調研工作，并取得用戶認同。

第三個階段就是調研后續工作落實階段，調研結束后往往要準備產品演示，技術交流，解決方案等工作，所以調研結束后一定要趁熱打鐵，把后續工作落實到一定程度才能再做其它工作，此時調研工作才能算結束。

這是很多人忽視的一點，以為調研成功事情就結束了，其實調研工作和后續工作往往不是同一個人準備，高質量調研信息如果不能及時有效完整傳遞到后續工作者頭腦中，調研工作實際上是更大的機會成本喪失。

從商務的角度來講，售前調研還存在一個時機問題，調研本身應該是商務策劃中的一個環節。

很多商務人員和用戶接觸以后，技術講不清楚，業務談不清楚，只好給一個模板化的方案給用戶，結果這種方案又沒有說服力，大家的方案高度雷同，用戶無法鑒別，往往提出一個請求：是否請安排貴公司業務人員做一個調研，然后再提供一個針對性方案？

有經驗的銷售人員還應該明白，調研是一個適當實際要去做的工作，不應該被用戶牽著走，應該是整個商務策劃中的一部分，不過這不是本文闡述重點，本文將重點介紹業務調研需要的技能。2.2 調研準備階段容易犯哪些錯誤？

一般接到一個調研工作任務后，大家都會去編制一個調研工作現場工作計劃，同時進行一些調研準備工作。

根據我的觀察，在調研準備階段大家常常存在這么幾個錯誤。

2.2.1 第一個容易犯的錯誤：不清楚調研的的目的

很多人編制計劃，寫本次現場工作目的時往往是這樣寫的：“完成項目現場調研工作”。

其實完成現場調研工作不是計劃本次活動的目的，而恰恰是完成本次調研目的的有效手段。

那么調研的目的到底是什么呢？

真正的調研目的有三條：

對用戶：讓用戶認為調研者已經非常了解或者有足夠能力了解企業現有業務流程。

對競爭對手：如果是售前調研，還要隨時制造給競爭對手的門檻，了解競爭對手給我們設計的門檻。

對公司：調研獲得信息足夠讓后續者進入下一階段工作。

我們很多人認為調研時一定要搞清楚企業業務，可是一定要切記，能夠評價你是否了解企業業務的人不是你公司的成員，而是用戶。

如果用戶都認為調研者非常或者有能力了解他們的業務，他們自然也比較相信這個調研者的后續的解決方案或產品演示。

如果用戶都認為調研者非常或者有能力了解他們的業務，調研者說服或者高質量幫助公司的同事進行后續工作自然不在話下。

明白這個目的的人，在調研階段就會設計大量的機會不斷強化用戶對調研者的認同感。如果最終用戶認同了調研者，或者大量的用戶認同了調研者，無論是對售前打單還是售后實施就開始取得了最廣泛的支持，項目成功的機會就在不斷的增加。

有的企業業務非常復雜，企業用戶自己都可能搞不太清楚，不太可能在短期內了解全部業務細節，特別是售前調研階段，用戶不太可能有積極性花費大量時間配合進行調研工作，這個時候調研工作目的就是要能讓用戶充分信服調研者所在公司或團隊是有能力了解企業業務。有了這個信任基礎，后面很多工作也容易推進。

有的項目用戶同時安排幾家供應商在同一時間段，或者在很緊湊的一個時間段安排幾家供應商都用兩三天的時間做一個調研，此時所有供應商恐怕都很難立即對項目情況有一個完備的了解，這個時候與其說調研目的是搞完全清楚企業業務流程，不如說是讓用戶認為我們在這個領域最有經驗，最有可能搞清楚企業業務流程，進而給競爭對手制造進入門檻。

所以在調研工作中要通過規范的業務程序讓用戶感覺到我們作為一家大公司的風范，通過業務交流讓用戶認可我們在這個領域的專業知識和技能，通過業務需求確認突出我們強項，給競爭對手制造壓力，同時了解競爭對手給我們制造了哪些門檻，靈活化解，或者為后續技術交流工作提供可利用的信息。

我們調研工作質量越高，認同程度越高，對手壓力就越大。一般對手在壓力下出錯的機會就越多，我們了解充分準備也容易充分，這樣我們項目成功的概率就越大。

調研一旦結束，調研者還要清楚一個環節，調研后要做什么？是做解決方案還是做技術交流，還是做產品演示，還是做實施方案？

不管進行什么工作，特別是在后續工作是公司其它同事配合完成的情況下，調研者有責任有義務確認自己調研工作信息明確被需要獲知這些信息的同事收到并理解，并能很好開展后續工作。

做到這一點，調研工作才能算結束，否則調研者個人認為其調研工作質量很高，后續者如果對調研情況不認同或者對調研業務報告不理解，后續工作質量還是沒有保障，這個時候調研工作并沒有發揮作用，所以調研者就是從尊重自己工作的角度而言，也要安排時間讓后續人員認同和理解自己的業務調研內容。

實際上有效的團隊在調研過程中會隨時收集團隊成員對調研記錄的意見，不斷動態調整調研過程，而不是在最后調研結束時一骨腦讓團隊成員吸收大量信息。同樣有經驗的人員在規劃一個項目時也一定會考慮調研工作和后續工作的協同，提前要求各個階段人員及時溝通和配合。

2.2.2 第二個容易犯的錯誤：計劃不夠細致

很多人調研計劃落實具體活動的時候，往往只有這么簡要的幾句，某年某月某日，在某地某部門進行業務調研。

這樣寫計劃要么是不清楚調研從哪里下手，只好先這樣寫著，到現場再走一步看一步，要么就是自以為有一些調研經驗，知道如何處理，所以在寫計劃時為了糊弄內部分管領導，好歹也寫了，質量上偷工減料。

實際上我們寫一個計劃寫給誰看？計劃是我們給用戶分管領導確認的，用戶領導對你的工作內容了解越清楚，他幫助你安排工作就越方便。

用戶領導或者有時候是用戶協調人也一定希望我們在現場的工作緊湊合理，不浪費彼此的時間。但用戶并不清楚如何做這種調研，他們能做的就是按照我們意見盡量安排合適人員配合。

如果你的調研是某幾天要來你們這里調研的話語，實際上用戶領導可能會回答，拿你們先來，來了再說。結果現場大部分時間都在協調調研資源和等待上，大量時間都無價值的浪費掉。

所以一份好的計劃應該是可操作，可執行的，也可以讓用戶看明白的。

我個人建議計劃不妨細化到每天的上午下午分別調研哪個部門，需要怎樣資歷人員配合，需要配合多長時間，將了解哪些方面的業務問題，需要準備哪些相關資料。這樣也便于用戶領導配合安排。

而且一份詳細的計劃做為開始，正是恰到好處的體現了我們的專業背景和職業素養。還有什么比這更劃算的呢？我們只需要做一份合理的模板，每次多寫幾個字，就可以換來一個好的印象。

還有一點必須要明確的是，寫一份詳細的計劃并非一定要讓計劃時間變得很長。任何調研工作都不可能把所有情況搞清楚，調研并不是一次就可以結束的事情。

實際上在一個項目中要隨時有調研的意識，一旦發現新的事實和歷史調研不符合，我們馬上可以重新完善我們的調研結論，進行相關調整。

所以知道這一點我們每次調研都有一個成本的概念，調研的目的對內只是獲得可以進入下一階段工作的足夠質量信息即可。

有時候一兩天的調研也可以達到這個目的，調研同樣可以結束。

即使是一天的調研計劃同樣可以認真細致地準備。2.3 調研準備階段容易犯哪些錯誤？

2.3.1 第三個容易犯的錯誤：計劃沒有在內部溝通

很多人接到調研任務，將計劃寫好，立即就開始和用戶溝通，工作精神很好，是不折不扣的行動派。

但是前面已經強調過，調研工作不是一個單獨的業務行為，調研是承上啟下的一個工作。所以我們的調研計劃一定要征求客戶經理，參與過調研其它人員意見，一些重點項目甚至是公司高管的意見，看看是否還值得推敲。

最關鍵的是，內部溝通計劃的過程是和其它部門約定后續工作配合的過程，通過內部溝通在完善調研合理性基礎上實際上確定如果調研工作結束，如何將我的工作移交給其它人，便于其安排后續工作。

調研者不要匆匆忙忙搞完一個調研，提交一份文檔，就投入另外一個項目。然后客戶經理過了一段時間又要求演示，然后演示準備者看著業務調研報告云里霧里的時候，又無法和調研者當面深入溝通一下業務，無法高質量開展工作。

所以做內部溝通的時候實際上也是調研者的一個自我保護，和別人約定階段工作的輸入輸出文檔和質量要求，那么做完這份工作，后續同事也就能夠獨立開展工作，而是是糾纏不清。

例如有的項目在調研階段就要同步準備演示方案，那么調研者最好在調研階段就清楚誰負責這個演示配置，并在調研期間約定和其有效溝通方式，便于在調研進行時可以考慮如何準備。

如果很明確要進行這類工作，但又沒有安排演示準備人員。調研者作為一個職業人員，我們至少要盡到提醒客戶經理去申請資源提前準備的責任。

幫助自己團隊成員少犯低級錯誤也是一個成熟職業經理人的心態，不管你的工作崗位有多么重要或者不重要。

此外在內部溝通時，如果是售前項目，要考慮和客戶經理溝通一個很重要的問題：調研的切入時機。

一般情況下不要輕易的做第一個調研者，做第一個調研者一定要安排能力強的人，在用戶關系不錯的情況下，經過調研做好工作，給后續對手制造壓力。

因為用戶如果發現后續者能力不強或者不夠職業會加強對第一個調研者的認同感。

但是如果你派的人能力不足，那就給對手超越的機會此時再次安排調研，已經很難挽回第一印象分。

不做第一個調研者除了規避這方面的風險之外，還有一個比較大的好處：不做栽樹人，要做栽果子的人。

很多用戶往往并不清楚他們要購買的軟件到底是什么東西，所以第一批調研者很多精力要花費在灌輸概念的工作上，如果基本概念不清楚，用戶往往不能提出有價值的需求，調研時往往沒有邊際。

第二個調研者再進行調研時用戶就會清楚很多事情，回答問題質量就比較高，同時我們也可以有機會了解對手的牌，進行針對性準備，后發制人。

當然何時切入調研應該更多程度上是客戶經理考慮的工作，我們調研者至少要知道客戶經理對這個問題是如何考慮的。此外調研一般要客戶經理到現場配合，所以調研計劃行程安排也一定要得到客戶經理確認，防止出現意外變化。

不過說實話在這個行業內，基本上客戶經理是很幼稚的，調研工作往往是盲目啟動，草草收尾。

2.3.2 第四個容易犯的錯誤：計劃沒有得到用戶確認

我們有的人把調研計劃做好，告訴用戶形成，就準備按計劃去現場了，這樣的調研者不及格。

有的人會提前發郵件或傳真給用戶，然后電話確認收到，然后確認時間無問題，然后再去，這樣的調研者60分。

有的人不但會確認計劃時間，還會認真了解計劃內容是否認同和有相關業務人員配合，得到肯定承諾后再去，這樣的人80分。

有的人還會準備一些前期調研文卷和資料準備清單，讓客戶經理配合落實后再去調研，這樣的人100分。

我們至少要做到80分！

計劃發給用戶后用戶一般是不會認真看和落實的，這是中國人做事的習慣，特別是一些地位不高的聯系人，可能連為這個事找領導這個協調的膽都沒有。

所以打電話確認的時候一定要請用戶確認是否可以按計劃進行，得到肯定答復后再出發，這樣第一計劃執行保障性會高一些，第二也給別人留下一個認真的印象。

這個計劃落實的工作也可以和客戶經理溝通后，請其利用其在企業的人脈落實。

最近我有一個同事就犯了一個這樣的錯誤，代理在合同簽訂后非常著急催促我們去現場落實調研工作，這位同事就立即制定計劃，并發送給代理，同時電話確認收到計劃，然后就立即按計劃動身。

結果到了現場，代理說用戶還沒有準備好，你怎么就來了？我們的同事也很郁悶，計劃上說如果有問題就打電話，沒有問題就不用打電話，既然沒有打電話反對當然是按計劃執行。結果雙方的開始很不愉快，這就是不了解中國人的辦事特點造成的，中國人是預期性的事情一定要口頭溝通確認，擔責任的事情一定要書面溝通確認。

2.4 調研準備階段容易犯哪些錯誤？

2.4.1 第五個容易犯的錯誤：沒有認真進行準備

調研要認真準備，但說來容易做來難，很多人調研前的準備工作其實都是很隨意的。

沒有經過認真準備的調研，到了現場很可能對各種突發情況措手不及。

從應付各種用戶刁專古怪的問題的角度而言，調研準備永無止境。

好的調研準備工作可以包括這么18個方面：

1、如果有的話，一定要認真閱讀商務合同和技術協議。

2、閱讀前期技術方案和各類備忘錄。

此點非常重要，不僅僅要閱讀，還要保證自己工作質量和規范和前期保持一致，一個行為高度一致性的公司是核心競爭力很強的公司。

此處有一個很重要的工作一定要向前期參加工作人員了解是否已經收集了一些資料，并想辦法獲得，已經搜集的資料和問題盡量避免重復詢問，這對用戶會造成巨大不滿。如果萬一前期資料不能獲得，也要另外提前準備好說法避免這種情況出現。

3、和項目前期人員(咨詢顧問、客戶經理和平臺主管)充分溝通。

聽取他們的建議，使自己調研更有針對性。

4、熟悉公司已實施的相近項目的情況。

他們企業業務調研報告和解決方案將對我們現在工作很有幫助，甚至在調研過程中給我們很多思路上的啟發。

5、熟悉相關軟件產品的功能及發展方向。

很多人在工作中不注意和規劃人員的溝通，其實在調研前確認自己了解產品的發展方向，現有和近期可實現的功能對調研時遇到一些很難回避的技術問題就可以做到心中有數，提前想好說法。當然最好的說法是這個功能我們已經實現了，在某某項目上也是這樣要求的。

6、了解企業所處行業的行業特點、競爭態勢、產品研發特點。

這些要從公司，特別是網上查詢資料分析，建立一個基本的業務原型，這樣在調研時可以讓用戶感覺到我們還是做了很多工作，對項目很認真。

7、準備同用戶交流時的軟件原型或交流PPT。

有的時候用戶在調研過程中提出要我們做一個培訓和軟件演示的要求，一般情況下我們應該避免在售前調研階段做這個工作，因為這些要經過精心調研仔細準備后再進行質量更高。

但在售后實施調研時我們可能要先主動做這個軟件演示和理念培訓工作，收斂用戶的思路，引導項目邊界，所以調研者也應提前對這些方面工作做一準備。即使是售前也很難完全避免這個情況，不但要準備，而且在語氣上還要有所區分。

8、準備企業業務調研問卷。不一定要給用戶，但一定可以讓自己不遺漏該問的問題。

9、設計業務調研方案。業務調研方案可以將自己調研經驗不斷積累，形成體系化的經驗，大家現在看到的文字就是我不斷完善業務調研方案的結果。

10、設計業務調研計劃。計劃一定要用心，用心才能做好。

11、準備業務調研培訓材料。

到現場調研時需要讓用戶知道我們的調研方法和思路，用戶才好配合，也認可我們的專業化程度，這個應該結合公司流程和自己體會進行準備。

12、軟件安裝盤和加密狗。有備無患。

13、電腦筆記本。IT農民的必備勞作工具，如果沒有就用筆記本解決問題，沒有電腦前麥肯錫一直是手記錄問題，現在他們還是提倡手記錄，因為方便。

14、WINDOWS2000/SQL SERVER/ORACLE安裝盤等常用工具軟件安裝盤。有時候很有用。

15、別的項目常用樣例及標準配置，用戶很難提供明確需求的時候，讓他們看看我們在別的企業成功樣例，有助打開思路，也體現我們給用戶帶去先進管理方式和成功經驗的合作初衷。

16、公司各種流程管理文檔。對于一些用戶了解我們公司內部問題的時候，如果搞不清楚該什么講的時候不要信口開河，翻翻資料再說。

17、可能涉及業務難點培訓資料和問題集。

用戶的問題千奇百怪，多準備一點沒錯，不斷積累這些問題就是一個個人知識完善的過程。

18、公司小禮品。

調研完成后送給調研對象一個小禮品是很容易給對方留下好印象的機會。如果有政策，一定不要浪費。

實際上我們每個做過調研的人捫心自問，調研準備18條我們到底做了幾條？

也許認真不認真就是我們一個工作到底有沒有質量的根本原因。2.5 現場調研階段容易犯哪些錯誤？

調研計劃確認，抵達現場就需要進行調研工作。在調研工作階段我們常常容易犯以下錯誤。

2.5.1 常見錯誤一：立即進入調研狀態

很多人非常努力，一到現場，就開始按計劃進行調研工作。

其實調研計劃到現場第一件事情不是啟動調研，而是再次確認調研計劃。

這樣做的理由有三點：

第一雖然很多企業和你電話口頭認同了計劃，但只有調研者到現場了才會真的重視，所以我們必須要重新確認計劃，保證我們的計劃需要的調研配合資源已經落實；

第二確認調研計劃往往不是和協調人確認，要主動通過這個機會見一見企業負責的高管，很多時候企業也會安排這個一次見面。和高管見面要做好三件非常重要的事情：

一、匯報我們的計劃，請其再次確認，并請其協調資源安排人員配合。

記住給領導溝通最有效方式之一就是“多請示，多匯報”。根據我個人的經驗，一般領導看過的東西不如口頭匯報的東西印象深刻，匯報也是建立領導對我們認同的手段。

很多時候被調研人員不愿意配合我們進行調研，因為這樣可能會影響他們正常工作或者有其它顧慮，所以當調研工作是領導的工作任務安排，他們配合積極性就高了。

很多時候領導也不能立即協調完所有的工作，特別是這個時候可以要求領導配置一個專門的聯絡人，由他出進行聯絡工作，可能的話，也要求其全程參與調研，這樣的人會給調研帶來極大方便。

二、匯報我們的調研工作方法，讓高管覺得我們做事很有套路，同時請其提出意見，做相應客戶化調整。

在匯報計劃的同時要順便告訴高管我們調研工作方法，先做什么，后做什么，每天需要如何開始，要花費多少時間調研，花費多少時間在整理，是否要開一次業務分析會，需要哪些人參加。

領導明白你思路了，也就知道我們這些天工作量都會很飽滿，很有組織性，也就對調研工作有信心并積極支持。

此外領導可能提出一些要求，例如進行培訓或者其它要求，我們可以根據實際情況確定是否要進行或者不進行。此時就有可能需要調整計劃內容和時間。

三、借匯報機會領導了解他們上項目的初衷。

很多時候領導看待一個項目角度和高度和我們進行下層調研人員理解是不同的，這個時候和領導交流其對項目的想法，是有助于我們在調研工作進行時判斷一些業務需求是否真的符合企業領導的構思，并可以尋求更好的方案。

從調研的角度，了解不同人員對同一個項目的需求也是調研工作的一個內容。領導層往往是管理性思維，業務層往往是技術性思維，兩種思維達成一致才能設計一個好的方案。這些都需要通過調研獲得。

第三和高管見面要約定如何匯報工作的機制。

調研如果有一段時期，不可能天天找領導匯報，也不能不匯報，那么這個時候就可以請示領導每幾天安排一次當面匯報還是書面匯報。

多和領導見面，多用肯定語氣溝通，就會讓領導不斷強化對我們積極的印象，逐步將感情的天平傾斜到對我們有利的方面。

不過有一點，首次和高管匯報工作原則一定要言簡意賅，不要表現自己。

讓領導建立對自己個人專業認同感就可以說達到目的了，對于一個領導認為有專業技巧的人，見面的機會他是一定會繼續提供的，所以不要追求一次搞定，這都是極為有害的冒進思想。

低調切入，等調研過程中收集足夠事實了再根據情況確定是否逐步抬高調門，表現自己的思路，是更穩妥和合理的策略。

和高管見面可能存在一個時間不確定因素。所以在調研準備階段計劃確認時盡量先保證這個時間，如果到現場時間不能保證，必須留機動調整的可能，一般情況下可以進行企業歷史，企業現狀，網絡硬件，組織機構等方面的業務調研，也可以為領導見面提供溝通的素材。

此外高管并非一定是企業的最高領導，高管是依據企業規模和項目規模動態確定的，一般選擇匯報高管對象的原則是對項目直接負責的人上級或以上級別的人。

企業大了，高管并非只有一位，有的匯報必要時該重復就重復，不要給別人不尊重的感覺。

2.5.2 常見錯誤二：匆忙地進入調研狀態

計劃一旦得到領導確認很多人就立即著手調研，這個時候容易犯的錯誤就是匆忙地進入調研狀態。

進行具體調研業務前首先是和企業調研協調人確定今天一天的調研計劃和資源可以到位，如果萬一今天計劃所在配合資源不在，給企業調研協調人幾個替代性調整方案，其負責落實到位后才能放心的開展調研。這就避免出現上午調研完了發現下午沒有人配合了的情況。

這個提前預約時間，即尊重被調研用戶又讓被調研用戶有所準備，保證質量。

那么安排用戶配合調研工作在可能情況下一定還要得到其直接主管領導的確認，讓訪談者上司出面安排會面會保證調研者的積極性，他就不必擔心調研影響正常工作而導致直接領導不滿。

這些工作完成后還不以開始調研，而是針對所訪談的對象，再一次回顧自己要問的問題，理清發問的思路，不要想到什么說問什么。

想清楚后就可以開始調研了，但和被調研對象見面不要三句話不到就立即進入主題，必須有一點點鋪陳才能展開調研。

這個鋪陳包括三個方面，第一是自我介紹，有時候還包括公司介紹，調研者也是公司的活名片，第二是了解被調研者的背景，對其配合調研表示感謝，順便奉承一下，例如說能得到您這樣有經驗人員配合是我們非常高興的事情，讓其有一個好心情開始配合調研工作，第三是對調研總體內容和時間有一個說明，說明我們想通過調研能為其業務設計好的信息化支持手段，讓其配合時做到心中有數，樂于協助。

做完這些工作才不是匆忙展開調研工作。2.6 現場調研階段容易犯哪些錯誤？(二)2.6.1 常見錯誤三：不斷地問問題，唱獨角戲

很多人在開始進行調研的時候準備了一份業務調研問卷，所以在調研的時候就按照調研問卷開始提問，這個方法對剛開始做調研的人是很有用的，可以幫助他在對業務不熟悉的時候不至于無話可問。

但這樣調研的后果就是調研者在唱獨角戲。調研者不停的提出問題，被調研者不斷的再回答，好象成了一種審問和被審問的關系，這樣的調研狀態雖然可以收集大量信息，但從調研角度而言，不是最佳的選擇。

真正有經驗的調研者首先是先向用戶了解整個業務過程，在具體業務過程中順便了解我們想重點關心的問題。

被調研的用戶如果沒有經過精心準備是無法回答很多具體的問題的，他也不知道你為什么要問這些問題，這樣的問題問多了，用戶一定很厭煩，也會產生一些戒備心理。

但是所有用戶一定很熟悉自己每天進行的業務，并知道業務中他感覺比較痛苦的一些問題。所以調研的方式應該是站在用戶的角度了解業務，有了一個對業務的總體認識，再了解細節也就更深入和細致。

所以好的調研者要充分的讓用戶講話，自己只是在提話題，讓用戶有興趣有心情把自己知道的事情完整有序地講明白。

舉一個例子，我們做PDM調研的很多關心你用什么設計軟件，產生哪些格式，每月設計幾個項目，產生多少圖紙，但如果是一個個問題這樣問下去，對用戶而言的確是一種折磨。還不如問他你每天設計任務是如何獲得的，如何開始，需要哪些資料參考，做完了以后形成什么文檔，交給誰？在這個過程中您覺得什么地方不太方便？在整個業務調研過程不斷順便問一句，這樣的任務你每個月大概接多少，多的時候多少，少的時候多少，每次出圖量多少，用什么軟件設計為主之類的問題。

這樣交流的好處是用戶對熟悉的業務可以很自如的進行表達和溝通，而不至于讓整個交流變成一個單向的信息收集，交流的氣氛會越來越好，問題也會越談越深入，而不僅僅停留在一些準備的表面問題上。

而且很多問題在一次業務溝通中就交流完成了，不需要反復去問，增加被調研者的工作強度，也節約了調研者的時間。

一個小塊業務問題問完后立即要做的一個工作，也是很重要的工作：立即主動復述用戶所講的業務和過程，讓用戶確認你明白他所說的內容。

當用戶發現他說講的內容你可以理解并接受的時候，是很高興的，第一覺得自己沒有白講，第二他就開始認為你也是比較熟悉業務或者有能力熟悉業務的人員了，第三如果發現復述有什么不對，可以立即糾正。

所以調研不是調研人員的獨角戲，而是用戶為主介紹，我們只要起到引出話題，復述內容的作用即可。一個滔滔不絕的用戶應該是一個成功調研的特征。

調研結束后一定不要忘記的一句話就是感謝！

感謝之余還要請用戶有時間審核我們的調研記錄。

根據麥肯錫的建議，有些人在快結束會談時可以再提出一個相對敏感的問題，這個時候問題人容易放松，會有心情回答一些一開始不愿意回答的問題，這個辦法有時候可以試一試。

2.6.2 常見錯誤四：不注意收集異常的事實，挖掘背后的需求

很多人做調研，問問題很積極，溝通也很有技巧，但是就是缺少一些職業敏感，很多很有價值的信息用戶已經說出來了，就是不注意。

一般多次調研的人很容易發現很多業務在不同的企業都是一樣的，漸漸在調研中失去新鮮感，其實調研不是簡單了解企業業務流程，而是要找到業務流程中問題。用戶請我們來就是準確發現問題，然后再提供解決方案的。

可以如何發現問題呢？

問題往往是隱藏在意外事故之中的，如果聽到一件和流程不符合的事情，或者和管理預期不符合的事情，這些事實就是異常的事實，值得我們高度重視，深挖窮究。

為什么會產生這個事實？原因是什么？這個原因到底是什么產生的？一層一層了解下去，就象撥筍一樣，最后把事情分析得很透徹和明白了，問題的解決思路也就出來了。

比如有的企業更改非常多，很多調研人員就寫上一句，更改管理業務很重要。或者更改管理是要重點解決的問題，可以為什么企業有這么多更改呢？這樣一查下去，就會發現不同企業造成更改的原因是不同的，不同的原因自然要用不同的藥去診療，才能收效。

如果我們不關注細節，不收集大量支持我們的事實，等我們真有機會見高管的時候，我們又怎么讓企業領導相信我們這些相對年輕的人可以找到企業的病根，并有好的解決思路呢？

唯有事實，大量的事實會幫助我們說服企業的領導支持我們。

所以在調研過程中要隨時分析現有流程存在的問題，而且一定要找到事例證明問題存在，并事后分析可能存在的改進點。

打動用戶的力量就在在于你對其業務了解的程度！2.7 現場調研階段容易犯哪些錯誤？(三)2.7.1 常見錯誤五：每天調研工作時間太長

有的人有一個習慣，喜歡把調研工作都完成后才開始寫調研報告，認為這樣有整體感。有的人每天從早調研到晚，用個把小時整理下調研記錄。這些都是不好的調研習慣。

其實每天調研的時間一般不要超過四個小時！

對每個個體一次訪問的時間也不要超過兩個小時！

四個小時的調研內容是需要用同等長度甚至更長時間整理才能成型成體系的，所以在每天的調研計劃中，必須要和企業溝通好我們自己的工作方法，保障我們整理調研內容的時間。不要讓用戶以為我們每天沒有調研的時間沒有在工作，實際上為了整理四個小時的調研內容往往要用掉八個小時。

如果要想控制每次調研時間又不至于遺漏關鍵信息，比較好的方法有兩個。

第一是將要調研的問題結構化，建立結構化的問題可以方便自己快速把調研信息轉換成調研記錄，也容易防止遺漏問題。

問題結構化就是針對一類業務將一組相關問題形成一個開放性和封閉性的問題引導區，這樣在短時間內可以把一個業務快速搞清楚，被調研者也容易順著業務思路解釋。

第二就是盡量不要一個人調研，應該兩個人調研，如果兩個調研者中有一個是企業項目組成員就更好，因為大家可以一起在調研中互相補充可能會遺漏的問題。而且可以一個主問，一個主記，合理分工，提高單位時間內的調研生產率。

調研完成后要及時迅速把調研內容轉化成文字，而且要轉化為結構化文字，不是用戶說什么我們寫什么。這樣做有很多好處：

第一避免遺忘，好記性不如爛筆頭，調研過程中不停把信息記錄在本子上，但可能還是有一些遺漏，必須用一些時間趁著大腦有印象，趕緊補記下來。

第二寫記錄的過程就很容易發現一些自己感覺清楚但實際上并不清楚的內容，這些內容馬上可以形成第二天的問題進一步確認，把調研逐步推向深入。

第三每天寫清晰完整的調研記錄，可以立即反饋給用戶確認修改，用戶也會認可我們的職業精神和專業水準，而且每天都看到具體的工作內容記錄，工作成果也容易得到確認。

第四可以反饋給公司相關同事，讓他們立即提供反饋意見調整調研進程。

第五整理的過程就是對企業問題深入思考的過程，這是一個很有趣的腦力勞動。

有的人想在這些方面偷懶，不隨時注意整理調研信息，最終調研報告質量就不會太高，缺少深入的分析，也就不能為后續工作提供有價值的信息。

2.7.2 常見錯誤六：聆聽，而不是提供解決方案

有的人在用戶提出一個疑難點的時候，很希望把自己的產品特色展示出來，花了大量時間講自己的賣點和特色，給用戶做了大量啟蒙工作。

當然有些用戶還會對一些特色功能念念不忘，并拿來要求其它供應商提供。

其實在調研過程不是做解決方案的過程，調研就是為解決方案奠定基礎的，過早在調研過程中提供問題的答案有如下壞處。

沒有經過精心準備的演示可以有幾個亮點，但很難形成整體打動別人決定性力量，反而浪費了調研的時間，影響了為有價值解決方案制作的調研時間。

提供解決方案往往是臨時思考沒有經過全面分析，難免偏頗，為了表現能力而承諾一定可行的內容發現實際上并不是那么容易，導致后期實施騎虎難下。

做項目不是一個人在做，而是一個團隊在做，如果沒有溝通就向用戶提供了自己的思路，可能會給整個團隊的思路帶來干擾，解決方案一定要在內部達成一致才能提供給用戶。

一些的確非常成熟有特色的業務解決方案可能會提前泄露給競爭對手，對手可以針對性進行準備，導致殺手锏失靈。

所以調研過程中不要過多花費精力介紹我們的產品，而是做一個好的發問者和聆聽者，用耳朵去聽，用心去想，用大腦去分析用戶的信息，去發現有價值的內容。

2.8 現場調研階段容易犯哪些錯誤？(四)2.8.1 常見錯誤七：沒有開業務分析會

很多人做完調研，就按計劃打道回府，準備后續工作，其實有經驗的調研人員還會多做一個工作，就是開一個針對企業領導、項目負責人和主要業務層面的調研工作匯報會。

我們說調研目的是讓用戶讓用戶認為調研者已經非常了解或者有足夠能力了解企業現有業務流程。

單個用戶是否建立這種認識我們是通過復述技巧實現的。但對于企業領導又如何知道我們了解企業業務呢？

有人說這些將在解決方案中完整體現，不過說實話，有幾個人相信我們這些管理供應商寫的多達百頁的文檔企業里會有三個以上的人看一遍？

都是在浪費紙張而已！

所以在調研完成之前，在調研計劃中調研者應主動安排或者創造這么一次匯報的機會，專門陳述我們對企業業務和要解決關鍵問題的認識，這個認識陳述好了，企業自然對供應商刮目相看，就算有一些偏差，也可以立即得到糾偏的機會。

這個匯報會時間不一定要很長，但可以讓企業領導真切感到我們調研工作的成效，我們對事實把握可靠程度，我們對企業業務了解深入程度，我們對問題分析細致程度，我們在該領域的專業程度即可。

有了這個階段性總結，調研工作就可以說順利完成了，可以進入下一階段準備工作了。

不過在業務分析會上一定要注意一點，不能用過高的姿態切入。

有的人經過調研確實發現了企業一些問題，也想到一些很好的解決思路。于是其在業務分析會上企圖指點天下，痛陳不足，確有嚴加改進必要的時候，就有可能犯一個大錯誤的時候。

有了表現欲，就容易昏頭。

業務分析會一個鐵的原則就是不要輕易說自己用戶的不足，即使要說，也應用一種委婉的方式表達；指出可進步的地方，而不是指出落后的地方。指出不受控的地方，而不是失控的地方，指出實現不方便的地方，而不是指出無業務管理覆蓋的地方。

這些都是做業務分析會要替自己客戶考慮到地方，不要隨意批評別人不足，也不要以為企業沒有人知道這些毛病，更不要以為他們不知道這些毛病該如何解決，有時候無非是外來的和尚無牽掛，好念經而已。2.9 現場調研階段容易犯哪些錯誤？(五)

2.9.1 常見錯誤八：只重視正式溝通，不重視非正式溝通

調研工作特別是在正式調研活動中有些問題并不方便了解，所以調研工作還包括一些非正式場合，這些場合適合調研者問一些相對敏感或者自己有看法但沒有把握的問題。

所以調研不僅僅在工作計劃中所列走訪，座談，會議等形式中，也在和用戶一起聚餐等非正式溝通活動中。

只要調研計劃沒有結束，所有的時間都是為調研而準備的，走路，閑談，吃飯都是可以進行調研的機會，不一定要正式場合才能開始調研。

這種非正式溝通信息一樣很重要，而且往往是真實運行企業的信息，和正式調研得到的信息正好可以互相印證。

在非正式溝通中調研者還可以和企業一些人建立友好的關系，為今后工作也奠定了良好的基礎。

所以好的調研者不僅僅是一個專業人員，在非正式場合也是一個可以讓別人說話的人，這樣的調研行為才是完整的。

2.9.2 常見錯誤九：關鍵業務只詢問了個別人意見

一些業務在整個調研工作中是占據很重要分量，而且涉及多個業務部門，這個時候調研就要記住“兼聽則明，偏聽則暗”，一定要把業務涉及不同部門意見都聽到，也要把不同人對同一業務描述進行對比調研，從中能發現很多錯誤。

此時不可因為覺得調研內容很飽滿或者時間緊張而只做單點調研，關鍵業務一定要從其它人那里不斷得到印證。

不過再問第二個人的時候，就可以用主動復述業務的方式，請其重點指出不對的地方，加快調研進度。

2.9.3 常見錯誤十：調研時有選擇問問題

有的調研者在調研階段就非常小心，特別是在其對自己軟件不足的地方有足夠了解的時候，總想在調研階段引導用戶，接受自己的系統，繞過這些自己產品不足的地方，這也是一種錯誤的做法。

首先如果調研發現用戶迫切需要很有價值的問題是公司目前不能解決的問題，并不等于不調研就可以回避，無論將來在技術答辯還是售后實施，這個問題總是要冒出來，與其回避，不如主動搞清楚，匯報給公司，看看到底有什么辦法可以解決。

真正的問題都是回避不了，繞不過去的。

我個人意見，越是有公司明顯不能解決的問題，越要調研清楚，搞清楚來龍去脈，為公司今后產品發展提供完整的需求建議，作為一家負責任的軟件公司，首先要承認自己的軟件不可能解決所有的問題，但一定要在發展過程中逐步解決更多的問題，調研時都回避了，不就失去了公司產品發展的機會了嗎？

其次如果有選擇性問問題，就會遺漏一些關鍵性業務，這樣對調研整體質量有影響，在后續工作中容易被動。

至于不想將用戶一些天馬行空問題，或者的確不想引發他們高度興趣的問題回避的方法，不是不通過調研，而是認真記錄，但不提供在正式文檔的方式規避。

很多人很多需求都是一時靈感，沒有經過認真思考，所以口舌之快，過了也就過了，不形成文字記錄，他自己也不記得自己說過什么了。如果是真的關鍵問題，在后續復述，確認調研記錄還有業務分析會上還會提出來的，這個時候再確定寫入正式文件也不遲。

對于這些暫時不能滿足的需求和超出范圍的需求，可以另外整理一份內部文檔給公司分析。

2.10 現場調研階段容易犯哪些錯誤？(六)2.10.1 常見錯誤十一：一次調研就企圖鎖定需求

很多項目啟動后轟轟烈烈進行了一次深入調研，然后開始配置開發實施，忙得不亦樂乎。好象把企業問題搞清楚了，就應該是實現和解決的階段。

實際上很少有人能夠在短短幾天內把企業的問題搞清楚，即使你努力進行了半個月甚至一個月的調研，在實施過程中你還是會發現對很多問題認識我們依然不夠深入，不夠完整。

這個時候我們應該意識到，我們依然還需要進行調研，切不可因為是大規模調研完成了，對此時的調研就隨意了，不留記錄，不進行確認了。

事實上這些調研信息要隨時記錄確認并最終完善到項目解決方案中，可以這樣說，信息化項目中始終要有隨時開始調研的意識，如果我們承認信息化需求是無止境的話，那么調研也是無止境的。

為什么不能通過一次調研鎖定需求呢？

正確的需求是系統成功的關鍵。預先鎖定需求的假設前提是用戶不經過系統上實踐的過程，用戶就能預先精確的提出所有的系統需求。

某些簡單軟件或者具有極高技術水平的用戶可能可以，但是一般情況是用戶只對其目標和需求最初只有模糊籠統的認識，許多細節都不清楚。要求一個只有初步設想的用戶或個別用戶負責人準確無誤地說出全部需求，顯然是不切實際的。

用戶為了證實和細化他們的設想，往往需要在某個系統上持續不斷學習和實踐的過程。特別是在大型管理系統軟件上。

即使經過深入細致的預先鎖定需求的工作，當人們實地觀察和使用了目標系統以后，也常常會改變原來的某些想法，對系統提出一些新的要求，以使系統更加符合他們要求，事先鎖定需求的方式其實也會經過多次反復，甚至完全失敗。

大型軟件的開發需要系統分析員、軟件工程師、程序員、實施經理、用戶領導、用戶負責人、具體用戶等眾多各類不同層次不同技術水平人員的一致協調努力，因此良好的通信和相互理解對于保證工程成功至關重要，傳統的需求鎖定方法假設使用適當的文檔可以做到項目參加者之間清晰、準確、有效的溝通。但是各種文檔本質上是被動、靜止的通信工具，通過它們來理解一個動態系統是困難的。

用戶變更需求是正常的，用戶沒有實際操作過軟件之前無論你怎樣描述都會有對軟件功能理解不一致的地方，可能是技術協議上書面文字表達一致但對實際軟件操作理解不一致，可能根本就是不用不知道哪里不適合自己的需求。

打個比方，就象買衣服，無論別人怎樣推銷，客人一般都會試一試覺得合身再買，我們一般比較大的項目都沒有讓用戶體驗過而且在推銷時說了很多動聽的話，自然期待高，失望也高，而且用戶為適應ISO認證或PDM/ERP系統必然伴隨組織機構和業務流程重組，這里面有很多反復的過程，對應的文檔，設計流程，對軟件操作提出變更是正常的。

我們的問題不再于要用戶不變更需求，而在于找到一種方法讓用戶認識到我們的軟件能發揮作用，當有新的需求時通過使用我們軟件建立的信任關系重新形成新的業務，這也是調研時要保持一種理念。

2.10.2 常見錯誤十二：調研工作表現不職業

有的調研人員工作很努力，但在現場很難得到用戶的認可，就是因為經常表現出一些職業不成熟的緣故，甚至有的表現是不道德的。

常見不成熟職業表現有：

1、不征求用戶同意就翻看其資料(如果有的競爭對手敏感資料想獲得，也一定不要給別人看到)；

2、調研過程中電話短消息不斷；

3、在用戶現場上網工作時順便聊天看和工作無關的內容；

4、沒有征求用戶同意使用用戶電話；

5、用戶同意使用電話講起來沒完沒了；

6、對用戶現有各方面狀態流露輕視的態度，例如認為用戶條件不成熟，管理不到位，表現出眼界高人一等的想法。2.11 調研工作方法推薦 2.11.1 每日調研流程

1、提出調研內容，請企業項目組成員配合預約人員時間安排訪談；

2、訪談

3、當場復述內容，確認理解對方表達的問題

4、立即將整理訪談結果形成文檔記錄，確認需要繼續了解的內容和未清楚的內容

5、如果需要，安排時間請被訪談對象確認訪談文檔記錄，特別是一些關鍵名詞定義部分

6、和企業項目組成員配合約定下一時間段訪談安排。

2.11.2 訪談成功的九個要點

讓訪談者上司安排會面

調研前應向調研者介紹調研內容和時間大概安排，讓其心中有數

聆聽，不要發表指導意見，要靠和用戶交流發現問題核心所在

隨時收集和記錄事實，尋找異常現象，發掘管理改進需求，認真記錄并探討原因

盡量兩個人一起采訪，最好一個是企業項目組的成員

復述、復述再復述

一次不要問得太多

在結束會談后又提出一個問題

訪談結束后一定要表示感謝

2.11.3 良好的結構化調研順序

先了解企業基本情況和項目組成員情況，由此建立對企業初步認識，對項目有個初步判斷；

再了解企業組織結構和崗位設計，由此確定訪談對象；

再逐個按照業務口了解業務流，業務流要關心業務可以劃分為哪些階段，每個階段應該是相互獨立，彼此窮盡的。

每個業務階段要問清楚業務目的，輸入數據和輸出數據，過程步驟，每個步驟的負責人，什么時候開始，什么時候結束。

輸入數據其什么作用，有哪些信息傳遞到輸出數據中。輸出數據又起什么作用，是指導下游還是反饋上游。

業務流程調研質量評判標準就是能否清晰簡明畫出企業業務流程圖和數據流程圖。

2.11.4 售前和售后調研的不同

售前調研一般是為產品演示，技術交流做準備，同時調研過程要注意突出自己強項，給競爭對手制造門檻。

售后調研一般是為解決方案，項目實施做準備，同時調研過程中要注意尋求項目價值點，利用價值點置換項目邊界，盡量把項目邊界最小化，項目才容易成功和受控。

售前調研一般由商務主動和用戶協商時機，根據實際情況確定先調研還是后調研。售后調研必須盡快啟動，而且應該在項目啟動大會后展開調研。

售后調研前一般要和企業高管親密接觸，取得支持。在啟動大會上對調研方法和需要取得支持告訴企業配合人員后進行。

售前調研一般要協助拿項目，所以不要輕易發表對問題傾向性看法，要了解事實，用比較文飾的語言表達對問題的認識，通過對事物認識深度獲取支持。售后調研可以相對直接提出問題，擺事實，陳厲害，爭取最大范圍重視，進而獲得支持。

2.11.5 如何寫調研日志

調研日志有三個要求：工作過程清晰化，調研內容結構化，不明內容有后續計劃。

首先調研日志上要看出本日你調研了哪些部門，走訪了哪些人，用了多少時間，獲取了哪些業務的信息，這就叫工作過程清晰化。

然后調研內容不能是流水帳記錄，必須將被調研者的話組織成一個個合理的單元，這些單元獨立可以反映某個業務層面的情況，然后整體上構成一個業務調研報告的部分。

不同的信息結構化方法可能不太一樣，有的適合用表格，有的適合用文字段落，有的適合繪制圖形(例如框圖，魚骨圖等等)。

調研日志最后要說明今天調研中還有哪些問題，需要進一步明確，并有認真記錄。

2.11.6 如何寫調研備忘錄

調研備忘錄一般情況下并不是把自己調研日志的內容匯總重新羅列，因為調研日志和業務調研報告就是做這個工作的。

調研備忘錄和一般的備忘錄一樣，主要是說明本次現場工作進行了哪些工作內容，達到了怎樣的目的，和企業約定的下一步工作安排是什么，并得到企業負責人簽字認可。

備忘錄主要讓用戶看到我們做事的規范性，而且在今后合作中將不斷用同一格式備忘錄強化我們在規范上的一致性，同時備忘錄要讓用戶感覺到我們本次現場調研工作時間緊湊，內容豐富，層次清晰，讓用戶對我們形成良好的印象。2.12 接口調研背景知識(上)

現在管理軟件項目中接口需求很多，很多項目接口實現得并不理想，原因就在于接口協議質量不高，而接口協議是和接口調研緊密相關的。一般接口調研和其它調研方法是一樣的，但要做好接口調研就必須具備一定的專業知識，這可能是能否做好接口調研的關鍵。

接口協議除一般性協議要素外，應該包括如下內容：

2.12.1 接口技術實現方式

接口方式最高級一種是主動式。

即通過直接對其它軟件的數據庫進行操作。這種方式因為涉及到對用戶數據讀寫操作，對于對方軟件而言，安全性是最大的問題，驗證的復雜程度也最高。主動式基本有兩種方式：

1)DATA方式，通過數據庫語言對數據庫進行直接讀寫。這種情況要求對對方數據有詳細認識。需要對方的人員可以提供數據庫的詳細資料。為了保障數據的安全，要界定對讀寫要求。一般和用戶自行開發的系統會比較多出現此類要求，商品化ERP很少提出這種方式。

2)利用其它軟件提供的工具。除了直接對數據進行讀寫外，有些軟件也提供了一些工具(可能是控件，函數，腳本等)。可以通過這些工具對數據庫進行操作。例如現在神州數碼易飛ERP就全部采用控件方式接口。

這種情況下要提供這些工具的詳細使用說明。

接口方式相對主動式的就是被動式開放。

同主動式對應，即開放軟件商自己的數據庫或開發接口給其它供應商讀取數據。這種方式涉及到軟件商提供的數據或開發程序。對方要我們的哪些數據，將成為了解需求的重點。按提供方式的不同可以分為以下四種。

1)DATA方式。即開方我們的文件或數據庫格式給對方。由對方軟件直接讀取數據。這樣的情況一般在企業有開發能力，而且只需要信息提取(不是寫入)時才使用。這種情況很少。

2)腳本方式。早期的腳本語言，多是一種專用高級編程語言。實現了基本的程序流程語句，簡單的數據結構，在此基礎上，提供訪問軟件內部數據的語句。通過這類專用語言，用戶可以對程序進行界面配置，實現簡單的功能擴展，給用戶提供了一定的靈活性。而只需用戶懂一點程序設計知識即可。這類語言的缺點是沒有通用性，功能有限，由于解釋執行，速度受到很大限制，并且應用軟件開發商實現專用編程語言及調試環境有較大難度。對于應用程序，需實現三個要求，就可擁有腳本語言編程接口：

A)應用程序的對象模型

B)適合應用程序對象模型的對象

C)腳本語言編程引擎

前面兩個方面，需要應用程序用組件對象模型的方式構造。采用組件方式，是軟件開發的發展方向，提供對象模型是一件很自然的事情。第三個方面，有通用腳本語言編程引擎供選擇，微軟的ActiveX腳本編程引擎可以免費使用，VBA腳本引擎需要購買。ActiveX腳本引擎實現了基本功能，沒有調試環境。VBA是一種通用編程語言，其核心就是應用廣泛的VB，擁有大量函數支持，窗口編輯能力，強大的調試環境。很明顯，微軟希望VBA成為應用軟件二次開發的通用語言。例如CAPP和國外PDM的接口就屬于這種開放方式。

3)鏈接庫方式。基于結構化的軟件，可以提供軟件內部使用的動態連接庫，供用戶使用。動態連接庫是速度最快的接口，應該說是一種很好的選擇，CAPP目前的二次開發接口就屬于動態連接庫方式。

但是動態連接庫在接口升級時會遇到麻煩，用戶程序難以和正在運行的應用程序進行數據交換。用戶也難以使自己的模塊(用戶實現的動態連接庫)嵌入應用程序。因為動態連接庫的通常首先實現的(至少要定義輸出函數接口)，而后才能使用動態庫。但應用軟件開發時，用戶實現的動態庫根本不存在，AutoCAD的ObjectARX用一種特殊的機制，才使AutoCAD可以使用用戶開發的動態庫。目前國內很多AutoCAD二次開發軟件，就是使用ObjectARX開發的，可以完全的嵌入AutoCAD。

4)COM組件方式。COM對象接口：基于組件對象模型的軟件，可以提供軟件的COM對象接口。組件應用程序由多個組件打包而成，組件之間的聯系是一種松散耦合，使其中某個組件的改變不影響其他組件，應用程序修改，改進變得方便。這就如同一臺復雜的機械設備的各種零部件用螺栓連接起來，零部件可以輕易更換。而傳統應用程序就像所有零部件都通過焊接連接的，如果要改進，只能重新做一個新的。組件程序由于由許多具有位置透明性(無需知道組件的位置)的組件構成，可以很容易實現分布式應用。組件架構強調實現對象模型，開發接口是基于對象的，符合用戶的思維方式，比動態庫提供的API，更易于理解，使用。組件是完全與語言無關的,任何過程性語言夠可以用來開發組件，根據不同的需求，可以輕易的用不同語言開發應用程序的不同部分，用戶可以選擇任何過程性語言做二次開發。通過COM的底層機制，可以訪問運行中的應用程序對象，實現與運行中程序交換數據。用戶組件也可以易于嵌入應用程序中。COM的主要問題是，運行速度比動態庫慢，特別是自動化接口；對系統穩定性要求高于動態庫，要求系統的COM平臺能正常工作。

最常用也是最安全，成本最低的接口方式是中間文件接口。

雙方的數據交流通過中間文件進行。這種方式由于比較靈活，接口雙方都比較明確工作。而且重要是的，接口雙方的軟件升級，對于接口本身(對方軟件本身)可以說沒有影響。是目前采用較多的接口方式。

如果是中間文件的還需要確定是全量式接口還是增量式接口。

接口本身是為了雙方數據可以保持交流和數據一致性進行的。一方提供數據，另一方根據對方的數據來更新自己的系統的數據。所以對于哪些信息是新加，哪些是刪，哪些是更新要進行判斷。從數據提供方而言可以提供以下幾種：

全量：按軟件數據內的數據提供全部的數據，不進行區分哪些是增，哪些是刪。這種方式需要用戶對比自己內部的數據進行區分哪些是增，哪些是刪。

增量：由數據提供方進行對比后，區分哪些數據是要更改的，哪些是要刪除的。對方軟件根據數據提供方提供的文件直接更新數據庫。這種方式的重點是要掌握同什么數據對比，得出增減記錄。另外，對不不同的記錄(增/減記錄)是提供不同的文件，還是在同一文件內對于不同的記錄做上標記也是要定義的。此時可能就要在接口字段上定義更改標識，更改單號，版本號等信息。2.13 接口調研背景知識(下)2.13.1 接口內容

接口方式一旦確定，就需要確定接口的內容。

接口內容首先要確定接口入口，從哪里開始匯總接口數據，接口數據每次包含多少對象，這些對象是如何聯系在一起的。例如接口數據每次都從一個完整的產品上開始匯總，或者從一個完整的工程任務上開始匯總，或者從任意零部件上都可以發起匯總。

第二接口內容要確定接口時機，要明確哪些字段由數據提供方(其它系統)寫，那些讀，在什么時候進行。也就是約定當數據達到怎樣的規定后才可以啟動接口輸出，此時也可以約定接口輸出負責人員。例如當產品結構發布，相關工藝數據也發布后才能啟動接口，如果有明確接口時機要求，接口程序應適當做校驗性判斷，防止提供不正確的數據給下游系統。

第三接口內容要確定接口格式。

接口格式包括明確數據交換提交的方式：是文件級還是數據庫級，然后明確交換文件的名字，存盤路徑。

明確文件的格式，包括文件或數據表包含的字段名，字段次序，字段類型，字段長度，分隔符(如是文本文件)，是否必填，默認值，下游系統對應含義，實際數據樣例，接口對應數據來源，該字段在實際操作中填寫規則。

第三接口內容要確定接口樣例。

接口技術協議附件必須包括用戶方提供的樣例數據，樣例數據必須具備典型特性，能夠覆蓋企業各種可能的實際數據情況，保證驗證樣例數據對接口測試的完整性；

如果一個樣例不能覆蓋可以提供足夠樣例數據，用戶方可提供多個樣例，直到可覆蓋各種可能情況為止。

用戶方要保證樣例數據的規范性。此時可能還需要針對接口樣例提供數據規范性錄入操作說明。

依據所提供樣例最終得到的接口中間文件將以完整實例作為驗證標準依據。如果有多個樣例，則需提供多個完整的接口中間文件實例。準備接口樣例將大大加快驗證時間和接口程序調整反復時間，也有利于企業，供應商快速就接口協議達成一致性理解，是看起來慢，實際上最快的有效接口方式。

2.13.2 接口數據一致性握手方式

接口數據的一致性通握手方式來保障。一致性分為靜態一致性，動態一致性，雙向一致性。

靜態一致性：如物料編碼信息，原始工藝設計信息。

動態一致性：如設計更改信息，在一個系統內的數據更新后，要求另一個系統內的數據也要進行相應的處理。握手方式即明確如何讓對方系統得到要進行更改的信息(也可能是依靠人員來進行手工操作)，這樣對方系統對接口文件進行處理。

雙向一致性：復雜的系統甚至要求，對方系統處理的數據結果要進行反饋。從而更新本身系統的數據。這里面也要對反饋進行定義。2.14 調研后續工作落實階段 2.14.1 如何寫業務調研報告

調研結束后第一個必須盡快整理出業務調研報告，業務調研報告主體內容可以在業務分析會上得到用戶確認。

寫業務調研報告應該結合軟件供應商特點形成一個比較統一的匯報目錄模板，有了模板整理起來就快，不同軟件關心業務內容不同，模板也應該不一樣。

一般而言業務調研報告目錄可以分為三個大的部分，第一部分是業務基本情況介紹，第二部分是企業業務流程圖和數據流圖，第三部分是項目關鍵價值點。

凡是不設計業務流和數據流，但必須要描述的內容，例如企業的一些基礎數據情況，我們把其作為企業的基本情況介紹，例如企業概況，企業設計數據統計情況，企業工藝數據統計情況，企業標準化編碼規定等等，做基本情況介紹時要把握兩個原則：

第一是結構化，不要散亂，將相關性強的一組基本情況設計成表格填寫，這樣既方便填寫，又不容易遺漏。

第二是按照調研先后順序組織，和業務流順序盡量一致。這樣不但層次清晰，而且可以直接將每天調研日志內容復制修改就可以得到最終結果，大大提高工作效率。

業務流程圖和數據流圖有大量標準工具和方法指導，建議這里大家去找相關專門知識學習，本文不在這里展開。

第三部分項目關鍵價值點是非常重要的，項目價值點組織也必須符合結構化層次，不要將很大的價值和很小的價值并列排放，應該將最大的價值，可以相互獨立做為一層，然后將小價值分別歸類到不同大價值下，形成一個價值支撐體系，這個支撐體系也是解決方案的實現思路。

2.14.2 業務調研報告完成后續工作

業務調研報告完成后必須趕緊去找后續工作同伴，按照約定的工作計劃把調研報告交給他們，如果有時間，還可以安排一個內部業務分析會議，做一個全面的介紹。

幫助團隊成員可以準確理解調研報告，啟動后續工作才是一個調研的工作結束。

如果你能按照以上方法進行調研，相信你的調研質量一定很棒，這樣的話，不管后續工作是什么，我相信你都會得心應手的去完成，或者幫助你的團隊成員去完成。

這也就是調研最大樂趣所在。如何寫解決方案？

3.1 解決方案難寫在哪里？ 3 如何寫解決方案？

3.1 解決方案難寫在哪里？

很多人對寫方案非常沒有信心，一涉及到方案的事情，就束手無策，到處求人。

作為一個公認的方案打手，意思是寫方案就象打字員一樣，我覺得我在這方面確實是有絕活。

我基本上都是在方案提交前一兩天接到寫方案的任務，而我自己的事情一般又比別人多一點，也不能不做，只好心里大罵一句，罵完后就打電話搞清楚別人的要求，邊問就邊構思整個方案的推導思路和結構提綱。

因為你不敢讓你的同事知道你只能用很少的一點時間寫方案(基本上我真正動筆寫方案的時間都在2~4個小時以內)，讓他們擔心方案的質量和進度保證，進而對自己的后續工作質量沒有信心。所以我其實也特別緊張，注意力也特別集中，大腦也高速反應，基本上幾分鐘電話或面談完思路基本就有了，然后該干嘛干嘛，找一些零散的小時間把思路不斷推導一下，然后到了一個比較安靜和完整的時間段前才開始寫，這個時候基本上要寫的話都想清楚了，只需要不斷敲字，敲字的時候也是注意力也特別集中，大腦也高速反應，越寫思路越開，很快也就完工了。

寫方案不難，知道怎么寫才難。關于寫方案我只總結一點，結構化地去組織你的思想。

有結構就有思路，有思路就有方案。

另外真正寫方案的人，對自己寫過的方案是永遠不會滿意的，只有這樣，每次都會進步一點點，解決方案水平質量就會隨公司能力不斷增長。

當然我曾經問過很多人，你到底為什么寫不出好的方案呢？

基本上原因可以歸為四類：

3.1.1 第一種是沒有體系

一旦用戶要求提供關于PDM的方案，很多人大腦是一片空白，完全不知道從哪里下手。很多人說起自己的產品來，好象知道不少賣點，不過真要寫出來，又覺得無從下筆。

這種情況一般是寫方案者不熟悉自己產品體系造成的，知道一兩個甚至更多的產品賣點不難，但難就難在成體系，知識就是成體系的點構成的，而不是一句一句離散的說法構成的。

因為我們這個行業從業人員說句不客氣的話，大部分對所銷售實施的管理系統并沒有很深入的研究，都是半路出家，從頭開始，在學習過程中熟悉，在熟悉過程中領悟。所以一下子去駕馭一個整體方案是很痛苦的。只有當一個人對一個產品思路有體系以后，才能夠寫出完整的方案，否則就是一個單元也要費盡腦汁。

所以一個人要想寫好一個方案，首先要把自己產品的來龍去脈，功能模塊，適應領域，典型客戶實施情況有一個全面的了解，這樣才能建立一個完整的知識體系，然后逐步補充競爭對手知識和一些技術性知識，不斷深化自己的知識體系。3.1.2 第二種是沒有思路

有很多用戶看多了模板化的方案以后，想看一些針對他們自己的業務的個性化內容，這個時候有的人按照標準方案模板修改還勉強能對付，但對于個性化內容針對性方案就速手無策了。

這種情況從根本上講還是寫方案者不熟悉企業業務造成的，寫方案，特別是針對性方案不僅僅要求了解企業的需求，而且要知道這些需求是在何種業務需求下產生的，用戶提出這樣的要求到底想解決什么問題，把這個問題找出來，一般針對性解決思路就有了，有了思路，自然可以很好的寫方案。

所以一個人要寫好方案，還需要了解下游客戶的業務，了解業務最有效的方法就是親自做幾次詳盡的業務調研，有了業務調研做基礎，在調研過程中把握用戶關注重難點問題，自然可以比較好的確定方案的個性化內容思路。

解決方案就是把客戶的利益和產品特性之間建立一個邏輯性的橋梁。

3.1.3 第三種是沒有素材

一般不經常寫方案的人，在寫一個方案的時候，即使有想法，有思路，但往往也會很累，就是因為缺少足夠的素材。很多項目現在都是投標，不同用戶可能有不同投標的要求，這樣很難用一個方案去適應所有的用戶，因此在每個方案中都有一些需要準備的內容。

這些內容基本上是通用的，但如果沒有足夠積累每次編制方案就需要花費大量時間去準備，造成方案完成周期過長。

所以寫好方案必須具備這三個條件，第一方案編制者對企業業務要很熟悉，或者有相關業務調研經驗，第二方案編制者對產品非常熟悉，至少對自己產品功能模塊作用很清楚，第三方案編制者手上有大量可公用的素材庫。

3.1.4 第四種是沒有層次

很多人剛和用戶接觸沒有多久，為了表現自己對客戶的重視，馬上表示要提供方案，當然有的客戶剛剛開始選型，也不知道到底要什么搞，也要供應商馬上提供一個方案。

結果拍胸脯容易，寫方案難，自己寫不出來只好求公司，公司沒有安排專人了解情況，只好按模板制作一個，用戶一看幾個供應商內容都差不多，覺得不好，又總結出一些個性化要求，于是大家有開始折騰第二輪方案。

其實方案編制在不同階段有不同策略，不要輕易提供方案。剛開始接觸是可以提供項目合作建議書，類似可行性報告，項目需要考察軟件技術，可以提供標準的產品技術白皮書，到了經過售前調研，有所準備，在演示前后階段和其它競爭對手刺刀見紅的時候，才在知己知彼的基礎上提供解決方案或者投標書。

過早提供方案只能匆匆了事，時間緊急，質量自然不高，自然也就覺得方案難寫。想急就又能解決問題的事情，本來就是一般人做不來的。

方案想要寫得好，一定要用心，用心就一定要耗時間，指望用幾個小時寫出一個高質量的方案是不可能的。如果你做了精心調研，你寫不出一個好方案唯一缺的是技巧。寫方案是一種技巧性工作，明白了這一點，大家都可以經過練習寫出好的方案。

3.2 壞的解決方案有哪些特征？(上)

3.2.1 第一個容易犯的錯誤：只有論點，沒有論證

不好的解決方案粗看起來非常厚重，其實都是功能羅列，象產品手冊摘要版，不象方案書。

不好的方案是一大堆內容，淹沒在一堆紙里面，也不知道想說什么，給你一個厚度，證明我們的工作質量很高。我們國內許多的企業客戶特別是大型企業都很在乎這點，認為可以從方案厚薄中看出對項目重視程度。

如果你做了精心調研，你寫不出一個好方案唯一缺的是技巧。寫方案是一種技巧性工作，有個金字塔式的寫做原理，也就是說文章一定是有結構的。

所以真正好的方案，不一定厚，但能看出你用心，你認真。

現在的解決方案一個不好的傾向是“長、厚、全”，看起來面面俱到，其實對決策者沒有幫助。

所有的方案無差異性，每家供應商都說自己能解決這些問題，而且都有成功案例。

結果所有的方案都無法給決策者簡明的判斷依據，不得不費更大勁去做產品演示和用戶考察。

其實很少有企業高管不知道自己的毛病，在企業你隨便去找一個人，對問題都能講一通，在企業你費很大勁可能都找不到一個人能告訴你這些問題可以怎樣去解決。

通觀這個方案并沒有研究為什么企業會產生這么多問題？問題是這些問題是什么產生的？為什么出這么多問題？而是不斷說“我能！我能！選我，選我！”。

如果不能找到解決這些問題的原因，簡單地去解決這些現象，就象治病不能治根一樣。這樣一個模板化，自我膨脹化的方案想打動用戶的心是非常困難的。

不好的解決方案最大的問題就象寫一篇議論文，能夠發現問題(這個也是模板化的，可惜中國企業大部分沒有意識到自己很多問題并不少見，總以為自己是特殊的一類企業)，提出答案(搞信息化)，但沒有論證(為什么搞信息化和企業管理進步有聯系呢？)。

沒有論證的東西不管內容陳列得多么繁復，名詞多么嚇人，但是無法打動用戶，特別是那種理性的用戶。

看到方案時候，其實很多用戶下不決心，他會感覺每家都差不多。

如果從沒看過方案的人，突然看到這幾個方案，你為什么會感覺某個方案寫得好呢，關鍵是有的方案圖畫的好，通過圖，通過表，會感覺這個公司還不錯，很規范。但對內容認可程度并不高，實際上沒看懂。

3.2.2 第二個容易犯的錯誤：業務解決方案成為功能列表

解決方案省事的一種方法就是將產品功能描述作為技術方案內容進行羅列，或者參照軟件用戶手冊羅列，這種解決方案不是按照用戶業務去準備的內容，而是按照軟件商自己的喜好去編制的解決方案是很難得到用戶認可的。

大凡按照功能列表組織的解決方案用戶會有一個體會，龐大而庸長，但要看到自己想看到的部分非常困難。

而且這種方案還有一個特點，一個問題反反復復的提，在業務背景中指出某個問題，講一通，在價值分析中又重點解釋一通，到了功能介紹時又將某個問題來龍去脈概要說明一下，給用戶感覺是一堆資料的堆積，哪里體現出了方案的針對性呢？

按功能列表準備方案的做法在很長一段時間內不會消失，這和我們普遍是4P銷售人員，還缺少SPIN(顧問式)銷售人員有關，在資源不足的情況下，要保證效率就只能提供功能列表方案了。3.3 壞的解決方案有哪些特征？(中)3.3.1 第三個容易犯的錯誤：結構不清晰

不好的解決方案最共性的毛病是結構不太好，沒有清晰的思路。

沒有思路的方案質量很低，用戶在審閱過程中也不會體會到和一個專人人士通過文字交流的樂趣，他不得不從供應商混亂的思路中發掘亮點，看看到底是誰能解決企業的問題，真是一件痛苦的工作。

一種常見的方案結構毛病就是重復的內容在不同的章節反復出現例如在第一章介紹了對某個問題的分析，提出企業的需求，這第二章介紹方案價值的時候又用不同語句組織類似內容，到第三章解決方案描述中還是要把問題描述一遍，給人感覺思路不連貫，結構臃腫。

這里有一個方案提綱的提綱，我們以這個提綱為例子說明結構不清晰的方案。

公司簡介及資質文件

1.1公司簡介

1.2 自有產品及代理產品情況 1.3 重點工程介紹 1.4 公司資質復印件 2 分項標價表 ***PDM系統技術解決方案 3.1 ***PDM系統技術解決方案 3.2 ***PDM系統具體功能模塊 3.3 報表及明細匯總 3.4 應用工具及封裝接口 3.5 用戶及權限管理 3.6 拼圖打印 3.7 編碼管理 4 實施計劃 4.1 實施步驟 4.2 實施計劃 5 培訓計劃

5.1 系統培訓對象 5.2 主要培訓內容 5.3 培訓方式 6 實施人員資質

6.1實施人員組成及工作職責 6.2實施人員資質說明 7 質量保證及售后服務 7.1 質量保證

7.1.1 工程技術力量的研發水平7.1.2 工程技術力量的實踐經驗 7.1.3 管理水平7.2 售后服務承諾

7.2.1 技術支持與服務的內容和承諾

7.2.2 技術支持與服務的保障 8 開目典型用戶 有關技術秘密的聲明 10 附件

這個方案第一部分、第二部分是用戶投標要求，必須如此，但第三部分技術解決方案應該是重點，這個部分結構就很奇怪。

一般好的方案結構標題就是論點，內容就是用事實進行論證，子目錄是上級總目錄論點的分論點，逐層論證下來，方案顯得邏輯性結構性很強，看看目錄就能看出方案的邏輯推導體系。這就是所謂金字塔文檔體系。

這個方案顯然不是這樣的，看起來一大堆內容，有經驗的人一看就知道是內容的羅列。

例如第三部分總標題是技術解決方案，結果第一個子標題還是技術解決方案，撞車！一定層次感都沒有。而且第一子章節技術解決方案后馬上是功能模塊，技術解決方案理論上包括功能模塊，不是一個層面的東西，技術解決方案應該和實施策略，服務策略平級的內容，所以一定要談談自己技術解決方案，不如用技術解決方案思路或者特色來表達，和功能模塊也就是一個層次分論點，統一支持技術解決方案這個大題目。

具體功能模塊后面跟著一大堆章節就更奇怪，里面每個都是具體的功能模塊，為什么成為和具體功能模塊平級的內容？應該設置為具體功能模塊子章節為妥。

很多人可能覺得用戶對這個點很關心，要重點突出，所以一定要單獨立一個章節，其實不必然，結構清晰的方案用戶看起來才不費心，反而想這個方案，將具體功能模塊，報表及明細匯總、應用工具及封裝接口、用戶及權限管理、拼圖打印、編碼管理列為同一層面內容，反而叫人看不出排列的思路，在厚厚一大本方案中尋找對應關心內容并不容易。

其實不如把技術解決方案分為兩大部分，一部分介紹整個方案的實現思路，對于工作比較忙的人可以看這塊中對企業業務和邏輯的分析是否到位，相當于整個方案的精華版；一部分介紹整個方案的技術支撐模塊，對于項目具體負責人就可以深入研究技術支撐和業務思路之間是否存在合理的組織關系。

在第二部分技術支撐模塊中根據業務邏輯或業務順序設計功能模塊的介紹。

例如一般企業是首先考慮靜態技術資料的受控管理，在受控的基礎上要求盡可能集成設計軟件中的信息，然后要對設計過程建立嚴密的動態控制體系，此外還希望得到一些設計過程的專業支持，例如變型設計，二級工藝路線管理等等，最后要求提供一些編碼，企業資源庫等等輔助工具。這就是我們實現企業需求的一個大的業務思路，在這個業務思路下我們可以將技術支撐模塊分為相應的五個部分。

到這里，整個方案大的框架就有了，我們需要設計一下分標題，使用戶一看就可以進入自己關心的內容，而且每個部分都是對所屬總標題的呼應支持，在業務環節上也是“相互獨立，彼此窮盡”的環節。

在標題的設計上不要過于簡單，例如技術資料管理，應該說有效的技術資料管理，因為有效才成為技術支撐模塊，進而呼應前面業務實現思路中的描述。

3.1 業務實現思路 3.2 技術支撐模塊

3.2.1有效的技術資料管理 3.2.2深入的數據集成 3.2.3嚴密的過程控制 3.2.4靈活的設計支持 3.2.5輔助設計工具

在上面這個思路基礎上，我們就開始結合企業業務和產品功能進行考慮分標題下級的結構，我們用第一有效的技術資料管理為例子。

有效的技術資料管理到底要解決哪些業務問題才算完整呢？我們現在就開始將企業管理技術資料的業務進行羅列，在業務思路中逐步說明。

企業管理技術資料是以產品為線索區分的，所以第一要說清楚產品資料如何管理；

產品下所有零部件是以特征為線索區分的，所以第二要說清楚零部件資料如何管理；

有些零部件還具有共圖共工藝的特征，所以第三要說清楚系列零部件資料如何管理；

進一步有的企業還有系列產品，所以第四要說清楚系列產品資料如何管理；

系列產品可能存在大量配置關系，所以第五要說清楚各種規則下產品配置資料如何管理；

有的企業產品配置型號在生產中還存在批次關系，所以第六要說清楚不同產品批次資料如何管理；

有的企業已經存在了大量歷史設計資料，所以第七要說清楚歷史產品資料如何入庫管理；

在資料入庫時有個問題每個人管理資料習慣不太一樣，全部統一成一種管理方式是必要的，但可能失去一些靈活性，所以第八要說明為個人自組織資料提供哪些支持；

最后要說清楚產品資料為什么入庫管理后是安全的；

我們現在總結一下，這些技術資料管理手段如果都提供了，應該是完整而且層次清晰的，這樣的話，第一個子標題下的分標題又有了。

3.2.1有效的技術資料管理 3.2.1.1 產品資料管理 3.2.1.2 零部件資料管理 3.2.1.3 系列零部件管理 3.2.1.4 系列產品管理 3.2.1.5 產品配置管理 3.2.1.6 產品批次管理 3.2.1.7 資料入庫管理 3.2.1.8 個人資料管理 3.2.1.9 資料安全管理

再看看這個標題和業務思路，這里面體現的一個結構化方式恰恰是“一句話一個意思，一層意思推動一層意思”，到最后就象剝筍一樣，層層剝開，問題解決思路也就步步清晰了，企業看起來也就很明白。

那么我們還可以繼續細分用戶提出的各種業務需求，把企業各種業務要求對號入座，例如下面有一組需求：

有的企業要求用戶訪問控制；有的企業要求提供角色權限管理；有的企業希望按產品目錄授權；有的企業要求全部存放在服務器的數據庫中；有的企業希望支持多數據庫獨立訪問； 有的企業要求提供備份工具等等。

我們現在看看這些業務是否都應該是關心資料安全的？所以應該放在資料安全管理目錄下，而且這些需求也可以分為不同層次，一些是和權限有關的，一些是和存儲和備份有關的，這樣很快又可以把子標題和分子標題設計出來了。

同樣我們可以推導出如下另外幾個部分的提綱：

3.2.2深入的數據集成 3.2.2.1 主流CAD的集成 3.2.2.2 CAPP的集成

3.2.2.3 和其它常用工具軟件的集成 3.2.2.4 數據挖掘統計工具

3.2.2.5 和其它PDM/ERP系統的集成 3.2.3嚴密的過程控制 3.2.3.1審核管理 3.2.3.2發布管理 3.2.3.3更改管理 3.2.3.4項目管理 3.2.4靈活的設計支持

3.2.4.1 變型設計業務支持

3.2.4.2 二級工藝管理業務支持

? ?

3.2.5輔助設計工具 3.2.5.1 編碼管理

3.2.5.2企業資源管理器 ? ?

這個結構化體系一旦出來后，整個方案的思路是否清晰明了，下筆容易了呢？

結構化體系最大的好處是不亂，今后用戶提出任何業務需求，或者產品功能如何擴充，都很容易對號入座，或者擴充子標題。這也是體現了一種分類管理的思想。

當然這個分類思路根據不同業務特征允許存在多種可能，而且分類層次應不超過5級標題，否則文章的可讀性不佳。

如果一定要超過5層，就可以采取其它排版方式體現。3.4 壞的解決方案有哪些特征？(下)

3.4.1 第四個容易犯的錯誤：口語書面語混雜，遣詞造句不嚴謹。

不好的解決方案還有一個毛病就是口語書面語混雜，遣詞造句不嚴謹。

有的人寫作時順著思路走，口語化成分很多，例如本人的行文基本是口語化的，也體現了這個毛病。當然大師級人物的確可以將文章寫得明白如話，但是對我們這些人而言方案是代表公司正式對外的文檔，一定不要出現口語和書面語混雜的情況。

例如太多的兒，的，我們，你們等等都是口語化語言，不應該大量出現在正式方案中。

有的人寫方案比較圖表現，喜歡指出用戶的不足，這個時候喜歡用很激烈的語言。例如缺少管理，業務失控，后果很嚴重等等語句，這樣的遣詞造句是不嚴謹的，方案用語不要追求“語不驚人誓不休”。而是理性分析，認真推導，句句講邏輯。

實在要用一些事實說明企業的問題，不要用刺激性強的語言，例如說企業業務存在問題，可以說業務有可改進的地方，例如說企業管理失控，可以說管理上存在很難受控的環節。

這樣的表達企業反而容易接受，不出問題。

3.4.2 第五個容易犯的錯誤：沒有認真檢查，存在大量硬傷。

不好的解決方案制造過程往往是找一個同類方案，然后主要工作是“CTRL+C”+“CTRL+V”。

很多人就圖快，省事，沒有很好的核對，結果往往容易出現如下幾種錯誤：

第一有些企業在一個方案中用了不同的稱呼(這個也要養成一個習慣在一篇方案中一個企業用一個簡稱和一個全稱)，替換不完整，結果在方案中出現了其它企業的名稱，非常不禮貌；

第二有時候替換過頭，把一些案例中類似的話也替換成為給用戶名稱，鬧出笑話。

第三只注意了文字替換，不注意圖形中的替換，結果文字是一個用戶的，圖片是另一個用戶的，感覺不尊重。

第四是只注意了文字替換，忽視了頁眉頁腳的替換，特別是注意了首頁或目錄的頁眉頁腳，沒有注意正文的頁眉頁腳。

第五是案例不對，明明是汽車行業的用戶，案例全部都是其它行業的，感覺在這個行業沒有經驗。

第六是聯絡方式不對，很多時候將別的營銷區域方案拿過來用，服務信息都沒有更正過來。

第七是存在大量技術硬傷，有時候為了突出軟件技術實力，將大量專家都不一定看得懂的詞匯大量堆砌，其實連軟件公司自己都搞不清楚采用了哪些。

企圖通過讓用戶對概念和名詞發暈進而對軟件產生信賴的方式已經過時，解決方案應該實事求是說明業務問題，不要在名詞上忽悠。.3.4.3 第六個容易犯的錯誤：過于突出自我

很多人寫方案大量出現“**軟件公司”內容，甚至每個產品都恨不得加上自家標識。在很多地方行文造句都是“我能，我行，我有?”等語氣。

這種方案很容易給用戶過度營銷的感覺。我們給用戶寫的方案在售前建議盡量用用戶做前綴，例如說某某企業PDM項目，不要總在說某某供應商PDM的話，給用戶一種相對的針對性，感覺這個方案的確是為用戶準備的。

在售后實施方案中軟件公司的名字只需要出現一次，后面就不需要反復出現，因為大家都知道是你的產品，何必反復體現，我們更應該把用戶的注意力集中到產品本身就應該具備的功能和支撐業務上，而不要形成某某可以，某某不可以的印象。

3.4.4 第七個容易犯的錯誤：沒有評審。

方案提交給客戶之前，一定要經過評審。

沒有開發點的方案，一般經過自評和互評即可，自評時，要重新審視整個方案的結構、問題描述、遣詞造句等方面，特別是用替換修改的企業名稱和營銷平臺等方面的內容，盡量減少低級錯誤。

自己評審過的方案一定要給一個其它的人評審。

互評時，要重新審視整個方案的結構、遣詞造句等方面的內容。

對于有開發點的方案，要經過公司的評審。提交給公司評審的方案，一定是已經過自評和互評的方案，而且要注明主要看哪些部分，以及編寫這些部分的背景知識。

3.4.5 第八個容易犯的錯誤：沒有體現公司產品最新進展。

一般人寫解決方案首先不是想著如何說清楚用戶的業務，如何在公司產品中體現出對業務的支持，而是想趕緊找一個模板，把這一關走過去再說，其實很多時候就是對每個階段工作沒有質量意識最后導致工作處處被動。

所以寫解決方案一定要根據公司最新產品功能認真組合功能實現企業業務，甚至可以考慮利用未來半年內會發布的功能認真組合，因為解決方案離正式實施往往需要半年甚至更長的周期。

很多時候解決方案一抄再抄，都是一兩年前的模板，自然缺少競爭力和說服力。

這個問題的核心是公司有沒有專人專崗負責對標準解決方案的維護和更新發布機制，其實比較好的一種做法結合典型項目技術公關推動解決方案水平不斷完善和提高。

3.5 寫好方案心得(上)3.5.1 動筆前先打一個電話

一般情況下方案撰寫人只是按照別人要求提供方案，并非直接利用方案的人，所以在寫方案之前，問問需要方案的同事，甚至是用戶，聽聽他們對方案的想法和建議，對自己寫方案會有很大幫助。

很多時候方案準備完成方案接受者并不滿意方案的組織，需要返工修改，所以動筆前先打幾個電話，問問別人要什么，不但可以提高方案準備命中率，甚至可以獲得大量現成的思路建議，對自己寫方案大有好處。

3.5.2 一定要努力按業務邏輯去寫。

一般寫方案最簡單的方式就是按照軟件自己的思路和功能模塊組織，因為有大量現成的材料可用。但這樣方案對用戶并非是一種最佳選擇，因為客戶要轉換到供應商的思維才能看懂方案字句之間的含義。

如果從以客戶為中心角度出發，方案應盡量讓用戶容易看懂，好理解，自然也就取得了幾個印象分。

我們方案就是要先仔細探討企業業務，不是將調研結論一羅列，而是從業務分析得出業務需求，最后描述技術實現手段。從這個意義上講，解決方案要按照簡明的操作手冊來準備。

3.5.3 按標準套路寫方案

不同類型的方案都有自己的套路，例如可行性報告，解決方案，建議書等等都有標準的套路，我們應盡量按照標準套路準備方案，不要自成體系，在套路下發揮，套路就體現了一種結構化體系化的思維模式。

關于常用套路我們另有一章說明。

3.5.4 先構思提綱，經過討論，最后動筆

很多時候方案準備時間并不充分，很多人接到任務，壓力之下立即開始動手，這往往是不好的工作習慣，有時候有模板，的確可以快速出活，但時間長了就養成一種惰性，替換方式抄方案還勉強，真要遇到有個個性化問題，因為在平時寫方案過程中思維始終不經過結構化思考的練習，真到方案模板沒有覆蓋的情況，就沒有辦法應付。

好的方案特點是：標題就是論點。結論做為標題馬上拿出來。

好的方案是觀點鮮明，立場明確，有理有據，有血有肉。

所以有方案要寫，一定不要急著寫，而是想自己的提綱，這個完整提綱目錄之間的邏輯聯系和業務銜接自己在心里面推導得比較有力和充分了，才開始動筆快速拿出提綱，有了提綱寫起來思路就不會斷電，寫起來才快。

好的方案一定是做了論點。

論點是假設的，例如說搞PDM有價值。

你說價值有三個方面，能降低成本，提高質量，能縮短交貨期。這都是你的假設。

你怎么知道成立？就要找些事實去證明它。

我們現在都喜歡找什么事實呢？你用了這個功能，所以你的論點就成立，因為你有這個功能，所以你的效率提高了。

這都是扯蛋！為什么用了PDM企業就能做到這幾點。根本沒邏輯推導。

不是還有大把企業用了ERP，用了PDM還不是該咋的咋的，錢都打水漂了。

假如你有好多論點，論點怎么組織呢？你比如我要搞信息化，信息化有大價值，小價值對不對？你要把它都列出來，列出后你還要想一想這個價值和那個價值是不是包容的關系？

好處一定是每個好處都是獨立，它是有層次，每層上的好處是平級的，大好處包含多個小好處，這些好處倒推出來就響應支持你的論點，這種方案看了以后別人就會理解并支持你。然后每個好處一定是在前一個好處的基礎上往前推動一步，最好得出一個強有力的論證過程。

所以好的方案必須是金字塔型的，論據論證最后構成堅實的基礎。

如果有條件的話，這個思路還應該和大家討論，特別是一些重要方案，一定要先反復討論提綱，大家各種意見和思路在提綱中統一了，再動手寫。這樣就不至于遇到寫了一半被人否定，推倒重來的痛苦了。

3.5.5 找一個安靜的地方和完整的時間段開始

寫方案最怕中間不停被人打斷，這樣思路連貫性會很差。所以我無論接到多么緊急的方案編制任務，也不會急著去寫，而是把手頭該處理的小事情處理干凈，然后保證開始后的時間相對安靜和完整，這樣才能保證方案的質量。

而且寫方案一定要保證在一個時間段內初步拿出完整的推導思路和結構提綱才能結束去干別的事情，這樣以后就是逐步補充和豐富內容，不至于還在為結構苦惱，不清楚從哪里下筆，3.6 寫好方案心得(下)

3.6.1 認真準備閱讀提示和摘要

一個方案往往厚厚一本，更多是充點門面，領導是不會真看的。萬一要看，也就是看看包裝是否精美，和頭幾頁文字。

所以方案可以單獨附一份摘要，這是關于整個方案業務分析和解決思路的精華部分，當然也可以帶一點實施方法和典型用戶的介紹。

這樣就可以讓自己方案思路在短短幾頁紙中清晰描述和表達出來，這種提煉過的語言和文字往往更能打動人心。

一般寫一份厚方案只需要一天，寫一份薄方案需要一周，要求在三頁紙內說明問題需要一個月！能把書讀薄是能力的體現。

對于方案也一定要提供一份閱讀指引，告訴不同的人其關心的內容可以在哪些章節直接獲得，方便其閱讀。實際上我們觀察很多論文和書籍序言都有一段來說明這個文字的結構，其實這也是一個標準做法。

3.6.2 注意排版

方案一定要注意排版，印刷要干凈，封面要隆重，裝訂要精美，方案就是一個公司的臉面，雖然不是說一份方案可以決定項目，但一份看上去都不好的方案一定很讓人懷疑公司的能力。

我們很多人見過外企的文字，一般都非常精美，排版很漂亮，大家一看就覺得是專業人士所為。

所以方案的文字和圖表內容最好請專門的美工設計一套標準的排版體系，對方案整體可讀效果會起到極大促進作用。

現在很多方案都是密密碼碼，內容是多，可以有什么用？

不如取巧，少寫一些文字，多在排版上動腦筋，實在想不出好的排版是什么回事的，去買基本暢銷書，你會發現可讀性好的書往往有一個技巧叫“留白”。

方案文字段落邊框之間保持適當距離，特別是邊框合理留白會讓一份方案可讀性大大提高。

象本文這樣的文字如果加上留白設計可讀性就會很不錯。

3.6.3 注意積累素材

寫方案無論如何按照企業業務組織，基本上90%內容是相同的，不過是根據不同思路進行組織而已，畢竟軟件功能不會在短期內發生巨大改變，方案涉及功能也沒有理由發生大的改變，所以方案中很多素材是可以通用的。

包括一些公司通用素材，更是要隨時積累補充完善和歸類存檔，這樣在寫方案時才不會因為尋求這些基本素材浪費大量時間。

基本素材收集還要注意隨時和公司公開宣傳口徑保持一致，防止引用過期素材。當然標準素材最好由公司統一維護。

獲取其它素材的途徑比較多，主要有：

現場初步需求調研與交流

與熟悉類似項目的銷售經理、技術支持工程師、實施工程師溝通、了解

營銷平臺交流

企業網站

相關行業資料介紹

書刊

??

一般可以從企業網站獲取企業介紹。從網站獲取的企業介紹需經“角色轉換”和“內容篩選”，角色轉換是指站在公司的立場描述該企業的情況介紹，要把第一人稱改為第三人稱。內容篩選是指主要介紹企業信息化的基礎，包括企業的經濟實力、管理水平、已完成和正在進行的信息化項目等內容。3.7 方案分類及用途 3.7.1 方案的種類

目前，公司為客戶撰寫的方案分為：建議書、解決方案、投標書。技術白皮書應作為統一的資料提供。

建議書是用于動員客戶啟動項目，或者用于客戶初步選型階段的技術支持，以入圍；

解決方案是用于洽談技術協議和合同之前的技術交底，或者用于議標階段以技術和實施服務等優勢戰勝對手；

投標書是用于客戶招標的技術交底，以綜合實力戰勝對手。

3.7.2 方案的基本結構

3.7.2.1 建議書的基本結構

建議書的側重點是分析客戶實施某項目的宏觀和微觀形式、現存的諸多問題，提出實施該項目的必要性和緊迫性，再介紹相關產品和技術的發展現狀公司的產品特點和優勢，落腳點是公司已具備相當的實力，與公司合作成功率最大、風險最低。建議書的基本結構如下：

引言

現狀分析與診斷

相關技術的發展現狀

公司相關產品的特點

公司具備的實力和基礎

結束語

各個部分撰寫技巧如下：

引言部分

從全國、行業的信息化現狀分析入手，說明信息化是大勢所趨，再從本行業的產品特點出發分析信息化需要注意的關鍵問題，最后介紹企業的情況，特別是信息化的已有基礎，包括企業的經濟實力、管理水平、已完成和正在進行的信息化項目等，說明該企業已具備實施本項目的基礎。

引言部分可分為：

制造業信息化現狀

本行業信息化特點分析

信息化的基礎

現狀分析與診斷部分

從本項目所涉及部門的業務現狀描述和分析入手，找出問題，并提出相應的解決辦法。

現狀分析與診斷部分可分為：

業務現狀描述

問題分析與診斷

相關技術的發展現狀部分

主要介紹本項目所涉及的PDM/CAPP/CAD等技術產生背景、發展過程，以及發展趨勢等內容，并說明這些技術已是成熟的實用性技術。

相關技術的發展現狀部分可按軟件產品類別分別介紹，最后有一個小結。

公司相關產品的特點部分

主要介紹公司相關產品的主要特點，說明公司相關產品是符合其發展趨勢的先進和成熟的產品。

公司相關產品的特點部分可按軟件產品類別分別介紹，最后有一個小結。

公司具備的實力和基礎部分

主要從公司簡介、完整產品線、研發能力、實施與服務體系等方面，說明公司已有足夠的能力承接本項目，并以成功案例證明與公司合作成功率高、風險最低。

公司的實力部分可分為：

公司簡介

完整產品線

雄厚的研發能力

科學的實施與服務保障體系

成功案例

結束語部分

闡明公司愿與企業強強聯手，結為(戰略)合作伙伴關系，共同推進企業乃至本行業的信息化建設。

在結束語部分要明確提出合作建議內容，對于一些戰略合作伙伴關系不能輕易宣講和承諾，一定要經報公司批準之后方可承諾。

建議書的要求是簡短緊湊，內容詳實，便于用戶決策，可以在一份建議書中形成幾個可選方案，推動用戶決策。

3.7.2.2 解決方案的基本結構

解決方案的側重點是分析現存問題，提出功能需求及相應技術實現手段，并輔以實施保障措施，說明用戶需求是可以實現的。解決方案的基本結構如下：

引言

現狀分析與診斷

系統規劃與設計

系統技術方案

系統實施方案

服務內容及措施

典型案例

結束語

引言部分

從全國、同行業的信息化現狀分析入手，說明信息化是大勢所趨。再從本行業的產品特點出發分析信息化需要注意的地方。接著介紹企業的情況，特別是信息化的已有基礎，包括企業的經濟實力、管理水平、已完成和正在進行的信息化項目等，說明該企業已具備實施本項目的基礎。最后通過公司介紹說明有能力承擔該項目。

引言部分可分為：

制造業信息化現狀

某行業信息化特點分析

信息化的已有基礎

公司介紹

現狀分析與診斷部分

從本項目所涉及部門的業務現狀描述入手，分析出問題，并提出改進建議，得出實施系統的必要性和緊迫性，以及需要解決的問題

現狀分析與診斷部分可分為：

業務現狀描述

問題分析與診斷

系統規劃與設計部分

根據現狀分析提出的需求，對本系統從總體目標、指導思想、總體框架等方面進行總體規劃與設計。總體目標，是從企業已有明確的總體目標中，結合用戶需求提煉出來的，不能簡單照抄，還需適當調整與補充。總體框架包括體系架構、運行模式，以及其它企業關心的問題等。

系統規劃與設計部分可分為：

總體目標

指導思想

總體框架

體系架構

運行模式

??

系統技術方案部分

從基本功能介紹、關鍵問題解決方案兩個層面介紹具體的技術方案。基本功能介紹是對本項目所涉及的產品，在標準模塊功能基礎上適當補充各模塊的新增功能或用戶的特殊功能。關鍵問題解決方案是就企業特別關心的問題(包括管理和技術兩個方面)、企業特殊需求中有一定難度的問題，以及管理方面需要改進的問題等提出解決方案和建議。

系統實施方案部分

從本項目的預期效益入手，分析項目實施存在的風險，接著介紹公司規避風險的實施保障措施，最后給出初步實施進度計劃和培訓計劃。實施規劃要結合用戶的實施打算，如果系統規模比較大，可以結合用戶的需求適當進行目標分解，分期完成。

系統實施方案部分可分為：

預期效益

風險分析及對策

指導思想

指導方法

實施管理

實施規劃

實施進度計劃

系統培訓

服務內容及措施部分

從公司能為客戶提供全方位服務承諾入手，闡述公司技術支持與服務的保障措施，讓客戶無后顧之憂。

服務內容及措施部分可分為：

服務內容及承諾

技術支持與服務保障

典型案例部分

用公司典型用戶的案例進一步證明，公司提供的技術方案是先進的、實用的，形成一套科學的、可操作的實施方案。典型案例選擇的針對性表現在：行業、特殊需求、項目類型等方面有相似之處。

結束語部分

闡明公司愿與企業強強聯手，達成合作伙伴關系，共同推進企業乃至本行業的信息化建設。

解決方案注意業務分析，系統規劃，技術方案三部分不要反復出現重復的內容，或者為了表達自己技術方案是扣著業務需求而在系統規劃和技術方案中再次反復描述需求，如果發現有這樣的問題就要精心去組織方案提綱。

此外解決方案要避免浮夸和務虛的內容，要盡量讓用戶看到可操作的內容，例如在實施方案中用戶最關心的是在實施分幾個階段？每個階段相互配合工作是什么？誰去做合適？階段結束的標志是什么？每階段工作需要多長時間？根據企業實際情況有哪些風險？如何規避？基礎數據如何準備？歷史數據如何錄入？工作流程應用前后有何變化？這些是用戶真正關心的內容。

所謂實施方法論，實施原則，實施指導思想，實施團隊結構等看起來飽滿，其實是務虛的內容少寫，寫得越多用戶越不得要領，實施方案的要害是具備不具備可操作性。這里面的原則就是計劃越細化越具有可操作性。

3.7.2.3 投標書的基本結構

投標書是針對標書的解決方案，包含解決方案的全部內容，再增加公司優勢和相關附件。投標書總是原則是按照用戶提供的招標書要求準備，用戶要求如何提供資料就如何提供，不要任意發揮。

常見投標書的基本結構如下：

引言

現狀分析與診斷

系統規劃與設計

系統技術方案

系統實施方案

服務內容及措施

開目公司的優勢

典型案例

結束語

相關附件

開目公司的優勢

相關附件

相關附件按照招標書的規定組織附件。

3.7.3 方案的針對性

為使方案具有鮮明的開目特色，方案必須具有一定的針對性。不同類別方案的針對性有不同的體現。

建議書的針對性體現在同行業的信息化特點分析，本企業已有的信息化基礎、本企業的現狀描述與問題分析等方面。

解決方案和投標書的針對性有相同的表現，主要體現在：同行業的信息化特點分析、現狀分析與診斷、總體目標、關鍵問題解決方案、實施規劃與進度計劃、典型案例等。

現狀分析與診斷部分、實施規劃與進度計劃部分，不能簡單把客戶名稱更改就變成另外一家的情況。

總體目標部分，有企業的個性，如果需要可以分解成近期、長期、遠期目標。

解決方案中可單獨把企業關心的關鍵問題單列為一部分，緊密結合企業的需求特點，不能簡單套用標準說法，必要時可以通過定制配置實現。

解決方案中的關鍵問題與投標答辯PPT中的關鍵問題有區別。投標答辯PPT中的關鍵問題主要是展示我們優勢部分，以攻擊對手的劣勢部分，但一定要有絕對的把握。如何做產品演示？

4.1 什么是演示？

入行五年，售前售后演示最少也有兩百次，也算有一點經驗了，今天把我個人做做產品演示的體會做一總結，希望對所有想做好演示的人員提供一點幫助和指導。

第三篇：sap調研提綱PP模塊

PP模塊調研問卷:

此問卷的目的是了解客戶管理的現狀以及管理水平,發現其中的問題及需改進之處,了解企業對現時管理咨詢的需求,通過問卷的評估,對目前管理各方面作出描述,對客戶需求作出分析,從而為項目實施確定一個系統的完整的業務藍圖.調研內容：

公司目前有實施哪些信息化項目,如ERP,MRP,SCM、PDM、OA等.2 公司目前PMC的組織結構,崗位設置和人員職責如何? 3 對與PP來說,目前最主要的問題在哪里?部門內部還是與別部門的溝通? 4.是什么樣的生產模式,按訂單,按庫存,還是都有,離散型,可重復生產還是其它? 5 目前有幾間工廠,有外包業務嗎?對與外包業務現在是如何處理? 6.公司現有人員多少,生產控制部門人員占的比例如何?人員流動大嗎? 7.對于生產計劃部分有做月計劃,周計劃還是日生產計劃.8.如何去掌控生產進度,以什么報表體現或是有使用相應生產作業系統 9.業務部門是如何把客戶需求給到生產控制部門,生產控制部門又是如何反饋信息給業務部門

10.生產產品種類多嗎?生產周期如何,相對應的物料采購周期呢? 11.公司BOM完不完整,目前BOM有幾層,是所有物料都有放BOM嗎?還是有些做單獨的安全庫存控制?BOM由誰在完成,以什么方式發放到相關部門?對于版本公司是如何控制的? 12.是否所有物料都有給編號,如何定義物料編碼?有分類嗎?目前有分幾大類? 13.是否所有工序都有作業指導書,所有產品都有Workflow? 14.公司的領料流程是怎樣的?退料呢?對于報廢或損耗部分如何處理?對于替代料呢?是否所有的領料都有領料單?沒有領料單倉庫會發料到生產線嗎?如有,事后又是如何處理? 15.公司的物流,倉庫管理狀況如何?如周期,庫存等.16.對于生產線的在制品(WIP),公司是如何控制的?生產線會常待料或堆料嗎? 17.公司有IE(工業工程）部門嗎? 有無完整的工時評估體系,目前誰在做標準工時? 18.公司目前是怎樣去評估產能,生產過程中瓶頸多嗎?主要是設備還是人力或是其他,那公司是如何去做能力的平衡? 19 工程變更頻繁嗎? 變更是否要紀錄?有使用工程變更通知(ECN)嗎? 由誰發出? 20.通過何種方式算物料需求,系統還是手工?是否所有的物料都有采購單,需求計劃準確嗎?會不會出現我要的沒有,不要的很多這種狀況? 21.目前生產線會有幾種形態,批量生產,樣品,重工(redo)等.22.目前執行生產計劃最困難的是什么?生產計劃能匹配到實際生產嗎?是否會出現客戶要的沒有,不要的生產了很多這種情況?造成生產不順暢的因素有哪些? 23.生產線領料是以什么方式來完成?按訂單.安工序的順序還是所有的一次領完? 24.對于客戶財產是如何管理? 25.對于出貨公司是如何管理的?

26.目前客戶交期率是多少?生產計劃部門是如何提升客戶的交期率的?

第四篇：SAP項目MM調研清單

資料準備

MM調研清單

? 目前采購系統和庫存系統的運作流程和功能簡述；

采購根據缺料表在訂單系統里錄入采購憑單，收料員收料，IQC檢驗，合格后，收料員在庫存系統里轉入驗收單入庫。若入庫后發現不合格，由收料員在庫存系統里錄入進貨退出。

庫存系統由進貨和銷貨組成，進貨由訂單系統里的驗收單轉入，銷貨由訂單系統里的訂購憑單轉入。庫存里有調撥單，調整單

? 目前使用的采購報表和庫存報表（提供報表名稱和內容結構框架即可，不必提供實際數據）以及未來可能的報表需求。采購報表由采購憑單，收料單，驗收單，退料單，驗退單

庫存報表有入庫單，調撥單，調整單，常用報表有現有庫存，歷史庫存，期初期未，應收帳款，應付帳款，交易明細

? 廠內組織架構圖，請標明采購組織和庫存組織，人員配置及主要職權劃分。

? 目前所設的原料庫、半成品庫、成品庫、銷售品庫、退貨庫、零頭庫、報廢庫等庫位配置圖。（目前所設的原材料倉A倉，無半成品庫，成品庫A，無退貨庫/零頭庫，報廢庫W。服務倉S）

訪談問卷:

? 組織架構

1.目前采購單位的組織架構？

? 物料主數據

1.主要產品和物料約有多少種？（物料約有1400種物料）大致分類如何（集成電路，線路板，繼電器，被動器件，變壓器，線材，開關，五金件，閥體，液晶屏，其他）？物料庫存單位（資材部）、采購單位（采購部）、發貨單位（資材部）和銷售單位（業務部）分別如何？

2.產品和物料數據量如何？物料數據量大，種類繁多。

3.其它各包裝材料是否納入物料和庫存管理中？（部分大金額包材納入庫存管理）

4.物料定價/估價方式（成品/半成品/原料）

原料按拆分材料，材料成分分析，多家比價進行估價。成品/半成品估價

? 供應商主數據

1.目前供應商分類及數量如何？（例如：主要原料供應商、MRO供應商、國內廠商、國外廠商、一次性廠商等）

Page 1 of 4

MM調研清單

分類：國內，國外，集團內/外，工廠，代理商，貿易商，一次性廠商）

2.與供應商的溝通模式（FAX / E-mail / EDI …）電話，傳真，電郵，去供應商現場訪問等 3.使用的付款條件和幣種的情況如何？ 月結，現金，預付款，支票，期票 4.供應商評估的業務流程簡述

供應商送樣品確認，填寫供應商調查表及相關資料，簽供貨及質量協議，審核供應商現場，小批試用，三批合格，量采。

5.是否記錄物料價格歷史？ 是

MRP & 預測

1.目前采用的物料需求計劃方式如何？

由PMC提供采購需求，長周期材料由采購和PMC協商制定采購計劃。

2.預測的準確度（%）如何？受哪些因素影響？

80%，受業務訂單及產品銷售趨勢，還有原材料的供應。

采購申請

1.采購申請單的產生方式？是否來自MRP(make-to-stock / make-to-order)還是人工建立？

在電腦里錄入，是從MRP系統里生成的 2.采購申請單由哪些單位建立? 由PMC，研發工程部，業務部

3.采購申請單審批流程和審批層次結構如何？

采購員下單，主管覆核，總經理審批，在電腦系統里由財務人員覆核

合約

1.長期合約的業務流程簡述（哪些采購類型和項目需要事先談定合約？）沒有

2.合約數量及維護單位如何？ 沒有

3.合約管理方式如何（數量/金額/排程）沒有

采購

1.生產用物料和非生產用物料的采購申請/采購流程，以及各自所占總采購支出的比例如何？ ?

?

?

?

Page 2 of 4

MM調研清單

生產用的物料是由PMC出缺料，由采購下單,非生產用物料由使用部門提出申請，經審批準后，交由采購部采購。非生產用物料占生產物料采購支出的比率是5%.2.采購項目含哪幾項物料類型？（原料、半成品、零件、包材、成品、貿易品…）

原料、半成品、零件、包材、成品、貿易品…

3.目前有哪些特殊采購類型？（例如外包、第三方采購、資產類采購、事務性采購或服務類采購等）外發加工，資產類采購

4.采購單審批流程如何？審批條件如何（例如金額大小等）？ 采購主管覆核，總經理審批。5.目前有哪些采購分析報表？

采購明細報表（日期別采購明細表，廠商別采購明細表，產品別采購明細表，預交日采購明細表）

采購未進狀況（日期別未進狀況表，廠商別未進狀況表，產品別未進狀況表，預交日未進狀況表）

存量預估報表（產品存量預估明細，產品存量預估統計）

? 發票校驗

1.各類采購的發票如何收集？發票校驗流程如何？

2.是否有“交貨后送發票”或“月結發票”的情況？發票校驗基于收貨信息還是訂單信息？ 3.運輸費如何預估和分攤？

? 外包業務

1.由哪一單位負責？（采購單位或生產管理單位？）外發加工由PMC提出指令，采購負責。2.外包管理方式和流程如何？

同材料采購的供應商管理方法及流程相同 3.如何計劃供料和發料？

根據PMC計劃按委外制造命令，錄入委外送料單形式將材料發給供應商。

4.如何結算外包加工費和后續帳務處理？ 同其他供應商處理方式相同。

? 庫存管理

1.各項物料類型（原料/半成品/成品…）的庫存科目以及成本計價方式如何？（標準成本法或移動平均法）物料類型分為原料/半成品/成品 成本按移動加權平均法 2.倉庫中庫位劃分方式如何？ 按物料編碼順序劃分

Page 3 of 4

MM調研清單

? 收貨

1.收貨及質量管理檢驗流程簡述

倉管員按采購訂單收料，在系統里錄入收料單，交由IQC驗收，合格后，在電腦里錄入驗收單，不合格則錄入驗退單。2.向供應商退貨的業務流程簡述

IQC檢驗不合格的物料，由IQC填寫《來料檢驗退貨報告》由采購簽字后，傳真給供應商。3.收貨后庫存狀態有哪些類型？ 合格品，問題隔離產品 4.目前有哪些庫存分析報表

銷貨明細表，銷貨退回明細表，進貨明細表，進貨退出明細表，調整明細表，調撥明細表，借入明細表，借出明細表，交易日應收/付帳款明細表，現有庫存，歷史庫存，低于安全存量表，庫存呆滯分析，期初期未存量明細，客戶交易明細，廠商交易明細，產品別銷項明細分析，產品別進項明細分析

? 發料

1.根據生產訂單發料或工作中心領料流程如何？ 根據訂單發料。

2.是否有借還料、寄售庫存等特殊情況？ 有借還料

? 發貨及退貨

1.客戶退貨及質量管理檢驗流程簡述

產品如有問題，客戶同業務部提出退貨申請，品管部及研發部確認是我們產品質量問題，總經理審批后，同意客戶退貨，由資材部打退貨單。

2.需要補交貨或再加工的流程簡述（無）

? 跨公司或跨廠交易

1.由哪一單位提出需求（采購單位或生產管理單位？）是否含交貨流程？（無）

2.該交易的計價方式如何（成本乘標定比率或固定價格）？多久調價一次？

? 盤點

1.盤點業務流程簡述

2.盤點頻率如何（年盤、月盤或其他）？

3.實際盤點天數及登記時間、盤盈盤虧調整所需時間如何？ 4.WIP如何盤點？

現有物料系統沒有用到盤點。

? 是否有其它期望達到而目前系統無法達到的需求；目前各流程是否存在困擾或需要改進的地方？

缺料信息一定要顯示什么時間該如什么物料；權限設定。

Page 4 of 4

第五篇：問卷調研

留學培訓有獎意向調查表

（非常感謝您配合我們的調研，我們會全程對您的個人信息進行保密，不會泄露您的個人信息作為商業用途）

我們會在所有參加調研的同學中隨機抽取10名贈送雅思口語暢銷書籍一本（短信通知）

委托機構：啟德學府

1，你有考慮要出國留學嗎

A，是B，否

2，如果有出國留學的想法，原因是（可多選）

A，國外教育水平比較高，希望提高素質學到知識B，看看外面的世界，長長見識 C，今后找工作容易D，為移民國外做跳板E，家長的期望F，追隨社會趨勢

3，如果你有出國留學的想法，你準備去哪個國家呢

A，美國B，英國C，加拿大D，澳大利亞E，其他__________

4，你出國準備參加那些語言類考試（可多選）

A，雅思B，托福C，GMATD，GREE，其他_________

5，你是否愿意周末期間參加培訓？

A，愿意B，不愿意

咨詢人姓名：____________聯系電話：________ QQ：____________

留學培訓有獎意向調查表

（非常感謝您配合我們的調研，我們會全程對您的個人信息進行保密，不會泄露您的個人信息作為商業用途）

我們會在所有參加調研的同學中隨機抽取10名贈送雅思口語暢銷書籍一本（短信通知）

委托機構：啟德學府

1，你有考慮要出國留學嗎

A，是B，否

2，如果有出國留學的想法，原因是（可多選）

A，國外教育水平比較高，希望提高素質學到知識B，看看外面的世界，長長見識 C，今后找工作容易D，為移民國外做跳板E，家長的期望F，追隨社會趨勢

3，如果你有出國留學的想法，你準備去哪個國家呢

A，美國B，英國C，加拿大D，澳大利亞E，其他__________

4，你出國準備參加那些語言類考試（可多選）

A，雅思B，托福C，GMATD，GREE，其他_________

5，你是否愿意周末期間參加培訓？

A，愿意B，不愿意

咨詢人姓名：_______________聯系電話：______________ QQ：_______________