|
实施过几个ORACLE HRMS项目，把自己实施过程中的一些经验和想法拿出来分享一下，可能不太系统：（ 总体： 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因为增加了有效日期这一新概念。而且，组织、人员类型、薪酬、终止雇佣都是集成，不是接受能力较强的用户，自己做肯定会多多少少会犯一些错误的，开始阶段还是经常到用户那多走走，多问问。不要因为一上线就万事大吉了：）款还没拿到呢 另外，人力资源项目不可能一下子全上，后续的培训、能力、绩效更麻烦，更没有统一的标准，维持好用户关系就是维持了自己的饭碗呢：）希望大家都是做完一个项目交一批朋友~ 漏了一个培训阶段，原因在于，我不太会做培训，呵呵 |
|
|
