業務設計的靈活性陷阱

一個業務顧問，跟使用者談需求，聊銷售訂單的後續操作。

問題：訂單建立儲存後要不要稽核？

回答：可能要，不確定。

問題：如果要稽核，要幾級稽核？是否上一級管理人員是必須的層級。

回答：可能多級，現在想不清楚。是不是直接上級審的事情，有很多情況，不同單子，可能管理歸屬不一樣，現在這方面也不明確，可以到時候我自己選麼？

問題：訂單建立後要不要自動觸發生成交貨單？還是全部手工建立？

回答：可以吧，都行，可不可以都可以？

好，如果你是業務顧問，你會怎麼辦？

某個業務顧問是這麼做的：好的，既然你們很多功能需求不確定，那麼這樣，我給你設計成可配置化，給你們設定介面，到時候你們自己設定一下，後面要改的話，就自己簡單調一下就好了。

使用者說：好極了，太棒了。

。。。。

然後業務顧問就設計了：

訂單，可以設定成需要審批，也可以不審批。

審批的話，可以隨便選審批人，一層也行，多層也行。

訂單後可以自動建立交貨單，也可以選擇不自動，全部手工。

你覺得如何？會不會讚揚這個顧問，水平真高！

我只能說：呵呵了。

作為一個資料顧問，跟業務顧問一起進場，同步過來跟使用者談資料分析需求，注意，是業務設計的同時，不是業務系統跑了一段時間以後。當你想跟使用者聊聊訂單處理時效性，有沒有延遲稽核分析，有沒有延遲交貨分析時，當你瞭解到業務設計是上述時，你會怎麼想？直接崩潰。沒有既定的業務分類，沒有既定的業務規則，怎麼做分析？怎麼設計分析路徑？

我們常說，看一個顧問好不好，負不負責，是初級的還是高階的，一個點就是看他有沒有設計了一堆hard code的功能，還是在必要的地方設計做成配置項，具備靈活性。

我們也常常說，做專案和做產品不同，把專案交付物產品化還需要好長路要走，更復雜，對需求分析人員的要求更高，因為產品需要更多完整性和靈活性。

所以，好像上述那個業務顧問很厲害啊。

大錯特錯了。這是個靈活性陷阱。

做專案不是做產品，或者說，如果你願意，你有能力，做專案也可以做成產品，但關鍵是不能只做到產品級別。

把一個產品拋給使用者，然後結束，那不是高階，不是負責任，而是不負責任，用靈活性的謊言去掩蓋不負責任的態度和管理想法的缺乏。

討論需求是討論什麼？討論業務該怎麼做，不該怎麼做，怎樣的業務流程是正確的，怎樣的業務管理模式是正確的，是有所謂標準和規則的。這樣也可以，那樣也可以，代表了使用者沒有想法，顧問也沒有帶給他想法，這不是個合格的顧問，這不是應有的業務流程再造諮詢過程。

功能可以設計靈活，可以把專案做成產品，可以都做成配置項，但得進一步，把配置方案都做出來。要不然，不就等於扔了一個空的sap系統給使用者讓使用者自己實施麼？

所以，當面對使用者需求的不確定時，提供靈活性確實是個方向，但千萬不能濫用，更好的、更負責任的辦法是，和使用者繼續深入討論，得出結論，那才是真正的業務藍圖。