马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。如果您注册时有任何问题请联系客服QQ: 83569622 。
您需要 登录 才可以下载或查看,没有帐号?注册
x
对于ERP系统所能支持的标准业务场景,如Procure to Pay, Order to Cash, Planning and Manufacturing, Warehouse Management等等,想必大家都已经知道最基本的流程是什么了。在这里,我会就SAP ERP(ECC 6.0)和Baan ERP(LN FP5)中的一些设置和操作做一些有目的地比较和说明。首先,让我们Procure to Pay看起。 下图所示,是我简单归纳的SAP ERP和Baan ERP在该标准流程中所涉及到的操作: 图1: 从上图可以看出,在采购到付款的业务流程中,这两款产品的操作步骤大同小异。即从系统运行MRP开始,催生计划采购订单,到下达采购订单,接着做来料接收,最后处理供应商发票和付款,基本上没有太多明显的差异。但是,熟悉SAP和Baan的朋友能感受的到,这两款产品的设计理念还是不尽相同的。简单点讲,SAP ERP强调包容性,也即支持尽可能多的业务场景以提高灵活的解决方案。对于Baan ERP,由于其侧重于制造业,所以它更关注系统解决方案的对口性,所有设计基于一个大的前提,即假设使用者所在行业为重复制造或离散制造业。 接下来,让我们看看早各自EPR系统中是如何体现上述流程的。 首先,我们就SAP ERP的操作流程及步骤做个简单的介绍。 MRP Run 在运行MRP之前,我们先在MD04中查看一下某个产品的需求列表。类似的,这项功能可以在Baan ERP进程cprmp2101m000中查看。 图2 特别地,由于SAP ERP可以指定对某个MRP 区域或工厂运行MRP,因此,在MRP的运行上便可以做到同公司内不同计划区域或者工厂级别的物料需求计划。若要在Baan中实现这一点,恐怕只能通过使用cluster或者project来特别地分类物料所属来进行计划。当然,由于这两款ERP系统所用到的组织结构是完全不同的,所以基于不同的组织结构所做的业务功能上的设计自然而然也有所区别。例如,在Baan ERP中便没有专门针对Plant的概念。通常情况下,一个Plant就是一个Baan Company。 在查看完需求信息后,我们可以通过MD41重新对该物料进行MRP运算。 图3 从参数控制上我们可以有多个选择。 Processing key,用来控制MRP运算时要如何针对物料进行计划。可选项包括: Net Change Planning, Net Change Planning in the Planning Horizon和Online Regenerative Planning。 Net Change Planning,即净改变计划。也就是仅计划那些由于上次计划运行而物料需求计划已经更改的物料。很显然,该方法对存在复杂BOM结构的生产流程可以有效提高其MRP运行的性能。 Net Change Planning in the Planning Horizon,即计划展望期中的净改变计划。简单点讲,也就是仅对处于计划展望期内的物料进行净改变计划。 Online Regenerative Planning, 即再生计划。在这个计划运行中,系统计划与计划相关的所有物料。 除了运行参数做选择外,我们也可以更详细的控制如何产生采购申请,以及对出货计划进行控制。在SAP ERP中,MRP的结果可以是仅是计划订单或者计划订单和采购申请。通常,计划订单指的是计划生产订单,但在这里,计划订单也可以根据其涉及的物料属性转换为采购申请。而采购申请则可以根据实际配置转化为采购订单或者库存转运单(Stock Transport Order,用于不同公司工厂或者同一公司不同工厂间的物料采购)。 接下来,让我们来运行一下MD41: 图4 MRP的基本逻辑在各个ERP中都是一样的,除了一些细节会因不同的设计理念和各自所拥有的最佳实践库的不同而有所不同。因此,这里我们跳过这里的MRP逻辑,而重点阐述一下从MRP结果的产生到正式订单的转换。 接着我们可以在MD04中对产生的计划订单进行处理。 首先我们来看看针对主产品产生的计划生产订单。 图5 双击该行: 图6 点击第一个按钮可将该计划订单转换为生产订单。 在进行计划订单转化的时候SAP ERP会根据后台配置对物料可用性进行检查,如果检查通过,则允许生产订单生成: 图7 图8 点击保存后并对该订单进行下达操作即可开始后续流程。在这里我就不对工单的操作做赘述了,稍后我会在其他的篇章里面介绍SAP ERP的工单操作和Baan ERP的工单操作之异同。 现在,我们可以对其中某个采购件所生成的计划订单做处理。 图9 *看到左边的警告灯了吗,确实是很不错的提示* 图10 图11 可以看到,我们所生成的MRP订单为计划订单,之后的操作是将该计划订单转换为采购申请(PR),然后我们就可以根据需要将该申请转换为正式的采购订单了。 当然,我们也可以让MRP直接对该采购件跑出计划申请(前提:对应的物料采购信息齐全,也即有效的Purchase Info Record/Source List存在以及适当的MRP控制参数)。 图12 由于我们没有对该物料维护适当的采购信息,所以在转换成PR之前,我们需要指定供应商及采购组织信息。 图13 图14 接下来,我们便可以对产生的采购申请做转换了。在SAP ERP中我们可以通过两种方式对PR进行转换,一是进行自动转换,二是通过关联PR来直接创建PO。 这里,我们通过ME59来自动将PR转换为PO。 图15 图16 PO创建成功。 接下来,让我对该PO进行处理。 通过ME22N我们可以对生成的PO进行维护和修改,可以看到,SAP ERP中的PO头和PO行是在同一个界面中的,当然,各自对应的数据表则不同。 图17 另外,就我看来,SAP ERP中的PO所能提供以及集成的信息还是非常丰富的。例如价格条件信息,付款条件详细信息,可编辑文本信息以及详细的物料信息。 在确定PO信息无误后,同样我们可以对PO进行打印。 图18 在SAP ERP中,打印的方式和Baan ERP略有不同。在SAP中,基本上我们可以把传输的信息定义为Message,对Message Output的维护在SAP中较为复杂,设计到一系列步骤和配置,如下所示: 图19 Maintain OutputConditions
|
简单来讲,我们可以有条件地来确定打印内容和形式(邮件,传真,文档或是电子数据交换)。可选的条件类型包括公司,物料,订单地址,工厂,采购组织,采购订单类型,供应商等。 在此例中,我们设定的条件为根据订单类型和采购组织的不同来确定打印内容及形式。 我们可以通过ME9F来打印PO。 图20 图21 图22 在供应商根据PO合同进行交付后,我们可以通过MIGO对来料进行接收。 图23 SAP ERP的来料接收程序MIGO实际上可以处理多种货物移动,处采购订单接收外,还包括工单报工,库存移库,销售订单发挥,工单发货等。之所以它能够做多种操作,是因为SAP ERP对物料流转的库存是基于流转类型来确定的。不同的流转类型决定了是收货还是发货,是移库还是退货。需要特别指出的是,除一般基于订单的货物移转处理外,MIGO还支持无订单收发货处理,如凭空向某库位增加库存,而这在Baan ERP中可以简单理解为库存调整操作。 在正式将该收货单进行过账处理前,我们可以通过检查按钮先对该收获单进行检查确认,如果一切无误,我们就可以对其过账了。当然,货仓人员也可以对该收货单进行冻结处理,稍后再对其进行过账。 图24 与Baan ERP将所有物流凭证的处理都与仓库订单挂钩的处理不同,SAP ERP则是以物料凭证为基础来关联其他物流模块的原始凭证或订单,当然也包括了来自仓库管理模块的仓库订单。 因此,在对PO接收完毕并过账后,系统会产生对应的物料凭证来记录过账过程,这与财务凭证相似,并且物料凭证作为SAP系统中物流模块的基础凭证,也是物流模块过渡到财务模块集成的桥梁。 截止到现在,整个Procure to Pay的流程已经走完了大半。余下则是对供应商发票进行处理的过程。在这里顺便提一下,对于SAP ERP中PO的审批则是通过对下达策略的配置来实现的。用户可以根据其组织结构来设定必要的人员及金额对PO进行审批,但需要注意的是,如果PO在审批的过程中被更改,那么PO的审批会从头进行,且审批不是一个可逆的过程,只能逐级向上或从头开始。 下面,我们来看一下如何对发票进行审核。 在SAP的概念里,发票审核属于物流模块,虽然该操作在现实业务中由财务部门进行,但在系统模块蓝图中,该部分属于MM。 现在,让我们用MIRO对供应商发票进行审核并过账。 图25 在发票录入的过程中如果无错误发生我们便可以将该发票过账到财务。 检查有无错误的方式有很多,simulate可以帮助我们检查发票完整性,而信号灯也提示了该发票的状态。 当然,通常财务人员会先通过MIR7对发票进行校验和冻结,在一切无误后再由相关人员在对发票进行过账处理,基本上发票的状态包括Open->on Hold->Parked->Posted。 原则上发票过账后我们便可以进行付款操作了,但在SAP ERP中我们还可以对付款进行冻结,在条件充分的情况下再对付款进行释放。例如此例中,当发票过账后我们可以看到如下信息: 图26 截止到此处,我们可以对计划订单的产生到供应商发票的校验做一个简单的总结。 对于熟悉Baan ERP操作的朋友相信不难看见,在上述几个过程中,有以下主要不同: ERP系统
| | | | | | | Baan ERP
| | | ISI/Item Purchase Business Partner和Source List | | |
| SAP ERP
| | | Source List和Infor Record控制采购订单生成 | | | 属于物流模块,且可提供详细的发票校验信息,支持发票锁定、释放、过账及直接冲销。 |
当然,上述流程中还有很多细节体现了两款ERP产品的不同之处,只可惜笔者能力有限,暂时无法就这些细节一一向大家阐述。不过我们也可以从下图看到两款产品之间的竞争力,并就其中一二做些许浅析。 图27(数据来源:http://www.technologyevaluation.com ) 从上图的对比来看,Baan ERP的劣势主要集中在定价管理和采购报表管理上。除采购订单管理和在线采购需求管理意外(欣喜的是该项成绩较SAP优秀),其他方面则与SAP持平。 事实上,按照性价比来讲,对于中大型复杂程度的制造企业,Baan ERP的功能是绰绰有余的。但问题在于该软件的扩展性不足,还不能应对一个企业未来30年对业务上的拓展。也正是因为如此,不少著名的大型制造企业,诸如波音,奔驰等都转投SAP的怀抱。 当然,我们仍然要对Baan ERP抱有信心,毕竟在信息技术飞速发展的时代很多技术上的区别最终会趋于大同,但从应用的角度来看,应用者的质素往往也决定了其能达到的高度和所能享誉的盛名。这也是为何R/3从推出到现在经历了十几年的创新瓶颈,但却仍被业界使用者所津津乐道,因为SAP相信只有在一个健康的Ecosystem中成长,让彼此互相肯定,才能让自己在整个产业链上占据主导地位。 |