對SAP專案文件的考核標準

w39發表於2007-03-06

這是前陣子做的一個SAP專案審計中對文件的審計標準。

這份標準實際上包括有幾個部分:
1、就是大家見到的這部分,主要說明了一個SAP專案中應該包括哪些內容(當然這部分並非全部,而只是常見的部分)。

2、標準文件的模版,主要是參考了以前專案和自己收集的文件資料所做的一個模版。這部分因為每個公司的標準不同,所以僅僅只能做個參考,對第一部分的參考。(這部分還在整理中,暫不公開,未來會放到我寫的SAP MM入門中)

由於做的專案多為小專案,文件內容難免不全,也希望各位能加以補充。

也見過很多專案的文件,說實在的,即使是五大的文件很多也殘缺不全。一方面跟專案文件的管理不嚴謹有關係,另一方面也是顧問或者使用者在做文件的過程中偷懶--偷懶是人的本性啦。

釋出這些東西的目的也是在於,期望客戶方對SAP專案所要形成的文件有個初步的認識--別被某些懶顧問忽悠了。

[@more@]

專案啟動階段
專案計劃及對計劃的調整

建議:
1、 對專案進度進行分類,定義每個階段的關鍵任務。
2、 對每個階段應形成的文件進行說明,哪類文件由誰製作,由誰籤核必須做出統一的規定。最好能提供每類文件的標準模版。
3、 定義每個階段結束的標誌,和判定結束的標誌。
4、 對於專案的進度控制可以參考專案管理方面的相關資料。在專案計劃中應特別留意對專案變更的控制。

專案調研階段
專案調研問卷
調研訪談記錄(訪談確認)
原型分析AS-IS
業務藍圖TO-BE
專案培訓文件
專案培訓記錄
培訓考試題目及成績

建議:
1、 確定調研的內容涉及到實施範圍內的所有流程。
2、 調研訪談記錄,記錄與使用者間溝通的所有關鍵內容,並由使用者確認。
3、 原型分析必須清晰的標明現有流程中控制的部分,以及需要產生哪些報表。對於各種報表建議按時間進行區分:哪些是日常性的報表,哪些是彙總報表,哪些是分析統計報表。
4、 業務藍圖經過相關領導簽字確認。並如實的在藍圖中反映該流程中所涉及到的各個崗位,及每個崗位處理該問題的頻率、時間。
5、 培訓文件,初期的專案培訓文件應該包括對本模組整體的內容培訓、關鍵部分的操作培訓等,並記錄每次培訓參與的人員,和考核的效果。

專案實現階段
系統配置文件
單元測試文件
整合測試文件
對整合測試的籤核
許可權設定文件

建議:
1、 系統配置文件詳細記錄了顧問在系統中做的每一個配置的動作,並有簡要的說明。
2、 配置文件應包括有基本的配置流程即配置的先後順序。
3、 單元測試文件為顧問測試本模組的配置是否正確,並對可能存在的問題進行修改。本文件非必要文件。
4、 整合測試文件以集中的方式測試業務藍圖中所涉及到的各個流程。
5、 使用者應對測試過程中產生的資料進行記錄,並對結果進行確認。所有參與測試的人員應在整合測試文件上簽字確認。
6、 在確認了使用者的權責後應對其在系統中的角色和許可權進行定義。
7、 在所有的配置完成後,顧問應督導使用者編寫使用者操作手冊。

系統切換階段(最後準備/啟動)
系統切換策略
使用者提供的原始資料
顧問匯入的模版
顧問匯入的原始資料

建議:
1、 定義系統整體的切換過程,什麼時間做什麼事情,由誰負責哪部分資料。
2、 定義每個模組切換時的注意事項,出現問題的反饋流程。
3、 顧問應提供資料匯入的模版和要求事項,由使用者保證資料的準確性。所有匯入的資料必須由相關領導簽字確認。
4、 對匯入的資料進行測試,初步檢查資料的準確性。
5、 對於所有匯入的原始資料資料均應保留,以方便事後對資料的核查。

專案上線
系統上線後的問題日誌
建議:
1、 系統上線後應該對整個上線的過程進行跟蹤,一般跟蹤的期限是1個月。
2、 記錄每個問題發生的時間、彙報的人員,負責解決問題的人員,要求的期限,處理的結果。並分清責任。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/854/viewspace-902891/,如需轉載,請註明出處,否則將追究法律責任。

相關文章