人力资源管理系统HRMS 天下三分—— Oracle HRMS,PeopleSoft HR,SAP HR，今日煮酒论英雄，大话三个HRMS的区别和联系：
主流HR软件对比分析
Oracle优点：
1. 从整体来说，Oracle套件属于大而全，比较完整的，全球化做得也比较好，公司的技术人员如果比较熟悉Oracle DB，也会比较愿意去用Oracle套件。
2. Fast Formulas可以使在 payroll 模块，增删改一个员工的薪水的计算公式时方便一些。
3. iLearning比较好。可以比较好地加入外部的培训目录、测验的功能。
4. 报表工具（就是Discoverer ）看上去比较容易使用。 不过我觉得peoplesoft的基于浏览器的更容易使用。
缺点：
1. patch 太多，有些地方好像还没开发好。
2. 实施比较麻烦，升级也比较麻烦。
3. 没有自带portal，如果要和其他portal 集成，会很麻烦，和其他系统集成也是很麻烦。
4. 由于HR模块不是重点，所以整个看上去更像把日常流程电子化，没有想过怎么增加HR的生产力。我记得2002年有个调查，说近50%的oracle HRMS的用户觉得，oracle的HR模块只能满足不到50%的需求。不过那时候大部分还是用老版本，用11i 的还很少，所以偏低也不奇怪。

SAP的优点：
1. 也是整个套件比较完整，全球化比较整齐。一般来说，制造业公司都倾向选择sap，上了sap后又都会打算上HR模块，不过最后, hr 模块上不上还取决于很多因素。
2. Portal 做得好。mySAP Workplace Portal 相当好，有些方面还比peoplesoft的Enterprise Portal 还好。不过，sap的 portal 和sap 套件其实是两种技术了，两种都掌握需要更长的时间。
3. 工作排程也作得非常好。可能是得益于制造业在这方面的需求和管理的严密性吧，和Oracle/ peoplesoft相比，sap 这点尤其突出。
4. 画组织结构图比较方便。并且修改组织结构图时可以同时修改��位等记录。
缺点：
1. 结构比较庞大复杂。其实有些部分不需要那么做，例如中间件，用tuxedo不挺好吗，sap 自己做了一个，系统管理也是，有了openview了，sap 还要自己做。从sap的开发重点来看，sap似乎是希望先整合好体系结构。
2. DB和app 的server的投入需要比较大。这和sap的架构设计有一定关系。
3. 实施时间比较长，实施价格比较贵。HR也不是sap的强势领域。

PeopleSoft 的优点：
1. 在HR方面，是领导者。需求分析做得比较深入，功能有前瞻性，portal 很直观，很容易使用，完全BS结构。有时候，单看菜单，好像大家都差不多，或者其他的看上去更容易用，但用下去，peoplesoft 肯定是最有效率的。
2.Payroll 比较好。peoplesoft 是全球一个db，从管理、功能更新、维护上有优势，跨国企业比较喜欢。因此payroll 可以全球统一管理，而且可以做demo 测试 rules 。
3. 自助服务，对客户的培训，这两个功能，都是peoplesoft 带头先做，并且做得最好。
4. 喜欢其HR模块的用户多，忠诚度高，尤其愿意使用 payroll 和 portal 。
5.实施周期短，总体价格比oracle/sap便宜
缺点：
1. peoplesoft 的全球化还不够完善，外资公司没问题。
2. 和高档的sap/oracle 相比，这两个可以买某某某几个模块送HR模块，peoplesoft 不行。呵呵。和中档相比，价格和复杂程度会比中档的套件贵、复杂。（其实总的看，贵不了多少。）
3. 懂的人少，招人困难。

总体：
1、系统实施是和人打交道，特别是人力资源系统，是和人力资源的人打交道，和他们搞好关系是必要的，也是必然的~系统好不好，能不能用，都是人去做的，也是人说的。作为一个信息工具和数据仓库，大量基础数据的录入和维护都是人工完成的，必须得到他们的支持和配���。
2、先不要去了解需求，人力资源管理，哪个单位都差不多的，从技术的角度上讲，也就是说只要你跟着实施了一个项目，就有能力独立做好另外一个项目。这点你不用担心。至于业务，没有太大的大型企业、小型企业以及国营企业、外资企业之分，也就是报表和管理侧重内容、细度的区别。大体了解一下现有的业务规则以及总体目标就差不多了~做到心里有数。
3、系统真正开始实施阶段，把计划制定的细致一点。计划越细致，工作起来就越轻松，到时候按部就班进行就是了，当然，计划细致也意味着调整计划的可能越多，只要控制在整体进度范围内即可，把关键点抓住，没必要因为有些可有可无，可轻可重的流程或步骤去频繁的催促用户，毕竟大家要互相体谅。我做的有的项目，对过程控制的都比较严格，事实上，系统实施是给用户用的，这个最终目标我们一定要把握住，至于文档，UAT测试什么的，自己有个把握就差不多了。你不会真的指望用户在UAT的时候给你测试系统的功能、安全性和稳定性吧？

