精品文檔-下載后可編輯深“入”淺“出”談需求要想做好企業信息化建設的需求調研，必須既要能“鉆進去”，又要能“跳出來”。

需求是信息化的基礎，企業在規劃信息化建設時，必須清楚自己的根本需求是什么，是想提高效率，還是優化流程，或是加強管理；在進行具體的系統選型和調研時，必須關注具體的業務現狀和改進需求，還要注意發現隱藏在表象之下的潛在需求，只有全面了解各方的真實需求，才能確保系統實施之后可以滿足企業的需要。

簡單點說，就是在整體規劃時要“跳出來”，把握最根本的目的和動機，了解細節背后的真實想法，從局限思維中“跳”出來，站在企業的高度去設計和規劃整個企業的信息化藍圖。

再說“鉆進去”，信息化的大方向確定之后，隨之而來的就是具體的應用系統建設，需要細致深入的了解和掌握用戶的實際需求，把所有可能的潛在需求點挖掘出來，等于是為系統的實施和上線掃清了障礙，為系統的穩定運行打好了基礎。鍥而不舍的“鉆”

某天下午，銷售部的小王和信息部的小張在會議室里正在討論調研中的商務系統需求。

小王：“這是訂購申請的界面格式，我希望各分公司的下單員進入系統后，系統能自動識別他們的分公司和可選的產品，然后通過指定一級大類、二級小類來選擇產品編碼，填寫本次的下單數量。我還想讓系統自動生成單價，可以嗎？”

小張：“單價是根據什么條件確定的，是產品編碼嗎？”小王：“是的，我想能自己來維護，不同的編碼會有不同的促銷價格。如果系統也能自動算出總價，就用單價×數量，數量就用訂購數量計算好了?！?/p>

小張（有點奇怪）：“訂購數量？難道還有別的數量？不是只有一個本次的下單數量嗎？”

小王（愣了一下）：“哎？還有我們返給分公司的贈送數量啊，不同時段的贈送品種和數量都不一樣的，這個最好也能讓我來維護?！?/p>

小張（嘆氣）：“好吧，也就是說，分公司最后拿到的產品數量是他付錢訂購的數量，也就是本次的下單數量，再加上我們贈送的數量，對吧？那這個贈送的數量根據什么來算呢？是產品編碼？還是下單數量？”

小王：“嗯，每個產品編碼根據不同的下單數量，返的數量也不同。比如分公司訂100個A產品，我們返他10%，訂1000個，返180個。但也不全是按訂購范圍來返，有時候小于100的返10%，等于100的返15個，是按階梯來的。”小張（考慮了一會）：“總之就是由你們維護一個數量范圍，也就是階梯，然后針對每個階梯給出返給分公司的數量或者百分比，對吧？”

小王（點頭）：“對的對的，返贈數量按階梯走，單價也是?！?/p>

小張（冒汗）：“還有單價？每個產品編碼的單價不是固定的嗎？”

小王：“是固定的，不同階梯的價格是固定的?！?/p>

小張（無奈）：“那就是說，單價和返贈數量一樣，都是按階梯確定，比如1～100個是1塊錢，100個是8毛錢，101～200個是7毛錢，是不是這樣的？”小王（使勁點頭）：“就是這個意思！”能看得出小王對這個流程已經十分熟悉，所以，按照訂購數量確定單價和返贈數量的規定，對他來說就像吃飯呼吸一樣不言自明。但是對于小張則不然，如果沒有特殊說明，他不會想到還有返贈數量，更不會想到單價還要與訂購數量掛鉤。如果不是小張敏銳地察覺到小王的弦外之音，這個隱含的需求點很可能就悄悄地潛伏起來了，而等到系統上線后再發現，想改動就不是那么簡單了。

所以，無論進行調研的系統其規模大小、重要程度和使用部門如何，在軟件選型或者系統開發之前，都應該進行細致全面的需求調研，盡量發現業務操作中隱含的、關鍵的、容易被忽略的需求點，無論用戶是否把它當作重點。

很多時候，用戶所關心的問題也許并不是系統實現時的難點，反而是那些長期積淀下來對業務起著關鍵作用的、有著高度的靈活性、復雜性和多樣性的啟發式規則，因為比較接近人腦的思考模式，所以偏重邏輯運算的計算機系統并不擅長處理?？倲埲值摹疤?/p>

還是在同一間會議室，小王正在給小張解釋銷售部針對分公司提交上來的訂購申請的審核流程。

小王：“我希望訂購申請的審核界面能把所有待審核的產品都列出來，讓我們選擇通過或者駁回……”

小張：“好吧。那么，你在審核的時候，通常是一個一個過，還是幾個產品一起過？”

小王：“嗯，一個一個過，通過的產品就轉到分配庫位的步驟，如果是駁回的，就讓分公司重新修改，但是廢除的訂單就不能再改了?！?/p>

小張：“除了通過和駁回，還有廢除？那廢除和駁回的訂單有什么區別？”

小王：“廢除的不能再修改，但是可以查詢到。駁回的可以修改后重新提交?！?/p>

小張：“那如果訂單包含多個產品，你們怎么駁回？”

小王（有點遲疑）：“就是，把單個產品駁回去……”

小張：“如果某張訂單有兩個產品，你通過一個，駁回一個，那訂單的狀態是算‘通過’還是算‘駁回’？是該由分公司修改還是進入下一個審批環節？修改的時候已經通過的產品還讓不讓分公司改？還有，如果分公司修改了被駁回的產品，是要重新經過你的審核，還是跟那個通過的產品一起進入下一步審批？”小王（擦汗）：“這些我還真沒仔細想過……”

小張：“從系統的角度來說，包含多個產品的單據審核，只要有一個產品沒通過就把整單都駁回去，等修改后重新提交，再進行整單的通過和駁回。當然，需要對產品進行單獨管理的情況除外，你們的訂購申請有這方面的管理要求嗎？”小王搖頭：“沒有，我們出庫的時候都是按訂單發貨，沒有拆開來出庫的。”小張點點頭：“那我還是建議對整張訂單進行通過、駁回和廢除，既方便訂單的控制也便于實際操作?！毙⊥酰骸斑€是你們專業，那就按整單走吧！”

具體的業務人員對本職工作的熟悉程度毋庸置疑，但這種熟悉也從某種程度上限制了他們的思維模式，使他們局限于自己的視角看問題，無法對流程的整體進行思考。但是，應用系統并不僅僅是為了減輕某個人、某個部門的工作強度而設計的，不可能只滿足部分人的需要，必須從整個流程的角度去衡量，因此必須跳出個人和部門的局限，系統地規劃信息化建設的方案。比如案例中的小王，他對系統提出的

要求就是以自己的工作習慣為依據的。但是由于過于拘泥細節，并沒有對審核背后的目的和要求多做考量，他了解的只是自己的日常工作，對單據流轉的流程整體和目的了解不多。所以，當小張問他如果按單個產品駁回后出現的各種情形該如何處理時，小王冒汗了。

小張根據以往的