IT售前咨詢白皮書Digital

1、it售前咨詢白皮書2008年7月目 錄1 前言52 售前咨詢及定位73 售前咨詢路線框架103.1 計劃與準(zhǔn)備階段113.1.1 輸入113.1.2 工作內(nèi)容113.1.3 輸出123.1.4 注意事項123.2 業(yè)務(wù)理解階段133.2.1 輸入133.2.2 工作內(nèi)容133.2.3 輸出143.3 解決方案階段143.3.1 輸入143.3.2 工作內(nèi)容143.3.3 輸出153.4 項目商務(wù)階段153.4.1 輸入153.4.2 工作內(nèi)容153.4.3 輸出173.5 項目實施階段173.5.1 輸入173.5.2 工作內(nèi)容173.5.3 輸出174 理解客戶業(yè)務(wù)184.1 業(yè)務(wù)戰(zhàn)略194

2、.2 業(yè)務(wù)模式204.3 組織架構(gòu)214.4 業(yè)務(wù)流程214.5 作業(yè)程序225 分析客戶需求245.1 軟件需求層次245.2 uml與相關(guān)模型255.2.1 uml概述255.2.2 用例模型265.2.3 順序模型275.2.4 活動模型285.2.5 類模型295.3 用uml進行需求分析305.3.1 確定系統(tǒng)邊界305.3.2 尋找參與者305.3.3 尋找用例315.3.4 尋找初始和終止事件315.3.5 準(zhǔn)備普通場景315.3.6 增加變化和異常場景315.3.7 尋找外部事件325.3.8 編制復(fù)雜用例的活動圖325.3.9 組織參與者和用例325.4 組織原型界面326

3、編寫技術(shù)方案346.1 業(yè)務(wù)理解346.1.1 項目背景分析356.1.2 企業(yè)現(xiàn)狀和業(yè)務(wù)架構(gòu)分析356.1.3 問題定義與變革分析366.2 需求分析366.2.1 系統(tǒng)目標(biāo)分析366.2.2 系統(tǒng)邊界分析376.2.3 系統(tǒng)功能需求分析376.2.4 系統(tǒng)性能要求396.2.5 系統(tǒng)技術(shù)要求406.3 技術(shù)方案406.4 實施方案406.5 運維方案416.6 公司簡介417 關(guān)于企業(yè)架構(gòu)431 前言到現(xiàn)在為止，我一直在問自己，你夠格嗎？懵懂地闖入了售前咨詢領(lǐng)域時，我?guī)缀醪幻靼资矍笆鞘裁?、?yīng)該做哪些工作，只記得最初的工作是從投標(biāo)開始的。記得自己第一次獨立承接標(biāo)書任務(wù)時，整整用了三天時間才理

4、出了一個提綱，然后用了十天時間完成了方案的編寫，很幸運的是公司中了那個標(biāo)，從此就開始了自己的售前之路。在渾渾噩噩的頭幾年，我的主要工作是針對公司現(xiàn)有的產(chǎn)品編寫解決方案和演示ppt，以及進行項目投標(biāo)活動（主要還是標(biāo)書的編寫和ppt的制作）。在寫方案的時候，針對客戶關(guān)系管理、物流管理等系統(tǒng)，我比較注重理論體系的學(xué)習(xí)，并把相關(guān)的理論體系應(yīng)用到方案中（說明理論的框架，并如明系統(tǒng)與理論的匹配度），這是我與公司之前的售前的最大區(qū)別他們習(xí)慣直奔主題闡述系統(tǒng)有哪些功能。這大概是我對售前工作理解的第一階段吧。今天回過頭去看看那段過程，最大的欠缺有兩方面：一是it售前的方法論，不能從全局的觀點去定義售前的工作，采

5、用方法論去指導(dǎo)自己的工作過程；二是理論與實踐的脫結(jié)，與客戶接觸較少，不清楚也不了解客戶的實際問題，不能用理論框架去實際地解決客戶的問題。事實上，當(dāng)時根本不明白這些，甚至頗有些自得地認為自己還挺不錯的，當(dāng)然有時心情也挺復(fù)雜的，畢竟售前咨詢面臨的領(lǐng)域太廣了，明顯覺得自己知識不夠用。2004年開始接觸到了信息化規(guī)劃，在不以為然其提交物的時候，也深深地被其方法論給震憾了。此后，比較多地關(guān)注了信息化規(guī)劃的路線圖和方法框架，在售前咨詢過程中會以一些信息化規(guī)劃模版為參照物，進行方案的編寫。不可否認，起初生搬硬套的痕跡非常地明顯，隨著不斷地學(xué)習(xí)和思考，慢慢地較深入地了解了信息化規(guī)劃的內(nèi)容以及實施路線，同時也領(lǐng)

6、悟到售前咨詢方案的編寫也可采用規(guī)劃的方法進行，二者的區(qū)別在于前者是基于全局業(yè)務(wù)的，而后者是基于局部業(yè)務(wù)的。采用信息化規(guī)劃的方法論指導(dǎo)自己的售前工作，也算是對售前工作理解的第二階段吧。后來自己開始帶團隊，為了培訓(xùn)團隊中的新人，我盡量把自己理解的售前咨詢的方法論教給他們，這過程中也發(fā)現(xiàn)自己了解的內(nèi)容也不是非常地體系。為了做好培訓(xùn)教材，上網(wǎng)查了很多資料，這才發(fā)現(xiàn)業(yè)界對售前的稱謂莫衷一是，對售前的職能和工作也沒有統(tǒng)一的定義。而實際上，自己團隊的工作也有些疲于奔命的感覺，整天忙著應(yīng)付來自銷售的需求?；靵y的現(xiàn)實促使我對售前職業(yè)進行了思考售前應(yīng)該是做什么的？售前應(yīng)該怎么作？售前的出路是什么？售前應(yīng)該具備哪些

7、知識和能力了？在此談點不成熟的看法。從客戶價值視角看，售前咨詢的主要工作應(yīng)該是認識問題（理解業(yè)務(wù)）、分析需求和提供解決方案。在整個售前咨詢過程中，目前主要的欠缺有二：一是缺少工作路線圖對售前工作的指導(dǎo)，幾乎沒有售前對工作推進路線有清晰的計劃；二是解決方案應(yīng)該如何編寫，要寫哪些內(nèi)容有些模糊。其實只要明白售前的主要工作是認識問題、分析需求和提供解決方案，方案的編寫內(nèi)容就清楚了。在一番思考后，我決定編寫一本it軟件應(yīng)用售前咨詢白皮書，本書的主要對象是為行業(yè)或為客戶提供應(yīng)mis系統(tǒng)的售前咨詢?nèi)藛T。希望通過本書能給剛?cè)腴T的售前提供指導(dǎo)，對職業(yè)有疑惑的售前提供幫助，也為一些資深的售前提供參考。在與很多優(yōu)秀

8、同行的競爭中，我已經(jīng)在這個職業(yè)中走過了七年，深深感覺售前咨詢領(lǐng)域的博大精深和售前咨詢工作的巨大挑戰(zhàn)，到目前為止，自己一直感覺未能切實地站在較高的高度為客戶提出可行的解決方案，這也是我一直置疑自己的原因。希望能用此書作為我七年工作的總結(jié)，同時也是自己提升的基礎(chǔ)吧。在此對所有在過去工作中給予我?guī)椭目蛻?、領(lǐng)導(dǎo)、同事和朋友表示感謝。2 售前咨詢及定位售前咨詢，作為銷售人員的技術(shù)支持，其職責(zé)是以專業(yè)的方法理解客戶業(yè)務(wù)、分析客戶需求，將管理理論、客戶需求、it技術(shù)和公司產(chǎn)品相結(jié)合提供解決方案，并將良好的公司形象、產(chǎn)品形象和服務(wù)能力傳達給客戶，從而達到有效戰(zhàn)勝競爭對手、促成簽章并合理降低項目風(fēng)險的目標(biāo)。近

