牛人绩效考核Word格式.docx

牛人绩效考核Word格式.docx

《牛人绩效考核Word格式.docx》由会员分享，可在线阅读，更多相关《牛人绩效考核Word格式.docx（8页珍藏版）》请在冰豆网上搜索。

如何选择绩效考核工具？

47089名），有采用绩效考核工具的企业有24495名，占52.02%，没有用到考核工具的有22594，占47.98%，近一半的企业没有使用绩效考核工具，究其原因有两个，一是没有考核，二是有考核，但比较简单粗放，如上级打分评价等方式。

怎么来选择合适的考核工具和方式，主要看企业文化、制度规范与管理水平、绩效推行基础、各考核方式和工具的利弊等，如不考虑是否时机成熟，上来就推KPi、BSc或360度考核方式的做法未必行得通，尤其是BSc对企业的要求较高，不建议中小企业采用，360度考核不能作为主要的考核方式，否则很容易使考核流于形式。

星期四：

如何降低绩效考核推行的阻力？

51229名），有“绩效考核推行阻力大”现象发生的企业有35222名，占68.75%，没有这类现象发生的只有16007名，占31.25%，表明有超三分之二的大部分企业的绩效考核推行并不那么的顺利。

考核推行受阻原因有多种，主要有领导不重视、管理层和员工对绩效考核的不理解或不支持、绩效考核方式方法选择不当、考核指标不合理、考核数据收集统计等配套机制不完善等，需要我们营造绩效考核氛围、寻求领导支持、成立专门的绩效推行组织、对相关人员进行推行绩效的培训、选对方法和工具、定好考核指标、明确考核数据统计收集制度流程和人员分工配合等，从各个方面对症下药去解决。

星期五：

企业绩效体系建设问题的诊断与改善

真可谓是家家有本难念的经啊，说起各自的绩效管理体系建设问题，卡卡们纷纷吐槽，各种各样的问题都有。

其中比较有代表性的问题有：

1、为了考核而考核，填个表打个分，流于形式；

2、目的和方向走偏，考核成了变相降薪的手段；

3、片面的认为考核只是人力资源部的事，只有苦逼的HR在为这事忙前忙后；

4、考核仅是为了发绩效工资，没有做绩效面谈和改善工作的落实等。

诸多问题暴露出来的是当前中国企业在推行绩效考核实施中的艰难事实，尤其是在广大中小企业。

我们不能片面地光看一个点的问题，要从系统层面来全面看待这些问题，尤其是在对绩效考核理解的意识形态和推行所具备的基础条件上，应该多下功夫，即不能匆忙跟风搞绩效考核，要看是否具备条件和时机是否合适，推行前做足摸底审查和准备工作是必不可少的。

篇二：

绩效考核改来改去,效果还是不行,怎么办？

绩效考核改来改去，效果还是不行，怎么办？

公司的绩效考核现在几乎一年改一次了，越改越难推行，越改越复杂了，现在对于绩效考核，很多员工都持否定意见了。

对于努力工作的员工，起不到激励作用，对于混日子的员工，起不到抑制作用。

感觉还不如不考核了！

在人制的企业，制度感觉再完美也是摆设.牛人解析：

中小企业推行绩效的过程中，大都会出现实施后再修改的问题。

有的企业前期工作扎实，试运行运用到位，出现微调的情况是有的。

但是，有的企业在绩效实施过程中，很多结点的所控失当，导致绩效最终流于形式或者弃之不用。

具体导致的原因有下：

一、前期没有试点，一上来就大面积实施，失去了调整的通道；

二、前期没有沟通并培训到位，尤其在绩效方案的目的、绩效的实施过程、绩效如何沟通上，缺乏落实；

三、绩效的计划下达不合理，要么太高，员工完成不了更加消极；

要么太低，员工没有挑战性。

一般都是任务超高；

四、绩效考核的周期把握不当，数据跟不上考核节点，也是流程的调控问题，导致数据不实或者无法对数据进行综合评价；

五、绩效缺乏后期员工的反馈面谈，员工对绩效不感冒，绩效成了HR部或者部门经理个别人的事情。

针对性的改进措施：

一、HR部门将绩效方案重新审视一遍，在Pdca循环过程中，哪个环节出了问题，或者哪个环节需要加强，做到心中有数；

二、集中中高层，将过去进行的绩效考核进行总结，大家提出对绩效的认识与不满，大家达成绩效有必要进行下去的共识。

这需要HR做足对公司现阶段绩效工作的功课：

1、事先与总经理沟通征得老总的支持；

