最近藍蘭集團信息中心主任張成又遇到了一個新問題，公司剛剛啟動了一個信息化新項目，就是內部供應鏈的項目，各個制造實體的訂單管理將統一在一個操作平臺上進行。
通過這個平臺，董事長魏武期望集團統一接單，然后將訂單分派給集團內部汽車配件制造實體-藍蘭氣泵制造有限公司、藍蘭汽車橡膠制品制造有限公司、藍蘭汽車軸承制造有限公司等五個公司以及正在不斷擴大的外部供應商。
"需求調研"惹起的禍端
這個戰略意圖我們不去討論它。現在的問題是，為了穩妥起見，魏武要求，先拿生產當家產品的藍蘭氣泵制造有限公司做試點，第一建造一個統一平臺，第二將氣泵的內部供應鏈做透，以方便客戶、業務代表檢查和監督訂單執行的各個環節。
張成已經和南方管理軟件公司確定了通過對南方管理軟件ERP的E3（15.2）版本進行適應性改造，以適應內部供應鏈的要求。也就是在基礎數據的管理上，以E3為基準，ERP的模塊功能按照訂單的執行過程進行整合，最后進行適當的二次開發。
按照計劃，2006年8月上旬南方公司將派華東大區的咨詢顧問來項目現場進行為期半個月的現場需求調研，這時問題出現了。
最早在簽約的時候，張成曾經和軟件公司討論過，需求調研由顧問按照提綱進行訪問，然后整理出文檔供確認。現在對方的項目經理李封來郵件說，將由顧問到現場對業務部門的需求責任人（大部分是管理人員）進行"模塊需求規格說明書"編寫的培訓，然后顧問用四天時間對大家提交的需求規格說明書進行批改。最后將收集上來的資料帶回華東大區，由乙方項目組進行集中梳理并與標準產品進行匹配，看差距在哪里，然后確定實施與開發任務。
"馬蹄"焉能"牛蹄"補
張成對整個計劃沒有特別疑問，這個安排還是比較符合一般項目的做法，但有一點是需求說明全部由業務部門來寫，效果能不能得到保證？張成見過南方公司提供的"模塊需求規格說明書"，完全是需求分析師、系統設計師才能寫出來的東西，有許多專業的表達方式，他自己對許多詞語還搞不透。
藍蘭氣泵制造有限公司的管理干部大部分是老員工，許多人勉強能打字，查查報表，現在要畫流程圖，說明字段輸入輸出規范、系統關聯等這樣的文章實在是勉為其難，一天的培訓很難讓大家有這樣的轉變，估計實際的調研進度將要大受影響。
他把這個顧慮告訴李封時，李封說，這其實也是為張成好，業務部門按照這個規范寫出來的東西，他們確認后，可以直接給需求分析與程序開發人員使用，減少了中間環節，提高項目效率，也明確了責任，將來，他們有需求變更也有明確的依據。張成琢磨，這樣是不是算是"下套"？-你看，從最基層到項目組都承認了這個需求，藍蘭公司與南方公司的契約也就更清楚了，將來有什么問題，難道還找李封？
當然張成擔心的主要還不是對方是不是"下套"，而是當前這樣的表達方式是不是能真切地表達項目需求，會不會因為表達方式的原因使基層的管理需求無法呈現，或者出現類似"精確的錯誤"這樣的東西。
為此他向李封嚴正提出，由雙方項目組人員聯合成立模塊需求規格說明編寫小組，分工到具體部門組織編寫。但是李封堅決不同意。眼看調研時間就到，藍蘭公司應該怎么做？如果按照李封的做法，應該做什么準備？李封堅持這樣做，到底有什么道理？有一個什么妥協的辦法嗎？張成迫切想知道。
◎ 點評專家
張欣 北京大學聯泰供應鏈研究與發展中心執行副主任
繹明宇博士 賽迪顧問項目咨詢總監
王磊 IDS Scheer中國副總裁
張振坤 凌云科技集團有限責任公司信息管理中心主任
張欣 北京大學聯泰供應鏈研究與發展中心執行副主任
在回答案例提出的問題之前，我們必須了解與需求分析有關的一些基本理論問題。
提前做好"功課"很必要
首先，了解需求分析的重要意義。其一，需求分析是企業IT建設的一個基本環節，是聯結企業IT規劃和IT實施的重要紐帶或橋梁；其二，需求分析是企業IT戰略的詳細表述，也是IT價值的根本所在；其三，需求分析是企業的一次管理改進過程。
其次，了解需求分析的演化趨勢。我們經常討論企業信息化失敗的比例有多高。其中一個很主要的原因就是需求分析沒做好。一種情況是IT項目甲乙雙方由于知識、能力、策略或管理等方面的問題未能做到無縫溝通。
另一種情況是，盡管甲乙雙方溝通不錯，但需求分析或許只是對管理現狀的一次簡單呈現，未能解決企業管理方面存在的根本問題，或是提得過于理想，導致項目過于復雜，實施周期過長，最終讓雙方喪失信心。
這些問題推動了需求分析的方式方法發生演化：一是IT服務方的需求分析責任人越來越多地由管理顧問來擔任；二是IT項目雙方合作得越來越緊密；三是隨著質量管理、項目管理技術的應用，需求分析變得越來越規范；四是隨著軟件工程理論的發展，需求分析的方法論也發生重大變化。比如，引入OOAD（對象導向分析設計）思想并結合UML為業務需求建模。
再者，了解需求分析的主要內容和實施步驟。需求分析主要涉及功能性需求與非功能性需求兩類，并以功能性需求為主。
一個需求分析詳細回答三個方面的問題：一是企業的現狀是什么（As-Is）；二是企業IT建設的目標是什么（To-Be）；三是從現狀到達目的的最佳途徑（方案）是什么（Best Solution）。那么，如何完成上述三個方面的準備呢？
首先，我們要了解需求分析的范圍。一是功能范圍。是一個ERP系統，還是一個獨立的財務管理系統？二是業務范圍。比如，一個管理會計功能模塊可能只用在整車制造環節，也可能覆蓋全部零配件制造環節。三是機構和人員范圍。一個會計核算系統可以只要財務部門負責數據維護，也可以開放一些數據接口給生產、采購、倉儲等部門。
其次，確定需求分析的層次。需求分析主要有兩個層次，一是面向系統開發的需求分析（要變更或改進，需要較大的工作量。）；二是面向系統配置的需求分析（變更或改進相對較容易些）。
再者，確定需求分析的模式（方法論）。需求分析的模式受三個因素影響：編制需求分析的指導思想、編制需求分析的工具、軟件服務企業的質量管理體系和項目管理體系。
了解了IT項目需求分析的范圍、層次、模式之后，我們再結合項目甲乙雙方的知識和能力作出判斷，有時可能需要第三方的協助。
要占取主動地位
再回到藍蘭集團的案例上來，那么，需求分析究竟該誰來做？
1、案例中提到，"在簽約的時候，曾經和軟件公司討論過，需求調研由顧問按照提綱進行訪問，然后整理出文檔供（甲方）確認"。那么，既然已有合同約定（包括口頭約定），雙方就應該按照約定的方式和步驟實施需求分析。
2、如果事先的約定可以變更，那么，我們再來看李封的建議。可見，其中存在幾個重大的邏輯缺陷：首先，如果顧問只是到現場對業務部門的需求責任人進行"模塊需求規格說明書"編寫培訓，那么，就無法對藍蘭企業做深入了解；其次，短暫培訓是否就能讓藍蘭公司的需求責任人員具備編寫需求分析的能力值得懷疑。
另外，李封說，"顧問用四天時間對提交的需求規格說明書進行批改。"那么，乙方顧問根本沒有對甲方進行過詳細調查，怎么能在四天內完成對甲方需求的批改呢？最后，對甲方需求與乙方標準產品之間的"差距"，是更改甲方需求，還是更改產品來彌補？也難有定論！
3、針對這種情況，藍蘭公司不能讓本來的主動地位變成被動，更不能在需求分析環節失去把握能力。而應該依據筆者提出的分析模型或其它類似的分析方法對自己和乙方的知識、經驗以及承擔需求分析責任的能力做出判斷，并據此來決定是接受還是否定李封的建議，甚至，當認為對方的知識、經驗、能力和責任心值得懷疑時，還可以取消與乙方的合作。
明確合作雙方的責任細節
繹明宇博士 賽迪顧問項目咨詢總監
藍蘭集團遇到的問題是企業在信息化建設過程中很常見的問題，主要原因是由于甲乙雙方在項目合作簽訂過程中，對一些細節的工作責任沒有明顯地界定而導致的。由于藍蘭集團是傳統企業，對信息化工程的過程和內容均不太熟悉，所以往往就會出現前期工作沒有考慮到的問題出現。
要回答業務需求分析工作應由哪方來承擔，就首先搞清楚信息化工程的內容，以及業務需求分析工作在整體信息化工程中的位置，這樣才能明確此工作應由誰來完成。
一般來說，一個信息化工程包括前期的系統分析、中期的系統實施、后期的系統運維與優化工作，其中本案例中引發甲乙雙方矛盾的"模塊需求規格說明書（不同企業對此有不同的稱謂）"屬于前期工作（系統分析工作）的內容。
系統分析工作包括業務需求分析和應用系統分析兩大部分，這兩者的關系是根據企業業務現狀以及信息技術特點而演化出來的新的業務需求（也就是業務流程重組或優化結果），推導出為信息系統所能識別的軟件功能模塊及其相互關系（應用軟件運作模型）。也就是說，業務需求分析是業務分析（也包括管理分析）過程，而應用系統分析是軟件"編譯"過程。
業務分析過程對于整個企業信息化過程有著關鍵的導向作用。分兩個階段工作，首先是企業供應鏈管理的現狀描述過程，其次是企業供應鏈管理模式優化和重組過程，前者也是后者的前提和基礎。
對于"模塊需求規格說明書"的內容的界定首先就要指明，它只是包括企業供應鏈管理的現狀描述過程，還是包含整個業務分析過程。
如果它只是企業供應鏈管理的現狀描述過程，那么藍蘭集團供應鏈系統分析過程只進行了第一步，還需有第二步的工作，也就是說，還需要二次需求確認環節。如果它包含了整個業務分析過程，則單靠藍蘭集團現有人員的技術力量顯然是不現實的。所以，我們可以把"模塊需求規格說明書"的內容的界定為藍蘭集團供應鏈管理的現狀描述過程。
有了這個前提，才能引出藍蘭集團供應鏈管理現狀描述工作承擔者的問題。實際上，對于企業信息化系統分析工作，并沒有統一的模式。有時是甲方企業來承擔，有時是乙方軟件商（或集成商）來承擔，有時是第三方信息化咨詢公司來承擔，另外，在實際操作中過程中，往往是這甲乙雙方，或甲丙雙方聯合承擔。張成希望甲乙雙方聯合項目組的方式，而李封是甲方企業承擔模式，只不過乙方在其間給予部分技術支持。
由于雙方存在著明顯的信息不對稱現象，所以應在雙方簽署合作協議時，由乙方向甲方提出，以供甲方根據自身的條件進行選擇和確定。
本案例中，顯然乙方并沒有提出工作承擔者問題，以致在合同簽訂后，引發出不必要的麻煩，因而總得來說，這造成此麻煩的責任在于南方管理軟件公司。
如果合同中約定了"需求調研由顧問按照提綱進行訪問，然后整理出文檔供確認"，則李封提出甲方承擔的模式顯然就是違約（因為這種改變會涉及到前期業務分析過程工作量的巨大變化），藍蘭集團有權提出中止合同，或要求南方管理軟件公司履約。如果在合同中沒有寫明"模塊需求規格說明書"由哪方來承擔，則甲乙雙方需重新進行協調，主要是測算工作量，以及重新確定合同金額（重簽合作）。
另外，由于南方管理軟件公司的項目經理對于此麻煩的產生有不可推卸的責任，而這種提醒工作是信息化工程中的常識性工作，乙方項目經理沒有做的原因只有兩種可能，其一是故意混淆概念，模糊工作量；其二就是沒有此方面的工作經驗。
不論是哪一種情況，對于藍蘭集團供應鏈管理系統的建設來說，都將是一種潛在的風險。因而，藍蘭集團可以直接向南方管理軟件公司提出更換其項目經理的要求，也就不存在"妥協的辦法"的問題了。
乙方并沒有提出工作承擔者問題，以致在合同簽訂后，引發出不必要的麻煩。
用"好工具"整合業務與技術需求
王磊 IDS Scheer中國副總裁
業務需求描述的環節，是一個信息化項目得以順利進行的基礎。而在眾多項目中，該環節往往會出現前期業務需求的描述不夠明確，從而導致項目后期不斷變更需求設計的情況。
在項目中，對于業務需求的描述往往是由精通業務的人員進行的，但這部分人員通常又是企業內部最為忙碌的人員。因此，在描述業務需求時由于不能有充足的時間來反復斟酌，從而使得所描述的需求比較粗糙。
另外，咨詢顧問要求業務人員用來描述業務需求的工具太過專業，使得業務人員無法用這些工具來很好地表達自已的想法。
比如，傳統的做法是先畫流程圖再填需求調研表，這種畫圖加填表的方式等于是將基于業務需求梳理軟件開發思路的工作全部交給了業務人員，這對于以業務操作為主很少接觸信息化管理系統的人員來說，確實是勉為其難的。
正是由于上述情況，所以又會經常出現在項目后期業務人員不斷提出新的業務需求或不斷變更業務需求的情況，從而給咨詢公司順利完成系統的開發和配置帶來很大的壓力。
針對上述情況，筆者認為由業務人員進行需求描述這一點應該是要堅持的一個方向。咨詢顧問通過調研整理出業務需求并請業務人員進行確認的做法，其準確性和完整性被大量實踐證明是很差的。
問題的關鍵是應該給業務人員提供一個很好的工作平臺，在這個平臺上業務人員能夠用業務的語言比較高效地進行需求的描述。而這種用業務語言描述出來的業務需求又能自動轉成IT人員所要的技術信息，以便于咨詢公司進行系統的開發或配置。
那么需要給業務人員提供一個什么樣的業務需求描述工具呢？筆者認為，這個工具平臺應該采用業務人員的工作語言。比如，描述一個業務流程，業務人員只要講清楚做什么事，誰來做，目前需要用到什么樣的數據或表單等即可，不用涉及專業的技術術語和概念。
但為了今后能基于此導出IT人員需要的信息，因此對于這些業務要素的描述應建立統一、標準、圖形化的流程描述語言、方法和標準。比如，流程的操作、執行者、輸入輸出等要素的表達符號、形狀、視圖格式、關聯邏輯等都應該有一個統一的規范和標準，流程要素的定義無二義性。
總而言之，應該有一套用業務語言統一起來的業務需求描述的建模規范，這套規范起到了聯系業務人員與咨詢顧問的作用，使得業務人員可以用自已的語言進行需求的描述，而咨詢顧問又可以基于此得到所要的技術信息。
IDS Scheer 公司的創始人希爾教授早在上世紀八十年代就提出了將業務語言與技術語言相結合的ARIS業務流程描述規則。經過20多年的發展，ARIS業務流程描述的房式結構已經成為一種業界的規范和標準，被大量的企業所采用。
那么，有了一個好的工作平臺后，是不是對于業務需求描述的責任全在業務人員呢？筆者認為，以業務人員為主進行業務需求描述是需要堅持的一種做法，但這并不意味著咨詢顧問只是起一個收集和分析信息的作用。在業務人員進行需求描述的過程中，咨詢顧問是應該全程參與其中的，咨詢顧問應該起到一個指導和共同梳理的作用。
從某種意義上來說，是雙方共同完成業務需求的描述。筆者反對的是傳統的由咨詢顧問對業務人員進行調研，然后由咨詢顧問出具需求分析并請業務人員進行確認的作業方式。這種作業方式，由于業務人員往往只是動動嘴，因此對于需求的描述肯定是不夠全面和深入的，這樣必然會導致后期需求的大量變更。
綜上所述，在管理信息化建設過程中，對于業務需求的描述應是由業務人員為主來進行，但同時應該給業務人員提供一個很好的工作平臺，而且咨詢顧問也應全程參與并起到指導作用。
應該有一套用業務語言統一起來的業務需求描述的建模規范，而咨詢顧問又可以基于此得到所要的技術信息。
信息中心應是需求分析的主角
張振坤 凌云科技集團有限責任公司信息管理中心主任
準確分析各角色心態
在信息化建設的需求分析過程中，有幾個主要的角色必須明確：
首先是企業的一把手。他的意圖必須要搞清楚：上信息化項目的目的是什么，究竟要解決什么問題，什么因素促使他對信息化項目產生了興趣。
老板既然有心想搞信息化，必定有其直接的原因。當信息系統最終偏離或達不到老板的意圖時，信息化就不可能說是取得了成功。
當然，也會有無心插柳柳成蔭的效果，就是說雖然沒達到預期的效果，但畢竟解決了其它方面的問題，不過這對于老板積極性的打擊也是很明顯的。
其次是企業業務部門的相關人員，或者說是信息系統的最終使用者。他們其實并不關心信息系統能否解決老板所關心的問題。他們只是對系統是否好用，能否解決自己在日常工作中的問題感興趣。他們所關心的是：最好不要改變傳統的工作習慣，在不影響既得利益的前提下能減輕一些手工操作。只要達到了這樣的目標，他們就會認為是好系統。
然后是信息系統的提供商，也就是軟件公司，或者是所謂的系統集成商。他們關心項目能否按期完成，合同款能否按期收到。要想實現這個目標，對于他們來說，最好的辦法就是把軟件安裝好后，經過簡單的培訓，甚至不培訓，企業就能自己解決問題，系統能順利運行。
他們最害怕所謂的二次開發，也就是滿足客戶的個性化需求。只要客戶提出了個性化需求，相對聰明或者有實力的軟件公司會在已有的功能里面找出變通的方案來代替，盡可能的搪塞敷衍。如果實在找不出能代用的解決方案，則會采用拖、磨等戰術，讓用戶沒有耐心來等，最終放棄原來的需求。
這種方法還有一種很堂而皇之的說法，叫做引進科學的管理方式，改變用戶的管理模式，以最佳的流程來優化企業的管理等。這樣做的結果就是用戶總是感覺被糊弄，被欺騙。
說了這么多，系統相關的各個角色及心態都清楚了，那么再來回答需求分析該由誰來寫這個問題，也就應該清楚了。
領會根本需求 占取優勢
企業的戰略意圖當然要討論，并且要認真分析。因為信息化的目標就是要為企業的戰略服務的。
從文中可以看出，藍蘭集團要實現內部供應鏈的管理模式是主要目的，具體的需求就是集團統一接單，然后將訂單分派給集團內部各子公司以及各供應商。
具體目標是建造一個統一平臺，將內部供應鏈做透，以方便客戶、業務代表檢查和監督訂單執行的各個環節。不知道以前藍蘭公司是怎么做的？是由各分子公司自己聯系業務、相互獨立經營？還是條塊分割，相互牽制？客戶、業務代表和公司究竟是如何對訂單進行管理的？要改變過去的模式究竟應該怎么做，需要制定什么樣的制度和流程，軟件在這中間究竟要發揮多大的作用？
完全由業務部門來寫需求分析，存在的風險在于：由于不理解軟件公司所提供的專業模版的具體意思，就敷衍了事，隨便對付一下交差，不能反映出實際的需求和真正的意圖。同時也會對項目抱過多的幻想和期待，提出一些不切合實際的要求，目標太多以至于導致項目無法完成。
更多的業務部門往往會過于計較細微末節的東西，如報表格式、錄入習慣等。還有就是對傳統工作方式的堅持和固執，不愿意變革。如果嚴格按照這樣的需求進行設計，所做成的系統極有可能還是傳統工作方式的電子化，所謂的穿新鞋走老路，偏離信息化項目真正的目標。
需求分析對于軟件公司來說，其意義不亞于合同的商業附加條款。既然已經明確了要進行適應性改造，南方公司李封的做法，實際上是在回避問題。
"由顧問到現場對業務部門的需求責任人（大部分是管理人員）進行"模塊需求規格說明書"編寫的培訓，然后確定實施與開發任務。"這里面的風險不僅是業務部門對專業術語的理解偏差，更主要的是南方公司的調研提綱，完全是按照自己已經設計好的軟件架構和思路來"引導消費"，有可能會出現目標的偏差，能否響應公司老總確定的目標就很難說。或許他們就根本沒考慮老板的最原始需求。
當然這樣做的結果是：對南方公司而言是以自己已有的軟件模版和框架為藍本，對業務部門進行培訓，由業務部門來寫需求分析，最終雙方簽字畫押進行確認，以此來引導、引誘乃至綁架最終用戶的需求。這樣可以使得將來的系統不至于陷入無休止的需求變更和二次開發的泥潭里，項目的最終目標相對明確，以利于最終能順利脫身。
比較合理的做法是，企業的信息中心要真正發揮出主導作用。要和老板多交流，認真分析和領會老板的意圖，因為這才是最終的目標、最根本的需求。要對軟件公司所提供的軟件解決方案進行分析，看到底能符合到什么程度，有多少問題能夠解決，還有多少根本做不到。
如果和目標偏離的太多就不要搞什么需求分析了，干脆再換一家公司來做。如果偏差不大，絕大部分功能都能實現，則坐下來和軟件公司的實施顧問一起研究，進行系統的模擬運行和推演，在確認可行的情況下，拿出具體的實施方案來給老板匯報，交給業務部門討論。
基本原則就是確保最終目標不變，并盡可能照顧到業務部門的操作習慣等需求，以此來確認最終的實施和開發內容。只有這樣做，系統才能達到預期的目標。
基本原則就是確保最終目標不變，并盡可能照顧到業務部門的操作習慣等需求。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：企業實施信息化 需求分析到底應該誰來寫？
本文網址：http://www.guhuozai8.cn/html/consultation/1081961617.html
相關文章
