業務流程不是需求

2022-03-19 18:55:30 字數 2334 閱讀 7099

沒有乙個專案不是重視需求調查的。從第一天開始,開發人員就拿著乙個筆記本,把使用者都拉到會議室,詢問他們的業務流程是什麼樣的。知道了業務流程,開發者剩下的工作就明確了,一條一條的去實現他們,系統就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電子打分系統進行業務評估。接入省公司受理部門於...