合同管理系統是一個企業參與信息化系統建設比較重要的一部分。本文結合筆者的項目經驗，嘗試為讀者呈現出一個具備行業通用性的、相對較完整的合同管理軟件設計思路。作為回顧性總結，也作為一個範例希望能幫到想轉戰 ToB 領域的同行。
一、合同管理系統做什麼？
對 ToB 產品來說，大多數情況下不需要 PM 擁有多麼大的腦洞，只需要搞清客戶需求，知道他們如何在線下處理各項工作即可。
因為每一個新奇的想法都需要公司付錢，而客戶並不一定會接受，所以不用亂加天馬行空的想法，甚至暫時不去迎合市場需要。比如電子簽證。
具體來說，需要先搞清以下問題：
- 客戶來自哪個行業？
- 系統的需求方來自哪個部門？
- 客戶要用系統處理哪些事情（哪些類型的合同）？
- 客戶需要通過系統如何處理工作？照搬線下工作場景，還是對此做改進？
- 有哪些員工（角色）會用到系統？使用頻率分別有多高？
在進行相關市場調研後，我們找到五個有可能與合同管理軟件發生關係的職能角色，以及他們的關鍵需求：
二、合同管理系統怎麼做？
對合同管理來說，實際上每一類合同都有自己相應的處理方式（可以參考百科中介紹的合同類型），但為每種類型的合同分別設計流程又不切實際。
因此需要產品經理事先了解每一類合同的使用場景、信息結構和處理方式，然後結合已經確定好的邊界（跟客戶簽下的合同就是邊界），對它們進行抽象化處理。
在簡單地瞭解客戶需求後，順便梳理一下有關合同管理的業務流程：可以把這個流程看作是“實際業務處理流程+理想化流程”的集合體，因為客戶採購一款系統並不僅僅只是想把線下工作照搬到線上，更希望帶來管理水平方面的提升。
此處省略長篇大論的分析，直接說結論！
1. 合同管理的業務流程
下圖就是合同管理最基本的業務流程；五個角色是抽象出來的用戶分類，真實情況下並不一定會按照這樣的職能分配進行管理，但流程大同小異：
在“合同管理員”角色完成“合同錄入”並審批通過後，即標誌著該合同正式生效——這是理想狀態下的流程：先立項，後籤合同。
而對於小額合同，可能根本就不需要立項申請和法務審核（直接使用模板合同）；或者是客戶選擇把立項工作放在線下。這樣的話，流程就變為下圖：
上面兩個流程比較粗略，接下來放大流程中兩處比較重要的細節：
- 審批
- 執行
審批有兩個層面的意思，一是人工審批（由領導主觀意願決定），二是系統控制（為需要控制的數據類型設置閾值）：
這裡的外部系統不僅可以是供應鏈系列的庫存系統，也可以是財務系列的預算系統，一個合同管理軟件有太多地方可以跟其他系統建立接口了，這裡只是舉例。
把對調外部系統數據和審批流程放在一起是為了方便解釋“審批”，所以畫的不太科學哈（費了半天勁，結果審批沒通過~
合同執行包含：業務層面的執行（項目進度、收發貨進度），財務層面的執行（收付款進度，開票進度）：
這個圖畫的更簡單了，能看懂就好。意思就是在執行環節，財務受業務（項目進度）制約；前半部分是合同按時履行的處理方式；後半部分表示業務人員拖進度時，財務可以對其進行“催辦”。
先介紹這麼多。
2. 功能清單
因為 ToB 項目大多都是分期完成的，很少會在系統設計之初就一次性列出功能清單，所以下表還是我第一次整理全部的功能……這才發現 ToB 項目原來這麼複雜，而且估計還有遺漏的地方，僅供參考吧。
“一二三級菜單”並不是準確的菜單名，主要代表相應的功能點。
3. 信息設計
產品信息設計主要是介紹每個頁面具體包含的內容（文字、圖片、數據及類型等等）。作為回顧性總結，分別列出每個頁面內容有些小題大作，所以本節只列出“合同錄入”時頁面包含的信息。
請忽略這個雞肋的 Excel 配色~
表格中有個名詞“會籤”可能不太常用，意思是：當審批人無法決定時，可以拉一個人跟他一塊審批；另外還有，雖然涵蓋多個主體的合同也不太常見，但我們需要考慮到這種情況。
結語
利用三個工作日的下班時間整理完，歡迎批評和點贊！等我看完評論後再決定詳細介紹哪個模塊~
對了，本文沒有提到當下比較熱門的“電子簽證”，因為這個功能相對比較獨立，對合同管理系統來說屬於錦上添花的部分，所以等後續有時間再介紹。（其實主要是因為我還沒做過~
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
