案例分析：给eHR外包一个理由

　　前言：

　　对于拥有自己的IT部门的企业而言，很多时候，在建立企业的HR系统时，总是在自行开发还是外包开发之间艰难选择。很多时候，企业领导与IT部门因为没有深入参与到HR管理活动中，不能很好理解HR管理的复杂程度，所以会认为HR系统的设计与开发并不是太困难的事情，同时，考虑到开发成本的问题，他们往往主张HR系统应自行开发；而对HR部门而言，他们很清楚企业IT部门自行开发HR系统将面临的诸多问题，首先，因为IT部门对HR业务的陌生，使得HR管理人员必须花很多的精力让IT人员去理解业务；其次，由于没有过去积累的经验，IT部门从系统分析与设计到系统开发完成并稳定运行的周期，可能会远远超出想象，一方面影响了HR部门的工作，另一方面实际投入的成本恐怕比外包还要高。

　　企业建设HR系统，到底应该是自行开发还是外包给专业公司呢？让我们来看一家大型企业集团在经历了3年自行开发历程之后，是如何理解这个问题的。出于可以理解的原因，我们暂且将这家公司称作Demo公司，其HR系统也简称为Demo_HRMS。

　　需要说明的是，受当时技术的限制，Java或.net平台在本文中未被采用。

　　HR系统：外包的理由

　　一、DEMO_HRMS现状

　　DEMO公司自1998年开始自行开发的人力资源管理系统（以下称DEMO_HRMS），从功能上涵盖了HR部门对员工在企业的全生命周期的管理，从人力资源规划、人才招聘到人事管理（包括人事信息管理、考勤休假管理、绩效管理、员工离职管理）、干部管理、薪资/福利管理以及员工培训与发展管理等各个方面，并能提供一些统计查询与报表输出功能。

　　从技术的角度来看，DEMO公司电脑部在人力投入严重短缺的情况下，完成了DEMO_HRMS系统从需求分析、设计、编码、测试、培训推广到日常维护的软件工程全过程，并在功能上覆盖得比较全面，同时还较好地确保了系统的稳定性，与电脑部相关技术人员的技术实力与敬业精神是密不可分的。

　　从系统应用的角度来看，目前DEMO公司内部主要在使用的是DEMO_HRMS系统的“员工信息管理”模块以及部分查询统计功能，大多数其他功能还没有发挥应有的作用。

　　经过对DEMO_HRMS系统本身、DEMO_HRMS研发的历史过程以及用户对系统的认识等方面进行综合分析，我们认为，导致DEMO_HRMS在应用上的表现不尽如人意的因素主要有：

　　1.技术的限制

　　DEMO_HRMS界面不够友好、系统运行效率不高是系统自身的两大突出问题，而这两个问题的出现，实际上是受到了技术路线选择的限制。

　　DEMO_HRMS系统前端开发工具为Develop2000，计算模式采用的是两层C/S结构。

　　由于DEMO_HRMS系统早在1998年就开始进行设计开发，国内当时在信息系统计算模式（二层C/S、三层C/S、B/S）的选择上还处于一种探索阶段，而当时Develop2000本身对三层C/S结构的支持就比较有限，使得DEMO_HRMS最终选择了两层C/S计算模式，这在当时大的技术背景下是一种稳妥的选择，尤其值得一提的是，与业务系统不同，DEMO_HRMS系统当时选择了集中式的计算模式，这是DEMO公司信息系统采用集中式管理模式的一次有益尝试。但随着技术的发展以及DEMO公司对信息系统的要求不断提高，两层C/S计算模式给DEMO_HRMS带来的限制就越来越明显。

　　首先是系统运行速度慢的问题，尤其是进行大多数查询统计操作的时间耗费，远远超出了用户的忍受极限，原因是，在两层结构下，客户端负担了大部分商业逻辑的处理工作，每次进行数据处理的时候，它需要把一个完整的查询结果（作为中间结果的数据集）取回到客户机，然后再由客户程序对该数据集进行商业逻辑处理，最后才能在GUI上显示最终结果。事实上，往往GUI需要显示的最终结果的数据量一般很小，但为了获得这个结果，却需要从数据库服务器上取回一个相对比较大的作为中间结果的数据集，造成数据传输量大大增加。另外，由于数据集本身具有很多严格的格式定义，在传输过程中，客户端与数据库服务器需要不断通信进行校验，如果网络通信环境再有限制，必将大大延长数据传输过程的时间。同时，由于商业逻辑需要在客户机上处理，如果客户机的性能不高，也会影响逻辑处理的速度，上述因素综合起来，就会导致用户的每次操作耗时的增大。

