产品设计：设计一款通用型合同管理系统（产品设计-设计一款通用型合同管理系统）
合同管理系统是一个企业参与信息化系统建设比较重要的一部分 。本文结合笔者的项目经验，尝试为读者呈现出一个具备行业通用性的 、相对较完整的合同管理软件设计思路 。作为回顾性总结，也作为一个范例希望能帮到想转战 ToB 领域的同行。
一、合同管理系统做什么？
对 ToB 产品来说，大多数情况下不需要 PM 拥有多么大的脑洞，只需要搞清客户需求 ，知道他们如何在线下处理各项工作即可。
因为每一个新奇的想法都需要公司付钱，而客户并不一定会接受 ，所以不用乱加天马行空的想法，甚至暂时不去迎合市场需要。比如电子签证。
具体来说，需要先搞清以下问题：
- 客户来自哪个行业？
- 系统的需求方来自哪个部门？
- 客户要用系统处理哪些事情（哪些类型的合同）？
- 客户需要通过系统如何处理工作 ？照搬线下工作场景 ，还是对此做改进？
- 有哪些员工（角色）会用到系统 ？使用频率分别有多高？
在进行相关市场调研后，我们找到五个有可能与合同管理软件发生关系的职能角色，以及他们的关键需求：
二、合同管理系统怎么做？
对合同管理来说，实际上每一类合同都有自己相应的处理方式（可以参考百科中介绍的合同类型），但为每种类型的合同分别设计流程又不切实际 。
因此需要产品经理事先了解每一类合同的使用场景、信息结构和处理方式，然后结合已经确定好的边界（跟客户签下的合同就是边界） ，对它们进行抽象化处理。
在简单地了解客户需求后，顺便梳理一下有关合同管理的业务流程：可以把这个流程看作是“实际业务处理流程 理想化流程”的集合体，因为客户采购一款系统并不仅仅只是想把线下工作照搬到线上，更希望带来管理水平方面的提升。
此处省略长篇大论的分析，直接说结论！
1. 合同管理的业务流程
下图就是合同管理最基本的业务流程；五个角色是抽象出来的用户分类，真实情况下并不一定会按照这样的职能分配进行管理，但流程大同小异：
在“合同管理员”角色完成“合同录入”并审批通过后 ，即标志着该合同正式生效——这是理想状态下的流程：先立项，后签合同。
而对于小额合同 ，可能根本就不需要立项申请和法务审核（直接使用模板合同） ；或者是客户选择把立项工作放在线下 。这样的话 ，流程就变为下图：
上面两个流程比较粗略 ，接下来放大流程中两处比较重要的细节：
- 审批
- 执行
审批有两个层面的意思 ，一是人工审批（由领导主观意愿决定），二是系统控制（为需要控制的数据类型设置阈值）：
这里的外部系统不仅可以是供应链系列的库存系统，也可以是财务系列的预算系统 ，一个合同管理软件有太多地方可以跟其他系统建立接口了 ，这里只是举例。
把对调外部系统数据和审批流程放在一起是为了方便解释“审批” ，所以画的不太科学哈（费了半天劲 ，结果审批没通过~
合同执行包含：业务层面的执行（项目进度、收发货进度），财务层面的执行（收付款进度 ，开票进度） ：
这个图画的更简单了，能看懂就好。意思就是在执行环节 ，财务受业务（项目进度）制约 ；前半部分是合同按时履行的处理方式；后半部分表示业务人员拖进度时 ，财务可以对其进行“催办” 。
先介绍这么多 。
2. 功能清单
因为 ToB 项目大多都是分期完成的，很少会在系统设计之初就一次性列出功能清单，所以下表还是我第一次整理全部的功能……这才发现 ToB 项目原来这么复杂，而且估计还有遗漏的地方，仅供参考吧 。
“一二三级菜单”并不是准确的菜单名，主要代表相应的功能点 。
3. 信息设计
产品信息设计主要是介绍每个页面具体包含的内容（文字 、图片、数据及类型等等）。作为回顾性总结 ，分别列出每个页面内容有些小题大作，所以本节只列出“合同录入”时页面包含的信息 。
请忽略这个鸡肋的 Excel 配色~
表格中有个名词“会签”可能不太常用，意思是：当审批人无法决定时 ，可以拉一个人跟他一块审批；另外还有，虽然涵盖多个主体的合同也不太常见，但我们需要考虑到这种情况。
结语
利用三个工作日的下班时间整理完 ，欢迎批评和点赞 ！等我看完评论后再决定详细介绍哪个模块~
对了，本文没有提到当下比较热门的“电子签证”，因为这个功能相对比较独立，对合同管理系统来说属于锦上添花的部分，所以等后续有时间再介绍。（其实主要是因为我还没做过~
作者：产品路漫漫；微信公众号 ：产品路漫漫
本文由 @产品路漫漫 原创发布于人人都是产品经理 。未经许可 ，禁止转载
题图来自Unsplash，基于CC0协议
