編輯導讀：針對業務流程而設定的解決方案並不是萬能的，在系統有限的範圍內，產品設計需要對邊界進行了確定。本文作者從邊界的概念出發，對此展開了梳理和説明，與大家分享。
業務場景與行業的結合往往是最切實際的約束條件，同樣是電子商務網站，有些商品可以線上交易，而有些大宗商品卻無法突破支付與信任的限制，也許普通商品的電子商務網站無需對用户的信用體系做審查，但是大宗商品的交易網站就要負起審查的職責。
大宗商品如棉花、鋼鐵等，買賣的最小單位是批次、規格等，牽涉的金額在百萬甚至千萬不等，合同以及訂單的履約風險是用户比較關注的情況。例如棉花商品的信息與實際合同如下圖所示。
從通用的角度來看，針對業務流程而設定的解決方案總是有約束的，系統的範圍總是有限的；在需求定義階段，對系統的範圍進行界定是十分重要的。
如何確定需求的邊界，推薦的方式是通過上下文關係圖，實際上是數據流圖中的頂層圖。相關的思路就是將整個待開發系統理解成一個黑盒，然後標識出外部的參與者和系統的交互關係。
而在實際的操作中，上下文關係圖的應用有兩個問題：一個是系統太大，不容易一下子梳理出來。
01 範圍 vs 邊界範圍和邊界需要區分開來，範圍是指系統涉及哪些內容，而邊界則是系統與人的職責邊界。針對這個問題，《掌握需求過程》一書中有個精彩的例子，如下圖
首先來看看這張數據流圖。
- 這是一個產品銷售公司的銷售過程示意圖；
- 顧客需要買東西時就會打電話給公司銷售人員，公司銷售人員根據供應商的促銷數據向顧客報價，並根據當前庫存量來判斷能否響應該顧客的訂單；
- 如果顧客接受了這個價格，並且也有足夠的庫存量，銷售人員就會認為該訂單是有效的，並將其轉給信用核查員；
- 信用核查員根據顧客的歷史交易數據以其信用卡的情況來決定該訂單是否是安全的，然後將審核的結果返還給銷售人員；
- 如果審核的結果表示訂單是安全的，那麼銷售人員就將訂單記錄下來
- 而其他環節（諸如收款、物流）將根據這裏的訂單記錄來進行相應的處理
如果該企業打算投資20萬–30萬開發一個完成覆蓋進、銷、存管理的軟件系統（這個業務流程是必然涉及其中的），
那麼該如何選擇系統的邊界，例如選擇2號邊界，或者選擇2號邊界，並將與信用卡公司的交互功能去掉。如果你選擇的是2號邊界，但用户要求實現3號邊界，你將如何應對？
02 確定邊界很多時候軟件設計者考慮的過於全面，總想做一個大而全的系統，然而很多時候我們是根據項目的投入和資源來限制邊界範圍的，如果沒有項目成本與時間的限制，那麼確定邊界的意義就失去了很多。
如果系統只是實現“記錄訂單”的功能，那麼實際上意味着用户必須手動完成接訂單和信用核查的工作，系統只是起到了一個電子化的功能，換句話説，通過某種形式的Excel也能記錄大部分的數據。
這樣的系統顯然不是一個投入20萬-30萬的系統所應該採用的邊界，或許在開發一個通用性的進銷存產品（定價在幾百元）時就會將邊界定義在這裏。
那麼2號邊界呢，這時系統不僅實現了記錄訂單功能，還將自動根據該顧客的歷史交易記錄、提供的信用卡進行信用檢查，這裏實現的功能顯然與用户的投入相匹配的。只不過信用卡檢查可能會存在一些變數。
再來看看3號邊界，也就是實現訂單接收的自動化，可能的方法有呼叫中心、Web網站等。這些功能雖然很合理，但它是超出系統預算的，因此不應該將其納入系統的邊界內。
03 功能的取捨沒有免費的軟件功能，一定的項目時間與成本控制下，必定需要對軟件功能進行取捨，上面的例子，用户將邊界從2號移到3號，也就意味着你需要開發電子商務網站或呼叫中心；那麼緊接着的是一系列的思考：
- 建立呼叫中心後，需要不斷的根據產品信息更新語音流程，這需要支付很高的成本；而且數字中繼、設備的維護成本也比較高。
- 呼叫中心相比於人工服務其友好性更差，可能會降低用户滿意度；這樣客户可能會轉回人工台，並不會降低成本。
- 電子商務網站的建設成本只是一部分，維護成本更是大塊，她包括網絡帶寬費用、主機託管費用，而且安全性能保障更加重要。
- 你的顧客羣中電子商務網站的使用率是否高，投入產出比是否合適。
- 你所在的行業如果是大宗商品的交易又當如何，考慮到貨款金額巨大，是否需要先簽署合同。
創新邊界的問題，通常是把顧客、顧客行為習慣納入了系統的範圍。例如把購買機票後的值機服務延伸到了機場之外，而不是從到達機場後才開始。
而像前面所説的例子，則是考慮計算顧客對商品的消耗速度，直接在客户缺貨前主動營銷。這種方法早在王永慶早年開米店時就使用過了，他的米店會記錄每個客户兩次買米的間隔時間，然後在客户米缸快空時（安全庫存理論）提前派人送來，並且現將客户剩下的米倒出來，將新的米裝到米缸後再把這些米放在最上面。
更多的約束還不少呢，立足於具體的業務場景才是關鍵。
本文由@山人小道 原創發佈於人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議