在SAP B1里面，主数据指的是物料、BOM、供应商、客户、仓库等需要预先维护到SAP中的数据。

其中主数据又大体可以分为两类：

一类是物料、供应商、客户等和业务相关，可能会经常有变动的数据。另一类是仓库、会计科目等相对固定，一旦建立就很少去变动的基础数据。今天我们主要来看看第一类。

对于和业务相关，经常会变动的数据。我们需要经常在SAP系统中执行添加、修改等操作。这部分数据会直接影响SAP系统中的业务是否能正常开展，后续的业务行为是否合理和准确。所以我们必须根据公司情况，设计一个严谨、合理的流程来进行主数据的维护。

如何设计一个严谨、合理的主数据维护流程？

首先要明确这个主数据的维护流程想要达成的管理目的；我认为：

第一是保证信息内容的准确性；例如供应商的名称和税号是否正确，客户的联系人信息和地址信息是否正确等。

第二是要通过流程，保证信息录入的准确性。例如供应商提供的税号虽然是正确的，但是在录入SAP的时候出现了错误，这就是信息录入的错误；通过流程的设计，达到尽量能够减少信息录入错误的目的。

明确这两个管理目的后，流程的设计思路就基本成形了。

我们需要把主数据信息的提供者，和录入者的角色分开。信息的提供者对信息本身的正确性负责；而信息的录入者，对信息本身的正确性不负责，仅对信息录入的正确性负责。

当一旦发现任何主数据的错误时，我们首先检查的是信息提供者是否提供了正确的信息。如果信息本身就是错误的，那么可以追究信息提供者的责任。

如果信息本身是正确的，仅仅是信息录入的过程中产生了错误，那么我们就需要追究信息录入者的责任。

出于流程设计的这种思路，我们需要在信息提供者和信息录入者之间添加一个可以追溯的流转凭证，以便于能正确追溯信息在哪一个环节出了问题。

这个凭证可以是一个纸质的流转单，也可以是依托SAP系统或者依托于OA系统的的一个电子流转单。例如新供应商评审表等等。

可能有些顾问就会有疑问了，为什么我们一定要把信息的提供者和录入者分开呢？假如真的如陈老师您所说，我们只是为了能追溯到责任，那么我们把这两个角色合二为一，提供者和录入者都是一个人，只要信息错了，我就找这个人，那不是更方便，责任更明确吗？

基于以下几个原因，我建议这两个角色是分开比较好。

其中最重要的一个原因是：信息的录入者，往往不知道信息的本身的内容。

例如一个录入的文员，他是不知道供应商的名称、相关资质或者联系人的。如果我们要把两个角色合二为一，那就只能是信息的提供者来完成，例如供应商的信息，就由负责开发供应商的采购员自己亲自来录入。

但信息的提供者，往往会是一个利益关联方。让利益关联方进行操作，流程会缺少监控手段和可能。

例如让一个销售员，自己来录入他所开发的新的客户，那么出于对销售业绩的追求，销售员有可能有意或者无意地，会录入一些夸大后的信息，流程会缺少发现些错误信息的监控手段。

这个道理其实就和财务上会计和出纳必须分开两个角色的道理，是一样的。

另外一个原因，是信息的提供者，往往并不会是一个人，或者一个部门。一个完整的基础主数据的信息，往往需要很多人，或者很多部门共同来提供和完成。

例如我们要维护一个物料主数据的信息，就会涉及到多个部门：

研发部门可能会提供物料的描述、规格、图号；质量部门会提供物料所要遵循的检验规范；采购部门会提供物料的单位包装量、提前期、默认供应商等信息；最后可能财务部门还会提供物料的成本计价方式、过账逻辑等等。

而这些需要多部门、多人共同才能完成的信息，假如没有一个统一整合和录入的唯一入口，会很容易导致数据重复、错乱，所以从实际操作来看，信息提供者和信息录入者分开，各司其职，我认为是最容易控管的一种设计方案。

基础主数据的维护通常有哪些具体流程来处理？

对于物料主数据的维护，基本上可能会涉及到以下几个部门，大家可以根据实际项目或者自己企业的需要进行选择：

其中物料的描述、规格、图纸号等，通常会有研发设计部门提供。

这里需要注意的是，我并不建议直接将图纸号用着物料编码。在现实中，图纸号和物料编号有可能会是多对多，而不是一对一的关系。

设计部门在进行图纸号分配的时候，考虑的仅仅是公司对图纸管理的需要。而物料编码，正如我们上一节所讲，有可能会考虑实物管理、财务要求，或者计划管理等多方面的需求。

经常会有研发部门一个图纸号对应多个物料编码的情况。

例如有一个东西，我们既可以自己采购、自己生产，又有可能会有客供料，那么在仓库管理和财务管理层面，我们必需要分配不同的物料编号进行管理，但它们有构造、设计可能是完全一样的，研发部门不愿意去维护两套一模一样，仅仅是号码不同的图纸。

而一个物料编码，也有可能对应多个图纸号。

例如有一些设计上的变更，会导致图纸产生细微的改变，但是出于一些原因，我们不想去变更物料编码，那么就会导致一个物料编码，会对应多个图纸号。