　　其次是负载均衡的问题。当前情况下，由于DEMO_HRMS的用户量还不算太大，并发访问造成的问题还没有暴露出来。但eHR的发展趋势是越来越多的普通员工、直线经理以及高层管理人员将参与到HRMS系统的应用过程中来（所谓的自助服务），否则HRMS系统将会成为HR部门的信息孤岛。对DEMO公司而言，必须要考虑HRMS系统潜在的用户数量将会比较大，将来随着越来越多的用户参与到DEMO_HRMS系统的应用中时，对并发访问的处理就必须进行考虑，否则又会成为影响DEMO_HRMS 系统应用推广的重要因素。对大量并发访问的处理手段，主要通过负载均衡来实现，目前DEMO_HRMS由于采用的是两层结构，客户端直接与数据库服务器进行通信，服务器端不具备专门处理客户端访问的中间服务器（应用程序），因而自身并不具备强大的负载均衡功能。对DEMO_HRMS而言，这将是未来一个很大的隐患。

　　Develop2000作为与Oracle配套的开发工具，在Oracle数据库开发上的确有着开发速度快、稳定性好等优势，但从另外一个角度来看，Develop2000与Oracle绑得比较紧使得它的开放性不高，控件及其它外部资源的支持较少，这将导致Develop2000开发出的系统，在界面的视觉效果上、界面的友好性以及简洁性上都有着很大的欠缺，而界面的美观、简洁、易用等问题，是用户最直接能感受得到的，是影响用户对系统的心理接纳程度的重要因素。 Develop2000使得DEMO_HRMS系统的外在表现比较沉闷、死板，很难满足对人性化甚至个性化的界面表现形式有较高要求的HR管理人员的需求。

　　2.用户需求与系统设计的限制

　　导致用户使用DEMO_HRMS系统积极性不高的另外一个主要因素，在于该系统是基于过去的管理需求设计开发的，很多功能已经不能满足用户当前的管理要求，而在这种情况下，系统又不能很好地适应需求的调整，所以影响了用户对系统的应用信心。

　　以DEMO_HRMS 的“人员信息管理”模块为例，当初在设计的时候，为了照顾到不同用户对系统提出的需求，在人员信息的数据项设计上采用了穷举法，即把所有当时认为可能会用到的数据项目都表现在界面上，对用户来讲，这么烦杂的界面无疑增加了用户进行数据维护的畏难心理；而从另外一个方面来看，随着HR管理政策的变化，还是有一些新的数据项出现了，而界面上却无法方便地进行调整，无法及时满足用户新的要求。

　　“考勤管理”模块也比较类似，当考勤的政策发生变动后，一些数据项目的设置也会相应发生变化，甚至后台逻辑处理也会变化，而现有的DEMO_HRMS系统因为只考虑了当初设计时的政策，并没有（对非商业化系统而言，事实上也很难）考虑到可能出现的其它情况，所以无法适应新的政策。

　　再如“培训管理”，由于没有考虑将来的扩展，一些可以设计成可以由用户自定义的数据字典的数据项，却需要系统开发人员每次进到数据表中人工编辑，这不仅增加了系统维护的复杂度，而且增加了出现数据库级错误的可能。

　　“干部管理”作为DEMO_HRMS系统的补充功能，自研发完成后就一直没有使用起来，其中的重要原因，就在于该模块虽然内容丰富，但功能上却相对简单，基本上只是对干部现状的信息管理，缺少应有的决策功能，更重要的是，该模块中存在大量的表格输入工作，这些表格的不同内容需要不同角色填写，本来应该可以通过网上走流程实现的，却全部要求由人事部门来完成全部的输入工作，无疑大大增加了人事部门的工作量，因而必然导致HR管理人员的抵制。

　　目前DEMO_HRMS中的报表基本上不具备灵活性，任何新的报表需求，都需要技术人员专门开发，然后再挂接到系统中去，无形中增加了技术支持的工作量，也让用户感觉限制比较大。

　　另外，由于HR管理各职能之间本身存在着各种各样的业务流程关联，相应的HRMS系统的各功能模块之间也应该存在严格的信息流程。比如绩效管理完成后，应该会对员工的培训与职业发展计划提出指导建议，绩效结果还可能会与员工薪资调整挂钩，所以对应的HRMS系统中，“员工绩效管理”应该与“员工培训”、“员工职业生涯规划”、“薪资管理”等功能模块建立数据关联（信息流）。管理信息系统的特点，是要让信息系统成为管理的工作平台，而不只是起着简单的数据存储与输出作用，所以在HRMS系统的设计阶段，各功能模块不应该被单独考虑，而应该通盘考虑彼此之间的信息关联性。这方面的工作在DEMO_HRMS系统中做了一部分，但还有较大的缺陷。

