快生活 - 传播价值、传递关注!

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


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