项目启动阶段
项目计划及对计划的调整
建议：
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项目所要形成的文档有个初步的认识－－别被某些懒顾问忽悠了。
)