　　总结起来，DEMO_HRMS缺乏灵活性与集成度、没有决策支持平台、没有工作流程是系统设计时的欠缺，上述问题可以说在DEMO_HRMS系统中是比较普遍的，是DEMO_HRMS系统的硬伤，基本上无法通过对系统的优化来适应DEMO公司对人力资源管理不断提升的要求（优化的初衷是好的，但可能会造成技术人员疲于奔命不断通过改造系统来满足用户需求变化的结果，除非用户不用系统）。

　　上述问题的出现，主要由两方面原因造成，一是由于对HR管理的不熟悉，系统分析人员对需求的理解从很大程度上只能被动地跟着需求提出方的思路走，而需求提出方本身也会有管理思路的局限性，当时的需求不一定考虑到未来的发展，管理者个人的需求也不一定代表DEMO公司普遍的需求，所以现在的DEMO_HRMS就成了为当时的需求提供者量体裁衣定制出来的系统（系统分析人员应该能在很好消化用户需求的基础上，根据过往的经验提出自己的合理设计思路，并经HR管理者认可）。其次，由于系统设计开发的工作任务十分繁重，而系统设计研发人员的投入人数却极其有限，导致了技术人员在系统设计的心态上，必然不会将重点放在系统的灵活性与继承性上，而是如何尽快地满足用户现有的需求（这与商品化产品的开发有很大区别）。

　　3.人员的变更

　　DEMO_HRMS系统（一期、二期）相关的HR管理人员与技术人员的频繁变更也是造成系统推广应用不力的重要因素。当初提供需求的HR管理人员，在系统研发过程中变动很大，目前已经所剩无几，新到位的管理者可能并不关心或不认可前任的这部分工作，从根本上没有重视起来，所以造成很多功能模块得不到应用。参与DEMO_HRMS系统研发的技术人员目前也所剩不多，而且因为DEMO公司电脑部本身业务多，仅有的几位技术骨干也不能全职投入到系统的改造、推广与应用中去，也是使得DEMO_HRMS不能稳步往前推进的原因之一。系统必须在应用过程中才能存活与提升，管理人员的变更是不可避免的，关键是系统研发的周期不能太长，应该尽量在预期的项目周期内完成项目的研发工作，并尽快推广开来，让相关管理人员都知道都应用系统，这样系统的命运就不会只维系在个别管理者身上了。而系统应用的成功，也使得电脑部在技术支持人员投入上的决心更大。

　　4.系统管理的难度

　　目前，DEMO_HRMS在系统管理上还比较繁琐，表现尤为突出的是权限管理。DEMO_HRMS的权限管理分为功能的权限管理与机构的权限管理。当前系统的权限管理从设计上建立在角色表、权限表、用户对照表之上，理论上是一套行之有效的解决方法，但实际应用过程中，虽然在系统功能权限上的管理可以交给HR部门完成，但机构权限管理却需要电脑部技术人员通过在数据库中手工建立视图来实现，原因是DEMO_HRMS没有为用户映射一个统一的二级帐户，而是需要为每一个用户设立一个Oracle数据库帐户，这就导致在为用户指定机构时，必须要在数据库中建立相应的视图来进行机构数据的过滤。这个过程无疑增加了系统管理的难度。

　　另外，由于本系统的客户端是以安装程序的形式发布，每增加一名新用户或者用户需要重新安装客户端，都需要技术人员进行支持，这无形中也增加了DEMO_HRMS系统的管理开销。

　　5.管理体系本身的因素

　　DEMO_HRMS系统中某些功能不能得到很好应用，也有DEMO公司内部管理体系太复杂的因素。比如薪资管理，本身是一项很有必要进行集中式管理的工作，但目前DEMO公司各级机构采用的薪资管理工具并不统一，很多机构更倾向于使用单机版系统，因为各机构都有需要进行数据加工后才上报总部的特殊情况存在，他们不希望采用集中式管理后削弱了机构自身的管理权限。这种情况下，公司就必须权衡集中透明化管理的利弊，在政策上要敢于下决心，否则系统开发出来了，也会受到机构用户的抵制。

　　所以讲，DEMO_HRMS的全面成功，必需要建立在明确而稳定的HR管理体系之上。

　　二、DEMO_HRMS改造建议

