产品设计设计一款通用型合同管理系统

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