9、代學(xué)者王國維認為，“古今之成大事業(yè)、大學(xué)問者，必經(jīng)三種境界?！薄白蛞刮黠L(fēng)凋敝樹，獨上高樓，望盡天涯路”，是為第一境界；“衣帶漸寬終不悔，為伊消得人憔悴”，是為第二境界；“眾里尋他千百度，驀然回首，那人卻在燈火闌珊處”，是為最終境界。這不只是做詩的境界，做學(xué)問的境界，從事藝術(shù)創(chuàng)造的境界，也是我們生活的境界，事業(yè)的境界，人生的境界。售前咨詢之道亦然。售前是作為公司的技術(shù)代表，其主要職責(zé)是協(xié)同銷售人員讓客戶接受公司的解決方案。但如何提供解決方案，亦存在幾種不同的境界。第一重境界：從產(chǎn)品到方案。將公司的產(chǎn)品說明書修改成針對用戶的解決方案，這一類售前咨詢不在少數(shù)，特別是一些作產(chǎn)品的公司。此重境界的售前咨

10、詢，可能比較了解自己的產(chǎn)品，甚至有相當(dāng)?shù)募夹g(shù)功底，也有良好用戶展示和交流能力（當(dāng)然如果這些都沒有那就真的是一無是處了），但不能站在客戶價值角度理解產(chǎn)品，通過了解客戶業(yè)務(wù)、界定客戶需求，并說明產(chǎn)品對客戶的價值。這是售前咨詢的初級階段，個人覺得也是比較幸福的售前階段，怎么說了，簡單就是幸福嘛。第二重境界：從需求到方案。通過不斷地學(xué)習(xí)和總結(jié)了，有了自己的知識體系和工作方法論（自覺或不自覺的），能站在管理咨詢的角度采用各種方法去了解客戶業(yè)務(wù)、分析用戶需求，并提供解決方案。達到此境界絕非易事，方法論、知識、技能和態(tài)度一個都不能缺少，應(yīng)該說此重境界的售前咨詢已經(jīng)是比較成功的假如沒有下一重境界的話。此境界的

11、售前咨詢能從較高的程度對客戶進行影響，可承擔(dān)一些客戶的管理咨詢工作，如進行產(chǎn)品體系規(guī)劃和產(chǎn)品設(shè)計。第三重境界：全程商務(wù)推進。畢竟售前咨詢的本質(zhì)還是促進銷售，因而在商務(wù)領(lǐng)域也必須有自己的思路和想法。此重境界的售前咨詢對于整個商務(wù)推進路線有著清晰的認識，能根據(jù)此路線圖制定計劃，并按照計劃在不同階段影響客戶，直至商務(wù)合同的簽訂，甚至延伸至售中領(lǐng)域?；谏鲜龅木辰缑枋?，不難看出一個優(yōu)秀的售前咨詢應(yīng)該具備的能力：一是體系化的方法論（包括商務(wù)推進）；其二必須具備較寬的知識體系，包括管理、技術(shù)和業(yè)務(wù)方面的知識，特別是要熟悉自己的產(chǎn)品；三是良好的綜合技能，包括各類工具的應(yīng)用，如計劃、調(diào)研、交流、方案編寫、方案

12、展示等技能；此外還需要強調(diào)的是態(tài)度。一個優(yōu)秀的售前，除了為客戶提供價值外，也應(yīng)該在公司價值鏈中找到自己合適的定位。價值鏈?zhǔn)侵钙髽I(yè)進行的一系列符合特定模式的活動，或者說，價值鏈?zhǔn)瞧髽I(yè)生產(chǎn)的產(chǎn)品或服務(wù)增值的環(huán)節(jié)或鏈條，價值鏈中的每項活動都增加了產(chǎn)品或服務(wù)的價值。從企業(yè)價值鏈看，價值的創(chuàng)造和傳遞包括三階段：選擇價值，通過市場細分，確定企業(yè)的市場目標(biāo)和價值定位；提供價值，根據(jù)企業(yè)的業(yè)務(wù)戰(zhàn)略，開發(fā)產(chǎn)品和服務(wù)，并制訂企業(yè)總體營銷策略；傳播價值，通過銷售、促銷及其他推廣工作，將企業(yè)價值推向市場。在企業(yè)價值鏈中，售前咨詢可以通過市場研究影響公司戰(zhàn)略選擇，也可參與產(chǎn)品開發(fā)以提供價值，更多的時候售前從事是的價值傳

13、播工作。因而一個優(yōu)秀的售前咨詢應(yīng)該在價值鏈的各個環(huán)節(jié)都要有所映射。基于上述分析，可將it售前咨詢定位如下： 價值選擇的輔助者，輔助公司戰(zhàn)略價值選擇。通過行業(yè)研究和市場分析，進行公司的產(chǎn)品體系規(guī)劃、服務(wù)體系規(guī)劃和市場發(fā)展規(guī)劃，以輔助領(lǐng)導(dǎo)決策。 解決方案的編制者，基于客戶需求提供解決方案。通過溝通和交流，了解客戶戰(zhàn)略與業(yè)務(wù)、分析客戶需求，并在此基礎(chǔ)上提供解決方案。 商務(wù)過程的推進者，輔助銷售推進商務(wù)進程。與銷售共同制定商務(wù)推進計劃，通過體系化的方法、深厚的技術(shù)能力和豐富的展現(xiàn)能力影響客戶選擇，并在方案、價格和合同協(xié)助銷售推進商務(wù)進程。 項目成功的保障者，保障項目的成功實施。通過業(yè)務(wù)分析界定客戶需求

14、范圍，從而實現(xiàn)客戶需求與產(chǎn)品開發(fā)項目的銜接。售前咨詢項目成功的秘訣在于運用客戶能夠理解、贊賞并反饋的方式來解決問題。在商務(wù)推進過程中，售前咨詢始終要采用頂級管理的眼光去看待問題，并根據(jù)項目情況對方法、商務(wù)推進線路進行裁剪，以保證對客戶影響的最佳。3 售前咨詢路線框架售前咨詢階段是實現(xiàn)銷售和進行項目實施的前沿階段，它包括了從銷售線索獲取、需求調(diào)研、調(diào)研分析到準(zhǔn)備項目建議書并向客戶進行陳述等工作內(nèi)容，為保證實現(xiàn)銷售的鋪墊階段。在售前咨詢階段，由于可能面臨眾多的競爭對手，同時在與客戶之間還沒有達成深入的溝通和了解，因此可能會遇到很多的困難和局限，如何在這一階段向客戶成功地展示自己的能力，說明客戶相信

15、自己就是最好的方案、產(chǎn)品以及服務(wù)的提供商，就成為項目能否繼續(xù)開展下去的關(guān)鍵所在。因而在此階段全局的過程路線框架和專業(yè)的知識、技能非常重要。在項目銷售過程中，對于售前咨詢來說，提供解決方案和推進商務(wù)進程是最重要的兩項職能，要完成銷售活動中的技術(shù)服務(wù)和商務(wù)推進工作，可采用售前咨詢路線如下：it項目售前咨詢路線包括五個階段：3.1 計劃與準(zhǔn)備階段3.1.1 輸入銷售線索分析與決策。獲取銷售線索以后，由銷售部門與售前部門進行銷售線索分析，并進行決策，如果需要跟進，則由銷售填寫銷售線索與項目立項書，進行項目立項。銷售線索與項目立項書模板。3.1.2 工作內(nèi)容計劃與準(zhǔn)備階段的主要工作：商務(wù)推進計劃編制。根

