IT企业技术人员绩效评价的变革——以A公司高级技术支持人员为例，本文主要内容关键词为：技术人员论文,为例论文,技术支持论文,高级论文,绩效评价论文，此文献不代表本站观点，内容供学术参考，文章仅供参考阅读下载。
一、案例背景
A公司是1988年创建于美国的一家高成长性的跨国信息安全软件公司，网络安全软件及服务领域的全球领导者。A公司在中国大陆已有400多名员工，其中高级技术支持中心分为客户／服务器组、邮件组和网络组三个不同的产品线组，由近30人的资深工程师构成，为欧洲、中东、非洲和亚太地区的客户提供最高级别的技术支持。该中心采用漏斗式三级技术支持体系确保快速解决内外部客户和合作伙伴的问题，即首诊支持、核心技术支持和客户支持性研发。客户的需求由电话、电子邮件或网页、设备自动呼叫三种途径进入A公司技术支持体系以后，绝大多数问题在首诊支持能够解决。首诊支持不能解决的问题，根据紧迫程度的不同，最快15分钟就会提升到核心支持。如果核心支持仍然不能解决问题，将交由研发工程师解决。A公司在全球数百名技术专家和来自合作伙伴的资深工程技术人员分布在美国、德国、日本以及中国等多个不同时区的国家，以不间断的方式为全球客户解决安全相关问题。核心支持是售后工程师参与的最高等级技术支持，本文中所提到的高级技术支持特指这一人群。
二、高级技术支持人员绩效评价现状
（一）评价步骤
高级技术支持人员的工作效率、工作态度和状况难以定量测量。2006年以前，A公司的所有高级技术支持部门采用的绩效评价分三步：
1.新一年度的员工发展计划。每年3月份由员工和主管人员及经理一起完成。具体操作是：(1)主管人员及经理制定好整个部门的全年目标，然后共享给所有的部门员工；(2)员工制定自己的个人全年目标和发展计划；(3)主管人员及经理在通览全局的基础上对每位员工的目标和计划进行检阅并提供调整意见；(4)员工和主管人员及经理一起讨论并达成一致。其中第2个步骤是最为重要。员工参考自己去年的绩效状况、360度绩效评估后的反馈以及职业发展兴趣，并考虑到今年部门的实际目标，依照SMART的原则为自己设定详细并且能和部门目标有效结合的个人目标，找出自己需要提高的地方，制定发展计划。
2.修改或调整目标。6月份进行年中绩效评定并对一些可能有变化的目标修改或调整：(1)员工对上半年的工作完成情况做小结，特别要针对那些完成状况欠佳的目标提出下半年的改进方案；(2)主管人员检阅员工的小结，提出概括性评价和建议，并主要针对已发生改变或者预期将发生改变的目标做出调整；(3)员工和主管就调整过的目标以及下半年的工作方案做沟通，并达成一致意见。
3.全年绩效评定。在第二年1月份进行全年绩效评定，包括以下步骤：(1)首先，由员工对自己全年绩效做总结，并给自己评级。公司的评级系统包括四个级别：A为“持续超过预期”，B为“超过预期”，C为“持续达到预期”，D为“部分达到预期”。公司并不要求确定的级别分布但是强烈建议分别按照15%、25%、50%、10%的比例进行分配；(2)主管人员和员工作正式沟通。沟通的重点并不是把自己对员工的看法告诉员工，而是在内心已有的初步假设下尽量在一些预期可能产生的较大分歧点上达成一致；(3)主管人员根据自己的判断来给员工做评价和定级，把结果提交给上一级管理人员作最终评定；(4)评级结果正式下来后，主管人员和员工再做一次沟通。如果员工对结果强烈不满，可以向人事部门投诉。
（二）评价指标
A公司绩效评价所采用的指标分为可量化的指标和不可量化的指标两部分。
1.可量化的指标
(1)处理的客户事件数。事件分配方式是由固定的人按照每个工程师可以支持的产品以及他现有的工作量来做分配。一般来说，支持产品多并且处理事件效率高的人会得到较多的事件。
(2)平均事件升级率。工程师技术上无法解决某个事件时可以把该问题升级到开发人员做进一步分析，就会产生事件升级。较低的平均事件升级率往往意味着该工程师具有较强的技术能力。
(3)平均事件解决时间。工程师在解决问题的过程中，需要详细记录每一步、每一次沟通所花的时间。把所有的时间总和除以事件总量就得到了平均事件解决时间。
(4)贡献的新解决方案数。公司技术人员在解决新出现的事件后都被建议写一篇文章记录下该解决方案以备其余人参考。高级技术支持人员遇到的事件中有相当一部分比例属于现有知识库无法解决的问题，所以有较多的机会贡献新的解决方案以充实公司的知识库。
2.不可量化的指标
(1)参与项目的程度和深度。部门总会不定期的收到上级指派的一些额外任务或者项目。尽管这些项目和工程师的主要职责相关联不大，但是完成的质量如何会影响到全部门的利益和发展。完成这些项目需要投入相当的精力并且影响客户事件的处理。在做绩效评定时应对员工在这方面的付出做出尽可能贴切实际的估计。
(2)接收培训和给他人提供培训的频度及反馈。高级技术支持人员既要接收来自开发人员提供的新产品培训也同时肩负着给前端技术支持人员以及销售技术人员的培训任务。在对员工做绩效评定时，也会考虑这方面。
(3)参与新产品测试的程度和贡献。高级技术支持人员的反馈对于新产品的质量和上市后可能面临的问题具有决定性的影响。员工支持的产品不同，所以对这件事情的参与度也会因人而异，要考虑员工在这方面付出的精力和贡献。
(4)参与升级事件解决的程度和贡献。高级技术人员无法解决的问题可以升级给开发人员。但是，公司希望高级技术人员在这种情况下仍能积极配合开发人员找出问题的解决方案。
(5)工作的态度和积极性。在评价员工的态度和积极性时，主管人员会结合自己的判断以及参考公司一年一次的360度绩效评估里所得到的来自多方面渠道的信息。
(6)技术能力在本部门及相关部门的被认同度。每个员工定期在部门或者公司范围做一些技术性讲座，主管做绩效评价时应予考虑。
三、绩效评价的问题与结果
（一）高级技术支持人员绩效评价中的问题
1.产品差异导致缺乏有效的绩效横向比较。该部门根据不同的产品线分成了三个组，各个组之间因为产品的差异化较大，导致这些量化绩效指标很难进行跨组比较。即使在同一个组内，也存在或大或小的产品差异而无法直接相互比较。由于缺乏横向比较的考核标准，绩效评价缺乏客观性和可比性。
2.员工没有清楚客观的自我定位导致自评中的高估。大部分高级技术支持人员拥有6到15年的工作经验，自我感觉相当良好，容易高估自己的能力和表现，而不够认同他人的工作。
3.缺乏横向比较带来主管的主观评价。主管及经理给员工打分一般会依据员工绩效指标的实际完成情况和员工绩效在部门里的相对位置。由于缺乏有效的绩效横向比较机制，在实际操作中更多的是依靠主管人员的主观判断，从而很难保证事实上的公平。当主管人员的判断和员工的自我评分差异较大时，会带来严重的沟通困难。
4.评估周期长导致员工无法及时得到主管的反馈与指导。由于正式的绩效评定只在每年结束之后才做，沟通频率低、周期长，绩效沟通的及时性、针对性受到损害。员工无法得到主管人员及时有效的绩效反馈和指导，原先掌握的事实依据就会显得不再那么鲜活，员工的体会也不会深刻。而且，绩效沟通需要涉及到的信息也多，难以聚焦，沟通的针对性会降低。
5.主管缺乏客观有效地对员工的能力做出评价。作为主管人员，在使用公司当时的绩效评价系统时，因为无法在既有量化指标的基础上对员工之间的能力优劣做出客观评价，在给员工设计专门的培训方案和配合员工的个人发展需要上都感觉缺乏有力的支持。
（二）绩效评价不到位所产生的结果
A公司高级技术支持人员虽然在制定目标时可以遵循SMART原则，但由于后继缺乏有效的绩效评价手段，无法对员工的绩效做很好的区分或者横向比较，导致实际工作成绩不理想的员工对自己的落后认识不足，无法确定正确的努力方向。那些实际工作成绩优异的员工，也因此无法及时得到同事及上级的承认。这种制度直接影响员工的主动性和积极性，导致员工不满率增加，乃至产生人才大量流失。该部门二十多人，但是每年流失的人员大约有4-6名。而培训一个合格的高级技术支持人员需要六个月的时间，较高的流失率对整个部门的效率和产出带来了很大的影响。
四、绩效评价体系的变革
（一）高级技术支持人员绩效考评系统的设计
1.评价目标。从A公司高级技术支持部门运作管理需要出发，本部门绩效评价的目标是对整个技术支持售后服务过程的监督、控制和指挥，分为三个部分：1)追踪员工绩效并不断与以往评价系统进行比较分析，主要就服务水平和员工工作表现的要素分析向管理者提供绩效评估报告；2)依据技术支持的标准化体系进行实时监督控制，追踪现行技术支持流程运作绩效，改进售后服务程序，及时调整运作方式；3)通过绩效评价来量化部门人员的工作成绩，实现更优化技术支持运作效率。
2.评价主体。由于本部门技术支持人员不直接面对客户工作，因此评价主体为上级和本人。
3.评价指标。公司首先对员工的具体工作内容做了详细的分析，发现本部门员工工作时间分配所占比例依次是：客户问题处理70%，书写解决方案5%，处理客户建议5%，产品测试5%，接受培训和给他人提供培训10%，其他5%。员工绝大部分时间用在直接处理客户的问题上，还有10%左右的时间用在书写解决方案和处理客户对产品的建议上。在此基础上，设计评价指标。
工作项目的数量方面包括三大块：一是客户问题处理（80分）。这是个人和部门被评价的最重要指标，分为三个指标：处理的事件总数（30分），事件平均解决时间（20分）和事件升级率（20分）。前两个指标比重较高的主要原因是它们的员工可控性明显高于最后一个指标；二是书写解决方案（5分）和客户建议处理（5分）；三是经理调控（10分），是经理根据员工的其他任务安排，如新产品测试、指导新员工、提供培训等做出的评价。为了避免由于员工接受的处理事件难易程度不同带来的不公平性，该部门对事件的分配方式做了研究，改变了人工分配方式，设计出一套自动分配事件的系统。
工作项目的质量方面包括三个方面：一是处理客户问题过程中有没有违反服务级别协议。违反一次，扣10分；二是员工有没有收到特别的表扬信。根据表扬信的实际情况，可以给予5分或10分的奖励；三是员工有没有收到确实因为自己的原因而导致的批评信。每收到批评信一次，扣1吩。
4.评价结果的反馈和处理。部门确定了以月为单位的考核周期，具体实施为：1)每个月结束后根据该月的具体数据来计算出每个人的分数并公布；2)每个月的最高得分者可以获得精神及物质上的奖励；3)每个季度的最高得分者可以代表本部门参加全公司的季度优秀员工的评比；4)每个年度的最高得分者可以代表本部门参加公司年度优秀员工的评比。考评周期缩短解决早期的事件平均解决时间的计算难题，并且降低了一些难以解决、花费时间长的事件对全年考评分数的影响。
（二）高级技术支持人员绩效评价系统变革的试点
本部门分为三个产品组，公司决定先在客户／服务器组里面试推广这个系统。客户／服务器组有三个主打产品和五、六个小产品。三个主打产品贡献了90%的事件量。该组的每个员工几乎都可以支持这三个主打产品，其难易度很接近。实施的基本步骤包括：
1.和员工沟通，对系统进行调整。先在部门会议上和员工做沟通，接收意见、讨论并达成一致，试运行一个月后根据评分的实际结果和员工的反馈再做一些调整。调整集中在各个项目分数比重的修正上。
2.打分评价。在每个月初，当上个月的事件处理详细数据出来后，可以很快计算出除了经理调控一项之外所有指标的分数。部门经理对经理调控的计算方法是：首先通过发邮件给每位员工来主动听取他们在过去一个月的贡献，再结合经理通过各种渠道了解的信息，最后做一个估分评定。
3.公布数据。在月初的小组会议上公布这些数据，给予分数最高的人一些物质奖励，同时请他做一个简短的演讲，来向大家共享一些他在过去一个月中工作的心得。
4.绩效反馈和指导。在随后进行的每个月一次的和员工一对一交流中，部门经理可以根据评估结果给予具体的绩效反馈和指导。由于该评价系统可以让员工很清楚地看到自己的强项和弱项，客观地了解自己在部门中的位置，绩效沟通也变得轻松而且有效。
（三）系统的完善与推广
在客户／服务器组试点该系统三个月后，该项试点的反馈大部分都很正面。与此同时，本部门战略上有了一个重大调整，客户／服务器组和邮件组的员工进行了合并。因此该部门决定实施对象拓展到原邮件组员工。邮件组有两个主打产品，还有三、四个小产品，具体情况和客户／服务器组类似。但是该主打产品和客户／服务器组的主打产品差异很大，处理一个两个组的产品问题所花的精力无法横向比较。因此，基于早期试点的情况以及部门的调整，绩效评价系统需要做出相应的调整。
1.以标准产品为基准解决产品差异带来的横向比较。客户／服务器组和邮件组在产品的难度差异较大，主要体现在不同的平均问题解决时间和事件升级率上。为了实现可比性，部门经理基于2007年三个主要产品相关数据，进行了定量的分析，并在组织员工讨论取得一致意见的基础上确定：以A产品为标准产品，在计算事件升级率的时候，给予C产品0.55的权重和B产品0.64的权重。在计算平均问题解决时间时，给予C产品0.79的权重和B产品0.76的权重。经过一个月的试运行对数据进行的检验，大家一致认可这个对策所反应的公平性。
2.调整指标的权重值。员工在试点中集中反映了两个问题：一是书写解决方案和处理客户对产品的建议各5分不能很好地对应他们的实际难度；二是经理调控的10分上限有时不能很好体现员工在该月的贡献（特别是当员工在某个项目上投注了很多精力时）；三是绩效变革使得有些员工过于在意自己的表现和分数，在对别人处理问题过程中提供帮助的频率和程度有所减少。通过部门员工的讨论，最后建议把书写解决方案和处理客户对产品的建议这两个项目的数据合并，总分定为5分，而把经理调控的分数上限从10分上升到15分。并利用经理调控这一项来鼓励员工做一些类似于经验共享等耗费个人时间却对同事别人和部门有益的事情。
3.剔除不可控因素。有些人反映事件升级率中有一部分是非自己可以控制的。譬如遇到由产品本身的缺陷导致的事件，只能升级到开发人员那边做出产品的修正。经过讨论后，大家一致同意在计算事件升级率时，把此类可以明确确定的事件类型剔除。但是，部门并没有承诺把各种非人控因素剔除，那样会使事情和计算过程过于复杂。
（四）本绩效评价系统实施的效果
1.员工开始主动学习和熟悉业务范围外技能。部门重组后，要求确保每个组内都有足够的员工可以支持所有的产品，对每个人可以支持的产品数量有了新的要求和挑战。变革前员工一般不太愿意主动去学习新产品，变革后明确了新的业务需求，员工能主动制定相对比较积极的学习计划，做好新产品支持的准备。此外，员工现在更加积极参与新产品测试和为其它部门提供技术培训，积极研究别人的经验来提高自己。
2.自我评估更合理化并促进沟通的有效性。由于绩效标准的明确和可比性增加，员工自我评估变得越来越合理。以2007年底员工绩效评定为例，15个员工自评结果中，有14个自我评级和部门经理的评价是一致的。高度的认知一致性使通常最令主管头疼的绩效结果沟通过程变得轻松而有效。
3.员工开始专注于以前不重视的工作领域。在实施该系统之前，员工对书写解决方案和处理客户对产品的建议这两件事情上缺乏热情，因为在这两项上的贡献在原先的绩效评比方案中是没有得到认可的。很多时候，主管人员都不得不去催促员工提高在这两方面的贡献度。但是实施该系统后，因为这两项也给了一定的比重，大家开始抢着去做。
4.对于控制员工离职率有积极的影响。对比发现，该部门尚没有实施该系统的网络组2007年离职率为33.3%，2008年7月之前离职率为22.2%；而客户／服务器组和邮件组2005年离职率为33.3%，2006年离职率为13.3%，2007年为零，2008年7月之前只有1人离职。
5.员工满意度大幅度上升。公司每年例行对员工进行的满意度调查显示，本部门员工的综合满意度从2005年的55.6%变化为20%年的70.4%，继而上升到2007年的81.5%。
五、成功经验与改进思路
（一）成功经验
1.授权于部门，鼓励员工参与，解决难题。由于每个部门的情况差异很大，制定绩效评价应当给予部门负责人充分的授权。在本案例中，部门经理得到了较大的授权，根据本部门工作的特征，利用自己的专业技术背景，拟定绩效变革方案，并鼓励员工的参与，广泛吸收员工的意见，共同探讨和解决绩效评价中遇到的难题。
2.工作分析细致全面。只有明确了岗位职责，才能有针对性地对企业内部的各工作团队及员工的实际工作行为进行考核，判断其行为与企业所要求的职责规范之间的拟合程度，并以此作为绩效的衡量标准与考核依据。在该部门绩效变革过程中，部门经理花了大量的精力和时间研究部门中各个组队及其成员的工作性质、工作任务和职业发展可能，通过指标微调的方式，将公司领导希望员工具有的能力和发展方向编写入考评指标，间接明确公司对员工发展方向的期望，并监督引导员工在正确的路线上发展。
3.分步实施，及时完善变革方案。绩效变革是一个难题，也是“牵一发而动全身”的事情，关系到部门和员工的切身利益。冒然推进不成熟或者可能存在缺陷的绩效评价方案会产生很大的负面影响。在本案例中，部门经理推行新的绩效评价方案采取了逐步实施，及时总结实施过程中存在的问题并对方案完善，避免可能产生的负面影响，这对变革的成功有很大的促进作用。
4.考核标准严谨清晰。之前，本部门绩效评价大都由部门经理主观采取“好”、“中”、“差”等描述性评语以及少部分可量化指标进行。变革后建立的绩效评价系统，基本上做到了完全数字化、量化，具有清晰公正的说服力。
（二）未来的改进思路
1.该系统的成功离不开一个重要的前提，也就是客户／服务器组和邮件组共有的特性：核心产品较少但是贡献了绝大多数的事件量。因此，该系统主要考虑了核心产品的影响，而忽略了其余的小产品。但是，同部门的网络组拥有8个以上比重相似但是特质迥异的主要产品，并且具体到每个人只能支持其中的2到3种，就很难对这些主要产品做横向比较。如果仍然采用以A产品为标杆，为各个网络组产品确定权重的方式，系统的计算过程又会变得相对复杂。所以，如何把这套系统同样高效的实施到网络组中去是该绩效变革的一个挑战。
2.该系统注重了绩效结果，但是对于员工具有的软能力，如解决问题过程中和各方的沟通能力、控制流程的能力等等就无法体现出来。对于技术人员而言，能力是非常重要的要素。建议可以利用技术人员的能力素质模型，采取双路径的业绩评价方法，既考虑到绩效结果，又考虑员工的能力素质进行绩效评价。
（参考文献略）
标签：绩效评价论文; 绩效指标论文; 绩效改进计划论文; 企业绩效评价体系论文; 绩效反馈论文; 绩效目标论文; 绩效沟通论文; 工作绩效论文; 系统评价论文;