手机网站
手机网站
本文分析了绩效管理体系的设计。作者分解了详细的工艺步骤，总结了设计过程中的一些问题，希望能给大家带来一些启发。
不久前，我的公司在寻找绩效管理解决方案。在考察了SaaS平台如工资表、欢歌、我的人力资源等之后。一个接一个，我们发现这些人力资源管理系统是对员工档案/招聘/薪酬/绩效/培训等综合事务的高效统一管理，而绩效管理只是其职能的一个分支。
但是，只为员工档案/工资计算/招聘管理的一个绩效管理功能和我们公司已经建立的其他系统购买一套完整的人力资源管理系统是不明智的。此外，这些人力资源管理系统的绩效管理部分不能满足公司相当“个性化”的绩效评估需求。
可能正是由于这些原因，公司决定根据其具体的业务逻辑和组织结构开发一个绩效管理系统
绩效管理系统旨在有效记录和管理员工的在线考核指标和绩效分数。这项任务落在了作者身上在与需求方沟通以完成评估流程和功能需求后，我对人力资源管理系统(如工资单、工资单等)仍有简单的经验。
工资单绩效评估流程
1人员绩效评估流程
公司绩效评估流程
在经历了工资单系统的绩效管理部分后，我发现他们只提供了一个更为通用的绩效评估方案，这与公司要求的评估方案不同:
公司要求绩效评估流程分为“方案审查”和“结果评估”两个阶段。只有通过“方案评审”流程后，才能进入“结果评价”阶段；但是，薪酬体系的绩效考核过程是“考核指标”和“分数”的结合。
公司要求绩效考核流程中的所有审批节点都必须有通过/拒绝项目，薪资系统无法满足如此复杂的审批流程。
公司要求绩效考核中各指标的比例和绩效考核过程根据员工的不同等级而不同。
鉴于这些竞争产品与公司要求的绩效考核逻辑之间的巨大差异，实际参考意义不大，所以我不得不自己踩在绩效体系设计的坑上。本文
是我对设计过程中的思考点的总结，是一份供反思的简短的项目简历。
1。审批流程的考虑-逐步拒绝或直接拒绝
在与需求方确认绩效管理系统所需的审批节点后，我一直在考虑如何尽可能简化整个评估流程。
例如，当每个节点执行“拒绝”操作时，选择逐步拒绝或直接拒绝-“逐步拒绝”明显减慢了批准流程，增加了无意义的批准流程
例如，绩效结果评估阶段交由副科长审批，副科长在咨询后不批准评分结果。
逐级剔除的过程是:从分数中剔除:副总剔除→人力资源剔除→上级剔除→员工修改提交；
拒绝他的分数:副总裁拒绝→人力资源部拒绝→上级拒绝→上级修改并提交；
直接拒绝的流程如下:
拒绝打分:副总裁拒绝→员工修改提交；
拒绝他的分数:副总裁拒绝→上级修改并提交；
因为员工或上级可以修改分数，他们必须是拒绝的终点，所以选择直接拒绝使过程更简单
2。思考绩效列表页面的信息呈现
列表页面以三种方式呈现:表单状态作为维度、部门作为维度或员工作为维度。这三个维度实际上是浏览效率和信息详细程度之间的权衡在选择
之前，首先要考虑相应审批节点的用户需求，打开“绩效方案管理”页面:
进度控制-检查每个审批节点的方案数量，并督促相关节点提交/审批方案；
高效筛选-快速找到需要您自己批准的计划；让我们比较几种方法的优缺点。按表单状态
区分的显示方式的优点是能够汇总整个公司/部门各种状态的绩效表单统计；
的缺点是:单页显示内容有限，在浏览各个部门的概览后需要多次翻页，导致浏览效率降低；
显示了根据组织结构的部门列表。
具有以下优点:为用户提供基于部门维度的初步筛选，浏览效率高；
的缺点:无法显示每个部门绩效表的详细概述
2。直接列出所有员工绩效计划的显示方法
优点:-
缺点:数据量大，无法有效管理如果直接列出一级页面，则没有部门绩效表的汇总，即不能满足“控制进度”的要求
显然，不建议直接列出所有性能方案。但是，按表单状态区分的显示模式可以同时满足“进度控制”和“高效筛选”的要求，是最佳选择。
3。对
绩效管理系统中账户权限分配的思考根据用户的级别，他的操作权限和查看权限肯定是不同的。
在设计权限面板时必须考虑以下情况:人员组织结构的变化、人员的进出等。
那么应该如何设计系统功能来实现有效和适用的权利分配？
我大致考虑了三种方式:
1。如果选择
作为直接向每个账户分配权限的方式，则每个账户的权限在创建时是固定的，当用户基数较大时，直接向账户分配权限的方式的操作会相当复杂。
考虑到公司的规模和目前的快速发展，公司的组织结构和员工的职级调整比较频繁，这显然是不合适的
账号用于分配等级和等级相关的权限:考虑到每个等级都有固定的操作权限，只有相应的操作权限需要与用户等级信息绑定，管理员可以通过修改用户的等级信息间接分配权限给用户
2。账号分配权限组、权限组分配等级、等级关联权限方法
提取对应于系统中所有功能的操作权限，管理员建立权限组并配置权限组成员也就是说，“用户组”的概念是在方案2的基础上扩展的。
权限组具有更广泛的适用性和更强的扩展性。
第一个方案实际上是传统的权限模型。方案2和3是RBAC权限管理模型，即用户与角色相关联，角色与权限重新相关联，从而间接授予用户权限与直接授予用户权限的传统模式相比，
可以实现用户权限的批量管理。
想象一个拥有大量用户的系统。如果在传统模式下分别为每个用户设置或修改权限，这将是一项巨大的工作
，但即使对于拥有大量用户的系统，也不会有太多类型的角色需要退出。通过设置或修改RBAC模式下角色的相应权限，可以简化此操作
综合考虑，选择了第二个方案因为已经与需求方确认，这些角色及其在绩效考核过程中的操作权限是固定的，并且考核过程不会改变。
plan 3在plan 2中添加了“权限自我配置功能”,这在目前看来是多余的。
4，用户体验优化虽然
B端产品与C端产品相比不需要太多的交互体验，但仍需保证易用性/稳定性
系统上线后，用户抱怨在填写性能时，系统会自动注销，导致填写内容丢失
因为这是一个内部系统，每个不好的评论都被直接联系，这绝对令人震惊。
在这里，我总结了一些优化用户体验的方法:
1。为了避免水平进度条
操作按钮未完全显示，需要在“查看”之前拖动水平进度条，这增加了用户的操作成本。
2。操作简化
点击绩效方案操作按钮以外的区域，直接输入绩效方案的详细信息
3。每个节点的关键操作需要二次确认。
主要是防止用户误操作
4。页面布局是自适应的
5。填充内容会自动保存
，以防止用户因异常情况而丢失填充内容
摘要在设计
绩效管理系统时，最重要的是要掌握工作流程，即审批内容审批流程的审批节点我也很关心审批过程的正确性和表演形式状态的改变，但是我忽略了另一个重要的内容——形式设计。
B终端产品中的表格实际上是信息显示细节条目的功能，也涉及一些交互体验，因此设计一个能够提高工作效率的表格尤为重要。在
绩效管理系统上线后，我又回到了系统的表设计，发现了更多的想法。例如，关于每页行数、每屏行数、垂直滚动时标题冻结、标题的哪些内容在前哪些在后、表格中的数据排序规则等的规定。都值得探索。只能说，B端产品的设计还有很长的路要走。
地图来自Unsplash，基于CC0协议
