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

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

对 ToB 产品来说，大多数情况下不需要 PM 拥有多么大的脑洞，只需要搞清客户需求，知道他们如何在线下处理各项工作即可。

因为每一个新奇的想法都需要公司付钱，而客户并不一定会接受，所以不用乱加天马行空的想法，甚至暂时不去迎合市场需要。比如电子签证。

具体来说，需要先搞清以下问题：

• 客户来自哪个行业？
• 系统的需求方来自哪个部门？
• 客户要用系统处理哪些事情（哪些类型的合同）？
• 客户需要通过系统如何处理工作？照搬线下工作场景，还是对此做改进？
• 有哪些员工（角色）会用到系统？使用频率分别有多高？

在进行相关市场调研后，我们找到五个有可能与合同管理软件发生关系的职能角色，以及他们的关键需求：

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

对合同管理来说，实际上每一类合同都有自己相应的处理方式（可以参考百科中介绍的合同类型），但为每种类型的合同分别设计流程又不切实际。

因此需要产品经理事先了解每一类合同的使用场景、信息结构和处理方式，然后结合已经确定好的边界（跟客户签下的合同就是边界），对它们进行抽象化处理。

在简单地了解客户需求后，顺便梳理一下有关合同管理的业务流程：可以把这个流程看作是“实际业务处理流程+理想化流程”的集合体，因为客户采购一款系统并不仅仅只是想把线下工作照搬到线上，更希望带来管理水平方面的提升。

此处省略长篇大论的分析，直接说结论！

1. 合同管理的业务流程

下图就是合同管理最基本的业务流程；五个角色是抽象出来的用户分类，真实情况下并不一定会按照这样的职能分配进行管理，但流程大同小异：

在“合同管理员”角色完成“合同录入”并审批通过后，即标志着该合同正式生效——这是理想状态下的流程：先立项，后签合同。

而对于小额合同，可能根本就不需要立项申请和法务审核（直接使用模板合同）；或者是客户选择把立项工作放在线下。这样的话，流程就变为下图：

上面两个流程比较粗略，接下来放大流程中两处比较重要的细节：

1. 审批
2. 执行

审批有两个层面的意思，一是人工审批（由领导主观意愿决定），二是系统控制（为需要控制的数据类型设置阈值）：

这里的外部系统不仅可以是供应链系列的库存系统，也可以是财务系列的预算系统，一个合同管理软件有太多地方可以跟其他系统建立接口了，这里只是举例。

把对调外部系统数据和审批流程放在一起是为了方便解释“审批”，所以画的不太科学哈（费了半天劲，结果审批没通过~

合同执行包含：业务层面的执行（项目进度、收发货进度），财务层面的执行（收付款进度，开票进度）：

这个图画的更简单了，能看懂就好。意思就是在执行环节，财务受业务（项目进度）制约；前半部分是合同按时履行的处理方式；后半部分表示业务人员拖进度时，财务可以对其进行“催办”。

先介绍这么多。

2. 功能清单

因为 ToB 项目大多都是分期完成的，很少会在系统设计之初就一次性列出功能清单，所以下表还是我第一次整理全部的功能……这才发现 ToB 项目原来这么复杂，而且估计还有遗漏的地方，仅供参考吧。

“一二三级菜单”并不是准确的菜单名，主要代表相应的功能点。

3. 信息设计

产品信息设计主要是介绍每个页面具体包含的内容（文字、图片、数据及类型等等）。作为回顾性总结，分别列出每个页面内容有些小题大作，所以本节只列出“合同录入”时页面包含的信息。

请忽略这个鸡肋的 Excel 配色~

表格中有个名词“会签”可能不太常用，意思是：当审批人无法决定时，可以拉一个人跟他一块审批；另外还有，虽然涵盖多个主体的合同也不太常见，但我们需要考虑到这种情况。

结语

利用三个工作日的下班时间整理完，欢迎批评和点赞！等我看完评论后再决定详细介绍哪个模块~

对了，本文没有提到当下比较热门的“电子签证”，因为这个功能相对比较独立，对合同管理系统来说属于锦上添花的部分，所以等后续有时间再介绍。（其实主要是因为我还没做过~

作者：产品路漫漫；微信公众号：产品路漫漫

本文作者 @产品路漫漫

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！