16、據(jù)銷售線索與項目立項書編制商務(wù)推進路線圖，大致的時間計劃以及資源需求。項目建議書編制。根據(jù)銷售線索與項目立項書，整合企業(yè)已有方案，編寫初步的項目建議書。此方案包括以下內(nèi)容： 定義項目背景、項目目標(biāo) 對客戶需求的粗略理解 公司的應(yīng)用和技術(shù)解決方案 公司關(guān)于售前咨詢的方法論、此項目的推進路線圖和大致時間計劃 項目的關(guān)鍵點及需要客戶配合的工作 現(xiàn)有產(chǎn)品演示需求調(diào)研計劃與問卷編制。制訂需求調(diào)研計劃，明確調(diào)研對象、訪談進度計劃和以及需要客戶配合的工作內(nèi)容。通過編寫初步方案明確哪些問題需要調(diào)研，從而制訂需求調(diào)研問卷。需求調(diào)研計劃包括以下內(nèi)容： 調(diào)研目的 調(diào)研范圍，涉及公司高層/主要業(yè)務(wù)部門/it部門等 調(diào)

17、研方式，問卷調(diào)查/電話調(diào)研/面談等 調(diào)研行程安排，為了提高整個調(diào)研的效率，行程安排務(wù)必緊湊、合理 調(diào)研人員組織需求調(diào)研問卷需要了解以下內(nèi)容： 行業(yè)背景和發(fā)展 組織的發(fā)展史和總體情況（企業(yè)文化、組織結(jié)構(gòu)、資產(chǎn)狀況、人員規(guī)模等） 組織今后的業(yè)務(wù)戰(zhàn)略和發(fā)展規(guī)劃 組織（關(guān)鍵業(yè)務(wù)部門）的職能、崗位設(shè)置、業(yè)務(wù)內(nèi)容和業(yè)務(wù)流程 新系統(tǒng)的規(guī)劃、目標(biāo)、規(guī)模、需求等，包括用戶對系統(tǒng)的安全性、可靠性、易用性、擴展性的要求 組織it建設(shè)的發(fā)展過程； 組織it現(xiàn)狀（基礎(chǔ)設(shè)施、應(yīng)用系統(tǒng)、組織人員等） 其他：客戶對平臺和數(shù)據(jù)庫選型的想法、對軟件開發(fā)機制的認識以及用戶感興趣的熱點技術(shù)需求調(diào)研計劃、需求調(diào)研問卷模板，下一步完善。

18、3.1.3 輸出*銷售項目商務(wù)推進計劃*項目建議書*銷售項目需求調(diào)研計劃*銷售項目需求調(diào)研問卷3.1.4 注意事項銷售應(yīng)根據(jù)銷售項目商務(wù)推進計劃及時與客戶溝通，以明確雙方第一次溝通的時間和溝通形式。同時，需提交項目需求調(diào)研計劃，并就調(diào)研時間進度與客戶進行協(xié)商，讓客戶進行需求調(diào)研安排。銷售人員需要一定的協(xié)調(diào)和掌控能力，使客戶能按照計劃表安排時間和項目交流的對口人員，避免時間和金錢的浪費。3.2 業(yè)務(wù)理解階段3.2.1 輸入銷售項目商務(wù)推進計劃、項目需求調(diào)研計劃和項目需求調(diào)研問卷。3.2.2 工作內(nèi)容業(yè)務(wù)理解階段的主要工作：首次客戶溝通交流。根據(jù)約定的時間與客戶進行第一次交流，提交裝訂精美的項目初

19、步解決方案，并進行方案講解。主要工作如下： 闡述客戶問題產(chǎn)生的背景與復(fù)雜性 總結(jié)客戶當(dāng)前需要解決的關(guān)鍵問題 定義項目目標(biāo)和項目范圍 解釋公司的售前咨詢方法和項目推進路線，解釋工作重點、階段性成果和需要客戶提供的幫助 項目推進進度安排，為后續(xù)工作按計劃進展做鋪墊客戶需求調(diào)研。根據(jù)項目需求調(diào)研計劃，進行相關(guān)部門和人員訪談，取得方案編寫所需信息。調(diào)研過程中仔細地聆聽，盡可能翔實地記錄。結(jié)束后對訪談記錄進行整理，編寫訪談紀(jì)要提交客戶確認。在需求調(diào)研中，應(yīng)設(shè)計業(yè)務(wù)流程的調(diào)查樣表，獲取流程名、簡單流程圖、主要過程文檔和支持系統(tǒng)等信息。對于沒有流程積累的客戶，售前咨詢需要花費時間和精力進行流程調(diào)研，對已收集

20、的流程進行檢查、分析，發(fā)現(xiàn)流程不全、尚需要補充細化的，要及時與業(yè)務(wù)部門聯(lián)系，回溯補遺?？蛻粽{(diào)研總結(jié)。調(diào)研完成后，自然就是對調(diào)研情況的整理和總結(jié)，編寫項目調(diào)研總結(jié)報告提交客戶確認，并約定下一次交流時間?？蛻粜枨笤L談記錄、客戶需求訪談紀(jì)要、客戶調(diào)研總結(jié)報告模板，下一步完善。3.2.3 輸出客戶需求訪談記錄客戶需求訪談紀(jì)要客戶調(diào)研總結(jié)報告3.3 解決方案階段3.3.1 輸入客戶需求訪談紀(jì)要、客戶調(diào)研總結(jié)報告。3.3.2 工作內(nèi)容解決方案階段的主要工作：客戶需求分析。根據(jù)客戶需求訪談紀(jì)要、客戶調(diào)研總結(jié)報告進行需求分析，需求分析的重點是通過對客戶業(yè)務(wù)架構(gòu)的梳理，編寫用戶需求用例。解決方案編寫。根據(jù)需求分

21、析進行解決方案的編寫，包括方案文檔和演示文檔制作，有可能的話可進行演示系統(tǒng)的準(zhǔn)備。關(guān)于需求分析的方法、解決方案的內(nèi)容和形式詳見第4、5部分。解決方案交流。根據(jù)約定時間與客戶進行解決方案的講解，與客戶進行方案探討，并整理客戶意見，對方案進行修改。*項目解決方案模板，下一步完善。3.3.3 輸出*項目解決方案3.4 項目商務(wù)階段3.4.1 輸入項目解決方案。3.4.2 工作內(nèi)容項目商務(wù)階段的主要工作：客戶立項。客戶立項雖然是外部流程，但對于售前來說是非常重要的一環(huán)，銷售與售前應(yīng)盡可能爭取為客戶提供項目立項申請報告?？蛻粽袠?biāo)準(zhǔn)備?？蛻粽袠?biāo)也是外部流程，此階段客戶的主要工作是供應(yīng)商的考察、招標(biāo)過程的組

22、織、招標(biāo)的實施和確定最終的供應(yīng)商，并與確定的開發(fā)集成商進行商務(wù)談判和簽訂合同。在此環(huán)節(jié)，銷售與售前應(yīng)力爭為客戶提供項目招標(biāo)書和項目招標(biāo)評分標(biāo)準(zhǔn)，給競爭對手設(shè)置相應(yīng)的商務(wù)、技術(shù)障礙。項目投標(biāo)。項目投標(biāo)是個復(fù)雜的過程，包括以下環(huán)節(jié)： 購買招標(biāo)書由銷售購買招標(biāo)書后，如確定投標(biāo)則回復(fù)投標(biāo)函，如果需要則辦理投標(biāo)保證金相關(guān)事宜。 編制投標(biāo)計劃由相關(guān)領(lǐng)導(dǎo)招集銷售、售前和技術(shù)部門對招標(biāo)書進行討論，根據(jù)項目的規(guī)模、技術(shù)難度和招標(biāo)時間的要求，明確投標(biāo)工作內(nèi)容，制訂投標(biāo)計劃，將計劃分解到每個人員上，確定每個人工作內(nèi)容和計劃，確定計劃的執(zhí)行的監(jiān)督人員。此外，投標(biāo)小組對招標(biāo)書進行討論，找出招標(biāo)書中描述不清楚的地方，根據(jù)