2、同时对现状、绩效应有的目的、改正措施等做到心中有数；

3、开会过程中，要将中高层的所有困惑尽情地表达出来；

4、HR检讨工作中的失误与如何调整如何推进；

5、最后由老总做结语决心。

三、实施改革，把握小步快跑的步伐。

也可以做一项目管理方式来实施：

1、HR部先行实施绩效，将绩效的流程做一模板固定；

期间注意指标的制定与考核的转换细节，并与考核人做充分地绩效沟通工作；

2、推行其他部门实施前，部门经理做足培训：

绩效管理的意义与流程、绩效沟通如何做，统一思想，统一步骤与方法；

3、难点是指标的确定，如何考。

部门经理最有发言权，同时每个部门的指标，由HR、财务与部门经理一同确定并完善。

最好这项工作有职位说明书来支撑，而职位说明书一旦得不到老总的支持的话，指标从工作流程中提取，由部门经理来共同拟定。

而且指标对员工不宜过多，一个销售一个行为；

或者其他行业由行业确定。

4、绩效全体试运营三个月，模拟与工资挂钩的情形，然后正式实施。

我们HR在家企业，抱怨总起不了作用。

只有我们自己能力提升了，与一线部门多沟通，我们有了更加完善的措施出台，不断在老板面前提供实质性的参考意见，才能提升我们HR的地位，才能推动不合理的加以完善。

绩效考评咋实施

牛人好，我们公司是一家生产制造型的广东的一家公司，公司大约100人左右，我们公司虽然建立起了绩效考

核甚至是绩效管理体系，员工的绩效还是没有改善，这种体系似乎成为一种摆设，没有真正起作用。

我想咨询一下绩效考评怎么才能不留于形式？

（提问者：

尋夢）牛人解析：

一、认识问题：

⑴、绩效是结果⑵绩效是行为⑶、绩效不是对历史的反应，而强调员工潜能与绩效的关系，关注员工素质，关注未来发展；

二、流程问题

绩效管理的基本流程：

绩效管理的过程通常被看做是一循环，这个循环份为五步：

绩效计划、绩效实施、绩效考核、绩效反馈与面谈、绩效结果的应用

⑴、绩效计划与指标体系构建

⑵、绩效管理的过程控制

⑶、绩效考核与评价

⑷、绩效反馈与面谈：

⑸、绩效考核结果的应用①、制订绩效改进计划②、组织培训③、薪酬奖金的分配④、职务调整⑤、员工职业发展开发⑥、人力资源规划⑦、正确处理内部员工关系

1、绩效计划：

是一个确定组织对员工的绩效期望并得到员工认可的过程。

2、绩效指标：

是指企业要从哪些方面对工作产出进行衡量或评估

3、绩效标准：

是指企业在各个指标上应该分别达到什么样的水平

4、绩效沟通：

管理者与员工共同工作，以分享有关信息的过程。

经常出现：

①由于考核标准本身比较模糊，面谈中容易引起争执。

②员工抵制面谈，认为绩效考核只是走形式，是为了制造人员之间的差距，变相扣工资，并惧怕因吐露实情而遭上级的报复和惩罚。

③主管没有科学地认识到其在绩效面谈中的角色定位。

分别讲讲出现的问题吧：

问题一：

考核结果无数据支撑，数据来源不明确

原因分析及解决方案：

原因：

KPi指标难以量化或者量化后数据收集难度大；

有些指标表面上看可考核，可量化，最后因收集、测算困难大无法得出具体数字。

解决：

一是设计指标要客户部门参与进来，客户部门提出考核内容及计算方式为主；

二是以行为为导向（比如面谈20人）。

问题二：

KPi指标维度不科学，难度系数不好控制（扣分标准）。

表单基本上由个人制作，绩效思维素养不够，表示制作考核表单时间花费多，很痛苦最终还达不到标准。

1、人力召开多次培训会议，培训以结果为导向，利用倒推法，多快好省的思维（数量、时间、质量、成本维度）。

2、推广其他中心成功经验：

通过几次KPi指标目标导向会议，决议选一人兼任考核人员，每个人完成任务后主动向他汇报，他进行登记，并算出结果，形成内部独立绩效运作模式。

问题三：

绩效考核模式、数据收集方式（区别数据来源）、考核流程有问题

原因1：

各中心副总考核不以企业年度目标为导向，以老板批准为导向造成老板压力很大。

因为整个中心的分数与中心领导的分数有很大关系。

年度目标分解成多项总监级指标，考核模式可学习营销以年度为导向，形成内部独立绩效运作模式。

