沒有乙個專案不是重視需求調查的。從第一天開始，開發人員就拿著乙個筆記本，把使用者都拉到會議室，詢問他們的業務流程是什麼樣的。知道了業務流程，開發者剩下的工作就明確了，一條一條的去實現他們，系統就ok了。但是，業務流程可以代替需求嗎？
實際上，在業務流程的背後，有乙個更加根本的因素——商業需求。商業需求才是真正的需求，業務流程只是一種實現手段而已。
開發者詢問使用者：「你們的業務流程是什麼樣的？」這個問題其實是很難回答的。業務流程的制定首先是要最大限度的滿足商業需求。並且，業務流程要受到各種條件的制約，it系統也是這個條件之一。開發者問使用者業務流程是什麼樣的，使用者也要問開發者系統的設計是什麼樣的，能達到什麼樣的效能指標，在這個基礎上才能制定合理的業務流程。
比如一家移動通訊公司，在處理新使用者入網的時候採用了乙個這樣的流程，按流程先後順序：
1：首先把sim卡和號碼在交換網路上做對應關係的註冊；
2：市場部把sim卡存入一定的金額，發給銷售商，收取銷售商的貨款；
3：銷售商把卡賣給使用者，使用者填寫入網合同，sim裝入手機可以立即通話；
4：銷售商把入網合同交給市場部，市場部資料錄入人員將使用者的資料錄入系統；
5：計費系統按照使用者選擇的資費對話單進行計費；
6、市場部按照使用者的消費情況給銷售商計算佣金和返利。
這個流程的制定並不是業務部門可以單獨確定的，他和it系統有著很深的聯絡。使用者買到sim卡以後，需要立即可以通話，但是由於it系統的條件有限，無法做到及時向交換網路註冊sim卡，所以就必須先把sim卡和號碼在交換網路上做好，再發放到銷售點去。由於採用了這樣的辦法，又產生了乙個新的問題：買到sim卡的使用者可以立刻打**，但是在資料錄入人員錄入使用者的資料之前，他們在系統裡是沒有資料的，也沒有計費策略，這是一段資料空白期。怎樣控制空白期的時間長度，怎樣對這些通話進行計費，怎樣防止空白期的惡意欠費。。。又形成了乙個個新的問題，於是又要發明乙個個業務流程來處理這個問題。
it系統和業務流程是緊密關聯的，他們互相制約，也互相促進。如果希望先把業務流程定下來，再回頭去開發it系統，這個難度是很大的。開發it系統，需要把目光看的更深入一點：it系統和業務流程是為什麼服務的。
it系統和業務流程都是為了更好的實現商業需求。商業需求是企業為使用者服務、與夥伴合作的過程中產生的需求，每個商業需求都是關係到實際的商業利益的。比如說剛才那個使用者入網的流程，如果按照商業需求來看，他是為了滿足下面幾點：
1、使用者買到sim，可以立刻裝到手機裡面打**；
2、使用者的通話可以按照他選擇的資費策略進行計費；
3、使用者交的錢計入他的賬戶，通話費用從這個賬戶中扣除；
4、使用者填寫的合同歸檔，作為日後辦理相關事宜的依據；
5、營業員收的錢計入他自己的賬本，待審核人員下班後核查；
6、市場部根據使用者的消費情況付給**商佣金。
這幾點就是「入網」這個業務流程需要滿足的商業需求。企業在實現這些商業需求的過程中，一定是遇到了一些麻煩，於是希望有乙個it系統來幫助自己。it系統的開發者要和企業使用者坐在一起，先把這些商業需求搞清楚。在這個基礎上，一方面要設計支援系統，另一方面要根據支援系統的情況來制定新的流程。最終實現自動化的業務流程，更好的滿足商業需求。
從商業需求中提取重要的元素，分析這些元素的行為和相互之間的關係，我們就可以得到乙個重要的東西：領域模型。
領域模型應該**於企業的商業活動，而不應該是it系統的業務流程。
設計領域模型，最基本的方法就是抓住一些明顯的元素進行分析。更進一步，需要抓住一些隱含的元素。業務領域中有經驗的人員，他們在分析問題時候，有時候會隨手畫出乙個草圖，寫下一些數值，或者查詢某個表單，這都是重要的領域元素。了解這些東西，可以使複雜的領域問題變得容易理解，使領域模型更加符合企業的實際情況。
當這個模型漸漸清晰的時候，開發者和使用者就可以一邊進行it系統的設計，一邊設計出更加合理高效的業務流程。有了乙個個實際的東西擺在面前，使用者也能很容易的回憶起商業活動中一些重要的細節。比如看到這個租機合同，開發者會問：「這個合同有什麼用處？」使用者回答說：「我知道乙個用處，使用者辦理資費變更的時候，需要檢查一下這個合同，有些資費形式是合同不允許的。」
於是開發者就在資費變更的流程中記下這樣的**：
ifnot
使用者->
合同->
允許(資費)
then
exception(
"使用者的合同禁止該資費")
endif
下一步的工作，就是繼續將這個商業需求的細節搞清楚。「合同如何判斷乙個資費形式是否允許，是判斷這個資費的收益率，還是判斷他的品牌型別。。。」
不要被表面的業務流程所迷惑，透過表面，看到背後的商業需求，你會發現需求原來非常穩定，這麼多年來其實變化不多。也不需要知道所有的細節性的需求，只要了解比較重要的20％的需求，其實就可以開始進行系統的設計和編碼了。把眼光放在商業需求上，最終的業務流程才能最大限度的滿足需要，it系統也能面臨少一點的「需求變更」。
業務流程不是需求
沒有乙個專案不是重視需求調查的。從第一天開始，開發人員就拿著乙個筆記本，把使用者都拉到會議室，詢問他們的業務流程是什麼樣的。知道了業務流程，開發者剩下的工作就明確了，一條一條的去實現他們，系統就ok了。但是，業務流程可以代替需求嗎？實際上，在業務流程的背後，有乙個更加根本的因素 商業需求。商業需求才...
業務流程管理
業務流程管理 課程背景 當今企業之間的競爭，實際上是商業模式及流程能力之間的競爭。一方面，流程是實現商業模式的核心載體，企業需要打造以客戶為導向的端到端流程。另一方面，流程是企業管理體系的關鍵模組，隨著企業的成長，需要不斷提公升流程成熟度，把例外變成例行 把經驗教訓總結到流程中去。隨著資訊時代的來臨...
變更業務流程
1 提交申請 sp於每月18日 前通過sims 向接入省公司提交新增業務申請。2 新增業務初評與測試 sp配合省公司於當月20日前 完成新增業務初評，並對 初評通過的業務完成測試 包括業務測試和計費測試 3 新增業務評估 省公司於當月22日前通過sims電子打分系統進行業務評估。接入省公司受理部門於...