1. 調研工作如何組織？

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

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

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

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

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

 

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

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

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

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

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

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

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

有經驗的銷售人員還應該明白，調研是一個適當實際要去做的工作，不應該被使用者牽著走，應該是整個商務策劃中的一部分，不過這不是本文闡述重點，本文將重點介紹業務調研需要的技能。

2. 調研準備階段容易犯哪些錯誤

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

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

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

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

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

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

真正的調研目的有三條：

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

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

對公司：調研獲得資訊足夠讓後續者進入下一階段工作。

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

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

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

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

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

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

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

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

調研一旦結束，調研者還要清楚一個環節，調研後要做什麼？是做解決方案還是做技術交流，還是做產品演示，還是做實施方案？不管進行什麼工作，特別是在後續工作是公司其它同事配合完成的情況下，調研者有責任有義務確認自己調研工作資訊明確被需要獲知這些資訊的同事收到並理解，並能很好開展後續工作。

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

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

2.2 第二個容易犯的錯誤：計劃不夠細緻

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

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

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

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

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

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

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

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

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

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

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

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

即使是一天的調研計劃同樣可以認真細緻地準備。

3. 調研準備階段容易犯哪些錯誤

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2 第四個容易犯的錯誤：計劃沒有得到使用者確認

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

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

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

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

我們至少要做到80分！

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

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

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

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

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

4. 調研準備階段容易犯哪些錯誤

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

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

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

好的調研準備工作可以包括這麼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條我們到底做了幾條？

也許認真不認真就是我們一個工作到底有沒有質量的根本原因。

5. 現場調研階段容易犯哪些錯誤

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

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

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

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

這樣做的理由有三點：

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

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

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

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

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

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

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

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

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

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

三、借彙報機會領導瞭解他們上專案的初衷。

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

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

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

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

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

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

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

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

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

此外高管並非一定是企業的最高領導，高管是依據企業規模和專案規模動態確定的，一般選擇彙報高管物件的原則是對專案直接負責的人上級或以上級別的人。

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

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

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

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

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

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

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

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

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

做完這些工作才不是匆忙展開調研工作。

5.3 常見錯誤三：不斷地問問題，唱獨角戲

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

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

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

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

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

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

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

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

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

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

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

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

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

感謝之餘還要請使用者有時間稽核我們的調研記錄。

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

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

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

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

可以如何發現問題呢？

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

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

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

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

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

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

打動使用者的力量就在在於你對其業務瞭解的程度！

5.5 常見錯誤五：每天調研工作時間太長

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.7 常見錯誤七：沒有開業務分析會

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

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

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

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

都是在浪費紙張而已！

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

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

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

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

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

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

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

這些都是做業務分析會要替自己客戶考慮到地方，不要隨意批評別人不足，也不要以為企業沒有人知道這些毛病，更不要以為他們不知道這些毛病該如何解決，有時候無非是外來的和尚無牽掛，好唸經而已。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.11 常見錯誤十一：一次調研就企圖鎖定需求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

常見不成熟職業表現有：

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

2.調研過程中電話短訊息不斷；

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

4.沒有徵求使用者同意使用使用者電話；

5.使用者同意使用電話講起來沒完沒了；

6.對使用者現有各方面狀態流露輕視的態度，例如認為使用者條件不成熟，管理不到位，表現出眼界高人一等的想法。

6. 調研工作方法推薦

6.1 每日調研流程

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

2.訪談

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

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

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

6.和企業專案組成員配合約定下一時間段訪談安排。

6.2 訪談成功的九個要點

讓訪談者上司安排會面

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

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

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

儘量兩個人一起採訪，最好一個是企業專案組的成員

複述、複述再複述

一次不要問得太多

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

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

6.3 良好的結構化調研順序

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

再瞭解企業組織結構和崗位設計，由此確定訪談物件；

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

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

輸入資料其什麼作用，有哪些資訊傳遞到輸出資料中。輸出資料又起什麼作用，是指導下游還是反饋上游。

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

6.4 售前和售後調研的不同

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

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

售前調研一般由商務主動和使用者協商時機，根據實際情況確定先調研還是後調研。售後調研必須儘快啟動，而且應該在專案啟動大會後展開調研。

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

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

6.5 如何寫調研日誌

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

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

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

不同的資訊結構化方法可能不太一樣，有的適合用表格，有的適合用文欄位落，有的適合繪製圖形(例如框圖，魚骨圖等等)。

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

6.6 如何寫調研備忘錄

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

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

備忘錄主要讓使用者看到我們做事的規範性，而且在今後合作中將不斷用同一格式備忘錄強化我們在規範上的一致性，同時備忘錄要讓使用者感覺到我們本次現場調研工作時間緊湊，內容豐富，層次清晰，讓使用者對我們形成良好的印象。

6.7 介面調研背景知識

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

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

6.8 介面技術實現方式

介面方式最高階一種是主動式。

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

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平臺能正常工作。

最常用也是最安全，成本最低的介面方式是中間檔案介面。

雙方的資料交流通過中間檔案進行。這種方式由於比較靈活，介面雙方都比較明確工作。而且重要是的，介面雙方的軟體升級，對於介面本身(對方軟體本身)可以說沒有影響。是目前採用較多的介面方式。

如果是中間檔案的還需要確定是全量式介面還是增量式介面。

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

全量：按軟體資料內的資料提供全部的資料，不進行區分哪些是增，哪些是刪。這種方式需要使用者對比自己內部的資料進行區分哪些是增，哪些是刪。

增量：由資料提供方進行對比後，區分哪些資料是要更改的，哪些是要刪除的。對方軟體根據資料提供方提供的檔案直接更新資料庫。這種方式的重點是要掌握同什麼資料對比，得出增減記錄。另外，對不不同的記錄(增/減記錄)是提供不同的檔案，還是在同一檔案內對於不同的記錄做上標記也是要定義的。此時可能就要在介面欄位上定義更改標識，更改單號，版本號等資訊。

6.9 介面內容

介面方式一旦確定，就需要確定介面的內容。

介面內容首先要確定介面入口，從哪裡開始彙總介面資料，介面資料每次包含多少物件，這些物件是如何聯絡在一起的。例如介面資料每次都從一個完整的產品上開始彙總，或者從一個完整的工程任務上開始彙總，或者從任意零部件上都可以發起彙總。

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

第三介面內容要確定介面格式。

介面格式包括明確資料交換提交的方式：是檔案級還是資料庫級，然後明確交換檔案的名字，存檔路徑。

明確檔案的格式，包括檔案或資料表包含的欄位名，欄位次序，欄位型別，欄位長度，分隔符(如是文字檔案)，是否必填，預設值，下游系統對應含義，實際資料樣例，介面對應資料來源，該欄位在實際操作中填寫規則。

第三介面內容要確定介面樣例。

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

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

使用者方要保證樣例資料的規範性。此時可能還需要針對介面樣例提供資料規範性錄入操作說明。

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

6.10 介面資料一致性握手方式

介面資料的一致性通握手方式來保障。一致性分為靜態一致性，動態一致性，雙向一致性。

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

動態一致性：如設計更改資訊，在一個系統內的資料更新後，要求另一個系統內的資料也要進行相應的處理。握手