比如研发物料和量产后定型后的物料，在某些特殊业务场景下，就会产生研发阶段和量产阶段物料号相同，但图纸会有细微差别的情况。

更极端的情况下，有些物料是没有图纸号对应的。

例如外协半成品；出于管理的需要，BOM会有不同的层级划分，层级所产生的半成品，在研发部门可能是没有一个单独的图纸号去对应的。

又或者在BOM中一些特殊的子物料，例如工时，或者标准成本法管理下的一些费用物料，又或者用物料来管理的一些特殊的物料，如外购模具、工装、备品备件等物料，都有可能没有研发部的图号的。

如果强行去要求图纸号和物料编码必需一一对应，那么可能会在后期产生大量冗余和不必要的工作，例如明明对研发部来说毫无影响的变化，仅仅是其它部门，例如财务的某些要求，就让研发部投入工程师的时间去制作一套额外的图纸，这个显然是得不偿失的。

而用研发部门对图纸的编码规则来对物料做编码，很显然也不能很好地涵盖所有物料的编码。

所以物料编码应该是专门的部门，根据编码规则和其它部门提供的物料属性，专门来分配编码，因此在物料的信息提供者中，还需要有编码部门提供的物料编码。

在某些企业，会有制造工艺部门专职的包装工程师，设计物料的单位包装量，以尽量满足生产节拍的需要。比较典型的就是JIT生产模式的汽车行业。所以这部分信息会由制造工艺路部门提供。

采购部门，会提供物料的默认供应商、采购计量单位、采购单位的换算关系，采购提前期、采购最小起订量等。

销售部门通常会提供销售计量单位，销售计量单位的换算关系等。

而财务部门会确定物料的过账逻辑，在库存中的计量单位。计划部门会提供生产提前期、计划方式，是采购，还是自己生产，以及订购周期等计划参数。

所以我一般建议可以根据这些信息的提供方式，设计一个物料维护的流转卡，由各部门各自提供相应的信息，并承担相应的责任。签核后，交给系统管理员，或者数据管理员统一维护到SAP系统中。

当然这个流转的流程，可以在系统外进行纸质的流转，也可以在OA中进行流转，在许可证允许的情况下，甚至还可以直接在SAP中进行流转，最后才能统一根据流转结果，维护或者更新到系统中正式生效。这

样以后在发生任何问题的时候，都可以追溯到唯一的责任人。

对于BOM的维护，通常大家会认为这是研发部门的工作职责，会交给研发部门的工程师，或者研发部门的文员去维护。

但我认为在工作量许可的情况下，尽量不要由研发部门自行去维护。BOM更改的频次通常会比较多，比如工艺变更、版本升级等。

每一次的变更，都应当由研发部门发起工艺变更申请，又叫做ECN，由相关部门评审通过后，再在指定的时间，进行BOM的变更。

这样做的理由有这么两点：

一是研发部门对于BOM的变更，往往会仅考虑设计层面的需要，甚至在有些研发和工艺分开的企业中，甚至都不会过多考虑制造工艺的需求和难点。

而对于变更的必要性，会让在途的多少物料或者半成品变成呆滞料，造成多大的产线切换的损失等，研发部门都不会去考虑，也无法去考虑的。所以必须要有一个各部门签核的流程，来保证每一次的设计变更都是经过各部门专业、充分考虑的结果。

在某些情况下，可能各部门的意见，会反过去促使研发部门重新思考变更的必要性，例如当变更可能会造成巨大的已入库材料的损失时，有可能研发部门就可以寻找其它的替代方案，推迟，甚至取消变更的计划。

二是在ECN生效的时间点，虽然已经在途的生产不会受到影响，但是生效后的生产任务，就会按照变更后的BOM来执行。

所以在什么时候变更，对在途的订单、对MRP的计算结果都会有直接影响，所以研发部门应该在ECN上指明变更和切换的方式、时间点，再由相关部门统一维护和更改，通知和协调各部门在变更的时间点进行统一切换。

所以对于BOM的维护，我认为不应当由研发部门自行来维护，最好也是由研发部门发起，第三方部门来维护，以减少BOM更改的随意性，给其它部门造成不必要的影响。

对于供应商的数据维护，我们下一讲会聊一聊供应商的评审流程，供应商的评审实际上供应商最后在系统中的维护流程是关联的，因此我们这个话题会留到下一讲再继续展开。

对于客户主数据的维护，也不应当由销售部门自行维护，而应当通过专门的客户维护评审流程。

在某些行业中，客户的信用会直接关系公司的商业风险。当我们引入一个新的客户，或者更改某个客户的等级、付款条款时，都需要对客户作严谨的评估。

例如为该客户分配多少信用额度，该客户是否可以有账期，或者必需要用预收款来杜绝商业风险。

又例如对某些经销商，需要评估是否交纳保证金，允许铺多少货等。所有的这些信息，最好根据企业的需要，都由销售员提供或者填写后，交由各专业的部门去评估，最后再统一在系统中进行维护。

以上举的物料、BOM、客户和供应商的例子，大家都可以看到，我们在流程上的设计思路，都是要保证主数据信息维护的准确和严谨性。

并不是简单地指定一个人往系统中录入就可以了。大家在设计的时候，也应当遵循这种思路，去思考一个流程的本质，而不要只顾方便、操作容易。