合同管理系統是一個企業參與信息化系統建設比較重要的一部分。本文結合筆者的項目經驗，嘗試為讀者呈現出一個具備行業通用性的、相對較完整的合同管理軟件設計思路。作為回顧性總結，也作為一個范例希望能幫到想轉戰 ToB 領域的同行。

一、合同管理系統做什么？

對 ToB 產品來說，大多數情況下不需要 PM 擁有多么大的腦洞，只需要搞清客戶需求，知道他們如何在線下處理各項工作即可。

因為每一個新奇的想法都需要公司付錢，而客戶并不一定會接受，所以不用亂加天馬行空的想法，甚至暫時不去迎合市場需要。比如電子簽證。

具體來說，需要先搞清以下問題：

• 客戶來自哪個行業？
• 系統的需求方來自哪個部門？
• 客戶要用系統處理哪些事情（哪些類型的合同）？
• 客戶需要通過系統如何處理工作？照搬線下工作場景，還是對此做改進？
• 有哪些員工（角色）會用到系統？使用頻率分別有多高？

在進行相關市場調研后，我們找到五個有可能與合同管理軟件發生關系的職能角色，以及他們的關鍵需求：

二、合同管理系統怎么做？

對合同管理來說，實際上每一類合同都有自己相應的處理方式（可以參考百科中介紹的合同類型），但為每種類型的合同分別設計流程又不切實際。

因此需要產品經理事先了解每一類合同的使用場景、信息結構和處理方式，然后結合已經確定好的邊界（跟客戶簽下的合同就是邊界），對它們進行抽象化處理。

在簡單地了解客戶需求后，順便梳理一下有關合同管理的業務流程：可以把這個流程看作是“實際業務處理流程 理想化流程”的集合體，因為客戶采購一款系統并不僅僅只是想把線下工作照搬到線上，更希望帶來管理水平方面的提升。

此處省略長篇大論的分析，直接說結論！

1. 合同管理的業務流程

下圖就是合同管理最基本的業務流程；五個角色是抽象出來的用戶分類，真實情況下并不一定會按照這樣的職能分配進行管理，但流程大同小異：

在“合同管理員”角色完成“合同錄入”并審批通過后，即標志著該合同正式生效——這是理想狀態下的流程：先立項，后簽合同。

而對于小額合同，可能根本就不需要立項申請和法務審核（直接使用模板合同）；或者是客戶選擇把立項工作放在線下。這樣的話，流程就變為下圖：

上面兩個流程比較粗略，接下來放大流程中兩處比較重要的細節：

1. 審批
2. 執行

審批有兩個層面的意思，一是人工審批（由領導主觀意愿決定），二是系統控制（為需要控制的數據類型設置閾值）：

這里的外部系統不僅可以是供應鏈系列的庫存系統，也可以是財務系列的預算系統，一個合同管理軟件有太多地方可以跟其他系統建立接口了，這里只是舉例。

把對調外部系統數據和審批流程放在一起是為了方便解釋“審批”，所以畫的不太科學哈（費了半天勁，結果審批沒通過~

合同執行包含：業務層面的執行（項目進度、收發貨進度），財務層面的執行（收付款進度，開票進度）：

這個圖畫的更簡單了，能看懂就好。意思就是在執行環節，財務受業務（項目進度）制約；前半部分是合同按時履行的處理方式；后半部分表示業務人員拖進度時，財務可以對其進行“催辦”。

先介紹這么多。

2. 功能清單

因為 ToB 項目大多都是分期完成的，很少會在系統設計之初就一次性列出功能清單，所以下表還是我第一次整理全部的功能……這才發現 ToB 項目原來這么復雜，而且估計還有遺漏的地方，僅供參考吧。

“一二三級菜單”并不是準確的菜單名，主要代表相應的功能點。

3. 信息設計

產品信息設計主要是介紹每個頁面具體包含的內容（文字、圖片、數據及類型等等）。作為回顧性總結，分別列出每個頁面內容有些小題大作，所以本節只列出“合同錄入”時頁面包含的信息。

請忽略這個雞肋的 Excel 配色~

表格中有個名詞“會簽”可能不太常用，意思是：當審批人無法決定時，可以拉一個人跟他一塊審批；另外還有，雖然涵蓋多個主體的合同也不太常見，但我們需要考慮到這種情況。

結語

利用三個工作日的下班時間整理完，歡迎批評和點贊！等我看完評論后再決定詳細介紹哪個模塊~

對了，本文沒有提到當下比較熱門的“電子簽證”，因為這個功能相對比較獨立，對合同管理系統來說屬于錦上添花的部分，所以等后續有時間再介紹。（其實主要是因為我還沒做過~

作者：產品路漫漫；微信公眾號：產品路漫漫

本文由 @產品路漫漫 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議