需求分析阶段：
4、根据自己的所有知识，包括业务知识和系统功能，尽可能的列出需求清单列表，把要问的问题形成文档，需求要做细，问问题要到位，具体调研的时候可以通过调研的效果进行取舍。对于大型企业、集团型企业，要参考公司层的看法。但更需要跟基层单位的具体业务人员进行访谈。因为系统毕竟主要是他们来用，ORACLE本身的操作性是有一定局限性的，多跟他们沟通，有利于消除这个系统是为集团服务的这种观点，可能有时候大型项目，基层操作用户比较多，也不能简单地让他们填写了事，需要找一些对业务比较精通的人员进行面对面、一个一个问题的沟通。另外，他们对一些问题看法也是系统���要解决的，对于集团来说，他们更关心的是报表，人事的指标集找他们要，大体框架和目标他们给就行了，挖掘不了更多的东西，具体的事情还是下面的人来做。另外，在需求分析阶段，经常会有一个系统原形的演示，这个演示无论你怎么准备，都会是比较糟糕的，业务人员会产生抵触。这就更应该找关键业务人员沟通，这个阶段不是讨论系统是怎么样子，而是，讨论未来业务应该怎么去实现。不要陷于对系统界面、一些特殊的功能、员工编码等一些无聊而且不能立即就能解决的问题争吵中去。

解决方案阶段：
5、整理好需求分析，就可以考虑解决方案了。也就是未来系统该如何实现了。对于人力资源来说，应该还是比较简单的。但也要仔细考虑需求的取舍。有些需求是互相矛盾的，有些需求是现有的工作模式，在ORACLE标准功能中可以有更好的替代方案，有些是比较合理的，但ORACLE标准功能无法实现。这些都要跟人力资源部的人有个很好的解释，并最终得到用户的确认。不要忙着完成这个文档，对于文档本身，这个是非常重要的，但也是最值得不断讨论完善的，不要认为依据这个文档配置好系统就可以交差了。在用户没有实际使用这个系统之前，都有很多的变数，晚改不如早改，所以，应该依据自己对业务和系统的了解，仔细地给用户解释清楚，怎么做？为什么这么做？把扩张性考虑在前面，让用户感觉到你真正在替他考虑问题，而不是自己根据上一个项目的经验往他们企业上套。这是比较关键的。只有在完全达成共识后，这个文档就可以交付签字确认了。

系统配置阶段：
6、相信ORACLE，没有ORACLE HRMS做不到的，只有你不会做的，或者说暂时不会做的。最多多绕点弯路而已。别听信ORACLE销售人员或者技术支持���员的概念或者PPT介绍，只要可能用到的功能或者有价值的功能，你自己亲自去测试一下，就知道里面到底有些什么东西，具体实施时能做到什么地步。ORACLE功能是强大的，也是开放的。所以，不怕做不了，只关心如何做。不要怕客户化，没有客户化，ORACLE任何一个项目都玩不转，但每个客户化都要仔细论证一下，是不是这样开发合理，效率如何，客户是否认同？是否有推广价值，未来的扩张性怎样？对于客户化开发，其实一个有经验的咨询顾问在前两个阶段就已经心理有数了，不要这个时候才来感叹需要那么多客户化。ORACLE本身的标准功能是有限的，不要惧怕，需要客户化的，跟客户多沟通，怎么做更合理，也让他们了解你为他们做了很多工作。很多公司严格控制客户化的，这也不能改，那也最好别动。事实上，我不太赞成这种方式，系统是为用户操作的，升级麻烦、版本控制麻烦、技术移交麻烦那是因为你这方面没做到位。把这方面做到位，总比优化某项操作给数个甚至上百个业务人员每次录入薪酬数据少按一次回车键容易得多吧。不要把别人的工作量不当工作量~尊重业务人员就会得到同样的回馈。当然，也不是主张什么都客户化，那不是ORACLE HRMS系统了。对于一些非合理的要求要懂得去鉴别，并和用户沟通，取得他们的谅解和支持。
上面主要写了客户化，至于标准功能，基本上就是值集、弹性域、菜单之类的啦，不多描述了。总之一条，扩展性、方便些、安全性仔细考虑，不要因为自己的武断造成后面的反复；把能想到的做到，不要明知道可能存在问题，还要等用户来提再去调整。

系统测试阶段：
7、仔细测试吧。标准功能没啥问题的。客户化需要谨慎，没人手的话，找关键用户也行。别等UAT，UAT完了就是���式上线了，那时候会有新的问题等你去处理，宁愿把这部分工作做扎实，把时间留给用户培训。

数据采集阶段：
8、这个一般和系统配置，系统测试并行的，千万不要放松~每次放在数据收集的时间总是最长的，也是最烦人的。一个好的数据收集模板是很关键的。另外对于数据时旧系统导出的，即便原来系统数据很完整，也要考虑到进入新系统后数据的合法性。先定员工编号，别串行了。别太相信用户的身份证号码，特别是来源不同的时候，例如人事的和薪酬提供的我就没见过完全一致的。检查一定要过细，与其后期频繁的打断关键用户工作还不如前期把工作做实。
另外，在数据检查以及后来的导入中，还是别自作主张改用户数据了，实在太麻烦，至少先记录下来让他们确认完成后再导入系统。

运维支持阶段：
9：ORACLE HR因为增加了有效日期这一新概念。而且，组织、人员类型、薪酬、终止雇佣都是集成，不是接受能力较强的用户，自己做肯定会多多少少会犯一些错误的，开始阶段还是经常到用户那多走走，多问问。不要因为一上线就万事大吉了：）款还没拿到呢
另外，人力资源项目不可能一下子全上，后续的培训、能力、绩效更麻烦，更没有统一的标准，维持好用户关系就是维持了自己的饭碗呢：）希望大家都是做完一个项目交一批朋友~