最近藍蘭集團信息中心主任張成又遇到了一個新問題，公司剛剛啟動了一個信息化新項目，就是內(nèi)部供應鏈的項目，各個制造實體的訂單管理將統(tǒng)一在一個操作平臺上進行。

    通過這個平臺，董事長魏武期望集團統(tǒng)一接單，然后將訂單分派給集團內(nèi)部汽車配件制造實體-藍蘭氣泵制造有限公司、藍蘭汽車橡膠制品制造有限公司、藍蘭汽車軸承制造有限公司等五個公司以及正在不斷擴大的外部供應商。

    "需求調(diào)研"惹起的禍端
    這個戰(zhàn)略意圖我們不去討論它。現(xiàn)在的問題是，為了穩(wěn)妥起見，魏武要求，先拿生產(chǎn)當家產(chǎn)品的藍蘭氣泵制造有限公司做試點，第一建造一個統(tǒng)一平臺，第二將氣泵的內(nèi)部供應鏈做透，以方便客戶、業(yè)務代表檢查和監(jiān)督訂單執(zhí)行的各個環(huán)節(jié)。

    張成已經(jīng)和南方管理軟件公司確定了通過對南方管理軟件ERP的E3（15.2）版本進行適應性改造，以適應內(nèi)部供應鏈的要求。也就是在基礎數(shù)據(jù)的管理上，以E3為基準，ERP的模塊功能按照訂單的執(zhí)行過程進行整合，最后進行適當?shù)亩�次開發(fā)。

    按照計劃，2006年8月上旬南方公司將派華東大區(qū)的咨詢顧問來項目現(xiàn)場進行為期半個月的現(xiàn)場需求調(diào)研，這時問題出現(xiàn)了。

    最早在簽約的時候，張成曾經(jīng)和軟件公司討論過，需求調(diào)研由顧問按照提綱進行訪問，然后整理出文檔供確認�，F(xiàn)在對方的項目經(jīng)理李封來郵件說，將由顧問到現(xiàn)場對業(yè)務部門的需求責任人（大部分是管理人員）進行"模塊需求規(guī)格說明書"編寫的培訓，然后顧問用四天時間對大家提交的需求規(guī)格說明書進行批改。最后將收集上來的資料帶回華東大區(qū)，由乙方項目組進行集中梳理并與標準產(chǎn)品進行匹配，看差距在哪里，然后確定實施與開發(fā)任務。

    "馬蹄"焉能"牛蹄"補
    張成對整個計劃沒有特別疑問，這個安排還是比較符合一般項目的做法，但有一點是需求說明全部由業(yè)務部門來寫，效果能不能得到保證？張成見過南方公司提供的"模塊需求規(guī)格說明書"，完全是需求分析師、系統(tǒng)設計師才能寫出來的東西，有許多專業(yè)的表達方式，他自己對許多詞語還搞不透。

    藍蘭氣泵制造有限公司的管理干部大部分是老員工，許多人勉強能打字，查查報表，現(xiàn)在要畫流程圖，說明字段輸入輸出規(guī)范、系統(tǒng)關(guān)聯(lián)等這樣的文章實在是勉為其難，一天的培訓很難讓大家有這樣的轉(zhuǎn)變，估計實際的調(diào)研進度將要大受影響。

    他把這個顧慮告訴李封時，李封說，這其實也是為張成好，業(yè)務部門按照這個規(guī)范寫出來的東西，他們確認后，可以直接給需求分析與程序開發(fā)人員使用，減少了中間環(huán)節(jié)，提高項目效率，也明確了責任，將來，他們有需求變更也有明確的依據(jù)。張成琢磨，這樣是不是算是"下套"？-你看，從最基層到項目組都承認了這個需求，藍蘭公司與南方公司的契約也就更清楚了，將來有什么問題，難道還找李封？

    當然張成擔心的主要還不是對方是不是"下套"，而是當前這樣的表達方式是不是能真切地表達項目需求，會不會因為表達方式的原因使基層的管理需求無法呈現(xiàn)，或者出現(xiàn)類似"精確的錯誤"這樣的東西。

    為此他向李封嚴正提出，由雙方項目組人員聯(lián)合成立模塊需求規(guī)格說明編寫小組，分工到具體部門組織編寫。但是李封堅決不同意。眼看調(diào)研時間就到，藍蘭公司應該怎么做？如果按照李封的做法，應該做什么準備？李封堅持這樣做，到底有什么道理？有一個什么妥協(xié)的辦法嗎？張成迫切想知道。

    ◎ 點評專家
    張欣 北京大學聯(lián)泰供應鏈研究與發(fā)展中心執(zhí)行副主任
    繹明宇博士 賽迪顧問項目咨詢總監(jiān)
    王磊 IDS Scheer中國副總裁
    張振坤 凌云科技集團有限責任公司信息管理中心主任
    張欣 北京大學聯(lián)泰供應鏈研究與發(fā)展中心執(zhí)行副主任

    在回答案例提出的問題之前，我們必須了解與需求分析有關(guān)的一些基本理論問題。

    提前做好"功課"很必要
    首先，了解需求分析的重要意義。其一，需求分析是企業(yè)IT建設的一個基本環(huán)節(jié)，是聯(lián)結(jié)企業(yè)IT規(guī)劃和IT實施的重要紐帶或橋梁；其二，需求分析是企業(yè)IT戰(zhàn)略的詳細表述，也是IT價值的根本所在；其三，需求分析是企業(yè)的一次管理改進過程。

    其次，了解需求分析的演化趨勢。我們經(jīng)常討論企業(yè)信息化失敗的比例有多高。其中一個很主要的原因就是需求分析沒做好。一種情況是IT項目甲乙雙方由于知識、能力、策略或管理等方面的問題未能做到無縫溝通。

    另一種情況是，盡管甲乙雙方溝通不錯，但需求分析或許只是對管理現(xiàn)狀的一次簡單呈現(xiàn)，未能解決企業(yè)管理方面存在的根本問題，或是提得過于理想，導致項目過于復雜，實施周期過長，最終讓雙方喪失信心。

    這些問題推動了需求分析的方式方法發(fā)生演化：一是IT服務方的需求分析責任人越來越多地由管理顧問來擔任；二是IT項目雙方合作得越來越緊密；三是隨著質(zhì)量管理、項目管理技術(shù)的應用，需求分析變得越來越規(guī)范；四是隨著軟件工程理論的發(fā)展，需求分析的方法論也發(fā)生重大變化。比如，引入OOAD（對象導向分析設計）思想并結(jié)合UML為業(yè)務需求建模。

    再者，了解需求分析的主要內(nèi)容和實施步驟。需求分析主要涉及功能性需求與非功能性需求兩類，并以功能性需求為主。

    一個需求分析詳細回答三個方面的問題：一是企業(yè)的現(xiàn)狀是什么（As-Is）；二是企業(yè)IT建設的目標是什么（To-Be）；三是從現(xiàn)狀到達目的的最佳途徑（方案）是什么（Best Solution）。那么，如何完成上述三個方面的準備呢？

    首先，我們要了解需求分析的范圍。一是功能范圍。是一個ERP系統(tǒng)，還是一個獨立的財務管理系統(tǒng)？二是業(yè)務范圍。比如，一個管理會計功能模塊可能只用在整車制造環(huán)節(jié)，也可能覆蓋全部零配件制造環(huán)節(jié)。三是機構(gòu)和人員范圍。一個會計核算系統(tǒng)可以只要財務部門負責數(shù)據(jù)維護，也可以開放一些數(shù)據(jù)接口給生產(chǎn)、采購、倉儲等部門。

    其次，確定需求分析的層次。需求分析主要有兩個層次，一是面向系統(tǒng)開發(fā)的需求分析（要變更或改進，需要較大的工作量。）；二是面向系統(tǒng)配置的需求分析（變更或改進相對較容易些）。

    再者，確定需求分析的模式（方法論）。需求分析的模式受三個因素影響：編制需求分析的指導思想、編制需求分析的工具、軟件服務企業(yè)的質(zhì)量管理體系和項目管理體系。

    了解了IT項目需求分析的范圍、層次、模式之后，我們再結(jié)合項目甲乙雙方的知識和能力作出判斷，有時可能需要第三方的協(xié)助。

    要占取主動地位
    再回到藍蘭集團的案例上來，那么，需求分析究竟該誰來做？

    1、案例中提到，"在簽約的時候，曾經(jīng)和軟件公司討論過，需求調(diào)研由顧問按照提綱進行訪問，然后整理出文檔供（甲方）確認"。那么，既然已有合同約定（包括口頭約定），雙方就應該按照約定的方式和步驟實施需求分析。

    2、如果事先的約定可以變更，那么，我們再來看李封的建議�？梢姡�其中存在幾個重大的邏輯缺陷：首先，如果顧問只是到現(xiàn)場對業(yè)務部門的需求責任人進行"模塊需求規(guī)格說明書"編寫培訓，那么，就無法對藍蘭企業(yè)做深入了解；其次，短暫培訓是否就能讓藍蘭公司的需求責任人員具備編寫需求分析的能力值得懷疑。

    另外，李封說，"顧問用四天時間對提交的需求規(guī)格說明書進行批改。"那么，乙方顧問根本沒有對甲方進行過詳細調(diào)查，怎么能在四天內(nèi)完成對甲方需求的批改呢？最后，對甲方需求與乙方標準產(chǎn)品之間的"差距"，是更改甲方需求，還是更改產(chǎn)品來彌補？也難有定論！

    3、針對這種情況，藍蘭公司不能讓本來的主動地位變成被動，更不能在需求分析環(huán)節(jié)失去把握能力。而應該依據(jù)筆者提出的分析模型或其它類似的分析方法對自己和乙方的知識、經(jīng)驗以及承擔需求分析責任的能力做出判斷，并據(jù)此來決定是接受還是否定李封的建議，甚至，當認為對方的知識、經(jīng)驗、能力和責任心值得懷疑時，還可以取消與乙方的合作。

    明確合作雙方的責任細節(jié)
    繹明宇博士 賽迪顧問項目咨詢總監(jiān)
    藍蘭集團遇到的問題是企業(yè)在信息化建設過程中很常見的問題，主要原因是由于甲乙雙方在項目合作簽訂過程中，對一些細節(jié)的工作責任沒有明顯地界定而導致的。由于藍蘭集團是傳統(tǒng)企業(yè)，對信息化工程的過程和內(nèi)容均不太熟悉，所以往往就會出現(xiàn)前期工作沒有考慮到的問題出現(xiàn)。

    要回答業(yè)務需求分析工作應由哪方來承擔，就首先搞清楚信息化工程的內(nèi)容，以及業(yè)務需求分析工作在整體信息化工程中的位置，這樣才能明確此工作應由誰來完成。

    一般來說，一個信息化工程包括前期的系統(tǒng)分析、中期的系統(tǒng)實施、后期的系統(tǒng)運維與優(yōu)化工作，其中本案例中引發(fā)甲乙雙方矛盾的"模塊需求規(guī)格說明書（不同企業(yè)對此有不同的稱謂）"屬于前期工作（系統(tǒng)分析工作）的內(nèi)容。

    系統(tǒng)分析工作包括業(yè)務需求分析和應用系統(tǒng)分析兩大部分，這兩者的關(guān)系是根據(jù)企業(yè)業(yè)務現(xiàn)狀以及信息技術(shù)特點而演化出來的新的業(yè)務需求（也就是業(yè)務流程重組或優(yōu)化結(jié)果），推導出為信息系統(tǒng)所能識別的軟件功能模塊及其相互關(guān)系（應用軟件運作模型）。也就是說，業(yè)務需求分析是業(yè)務分析（也包括管理分析）過程，而應用系統(tǒng)分析是軟件"編譯"過程。

    業(yè)務分析過程對于整個企業(yè)信息化過程有著關(guān)鍵的導向作用。分兩個階段工作，首先是企業(yè)供應鏈管理的現(xiàn)狀描述過程，其次是企業(yè)供應鏈管理模式優(yōu)化和重組過程，前者也是后者的前提和基礎。

    對于"模塊需求規(guī)格說明書"的內(nèi)容的界定首先就要指明，它只是包括企業(yè)供應鏈管理的現(xiàn)狀描述過程，還是包含整個業(yè)務分析過程。

    如果它只是企業(yè)供應鏈管理的現(xiàn)狀描述過程，那么藍蘭集團供應鏈系統(tǒng)分析過程只進行了第一步，還需有第二步的工作，也就是說，還需要二次需求確認環(huán)節(jié)。如果它包含了整個業(yè)務分析過程，則單靠藍蘭集團現(xiàn)有人員的技術(shù)力量顯然是不現(xiàn)實的。所以，我們可以把"模塊需求規(guī)格說明書"的內(nèi)容的界定為藍蘭集團供應鏈管理的現(xiàn)狀描述過程。

    有了這個前提，才能引出藍蘭集團供應鏈管理現(xiàn)狀描述工作承擔者的問題。實際上，對于企業(yè)信息化系統(tǒng)分析工作，并沒有統(tǒng)一的模式。有時是甲方企業(yè)來承擔，有時是乙方軟件商（或集成商）來承擔，有時是第三方信息化咨詢公司來承擔，另外，在實際操作中過程中，往往是這甲乙雙方，或甲丙雙方聯(lián)合承擔。張成希望甲乙雙方聯(lián)合項目組的方式，而李封是甲方企業(yè)承擔模式，只不過乙方在其間給予部分技術(shù)支持。

    由于雙方存在著明顯的信息不對稱現(xiàn)象，所以應在雙方簽署合作協(xié)議時，由乙方向甲方提出，以供甲方根據(jù)自身的條件進行選擇和確定。

    本案例中，顯然乙方并沒有提出工作承擔者問題，以致在合同簽訂后，引發(fā)出不必要的麻煩，因而總得來說，這造成此麻煩的責任在于南方管理軟件公司。

    如果合同中約定了"需求調(diào)研由顧問按照提綱進行訪問，然后整理出文檔供確認"，則李封提出甲方承擔的模式顯然就是違約（因為這種改變會涉及到前期業(yè)務分析過程工作量的巨大變化），藍蘭集團有權(quán)提出中止合同，或要求南方管理軟件公司履約。如果在合同中沒有寫明"模塊需求規(guī)格說明書"由哪方來承擔，則甲乙雙方需重新進行協(xié)調(diào)，主要是測算工作量，以及重新確定合同金額（重簽合作）。

    另外，由于南方管理軟件公司的項目經(jīng)理對于此麻煩的產(chǎn)生有不可推卸的責任，而這種提醒工作是信息化工程中的常識性工作，乙方項目經(jīng)理沒有做的原因只有兩種可能，其一是故意混淆概念，模糊工作量；其二就是沒有此方面的工作經(jīng)驗。

    不論是哪一種情況，對于藍蘭集團供應鏈管理系統(tǒng)的建設來說，都將是一種潛在的風險。因而，藍蘭集團可以直接向南方管理軟件公司提出更換其項目經(jīng)理的要求，也就不存在"妥協(xié)的辦法"的問題了。

    乙方并沒有提出工作承擔者問題，以致在合同簽訂后，引發(fā)出不必要的麻煩。

    用"好工具"整合業(yè)務與技術(shù)需求
    王磊 IDS Scheer中國副總裁
    業(yè)務需求描述的環(huán)節(jié)，是一個信息化項目得以順利進行的基礎。而在眾多項目中，該環(huán)節(jié)往往會出現(xiàn)前期業(yè)務需求的描述不夠明確，從而導致項目后期不斷變更需求設計的情況。

   在項目中，對于業(yè)務需求的描述往往是由精通業(yè)務的人員進行的，但這部分人員通常又是企業(yè)內(nèi)部最為忙碌的人員。因此，在描述業(yè)務需求時由于不能有充足的時間來反復斟酌，從而使得所描述的需求比較粗糙。

   另外，咨詢顧問要求業(yè)務人員用來描述業(yè)務需求的工具太過專業(yè)，使得業(yè)務人員無法用這些工具來很好地表達自已的想法。

    比如，傳統(tǒng)的做法是先畫流程圖再填需求調(diào)研表，這種畫圖加填表的方式等于是將基于業(yè)務需求梳理軟件開發(fā)思路的工作全部交給了業(yè)務人員，這對于以業(yè)務操作為主很少接觸信息化管理系統(tǒng)的人員來說，確實是勉為其難的。

    正是由于上述情況，所以又會經(jīng)常出現(xiàn)在項目后期業(yè)務人員不斷提出新的業(yè)務需求或不斷變更業(yè)務需求的情況，從而給咨詢公司順利完成系統(tǒng)的開發(fā)和配置帶來很大的壓力。

    針對上述情況，筆者認為由業(yè)務人員進行需求描述這一點應該是要堅持的一個方向。咨詢顧問通過調(diào)研整理出業(yè)務需求并請業(yè)務人員進行確認的做法，其準確性和完整性被大量實踐證明是很差的。

    問題的關(guān)鍵是應該給業(yè)務人員提供一個很好的工作平臺，在這個平臺上業(yè)務人員能夠用業(yè)務的語言比較高效地進行需求的描述。而這種用業(yè)務語言描述出來的業(yè)務需求又能自動轉(zhuǎn)成IT人員所要的技術(shù)信息，以便于咨詢公司進行系統(tǒng)的開發(fā)或配置。

    那么需要給業(yè)務人員提供一個什么樣的業(yè)務需求描述工具呢？筆者認為，這個工具平臺應該采用業(yè)務人員的工作語言。比如，描述一個業(yè)務流程，業(yè)務人員只要講清楚做什么事，誰來做，目前需要用到什么樣的數(shù)據(jù)或表單等即可，不用涉及專業(yè)的技術(shù)術(shù)語和概念。

    但為了今后能基于此導出IT人員需要的信息，因此對于這些業(yè)務要素的描述應建立統(tǒng)一、標準、圖形化的流程描述語言、方法和標準。比如，流程的操作、執(zhí)行者、輸入輸出等要素的表達符號、形狀、視圖格式、關(guān)聯(lián)邏輯等都應該有一個統(tǒng)一的規(guī)范和標準，流程要素的定義無二義性。

轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/

本文標題：企業(yè)實施信息化 需求分析到底應該誰來寫？

本文網(wǎng)址：http://www.ezxoed.cn/html/consultation/1081961617.html