23、情況向招標(biāo)方提出要求解釋。 解決方案編制包括技術(shù)解決方案和商務(wù)解決方案的編制以及演示系統(tǒng)的準(zhǔn)備。在編寫標(biāo)書前，應(yīng)仔細、反復(fù)閱讀招標(biāo)書，從而確定投標(biāo)書的內(nèi)容、投標(biāo)方式。商務(wù)解決方案由銷售負責(zé)（公司簡介、公司資質(zhì)、公司榮譽、典型案例、售后服務(wù)承諾等內(nèi)容），商務(wù)投標(biāo)書應(yīng)該按照招標(biāo)書的要求進行嚴(yán)格的應(yīng)答，應(yīng)答的順序和格式最好嚴(yán)格遵循招標(biāo)書的要求。存在資質(zhì)共享的情況下，應(yīng)該請資質(zhì)擁有的法人單位簽署授權(quán)聲明。 演示ppt和演示系統(tǒng)準(zhǔn)備在投標(biāo)前，講標(biāo)的每一部分應(yīng)該準(zhǔn)備好相應(yīng)的幻燈片，通過幻燈片，規(guī)范講解思路，并通過文字、圖片、動畫等多種方式，直觀的向評委傳達信息，便于評委對講解內(nèi)容的理解。 簽字蓋章在技術(shù)和

24、商務(wù)解決方案完成（校對、審核）后，打印解決方案，由相關(guān)人員進行簽字、蓋章。商務(wù)投標(biāo)書中的資質(zhì)和要求公司蓋章的部分一定要對照招標(biāo)書的要求，嚴(yán)格檢查，這部分的錯誤和遺漏將有可能造成廢標(biāo)，因此，最好有兩個以上的人員專門檢查核對。 裝訂與封裝將簽字、蓋章后的方案進行裝訂，并根據(jù)招標(biāo)書要求進行封裝。在規(guī)定的投標(biāo)文檔密封條基礎(chǔ)上，一定要多準(zhǔn)備幾張備用的、蓋好章的密封條。 遞交標(biāo)書、述標(biāo)和演示根據(jù)招標(biāo)書要求遞交標(biāo)文，由相關(guān)人員進行述標(biāo)和系統(tǒng)演示。講標(biāo)應(yīng)該有既要有重點，又要覆蓋到各項內(nèi)容，突出公司特點和優(yōu)勢、突出技術(shù)優(yōu)勢和特點。展示系統(tǒng)時，要注意揚長避短，屏蔽掉一些系統(tǒng)的弱點和缺陷，同時要注意演示的時間控制。

25、商務(wù)談判與合同準(zhǔn)備。在預(yù)中標(biāo)后，將會進行商務(wù)和技術(shù)談判，售前技術(shù)支持人員主要參加技術(shù)協(xié)議的談判和起草，并為合同準(zhǔn)備技術(shù)方案附件。技術(shù)協(xié)議目的是界定好功能邊界和深度，技術(shù)協(xié)議的談判就是要對敏感問題和技術(shù)難點要進行溝通，達成共識，使項目風(fēng)險在項目實施前就得到充分的展示和控制。技術(shù)投標(biāo)方案和商務(wù)投標(biāo)方案模板，下一步完善。3.4.3 輸出*項目投標(biāo)方案3.5 項目實施階段3.5.1 輸入項目投標(biāo)方案。3.5.2 工作內(nèi)容項目實施階段的主要工作：協(xié)助制定項目實施計劃。在合同簽訂以后，與項目經(jīng)理進行溝通，為項目經(jīng)理理解客戶需求和界定項目范圍提供幫助，并協(xié)助項目經(jīng)理制定項目實施計劃。3.5.3 輸出*項目實

26、施計劃。4 理解客戶業(yè)務(wù)曾經(jīng)一度，我和大家一樣是極端鄙視那些的咨詢專家的，除了“他們的方法論的確不錯”。平心而論，咨詢專家能借助一套方法和工具，能在非常短的時間內(nèi)進入一個他們完全不熟悉的業(yè)務(wù)領(lǐng)域進而成為業(yè)務(wù)專家，是非常不容易的。設(shè)想你站在伸手不見五指的茫茫曠野之中，恐懼陣陣來襲，這時候你是多少希望有一盞明燈啊，而企業(yè)業(yè)務(wù)架構(gòu)就是指引我們了解客戶業(yè)務(wù)的明燈。企業(yè)的戰(zhàn)略往往取決于市場的環(huán)境、客戶的需求和企業(yè)的資源和能力，而在戰(zhàn)略制定之后，落實則主要依賴于業(yè)務(wù)架構(gòu)的承載。企業(yè)業(yè)務(wù)架構(gòu)描述了企業(yè)的業(yè)務(wù)策略、管理模式、組織結(jié)構(gòu)和關(guān)鍵業(yè)務(wù)流程。業(yè)務(wù)架構(gòu)用來定義企業(yè)的業(yè)務(wù)戰(zhàn)略、企業(yè)業(yè)務(wù)模式/價值鏈、企業(yè)治理

27、和管理架構(gòu)、業(yè)務(wù)流程和作業(yè)程序，并通過企業(yè)信息架構(gòu)和技術(shù)架構(gòu)來實現(xiàn)。在這一業(yè)務(wù)架構(gòu)中，業(yè)務(wù)模式將直接承載企業(yè)的戰(zhàn)略，而流程則是業(yè)務(wù)模式的承載體，作業(yè)程序則承載著流程中某項作業(yè)的具體實現(xiàn)。一般來說，戰(zhàn)略的改變需要對業(yè)務(wù)模式進行重新思考，進入影響到業(yè)務(wù)流程的改變，而作業(yè)程序作為業(yè)務(wù)架構(gòu)中最底層的操作，由最基本的任務(wù)單元的特征所決定，一般不會受到戰(zhàn)略改變的影響。企業(yè)業(yè)務(wù)架構(gòu)是指導(dǎo)售前咨詢理解客戶業(yè)務(wù)和需求的方法論框架。值得注意的是，在售前咨詢階段，由于客觀原因限制，不可能對業(yè)務(wù)了解地非常詳細，但要盡力而為。4.1 業(yè)務(wù)戰(zhàn)略任何企業(yè)都有自己的戰(zhàn)略，彼得德魯克在事業(yè)理論：企業(yè)的靈魂一書中指出，每個企業(yè)都

28、應(yīng)依據(jù)一套“事業(yè)理論”運作。企業(yè)戰(zhàn)略包括的內(nèi)容： 企業(yè)使命定義公司為什么存在。企業(yè)使命描述一個持久的事實，是一個無限時期的解答，為組織內(nèi)所有決策提供前提，為內(nèi)部和外部人員提供指導(dǎo)。 企業(yè)愿景領(lǐng)導(dǎo)者希望公司發(fā)展成什么樣。企業(yè)愿景描述一個鼓舞人心的事實，可以在一個特定時期內(nèi)實現(xiàn)，指導(dǎo)戰(zhàn)略和組織的發(fā)展，主要是為內(nèi)部人員提供指導(dǎo)（有些口號也可提供給外部人員）。 企業(yè)競爭戰(zhàn)略擊敗現(xiàn)有及潛在競爭者的計劃。企業(yè)競爭戰(zhàn)略描述公司戰(zhàn)略選擇的“價值方案”，列出一系列舉措以提供產(chǎn)品或服務(wù)，創(chuàng)造高于其成本的價值，競爭戰(zhàn)略隨市場分析、消費者經(jīng)驗、試驗而不斷改善，且嚴(yán)格限制在內(nèi)部使用。戰(zhàn)略構(gòu)架抽象描述了一個公司在市場上正