　　作为专业从事HR管理信息化解决方案提供商的Provider公司，在有幸作为外包方承担KPI以及绩效管理两大项目任务之后，经过与DEMO公司人力资源部、电脑部相关项目人员的长期合作与深入沟通，对DEMO公司的HR管理体系以及信息系统的建设有了比较深刻的认识。当前DEMO人力资源部正在全公司范围内进行人力资源管理的提升（数个HR改革项目在同步推进），而大多数管理提升的结果，需要借助HR管理信息化平台来直观地呈现，这就对新的DEMO_HRMS系统提出了很高的要求。

　　新的DEMO_HRMS系统应该是DEMO的先进HR管理技术与信息技术的完美结合，它不仅应该是一个高效的HR管理工具，更应该成为DEMO推行由直线经理、高层管理者以及普通员工都能参与到HR管理活动中来的“全面人力资源管理工作平台”。只有这样，HRMS才能适应DEMO人力资源管理层次的不断提升，才能符合现代人力资源管理的发展趋势。

　　为实现上述目标，避免在人力资源管理信息系统建设过程中走弯路，Provider公司建议从以下几个方面分层次来考虑：

　　1、优化还是重建

　　在前面的分析中，我们已经看到现行DEMO_HRMS系统的所谓“硬伤”（缺乏灵活性与集成度、没有决策支持平台、没有工作流程），这些“硬伤”彼此之间盘根错节，将会影响到该系统根基的稳固，更谈不上适应未来的扩展，而优化只能解决一些技术性能的问题以及系统功能上眼前的和表面的问题，要解决“硬伤”的问题，需要对系统很根本的东西进行改造，而改造往往会只见树木不见森林，也许通过优化能够迅速看到一些短期成果，但如果改造得不完整不彻底，技术人员必将陷入无止境优化的泥潭。

　　另外，并发访问时的负载均衡需要中间服务器来处理，而目前DEMO_HRMS要从两层结构转为三层结构，就需要增加一个中间服务器，如此一来，客户端原来与数据库服务器的所有通信连接需要彻底重写，这种改造的工作量是海量存在的，因为这种通信环节在系统中无处不在。而并发访问处理不好，就会无法满足将来用户量的扩大。

　　而系统重建，可以在吸取原有系统经验教训得基础上，从根本上对新系统的设计研发提出全面合理的解决方案。也许短期内的效果不如进行系统优化来得快，但从长远来看，“硬伤”问题的解决，必将能延长系统的生命力，而技术人员付出的代价也会越来越小。因此，我们建议对DEMO_HRMS系统进行重建。

　　2、自行研发还是外包

　　DEMO公司电脑部拥有一支强大的技术开发队伍，有着大系统的设计开发经验。自行设计研发从理论上看，可以确保系统维护升级的持续性，但自行研发也存在两个比较大的问题：

　　1）工作效率低下

　　软件开发与技术支持不同，其工作强度是非常之大的，为了如期完成一项开发任务，软件人员往往需要具备很强的面对持续作战时的压力承受力。在企业内部，由于缺乏强有力的激励与约束机制，技术人员在为自己的企业提供软件开发服务时，往往对阶段性目标的重视程度不够，目标达成与否对自身影响都不是很大，所以会导致开发人员给自身施加的压力不够。另外，因为公司大，事情多，要应付一些日常事务影响到开发人员的工作效率。工作效率低下必然会增加系统开发的成本，而且因为责任心的问题，可能还会在系统中留下很多难以排除的隐患。

　　2）设计思路局限

　　由于缺乏商业化产品的设计开发经验，企业内部的开发人员在进行系统设计时很容易拘泥于企业本身的现实情况，而很难考虑到发展的问题，这将导致开发出来的系统扩展性差，生命周期比较短。这对企业而言也是一个损失。

　　Provider公司与DEMO公司合作开发KPI与绩效管理系统，是DEMO电脑部进行IT业务外包的一次尝试，从整个合作过程来看，Provider公司克服了任务重、时间紧的诸多困难，与DEMO公司人事部、电脑部项目人员一起，将上述两个系统尤其是KPI系统这块硬骨头硬是基本成功啃下来了，这是DEMO公司期望达到的目标，也是Provider公司历经艰辛后乐于看到的结果。Provider作为DEMO的项目外包公司，有着明确的目标与各种内外部压力，加上专业化的服务，所以才有可能与DEMO公司一起走到这一步。Provider也愿意继续成为DEMO公司诚信的长期的合作伙伴，在为DEMO提供优质服务的同时实现双赢。

　　3、统筹规划还是分模块设计

　　由于人力资源管理是一个庞大的系统工程，管理体系内部流程比较复杂，各管理职能之间都会有关联，因此，相应的HRMS也要在系统内部建立完整的信息流程，这就要求在进行系统设计时，必须统筹规划，通盘考虑问题，不能简单地将某种管理职能地信息化工作独立出来考虑。

