产品手札:企业服务产品的非标性思考

所有的企业服务产品都妄想实现用一套标准来适用于所有目标公司和所有人群。

一方面,无法标准就无法产品化,无法产品化导致的就是功能模块混乱庞杂不清,用户学习适用成本高,亲切性低。

一方面,也是无法标准化就无法产品化,无法产品化就无法规模化。直白说就是不可复制,不可复制的企业产品就是早期的各种企业软件开发公司,最理想的生存状态就能够接到高客单价的定制业务,而赖以存活的核心竞争力就是技术研发的产出速度。弊端就不详细赘述

一个人是复杂的,多个人然后组成团队/部门,多个团队/部门最后组成公司。这样算下来一个公司就是复杂的N次方合集,怎么可能做到标准化的去满足每个人的需求。

场景一:权限

事件:为A部门设置部门负责人

背景:A部门实际的负责人是张三,A部门存在子部门A1,A2,A3,张三在组织架构被归类在A1部门

问题:是否允许添加部门外的人员成为部门负责人

如果允许,就可能出现李四成为了A部门负责人

如果不允许,要想将张三设置为A部门负责人,就必须把张三从A1部门挪到A部门

而企业实际在进行组织架构人员管理时,往往部门负责人A被归类了在A1子部门,典型的案例就是老板

场景二:范围

事件:考勤

背景:公司考勤打卡上班9:00,下班18:00

问题:是否开放自定义考勤范围

而实际情况往往存在多个维度,例如:老板、管理者、员工 | 加班部门、不加班部门;

如果管理者11:00和不加班部门9:00重合时,如何判定?

再如果管理者11:00和加班部门10:00重合时;员工9:00和加班部门重合时

可能有人说很好处理,只要程序去区分一个优先级就好了,但这样的考勤范围需要产品做多少种条件组合的逻辑说明,程序需要做多少种条件组合的判定,用户使用的时候又需要怎么去理解逻辑设置多少遍。并且还需要去自主定义管理者、部门的人员分类管理,而在人员分类管理又可能将涉及到联动到场景一

假使上述所有流程用户都理解,并设置成功,这样的价值又有多高?

产品手札:企业服务产品的非标性思考_第1张图片
多种员工考勤维度
产品手札:企业服务产品的非标性思考_第2张图片
多种部门考勤维度

场景三:流程

事件:请假审批流程节点用角色用户代替某个员工

目的:避免某个流程节点的员工离职审批人空缺状况发生

问题:角色用户是否能够在所有公司请假审批场景下代替某个员工

请假的维度:事假,年假,病假,丧假,产假

审批的维度:审批人,知会人

审批条件:1层,2层,3层

不同条件和维度下的审批需要不同的角色用户进行,这样组合的场景角色数就是上述请假维度、审批维度、审批调价的排列组合数。例如:事假+1层+审批人=角色A;年假+2层+审批人=角色B。每种场景下的单独角色设置是极端情况,实际情况很可能是多个场景下复用同一种角色。例如:请假的维度+1层=角色C;请假的维度+2层=角色D;请假的维度+审批条件+知会人=角色E

而为了避免某个流程节点的员工离职审批人空缺状况发生,每一个角色用户一定要是多个。再与上述的多场景下复用同一种角色组合出现的情况就是:张三发起事假+1层的审批,被判定为角色C进行审批,角色C里有李四(管理张三所在部门)和王五(管理张三所不在部门),这个时候张三进入到角色C里选择谁作为审批人时仍然还是需要通过主观意识的判断。这样又与没有角色直接选择人进行审批又有什么区别呢?

你可能感兴趣的:(产品手札:企业服务产品的非标性思考)