原因2：

即各部门没有形成独立的绩效动作模式，各部门负责人不懂绩效运作的作用和意义。

考核目前数据来源汇总人力部，造成各部门考核压力转移人力部。

绩效成绩倒推法，企业希望每个部门表现特别好，都拿150%绩效奖金，

现阶段希望，每个部门通过绩效考核，表现好的可拿120%，表现差拿80%，总和平均在100%左右。

问题四：

指标制作有难度，涉及考核指标、考核目标、计算公式、考核结果、数据来源、原因分析及改善措施等

总结上月份经验，对下月份考核进行培训，次月份KPi制定进行指导。

1、团队与个人：

如果过于注重个人绩效，造成内部竞争加大，团队精神减弱，相互帮助减少。

考核团队配合指标应该权重放大，个人指标权重放低。

2、找客户部门提出要考核项目，避免避重就轻的现象。

3、数据来源需要与数据输出部门共同确定数据计算方式；

方可填入KPi表单内（前期要输出方签字）

4、KPi表单最上面60%固化，下面40%随着周期与工作进行变化；

5、文员类的考核表单制作需研讨一种计算形式：

6、人力主要负责工具输出与培训、监督数据真实性；

篇三：

小型软件公司的绩效考核

实际上小型软件公司是大多数，相对于大型软件公司，更缺乏的是绩效考核，或者说是缺乏可量化的绩效考核方法。

组织模式

首先，工作如何量化？

这取决于公司的组织结构。

不同的组织结构导致了不同的工作量化方式。

小型软件公司一般是小项目/小组织的特点，小型软件企业里十之八九都是项目型组织结构。

比方说：

a公司有15个工作人员，又有4个项目并行，最常见的就是分4拨人（每拨人包括项目经理、程序员、测试员）。

表面上每个项目都有一个责任明确的“包工头”，最高领导者很省心。

其实不然，项目做下来省不了多少心。

一会儿报告来不及做，一会儿报告说跳槽了，一会儿客户来投诉质量太差。

而且，这样的人力资源利用率是否最高呢？

其实更不然，撇开每个项目经理管理的能力差异（项目经理管理能力差异很大导致团队产出差异也很大）不提，每个项目组里的某段时期里中总有人空闲。

企业改变这一现象的办法就是：

把企业的组织模式改为职能型组织结构。

这样一来，a公司有15个工作人员，4个项目并行，也仅有一个团队。

其中有1个职能经理，4个项目经理，3个测试人员，7个开发人员。

对于团队负责人职能经理来讲，人力资源的使用情况一目了然。

有朋友提出：

一个人在多个项目里“切换”，但人不是cPU，不是多任务的，频繁切换（即使是一周换一个项目）会降低效率。

可事实证明是可以“切换”的，甚至可以频繁到一个人一日多项目。

比如一个公司有14名员工“切换”在12个项目里（有的项目还在继续中,其中3个是较大的项目），所以，毋庸置疑“切换”的可行性。

实际上，在小型软件企业中推行职能型组织管理，只需要改变一下领导者的管理理念和支撑的管理平台（后文中会有所提及）。

职能型组织的特点就是提高人力资源的使用率，对缺乏人员的小型软件公司来讲这一点非常的重要。

当然，职能型组织模式还有其他管理优势。

职能型组织趋向于“机械式组织”，它有利于专业化管理，有利于组织稳定，有利于集权化和正规化。

如果企业做的项目规模比较小，并且是以非创新技术为重点的项目，那么“机械式组织”有利于创造高效率和低成本。

团队建设

组织模式确定之后，接下来就是团队建设。

首先，我们要定义工作角色。

有了角色，职权就能定义了。

通常的角色有项目经理，程序开发，数据库开发，测试，技术支持等。

由于采用的是职能型组织结构，所以项目经理的主要任务就是接受客户需求，进行设计和任务分解。

项目经理对于项目的管理权利是非直接的，而是由职能经理负责这方面的工作，由他来决定哪些人做哪些事情，并要求何时完成任务（真正的实权在握）。

开发流程

从组织模式谈到团队建设（定义角色），而这些都是绩效考核的基础工作。

接下来就是一个重点，a公司怎么依靠1个职能经理，把15个人、4个项目运作起来？

这个问题首先涉及到开发流程。

凡是搞软件开发的人都知道，开发流程大致分需求分析、设计，开发、测试和部署环节。

如果你在一家公司里，发现几个人包揽了全部环节，那么可以不用花力气搞绩效考核。