　　缺少业务流程的管理将会造成混乱的局面，而缺少内部信息流程的HR管理系统将只能作为一种数据处理的工具来使用。

　　Provider公司建议DEMO_HRMS系统采用统筹规划、分阶段实施的策略来开展工作。

　　4、技术路线的选择

　　1）采用三层结构

　　三层结构的集中式计算模式可以提高系统运行的效率。三层结构的特点是商业逻辑在中间服务器与数据库服务器之间进行高速处理，而客户端只是浏览器或GUI界面，负责事务处理的请求与处理结果的显示。Provider在客户端与中间服务器间通过采用XML技术，使得网络上传输的是简单的文本，大大减少了数据传输量（只传输最终结果，不传输作为中间结果的数据集），降低了传输耗时，同时，因为网络上传输的是没有复杂格式信息的文本文件，还减少了数据校验的耗时，从而总体上可以提高系统运行的速度。

　　由于客户端不进行商业逻辑处理，可以降低客户端对系统资源的开销。

　　采用无需安装的客户端部署方式，还能减少系统的维护工作量。

　　另外，三层结构的采用，使得中间层应用服务器可以提供必要的负载均衡功能，专门解决潜在的并发访问问题。

　　2）统一开发平台

　　在现有的DEMO_HRMS系统中，同时采用了Develop2000与PowerBuilder两种开发工具，而KPI系统与绩效管理系统则成功地采用了Delphi。

　　事实证明，Delphi在三层结构的管理信息系统开发中有着一些独到的优势，它是最早支持也是最为稳定的三层计算模式的专业开发工具；它受到大量程序员的青睐，拥有丰富的控件资源；它开发的软件界面十分友好；与各种数据库有着很好的接口；学习与使用简单等等。

　　如果同一个系统的开发平台不统一，将会导致系统维护难度的增加，接口也将成为一个问题。

　　DEMO公司的KPI系统是一个庞大的系统整合工程，其人力资源状态指标将建立在HRMS系统之上，如果新的DEMO_HRMS系统能够与KPI系统实现平台统一，在数据库的设计上通盘考虑，将为KPI系统未来的不断提升创造良好的条件，并能大大降低KPI系统数据采集与维护的工作量。

　　通过在KPI系统以及绩效管理系统中的成功应用，Provider相信，Delphi是能为DEMO公司重建HRMS提供快速、专业、界面友好的解决方案比较好的选择。

　　3）增强系统灵活性

　　在新的DEMO_HRMS系统中，必须要增强其灵活性以适应管理需求的不断提升。Provider公司作为专业HR系统开发商，因为需要考虑大量不同客户的需求，因此，在系统设计的灵活性上有着丰富的经验与技术储备。

　　4）建立工作流引擎

　　现有DEMO_HRMS系统由于缺少工作流机制，使得大量HR管理流程无法通过网络实现，导致的结果是人工流程照样走，走完的结果以书面的方式提交给HR部门，再由HR管理者将全部信息维护到数据库中，着无疑增加了HR管理者的工作量。

　　如果系统有了工作流引擎，很多HR管理流程就可以再网上实现了，比如休假，申请人在网上填写完休假申请单后，将提交给主管审批，主管审批完，再提交给下一级管理者，直到数据入库，而整个过程中，相关人员各司其职，分别填写自己该填的信息，而不至于最后由HR管理者来维护全部信息。

　　Provider的HR系统中已经具备对工作流机制的支持，这在我们为DEMO公司开发的新的绩效管理系统中已经充分体现。

　　5）强化权限管理

　　由于员工与各级管理者的参与，由于将来使用新的DEMO_HRMS系统的用户会越来越多（比如绩效管理系统的用户目前是2000人，最终会达到20000人），系统在权限管理上就必须要找到一个简单的方法，而不能象目前那样，建一个新用户就要到数据库中创建一个数据库用户以及建立一个新视图。

　　Provider在DEMO公司KPI系统与绩效管理系统中，权限的管理采用了建立二级帐户的方法，所有用户都公用同一个数据库帐户，而功能的权限管理和机构的权限管理都在系统中完成，不会涉及到对数据库的直接操作。这种解决方案是未来DEMO_HRMS系统值得借鉴的。

　　5、管理体系的完善

　　如果确定了某项管理职能必须进行信息化，那么对于将要影响到系统推广应用的管理体系，要有决心进行统一，并进一步完善。这是DEMO总部人事部需要引起重视的一项工作。