29、在或期望扮演的角色，以及這樣的角色能夠長期穩(wěn)定地創(chuàng)造價值的關(guān)鍵原因。戰(zhàn)略構(gòu)架包括： 在哪兒競爭指從廣泛的市場參與（即眾多的產(chǎn)品種類，及可能吸引的各類消費者）中選擇一些目標(biāo)市場、產(chǎn)品和顧客，以集中力量于一些細分的產(chǎn)品或顧客市場上。其核心是顧客、產(chǎn)品、地理區(qū)域、渠道和垂直整合程度 如何競爭指列舉所有該產(chǎn)業(yè)通常的可能競爭方式，并嘗試采用不同的基本競爭手段（例如，采用新技術(shù)，或不同的基本手段以滿足顧客需求）。 何時競爭指戰(zhàn)略的時間動態(tài)考慮。4.2 業(yè)務(wù)模式所謂業(yè)務(wù)模式，指的是企業(yè)創(chuàng)造價值的核心業(yè)務(wù)邏輯，包括核心業(yè)務(wù)的組合及相互的關(guān)系，簡單地說，就是企業(yè)是如何實現(xiàn)盈利的。企業(yè)的盈利模式有很多種，這也就導(dǎo)

30、致了業(yè)務(wù)模式的大量衍生。即使在同一行業(yè)，企業(yè)可以采用完全不同的業(yè)務(wù)模式。有的企業(yè)可以從上游的原材料一直延伸到下游的分銷，這是一種盈利模式，或者說是一種業(yè)務(wù)模式；而有的企業(yè)只專注制造業(yè)務(wù)，有的企業(yè)集中于分銷。通過這些業(yè)務(wù)的不同組合，市場上衍生出若干不同的業(yè)務(wù)模式，每個企業(yè)憑借著自己的業(yè)務(wù)模式來實現(xiàn)價值。其實，即使只是同一種業(yè)務(wù)，卻依然可以有不同的業(yè)務(wù)模式，例如從事銷售的企業(yè)，就有直銷模式和分銷模式之分。對于企業(yè)而言，采用什么樣的業(yè)務(wù)模式，則主要取決于企業(yè)的戰(zhàn)略，即企業(yè)想通過什么樣的方式來盈利，包括在哪些業(yè)務(wù)領(lǐng)域進行競爭，通過什么樣的方式進行競爭等。企業(yè)的戰(zhàn)略將直接決定企業(yè)的業(yè)務(wù)模式，而業(yè)務(wù)模式也

31、將直接決定企業(yè)的競爭能力，或者說戰(zhàn)略實現(xiàn)的能力。正如管理學(xué)大師彼得德魯克（peter f.drucker）曾說過：“當(dāng)今企業(yè)之間的競爭，不是產(chǎn)品之間的競爭，而是業(yè)務(wù)模式之間的競爭。”要了解企業(yè)的業(yè)務(wù)模式對企業(yè)的現(xiàn)有流程進行系統(tǒng)性的梳理，全面掌握企業(yè)價值鏈和高階流程的現(xiàn)狀。4.3 組織架構(gòu)影響公司成功的三個關(guān)鍵因素是成功的戰(zhàn)略、有效的運營和高效的組織。因而要了解企業(yè)，就必須了解企業(yè)的組織事務(wù)和變革管理方面的內(nèi)容。包括： 企業(yè)治理組織結(jié)構(gòu)企業(yè)的產(chǎn)權(quán)構(gòu)成、治理模式以及治理的組織架構(gòu) 企業(yè)管理組織結(jié)構(gòu)企業(yè)的單元、部門和崗位設(shè)置情況 組織和崗位職能明確單位、部門和崗位的工作職責(zé)、標(biāo)準(zhǔn)要求和履職條件4.4

32、 業(yè)務(wù)流程流程是指把一個或多個輸入轉(zhuǎn)化為對顧客有價值的輸出的活動組合。在業(yè)務(wù)架構(gòu)中，業(yè)務(wù)模式是戰(zhàn)略的直接承載體，而業(yè)務(wù)模式中的價值創(chuàng)造，則需要流程來實現(xiàn)。業(yè)務(wù)模式呈現(xiàn)了盈利的業(yè)務(wù)全景，包括企業(yè)有哪些業(yè)務(wù)，以及這些業(yè)務(wù)主體之間的關(guān)系。而流程呈現(xiàn)的則是這些業(yè)務(wù)在每一步需要做什么。不同的業(yè)務(wù)模式將需要不同的業(yè)務(wù)流程來支撐。例如，批量生產(chǎn)模式和定制生產(chǎn)模式的業(yè)務(wù)流程將完全不同；直銷模式和分銷模式的業(yè)務(wù)流程也將完全不同；同樣直營連鎖模式和加盟連鎖模式的業(yè)務(wù)流程也將存在著差別。說到底，什么樣的業(yè)務(wù)模式?jīng)Q定什么樣的業(yè)務(wù)流程?？刹捎谩奥毮苡蛄鞒袒顒涌蚣堋边M行業(yè)務(wù)流程及業(yè)務(wù)活動之間的關(guān)系梳理、編目及查詢，以建立

33、業(yè)務(wù)流程主題庫。 “職能域流程活動框架”中，最高層是職能域，是企業(yè)級的運營和支撐業(yè)務(wù)視圖，由若干個職能域（業(yè)務(wù)流程組）組成。第二層是流程，是對職能域的分解，一個職能域即一個業(yè)務(wù)流程組，包含若干個業(yè)務(wù)流程，有些流程下可能包含子流程（第三層）。第四層是組成流程的活動。根據(jù)需要，高層的流程模型可以進一步“分解”為較低的層次。在不同的層次上對流程進行規(guī)范時，應(yīng)該使用統(tǒng)一的指導(dǎo)方針和流程術(shù)語。4.5 作業(yè)程序作業(yè)程序是作業(yè)活動的具體操作方法，是業(yè)務(wù)架構(gòu)中最底層的元素，承載著業(yè)務(wù)流程中各種任務(wù)單元的的具體實現(xiàn)。如果說流程回答的是業(yè)務(wù)模式中每一步需要做什么的問題，那么作業(yè)程序則回答的是每一步怎么做的問題。每

34、一步做什么體現(xiàn)的是業(yè)務(wù)活動的邏輯關(guān)系，因此與業(yè)務(wù)模式息息相關(guān)，而每一步怎么做則是實現(xiàn)某項任務(wù)單元的操作方法，一般來說只與任務(wù)單元的特征相關(guān)，而與業(yè)務(wù)活動的邏輯無關(guān)，因此也就與業(yè)務(wù)模式無關(guān)了。作業(yè)程序就像最基本的零件單元，而流程則像組件，流程需要作業(yè)程序配置在哪，作業(yè)程序就放在哪。因此，企業(yè)在制定戰(zhàn)略之后，需要思考需要什么樣的業(yè)務(wù)架構(gòu)來支撐戰(zhàn)略的實現(xiàn)，而在戰(zhàn)略發(fā)生重大轉(zhuǎn)變時，企業(yè)就需要對業(yè)務(wù)模式進行調(diào)整，而對承載業(yè)務(wù)模式的業(yè)務(wù)流程進行再造。作業(yè)程序只是根據(jù)流程的需要進行重新的配置，一般卻并不對作業(yè)程序的本身進行調(diào)整。5 分析客戶需求軟件開發(fā)是由系統(tǒng)構(gòu)思、需求分析、系統(tǒng)設(shè)計、編碼實現(xiàn)、系統(tǒng)測試、系

