51Testing软件测试论坛

标题: 不使ERP成空中楼阁 标准化编码奠定基石 [打印本页]

作者: 51testing    时间: 2007-10-12 13:58
标题: 不使ERP成空中楼阁 标准化编码奠定基石
在ERP的运行过程中,由唯一的物料编码编制的BOM是整个体系运行的基石。如果该基石不牢固的话,那么整个ERP就是空中楼阁,无本之木,必然导致失败的厄运;就算是勉强上线,也避免不了大规模维护和调整,举步维艰。
    所以从物料编码和BOM的编制规则、编码编制、参数定义、编码启用、编码维护等各个环节都要有一个统一的规划,才可以使物料编码和BOM规范。

    笔者总结工作经验和自己对ERP的理解,总结出以下对物料编码和BOM规范的具体要求:

物料编码和BOM的编制规则

    ①首先,物料编码和BOM的编制要有一个规则,此规则应该符合企业、行业或者国家的产品技术标准或命名规则。

    ②其次,BOM中产品断阶要注意工艺路线和成本核算的结合。一般来说,企业的成本核算级次比工艺路线的层次要低。只要是成本核算,需要进行收发管理的必须纳入BOM管理。对于不核算成本的工序,笔者的建议是以虚拟件管理方式,方便以后工艺调整的时候进行维护。

    ③物料编码和BOM与物料的唯一性是基本原则,否则系统不能接受和处理。

    ④属性编制这个问题涉及的范围比较广,也是企业在物料编码应用时经常困惑的地方之一。经常看到的情况如下:

    a、物料的部分属性在系统中是有表可以设置的,部分属性在系统中没有表可以对应。一般来说,能在系统中有表可以设置的则不要在编码中反映,比如:仓库、库位、供方等,而需要经常汇总和查询的属性建议反映到编码中(即使可以在系统的表中设置),比如物料类别。

    b、另外反映属性和编码的长短是关联的,反映的属性越详细,则编码长度越长,记忆难度越大;这样就会产生矛盾。因此企业需要在属性的详细程度和编码的长度之间找一个平衡点。

    c、属性本身还是有变化的,需要留下拓展的空间。

    ⑤编码的长度要尽可能短,同类的物料编码的长度最好要一致,尽量避免用英文字母。

    ⑥对于虚拟、计划、可选、配置等方式的运用要理解、合理并慎重。
编码要慎重规划

    从上面的叙述可以看出,对于不同的企业有不同的编码规则和方式,在编码之前一定要慎重规划。

    ①物料编码和BOM的编制是一项技术标准化工作,要有专人负责。企业的管理者尤其是技术标准化的人员理解之后再编制,最好不是IT部门编制,除非以后的技术标准化在IT部门维护。

    而且绝对要注意的是:乙方不要越俎代庖,替甲方编制;就算是原来有成功的例子,也只能是推荐,由甲方自行决定是否使用。

    ②参数定义要完整。很多ERP软件对物料的赋值率是有要求的,很多软件要求是100%。物料参数的完整性比完美性更重要,物料参数不完整是导致大多数系统不能自动进行MRP或MPS的障碍。而物料属性、计划属性、成本属性、负责人、库位等不是一个部门能总结的,需要公司全体部门的通力协作。这也是很多公司把IT部门作为实施部门,之后造成项目失败的主要原因。

    我推荐的方式是制定一个物料编码的审批表格(用固定的电子表格或者在系统里直接完善也是可以的),上面规定好每个部门所负责的参数,比如:技术部门负责编码的号码,生产部门负责定义其制造提前期,采购部门填写采购提前期和批量规则,仓库负责规定库位等等,在所有的参数完成以后,再进行到下序:物料编码和BOM的启用。

    ③物料编码和BOM的启用和编制是两个性质不同的工作。编制是技术标准化工作,需要脑力活动;而启用是简单的判断工作,检查参数是否完整就可以了。这个工作可以设置在任何相关的业务部门,但是启用要严格的限制权限,避免不合格的物料编码在系统内运行。因为调整的工作量要大得多。

    ④物料的维护比设置还要重要。我个人认为这是系统运行最关键的地方。对于物料编码和BOM的增删、变更和参数的维护,是一项细致和长期的工作。

    在实际的运行中,我们常常看到:原有的物料编码和BOM规则往往被淡化,物料的提前期保险系数过大,工艺路线变更维护不及时造成产品核算失真或投料错误。解决以上问题的最好方法就是加强权限控制,规范变更的审批流程。

    我相信,通过以上一系列的标准化操作,企业会建立起一套行之有效的编码系统,为ERP的运行奠定良好的基础。
作者: BenjaminCheung    时间: 2008-2-29 17:38
BOM 表是制造业的的命根,材料编码是身份识别。
在这个论坛里面没有人关注制造业。
我就是在制造业呆过几年。制造业信息化任务重啊,

悲衰.......




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2