因为公司所依仗的就是这些“牛人”,就像地方政府依仗缴税大户一样，大都是免检。

活生生的例子就是三鹿奶粉，由于它维持地方财政税收，自然是“免检产品”。

那么如果要施行考核制度，就必须分环节和引入竞争。

要把那少数几个“牛人”干的活，分成多个人来做。

这样做有几个好处，从企业管理的难易程度上讲，多个人分工合作好于一个“牛人”独自做；

从企业成本来讲，多个人的合计成本反而低于一个“牛人”；

从项目风险来讲，一个人一个项目的风险不言而喻；

从个人工作强度来讲，专业分工更节省人力；

从个人的职业发展来讲，做得更专业比做得泛泛的好。

于是，这样对于企业对于个人都有好处。

有了角色分工就能和开发流程对应起来。

比如，项目经理要完成需求和设计工作；

开发

人员要完成开发工作；

测试和技术支持人员要完成测试和部署工作。

那么，如何把大家的工作贯穿起来？

我们是通过任务单。

设计人员必须完成含有设计说明，预估完成工时等信息的任务单。

职能经理分派任务单给相应的开发人员和测试人员。

任务的分派过程由管理平台支持，职能经理基于这个平台，实现了职能型组织的管理。

通过管理平台跟踪整个开发过程，管理者就可以统计方方面面的信息了，比如个人的能力系数，缺陷系数等等，到这里便可以开始真正的“绩效”了。

那么具体都包括哪些信息呢？

针对设计人员角色有每月完成的任务单数、设计总工时、估计总工时、相应的开发总工时、相应的测试总工时、相应的测试总次数、相应的缺陷总数、缺陷系数和周工作量系数等。

职能经理可以通过设计总工时或者周工作量系数，来了解设计人员工作是否饱和，哪个人设计的缺陷比较多，哪个人效率比较高等信息。

举例，a公司的职能经理，他可以知道手下4个项目经理每月的工作情况（这里的项目经理，其实更应该称为设计人员，因为有的时候可能只有一个真正的项目经理，另外三人在做设计工作）。

数据累计一定量之后，便可以知道哪个人不能完成最低设计工作量，哪个人能力比较强了。

设计完成之后，职能经理就可以派发任务单给开发人员了。

设计人员对每个任务都有一个预估时间，对比开发人员的实际开发时间，可以得到一个能力系数。

当然还有很多其他信息，比如开发人员每月完成的任务单数、相应的估计总工时、开发总工时、测试总工时、测试总次数、缺陷总数、缺陷系数等等。

其中仅能力系数和缺陷系数两项指标就足够衡量一名开发人员了。

另外，因公司而异，公司可能会有最低的开发工作量和缺陷率。

通过统计，你会诧异的发现优秀的开发人员可比一般开发人员高出一倍产量，同时只有1/4的缺陷。

这里要插一句，团队中的“南郭先生”会立刻显露无遗，而优秀开发人员可以站出来大呼加薪了。

当开发完成之后，职能经理就可以派发任务项给测试人员了。

因为有详细设计文档，测试人员只要按照文档进行测试，然后把缺陷编号录入到管理平台中。

同样，管理平台也可以评价测试人员的工作效率，比如每月所测的任务单总数、测试总工时、发现的缺陷数量等等。

这样管理人员就能够了解测试工作量是否饱和，哪个人找缺陷最拿手。

绩效管理成本。

其实绩效考核的的目的是为了建设一个公平竞争的环境，找出业务水平有待提高的员工，让优秀的员工有相应的回报，让公司也能高效率的运作。

对企业来讲，成本倒不是问题。

因为采用了职能型组织之后，就会发现原来小公司内部还有那么多空闲时间（我们的管理平台就是在空闲中完成的）；

另一方面，如果工作效率提高了，产量增加了，三个月就能收回开发成本。

举例，公司执行之后的月开发量提高了179%，2个月的工作量相当于之前3.5个月的工作量。

再谈考核

我们一直在讲“绩效”，还没有谈到“考核”。

公司光有“绩效”没有“考核”是不能提高工作效率的。

如何建立奖惩制度也是一门学问，不同公司做法不同。

《论语》中谈到：

“名不正则言不顺；

言不顺则事不成；

事不成则礼乐不兴；

礼乐不兴，则刑罚不中；

刑罚不中，则民无所措手足”。

这句话是告诉我们要如何做好绩效考核的。

首先要名正言顺，有了良好的舆论环境才能立项做事，才能建立工作流程；

有了工作流程，才能有奖罚标准；

有了奖罚标准，员工就知道怎么做才是正确的。