35、統(tǒng)培訓(xùn)、系統(tǒng)部署和系統(tǒng)維護等一系列定義良好的階段構(gòu)成的，每個階段都有不同的目標(biāo)、輸入和輸出，整個過程應(yīng)該是無縫的，在整個開發(fā)過程中，要使用相同的概念和表示方法。uml（統(tǒng)一建模語言，unified modeling language）是一種面向?qū)ο蟮慕ＵZ言，采用圖形表示法來表示oo的概念。通過uml，可以構(gòu)建一種應(yīng)用模型，并在設(shè)計過程中增加細節(jié)。從分析到設(shè)計再到實現(xiàn)使用的是相同的無縫表示法，這樣一個開發(fā)階段增加的信息就不會在下一階段中丟失了。需求分析的過程是將企業(yè)業(yè)務(wù)模型到企業(yè)信息模型的映射的過程，實現(xiàn)從業(yè)務(wù)模式向信息模型的轉(zhuǎn)變、業(yè)務(wù)需求向信息功能的映射、企業(yè)基礎(chǔ)數(shù)據(jù)向企業(yè)信息的抽象，通過抽

36、象和建模，將企業(yè)業(yè)務(wù)實體抽象成為信息對象、業(yè)務(wù)運作模式抽象成為信息對象的屬性和方法，建立面向?qū)ο蟮钠髽I(yè)信息模型。uml通過構(gòu)造模型來更加深入地理解需求，分析的目標(biāo)就是指明必須實現(xiàn)什么的規(guī)格說明，它描述了系統(tǒng)的行為、特性或?qū)傩?，是在開發(fā)過程中對系統(tǒng)的約束（而不是如何完成這些內(nèi)容）。需求是開發(fā)者和用戶交互的一個過程，任何一方的不投入都會導(dǎo)致項目的失敗。由于售前咨詢的定位，必然存在著客戶溝通和客戶合作態(tài)度的問題（再者用戶不是專業(yè)人士），因而開發(fā)者需要以積極的態(tài)度告訴客戶需求開發(fā)的方法，以獲取客戶的支持。5.1 軟件需求層次軟件需求包括三個不同的層次業(yè)務(wù)需求、用戶需求和功能需求，也包括非功能需求。業(yè)務(wù)

37、需求反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，在項目視圖與范圍文檔中予以說明。用戶需求描述用戶使用產(chǎn)品必須要完成的任務(wù)，可使用用例文檔或場景腳本予以說明。功能需求定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。所謂特性是指邏輯上相關(guān)的功能需求的集合，給用戶提供處理能力并滿足業(yè)務(wù)需求。無論哪個層次的需求，其目的都是為了說明系統(tǒng)要完成的內(nèi)容，可采用不同的模型進行分析和展現(xiàn)： 業(yè)務(wù)需求，通過業(yè)務(wù)建模（即采用業(yè)務(wù)架構(gòu)理解客戶業(yè)務(wù)），對企業(yè)目前的業(yè)務(wù)流程進行描述和評估 用戶需求，重心就是如何收集用戶的需求上，即確定角色和角色的用例，通過用例和場景說明客戶的工作內(nèi)容

38、和信息化需求 功能需求，依賴于用戶需求，是用戶需求在系統(tǒng)上的一個映射（mapping）。在這個層次上，為用戶做一個軟件原型是一個不錯的方法5.2 uml與相關(guān)模型uml是一種圖形化的面向?qū)ο蠼ＵZ言，通過不同的圖形表示來捕捉系統(tǒng)靜態(tài)結(jié)構(gòu)和動態(tài)行為的信息，建立起對象模型。考慮到售前咨詢過程更多的是理解和闡述客戶需求，因而可以將注意力聚焦在用例和活動圖上，即通過層次化的用例（use case）模型和時序模型描述企業(yè)范圍內(nèi)各種應(yīng)用的功能需求；通過逐級分解的活動模型（業(yè)務(wù)過程、子過程、活動）來細化描述業(yè)務(wù)。當(dāng)然也可適當(dāng)考慮類模型的分析，借此說明企業(yè)相關(guān)的實體和關(guān)系。5.2.1 uml概述uml的概念包

39、括了uml語義（semantics）和uml表示符（notation）兩個部分，uml語義定義了三種模型（類模型、狀態(tài)模型和交互模型），uml表示符提供了完整的語義定義，uml的表示符包括了下面的幾種主要的圖：類圖、用例圖、順序圖、協(xié)作圖、狀態(tài)圖、活動圖和部署圖。三種模型從不同的視角來描述系統(tǒng)： 類模型。描述了系統(tǒng)內(nèi)部對象及其關(guān)系的靜態(tài)結(jié)構(gòu)它們的標(biāo)識、與此同時其他對象的關(guān)系、屬性以及操作。類模型提供了放置狀態(tài)模型和交互模型的基本框架。類模型中最重要的概念是類、關(guān)聯(lián)和泛化。 狀態(tài)模型。描述的是對象當(dāng)中與時間相關(guān)的內(nèi)容，如表明變化的事件，以及那些界定了事件上下文的狀態(tài)。狀態(tài)模型是由多張狀態(tài)圖所構(gòu)成

40、的，一個類有一張狀態(tài)圖，每張狀態(tài)圖都包含了一些重要的時序行為。 交互模型。描述的是對象如何協(xié)作以達成某種結(jié)果。交互模型是跨越了許多對象的整體視圖。交互可以在不同的抽象層次上建模。在高層上，用例描述的是系統(tǒng)如何與外部參與者交互（用例表示功能片段，有助于捕獲非形式化的需求）；順序圖提供更多的細節(jié)，顯示交互的對象，以及對象交互的時間順序；活動圖提供最詳盡的細節(jié)，以顯示某次活動中處理步驟之間的控制流。5.2.2 用例模型用例是從用戶的角度看待系統(tǒng)，用例標(biāo)識系統(tǒng)的功能，并根據(jù)用戶的觀點組織這些功能。用例模型包括參與者、用例和用例圖三部分構(gòu)成： 參與者（actor）。系統(tǒng)的直接外部用戶直接與系統(tǒng)通信的一個

41、對象或一級對象，但并不是系統(tǒng)的一部分。 用例。用例是系統(tǒng)通過與參與者的交互可以提供的一段連貫的功能，每個用例會涉及一個或多個參與者以及系統(tǒng)本身。用例把與此一部分系統(tǒng)功能相關(guān)的所有行為組合在一起，包括普通主線行為、普通行為的變體、異常條件、錯誤條件和請求取消。 用例圖。uml用一套圖形表示法來總結(jié)用例，如下圖。其中矩形包含了系統(tǒng)的用例，參與者列在矩形外面。系統(tǒng)的名稱可以寫在矩形的某條邊的附近。橢圓內(nèi)部的名稱表示用例?！盎鸩袢恕眻D標(biāo)表示參與者，參與者的名稱列在圖標(biāo)下方或者臨近圖標(biāo)的地方。實線連接用例及其參與者。5.2.3 順序模型順序模型詳細描述用例的主題。有兩種順序模型：場景和順序圖，順序圖具有

42、更加結(jié)構(gòu)化的形式。場景。是指系統(tǒng)在某個特定的執(zhí)行期內(nèi)所發(fā)生的一系列事件，如用例。場景的范圍可以變化它可以包括系統(tǒng)中的所有事件，或者只包括與某些對象有密切聯(lián)系或由這些對象產(chǎn)生的那些事件。場景可以是執(zhí)行一個實際系統(tǒng)的歷史記錄，或者是執(zhí)行擬采用系統(tǒng)的預(yù)想實踐。順序圖。文本格式便于編寫，但無法清晰地顯示每條消息的發(fā)送者和接收者，順序圖顯示了交互的參與者之間的消息順序。每個用例需要一張或多張順序圖來描述其行為。每張順序圖顯示用例的一個特定的行為序列，同時用例內(nèi)部的每種異常條件也需要繪制順序圖。在多數(shù)系統(tǒng)中，會有無限多的場景，因此全部顯示是不可能的，但是應(yīng)該試著詳細描述所有的用例，并用順序圖來覆寫基本的行

