【正文】 告的部分。不同的信息結構化方法可能不太一樣，有的適合用表格，有的適合用文字段落，有的適合繪制圖形(例如框圖，魚骨圖等等)。調研日志最后要說明今天調研中還有哪些問題，需要進一步明確，并有認真記錄。 如何寫調研備忘錄調研備忘錄一般情況下并不是把自己調研日志的內容匯總重新羅列，因為調研日志和業(yè)務調研報告就是做這個工作的。調研備忘錄和一般的備忘錄一樣，主要是說明本次現(xiàn)場工作進行了哪些工作內容，達到了怎樣的目的，和企業(yè)約定的下一步工作安排是什么，并得到企業(yè)負責人簽字認可。備忘錄主要讓用戶看到我們做事的規(guī)范性，而且在今后合作中將不斷用同一格式備忘錄強化我們在規(guī)范上的一致性，同時備忘錄要讓用戶感覺到我們本次現(xiàn)場調研工作時間緊湊，內容豐富，層次清晰，讓用戶對我們形成良好的印象。 接口調研背景知識(上)現(xiàn)在管理軟件項目中接口需求很多，很多項目接口實現(xiàn)得并不理想，原因就在于接口協(xié)議質量不高，而接口協(xié)議是和接口調研緊密相關的。一般接口調研和其它調研方法是一樣的，但要做好接口調研就必須具備一定的專業(yè)知識，這可能是能否做好接口調研的關鍵。接口協(xié)議除一般性協(xié)議要素外，應該包括如下內容： 接口技術實現(xiàn)方式接口方式最高級一種是主動式。即通過直接對其它軟件的數(shù)據(jù)庫進行操作。這種方式因為涉及到對用戶數(shù)據(jù)讀寫操作，對于對方軟件而言，安全性是最大的問題，驗證的復雜程度也最高。主動式基本有兩種方式：1)DATA方式，通過數(shù)據(jù)庫語言對數(shù)據(jù)庫進行直接讀寫。這種情況要求對對方數(shù)據(jù)有詳細認識。需要對方的人員可以提供數(shù)據(jù)庫的詳細資料。為了保障數(shù)據(jù)的安全，要界定對讀寫要求。一般和用戶自行開發(fā)的系統(tǒng)會比較多出現(xiàn)此類要求，商品化ERP很少提出這種方式。2)利用其它軟件提供的工具。除了直接對數(shù)據(jù)進行讀寫外，有些軟件也提供了一些工具(可能是控件，函數(shù)，腳本等)。可以通過這些工具對數(shù)據(jù)庫進行操作。例如現(xiàn)在神州數(shù)碼易飛ERP就全部采用控件方式接口。這種情況下要提供這些工具的詳細使用說明。接口方式相對主動式的就是被動式開放。同主動式對應，即開放軟件商自己的數(shù)據(jù)庫或開發(fā)接口給其它供應商讀取數(shù)據(jù)。這種方式涉及到軟件商提供的數(shù)據(jù)或開發(fā)程序。對方要我們的哪些數(shù)據(jù)，將成為了解需求的重點。按提供方式的不同可以分為以下四種。1)DATA方式。即開方我們的文件或數(shù)據(jù)庫格式給對方。由對方軟件直接讀取數(shù)據(jù)。這樣的情況一般在企業(yè)有開發(fā)能力，而且只需要信息提取(不是寫入)時才使用。這種情況很少。2)腳本方式。早期的腳本語言，多是一種專用高級編程語言。實現(xiàn)了基本的程序流程語句，簡單的數(shù)據(jù)結構，在此基礎上，提供訪問軟件內部數(shù)據(jù)的語句。通過這類專用語言，用戶可以對程序進行界面配置，實現(xiàn)簡單的功能擴展，給用戶提供了一定的靈活性。而只需用戶懂一點程序設計知識即可。這類語言的缺點是沒有通用性，功能有限，由于解釋執(zhí)行，速度受到很大限制，并且應用軟件開發(fā)商實現(xiàn)專用編程語言及調試環(huán)境有較大難度。對于應用程序，需實現(xiàn)三個要求，就可擁有腳本語言編程接口：A)應用程序的對象模型B)適合應用程序對象模型的對象C)腳本語言編程引擎前面兩個方面，需要應用程序用組件對象模型的方式構造。采用組件方式，是軟件開發(fā)的發(fā)展方向，提供對象模型是一件很自然的事情。第三個方面，有通用腳本語言編程引擎供選擇，微軟的ActiveX腳本編程引擎可以免費使用，VBA腳本引擎需要購買。ActiveX腳本引擎實現(xiàn)了基本功能，沒有調試環(huán)境。VBA是一種通用編程語言，其核心就是應用廣泛的VB，擁有大量函數(shù)支持，窗口編輯能力，強大的調試環(huán)境。很明顯，微軟希望VBA成為應用軟件二次開發(fā)的通用語言。例如CAPP和國外PDM的接口就屬于這種開放方式。3)鏈接庫方式?；诮Y構化的軟件，可以提供軟件內部使用的動態(tài)連接庫，供用戶使用。動態(tài)連接庫是速度最快的接口，應該說是一種很好的選擇，CAPP目前的二次開發(fā)接口就屬于動態(tài)連接庫方式。但是動態(tài)連接庫在接口升級時會遇到麻煩，用戶程序難以和正在運行的應用程序進行數(shù)據(jù)交換。用戶也難以使自己的模塊(用戶實現(xiàn)的動態(tài)連接庫)嵌入應用程序。因為動態(tài)連接庫的通常首先實現(xiàn)的(至少要定義輸出函數(shù)接口)，而后才能使用動態(tài)庫。但應用軟件開發(fā)時，用戶實現(xiàn)的動態(tài)庫根本不存在，AutoCAD的ObjectARX用一種特殊的機制，才使AutoCAD可以使用用戶開發(fā)的動態(tài)庫。目前國內很多AutoCAD二次開發(fā)軟件，就是使用ObjectARX開發(fā)的，可以完全的嵌入AutoCAD。4)COM組件方式。COM對象接口：基于組件對象模型的軟件，可以提供軟件的COM對象接口。組件應用程序由多個組件打包而成，組件之間的聯(lián)系是一種松散耦合，使其中某個組件的改變不影響其他組件，應用程序修改，改進變得方便。這就如同一臺復雜的機械設備的各種零部件用螺栓連接起來，零部件可以輕易更換。而傳統(tǒng)應用程序就像所有零部件都通過焊接連接的，如果要改進，只能重新做一個新的。組件程序由于由許多具有位置透明性(無需知道組件的位置)的組件構成，可以很容易實現(xiàn)分布式應用。組件架構強調實現(xiàn)對象模型，開發(fā)接口是基于對象的，符合用戶的思維方式，比動態(tài)庫提供的API，更易于理解，使用。組件是完全與語言無關的,任何過程性語言夠可以用來開發(fā)組件，根據(jù)不同的需求，可以輕易的用不同語言開發(fā)應用程序的不同部分，用戶可以選擇任何過程性語言做二次開發(fā)。通過COM的底層機制，可以訪問運行中的應用程序對象，實現(xiàn)與運行中程序交換數(shù)據(jù)。用戶組件也可以易于嵌入應用程序中。COM的主要問題是，運行速度比動態(tài)庫慢，特別是自動化接口；對系統(tǒng)穩(wěn)定性要求高于動態(tài)庫，要求系統(tǒng)的COM平臺能正常工作。最常用也是最安全，成本最低的接口方式是中間文件接口。雙方的數(shù)據(jù)交流通過中間文件進行。這種方式由于比較靈活，接口雙方都比較明確工作。而且重要是的，接口雙方的軟件升級，對于接口本身(對方軟件本身)可以說沒有影響。是目前采用較多的接口方式。如果是中間文件的還需要確定是全量式接口還是增量式接口。接口本身是為了雙方數(shù)據(jù)可以保持交流和數(shù)據(jù)一致性進行的。一方提供數(shù)據(jù)，另一方根據(jù)對方的數(shù)據(jù)來更新自己的系統(tǒng)的數(shù)據(jù)。所以對于哪些信息是新加，哪些是刪，哪些是更新要進行判斷。從數(shù)據(jù)提供方而言可以提供以下幾種：全量：按軟件數(shù)據(jù)內的數(shù)據(jù)提供全部的數(shù)據(jù)，不進行區(qū)分哪些是增，哪些是刪。這種方式需要用戶對比自己內部的數(shù)據(jù)進行區(qū)分哪些是增，哪些是刪。增量：由數(shù)據(jù)提供方進行對比后，區(qū)分哪些數(shù)據(jù)是要更改的，哪些是要刪除的。對方軟件根據(jù)數(shù)據(jù)提供方提供的文件直接更新數(shù)據(jù)庫。這種方式的重點是要掌握同什么數(shù)據(jù)對比，得出增減記錄。另外，對不不同的記錄(增/減記錄)是提供不同的文件，還是在同一文件內對于不同的記錄做上標記也是要定義的。此時可能就要在接口字段上定義更改標識，更改單號，版本號等信息。 接口調研背景知識(下) 接口內容接口方式一旦確定，就需要確定接口的內容。接口內容首先要確定接口入口，從哪里開始匯總接口數(shù)據(jù)，接口數(shù)據(jù)每次包含多少對象，這些對象是如何聯(lián)系在一起的。例如接口數(shù)據(jù)每次都從一個完整的產(chǎn)品上開始匯總，或者從一個完整的工程任務上開始匯總，或者從任意零部件上都可以發(fā)起匯總。第二接口內容要確定接口時機，要明確哪些字段由數(shù)據(jù)提供方(其它系統(tǒng))寫，那些讀，在什么時候進行。也就是約定當數(shù)據(jù)達到怎樣的規(guī)定后才可以啟動接口輸出，此時也可以約定接口輸出負責人員。例如當產(chǎn)品結構發(fā)布，相關工藝數(shù)據(jù)也發(fā)布后才能啟動接口，如果有明確接口時機要求，接口程序應適當做校驗性判斷，防止提供不正確的數(shù)據(jù)給下游系統(tǒng)。第三接口內容要確定接口格式。接口格式包括明確數(shù)據(jù)交換提交的方式：是文件級還是數(shù)據(jù)庫級，然后明確交換文件的名字，存盤路徑。明確文件的格式，包括文件或數(shù)據(jù)表包含的字段名，字段次序，字段類型，字段長度，分隔符(如是文本文件)，是否必填，默認值，下游系統(tǒng)對應含義，實際數(shù)據(jù)樣例，接口對應數(shù)據(jù)來源，該字段在實際操作中填寫規(guī)則。第三接口內容要確定接口樣例。接口技術協(xié)議附件必須包括用戶方提供的樣例數(shù)據(jù)，樣例數(shù)據(jù)必須具備典型特性，能夠覆蓋企業(yè)各種可能的實際數(shù)據(jù)情況，保證驗證樣例數(shù)據(jù)對接口測試的完整性；如果一個樣例不能覆蓋可以提供足夠樣例數(shù)據(jù)，用戶方可提供多個樣例，直到可覆蓋各種可能情況為止。用戶方要保證樣例數(shù)據(jù)的規(guī)范性。此時可能還需要針對接口樣例提供數(shù)據(jù)規(guī)范性錄入操作說明。依據(jù)所提供樣例最終得到的接口中間文件將以完整實例作為驗證標準依據(jù)。如果有多個樣例，則需提供多個完整的接口中間文件實例。準備接口樣例將大大加快驗證時間和接口程序調整反復時間，也有利于企業(yè)，供應商快速就接口協(xié)議達成一致性理解，是看起來慢，實際上最快的有效接口方式。 接口數(shù)據(jù)一致性握手方式接口數(shù)據(jù)的一致性通握手方式來保障。一致性分為靜態(tài)一致性，動態(tài)一致性，雙向一致性。靜態(tài)一致性：如物料編碼信息，原始工藝設計信息。動態(tài)一致性：如設計更改信息，在一個系統(tǒng)內的數(shù)據(jù)更新后，要求另一個系統(tǒng)內的數(shù)據(jù)也要進行相應的處理。握手方式即明確如何讓對方系統(tǒng)得到要進行更改的信息(也可能是依靠人員來進行手工操作)，這樣對方系統(tǒng)對接口文件進行處理。雙向一致性：復雜的系統(tǒng)甚至要求，對方系統(tǒng)處理的數(shù)據(jù)結果要進行反饋。從而更新本身系統(tǒng)的數(shù)據(jù)。這里面也要對反饋進行定義。 調研后續(xù)工作落實階段 如何寫業(yè)務調研報告調研結束后第一個必須盡快整理出業(yè)務調研報告，業(yè)務調研報告主體內容可以在業(yè)務分析會上得到用戶確認。寫業(yè)務調研報告應該結合軟件供應商特點形成一個比較統(tǒng)一的匯報目錄模板，有了模板整理起來就快，不同軟件關心業(yè)務內容不同，模板也應該不一樣。一般而言業(yè)務調研報告目錄可以分為三個大的部分，第一部分是業(yè)務基本情況介紹，第二部分是企業(yè)業(yè)務流程圖和數(shù)據(jù)流圖，第三部分是項目關鍵價值點。凡是不設計業(yè)務流和數(shù)據(jù)流，但必須要描述的內容，例如企業(yè)的一些基礎數(shù)據(jù)情況，我們把其作為企業(yè)的基本情況介紹，例如企業(yè)概況，企業(yè)設計數(shù)據(jù)統(tǒng)計情況，企業(yè)工藝數(shù)據(jù)統(tǒng)計情況，企業(yè)標準化編碼規(guī)定等等，做基本情況介紹時要把握兩個原則：第一是結構化，不要散亂，將相關性強的一組基本情況設計成表格填寫，這樣既方便填寫，又不容易遺漏。第二是按照調研先后順序組織，和業(yè)務流順序盡量一致。這樣不但層次清晰，而且可以直接將每天調研日志內容復制修改就可以得到最終結果，大大提高工作效率。業(yè)務流程圖和數(shù)據(jù)流圖有大量標準工具和方法指導，建議這里大家去找相關專門知識學習，本文不在這里展開。第三部分項目關鍵價值點是非常重要的，項目價值點組織也必須符合結構化層次，不要將很大的價值和很小的價值并列排放，應該將最大的價值，可以相互獨立做為一層，然后將小價值分別歸類到不同大價值下，形成一個價值支撐體系，這個支撐體系也是解決方案的實現(xiàn)思路。 業(yè)務調研報告完成后續(xù)工作業(yè)務調研報告完成后必須趕緊去找后續(xù)工作同伴，按照約定的工作計劃把調研報告交給他們，如果有時間，還可以安排一個內部業(yè)務分析會議，做一個全面的介紹。幫助團隊成員可以準確理解調研報告，啟動后續(xù)工作才是一個調研的工作結束。如果你能按照以上方法進行調研，相信你的調研質量一定很棒，這樣的話，不管后續(xù)工作是什么，我相信你都會得心應手的去完成，或者幫助你的團隊成員去完成。這也就是調研最大樂趣所在。如何寫解決方案？ 解決方案難寫在哪里？ 3 如何寫解決方案？ 解決方案難寫在哪里？很多人對寫方案非常沒有信心，一涉及到方案的事情，就束手無策，到處求人。作為一個公認的方案打手，意思是寫方案就象打字員一樣，我覺得我在這方面確實是有絕活。我基本上都是在方案提交前一兩天接到寫方案的任務，而我自己的事情一般又比別人多一點，也不能不做，只好心里大罵一句，罵完后就打電話搞清楚別人的要求，邊問就邊構思整個方案的推導思路和結構提綱。因為你不敢讓你的同事知道你只能用很少的一點時間寫方案(基本上我真正動筆寫方案的時間都在2~4個小時以內)，讓他們擔心方案的質量和進度保證，進而對自己的后續(xù)工作質量沒有信心。所以我其實也特別緊張，注意力也特別集中，大腦也高速反應，基本上幾分鐘電話或面談完思路基本就有了，然后該干嘛干嘛，找一些零散的小時間把思路不斷推導一下，然后到了一個比較安靜和完整的時間段前才開始寫，這個時候基本上要寫的話都想清楚了，只需要不斷敲字，敲字的時候也是注意力也特別集中，大腦也高速反應，越寫思路越開，很快也就完工了。寫方案不難，知道怎么寫才難。關于寫方案我只總結一點，結構化地去組織你的思想。有結構就有思路，有思路就有方案。另外真正寫方案的人，對自己寫過的方案是永遠不會滿意的，只有這樣，每次都會進步一點點，解決方案水平質量就會隨公司能力不斷增長。當然我曾經(jīng)問過很多人，你到底為什么寫不出好的方案呢？基本上原因可以歸為四類： 第一種是沒有體系一旦用戶要求提供關于PDM的方案，很多人大腦是一片空白，完全不知道從哪里下手。很多人說起自己的產(chǎn)品來，好象知道不少賣點，不過真要寫出來，又覺得無從下筆。這種情況一般是寫方案者不熟悉自己產(chǎn)品體系造成的，知道一兩個甚至更多的產(chǎn)品賣點不難，但難就難在成體系，知識就是成體系的點構成的，而不是一句一句離散的說法構成的。因為我們這個行業(yè)從業(yè)人員說句不客氣的話，大部分對所銷售實施的管理系統(tǒng)并沒有很深入的研究，都是半路出家，從頭開始，在學習過程中熟悉，在熟悉過程中領悟。所以一下子去駕馭一個整體方案是很痛苦的。只有當一個人對一個產(chǎn)品思路有體系以后，才能夠寫出完整的方案，否則就是一個單元也要費盡腦汁。所以一個人要想寫好一個方案，首先要把自己產(chǎn)品的來龍去脈，功能模塊，適應領域，典型客戶實施情況有一個全面的了解，這樣才能建立一個完整的知識體系，然后逐步補充競爭對手知識和一些技術性知識，不斷深化自己的知識體系。 第二種是沒有思路有很多用戶看多了模板化的方案以后，想看一些針對他們自己的業(yè)務的個性化內容，這個時候有的人按照標準方案模板修改還勉強能對付，但對于個性化內容針對性方案就速手無策了。這種情況從根本上講還是寫方案者不熟悉企業(yè)業(yè)務造成的，寫方案，特別是針對性方案不僅僅要求了解企業(yè)的需求，而且要知道這些需求是在何種業(yè)務需求下產(chǎn)生的，用戶提出這樣的要求到底想解決什么問題，把這個問題找出來，一般針對性解決思路就有了，有