自学SAP三道坎
成都创新互联主营工布江达网站建设的网络公司,主营网站建设方案,成都app开发,工布江达h5微信小程序搭建,工布江达网站营销推广欢迎工布江达等地区企业咨询
打算进入SAP咨询领域的朋友很多，只是SAP的产品过于复杂，而实施了SAP的企业也不愿意重新培养自己SAP人员――培养了不长时间就因为薪资待遇问题而离职，得不偿失。所以对于有ERP工作经验的人来说，SAP的门槛太高。入行的机会甚至远小于那些刚毕业的学生。
通过自学SAP进入SAP咨询领域，相信是很多ERPer共同的梦想，那么如何跨过这道门槛呢？在这里我总结了些经验供大家参考。
第一道坎：入门
自学SAP的人在入门的时候常常遇到的有四个误区，或许很多人都没有仔细考虑过，这样的错误我也曾犯过，也耽误了不少时间。
误区一：不学前台学后台
有ERP经验的人自学SAP反倒不如没有ERP经验的人学习SAP快，或许这个问题很多人都没有想过。在论坛里跟很多自学SAP的朋友沟通过，似乎大伙所看重的不过是如何配置SAP系统。装上个IDES就要研究SPRO――前台嘛，那算什么？可问题就在于：根基不稳，如何能走的快，走的远？很多人倚仗自己对别的ERP产品的理解来研究SAP，可往往在学习了很久以后仍看不到自己的长进，原因也就在于此：不够踏实。
误区二：不看功能，看维护
在这里所指的维护是一些“设置用户权限”“CLIENT拷贝”“系统调优”“内存优化” “数据库优化”等BASIS所做的工作。然而在真正的SAP团队中，这些工作是由专人负责的。花过多的精力在这个上面，也就耽误了真正该学习的内容。
不知道哪位仁兄在论坛里宣传什么装好IDES后拷贝一个“干净的”CLIENT来学习――或许这话是对的，但对于初学者来说：等到你能把所有参数都设置完成了，呵呵呵，恐怕已经是三五年后的事情了。
还有部分人一开始就琢磨SAP的权限分配、数据库备份。而这部分也是由BASIS专职负责――而做好BASIS的难度绝不亚于一个模块顾问的难度。
误区三：开发跟实施不分
也听很多朋友说过：研究一个系统最简单的方式是看数据库中数据的流向。弄懂了数据的流向你才能真正明白这个系统是如何设计的，才能从底层掌握这个系统。嗯，这话没错。但别忘记：你是个初学者，你的目标是SAP的咨询顾问，而不是开发人员。对，ABAPer跟咨询顾问也是两个职位，除非你自己定位的是开发顾问，否则，在初学的阶段还是远离ABAP的好。要知道SAP有数万个表，一个不小心你就会掉进迷潭。
但话也要分开讲――一个不懂ABAP的咨询顾问，也绝对成不了高级顾问，只是你不能太急罢了。
误区四：满大街找资料
我自己手头的SAP资料大约是几十个G吧，可回过头来看看，真正对自己入门帮助最大的还是ONLINEHELP。对，SAP的在线帮助。怎么？不知道哪有？上HELP.SAP.COM看看去。
大把的英文资料看得头痛？也是。但只要你找对方法，学习起来真就很容易了。而正确的方法就是：看跟IDES相关的东西。你装的学习环境不就是IDES嘛，里面什么数据都有，参考着SAP帮助文件里的步骤一步一步走下去，很快就能熟练的操作这个系统。入门实在是太容易了。
总结起来，入门的方法就是：不要急，从前台操作入手，研究透了基本操作再研究后台的设置。这个方法简单吧？对，抛开你以前所有的经验和资历，象一个完全不懂的菜鸟那样从SAP的基本操作开始学习。看看PPT，看看入门教材一步一步的走下去。
第二道坎：英语
说到学SAP的第二道坎，恐怕N多人都会有相同的感慨：英语。
很多人都上网去找中文的资料，说是看起来更容易些，可别忘记了，那并非SAP官方资料。在翻译和理解上中英文的资料差异还是非常大的。尤其是提高方面的资料――官方认证培训资历，可是只有英文版的。
作为一个自学者，在熟练的掌握了SAP的基本操作以后，必然要去看SAP的官方培训资料――提高嘛。更不用说我们在前面提到的ONLINE HELP。在这方面，如果没有良好的英语基础或者说没有看英文资料的习惯，在很长的时间内都难以提高。
说到英文的资料，如果是自学的话，最终于的一点还是强迫自己习惯这些东西。这也是没有办法的事情。
研究SAP的后台配置是学习最重要的工作之一，就我目前所能掌握到的资料来看，有心将所有的配置关联讲清楚的，也只有SAP的官方资料。所以……，不要叫苦啦。
第三道坎：机会
能不能耐的住寂寞？
对于自学者来说，不被正规渠道所承认是非常难受的事情。如何被正规渠道所承认呢？
在我看来，自学SAP难就难在耐不住寂寞。
仔细想想，对于SAP的用户来说，两年经验也都只能算菜鸟，那么对于自学SAP的人来说，你能否坚持两年，勤勤恳恳的学下去？相信没有具体的工作，很多人学习了三五个月便放弃了。而三五个月学习的真实效果如何？不用我说，对比了时间我想你也知道。当然，也有人会说：我投入的时间绝对不比人家专职学习花费的时间少――可这话，你仔细想想，能成立吗？有心做SAP顾问的人会不用心去学习系统吗？
所以我认为：坚持下去才是最最难得的事情。在你看不到路的情况下，如何抹黑的走下去。
对于自学SAP朋友的建议
1、 从基础开始，目标要清晰，绝对清晰。但不要把初始的目标定的过于远大。参考一个SAP顾问正常的途径走下去，从基本的操作开始。要对所有的前台工作都了如指掌。这也是一个SAP顾问所需要具备的基本要求。
2、 坚持看英语的文档，尤其是仔细按照ONLINE HELP所提供的那些练习一步一步的来做。有了基础之后在仔细研究SAP的标准教材。直到你有能力看完PA的课程。
3、 交流，尽量的与人交流，包括在BBS上，QQ群上，尽量的与人交流。而交流过程中最重要的并非看别人的帖子，按别人说的方法去操作――尽管这也是每个人学习SAP过程中要做的事情。最重要的是：解答别人的问题。细想一下：作为顾问难道不就是每天要回答用户提出的各种问题吗？对，你只是提前测试这项工作罢了。仅仅按照别人提供的思路解决问题并不能代表什么，关键是自己的吸收。
4、 规划自己学习的过程。按自己计划的方式学习，不要偏离方向。
对于第四点，我个人的感触特别深。对于自学者而言，你很难知道哪一天才能加入SAP相关工作的行列――一年？两年？甚至是更长的时间，没有一个良好的学习规划，并且坚持下去，恐怕没有人能等到最后。所以一定要给自己一个比较长期的规划。而对于一个SAP的项目来说，我们同样要强调的是计划。
5、 尽量结合你现有的工作整理数据。
对于所有的ERP项目来说对数据的收集整理导入都是必须经历的。而SAP的项目对于流程的调研、数据的收集更为重视。只有结合你现有的工作并在SAP系统中模拟这些工作，你才能更贴切的了解上一个系统到底要做些什么。
SAP的项目资料对于初学者和自学者来说参考价值有限。除了SAP公司似乎还没有哪家公司的哪套资料能将一个项目所涉及到的所有内容完整的展现――即使是有这样的资料，对于初学者来说你也不清楚什么阶段该做什么，什么阶段该如何循环。网络上的那些所谓项目资历对于大多数顾问来说仅仅是“参考”而以，甚至连参考的价值都没有。
想到的也就这么多了。坚持！就这样坚持下去！给自己两年的时间。
SAP官网本身提供若干免费试用下载和预约演示：
1、浏览器搜索SAP系统下载。
2、点击快速安装。
3、下载完成，我们选择打开。
4、选择解压到，选择一个文件解压位置，点击解压。
5、依次找到windows—system32—drivers—etc—hosts。
6、鼠标右键单击hosts，选择记事本打开。
7、在IP，网址之间添加空格，点击保存即可。
SAP系统的优势：
1、SAP是全球所有ERP产品中对企业构架和财务控制考虑得最细致的系统，也是整体控制逻辑和整体系统结构是最严谨的系统，可以让企业引进先进的管理理念；
2、对产品在各种行业的适用性考虑得最多的系统，即应用的行业最广；
3、SAP系统是整体稳定性最好的系统；
4、如中国最大的几家企业集团（中石油、中石化、中海油、几个钢铁集团等等）如果要在整个企业全面展开各个专业的、统一的ERP实施，SAP是唯一能适合的产品，特别是财务模块。
5、SAP有针对不同行业的解决方案，也有适合中小型企业的产品，如SAP Business One，SAP All-in-One，和云产品SAP Business ByDesign；
6、应用最广的产品。它集成性好，财务、物资、项目、设备、人力资源等等功能都具备。
对入门人员将学习sap可以按照如下步骤：
01：先熟悉前台操作，业务知识的熟悉是最重要的，应该放在第一步
02：在熟悉后台
03：找准机会做项目
自学SAP的人在入门的时候常常遇到的有四个误区：
误区一：不学前台学后台
有ERP经验的人自学SAP反倒不如没有ERP经验的人学习SAP快，或许这个问题很多人都没有想过。问题就在于：根基不稳，如何能走的快，走的远？很多人倚仗自己对别的ERP产品的理解来研究SAP，可往往在学习了很久以后仍看不到自己的长进，原因也就在于此：不够踏实。
误区二：不看功能，看维护
在这里所指的维护是一些“设置用户权限”“CLIENT拷贝”“系统调优”“内存优化” “数据库优化”等BASIS所做的工作。然而在真正的SAP团队中，这些工作是由专人负责的。花过多的精力在这个上面，也就耽误了真正该学习的内容。
误区三：开发跟实施不分
也听很多朋友说过：研究一个系统最简单的方式是看数据库中数据的流向。弄懂了数据的流向你才能真正明白这个系统是如何设计的，才能从底层掌握这个系统。嗯，这话没错。但别忘记：你是个初学者，你的目标是SAP的咨询顾问，而不是开发人员。对，ABAPer跟咨询顾问也是两个职位，除非你自己定位的是开发顾问，否则，在初学的阶段还是远离ABAP的好。要知道SAP有数万个表，一个不小心你就会掉进迷潭。
但话也要分开讲――一个不懂ABAP的咨询顾问，也绝对成不了高级顾问，只是你不能太急罢了。
误区四：满大街找资料
SAP的在线帮助。上看。正确的方法就是：看跟IDES相关的东西。里面什么数据都有，参考着SAP帮助文件里的步骤一步一步走下去，很快就能熟练的操作这个系统。
总结起来，入门的方法就是：不要急，从前台操作入手，研究透了基本操作再研究后台的设置。看看PPT，看看入门教材一步一步的走下去。
序
现在的中国，做软件咨询这行业的人已经烂大街了。
很多人从做技术转过来，SAP功能玩得很熟。
有的人从企业转去咨询公司，原先的业务很精通。
也有些人一毕业就能进咨询公司，一个项目接一个项目。
所有这些人，在这个圈子里混的人，对于怎么做项目，大多都能侃两句，说个1，2，3
什么Blueprint啦，Build啦，Testing啦，这些实施过程中的阶段，大家都说得出，都知道。
可是，大家真的都了解怎么做项目吗？
真的知道一个Deployment需要做的事有哪些吗？
真的知道一个Program中各个Deployment之间的联系吗？
真的知道为什么要这样做吗？
一，从最细节做起
我刚做项目的时候，是一个外企的Roll Out，PM是马来西亚人。
当时每个Team要做Status Report，Status Report是用PPT做的，有专门的模板
每周开会，大家在一起一个一个Team Review
PM在开会的时候，会盯住Report的格式。
增加一个页面不能用Ctrl C + Ctrl V，一定要在PPT里insert一个页面，这样才能最完整地Copy模板
每个页面的每个文本框的字体大小要符合模板
分行，分段，页数，日期格式，要符合模板
Report的内容里，一定要有准确的数字，本周计划完成几个，实际完成几个，绝对不能用百分比来糊弄过去要做的任务，要有PIC（Person in Charge），Target Day。
在描述一个事的时候，不能用“我们”“他们”之类的词。“我们”是谁？“他们”又是谁？
最后，还要写好revision history。
当时我们，特别是中国的同事，觉得好麻烦啊。花那么多时间看这些细节做什么。
字体不一样又不会有事。每个工作的完成情况，要精确到具体数字，统计起来也很花时间
不过，久而久之也就习惯了。
若干年以后，当我看到另一个国企项目的Status Report。
那个国企项目的Status Report，也有模板，但是很简单
而具体的报表内容，完全没有上面我提到的要求
结果就是，我完全看不懂。
另外，不同的Team的report要汇总在一起，如果字体不一样，换页的时候你会很明显看到差别。
Status Report只是一个小东西。但是对于细节的认真却是非常重要的。
任何一件事，谁去做，谁来review，怎么做，什么时候完成。。。
你如果不讲清楚，别人也不会知道，结果肯定是事情做不好，要不就Delay。
所以，要做好一个项目，首先请认真对待细节。
二，Logistics
这里的Logistic是指后勤，是项目中为大家提供的生活工作服务。
为什么要说这个呢？
因为作为一个Deployment，最开始的事情，是PM要解决Logistic方面的问题。
现在做一个项目，成员大多是从不同地方来的。那么住宿应该怎么安排？
通常的，PM要找几家当地的宾馆谈谈价格，有时客户那里也拿得到协议价。
住的地方不能离客户太远，上下班会花很多时间，打车费用也贵
住的地方不能离市区太远，顾问出差不能与世隔绝，也要考虑生活便利
住的地方的房型怎么样，是1个人一套还是2个人一套
2个人的话，人员怎么安排？不是随便2个男人就可以安排在一起的。
要考虑这2个人是否能相处。
往返机场，往返客户那里，找什么样的交通方式？
找固定的出租车司机还是随便在马路上打车？
要知道，安全是第一位的！
吃饭的话，Team Member有没有忌口，有没有国外的习惯
在客户那里，办公在什么地方，
一个项目20个人左右，加上Key User，怎么坐？
一般会说一个Team做一起，那么Team和Team之间的交流呢？
FI和CO要近一些，PP最好和MM近一些
顾问和Key User最好隔着坐，不要顾问只管自己，这样方便沟通
办公的地方，出入证明，电话，传真，打印机，复印机，饮水机，网络，空调，投影机，会议室
等等这些资源都要安排好。
把Team Member的名字贴在位子上方便别人找到
做一个通讯录，最好打印出来发给每个人
......
其实要说清楚Logistic的事情，实在是太多了。
可是你知道吗，这是PM要负责的事情
因为这时候项目还没有开始，人员还没来。
而且很多牵涉到费用，PM需要控制成本。
当然有的时候PM会找人帮忙，等项目开始以后让某个人来管。
但是，这始终是作为一个Deployment开始所要做的事
也许很多PM做这个比较随便，甚至很舍得花钱。
但我想说的是，事情做得好不好，关键还是在细节。
安排的资源有没有考虑别人的感受想法。
要考虑如何才能大家不用抱怨环境差，开心地工作。
三，Global Template
让我以一个Global的Program为例子吧。
什么是Template
通常的，在一个跨国企业实施SAP的时候，要面对的是不同国家，不同工厂
不同分公司业务也不一样，有些是生产型的工厂，有些是贸易公司
那么作为跨国企业，一般都是要把业务整合在一个系统里。
在SAP里就是1个Client，里面分多个Company Code
Company Code就是单独的分公司
所以在开始真正实施SAP之前，就要考虑整个企业（Client）的架构
包括统一的业务流程，统一的解决方案，统一的数据格式
这样一些统一的东西，就叫Template
我们自己的说法，也叫Global Template
等设计完了这些之后，再去一个一个工厂实施
在工厂实施过程中，肯定会碰到和Template不一样的需求，这时候也可以再修改Template.
Template包括哪些内容
首先是组织结构
要控制这样一个Template，就要有一个专门的Team来管理，GT Team (Global Template Team)
这个Team里每个人是一方面的专家，比如FI，MM。这些Team Member面对的客户的人，是整个企业这一级别的BPO（Business Process Owner），比如CFO。
在每个Deployment实施过程中，Deployment Team碰到的需要更改Template的需求，都要报告给GT Team，由GT Team负责协调其他Deployment，看是否能做这样一个修改
比如说某个Deployment想在物料主数据里用某个字段来放一些参考信息。
可不可以呢？这就要考虑，这个字段在SAP的标准功能的用途是什么，
物料主数据是被所有工厂都通用的，其他Deployment实施的时候会否用这个字段
这个字段在系统的报表里会不会被用到
......
Template的重点是Blueprint Design
物料主数据的命名规则是什么？
什么物料用什么物料类型？
集团的科目怎么定义？
Cost Center，Profit Center，Product Hierarchy
要不要用Material Ledger
要不要用Split Valuation
Document Type用哪些？Number Range是多少？
......
统一的Process
比如采购申请，谁提申请，谁批准
比如生产订单发料，是Issue to Order，还是Backflush，还是都可以
......
统一的权限控制
设置Common Roles，Deployment只要Copy 这些 Roles就可以了
......
Template也包括程序开发
有些report是整个企业都会用到的，那么就在Template里做好
到Deployment时期只要用就可以了
......
还有Document Template
所有的文档的格式，Status Report，Data Conversion Template，To Be Process，
当然包括我一开始提到的字体大小，分行分段等等，都是在Template里定义
怎么做一个Template
很遗憾，我没有做过Template，所以这部分我说得不仔细
做Template也是个单独的项目
一般在Program开始后，在Deployment开始前
企业会召集很多人，有顾问有用户，用户可能来自各个工厂
过程也象做项目一样，业务调研，蓝图设计，系统搭建，文档准备等等
为什么要做Template
很难想象，如果没有Template，怎么为企业实施一个整合的SAP系统
Template的好不好，还是取决于细节
当我一开始看到Template所做的文档，我很惊讶，居然把项目中要用的文档都做得那么详细
很多时候，我们只要Copy过来，改几个字就可以用了
看着Template，就可以很轻松地去工厂实施。
所以，一个好的，详细的Template，是整个Program成功的前提
四，Capture Local Input
有了Template，接下来就是去分公司/工厂做Deployment了
前面提到，不同的工厂业务不一样，Template不一定完全适用
所以在开始Deployment的第一个阶段就是Capture Local Input，中文来说就是收集当地的需求
那么怎么来收集需求呢？
首先要准备介绍资料。介绍SAP系统，介绍Template的设计
介绍资料一般用PPT做，用于在Workshop上跟用户讲解
其中的重点是，要用用户看的懂得方式去介绍。
我看到过一些人写的资料，包括培训材料，完全是走技术路线
说说用到哪些功能，T-code怎么样，在系统中产生什么Document，就结束了
可是，另外的，可以写一些：
1.名词解释
2.企业有什么Policy，来让我们决定Template的设计
3.原来的业务流程是什么，Template会改变什么，有什么Benefit
4.对于权限有什么影响，对应于业务上的什么部门的什么岗位
要记住我们在Template的基础上做实施，就是要做好功课，才去工厂Capture Local Input
介绍资料之后，还要有一个Question List
哪些物料类型会用到？
不能直接问有没有产成品，原材料。
可以问，有没有Packaging Material，比如Chip Board，Wood Pallets，Wood Containers
有没有Petrochemicals，比如Fuels，Industrial Chemicals，Lubricant
......
哪些Payment Term会用到？
比如见票30天付款，见票60天付款
......
在Template的基础上，就不要问很基础的问题了，要跟实际业务相关，能直接帮助之后系统设计的问题
在Capture Local Input阶段，通常会召集不同部门用户来开Workshop
召集的用户人员，范围，需要仔细研究
一个用户不能同时参加MM和FI的2个Session。所以有必要的话时间要错开
有的Workshop，需要BPO参加，要事先打好招呼发invitation
有的Workshop需要不同Function Team一起讨论，称为Integration Session
经过Workshop，要把Local Inputs记录下来，成为Local Inputs List
在这个List里，当然的，要包括
1.简短的一句话来描述这个Inputs
2.详细介绍
3.谁提出来的
4.提出的日期
5.对应的BPO是谁
6.分类，这个每个项目可能不同定义
7.需求类型，这是个Config相关的需求，还是Data Conversin相关的需求
8.是否影响Global Template
9.Priority，这个Priority有专门的定义，不是用户说High就是High的
10.谁负责跟踪这个需求
11.可能的解决方案
12.状态，Open还是Closed
这里要提到的是，记录的需求多没关系，只要跟踪好，稍后跟用户确认，状态Closed掉就可以了
就怕2种用户，说话太多和说话太少
这阶段嘛，项目经验还是很重要的。很多需求在Workshop时就可以砍掉了
另外，报表的需求也要在这阶段收集
重点是在这阶段就要做rationalization，合理化。
要知道，开发的需求搞得越多越烦，一定要砍掉，砍掉，砍掉。
最后，PM需要每天开会，Review Status
今天收集了多少local inputs, High的多少
不断地跟踪状态。
结束的时候，Local input list要跟BPO确认，作为下一阶段Blueprint Design的依据
五，Blueprint Design
Blueprint Design阶段，主要的时间在针对Local Input来讨论Solution
也就是说，收集到需求，都要在这一阶段找到解决方案
其中，有3个文档是最重要的
它们是Blueprint，To Be Process和Data Conversion Approach。
什么是Blueprint？
有一些比较概念性的介绍，比如这是系统的设计，解决方案....
实际的，这是一系列Word文档
每个文档对应一个模块，里面详细介绍各个功能设计
文档里要包括对于这一功能的需求介绍，详细的需求分析和解决方案，对于这一个Deployment的特别的结论
比如说，Physical Inventory 库存盘点
1.用户的需求是什么？保证库存准确率？和财务的Balance一致？
2.详细的需求呢？库存准确率是按Plant level还是Storage Location level？要不要用Cycle Count？
3.解决方案呢？A, B, C分类怎么定义？库存调整的Reason Code用哪些？
4.关于这一个Deployment，和Template有什么不一样的地方？
关于To Be Process，大家肯定看过到很多了
只是，这里要强调一下文档的规范
使用的符号，标注的方式，页眉页脚，都要根据Template来做
不然人家也很难看懂啊
Data Conversion Approach，简称DCT，是对于Data Conversion指导性的文档
里面包括，在这一个Deployment有哪些Conversion Items。
原始数据是哪里？数据量有多大？谁提供？谁协调？谁确认？
现有的SAP数据上传模板可不可以用？
原始数据怎么转成SAP的数据模板？字段怎么对应？比如在老系统里某字段的字符长度大于SAP的字段长度，怎么解决？
......
这3个文档，是Blueprint Design阶段的关键
整理好这3个文档以后，要跟BPO review，并且sign-off
作为下一阶段Build 系统的依据
除此之外，要开发的东西的列表也要在这一阶段确定下来。
项目实施，是一环接一环的，
你收集的需求不完全或者不准，那么你的Blueprint Design肯定也不完善
你Blueprint 阶段还留下一些需求没有解决方案，如果这样开始Build系统的话，以后肯定有问题要返工
每一阶段完成的标志是BPO Confirm。Sign-off以后不能随便改。
当然不是说不能有新的需求，也有的客户不重视sign-off
但是作为PM，要坚持这样的approach，要guide用户按这样的approach来合作
制订这样的approach，是项目管理中最重要的事。
六，Build and Testing
研究技术问题是中国人的强项。
很多强人对SAP的配置很熟悉，知道能不能在SAP里能实现某个功能
但是，光了解技术，要做Consultant是不够
首先介绍一下系统环境
在SAP里，不同的Client就是不同的环境
通
常的，有一个做Config的Client，一个做Development的Client，一个Sandbox的Client（随便改随便用）还有一个
SIT的Client，一个UAT的Client，Training的Client，Mock
Conversion的Client，Production的正式Client，User Support的Client
做Config的Client不能做任何Transaction，做好配置以后能自动传到Development Client
在Development Client里做Component Test
Development Client同时也是做开发的Client
因为在Config的Client里，如果做任何Transaction，有可能有的配置改不了
比如Number Range，你做了一个transaction，号码就跳了一个了
而Development需要测试程序，所以Development Client需要测试的数据
在做配置的时候，首先，要有一个Config List
这是一个Excel 文件，包括所有SAP IMG里面所有的配置项
单独用一列来标识，哪些Config 需要在这一个Deployment里做，哪些是Cross Client的，哪些是Corss Company Code。还要记录Transport Request号码
另外，当然是Config Notes了，相信大家看到过很多
Transport是Basis控制的，这方面要跟Basis协调好
谁提request，谁approve，什么时候传
一般在大的项目里，不是你想改就改配置的
要经过GT Team Approve
Testing分Component Test，SIT和UAT
Component Test就是你做好了配置，要去测试环境里试一下配置可不可以用，这部分不需要用户参与SIT和UAT都取决于你的Blueprint Design阶段
Testing Script来源于To Be Process
跟用户确定过哪些流程，当然就要在系统里都试一下
比如创建个物料主数据，做个销售订单。。。。
SIT和UAT的Testing Script都需要跟BPO确认
SIT和UAT的Testing Script结果都需要User Sign-off
SIT和UAT的区别在于
UAT的范围大于等于SIT，有些To Be Process比较简单，很少用到，那么跟BPO确认一下，SIT测了以后，UAT就不用再测了
SIT和UAT的用户范围不一样，SIT参与的用户是Key User，UAT参与的用户是Selected End User
还有Integration Test，是指有些流程是牵涉到3个以上模块的
比如Make to Stock，Make to Order
Integration Test在SIT和UAT阶段都会存在
Testing Script，Testing Data要事先准备好，
安排测试的时候，要注意用户的时间不能冲突，有的用户参加Integration Test和某个模块的Tesing，那么时间上要分开
七，Data Conversion
Data Conversion不只是上线前把数据导进去而已，而是贯穿整个项目实施过程所要做的事
一定要有一个专门的Leader，来负责盯这部分工作。
在Capture Local Input的时候，要确定Data Gathering Scope
对于每个模块，有哪些Conversion Items，数据源是哪里？谁提供数据，谁负责收集，谁Approve，数据量估计多少
在Blueprint Design阶段，要完成3个文档
DCA（Data Conversion Approach），DMM（Data Mapping Matrix）还有DCT（Data Conversion Template）
DCA里面要详细描述每一个Conversion Item怎么样导入SAP系统中
要怎么详细呢？
比如说，用户现在的数据要清理吧，那么怎么清理呢？
采购订单没有收货的怎么处理？收完的？收了一半的？发票先收了的？发票收了一半的？
数据怎么从用户的系统导出来？手工还是有工具？工具谁准备？谁测试？
DMM是用于Mapping用户系统和SAP的字段的
不同系统中，即使同样的字段，字符长度也可能不一样，更不用说一些物料参数了
DCT是用于上传到SAP之前的模板，基本上DCT里的字段完全对应SAP里的字段了
在Build and Testing阶段，要做Conversion Tools Build Test
这个好理解，就是开始按照之前的DCA来做事
在这一阶段，同时要展开的是Mock Conversion
通常的，Mock Conversion会有3次，Mock 1，Mock 2和FDR
为什么搞这么多次呢？
Mock
1的目标比较简单，可以只准备Go Live的30~50%的数据，生产型的企业可以准备一个完整的BOM。这样的Mock
Conversion，可以为SIT准备基本的数据，可以估计上传数据的时间，可以测试上传工具，可以保证用户了解Data Conversion全过程
Mock 2的要求就比较高一点，数据量要求Go Live的75%左右。
Mock 2的数据要为UAT做准备，需要取一个月底的时间，可以核对财务和物流的余额
FDR就是Full Dress Rehearsal，完全模拟上线的情况
上传数据的量和时间安排都要参考Cut Over的要求来做
而且FDR过程中的数据需要Sign-off，总之要模拟上线。
同时，很多这一阶段准备的数据也可以用在Cut Over的时候，比如Material Master，不用重复准备了。
Data Conversion是很重要的工作，可以通过它来熟悉用户的系统
没有经过好的Mock Conversion，怎么能保证上线能顺利进行呢？
最后，在系统上线前，那就是最终的Data Conversion。要安排好Conversion Plan
每一个Conversion Item，哪一天Upload，顺序是什么，有没有dependency
估计需要多少时间上传，数据量？谁负责上传？以及任何相关问题的跟踪。
八，Authorization
在实施项目的时候，权限是谁来实施的呢？
不是Basis，是Function Team。
Basis应该负责具体在系统中创建Role以及transport之类的工作。
但是关于决定需要哪些role，分别有什么权限，应该是Function Team的工作。因为Function Team会了解业务，知道Role应该怎么设置
权限的实施也不简单
首先，作为Global Template，已经有一套Common Role，在做Deployment的时候，就是要把这些Common Role copy as Local Role，有一些更改的作为Variant Roles
1 在做Blueprint Design的时候，要做Legal Entity Map onto Role
在这一个Deployment用到几个Company Code, Plant，哪些Common Role会用到，要列出来
2.Confirm SAP Tcode to Role Mapping
同样的，经过Blueprint Design，哪些T Code会被用到也应该知道了，要检查Commone Role里面是否都包括还有一些本地的开发会有新的T-code可能要加进去。
任何改变都需要创建Variant Role
3 Confirm Roles to User ID Mapping
这
是一个Excel文件，首先要用一个Sheet列出所有的用户信息，名字，ID，Department，E-mail之类。还有Role
Description，这个文件给用户看，当然要让用户知道每个role是做什么事，不要技术性的描述。还有SOD
Control，根据Sarbanes-Oxley所制订的审核原则，要用户知道什么role和什么role冲突。后面是重点，User ID
Mapping to Roles，这个不用多说了
这个文件应该交给Key User去完成，最后要BPO sign-off
不同的Team可能用Corss Team的权限要求，比如MM User想要财务的权限，
这就需要Authorization Leader去协调
4 接下来就是交给Basis Team去创建Roles了，技术方面的东西就不说了
5 权限测试
分2种测试，单独的Role测试和基于User ID的测试
为每一个Role创建一个ID，一个ID只有一个role，登录以后测这个Role的权限
为每一个User创建一个ID，在测试系统里，按照Function的操作测试用户的权限
6 最后，就是上线的权限准备了，
把Role传到生产系统里，在生产系统里创建ID，设置有效时间等等
这里要提到的是，权限的更改是正常的业务流程，只有要改T-code之类要transport的才是Issue
这在上线以后要特别区分开。