43、為種類。5.2.4 活動模型活動圖顯示了組成復(fù)雜過程的步驟序列，例如算法和工作流。與順序圖類似，活動圖可以顯示控制流，但專注于操作而不是對象?；顒訄D很像傳統(tǒng)的流程圖，一步一步地顯示流程控制。在活動圖中，拉長了的橢圓表示活動，箭頭表示活動的順序，菱形表示決策點，粗線條表示并發(fā)線程的分流和合并，帶輸出箭頭的實心圓表示活動圖的起點，靶心（空心圓圍繞著實心圓）表示終止點。5.2.5 類模型類描述了擁有相同特性（屬性）、行為（操作）、關(guān)系種別以及語義的一組對象，類中的對象有著相同的屬性和行為模式。類圖提供了地類及其關(guān)系進行建模的一種圖形化的表示法。類的uml表示法是一個方框，方框里面是類名（用黑體字表示

44、，一般用單數(shù)名詞表示）。值和屬性。屬性是類的一個命名特性，它描述了類的每個對象都擁有一個值，值就是一段數(shù)據(jù)。uml表示法會在類方框的第二格里列舉屬性，而第二格里也可能會包含屬性，其表示法是列出每個屬性名，之后跟著等號和取值。操作和方法。操作是一個函數(shù)或過程，可以應(yīng)用于類的對象，或被對象使用。方法是類中操作的實現(xiàn)。uml表示法在類的第三格里列舉操作。可以通過鏈接、關(guān)聯(lián)、泛化和繼承來建立對象與類之間的關(guān)系。由于類與類之間的關(guān)系內(nèi)容比較得雜，且不是售前咨詢關(guān)注的重點，本文就不細述。5.3 用uml進行需求分析采用uml進行需求分析，我們通過確定系統(tǒng)的整體邊界來進行需求建模，然后識別用例，用場景和順序

45、圖來充實用例：5.3.1 確定系統(tǒng)邊界首先，必須要了解系統(tǒng)的準(zhǔn)確范圍，也即系統(tǒng)邊界，以便把功能確定下來。這意味著必須要確定系統(tǒng)包括哪些功能（或者涵蓋的業(yè)務(wù)范圍），更重要的是，要確定系統(tǒng)應(yīng)該忽略哪些內(nèi)容。在確定系統(tǒng)邊界階段，可以把系統(tǒng)看作是一個可以和外界交互的黑盒（內(nèi)部系統(tǒng)被隱藏了），我們要確定的是系統(tǒng)的意圖以及系統(tǒng)呈現(xiàn)給參與者的視圖。通過不應(yīng)該把人看成是系統(tǒng)的一部分人是必須與系統(tǒng)交互的參與者，但他們的活動不受系統(tǒng)控制。5.3.2 尋找參與者一旦將系統(tǒng)邊界確定下來之后，就要確定與系統(tǒng)直接交互的外部對象，這些都是系統(tǒng)的參與者。參與者可以是人、外部設(shè)備和其他軟件系統(tǒng)。在尋找參與者的過程，要找的不是個

46、體，而是行為原型。每個參與者都代表一個理想化的會執(zhí)行一部分系統(tǒng)功能的用戶，外部對象可能會有多個參與者。5.3.3 尋找用例對于每個參與者，列舉參與者使用系統(tǒng)的不同方式，每一種方式都是一個用例。用例將系統(tǒng)功能劃分成少數(shù)離散單元，所有的系統(tǒng)行為都必須處在某種用例之下。每個用例都應(yīng)該表示系統(tǒng)所提供的一類服務(wù)，即給參與者提供價值的內(nèi)容。在用例中，要努力使所有的用例都保持相似的層次細節(jié)。此時可繪制初步的用例圖，顯示參與此同時者和用例，并將參與者連接到用例上。5.3.4 尋找初始和終止事件用例將系統(tǒng)功能拆分成離散單元，并顯示了每一個單元所涉及到的參與者，但它們并沒有清晰地顯示行為。要理解行為，就必須理解覆

47、寫每一個用例的執(zhí)行順序，我們可以從尋找發(fā)起每個用例的事件開始，確定哪個參與者發(fā)起了用例，并且定義它發(fā)送給系統(tǒng)的事件。在許多情況下，初始事件是對用例所提供服務(wù)的一種請求。同時，還應(yīng)該確定一個或多個終止事件以及每個用例中究竟要包含多少個終止事件。5.3.5 準(zhǔn)備普通場景對于每一個用例，準(zhǔn)備出一種或多種典型的對話，以獲得對系統(tǒng)期望行為的感覺。這些場景描述了主要的交互、外部顯示格式以及信息互換等（場景是在一組交互對象之間發(fā)生的一系列事件）。對于大多數(shù)問題來說，邏輯上的正確性要取決于交互序列，而不是交互的確切時間。5.3.6 增加變化和異常場景整理“普通”情形的場景，也即沒有任何異常輸入或者錯誤的交互。

48、因而在準(zhǔn)備好典型場景之后，就要考慮特例了，此外還要考慮錯誤情形（包括無效值和沒有響應(yīng)）。5.3.7 尋找外部事件檢查場景，尋找所有的外部事件，包括所有的輸入、決策、中斷以及用戶或外部設(shè)備之間的往來交互，外部事件可以觸發(fā)目標(biāo)對象動作。把信息傳輸給對象是一種事件，許多事件都有參數(shù)。應(yīng)該把對控制流有著相同效果的事件都組織在同一個名稱下面，即使它們的參數(shù)值不同的時候也要這么作。事件之間的差異取決于應(yīng)用。為每一種場景都準(zhǔn)備一張順序圖，順序圖要清晰地顯示每次事件的發(fā)送者和接收者。如果同一個類的多個對象都參與了場景，那就要給每一個對象分配一列，通過檢視圖中的某一列，就可以觀察到會直接影響某個對象的事件，這樣

49、從順序圖就可以總結(jié)出每個類接收和發(fā)送的事件。5.3.8 編制復(fù)雜用例的活動圖順序圖捕獲參與者之間的會話與相互作用，但并沒有清晰地給出分支和決策，而活動圖通過歸檔控制流中的分叉和匯合，對業(yè)務(wù)邏輯進行分析。5.3.9 組織參與者和用例下一步是用關(guān)系（包括、擴展和泛化）來組織用例了。5.4 組織原型界面用戶界面是以一致的方式給系統(tǒng)用戶提供訪問其領(lǐng)域?qū)ο?、命令和?yīng)用選項的一個或一組對象。在售前咨詢階段，原型界面的展現(xiàn)和功能描述是關(guān)鍵環(huán)節(jié)。在售前咨詢階段，界面要求通常是模糊的、不明確的，多數(shù)用戶往往并不能提出明確的、全局的界面需求。因而組織原型界面，要先草擬出一種示例界面，將應(yīng)用程序的操作可視化表示，并

50、看看有什么重要內(nèi)容被遺漏。原型界面的組織步驟可為：確定所涉及的界面元素，分析用戶特征并定義用戶角色，依據(jù)用戶角色的界面需求設(shè)計界面原型并不斷改進完善。通常一個軟件界面的元素包括界面主顏色、字體顏色、字體大小、界面布局、界面交互方式、界面功能分布、界面輸入輸出模式。其中：對用戶工作效率有顯著影響的元素包括：輸入輸出方式、交互方式、功能分布，在使用命令式交互方式的系統(tǒng)中，命令名稱、參數(shù)也是界面元素的內(nèi)容，如何設(shè)計命令及參數(shù)也很重要。影響用戶對系統(tǒng)友好性評價的元素則有：顏色、字體大小、界面布局等，這種劃分不是絕對的，軟件界面作為一個整體，其中任何一個元素不符合用戶習(xí)慣、不滿足用戶要求都將降低用戶對軟

