随着社会节奏日渐加速,越来越多的企业加入了自动化办公OA(Office Automation)的大军,疫情期间更是让企业办公软件钉钉一度冲上了各大软件平台的榜首。 在企业办公中较为常见的场景有考勤打卡、出差报销和请假审批等,那么今天我们就来分享一下如何为ToB企业设计OA审批功能。 本次的设计链路主要分为3个环节: 一、 问题(场景) → 需求凡是需要多人分工协作的企业,无可避免都需要进行审批。既然钉钉、企业微信等各大办公软件上的审批功能都已经十分成熟了,为什么我们B端客户还需要自己做审批呢?原因有三: 因此,虽然OA审批已经是一个相对成熟的业务模块,但仍旧因行业和互联网化程度不同等原因而存在大量的特异化需求和市场。那么,不同公司的审批场景和需求有什么不同呢? 因为笔者面向的都是某一细分行业的客户,故此处我们先忽略行业性质,简单地来从规模上进行区分讨论。就自身经历而言,笔者既待过数十个人的小公司,也待过上千人的上市公司,对二者的审批流程区别有十分深刻的体会: 大公司的审批流程虽然繁杂,但如果使用口头审批等不太规范的流程,那么其中随随便便在报销金额上出点纰漏,累积下来就是非常高额的代价。 综上我们可以看出,大小规模公司之间的实际审批流程存在很大的差异性。因为笔者目前所涉客户以传统行业的小公司为主,故以下就专门针对传统行业的小公司审批流程来进行探讨。 传统行业小公司线下审批流程的问题常见于: 为什么传统行业小公司会容易产生这些审批上的问题呢? 那么,针对传统行业小公司的上述3个主要问题,我们整理出对应的需求如下: 二、需求→功能在了解到客户需求之后,我们需要通过设计功能和确立优先级去思考对应提供怎样的解决方案。针对上述3个需求,我们粗略地给出各自需求对应的模块清单: 1. 规范的审批SOP首先我们来讲如何什么算作一个完整的审批流程SOP:发起审批-等待审批-处理审批(结果告知)。 1)审批角色 在一个完整的审批SOP中,牵扯到的角色共分为4类: 上述是一个相对较完善的审批SOP,其中涉及到了4种角色。显然易见,这4种角色对「审批」事件的影响和关联程度有轻有重,那么这自然就需要依赖到权限层面的设计。 这里不展开讲权限层面的设计,但是无论选择哪种权限设计方式,最终需要明确的结论是:哪一些(类)账号可以发起审批、哪一些(类)账号可以处理审批、而哪一些(类)账号能够查看审批。 2)审批方式 常见的审批方式有3种:并行审批、串行审批、并串混合审批,这里就依赖于我们所面对企业的实际审批流是哪种方式来进行设计。 (并行审批) 无论是审批流,还是类似于WBS箭线图这类活动流,只要是以「流」这种形式所存在的任务,都可以与我们的电路图进行类比,即串联电路、并联电路,以及二者混合的电路。 在设计时,我们可以将工作流类比成电路图,那么思路也就会更为形象和开阔。 同时,我们需要在设计时考虑未来的可扩展性。 如若现在决策只支持并行审批,那么未来是否会存在并串混合审批的可能性?从产品角度上来讲,需要通过对业务的理解来给出一定的未来方向预测并融入业务设计中去,这样能够有效提升研发代码的有效性和可扩展性、避免推倒重来。 2. 数据沉淀&数据流在系统上操作审批,无疑会产生一系列的活动轨迹和行为数据,而这些数据才是系统能够带给客户的最大价值。那么,我们先来按照一个完整的审批流梳理一下对应会产生哪些数据: 在梳理好数据之后,我们需要一个完整的数据管理中心,即就是在整个OA审批流程中需要一个完整的审批单管理。审批单会根据其状态分为待审批、审批通过、审批拒绝(此处简单说明,暂不赘述发起人撤回和再次修改的更多场景)。 同时,审批单管理需要考虑好不同角色在不同场景下的使用需求。 系统虽然是无情的数字机器,但每一个电脑背后都是一个个真实的人在使用,那么我们就要以人为本,从人的角度去思考如何让审批单管理更贴合还原真实的使用场景。 例如,发起人的关注点:是否发起成功?何时审批通过?若被拒绝,被拒绝的原因是什么?我该如何修改后再次发起审批呢? 对应给出的解决方案应该为:发起后即时给出发起结果;提供审批进度查询、即时推送传达审批结果;审批流程受阻时,及时提供原因和解决方案。 审批人的关注点: 对应给出的解决方案应该为:提供审批待办和推送;在审批时,提供关联业务的表单跳转和查询;审批拒绝后,尤其需要提供对应的驳回原因说明。 上述只是提供了几种思路和高频场景,核心理念还是在于当我们设计功能时,要着重注意考虑和权衡不同角色的使用场景。因为这冰冷的数据背后,也是一个个和我们一样面对陌生系统无处下手的普通人。 3. 效率提升有人说过,产品经理70%的时间都花在了沟通上,但是其实很多从事传统行业的职业也是。他们在忙于自己手头工作的同时,将大部分的协作都简单地使用了电话、微信和当面沟通来处理,方式很简单,但效率却很低下。 因此,在审批流程的效率提升上,我们需要做的第一件要事就是降低沟通成本,将大部分的沟通场景使用系统来进行替代。 例如,发起人需要知道发起后由谁审批、共需要几个审批环节、当前在什么环节等信息,这个时候,我们就需要对应给出明确的审批流和当前进度等供发起人查询。 当审批人在操作审批时,发现报销表单中除金额填写有误外其余表单都是正确的,那么在驳回该项审批时,就需要能够直接注明驳回原因,而不是再私下发微信找到审批人去进行说明。 帮助审批流中的不同角色减少不必要的额外沟通,就已经能够帮助客户提升大部分场景下的工作效率了。 除此之外,也可以像钉钉那样提供一些审批效率的智能分析统计,比如在审批环节中,谁的审批效率最低,平均每个人的审批处理时长是多久等等,从而可以帮助企业优化每一个审批环节,更好地通过数据反哺流程的优化。 三、 功能→问题(场景)从某种程度上来说,上线前的方案设计都只是产品经理的一厢情愿。只有上线后接受到了客户的真实反馈,才能真正验证解决方案的有效性。 上线后的追踪验证可以分为两条思路:一条依赖于此前的数据埋点,通过定量分析来进行验证;另外一条可以通过客户调研回访来进行定性分析。 理想状态下,最好能够在一个月内就最终验证成果给出一定的响应优化。 归根结底,审批只是诸多办公场景中的一类,而企业办公的核心要义就在于准确和高效。 在整个OA审批设计中,我们需要时时刻刻从发起人和审批人的角度出发,通过还原真实的使用场景来提供审批功能设计,帮助他们快速而准确地完成一次审批。 客户成功,也就从侧面赋予了我们toB企业成功的价值。 本文由 @冰冰酱 原创发布于人人都是产品经理 题图来自 Pexels,基于 CC0 协议 |
|