SAP項目文檔的考核標準

項目啟動階段
項目計劃及對計劃的調整

建議：
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、 記錄每個問題發生的時間、匯報的人員，負責解決問題的人員，要求的期限，處理的結果。并分清責任。

我們一般按照四步法去實施項目，實際上與其大同小異。

項目準備階段
藍圖設計階段
系統上線階段
驗收交付階段

這是前陣子做的一個SAP項目審計中對文檔的審計標準。

這份標準實際上包括有幾個部分：
1、就是大家見到的這部分，主要說明了一個SAP項目中應該包括哪些內容（當然這部分并非全部，而只是常見的部分）。

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

由于做的項目多為小項目，文檔內容難免不全，也希望各位能加以補充。

也見過很多項目的文檔，說實在的，即使是五大的文檔很多也殘缺不全。一方面跟項目文檔的管理不嚴謹有關系，另一方面也是顧問或者用戶在做文檔的過程中偷懶－－偷懶是人的本性啦。

發布這些東西的目的也是在于，期望客戶方對SAP項目所要形成的文檔有個初步的認識－－別被某些懶顧問忽悠了。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的SAP项目文档　清单　考核标准的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。