51、件系統(tǒng)的認可度，因而在做原型界面時要盡量地考慮友好性。6 編寫技術(shù)方案解決方案的路徑是說明問題分析問題解決問題的過程。編制解決方案的過程是從業(yè)務(wù)理解到技術(shù)方案編制的過程，即通過業(yè)務(wù)架構(gòu)分析，了解組織的戰(zhàn)略、相關(guān)業(yè)務(wù)的組織結(jié)構(gòu)和職能、關(guān)鍵流程，從而構(gòu)建企業(yè)的應(yīng)用系統(tǒng)架構(gòu)，并根據(jù)應(yīng)用系統(tǒng)需求提供技術(shù)解決方案。根據(jù)此理解，解決方案的編寫路線如下：整個技術(shù)解決方案包括五部分：6.1 業(yè)務(wù)理解此部分內(nèi)容旨在闡述公司對客戶業(yè)務(wù)的理解，通過項目背景、業(yè)務(wù)架構(gòu)、問題與變革三部分分析，說明客戶的業(yè)務(wù)現(xiàn)狀、遇到問題和未來可能的變革，以實現(xiàn)在業(yè)務(wù)層面與客戶的共鳴。6.1.1 項目背景分析項目背景分析包括競爭環(huán)境分析

52、、業(yè)務(wù)標(biāo)桿分析和信息化標(biāo)桿分析三部分內(nèi)容：競爭環(huán)境分析。競爭環(huán)境包括宏觀環(huán)境和任務(wù)環(huán)境，其中宏觀環(huán)境包括政治、經(jīng)濟、社會和技術(shù)環(huán)境等，任務(wù)環(huán)境是指與企業(yè)直接有關(guān)的產(chǎn)業(yè)環(huán)境，通?？刹捎貌ㄌ氐母偁幜δＰ瓦M行分析。波特認為影響行業(yè)競爭結(jié)構(gòu)及競爭強度的主要因素包括行業(yè)內(nèi)現(xiàn)有企業(yè)、潛在的進入者、替代品制造商、供應(yīng)商和顧客（產(chǎn)品購買者）。業(yè)務(wù)標(biāo)桿分析?；鶞?zhǔn)化分析法（benchmarking）就是將本企業(yè)各項活動與從事該項活動最佳者進行比較，從而提出行動方法，以彌補自身的不足，是一種評價自身企業(yè)和研究其他組織的手段。信息化標(biāo)桿分析。針對相關(guān)信息化領(lǐng)域，提供信息化標(biāo)桿分析。6.1.2 企業(yè)現(xiàn)狀和業(yè)務(wù)架構(gòu)分析業(yè)

53、務(wù)架構(gòu)分析包括企業(yè)基本情況、業(yè)務(wù)戰(zhàn)略、組織架構(gòu)、業(yè)務(wù)模式及關(guān)鍵流程和信息化現(xiàn)狀分析等五部分內(nèi)容：企業(yè)基本情況分析。企業(yè)生產(chǎn)經(jīng)營概況，包括公司簡介、主要業(yè)務(wù)和效益情況、在同行業(yè)內(nèi)所處的地位等。企業(yè)業(yè)務(wù)戰(zhàn)略分析。企業(yè)的使命、目標(biāo)、價值觀和企業(yè)的競爭戰(zhàn)略（量化的競爭目標(biāo)和競爭實施計劃）。企業(yè)組織架構(gòu)分析。企業(yè)的組織架構(gòu)設(shè)置情況、組織各單元的主要職能、關(guān)鍵崗位設(shè)置和崗位職責(zé)情況。業(yè)務(wù)模式及關(guān)鍵流程分析。本部分內(nèi)容是關(guān)鍵，采用價值鏈理論進行業(yè)務(wù)模式分析，并采用編目的方法進行流程描述和說明。信息化現(xiàn)狀分析。描述企業(yè)相關(guān)的應(yīng)用系統(tǒng)、軟/硬件設(shè)備投入情況，以及企業(yè)信息化管控模式。6.1.3 問題定義與變革分析

54、問題定義與變革分析包括三部分內(nèi)容：宏觀問題。根據(jù)環(huán)境和標(biāo)桿分析，指出企業(yè)業(yè)務(wù)模式各環(huán)節(jié)存在的問題及改進建議。業(yè)務(wù)流程存在的問題。根據(jù)業(yè)務(wù)流程現(xiàn)狀分析，分析企業(yè)業(yè)務(wù)流程存在的問題和改進建議。企業(yè)未來可能的變革分析。根據(jù)問題分析、企業(yè)戰(zhàn)略和標(biāo)桿分析，指出企業(yè)未來業(yè)務(wù)可能存在的變革。6.2 需求分析此部分內(nèi)容旨在闡述公司對客戶需求的理解，通過系統(tǒng)目標(biāo)、系統(tǒng)邊界分析、系統(tǒng)功能需求分析、系統(tǒng)性能需求分析和技術(shù)要求等內(nèi)容，說明公司對客戶需求的理解，作為與客戶進行需求交流的基準(zhǔn)。6.2.1 系統(tǒng)目標(biāo)分析系統(tǒng)目標(biāo)敘述該項軟件開發(fā)的意圖、應(yīng)用目標(biāo)、作用范圍以及其他應(yīng)向讀者說明的有關(guān)該軟件開發(fā)的背景材料。解釋被開

55、發(fā)軟件與其他有關(guān)軟件之間的關(guān)系： 待開發(fā)的系統(tǒng)名稱 系統(tǒng)是為誰而開發(fā)的，包括項目的任務(wù)提出者、開發(fā)者、用戶 系統(tǒng)解決哪些問題，清晰地界定系統(tǒng)范圍，以及系統(tǒng)功能所解決的客戶問題 系統(tǒng)會用在什么地方，說明系統(tǒng)的部署要求 項目的進度要求6.2.2 系統(tǒng)邊界分析從用戶的角度來看，他們并不想了解系統(tǒng)的內(nèi)部結(jié)構(gòu)和設(shè)計，他們所關(guān)心的是系統(tǒng)所能提供的服務(wù)，也就是被開發(fā)出來的系統(tǒng)將是如何被使用的。所謂邊界，也就是將這個系統(tǒng)看成一個黑盒子，和外界的交互。系統(tǒng)邊界分析需要定義系統(tǒng)要與外部環(huán)境交互什么，確定系統(tǒng)邊界非常重要，是使用用例技術(shù)的基礎(chǔ)。系統(tǒng)邊界分析需要確定系統(tǒng)的參與者，所謂的參與者是指所有存在于系統(tǒng)外部并與

56、系統(tǒng)進行交互的人或其他系統(tǒng)。通俗地講，參與者就是我們所要定義系統(tǒng)的使用者。系統(tǒng)邊界分析要涵蓋以下內(nèi)容： 系統(tǒng)使用者。定義有哪些系統(tǒng)使用角色，各角色對系統(tǒng)的信息需求是什么 相關(guān)交互系統(tǒng)。定義有哪些交互系統(tǒng)以及系統(tǒng)之間的關(guān)聯(lián)關(guān)系，如需要與這些系統(tǒng)協(xié)同什么流程、交互什么信息 相關(guān)硬件設(shè)備系統(tǒng)。定義系統(tǒng)需要控制哪些硬件 系統(tǒng)管理者。定義系統(tǒng)的管理角色，系統(tǒng)管理角色對系統(tǒng)的需求是什么6.2.3 系統(tǒng)功能需求分析一般將系統(tǒng)需求分為功能、可用性、可靠性、性能、可支持性、設(shè)計約束等以下幾類，除了第一項功能性需求之外的其他需求都歸之為非功能性需求。用例模型主要用于描述系統(tǒng)的功能性需求，對于其他的非功能性需要用其他文檔來記錄?？刹捎靡?/p>