SOW‐7: 自動通知業(yè)務(wù)點有關(guān)訂單發(fā)貨日期。

　　SOW‐8: 有關(guān)發(fā)票內(nèi)容自動轉(zhuǎn)發(fā)會計部門，建立有關(guān)應(yīng)收賬款記錄。

　　SOW 并不是我們所說的系統(tǒng)功能，是在項目完結(jié)后這個系統(tǒng)所應(yīng)該提供的最終目的。以上的SOW 說明了這個項目的范圍，包括的有關(guān)部門及現(xiàn)有系統(tǒng)的連接。在客戶確認后每一個SOW 將當作一個ToR處理，這個ToR 便成為整個系統(tǒng)建設(shè)項目中的一個子項目(也是子項目名稱的起源)。如何才知道我們建立的SOW 已經(jīng)包含整個系統(tǒng)的各個部門，如何保證這個范圍能夠有效地提供一套“訂單管理”的系統(tǒng)，這需要項目負責人對行業(yè)有一定的理解，同時為保證開發(fā)過程中能夠控制范圍的變動，在有關(guān)文檔中明確說明SOW 所包含或不包含那些工作。利用“包含(Inclusive)”和“不包含(Exclusive)”的說明來牢牢地建立一個固定項目范圍。

　　在項目規(guī)劃完成后，系統(tǒng)分析師便按照被分派的SOW 采用ToR 的調(diào)查方式進行深入調(diào)查，對有關(guān)工作進行訪談，理解有關(guān)SOW 的工作流程后對有關(guān)流程進行分析，并找尋初步的解決方案。如何利用科技取代電話咨詢庫存量，利用科技取代傳真把訂單從業(yè)務(wù)部門傳送回銷售部門，或取代傳真送貨通知單到運輸部門，取代內(nèi)部文件傳送發(fā)票副本到會計部門等等工作，什么時候需要進行數(shù)據(jù)收集，需要進行數(shù)據(jù)更新，需要打印發(fā)票或其它有關(guān)報告等工作便成為項目的功能需求。

　　如果在開發(fā)過程中，用戶認為需要貨品在運送完畢后，收貨單應(yīng)該自動確認有關(guān)應(yīng)收賬款的作業(yè)流程，或者需要增加萬一退貨后的訂單處理操作流程時，我們便可以依據(jù)原SOW 來控制項目的范圍變動，因為這兩項操作流程并沒有在項目的SOW 中說明。如果用戶認為一定需要增加這兩個操作流程，那么項目的范圍會變動，帶出額外的工作量，額外的開發(fā)時間，額外的投資預算，修正系統(tǒng)的架構(gòu)，增加軟件模塊，追加人力資源等等因應(yīng)的后果。有能力的項目負責人會盡量說服客戶把有關(guān)工作在目前的系統(tǒng)建設(shè)完成后才進行處理，避免延誤項目的進度和交付日期。

　　這個系統(tǒng)集成的項目再一次說明如何從項目范圍中建立有關(guān)功能需求。建立功能需求是軟件從業(yè)人員的責任，不是客戶或用戶能夠提供的內(nèi)容。在完成人工操作過程分析訂立系統(tǒng)的功能需求后，更要進一步考慮如何讓科技提升企業(yè)的運營效率。也許在設(shè)計過程中發(fā)現(xiàn)當時的貨品運送流程是從倉庫直接送到銷售部門，再由銷售部門安排貨品連同發(fā)票一起送到客戶的指定地點，設(shè)計師可能考慮是否可以直接從倉庫把貨品運送到客戶指定地點，銷售部門另外把有關(guān)發(fā)票直接送交客戶?這個改變會為企業(yè)帶來多大效率改善?有了確實的構(gòu)思后便需要說服用戶這個系統(tǒng)如何能夠更有效地完成有關(guān)貨品運送的過程，要說服用戶這些功能可以提升貨品運送的效率和客戶滿意度，讓銷售部門和運輸部門可以體會未來的工作流程將有所改變。決定最終解決方案及用戶認可后依據(jù)分析師的建議建立有關(guān)系統(tǒng)的功能，交由系統(tǒng)設(shè)計師對有關(guān)功能進行模塊組合及邏輯設(shè)計。到這里，我們可以清楚知道系統(tǒng)建設(shè)不是依據(jù)客戶的需求而建設(shè)，是依據(jù)如何達到項目最終目的和項目的最終交付