如果项目实施的成功，那么公司的业务能够正常的流转，销售，采购，生产能实时准确的知道相关的需求计划。规范化公司的物料管理流程。减少了公司呆滞料和库存。
创新互联建站长期为上千家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为镇海企业提供专业的成都做网站、成都网站设计，镇海网站改版等技术服务。拥有10余年丰富建站经验和众多成功案例,为您定制开发。
MTO的运用理论上可以实现销售0库存。
文 | 大话SAP
我有时候会想，有没有一个万能公式，只要掌握了这个公式，项目就一定能成功。
说公式，可能不太恰当，实际上应该是一个To-do list，只要把这个清单上的事情做完，项目就完美结束了。
有点可惜，暂时我还没找到这样的一份To-do list。项目中总是有太多的不确定性，用户变幻莫测的心情，翻来覆去的需求。顾问也可能设计出不靠谱的方案，到了UAT的时候才被发现，之后再被推倒重来。
这一切，都让我想象中的「万能」To-do list成为不可能。
But，在大学里教马哲课的司马老师曾经说过：「事物都是既矛盾，又统一的」。在充满不确定性的SAP项目里，有一个阶段却是很规律的，固定做好几件事，就能获得预期的结果。
没错，我说的就是上线前的数据导入阶段。
废话不多说，下面说说5件事。
01 一份详细的上线数据切换计划
这是最重要，却常常容易被忽略的事情。很多顾问会认为，数据导入已经做过无数遍了，何必要什么计划，闭着眼睛都能做。
可数据切换绝不仅仅是顾问的事。一般项目上，大多数的用户都是第一次参与上线数据准备，他们其实很需要对整个上线过程有一个全面的理解：涉及多少个数据对象，负责人是谁，何时提交数据等等。
一份公布出来的上线数据切换计划就是整个项目组作出的承诺，无论用户还是顾问，都必须按照计划执行。有计划和没计划，绝对是天壤之别。
02 一套高效的数据导入工具
无论你喜欢用LSMW，还是最新的Migration Cockpit，抑或是你每次都是让ABAPer帮你开发专用工具，我都建议你一定要好好打磨自己的导数工具。
老祖宗说：「工欲善其事，必先利其器」，我从N个项目中体会到，这是真理呀。
设计得不好的LSMW，可能有三分之一以上的数据需要顾问前台手工处理。相反，只需要增加几个小小的判断和变量，就能让整个效率提高一大截。
大多数的数据对象，SAP都有标准的BDC或者BAPI可以调用。花点时间研究一下，比手忙脚乱的临时录屏要强得多。
03 准备好数据收集模版
有数据导入工具，自然得有数据收集模版，这是显而易见的事情。
什么才是一份好的数据收集模版？我觉得要满足几个标准：通用，准确，带例子。
通用，就是在模版中把必输字段和常用的可选字段都包括进去，既满足导入数据的最小需求，又通过可选字段，让用户能把尽量多的信息包括进去。有时候顾问会在数据模版中只放必输字段，等导完之后才发现某些其实有用的信息由于模版中没有，用户忘记提供了。再要修改，就麻烦了。
准确，是说对于每个字段都要标记清楚究竟是必输还是可选，长度有几位，如果是从选项中选择，那选项都有哪些。这些解释，是为了帮助用户准确填写模版。
带例子，这不用解释了。顾问先打个样，用户照猫画虎，错不到哪去。
04 给用户讲解数据导入模版
光有模版还不够。通常甩一份模版给用户去填，回来的结果都是错漏百出。
数据收集之前，一定要安排一次会议，逐字段给用户解释模版。这很重要，因为即便是中文字，每个人理解也都不同。模版上写着“成本中心”字段，你要的究竟是SAP里的成本中心，还是老系统的成本中心，不当面说明白，那可不行。
05 一次「模拟」数据导入
准备得再好，也不代表一定成功。想早点暴露问题，最好做一次模拟导入。
所谓模拟导入，一定要用真实数据。
模拟导入就是一次演练，测试导入工具的可用性，测试各个数据对象之间的先后顺序，测试真实数据量下所需的导入时间。
把该发现的问题提早发现了，等上线导入，真就是只是点点鼠标的事了。
99 最后
可能你觉得，有些项目导数时随意一点，一样上线了。我是这么想的：不认真，浪费的是自己的生命。
作为目前ERP升蓝 市场上最为领先的应用系统之一，一直以来，SAP R/3在提供API应用编程接口和接口工具方面也同样领先于其它ERP升蓝 厂商。ALE/IDocs是SAP公司为SAP R/3 R4.6C版本所提供的接口机制，目前应用最为广泛。在 R4.0以后的版本中，又添加了技术上先进的BAPI。本文作为系列介绍之一，对ALE/IDocs， BAPI以及其它可用的整合方式进行介绍。
1、ALE/IDocs是什么？
ALE 是Application Link and Enabling的缩写，是SAP专门为SAP与SAP之间所设计的整合中间件。IDocs是中介文本 (Intermediate DOCument) 的缩写，是SAP提供的系统整合专用的数据/消息格式。ALE在SAP 3.0版本开始就作为SAP整个应用体系的一部分，为分布式数据交换提供了可靠安全的通讯机制。ALE的设计，原本作为两个SAP流程之间的一种消息传递服务(Messaging Service) ，使SAP与SAP的业务流程之间企业数据能够有效的交换，为两个独立的SAP之间提供了的系统整合服务。不过，随着应用的发展，ALE/IDocs接口机制也已然成为与其它非SAP系统的标准的整合方式。
ALE的设计结构可以分为三层，即应用层，数据/消息分配层和通讯层。通讯层是SAP整合机制的基础，它利用远程功能呼叫RFC(Remote Function Call) 调用SAP系统的功能模块。
数据/消息分配层，主要提供三个关键服务：
按数据分配模型决定数据接收者。
消息的过滤和转换。
数据/消息的压缩，以提高传递效率。
应用层直接与SAP系统接口，生成或从其它系统接收含有路由信息的消息文本IDocs，包括消息接收者的姓名，要求发送的类型以及对消息进行处理的规则。
ALE的机制代替了原来的SAP所提供的批数据通讯BDC(Batch Data Communication) 方式。顾名思义，BDC为系统之间提供了简单的数据批处理服务，还不能作为一种中间件技术，它没有提供系统之间进行无缝整合所要求的纠错功能、系统管理和其它安全措施。总得说来，应用SAP的ALE机制进行SAP与SAP或非SAP系统整合有以下几个好处：
ALE技术不受SAP版本升级的影响，它提供了版本向后兼容性。ALE定义于SAP应用层，与SAP的逻辑层相对独立，整个ALE中间件独立于发送和接收系统。
ALE消息设计逻辑保证消息的“一次且只有一次”的消息传递。ALE采用“存储-发送”技术确保消息即使系统发生故障或接收方没有准备接收时也可以达到目的地。这样就保证接收方不至于收到重复消息。
ALE也提供了IDocs管理功能。主要有文本缩减、文本版本控制以及文本数据过滤。三种控制机制使得SAP开发人员可以根据实际需要对IDocs文本在运行中进行动态处理。
ALE提供了系统管理功能，允许对ALE系统进行启动/复位/恢复等系统操作，为开发人员提供了进一步的管理控制。
IDoc 几乎可以传带任何SAP应用的数据，是一种“外围”定义格式，与SAP的应用数据定义不直接相关。IDocs已经广泛应用于早期的SAP-EDI的数据交换，因而它的设计有点类似于EDI的标准，即EDIFACT标准。
IDocs是以字符基础的，因而是可读的。它有三种纪录类型，即：
控制纪录-含文本信息，如IDoc类型，发送/接收方信息以及文本标识。
数据纪录-含管理和实际数据部分。
状态纪录-用来追踪文本传递各点的状态，如状态码，系统时间，错误标识等。
2、ALE/IDocs的消息发送接收过程
下面对ALE/IDocs在系统整合过程中消息的实际传递进行介绍。
让我们首先看发送过程。
一个发送过程由事件触发，文本生成，数据打包以及交由传输媒介传递这四个步骤组成，具体如下：
应用系统事件触发
系统目标(Objects) 的状态变化，用户自主活动或其它数据库特定变化等可以启动数据表的触发程序，从而进行数据传递的初始化工作，如数据准备。
生成主IDoc文本(Master)
按标准格式生成主IDoc文件，包含所有可以传递数据(不分接收者)
生成通讯Idoc
从主IDoc中生成只与特定接收者有关的文本，通讯文本是主文本的子数据集(Subset)
Idoc 发送
利用异步通讯方式将一定版本的IDoc传递到接收方。
下面，让我们看接收过程。
接收过程始于SAP系统从外部收到IDoc文本。接收过程的优点在于，接收方既可以是SAP系统，也可以是第三方系统，这也是SAP与第三方进行有效整合的基础。接收过程由以下三个步骤组成：
存储Idoc-将文本存储于数据库，并进行语法校验
邮件处理程序读取Idoc--一个专门设计的IDoc处理程序读取IDoc并产生SAP或其它系统所需的系统消息。多个程序可以同时运行。
生成系统文本--处理程序进一步生成系统文本供系统使用，并将结果信息存于Idoc d的状态纪录中。
3、BAPI简介
BAPI是Business Application Programming Interface的缩写， 是SAP为3.0版本以上提供的基于企业目标(Business Object) 技术的接口应用界面。SAP在3.0版本以上采用了Object-oriented技术，逻辑定义了SAP R/3系统的所有功能目标，并且将所有的目标(Objects) 和BAPIs存储于企业目标库BOR(Business Objects Repository). SAP R/3 企业目标的目标类型(Object Type) 相当于目标设计语言中类(Class) 的概念，其定义结构由以下几部分组成：
基本数据--所有目标类的通用属性，如目标标识和默认方法(Method) 。接口界面--目标的方法(Method)， 事件(Event), 特征(Attributes) 。键(Key Fields)--供BOR中目标检索使用方法(Methods)-- 对目标进行所要求的各种操作。
特征(Attibutes)-- 描述目标特征。事件(Events)-- 触发以改变目标状态。
利用BAPI，开发人员可以实现对BOR进行实时访问，从而实现应用系统(SAP-SAP)之间在数据/逻辑层上的有效整合。
4、应用SAP-DCOM接口SAP于1998首次提供SAP-DCOM接口，以满足各种桌面应用开发的要求。利用DCOM连接端口，开发人员可以利用VB， C++，以DCOM目标方式访问SAP数据。在Web应用上，可以用VBScript, JavaScript 以DHTML方式页面访问，也可以用ASP访问数据。
另外，利用DCOM也可以间接访问SAP的企业目标库BOR。上面提到的BAPI是SAP系统上专用的，在实际应用上不如DCOM来得广泛。DCOM端口主要有两个技术模块组成，一个是管理模块，另一个模块生成SAP BO的DCOM 代理组件(Proxy Components)，生成的DCOM组件存放于C++。代理组件有以下属性：
Client-要访问的R/3客户系统
UserID-R/3用户
Password-用户密码
Language-系统语言
Destination-预先定义的目标名称
另外，每个组件具有以下方法：
PutSeesionInfo()—设定系统一次调用的目标参数
AdviceRfcGuiSink()—用于需要SAPGUI或dubugging的场合。
CommitWork()-用于数据更新，无implicit commit的场合。
InitKeys()-DCOM目标键初始化
DimAs()-返回Microsoft ADO(Advanced Data Object) 纪录集(支持游标控制)。
其它从R/3 BO定义中继承的方法。
总起说来，SAP R/3 作为一个相对灵活的ERP升蓝 系统，利用上述的各种整合技术能够实现SAP系统之间以及SAP 与其它系统之间的数据/过程的整合。当然，一个应用系统的高度客户化导致了系统整合的难度。随着系统功能的增加，多种可供采用的整合技术也就显得很有必要。对于SAP R/3用户来说，正确选择适用的整合技术是实现成功系统整合的关键。