你的工资是怎么发到手里的？
这两年我一直在想，怎样才能把产品功能讲明白，让外行也能听懂？怎样才能把产品讲明白，让同行快速理解来龙去脉，让新人快速上手？
关于这个问题，我始终觉得要把握业务场景，并通过业务场景映射到产品流程中，再结合产品思维将业务功能化，功能完整化。
所以，本文我将按照这样的思路来聊一聊和我们打工人息息相关的“工资”这件事。全文将以常见的人力资源管理系统（E-HR）中的“薪酬”为基点展开介绍。
本文将分为三大部分：
- 我们的工资是怎么来的；
- 这个场景对应了哪些软件模块；
- 对场景的标准化拓展。
备注：文中的系统截图来源于“2号人事部”和“钉钉智能薪酬”，两款我觉得在这个赛道里做得不错的SaaS产品。如有侵权，请联系删除。
一、工资发放的用户场景
张三月薪10k，其中有5k是基本工资、4k是绩效工资、1k是补助，这个薪资构成是在张三入职签合同，或者公司调薪之后确定的。
而基本工资在张三所在的企业，受月度考勤的影响。比如请假、旷工、迟到早退都会按照企业统一规则进行扣减。
他的绩效工资是每月按照领导的打分结果计算，有时多、有时少。而且张三在工作期间也可能会加班、出差，这些行为可能会产生额外收入。
这样汇集到一起，每个月会形成张三的工资表，在企业现有的薪资构成下填充不同的金额，通过公式最终得出张三的税前工资，也叫应发工资。
之后，根据张三的应发工资以及公司最初制定的五险一金规则，为其计算对应的社保、公积金缴纳金额，包括个人承担的部分，以及企业需要承担的部分。
五险一金计算完成之后，需要提前计算个人所得税，按照国家规定的公式计算。
最后，张三的实发工资由应发工资扣减五险一金的个人承担部分，再扣减个人所得税最终形成。
以上，是一个最基础，最常见的薪资计算流程（其他场景和规则下文会补充）。
每个企业都会有一个或多个这样的表格，表格里记录着企业内的各个薪资构成项（简称“薪酬项”），每次发薪之前，相关人员都要算一次。每一个表格，都可以称为企业的一个“薪酬方案”（薪酬组）。
完成上述操作之后，我们仅是将张三的工资算出来了，但还没有发到他的工资卡上。五险一金和个税也是一样，仅停留在数据层面，并未发生资金交易。
因此，企业的财务人员将按照不同的费用，在不同的系统上进行操作（当然，也可能是线下）。
发工资最常见的是登录企业对公账户开户行的企业网银（或银行提供的其他发薪软件），将线下做好的工资表导入系统，提交发薪流程，通过一层层的审批，最终完成账务处理。
这一步在银行的系统里叫“批量代发（代付）”业务，看起来是直接从企业的对公账户将资金转入个人工资卡，实际上里面的资金处理流程也很复杂。常见的流程有两类：
1）企业对公账户——>银行批量代付过渡户（不要纠结名字，各家银行叫法可能不一样）
银行批量代付过渡户——>员工工资卡
2）冻结企业对公账户对应的发薪额度
企业对公账户——>员工工资卡
如果额度没发完，再解冻。
以上两类，虽然看起来只有几个步骤，但其中的验证、异常处理、反洗钱防范等流程会做的很复杂，在此不展开介绍。
到这里，张三的卡里就收到工资了。
然而员工的五险一金还没交，企业的人事部门还要登录各地社保系统、公积金系统进行缴纳操作。
员工的个税也没有申报，企业的相关人员还要登录各省的税务系统，进行个人所得税的申报和预扣预缴。
我们来回看一下整个流程：
然而，这只是我们当下能看到的流程，但在张三入职之前，这些规则是怎么来的？
其实，最主要的一步前置条件，应该是“确定算薪方案”，即企业要提前设置好各个薪酬项，以及薪酬项之间的计算公式、关联关系。还要设置好五险一金的缴纳规则、比例系数。
这样在有新员工入职之后，直接将员工添加到对应的算薪方案中，才会有后面的故事。
另外，整个流程结束之后，还需要进行相关统计，如成本统计、薪资趋势统计、薪资构成统计等等。
所以，我们最终来看一下这个场景的业务流程图：
自此，一个简单而标准的场景就描述完了。
二、用户场景与产品功能的映射
用户场景梳理完成之后，对应的每一个用户应用节点，都将映射出产品功能。下面我们来看看这个薪酬场景都有哪些一级功能（我建议在梳理具体功能之前，先画一张功能架构图，以便从宏观上认识它）。
1. 设置企业的算薪方案
这是一个规则配置的功能，包含了自定义添加规则项，采用公式编辑器维护各个规则的计算公式，并选择数据来源。
这里需要提醒的是，大部分产品对于这种操作复杂的规则设置，会预制常用的模板，更厉害一点的，则支持Excel文件导入，自动识别里面的公式和规则项。
当然，你也看到了，这玩意一般人还真玩不明白。很多SaaS平台的实施岗，就是帮客户提前配置这些规则。而且总会有场景系统不支持，这时便需要“曲线救国”的策略。
2. 设置企业的社保方案
我觉得社保最大的难点在于各个城市的具体政策和系统都不一样，所以一旦面向全国的客户，这个功能的维护成本就会很高。
而且员工社保还会涉及到参保、停保、年度调整等环节，大多数E-HR平台只能做到“离线计算”，无法和相关的社保局系统对接，进而导致这个功能很鸡肋，数据存在不准确的情况。
另外，不同企业在社保上的缴纳方案也不同，有三险、三险一金、五险、五险一金、六险一金等等。而且还会增加企业自己的限制。
比如按基本工资的80%缴纳、转正后缴纳、入职一年之后缴纳等等，都增加了这个功能的复杂性。
3. 同步企业花名册信息
系统内的数据是联动的，薪酬模块本身只是E-HR平台中的一部分，其中所需的基础数据（如员工信息）都需要从其他模块中获取。
如果是同一个平台，数据源是一致的，这个问题还好解决。但有些大型企业会有多个平台，其中员工的基本信息在A系统里，薪酬或其他业务功能在B或C系统里，信息的同步变成了多个平台之间的交互。
一旦涉及到数据源的变更，又是一个难题。
4. 定调薪
其实这个功能就是为了给企业的每个员工维护各自的薪资数据，包含哪些薪酬项是固定的，哪些是浮动的，什么时候生效等基础规则。
因为一个企业有很多员工，所以这个功能要考虑批量设置的情景。而且要考虑这些关键数据修改的权限、流程。
从数据维护的角度来看，可以在页面上操作，也可以导入文件。一旦涉及到文件导入，又将面临格式、必输项、数据准确性、报错提示、错误修改等一系列的设计难题。
说句题外话，我觉得B端产品在不同场景下的文件导入，应该可以抽象出一个单独的处理引擎，根据不同文件的格式设置不同的分支，将每个分支下的基础验证、业务验证、错误提示、异常修改等流程标准化，具体的规则配置化。
这样既能从应用层做到全局一致，也能减少设计冗余。可惜这一步，我没有实践成功。
5. 薪酬计算
按照上文的介绍，薪酬计算至少要分为四个步骤：计算应发、计算社保、计算个税、计算实发。
这四个步骤是有先后顺序的，而且分别需要借助多个功能的数据规则、数据结果。所以在操作上、效率上、连贯性上、以及中间过程的细项分支上，都会衍生出很多二级、三级功能和逻辑。
其实，E-HR系统下的薪酬管理，最核心的功能就是计算，我们基于如何计算向前拓展了很多个步骤，通过场景梳理和规则预设，让系统具备快速准确计算的可能性。
当然，这里面要还要考虑性能问题，一个月计算多次的问题，中途调薪、调规则的问题，跨月的问题，出现错误如何预警的问题，以及数据安全性的问题等。
6. 薪资发放
因为最终的资金处理需要依托银行的服务，所以很多系统初期没有与银行对接，仅将最终的算薪结果按照银行的“网银报盘”（其实就是上传的Excel文件）格式导出，再由操作人员登录到银行系统进行导入。
但这一步在业务流程上是割裂的，所以越来越多的E-HR平台开始和银行合作，支持企业对公账户开户行为合作银行的企业直接进行资金处理。但因为涉及到资金的安全性、审核的严格性，大多数平台这一步的连接做得并不“顺滑”。
不过，近些年很多银行也在创新相关的产品，对外提供了集发薪、算薪于一体的企业级SaaS平台。比如招商银行的“薪福通”产品（浅谈招商银行“薪福通”）。
另外，像社保缴纳、个税申报的环节，同样存在多系统间割裂的问题，而作为E-HR平台，想要拿到这些合作资源，壁垒会非常高，真正对接时将面临的业务、技术难题也远超想象。
因此，评估一个产品做得好不好，除了看产品所覆盖的场景，解决的问题，带来的体验，还要看这款产品背后所能链接的资源。
在账务处理这个层面，就不多介绍了。
7. 报表分析
线下需要统计的各类报表，我相信对于系统来说实现起来并不难，难的是如何将业务数据形成所谓的数据资产，为企业经营决策赋能？
而且本身大多数企业线下的统计维度比较简单，真正从趋势、对比、多维度加权整合的方向来考虑，无论是数据报表，还是可视化图形报表，都是产品团队需要深入研究的。
就像《数据化决策》这本书中提到，我们应该通过数据量化什么？
——量化不确定性，量化风险，量化信息价值
遗憾的是，我所见到的免费版E-HR平台报表，还远没有达到这个效果。
三、对产品功能的标准化设计
从理论到落地，我觉得最难的阶段，就在于标准化设计。
因为业务好理解，功能框架也容易梳理，但真正到了设计阶段，面对多变、复杂的实际使用场景，如何让自己的产品具备适应性，对产品团队是一个极大的挑战。
本文第一章列举张三的例子，只是一个很小的部分。实际场景中可能涉及不同岗位、不同职级有不同的薪资构成和计算规则。尤其涉及到某些薪酬项依托于其他模块的数据时，模块之间的连接性、数据的可用性、规则的多变性，都需要考虑。
另外，我们只讨论了固定工资的场景，很多行业都是以业绩、劳动量等变化的维度计算工资。比如常见的“计件工资”、“计时工资”、“销售提成”、“利润分红”等。这些场景如何在标准化设计中有效融入？
在产品设计阶段，即便我们形成了可以标准化的方案，在分析细化的过程中还要考虑几个重要的维度：异常操作、功能间的耦合性、体验优化、拓展性配置。
1. 异常操作
用户大概率不会按照我们预设的操作步骤进行，尤其是新用户。
他们经常会遇到一些奇怪的问题，而这些问题大多都是因为产品设计时对于异常操作覆盖度不够而导致的。
比如不按照操作步骤进行，前置操作未完成时点击后续操作。这种情况需要考虑是进行合理的提示并支持直达前置操作，还是从设计上统一入口，只能按顺序执行，以避免用户误操作的可能性。
比如你以为一定能成功的操作，如果失败了怎么办？一个批量的操作如果一部分成功一部分失败怎么办？
比如出现了关键业务的并发操作，甲正在算薪，乙去把方案规则修改了怎么办？
类似的情况有很多，预测这些异常，并找到合理的方案，这款产品的可用性才会提升。否则，上线之后团队的大部分精力可能都在解决一个个“离奇”的问题上。
2. 功能间的耦合性
同一个功能下多个子功能之间相互联系、相互制约。不同功能下的数据、流程也相互联系、相互制约。同一个大生态下，不同系统之间很多数据同样相互联系、相互制约。
所以，在做标准化设计过程中，解决功能间的耦合性，是一个难点。
比如在薪酬场景中，给员工定薪之前，需要员工先通过人事系统将个人信息维护进来。而人事系统又会分为入、转、调、离四个阶段，不同阶段对于薪酬方案都可能存在影响。
比如很多操作都需要预先配置规则，而规则之间也存在关联。像企业给员工调薪，一般都需要审批，审批通过后才能生效。因此调薪功能就要和平台的审批流引擎相结合。
比如计算应发时，需要获取员工的考勤数据，又将联动协同办公（OA）模块中的周期性数据，并依据规则进行计算。
正所谓“牵一发，而动全身”。
3. 体验优化
作为B端产品，体验一直是优先级较低但又始终绕不开的话题。小到错误提示是否通俗易懂，大到帮助中心是否能够真正解决用户的问题。
上周在和
不想延期，公众号：不想延期。半路转行的B端泛金融产品，坚持“以实践验证理论，以输出倒逼成长”的目标。点滴珍贵，重在积累
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
