不管是有經驗的還是說初事這一行業的，在數字化系統建設過程當中，我們總是要進行需求調研的，怎么能夠快速準確地把握住企業的真正需求，還是有一些需要注意的地方的。本文不是一個全面系統的需求調研步驟，而更多的是偏重于一些注意要點，是自己的經驗感觸比較深的幾個方面吧。
（1）摒棄成見，拋掉既往的包袱。
一般受制于自己的既往經驗，或者說是已有的系統基礎，或者說實踐的經歷，乃至自己的知識基礎，調研過程當中最大的一個問題就是帶有成見或者帶有一種既有的慣性思維，最容易犯的錯誤，就是認為企業應該是什么樣子。
尤其是看了一些書之后，所獲得的一些知識與實際存在很大的不同。這些書本的知識，一般從教學或者著作的角度，為了將問題能夠講清楚，一般都是做了大量的假設，或者說是進行了較為明確的分條描述。但一般來說實際的問題要復雜的多，這些知識是遠遠不夠的。
比如APS，筆者這么多年所經歷的經驗表明，書本上的任何一種假設，在實際當中基本都有被推翻的場景。
說這些不是說書本的知識或者經驗不重要。而是說千萬不能抱著這些來進行需求調研。這種調研很大程度上，一方面是調研的不夠細致和深入，另外一個方面就是調研的結果，甚至是錯誤的。
（2）問題導向與目標驅動。
進行需求調研，雖然現狀的需求是很必要的，但是我們一定要秉持問題導向與目標驅動。
這個其實是說任何數字化系統的建設是一定要帶來效果的，而這些效果就是企業的問題的解決，而效果想要達到的程度，其實就是企業的目標。
對于問題導向其實就是要聚焦主題，抓住企業的瓶頸、痛點和難點，并且深入分析，導致這些瓶頸痛點難點產生的根本原因是什么？再進一步的深入挖掘。
而對于目標驅動。其實涉及到自上而下的指標分解，明確這些指標與哪些業務流程或業務環節緩解密切相關？再進一步的深入挖掘。
（3）直指問題的技術求解的本質。
我們在進行需求調研的時候，如果能夠具備在現場基于企業的問題，快速的在心里形成技術解決方案，這是我們希望的一個局面。這樣的話才能夠快速地衍生出進步的調研問題話頭，才能無需全面細致的挖掘出企業的問題需求。
但這里說的解決方案并不是最終的技術方案，一般來說，這種技術方案是需要基于需求調研的信息和資料，從業務場景和軟件技術兩個方面，進一步綜合細化才能夠形成的。
這里更多的是強調對于問題驅動的內部求解機制。比如對于APS來說，其本質是作業或任務與資源在時間維度上的配置。比如對于MES來說了，其本質是制造要素與訂單主線和工業流程主線的關聯關系，以及基于精益、敏捷、并行等思想在其中的落實。
如果不能從本質的角度來進行問題求解的思考，那可能了解到的只是一些特例，而不是企業真正想要解決的問題。
（4）現狀業務運行的全面細節理解。
我們經常說現場有神明，其實對現狀業務的深刻理解是進行數字化系統建設的基礎，而這種深刻理解一定要體現在細節方面。
對企業來說，我們要想辦法能夠引導對方將所有的細節表達出來。
這就要求在進行現場調研的時候，具有隨機應變的思維方式，就類似思維導圖一樣，不放過任何一條分支和蛛絲馬跡，就如同數據挖掘一樣一直向下挖掘，應該具有刨根問底的精神以及皰丁解牛的思想。
同時要一直在頭腦里面構建他們的現狀圖景，讓這些細節有機地組織起來，而這種組織最常用的方式就是按照業務流程主線來展開，而這些細節就是在填充和完善流程當中的各個環節。
是否已經對現狀進行了充分了解了，檢驗的標準就是：能夠用企業的語言跟企業的人員再復述一遍。當你能夠不結巴的情況下，非常順暢的將業務場景說清楚，包括各種細節，基本上你就做到了自圓其說，而如果再能夠得到企業的認可，就說明調研的還是比較充分的。
………………………………
寫這篇文章的一個目的主要是因為近期安排了多支團隊進行MES和APS業務需求的調研，每次都要給他們進行一些深入的討論，以便下次或者第2天能夠進行更加深入的調研，以便能夠提高調研的完整性和有效性。所以寫出來一點東西，算是一種總結吧。