實施過幾個ORACLE HRMS項目，把自己實施過程中的一些經(jīng)驗和想法拿出來分享一下，可能不太系統(tǒng)：（
總體：
1、系統(tǒng)實施是和人打交道，特別是人力資源系統(tǒng)，是和人力資源的人打交道，和他們搞好關(guān)系是必要的，也是必然的~系統(tǒng)好不好，能不能用，都是人去做的，也是人說的。作為一個信息工具和數(shù)據(jù)倉庫，大量基礎(chǔ)數(shù)據(jù)的錄入和維護都是人工完成的，必須得到他們的支持和配合。
2、先不要去了解需求，人力資源管理，哪個單位都差不多的，從技術(shù)的角度上講，也就是說只要你跟著實施了一個項目，就有能力獨立做好另外一個項目。這點你不用擔心。至于業(yè)務(wù)，沒有太大的大型企業(yè)、小型企業(yè)以及國營企業(yè)、外資企業(yè)之分，也就是報表和管理側(cè)重內(nèi)容、細度的區(qū)別。大體了解一下現(xiàn)有的業(yè)務(wù)規(guī)則以及總體目標就差不多了~做到心里有數(shù)。
3、系統(tǒng)真正開始實施階段，把計劃制定的細致一點。計劃越細致，工作起來就越輕松，到時候按部就班進行就是了，當然，計劃細致也意味著調(diào)整計劃的可能越多，只要控制在整體進度范圍內(nèi)即可，把關(guān)鍵點抓住，沒必要因為有些可有可無，可輕可重的流程或步驟去頻繁的催促用戶，畢竟大家要互相體諒。我做的有的項目，對過程控制的都比較嚴格，事實上，系統(tǒng)實施是給用戶用的，這個最終目標我們一定要把握住，至于文檔，UAT測試什么的，自己有個把握就差不多了。你不會真的指望用戶在UAT的時候給你測試系統(tǒng)的功能、安全性和穩(wěn)定性吧？
需求分析階段：
4、根據(jù)自己的所有知識，包括業(yè)務(wù)知識和系統(tǒng)功能，盡可能的列出需求清單列表，把要問的問題形成文檔，需求要做細，問問題要到位，具體調(diào)研的時候可以通過調(diào)研的效果進行取舍。對于大型企業(yè)、集團型企業(yè)，要參考公司層的看法。但更需要跟基層單位的具體業(yè)務(wù)人員進行訪談。因為系統(tǒng)畢竟主要是他們來用，ORACLE本身的操作性是有一定局限性的，多跟他們溝通，有利于消除這個系統(tǒng)是為集團服務(wù)的這種觀點，可能有時候大型項目，基層操作用戶比較多，也不能簡單地讓他們填寫了事，需要找一些對業(yè)務(wù)比較精通的人員進行面對面、一個一個問題的溝通。另外，他們對一些問題看法也是系統(tǒng)需要解決的，對于集團來說，他們更關(guān)心的是報表，人事的指標集找他們要，大體框架和目標他們給就行了，挖掘不了更多的東西，具體的事情還是下面的人來做。另外，在需求分析階段，經(jīng)常會有一個系統(tǒng)原形的演示，這個演示無論你怎么準備，都會是比較糟糕的，業(yè)務(wù)人員會產(chǎn)生抵觸。這就更應(yīng)該找關(guān)鍵業(yè)務(wù)人員溝通，這個階段不是討論系統(tǒng)是怎么樣子，而是，討論未來業(yè)務(wù)應(yīng)該怎么去實現(xiàn)。不要陷于對系統(tǒng)界面、一些特殊的功能、員工編碼等一些無聊而且不能立即就能解決的問題爭吵中去。
解決方案階段：
5、整理好需求分析，就可以考慮解決方案了。也就是未來系統(tǒng)該如何實現(xiàn)了。對于人力資源來說，應(yīng)該還是比較簡單的。但也要仔細考慮需求的取舍。有些需求是互相矛盾的，有些需求是現(xiàn)有的工作模式，在ORACLE標準功能中可以有更好的替代方案，有些是比較合理的，但ORACLE標準功能無法實現(xiàn)。這些都要跟人力資源部的人有個很好的解釋，并最終得到用戶的確認。不要忙著完成這個文檔，對于文檔本身，這個是非常重要的，但也是最值得不斷討論完善的，不要認為依據(jù)這個文檔配置好系統(tǒng)就可以交差了。在用戶沒有實際使用這個系統(tǒng)之前，都有很多的變數(shù)，晚改不如早改，所以，應(yīng)該依據(jù)自己對業(yè)務(wù)和系統(tǒng)的了解，仔細地給用戶解釋清楚，怎么做？為什么這么做？把擴張性考慮在前面，讓用戶感覺到你真正在替他考慮問題，而不是自己根據(jù)上一個項目的經(jīng)驗往他們企業(yè)上套。這是比較關(guān)鍵的。只有在完全達成共識后，這個文檔就可以交付簽字確認了。
系統(tǒng)配置階段：
6、相信ORACLE，沒有ORACLE HRMS做不到的，只有你不會做的，或者說暫時不會做的。最多多繞點彎路而已。別聽信ORACLE銷售人員或者技術(shù)支持人員的概念或者PPT介紹，只要可能用到的功能或者有價值的功能，你自己親自去測試一下，就知道里面到底有些什么東西，具體實施時能做到什么地步。ORACLE功能是強大的，也是開放的。所以，不怕做不了，只關(guān)心如何做。不要怕客戶化，沒有客戶化，ORACLE任何一個項目都玩不轉(zhuǎn)，但每個客戶化都要仔細論證一下，是不是這樣開發(fā)合理，效率如何，客戶是否認同？是否有推廣價值，未來的擴張性怎樣？對于客戶化開發(fā)，其實一個有經(jīng)驗的咨詢顧問在前兩個階段就已經(jīng)心理有數(shù)了，不要這個時候才來感嘆需要那么多客戶化。ORACLE本身的標準功能是有限的，不要懼怕，需要客戶化的，跟客戶多溝通，怎么做更合理，也讓他們了解你為他們做了很多工作。很多公司嚴格控制客戶化的，這也不能改，那也最好別動。事實上，我不太贊成這種方式，系統(tǒng)是為用戶操作的，升級麻煩、版本控制麻煩、技術(shù)移交麻煩那是因為你這方面沒做到位。把這方面做到位，總比優(yōu)化某項操作給數(shù)個甚至上百個業(yè)務(wù)人員每次錄入薪酬數(shù)據(jù)少按一次回車鍵容易得多吧。不要把別人的工作量不當工作量~尊重業(yè)務(wù)人員就會得到同樣的回饋。當然，也不是主張什么都客戶化，那不是ORACLE HRMS系統(tǒng)了。對于一些非合理的要求要懂得去鑒別，并和用戶溝通，取得他們的諒解和支持。
上面主要寫了客戶化，至于標準功能，基本上就是值集、彈性域、菜單之類的啦，不多描述了?？傊粭l，擴展性、方便些、安全性仔細考慮，不要因為自己的武斷造成后面的反復；把能想到的做到，不要明知道可能存在問題，還要等用戶來提再去調(diào)整。
系統(tǒng)測試階段：
7、仔細測試吧。標準功能沒啥問題的?？蛻艋枰斏?，沒人手的話，找關(guān)鍵用戶也行。別等UAT，UAT完了就是正式上線了，那時候會有新的問題等你去處理，寧愿把這部分工作做扎實，把時間留給用戶培訓。
數(shù)據(jù)采集階段：
8、這個一般和系統(tǒng)配置，系統(tǒng)測試并行的，千萬不要放松~每次放在數(shù)據(jù)收集的時間總是最長的，也是最煩人的。一個好的數(shù)據(jù)收集模板是很關(guān)鍵的。另外對于數(shù)據(jù)時舊系統(tǒng)導出的，即便原來系統(tǒng)數(shù)據(jù)很完整，也要考慮到進入新系統(tǒng)后數(shù)據(jù)的合法性。先定員工編號，別串行了。別太相信用戶的身份證號碼，特別是來源不同的時候，例如人事的和薪酬提供的我就沒見過完全一致的。檢查一定要過細，與其后期頻繁的打斷關(guān)鍵用戶工作還不如前期把工作做實。
另外，在數(shù)據(jù)檢查以及后來的導入中，還是別自作主張改用戶數(shù)據(jù)了，實在太麻煩，至少先記錄下來讓他們確認完成后再導入系統(tǒng)。
運維支持階段：
9：ORACLE HR因為增加了有效日期這一新概念。而且，組織、人員類型、薪酬、終止雇傭都是集成，不是接受能力較強的用戶，自己做肯定會多多少少會犯一些錯誤的，開始階段還是經(jīng)常到用戶那多走走，多問問。不要因為一上線就萬事大吉了：）款還沒拿到呢
另外，人力資源項目不可能一下子全上，后續(xù)的培訓、能力、績效更麻煩，更沒有統(tǒng)一的標準，維持好用戶關(guān)系就是維持了自己的飯碗呢：）希望大家都是做完一個項目交一批朋友~
漏了一個培訓階段，原因在于，我不太會做培訓，呵呵
