论文部分内容阅读
摘 要：因IT部门投入产出不透明的特点，企业通常采用行业同比法和固定成本法来控制成本。这两种方法并不能为具体的企业现状来提供精确客观的评估。因此，本文以软件工程生命周期理论为基础，结合企业实际情况，提出了一种新型的IT部门人力成本评估方法，有效的解决了IT部门人力成本估算的问题。
关键词：IT 人力成本 评估
一、问题的提出
随着企业的不断发展壮大，必须要采用信息化的方式才能够大幅度降低人力成本。非计算机相关企业的信息技术部（后文简称IT部）承担了越来越多的后勤支持任务。但IT部作为成本部门，并不能采用简单的投入产出比来评估部门效率。在人力不足的情况下，上线新系统会導致严重的后果，如上线周期延迟、影响原有系统的运维等；而前期招聘过多的员工则又导致人力资源浪费。
IT部不同于成本中心的其它部门，IT部的工作只有好与差的区别，投入人力越多，效率越高，越能提高其它部门的效率。但短时间并不会明显的将投入转化为生产力。非IT企业的高管可能不太清楚软件工程相关的知识，无法通过一种比较科学的方法来估算信息技术部运转是否健康。在这种情况下，企业高管通常采用两种保守的方法来做投入：行业同比法和固定成本法。
行业同比法是根据同业公司第N年的IT人力水平来评估当前公司的现状。该方法的缺点是：市场迅速变化，同业公司当年的情况不见得适用于本公司；同业公司当时的决策未必是最优的。
固定成本法是按照企业每年固定收入的百分比来控制IT的投入。该方法虽然有效的让IT投入伴随着企业发展不断增长，但其缺点同样非常明显：无法证明当前的投入策略为最优的。
因此，企业需要采用一种有效的方法来正确评估信息技术部的运转状态，并实施最优投入策略。
二、问题分析
从软件工程的角度来看，一个软件系统的上线需要经历需求、设计、开发、测试、上线、后期运维等必不可少流程。如果前期投入过少就匆匆上线，则会极大增加后期运维的人力。
从运维的角度来看，后期的运维工作主要有：缺陷修复、必开发需求、可开发需求、权限配置、报表统计、产品优化、系统培训等等。其中缺陷修复、必开发需求、权限配置是必须要做的，其它的工作则取决于IT部人力富余的程度。
当企业高管正确评估出信息技术部的人力充足程度，才能制定合理的计划。
否则，如果人力投入太少，一方面难以立刻招聘到合适的人，另一方面项目出现问题，企业上下都会抱怨，增加了上下级的不信任感，极大的破坏了整体协作性。
而人力投入过多，又会导致企业产生额外的成本，难以向股东交代。
从理论上来讲，如果所有的产品严格按照软件工程的方法论进行生产，那么作为日常的运维工作并不需要太多的人力。但这种理想化的情况在现实中难以存在，这是因为企业面临成本方面的压力，而对软件工程体系的认识又比较肤浅，企业决策者往往并不是计算机专家。
因时间和成本的压力，企业中的软件实施项目往往只经过了草率的设计、开发和测试就上线了。IT部承担了过多的本应该在产品开发过程中就应该完成的任务。
在这种情况下，本文提出了一种人力评估模型来估算IT部的人力富余程度。
三、解决方案
针对以上情况我们采用以下整套方案来解决这个问题。
首先需要采用一种模型来衡量IT部门整个生命周期的状况；其次需要一种方案来评估部门当前的现状，用于在整个生命周期中做匹配；再次需要一种方法来评估未来新增项目或需求而增加的人力成本；最后提出几个需要注意的地方。
（一）IT生命周期人力成本评估模型
图一 IT生命周期人力成本评估模型
图一中的内容分为两个部分：
第一部分为随着年份增长而不断扩大的“水池”。这个水池表示随着年份的增长，新系统和新需求不断的上线，导致IT部需更多的员工进行运维工作。
第二部分为人力富余度的衡量标准，该部分采用了三个阶段来表示。
警告阶段：IT部只能对现阶段的系统维持最基本的运维工作，例如缺陷修复、必开发需求、权限配置。这些工作是不得不做的，否则企业无法正常运转。在这种情况下，每个人一般身兼数岗且不存在AB角色。当员工因各种原因缺岗时，无法在短时间内找到合适的人接手，或不得不停止其它不重要的运维工作来保证最重要的系统运转。
在警告阶段分为两个等级：
Lv1为最重要系统的运维。在保险公司中，核心业务系统、财务系统为最重要的两个系统，一旦这两个系统没有人力进行运维，则企业无法正常营业。
Lv2为其它外围系统的运维。像统计分析系统、销售管理系统、人力资源管理系统等。这些系统无法运转会导致企业效率低下，但仍可续营业。
一旦IT部处于警告阶段，那么增加新系统和新需求必然会遭到失败或不得不牺牲其它系统的常规运维工作来满足新系统的运转。
这时候，IT部必须要将招聘新员工作为首要任务。
冗余阶段：在满足所有系统有人进行运维的情况下，企业需要所有的岗位有AB角色和系统培训。
当某员工因种种原因缺岗时，可以在不牺牲任何一个系统常规运维的前提下完成系统的正常支持工作。
冗余阶段也分为两个等级：
Lv1为岗位冗余，保证所有的岗位都有B角色。
Lv2为岗位培训，A角色应提供本岗位知识文档和培训的工作。这不同于员工离职的岗位交接。
优化阶段：在满足警告阶段和冗余阶段的人力需求后，企业会投入额外的人力进行以提高效率为目的的非必要工作，如优化系统性能、提高系统安全性或提升CMM等级等工作。
这部分的等级只是用于说明，并无明确的指标。
图一中的工作并不包含：日常权限配置、统计报表等工作，因为这些工作的多少取决于具体的系统，这些工作量应另行计算。
（二）IT部现状评估
因为企业的项目和需求是不断增加的，IT部的员工数量也是在不断变动的，IT部需要每半年到一年对当前的现状进行一次评估，需根据评估结果进行动态调整。 具体的评估方法是按照表一为基础，将所有非管理员工的情况填写进去，并通过日常文档来确定填写的准确性。最终将计算的平均值与期望目标相比较，得出未来IT部的调整方案。
基本任务：以正常工作时间的100%为基准，如存在经常性加班，总和可超过100%
缺陷处理：处理所有涉及到导致系统无法正常运转的问题。
需求处理：涉及到新功能开发、需求沟通、额外要求提供报表清单、项目方案策划、产品采购等工作。
常规运维：如权限等配置性签报处理、沟通协调、日常管理和支持等工作。
AB角色：以A角基本任务工作完全可被B角替代为100%
系统掌握：不依赖外包公司独立完成需求沟通和问题处理为100%
培训、撰写文档等：对其它同事或機构进行培训方面的工作；撰写系统操作、管理等文档。新人如能依据文档或培训承接工作，则为100%
从表一的例子中可以很明显的看出：IT部仅仅能够维持关键系统的常规工作，无法支撑企业的发展，因此，需要大量增加人力。
（三）运维人力估算公式
运维人力的计算，本质上是对产品研发的不充分的补偿。我们需要计算：在现有基础上应增加多少百分比的人数才可以满足需求。
本文依据软件生命周期理论提出了一个公式来计算系统应投入的人月值：
Sum=T-R+T/4
T为某项目实际应投入的理论人月数。包含了完整的需求、设计、开发、测试、上线和版本管理等一系列的工作。理论人月数的标准为：上线后暴露的缺陷应低于总缺陷数的5%，且不存在影响运营的严重缺陷。
R为某项目实际投入的人月数。假如实际的月数与理论应投入的人月数相等，那么就表明该系统几乎不需要后期运维。如果系统匆匆上线，那么R值较小，整个项目需较多的后期运维。
T-R为补偿前期产品研发投入人月不足的时间。
T/4为产品知识成本。在不依赖开发团队进行系统运维的前提下，IT部必须要花费大量的时间对产品进行学习才能够独立完成运维工作。否则就要依赖原先的开发团队才能够做好工作。因一个产品完整周期的需求+设计+开发的时间约占50%左右的时间，在有足够完整的文档情况下，我认为大约要25%的实际人月的学习即可完成学习工作。在文档不完整的情况下，产品知识成本则会更高。
这里估算的前提是无开发商或实施商的协助。如果有这方面的援助，例如购买延长的运维期服务，则可以极大的减少其后期运维工作量。
Sum越小，表示前期的设计、开发和测试越完整和充分。但系统本身的复杂度又会使Sum变大。
图二 人力成本均摊
图二说明了如何计算人力成本均摊的方式。
图表中的线段A、B、C、D与坐标所包围的面积为产品或需求上线后所需要的运维人月成本。面积越大，所需的人月成本越大。
线段陡峭程度表明了该系统的使用频率。一个产品的使用频率越高，其曲线越陡峭。这意味着短时间内发现的问题越多如线段A；产品使用频率越低，则曲线越平缓，这意味着短时间内发现的问题越少，一些月度统计系统，因为每月只有一次使用机会，所以需要很长的使用时间才能够发现所有问题，其线段倾斜的程度较低，如线段C。
线段与X和Y轴所围的面积即所需的运维总人力。该面积由固定的时间长度切割，从而得出每阶段应运维的时间。即：Sum=∑F(n)。其中F(n)为图二中每个时间段的面积。
（四）影响因素
在实际应用中，我们无法将该模型直接应用于实践中。有一些重要的因素需考虑。
1、产品外包。
为了避免自建队伍产生的离职等风险，企业往往从人力资源的风险考虑问题，将大型项目整体外包给开发商。以提高成本为代价降低责任风险。在这种情况下，IT部只需承担极少的人力成本即可完成运维工作。
2、未充分测试的产品。
一个软件产品至少要经过完整的测试：黑盒测试、白盒测试、代码覆盖率测试、集成测试和压力测试等。并经过一段时间的试运营才可以在正式上线前发现至少95%的缺陷。但这样做的代价很高，企业往往会对产品的成熟度和开发团队的能力来综合评估以降低风险。IT部应该对产品的测试情况和团队来确定未来实际应投入的人力成本。
3、大量新增需求
企业的核心业务系统往往是需求变更最多的系统，它们的特点是：成本高、复杂度高、大量新增需求。从软件工程的角度来说，现有系统的规模会增加新增需求的测试成本。因此，每次新增需求都应该对该系统的运维工作量重新计算。
4、软件项目管理
系统的版本管理、需求和缺陷管理和灾备保障也会消耗相应的人力成本。如企业期望有较高的软件项目管理成熟度，那么企业应做好这方面的人力支出准备。系统越复杂、新增需求越多，其项目管理的人力成本也会相应的大幅提高。
三、企业实践建议
本文提出的人力成本评估模型为企业提供了两方面的建议：
1、为IT部做整体的项目人力预算。
IT部负责人可根据已运维的系统和未来将上线的系统来精确的计算出未来数年所需要的人月数。对比目前现有员工数，可得出IT部目前所处的位置，并为部门运转提供指导性意见。如人力处于警告阶段，要求进行优化或培训等工作必然会导致员工加班，或影响到现有的常规运维工作。企业高管如能够掌握这部分的情况，则可以采取稳妥的策略来处理新系统上线等需要权衡的问题。
2、评估新项目
甲方与乙方往往会在需求阶段开始博弈：甲方通常存在上线时间和预算的压力，期望乙方花费较多的人力并采用成熟团队来进行产品开发；而乙方则会严格管控成本。
因此，甲方在招标的时候会首要考虑：以成熟产品为蓝本、高质量的研发团队、充分完善的测试、全面的灾备方案。
因为时间和成本的压力，往往双方会在测试和灾备上打折扣，这就导致了后期较高运维成本。在这种情况下，产品越成熟，二次开发的内容越少，测试越充分，上线后系统运转压力越大，后期运维成本就少。相反，企业应准备好做长期运维的打算。
五、总结
通过上文的分析可以看出，无论是新成立的公司还是以运营多年的企业，都可以采用本文的方法来精确的评估IT部门人力成本投入的情况，并有效的改善企业在后勤支持方面的效率。本人所在的企业采取了该方法进行评估，取得了比较好的效果。
参考文献：
[1] 张海藩编著，《软件工程导论（第5版）》，清华大学出版社，2008
[2] 迈克康奈尔编著，《代码大全（第二版）》，电子工业出版社，2006
作者简介：宫洁卿（1984.07—）男，所在单位：紫金财产保险股份有限公司，学位：东南大学软件工程硕士。
关键词：IT 人力成本 评估
一、问题的提出
随着企业的不断发展壮大，必须要采用信息化的方式才能够大幅度降低人力成本。非计算机相关企业的信息技术部（后文简称IT部）承担了越来越多的后勤支持任务。但IT部作为成本部门，并不能采用简单的投入产出比来评估部门效率。在人力不足的情况下，上线新系统会導致严重的后果，如上线周期延迟、影响原有系统的运维等；而前期招聘过多的员工则又导致人力资源浪费。
IT部不同于成本中心的其它部门，IT部的工作只有好与差的区别，投入人力越多，效率越高，越能提高其它部门的效率。但短时间并不会明显的将投入转化为生产力。非IT企业的高管可能不太清楚软件工程相关的知识，无法通过一种比较科学的方法来估算信息技术部运转是否健康。在这种情况下，企业高管通常采用两种保守的方法来做投入：行业同比法和固定成本法。
行业同比法是根据同业公司第N年的IT人力水平来评估当前公司的现状。该方法的缺点是：市场迅速变化，同业公司当年的情况不见得适用于本公司；同业公司当时的决策未必是最优的。
固定成本法是按照企业每年固定收入的百分比来控制IT的投入。该方法虽然有效的让IT投入伴随着企业发展不断增长，但其缺点同样非常明显：无法证明当前的投入策略为最优的。
因此，企业需要采用一种有效的方法来正确评估信息技术部的运转状态，并实施最优投入策略。
二、问题分析
从软件工程的角度来看，一个软件系统的上线需要经历需求、设计、开发、测试、上线、后期运维等必不可少流程。如果前期投入过少就匆匆上线，则会极大增加后期运维的人力。
从运维的角度来看，后期的运维工作主要有：缺陷修复、必开发需求、可开发需求、权限配置、报表统计、产品优化、系统培训等等。其中缺陷修复、必开发需求、权限配置是必须要做的，其它的工作则取决于IT部人力富余的程度。
当企业高管正确评估出信息技术部的人力充足程度，才能制定合理的计划。
否则，如果人力投入太少，一方面难以立刻招聘到合适的人，另一方面项目出现问题，企业上下都会抱怨，增加了上下级的不信任感，极大的破坏了整体协作性。
而人力投入过多，又会导致企业产生额外的成本，难以向股东交代。
从理论上来讲，如果所有的产品严格按照软件工程的方法论进行生产，那么作为日常的运维工作并不需要太多的人力。但这种理想化的情况在现实中难以存在，这是因为企业面临成本方面的压力，而对软件工程体系的认识又比较肤浅，企业决策者往往并不是计算机专家。
因时间和成本的压力，企业中的软件实施项目往往只经过了草率的设计、开发和测试就上线了。IT部承担了过多的本应该在产品开发过程中就应该完成的任务。
在这种情况下，本文提出了一种人力评估模型来估算IT部的人力富余程度。
三、解决方案
针对以上情况我们采用以下整套方案来解决这个问题。
首先需要采用一种模型来衡量IT部门整个生命周期的状况；其次需要一种方案来评估部门当前的现状，用于在整个生命周期中做匹配；再次需要一种方法来评估未来新增项目或需求而增加的人力成本；最后提出几个需要注意的地方。
（一）IT生命周期人力成本评估模型
图一 IT生命周期人力成本评估模型
图一中的内容分为两个部分：
第一部分为随着年份增长而不断扩大的“水池”。这个水池表示随着年份的增长，新系统和新需求不断的上线，导致IT部需更多的员工进行运维工作。
第二部分为人力富余度的衡量标准，该部分采用了三个阶段来表示。
警告阶段：IT部只能对现阶段的系统维持最基本的运维工作，例如缺陷修复、必开发需求、权限配置。这些工作是不得不做的，否则企业无法正常运转。在这种情况下，每个人一般身兼数岗且不存在AB角色。当员工因各种原因缺岗时，无法在短时间内找到合适的人接手，或不得不停止其它不重要的运维工作来保证最重要的系统运转。
在警告阶段分为两个等级：
Lv1为最重要系统的运维。在保险公司中，核心业务系统、财务系统为最重要的两个系统，一旦这两个系统没有人力进行运维，则企业无法正常营业。
Lv2为其它外围系统的运维。像统计分析系统、销售管理系统、人力资源管理系统等。这些系统无法运转会导致企业效率低下，但仍可续营业。
一旦IT部处于警告阶段，那么增加新系统和新需求必然会遭到失败或不得不牺牲其它系统的常规运维工作来满足新系统的运转。
这时候，IT部必须要将招聘新员工作为首要任务。
冗余阶段：在满足所有系统有人进行运维的情况下，企业需要所有的岗位有AB角色和系统培训。
当某员工因种种原因缺岗时，可以在不牺牲任何一个系统常规运维的前提下完成系统的正常支持工作。
冗余阶段也分为两个等级：
Lv1为岗位冗余，保证所有的岗位都有B角色。
Lv2为岗位培训，A角色应提供本岗位知识文档和培训的工作。这不同于员工离职的岗位交接。
优化阶段：在满足警告阶段和冗余阶段的人力需求后，企业会投入额外的人力进行以提高效率为目的的非必要工作，如优化系统性能、提高系统安全性或提升CMM等级等工作。
这部分的等级只是用于说明，并无明确的指标。
图一中的工作并不包含：日常权限配置、统计报表等工作，因为这些工作的多少取决于具体的系统，这些工作量应另行计算。
（二）IT部现状评估
因为企业的项目和需求是不断增加的，IT部的员工数量也是在不断变动的，IT部需要每半年到一年对当前的现状进行一次评估，需根据评估结果进行动态调整。 具体的评估方法是按照表一为基础，将所有非管理员工的情况填写进去，并通过日常文档来确定填写的准确性。最终将计算的平均值与期望目标相比较，得出未来IT部的调整方案。
基本任务：以正常工作时间的100%为基准，如存在经常性加班，总和可超过100%
缺陷处理：处理所有涉及到导致系统无法正常运转的问题。
需求处理：涉及到新功能开发、需求沟通、额外要求提供报表清单、项目方案策划、产品采购等工作。
常规运维：如权限等配置性签报处理、沟通协调、日常管理和支持等工作。
AB角色：以A角基本任务工作完全可被B角替代为100%
系统掌握：不依赖外包公司独立完成需求沟通和问题处理为100%
培训、撰写文档等：对其它同事或機构进行培训方面的工作；撰写系统操作、管理等文档。新人如能依据文档或培训承接工作，则为100%
从表一的例子中可以很明显的看出：IT部仅仅能够维持关键系统的常规工作，无法支撑企业的发展，因此，需要大量增加人力。
（三）运维人力估算公式
运维人力的计算，本质上是对产品研发的不充分的补偿。我们需要计算：在现有基础上应增加多少百分比的人数才可以满足需求。
本文依据软件生命周期理论提出了一个公式来计算系统应投入的人月值：
Sum=T-R+T/4
T为某项目实际应投入的理论人月数。包含了完整的需求、设计、开发、测试、上线和版本管理等一系列的工作。理论人月数的标准为：上线后暴露的缺陷应低于总缺陷数的5%，且不存在影响运营的严重缺陷。
R为某项目实际投入的人月数。假如实际的月数与理论应投入的人月数相等，那么就表明该系统几乎不需要后期运维。如果系统匆匆上线，那么R值较小，整个项目需较多的后期运维。
T-R为补偿前期产品研发投入人月不足的时间。
T/4为产品知识成本。在不依赖开发团队进行系统运维的前提下，IT部必须要花费大量的时间对产品进行学习才能够独立完成运维工作。否则就要依赖原先的开发团队才能够做好工作。因一个产品完整周期的需求+设计+开发的时间约占50%左右的时间，在有足够完整的文档情况下，我认为大约要25%的实际人月的学习即可完成学习工作。在文档不完整的情况下，产品知识成本则会更高。
这里估算的前提是无开发商或实施商的协助。如果有这方面的援助，例如购买延长的运维期服务，则可以极大的减少其后期运维工作量。
Sum越小，表示前期的设计、开发和测试越完整和充分。但系统本身的复杂度又会使Sum变大。
图二 人力成本均摊
图二说明了如何计算人力成本均摊的方式。
图表中的线段A、B、C、D与坐标所包围的面积为产品或需求上线后所需要的运维人月成本。面积越大，所需的人月成本越大。
线段陡峭程度表明了该系统的使用频率。一个产品的使用频率越高，其曲线越陡峭。这意味着短时间内发现的问题越多如线段A；产品使用频率越低，则曲线越平缓，这意味着短时间内发现的问题越少，一些月度统计系统，因为每月只有一次使用机会，所以需要很长的使用时间才能够发现所有问题，其线段倾斜的程度较低，如线段C。
线段与X和Y轴所围的面积即所需的运维总人力。该面积由固定的时间长度切割，从而得出每阶段应运维的时间。即：Sum=∑F(n)。其中F(n)为图二中每个时间段的面积。
（四）影响因素
在实际应用中，我们无法将该模型直接应用于实践中。有一些重要的因素需考虑。
1、产品外包。
为了避免自建队伍产生的离职等风险，企业往往从人力资源的风险考虑问题，将大型项目整体外包给开发商。以提高成本为代价降低责任风险。在这种情况下，IT部只需承担极少的人力成本即可完成运维工作。
2、未充分测试的产品。
一个软件产品至少要经过完整的测试：黑盒测试、白盒测试、代码覆盖率测试、集成测试和压力测试等。并经过一段时间的试运营才可以在正式上线前发现至少95%的缺陷。但这样做的代价很高，企业往往会对产品的成熟度和开发团队的能力来综合评估以降低风险。IT部应该对产品的测试情况和团队来确定未来实际应投入的人力成本。
3、大量新增需求
企业的核心业务系统往往是需求变更最多的系统，它们的特点是：成本高、复杂度高、大量新增需求。从软件工程的角度来说，现有系统的规模会增加新增需求的测试成本。因此，每次新增需求都应该对该系统的运维工作量重新计算。
4、软件项目管理
系统的版本管理、需求和缺陷管理和灾备保障也会消耗相应的人力成本。如企业期望有较高的软件项目管理成熟度，那么企业应做好这方面的人力支出准备。系统越复杂、新增需求越多，其项目管理的人力成本也会相应的大幅提高。
三、企业实践建议
本文提出的人力成本评估模型为企业提供了两方面的建议：
1、为IT部做整体的项目人力预算。
IT部负责人可根据已运维的系统和未来将上线的系统来精确的计算出未来数年所需要的人月数。对比目前现有员工数，可得出IT部目前所处的位置，并为部门运转提供指导性意见。如人力处于警告阶段，要求进行优化或培训等工作必然会导致员工加班，或影响到现有的常规运维工作。企业高管如能够掌握这部分的情况，则可以采取稳妥的策略来处理新系统上线等需要权衡的问题。
2、评估新项目
甲方与乙方往往会在需求阶段开始博弈：甲方通常存在上线时间和预算的压力，期望乙方花费较多的人力并采用成熟团队来进行产品开发；而乙方则会严格管控成本。
因此，甲方在招标的时候会首要考虑：以成熟产品为蓝本、高质量的研发团队、充分完善的测试、全面的灾备方案。
因为时间和成本的压力，往往双方会在测试和灾备上打折扣，这就导致了后期较高运维成本。在这种情况下，产品越成熟，二次开发的内容越少，测试越充分，上线后系统运转压力越大，后期运维成本就少。相反，企业应准备好做长期运维的打算。
五、总结
通过上文的分析可以看出，无论是新成立的公司还是以运营多年的企业，都可以采用本文的方法来精确的评估IT部门人力成本投入的情况，并有效的改善企业在后勤支持方面的效率。本人所在的企业采取了该方法进行评估，取得了比较好的效果。
参考文献：
[1] 张海藩编著，《软件工程导论（第5版）》，清华大学出版社，2008
[2] 迈克康奈尔编著，《代码大全（第二版）》，电子工业出版社，2006
作者简介：宫洁卿（1984.07—）男，所在单位：紫金财产保险股份有限公司，学位：东南大学软件工程硕士。