精华内容
下载资源
问答
  • 对供应商的要求的原则
    千次阅读
    2020-07-16 08:58:44

    概述

            向大家介绍过一些软件开发的原则,比如优质代码的十诫Unix传奇(下篇)中所以说的UNIX的设计原则。相信大家从中能够从中学了解到一些设计原理方面的知识,正如我在《再谈“我是怎么招聘程序”》中所说的,一个好的程序员通常由其操作技能、知识水平,经验层力和能力四个方面组成。在这里想和大家说说设计中的一些原则,我认为这些东西属于长期经验总结出来的知识。这些原则,每一个程序员都应该了解。但是请不要教条主义,在使用的时候还是要多多考虑实际情况。其实,下面这些原则,不单单只是软件开发,可以推广到其它生产活动中,甚至我们的生活中。

    Don’t Repeat Yourself (DRY)

    DRY 是一个最简单的法则,也是最容易被理解的。但它也可能是最难被应用的(因为要做到这样,我们需要在泛型设计上做相当的努力,这并不是一件容易的事)。它意味着,当我们在两个或多个地方的时候发现一些相似的代码的时候,我们需要把他们的共性抽象出来形一个唯一的新方法,并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。

    参考:http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

    Keep It Simple, Stupid (KISS)

    KISS原则在设计上可能最被推崇的,在家装设计,界面设计 ,操作设计上,复杂的东西越来越被众人所BS了,而简单的东西越来越被人所认可,比如这些UI的设计和我们中国网页(尤其是新浪的网页)者是负面的例子。“宜家”(IKEA)简约、效率的家居设计、生产思路;“微软”(Microsoft)“所见即所得”的理念;“谷歌”(Google)简约、直接的商业风格,无一例外的遵循了“kiss”原则,也正是“kiss”原则,成就了这些看似神奇的商业经典。而苹果公司的iPhone/iPad将这个原则实践到了极至。

     

    把一个事情搞复杂是一件简单的事,但要把一个复杂的事变简单,这是一件复杂的事。

    参考:http://en.wikipedia.org/wiki/KISS_principle

    Program to an interface, not an implementation

    这是设计模式中最根本的哲学,注重接口,而不是实现,依赖接口,而不是实现。接口是抽象是稳定的,实现则是多种多样的。以后面我们会面向对象的SOLID原则中会提到我们的依赖倒置原则,就是这个原则的的另一种样子。还有一条原则叫 Composition over inheritance(喜欢组合而不是继承),这两条是那23个经典设计模式中的设计原则。

    Command-Query Separation (CQS)  – 命令-查询分离原则

    • 查询:当一个方法返回一个值来回应一个问题的时候,它就具有查询的性质;
    • 命令:当一个方法要改变对象的状态的时候,它就具有命令的性质;

    通常,一个方法可能是纯的Command模式或者是纯的Query模式,或者是两者的混合体。在设计接口时,如果可能,应该尽量使接口单一化,保证方法的行为严格的是命令或者是查询,这样查询方法不会改变对象的状态,没有副作用,而会改变对象的状态的方法不可能有返回值。也就是说:如果我们要问一个问题,那么就不应该影响到它的答案。实际应用,要视具体情况而定,语义的清晰性和使用的简单性之间需要权衡。将Command和Query功能合并入一个方法,方便了客户的使用,但是,降低了清晰性,而且,可能不便于基于断言的程序设计并且需要一个变量来保存查询结果。

    在系统设计中,很多系统也是以这样原则设计的,查询的功能和命令功能的系统分离,这样有则于系统性能,也有利于系统的安全性。

    参考:http://en.wikipedia.org/wiki/Command-query_separation

    You Ain’t Gonna Need It (YAGNI)

    这个原则简而言之为——只考虑和设计必须的功能,避免过度设计。只实现目前需要的功能,在以后您需要更多功能时,可以再进行添加。

    • 如无必要,勿增复杂性。
    • 软件开发先是一场沟通博弈。

    以前本站有一篇关于过度重构的文章,这个示例就是这个原则的反例。而,WebSphere的设计者就表示过他过度设计了这个产品。我们的程序员或是架构师在设计系统的时候,会考虑很多扩展性的东西,导致在架构与设计方面使用了大量折衷,最后导致项目失败。这是个令人感到讽刺的教训,因为本来希望尽可能延长项目的生命周期,结果反而缩短了生命周期。

    参考:http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It

    Law of Demeter – 迪米特法则

    迪米特法则(Law of Demeter),又称“最少知识原则”(Principle of Least Knowledge),其来源于1987年荷兰大学的一个叫做Demeter的项目。Craig Larman把Law of Demeter又称作“不要和陌生人说话”。在《程序员修炼之道》中讲LoD的那一章叫作“解耦合与迪米特法则”。关于迪米特法则有一些很形象的比喻:

    • 如果你想让你的狗跑的话,你会对狗狗说还是对四条狗腿说?
    • 如果你去店里买东西,你会把钱交给店员,还是会把钱包交给店员让他自己拿?

    和狗的四肢说话?让店员自己从钱包里拿钱?这听起来有点荒唐,不过在我们的代码里这几乎是见怪不怪的事情了。

    对于LoD,正式的表述如下:

    对于对象 ‘O’ 中一个方法’M’,M应该只能够访问以下对象中的方法:

    1. 对象O;
    2. 与O直接相关的Component Object;
    3. 由方法M创建或者实例化的对象;
    4. 作为方法M的参数的对象。

    在《Clean Code》一书中,有一段Apache framework中的一段违反了LoD的代码:

    final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

    这么长的一串对其它对象的细节,以及细节的细节,细节的细节的细节……的调用,增加了耦合,使得代码结构复杂、僵化,难以扩展和维护。

    在《重构》一书中的代码的环味道中有一种叫做“Feature Envy”(依恋情结),形象的描述了一种违反了LoC的情况。Feature Envy就是说一个对象对其它对象的内容更有兴趣,也就是说老是羡慕别的对象的成员、结构或者功能,大老远的调用人家的东西。这样的结构显然是不合理的。我们的程序应该写得比较“害羞”。不能像前面例子中的那个不把自己当外人的店员一样,拿过客人的钱包自己把钱拿出来。“害羞”的程序只和自己最近的朋友交谈。这种情况下应该调整程序的结构,让那个对象自己拥有它羡慕的feature,或者使用合理的设计模式(例如Facade和Mediator)。

    参考:http://en.wikipedia.org/wiki/Principle_of_Least_Knowledge

    面向对象的S.O.L.I.D 原则

    一般来说这是面向对象的五大设计原则,但是,我觉得这些原则可适用于所有的软件开发。

    Single Responsibility Principle (SRP) – 职责单一原则

    关于单一职责原则,其核心的思想是:一个类,只做一件事,并把这件事做好,其只有一个引起它变化的原因。单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申,将职责定义为引起变化的原因,以提高内聚性来减少引起变化的原因。职责过多,可能引起它变化的原因就越多,这将导致职责依赖,相互之间就产生影响,从而极大的损伤其内聚性和耦合度。单一职责,通常意味着单一的功能,因此不要为一个模块实现过多的功能点,以保证实体只有一个引起它变化的原因。

    • Unix/Linux是这一原则的完美体现者。各个程序都独立负责一个单一的事。
    • Windows是这一原则的反面示例。几乎所有的程序都交织耦合在一起。

    Open/Closed Principle (OCP) – 开闭原则

    关于开发封闭原则,其核心的思想是:模块是可扩展的,而不可修改的。也就是说,对扩展是开放的,而对修改是封闭的。

    • 对扩展开放,意味着有新的需求或变化时,可以对现有代码进行扩展,以适应新的情况。
    • 对修改封闭,意味着类一旦设计完成,就可以独立完成其工作,而不要对类进行任何修改。

    对于面向对象来说,需要你依赖抽象,而不是实现,23个经典设计模式中的“策略模式”就是这个实现。对于非面向对象编程,一些API需要你传入一个你可以扩展的函数,比如我们的C 语言的qsort()允许你提供一个“比较器”,STL中的容器类的内存分配,ACE中的多线程的各种锁。对于软件方面,浏览器的各种插件属于这个原则的实践。

    Liskov substitution principle (LSP) – 里氏代换原则

    软件工程大师Robert C. Martin把里氏代换原则最终简化为一句话:“Subtypes must be substitutable for their base types”。也就是,子类必须能够替换成它们的基类。即:子类应该可以替换任何基类能够出现的地方,并且经过替换以后,代码还能正常工作。另外,不应该在代码中出现if/else之类对子类类型进行判断的条件。里氏替换原则LSP是使代码符合开闭原则的一个重要保证。正是由于子类型的可替换性才使得父类型的模块在无需修改的情况下就可以扩展。

    这么说来,似乎有点教条化,我非常建议大家看看这个原则个两个最经典的案例——“正方形不是长方形”和“鸵鸟不是鸟”。通过这两个案例,你会明白《墨子 小取》中说的 ——“娣,美人也,爱娣,非爱美人也….盗,人也;恶盗,非恶人也。”——妹妹虽然是美人,但喜欢妹妹并不代表喜欢美人。盗贼是人,但讨厌盗贼也并不代表就讨厌人类。这个原则让你考虑的不是语义上对象的间的关系,而是实际需求的环境。

    在很多情况下,在设计初期我们类之间的关系不是很明确,LSP则给了我们一个判断和设计类之间关系的基准:需不需要继承,以及怎样设计继承关系。

    Interface Segregation Principle (ISP) – 接口隔离原则

    接口隔离原则意思是把功能实现在接口中,而不是类中,使用多个专门的接口比使用单一的总接口要好。

    举个例子,我们对电脑有不同的使用方式,比如:写作,通讯,看电影,打游戏,上网,编程,计算,数据等,如果我们把这些功能都声明在电脑的抽类里面,那么,我们的上网本,PC机,服务器,笔记本的实现类都要实现所有的这些接口,这就显得太复杂了。所以,我们可以把其这些功能接口隔离开来,比如:工作学习接口,编程开发接口,上网娱乐接口,计算和数据服务接口,这样,我们的不同功能的电脑就可以有所选择地继承这些接口。

    这个原则可以提升我们“搭积木式”的软件开发。对于设计来说,Java中的各种Event Listener和Adapter,对于软件开发来说,不同的用户权限有不同的功能,不同的版本有不同的功能,都是这个原则的应用。

    Dependency Inversion Principle (DIP) – 依赖倒置原则

    高层模块不应该依赖于低层模块的实现,而是依赖于高层抽象。

    举个例子,墙面的开关不应该依赖于电灯的开关实现,而是应该依赖于一个抽象的开关的标准接口,这样,当我们扩展程序的时候,我们的开关同样可以控制其它不同的灯,甚至不同的电器。也就是说,电灯和其它电器继承并实现我们的标准开关接口,而我们的开关产商就可不需要关于其要控制什么样的设备,只需要关心那个标准的开关标准。这就是依赖倒置原则。

    这就好像浏览器并不依赖于后面的web服务器,其只依赖于HTTP协议。这个原则实在是太重要了,社会的分工化,标准化都是这个设计原则的体现。

    参考:http://en.wikipedia.org/wiki/Solid_(object-oriented_design)

    Common Closure Principle(CCP)– 共同封闭原则

    一个包中所有的类应该对同一种类型的变化关闭。一个变化影响一个包,便影响了包中所有的类。一个更简短的说法是:一起修改的类,应该组合在一起(同一个包里)。如果必须修改应用程序里的代码,我们希望所有的修改都发生在一个包里(修改关闭),而不是遍布在很多包里。CCP原则就是把因为某个同样的原因而需要修改的所有类组合进一个包里。如果2个类从物理上或者从概念上联系得非常紧密,它们通常一起发生改变,那么它们应该属于同一个包。

    CCP延伸了开闭原则(OCP)的“关闭”概念,当因为某个原因需要修改时,把需要修改的范围限制在一个最小范围内的包里。

    参考:http://c2.com/cgi/wiki?CommonClosurePrinciple

    Common Reuse Principle (CRP) – 共同重用原则

    包的所有类被一起重用。如果你重用了其中的一个类,就重用全部。换个说法是,没有被一起重用的类不应该被组合在一起。CRP原则帮助我们决定哪些类应该被放到同一个包里。依赖一个包就是依赖这个包所包含的一切。当一个包发生了改变,并发布新的版本,使用这个包的所有用户都必须在新的包环境下验证他们的工作,即使被他们使用的部分没有发生任何改变。因为如果包中包含有未被使用的类,即使用户不关心该类是否改变,但用户还是不得不升级该包并对原来的功能加以重新测试。

    CCP则让系统的维护者受益。CCP让包尽可能大(CCP原则加入功能相关的类),CRP则让包尽可能小(CRP原则剔除不使用的类)。它们的出发点不一样,但不相互冲突。

    参考:http://c2.com/cgi/wiki?CommonReusePrinciple

    Hollywood Principle – 好莱坞原则

    好莱坞原则就是一句话——“don’t call us, we’ll call you.”。意思是,好莱坞的经纪人们不希望你去联系他们,而是他们会在需要的时候来联系你。也就是说,所有的组件都是被动的,所有的组件初始化和调用都由容器负责。组件处在一个容器当中,由容器负责管理。

    简单的来讲,就是由容器控制程序之间的关系,而非传统实现中,由程序代码直接操控。这也就是所谓“控制反转”的概念所在:

    1. 不创建对象,而是描述创建对象的方式。
    2. 在代码中,对象与服务没有直接联系,而是容器负责将这些联系在一起。

    控制权由应用代码中转到了外部容器,控制权的转移,是所谓反转。

    好莱坞原则就是IoC(Inversion of Control)或DI(Dependency Injection )的基础原则。这个原则很像依赖倒置原则,依赖接口,而不是实例,但是这个原则要解决的是怎么把这个实例传入调用类中?你可能把其声明成成员,你可以通过构造函数,你可以通过函数参数。但是 IoC可以让你通过配置文件,一个由Service Container 读取的配置文件来产生实际配置的类。但是程序也有可能变得不易读了,程序的性能也有可能还会下降。

    参考:

    High Cohesion & Low/Loose coupling & – 高内聚, 低耦合

    这个原则是UNIX操作系统设计的经典原则,把模块间的耦合降到最低,而努力让一个模块做到精益求精。

    • 内聚:一个模块内各个元素彼此结合的紧密程度
    • 耦合:一个软件结构内不同模块之间互连程度的度量

    内聚意味着重用和独立,耦合意味着多米诺效应牵一发动全身。

    参考:

    Convention over Configuration(CoC)– 惯例优于配置原则

    简单点说,就是将一些公认的配置方式和信息作为内部缺省的规则来使用。例如,Hibernate的映射文件,如果约定字段名和类属性一致的话,基本上就可以不要这个配置文件了。你的应用只需要指定不convention的信息即可,从而减少了大量convention而又不得不花时间和精力啰里啰嗦的东东。配置文件很多时候相当的影响开发效率。

    Rails 中很少有配置文件(但不是没有,数据库连接就是一个配置文件),Rails 的fans号称期开发效率是 java 开发的 10 倍,估计就是这个原因。Maven也使用了CoC原则,当你执行mvn -compile命令的时候,不需要指源文件放在什么地方,而编译以后的class文件放置在什么地方也没有指定,这就是CoC原则。

    参考:http://en.wikipedia.org/wiki/Convention_over_Configuration

    Separation of Concerns (SoC) – 关注点分离

    SoC 是计算机科学中最重要的努力目标之一。这个原则,就是在软件开发中,通过各种手段,将问题的各个关注点分开。如果一个问题能分解为独立且较小的问题,就是相对较易解决的。问题太过于复杂,要解决问题需要关注的点太多,而程序员的能力是有限的,不能同时关注于问题的各个方面。正如程序员的记忆力相对于计算机知识来说那么有限一样,程序员解决问题的能力相对于要解决的问题的复杂性也是一样的非常有限。在我们分析问题的时候,如果我们把所有的东西混在一起讨论,那么就只会有一个结果——乱。

    我记得在上一家公司有一个项目,讨论就讨论了1年多,项目本来不复杂,但是没有使用SoC,全部的东西混为一谈,再加上一堆程序员注入了各种不同的观点和想法,整个项目一下子就失控了。最后,本来一个1年的项目做了3年。

    实现关注点分离的方法主要有两种,一种是标准化,另一种是抽象与包装。标准化就是制定一套标准,让使用者都遵守它,将人们的行为统一起来,这样使用标准的人就不用担心别人会有很多种不同的实现,使自己的程序不能和别人的配合。Java EE就是一个标准的大集合。每个开发者只需要关注于标准本身和他所在做的事情就行了。就像是开发镙丝钉的人只专注于开发镙丝钉就行了,而不用关注镙帽是怎么生产的,反正镙帽和镙丝钉按标来就一定能合得上。不断地把程序的某些部分抽像差包装起来,也是实现关注点分离的好方法。一旦一个函数被抽像出来并实现了,那么使用函数的人就不用关心这个函数是如何实现的,同样的,一旦一个类被抽像并实现了,类的使用者也不用再关注于这个类的内部是如何实现的。诸如组件,分层,面向服务,等等这些概念都是在不同的层次上做抽像和包装,以使得使用者不用关心它的内部实现细节。

    说白了还是“高内聚,低耦合”。

    参考:http://sulong.me/archives/99

    Design by Contract (DbC) – 契约式设计

    DbC的核心思想是对软件系统中的元素之间相互合作以及“责任”与“义务”的比喻。这种比喻从商业活动中“客户”与“供应商”达成“契约”而得来。例如:

    • 供应商必须提供某种产品(责任),并且他有权期望客户已经付款(权利)。
    • 客户必须付款(责任),并且有权得到产品(权利)。
    • 契约双方必须履行那些对所有契约都有效的责任,如法律和规定等。

    同样的,如果在程序设计中一个模块提供了某种功能,那么它要:

    • 期望所有调用它的客户模块都保证一定的进入条件:这就是模块的先验条件(客户的义务和供应商的权利,这样它就不用去处理不满足先验条件的情况)。
    • 保证退出时给出特定的属性:这就是模块的后验条件——(供应商的义务,显然也是客户的权利)。
    • 在进入时假定,并在退出时保持一些特定的属性:不变式。

    契约就是这些权利和义务的正式形式。我们可以用“三个问题”来总结DbC,并且作为设计者要经常问:

    • 它期望的是什么?
    • 它要保证的是什么?
    • 它要保持的是什么?

    根据Bertrand Meyer氏提出的DBC概念的描述,对于类的一个方法,都有一个前提条件以及一个后续条件,前提条件说明方法接受什么样的参数数据等,只有前提条件得到满足时,这个方法才能被调用;同时后续条件用来说明这个方法完成时的状态,如果一个方法的执行会导致这个方法的后续条件不成立,那么这个方法也不应该正常返回。

    现在把前提条件以及后续条件应用到继承子类中,子类方法应该满足:

    1. 前提条件不强于基类.
    2. 后续条件不弱于基类.

    换句话说,通过基类的接口调用一个对象时,用户只知道基类前提条件以及后续条件。因此继承类不得要求用户提供比基类方法要求的更强的前提条件,亦即,继承类方法必须接受任何基类方法能接受的任何条件(参数)。同样,继承类必须顺从基类的所有后续条件,亦即,继承类方法的行为和输出不得违反由基类建立起来的任何约束,不能让用户对继承类方法的输出感到困惑。

    这样,我们就有了基于契约的LSP,基于契约的LSP是LSP的一种强化。

    参考:http://en.wikipedia.org/wiki/Design_by_contract

    Acyclic Dependencies Principle (ADP) – 无环依赖原则

    包之间的依赖结构必须是一个直接的无环图形,也就是说,在依赖结构中不允许出现环(循环依赖)。如果包的依赖形成了环状结构,怎么样打破这种循环依赖呢?有2种方法可以打破这种循环依赖关系:第一种方法是创建新的包,如果A、B、C形成环路依赖,那么把这些共同类抽出来放在一个新的包D里。这样就把C依赖A变成了C依赖D以及A依赖D,从而打破了循环依赖关系。第二种方法是使用DIP(依赖倒置原则)和ISP(接口分隔原则)设计原则。

    无环依赖原则(ADP)为我们解决包之间的关系耦合问题。在设计模块时,不能有循环依赖。

    参考:http://c2.com/cgi/wiki?AcyclicDependenciesPrinciple

    ————————————————————————————

    上面这些原则可能有些学院派,也可能太为理论,我在这里说的也比较模糊和简单,这里只是给大家一个概貌,如果想要了解更多的东西,大家可以多google一下。

    不过这些原则看上去都不难,但是要用好却并不那么容易。要能把这些原则用得好用得精,而不教条,我的经验如下:(我以为这是一个理论到应用的过程)

    1. 你可以先粗浅或是表面地知道这些原则。
    2. 但不要急着马上就使用。
    3. 在工作学习中观察和总结别人或自己的设计。
    4. 再回过头来了回顾一下这些原则,相信你会有一些自己的心得。
    5. 有适度地去实践一下。
    6. Goto第 3步。
    更多相关内容
  • 其实无论是我们挑选供应商,还是客户挑选合作伙伴,都有一套对供应商的评级体系的,而所有的评价体系基本都要符合一个基本的原则,就是5R原则,5R原则是采购商也就是我们客户的入门知识,就像我们做外贸也有自己刚...

    其实无论是我们挑选供应商,还是客户挑选合作伙伴,都有一套对供应商的评级体系的,而所有的评价体系基本都要符合一个基本的原则,就是5R原则,5R原则是采购商也就是我们客户的入门知识,就像我们做外贸也有自己刚入门的必须掌握的知识是一个道理,那么5R都包括什么?

    适时(Right Time)、实质(Right Quality)、适量(Right Quantity)、适价(Right Price)、适地(Right Place)的从供应商手中挑选产品和材料

    当你了解之后,你才能潜意识的站在客户的角度去思考问题,就能把客户越跟越近,最终拿下订单,维护老客户关系也是同理,想客户之所想,急客户之所急。

    1.适时(Right time)

    适时即合适的时间;根据客户的需求,供应商能够在双方协商的时间内为客户提供所需的产品。

    也许有人会问到:如果提前完成生产,是否可以获得客户的好感呢?显然答案是"NO",客户有自己的计划,如果你提前太久交货,产品会有保质期的问题、产品货物仓库堆积、季节性的产品销售时间等。所以时间的把控非常重要。

    而交货期延迟则是合作中的大忌,会给客户造成一定的损失或不便,所以,一定要在合适的时间交货,客户才会慎重的选择和你合作。

    2.适质(Right quality)

    适质即合适的质量。首先要根据客户的情况去决定质量,不同的国家有不同的采购标准,所以不同的客户群体所对应的质量也有所区别。

    像欧美国家,注重产品品质,因此价格会偏高;而对于一些非洲等国家,如果你以同样高标准的质量去要求,那所对应的成本及价格也是偏高,以当地的一个消费水平极难匹配。

    但于此同时,我们不能为了更低的价格或更多的利润而去做假货、质量不合格的产品,要根据客户群体及客户需求去决定。

    所以适质并不是指最好的质量,而是最适合对应客户群体的质量。

    3.适量(Right quantity)

    适量即合适的数量。采购者订购产品是有合理的计划,一次性采购或分批采购。当该产品属于快销品,需求量较大,采购者会尽可能的订购大量产品以获得价格优势。若担心产品过量库存积压风险,则会分批采购。所以我们要根据客户实际情况,以及产品自身条件,为客户分析判断,并给出客户好的建议。为客户所处的情况思考,而不是一昧的让客户一次性采购,更容易获得客户的好感。

    4.适价(Right price)

    适价即合适的价格。作为采购商,价格是考虑的重要因素之一,商人注重利润。价格在采购过程中也是最为敏感、最为关键的因素。所以在价格谈判的环节花费的时间和精力往往更长。但我们始终应该明白,客户需要的不是最低价,而是匹配当前质量及数量的情况下的最合适的价格。因为我们就要在价格谈判方面多思考一些谈判技巧。

    在各方面都合适的情况下,客户会选择不同的供应商进行比价,俗话说“货比三家”,而咱们的外贸客户也不例外。

    提升价格谈判的一些技巧。参考学习:

    1.报价后客户说价格高怎么办 |价格谈判

    2.为什么国外买家总是说你的价格太高?

    经历报价-比价-砍价-定价,最终根据市场的供求关系和物品的和市场的关系及价格谈判获得最优的价格。

    这是一个采购商的常见流程,所以我们要根据实际情况,提供合适的价格,灵活变动,以促成合作。

    5.适地(Right place)

    适地即合适的地点。在采购商选择供应商时,地点也是考虑因素之一。俗话说:天时地利与人和。

    地理位置决定运输方式、运输时间及运输成本,所以客户会综合考虑物流成本及运输时间的问题。

    总之:供应商在采购时,参考5R原则,但很多时候难以满足每一方面,因此我们在合作过程中,要了解客户更注重的因素,纵观全局,更精准的为客户提供合适的产品。这也是我们最终达成合作实现双赢的目的。

    更多外贸干货知识,请关注微信公众号:外贸原力

     

    展开全文
  • 采购谈判和供应商选择综述
  • 上海大众供应商质量管理要求 供应商管理 质量原则 质量要求 质量业绩 供应商支持 供应商质量能力提升 背景介绍 提升对象 提升方法及流程 提升的两个模块(培训、审核)
  • - 供应商检验(最终检验、供应商要求的产品认证), - 客户检验(来料检验、审核检验、验收抽样), - 第三方检验(产品认证、遵守国际标准要求的检验和监督、供应商和/或客户要求的质量检验),
  • 基于权变理论的供应商风险管理.pdf基于权变理论的供应商风险管理.pdf基于权变理论的供应商风险管理.pdf基于权变理论的供应商风险管理.pdf基于权变理论的供应商风险管理.pdf基于权变理论的供应商风险管理.pdf基于权变...
  • 基于权变理论的供应商风险管理.docx基于权变理论的供应商风险管理.docx基于权变理论的供应商风险管理.docx基于权变理论的供应商风险管理.docx基于权变理论的供应商风险管理.docx基于权变理论的供应商风险管理.docx...
  • 华为供应商质量管理体系考察报告全).docx华为供应商质量管理体系考察报告全).docx华为供应商质量管理体系考察报告全).docx华为供应商质量管理体系考察报告全).docx华为供应商质量管理体系考察报告全).docx华为供应商...
  • 华为供应商质量管理体系考察报告全).pdf华为供应商质量管理体系考察报告全).pdf华为供应商质量管理体系考察报告全).pdf华为供应商质量管理体系考察报告全).pdf华为供应商质量管理体系考察报告全).pdf华为供应商质量...
  • IT供应商管理办法(适合中大型组织).pdfIT供应商管理办法(适合中大型组织).pdfIT供应商管理办法(适合中大型组织).pdfIT供应商管理办法(适合中大型组织).pdfIT供应商管理办法(适合中大型组织).pdfIT供应商管理办法...
  • 华为供应商质量管理体系考察报告(全) (2).docx华为供应商质量管理体系考察报告(全) (2).docx华为供应商质量管理体系考察报告(全) (2).docx华为供应商质量管理体系考察报告(全) (2).docx华为供应商质量管理体系考察...
  • 供应商管理库存(VMI)实施过程中存在的问题及对策研究.docx供应商管理库存(VMI)实施过程中存在的问题及对策研究.docx供应商管理库存(VMI)实施过程中存在的问题及对策研究.docx供应商管理库存(VMI)实施过程中存在的...
  • 25-供应商管理制度-模板.docx
  • ISO 28598 的这一部分为供应商、客户和/或第三方同一批次进行的连续独立检验提供了属性抽样程序和单一抽样计划。ISO 28598 的这部分地址: - 供应商检验(最终检验、供应商要求的产品认证); - 客户检验(来料...
  • 供应商供应链质量管理试题(SQE完整版含答案).docx
  • 管理信息化征文:软件供应商评估参考体系_ERP_管理信息化_3663
  • 企业信息化建设规划原则.pdf企业信息化建设规划原则.pdf企业信息化建设规划原则.pdf企业信息化建设规划原则.pdf企业信息化建设规划原则.pdf企业信息化建设规划原则.pdf企业信息化建设规划原则.pdf企业信息化建设规划...
  • 企业信息化建设规划原则.docx企业信息化建设规划原则.docx企业信息化建设规划原则.docx企业信息化建设规划原则.docx企业信息化建设规划原则.docx企业信息化建设规划原则.docx企业信息化建设规划原则.docx企业信息化...
  • 推广企业信息化CIO们的“三不”原则-管理资料.pdf推广企业信息化CIO们的“三不”原则-管理资料.pdf推广企业信息化CIO们的“三不”原则-管理资料.pdf推广企业信息化CIO们的“三不”原则-管理资料.pdf推广企业信息化...
  • 供应商能提供符合客户质量要求的产品 (适用, 安全, 耐用) 产品质量和质量成本 防止过左或过右倾向 2. 供应商产品质量保证的三不原则 不制造不良品: 工艺控制 不接受不良品: 层层把关 不使不良品流出: 最终...
  • 医疗器械软件注册技术审查指导原则.doc
  • 医疗器械网络安全注册技术审查指导原则.docx
  • 《10.电工装备供应商数据采集及接口规范-第10部分-6 kV~35 kV电力电缆》编制说明.docx
  • 供应商和客户如何分类 围绕着这个主题,我们主要来聊一聊如何标准化物料,一些特殊的物料,建议遵循什么样的原则去进行标准化。以及物料编码的一些处理建议。 我们先来看看物料的定义,在SAP B1中,物料指的并...

    供应商和客户如何分类 

    围绕着这个主题,我们主要来聊一聊如何标准化物料,对一些特殊的物料,建议遵循什么样的原则去进行标准化。以及对物料编码的一些处理建议。

    我们先来看看物料的定义,在SAP B1中,物料指的并不仅仅是原物料,而是指公司所有需要进行库存管理的物品,主要可能会包括:成品、半成品、零部件、主要原材料、辅助材料、包装物、低值易耗品等等。而物料主数据则是指在SAP系统中维护的物料信息。在SAP B1中,物料也可以是不需要进行库存管理的物料,例如有些项目中可能会有虚拟物料,或者费用类物料等,这些是不需要进行库存管理的,这部分物料我们今天不去讨论,我们今天讨论的主要还是需要做库存管理的这部分物料。

    需要做库存管理的物料中,又可以分为两类,一类是生产过程中会使用或产生的物资,例如构成产品的原物料、包装物。生产过程中使用到的消耗品,例如擦拭机器的酒精,清洗产品的化学药剂等。还有一类是生产过程中会用到的工装、夹具、模具,或者为了保证设备正常运转,常备的一些备品备件等。

    对于产品构成部分的原物料、内包装这类物资,我们通常建议通过MRP来计算其真实的需求量。对于消耗品,我们一般建议通过保有一定的安全库存来计算需求。对于工装、夹具、模具等,可以通过申购流程来处理,这一类物料的管理逻辑和管理目标,我们在后面的课程中,会再详细地和大家讲一讲。

     

    物料的标准化

    下面我们来聊一聊物料的标准化。什么是物料的标准化?通俗一点说,就是什么样的物料,我们视为同一种物料,给同一个编码。而什么情况下,我们又把物料视为不同的物料,给不同的编码,分别做库存管理。

    对于物料的标准化,一般我建议按如下原则来处理,当然这只是我个人的一些通用性的建议,具体的处理方案,还是要在不同的项目的,根据实际情况来取舍和判断的。

    如果物料的属性、名称完全相同,并且在技术上完全可以互相通用,仅仅是供应商不同的,建议视同为同一个物料,用不同批次来进行供应商的追溯,不要分配不同的物料号。

    这里需要注意的是,供应商和品牌是两个概念。供应商可以是原厂的供应商,也可以是代理商。比如你要买一个iphone手机,你可以从苹果的专卖店买,也可以从京东商城买。你买到的手机品牌都是苹果,但是供应商是可以不一样的,一个是苹果,一个是京东。

    不同供应商的物料,一般建议做为同一个物料。

    但是不同品牌的物料,通常情况下会被视同为两个不同的物料。因为如果遇到需要做品牌管理的物料,那么一般来说不同品牌的东西是不可以混用的。

    例如同一个传感器,功能可能都是一样的,但是品牌不同,一个是欧姆龙的,一个是西门子的,那么它们对最终产品的质量、等级可能都会产生不同的影响。而最终客户,往往也会指定必需要用哪个品牌的传感器来生产。

    在仓库库存管理中,不同品牌的东西外观、标识也会不同,仓库管理通常也是分开存放管理的,所以不同品牌的物料,一般建议视为不同的物料。不过并不是每种材料都需要管理品牌,例如钢材、包装物等等,这类物资不同品牌的性状往往差别不大,对品牌不是那么在意的,就不需要分品牌管理。

    对于一些有等级概念的物料,我们需要根据项目的实际情况来区别对待。

    例如,如果是采购进来的原物料,买的时候不清楚它的真实等级,对供应商付的采购价格都是相同的,买进来以后,通过检验,或者挑选,区分出不同等级,并指定可以用在不同的产品上的,这类物料可以视为一个物料,分配一个编码进行管理。

    但是必需要做批次管理,在批次属性中标明它的等级或者适用的产品范围。在仓库中做管理时,不同批次需要分开管理,不可以混料。比如一些可能会具有不同色差的油漆,买的时候采购价格是相同的,也指明了要购买的颜色,但是供应商的生产批次不同,每一批到货都会有不同的色差,最终导致每一批只能用在特定的产品或者特定批次的产品上面。

    又比如一些矿物质原料,购买的时候不分等级,买进来以后需要通过实验室检验,或者挑选,再分出不同等级的矿,决定可以用在不同质量要求的产品上,这些都是属于这种情况。

    而对于一些不同等级的,自己生产的产品,往往有可能需要分不同的物料号,视为不同的物料来管理。

    因为这类产品对外的售价可能是不同的,成本相差有可能也相当大,客户下订单也会明确地要求购买哪种等级的产品。

    但是如果产品在生产的时候,无法指定等级,必需要等生产完成以后,通过检验才能确定等级的,这类产品成本其实是一样的,也可以视为同一种物料,然后用不同的批次来进行库存和发货管理。

    最典型的,例如一些化工企业,他们生产的产品,有时候必需要等生产完成以后,能过检验确定浓度等指标,才能给产品定级。这种无法在生产完成前就确定产品等级甚至种类的,视为同一物料的不同等级来管理,可能会更适宜。

    有一些贸易型的公司来说,可能会存在一种特殊的情况。商品本身是完全一样的,我们向供应商购买,并要求供应商直接送货到我们的客户处。

    我们的客户可能会分布在不同的地方,每一次要把商品从供应商的工厂,运输到不同的目的地,所需要的运输费用都是不一样的。

    有一些供应商在每次报价的时候,就会把货物本身的价格,和运输费用分开报价,这种情况下我们可以把商品视同为同一个物料,因为贸易企业的运费是不计入成本的,货物本身的价格不会随着运往不同的地方而变化,我们可以正确地分析销售毛利。

    但是如果供应商直接把运输费用计入商品的售价中,无法分开商品本身的价格和运输费用。例如供应商直接报一个CIF的价格,这就会导致运往不同目的地的商品,供应商售价不同,成本相差较大,如果用同一个物料号来管理,不同客户的商品成本会被加权平均掉,销售毛利就会完全失真。这种情况下,建议可以做为不同的物料,分配不同的物料号来进行管理,以便正确分析每一单的销售毛利。

    如果存在客供料,那么不同的客户提供的原料,哪怕外形、技术参数与其它客供料或者公司自有材料完全相同,也必需分配不同的物料号,因为他们的成本管理需要完全分开。对于客供料,我们后面还会再讲到。

    以上这些,就是对怎么标准化物料的一些通用原则和方法,大家可以用作参考。不过我的观点一向是,任何的方案都没有绝对的好与坏,只有适合与不适合。用对了地方的方案就是好的,如果不考虑具体的项目环境,生搬硬套一个以为很优秀的方案,那么在别的地方再怎么优秀的方案,也会变成一个坏的方案。所以上面我列举的这些,大家最好多去想想我所说的理由,而不要去太在意我的结论。

     

    物料编码

    下面我们来聊一聊物料编码。

    物料编码又叫物料代码。在SAP中物料代码是用来唯一标识一个物料的编号。物料建立后,一旦发生了任何业务,物料代码再也不能更改。在整个公司所有会用到物料的部门,从采购,到仓库,再到生产、销售,物料代码必需要统一,唯一的一个代码,就只能指代唯一的一种东西。所以物料代码大家可以理解为一个物料的身份标识。

    在很多企业里面,往往会把物料编码设计得异常复杂。会把大类、中类、小类等等,或者型号+规格+颜色的搭配等,几乎所有的物料信息和属性,都恨不得全编到物料代码中。第几位,用什么字母或者属性,代表什么信息。一个完整的物料代码,往往会有几十个字母和数字、符号组成。而为了描述这些编码规则,所写下来的编码方法,或者叫编码规则制定的手册,甚至会厚达几十页。

    这种编码方法看起来很正规,代码也看起来有模有样,好象挺规范,挺严肃的样子。但其实这种编码方式是从古老的手工做账时代传下来的一种过时的做法。在ERP普及的今天,这种方式存在很大的缺陷。主要有以下理由:

    第一:在手工做账时代,员工需要很直观地通过代码了解物料或产品的大概属性。

    这样在日常工作的时候,可以通过编码进行快速地识别。但是在电脑普及的年代,只要在电脑中输入任意物料代码,该物料的所有属性即可一览无遗,不管这些属性是否包含在编码中,电脑都可以快速地按照你的意愿调出你想要的信息和属性。所以代码的作用仅仅是一个标识,本身可以不包含任何信息。

    第二:过去通过代码去了解物料的做法,本身就有很大风险:

    员工有可能对代码规则存在记忆错误;也有可能规则并不能涵盖所有的属性;或者规则本身太复杂,除非查询规则手册,否则从代码本身还是会解读出错误的属性(这一点在很多大公司特别明显,制定出很详细的编码规则,甚至能编写出一本厚厚的编码规则手册。但是除非员工人手一本,随时查阅,否则那些异常复杂的代码对普通员工来说毫无意义)。

    现在随着管理手段的提高,电脑的普及,我们有更科学,更快捷的方法来获取物料的属性,所以代码本身的作用已经退化为仅仅是一个标识。

    第三:代码的规则,无论一开始想得多么全面,设计得多么复杂,总有不能向后兼容的情况。

    从业务伙伴组的这几个作用,我们就可以得出一个原则:

    比如,有一家公司,一开始把物料代码的规则,可能定义为型号+规格+颜色来做为一个物料的编码。

    可是过不了多久,技术部门开发了一种新的产品,型号,规格,颜色都和现在的完全一样,然而材质不同,这就会构成对现有编码规则的挑战。在万般无奈中,可能会拓展现有规则,再增加一个材质的属性。

    这个时候原来的规则就会失效,必需又再加一个材质。而又过了一段时间,可能又出来一种新的产品,型号、规格、颜色、材质也是完全相同,但是外壳会有小小的差异,那这个新的产品,又无法用现有的规则来给它编码,必需要加一个外壳的属性,来和以前的老产品区分开。

    长此以往,编码会越来越复杂,越来越长。当无法承受再增加属性的时候,只好在代码中加上几位流水码。而老的编码考虑到历史可追溯性,可能不会去变动,还是会保留最原始的型号+规格+颜色,但此时它的代码已经失去正确识别一个物料的原有意义了,因为从这个编码已经无法识别它的材质、它的外壳和新物料的区别了。

    所以既然要加流水码,为什么我们不在一开始就用流水码表示,而硬要把属性挤到代码中,限制了代码向后兼容的能力呢?

    第四:代码本身最核心的意义,在于唯一辩识一种物料,相当于一个身份ID,如果代码中包含太多信息,那么这个代码势必会很长。非常不利于现场操作人员使用。

    我们的仓库、物流等人员在使用代码的时候,可能根本不关心代码本身的含义,只要准确无误就可以了,我照着代码录单据,或者照着代码收发实物。

    如果代码很长,其中某几位细微的变动,反而不利于肉眼发现,也不利于手工输入,更容易带来不必要的麻烦,增加了易错性。

    实际上复杂的编码体系,除了制定编码的部门,其它部门其实根本不关心,而就算是制定编码的部门,面对复杂冗长的编码时,除非抱着厚厚的编码手册查询,否则也极有可能分不清中间第多少位的AB分别代表什么。

    在项目中,我对很多客户,都喜欢举这么一个例子,在这里也可以和大家分享一下。很多年前曾经有个客户很疑惑地问过我,他说陈老师,你觉得太过复杂,包含太多意义的编码是不可取的,那为什么我们中国的身份证号码会有十几位,那么长的一个编码呢。

    其实在我看来,中国的身份证号码有十几位,看起来很严肃很规范,某几位是什么含义,代表着哪个省份、哪个城市,某几位又代表着什么信息。但这种编码方式,恰恰是不足以借鉴一个编码规则。

    以我自己为例,我是四川人,所以我的身份证号码头两位是51。不过后来大学毕业以后,我到了上海,在上海定居,户口迁到了上海,但是身份证号码却不能再变。没有变成上海的31开头,还是以51开头。因为我们的身份证号码是不能再变的,我们需要追溯我们过去的行为。所以这个时候我的身份证号码里面包含的省市这个信息,就失效了。

    当你光看我的身份证号码的时候,你是不能知道我现在的居住地,现在的户籍所在地的。

    那么身份证号码里面包含的这个信息,不但是不可以再用,反而可能会起到误导的作用,让你以为我还在四川。如果你想知道我的准确的信息,你还得根据我的身份证号码,再去电脑里面查更详细的,关于我的信息。

    如果你想偷懒,只从号码上对我进行判断,那你可能就错了。所以既然这样,我们干嘛还要在身份证号码里面包含这些可能会变动,可能会变成错误的信息码呢?不如把身份证号码变得短小一点,在输入电脑查询的时候,还可以更方便,更不容易错一点。

    当然我们国家的身份证号码的编码体系,在当时电脑不那么普及,还没有什么大数据,没有什么云平台中心的年代,那是必需这么编的。

    因为我们要按不同的省市去分发号段,避免身份证号码重复,这在当时没有形成统一信息平台的环境下,是最优的选择。

    所以我并不是说我们国家的身份证号码的编码规则就完全不对,这在当时的年代,是最适合的。但是如果是现在来设计身份证制度,那这种编码规则,就值得再商榷了。

    因此我们在项目中,为客户设计物料的编码规则的时候,就一定不要让过去的一些习惯做法,或者在过去的手段和环境下适合的方案,直接搬过来,不加分析地就用在现在的环境下。

     

    项目中常见的分类方法

    第一种:很多客户或者顾问,喜欢把业务伙伴按产品类别进行分类。

    例如将供应商分为主材供应商、辅材供应商、固定资产供应商等;将客户按购买产品的种类,可能分为电机类客户,电器类客户等。这种分类方法看起来挺合理,但其实相当不科学。

    所有的分类必需是唯一的。某一个供应商或者客户,根据你分类的原则,要么是属于A分类,要么是属于B分类。不能既可以属于A,又可以属于B

    第二种:按业务伙伴的重要程度来进行分类。

    例如把客户可以分为VIP客户、普通客户,把供应商分为A类供应商、B类供应商、C类供应商等等。

    这种分类的管理目的:

    一是可以按重要程度来对不同类别的业务伙伴提不同的要求,增加不同的逻辑控制和约束。比如普通客户,我们可能就要求必需要有预收款,或者必需要做信用额度的管理等,而VIP客户,我们允许进行月结,不用预收款等等。

    二是可以按重要程度的不同,来对不同类别的业务伙伴进行评分,或者统计分析。例如对A类供应商和B类供应商,我们可以有不同的到货及时率的考核和要求,并进一步影响到不同类别供应商的回款周期等等。

    三是可以对不同重要程度的业务伙伴,指派合适的、专人进行业务跟踪。例如对于A类供应商,有可能采购金额大,重要程度高,我们可能需要指派经验丰富、技能更强的采购员进行跟进。而B类供应商,我们可能就指派几个供应商,由一个采购员兼管等等。

    第三种:按业务伙伴的身份来分类。

    这种分类在集团化管理的公司中比较常见。按集团的子公司、集团外部等因素划分为:关联方业务伙伴、外部的业务伙伴等。方便做集团层面的合并报表。

    第四种:按地域将客户分为华东区的客户、华南区的客户等。

    但是我不建议这个分类用业务伙伴组来划分。可能你觉得很奇怪,这个分类通常是不变的,并且按业务伙伴组来划分,可以指定不同的价格清单,很符合我们前面的原则,为什么不用业务伙伴组来划分呢?

    第一:某一个业务伙伴,它所属的地区可能是不变的,但是我们对地区的划分,是有可能随着管理要求的变化而变化的。所以我们的管理要求在不断变化,我们这个分类的标准可能就会不断变化,用业务伙伴组来划分,那就要不停地去修改,重新归类,甚至重新去制定过账的逻辑、控制约束的逻辑等等,很不方便。

    第二:我们在业务伙伴主数据里面,本来就有地区这个属性,并且这个属性是可以不断增加和修改,还能添加层次的,所以我们应当用这个属性来做地区的分类,这才是最适宜的。

    第五种:按业务伙伴的性质来划分。

    例如对客户,我们可以分为代理商、经销商或者最终客户等。对供应商,我们可以分为长期供应商,零星供应商等。这种分类,通常的管理目的,是针对不同性质的业务伙伴,制定不同的价格策略;例如对代理商和最终客户,可能就会执行代理价和最终售价等等。

    另外还可以对不同性质的业务伙伴,制定不同的、强制管理逻辑。比如可以设置对长期供应商,必需要用价格协议来管理,并且自动检查采购订单的价格,是否和签定的价格协议相符。而对零星供应商,则强制触发采购订单或者采购报价单的审批流程等。

    以上,我们列举了常见的一些业务伙伴分类的方法,以及他们的管理目标。在实际的项目中,根据客户所处的行业、管理目标,还会有很多的一些分类要求,这些就需要我们的顾问,在实际项目中,认真的分析客户管理上真正的需求和痛点!帮助客户分析,并给出建议。

    那么我们在有了ERP这种工具以后,比较好的编码方案应该如何去制定呢?我最常用的一种编码方案,可以给大家分享一下:

    我一般会建议,以流水号为SAP系统中的物料编号:物料编码的首位,可以按物料组,或者物料的其它大类进行分类区分,除此外全部用流水码进行识别。而首位,通常用一个字母来区分就可以了,一个字母+流水号,最简捷,最方便。而流水号如果有四位,你的编码体系,仅仅一个物料大类就可以容纳1万种物料,而整个编码总长度也才5位,既方便记忆,又方便录入,非常有实用性。

    按物料组或者大类,进行首位区分,在实际使用中最方便。例如用字母A代表产成品,那么在SAP系统中选择物料时,输入A,所有的产成品就会自动筛选。也比较有利于录单人员进行快速识别和选择。

    另外首位建议尽量用字母,不要用数字。这个建议是完全基于实际操作层面的一个小细节提出的。因为你如果首位用数字,再加上后面流水码也是数字,当你导出EXCEL的时候,EXCEL很容易误认为导出的就是一个数字,有可能帮你自动变成科学计数,也有可能自动去掉首位的0,还有可能将某些特定的数字转换成日期等等。看起来好象无关紧要,但对现场操作人员来说,可能会带来额外的,很烦的一些转换的工作量。这些细节我们都要为客户考虑到。

    今天的课程主要内容大约就是这些,我们主要讲了两方面的内容,一方面是如何标准化物料,以及标准化物料中的各种处理的思路。另一方面就是物料编码设计的原则。因为时间关系,我们有一些内容并没有拓展开来讲。例如对于研发中的物料如何管理,客供料的主要管理的流程,以及一些特殊的物资,比如办公用品、劳保用品如何去处理,要不要做物料管理等等。这些内容在后面的课程中,我会尽量穿插进去和大家分享。

    文章来源:陈华讲B1

    展开全文
  • 物联云仓是专业从事仓库租赁、仓运配、供应链金融、云端应用、现货批发的一站式仓储电商综合服务平台。平台以日均25万平米的速度汇聚全国仓储资源,拥有月均超过100万平米的在线仓库需求,在线仓源1亿多平米,拥有PC...

    仓库货物如何堆放是不少企业最头疼的问题之一。明明预计的场地足够,但到最后却有一大堆货物没处安放,员工的工作效率也极低,白白浪费了钱财与空间。而企业想要利用有限的空间发挥最大的作用就只有先了解仓库货物堆放标准。

    图片来源:网络

    一、仓库货物堆放方法

    1、散堆法

    散堆法是一种将无包装的散货直接推成货港的货物存放方式。它特别适合于露天存放的没有包装的大宗货物,如煤炭、矿石、散粮等。这种缩码方式简便,便于采用现代化的大型机械设备,节约包装成本,提高仓容利用率。

    2、垛堆法

    对于有包装的货物和裸装的计件货物一般采取垛堆法。具体方式有:置叠式、压缝式、纵横交错式、通风式、栽柱式、俯仰相间式等。货物堆垛方式的选挥主要取决于货物本身的性质、形状、体积、包装等。一般情况下多平放(卧放),使重心降低,最大接触面向下,这样易于堆码,货垛稳定牢固。下面介绍几种常用的堆垛方式:

    (1)重叠式:重叠式又称宜叠式,货物逐件、逐层向上整齐地码放。这种方式稳定性较差,易倒垛,一般适合袋装、箱装、平板式的货物。

    (2)压缝式:压缝式即上一层货物跨压在下一层两件货物之间。如果每层货物都不改变方式,则形成梯形形状。如果每层都改变方向,则类似于纵横交错式。

    (3)纵横交错式:纵横交错式即每层货物都改变方向向上堆放。采用这种方式码货定性较好,但操作不便,一般适合管材、扣装、长箱装货物。

    (4)通风式:采用通风式堆垛时,每件相邻的货物之间都留有空隙,以便通风防潮、散湿散热。这种方式一般适合箱装、桶装以及裸装货物。

    (5)栽柱式:码放货物前在货垛两侧栽上木桩或钢棒,形成U形货架,然后将货物平放在桩柱之间,码了几层后用铁丝将相对两边的桩柱拴连,再往上摆放货物。这种方式一般适合棒材、管材等长条形货物。

    (6)俯仰相间式:对上下两面有大小差别或凹凸的货物,如槽钢、钢轨、箩筐等,将货物仰放一层,再反一面伏放一层,仰伏相间相扣。采用这种方式码货,货垛较为稳定,但操作不便。

    3、货架法

    货架法即直接使用通用或专用的货架进行货物堆码。这种方法适用于存放不宜堆高,需要特殊保管的小件、高值、包装脆弱或易损的货物,如小百货、小五金、医药品等。

    4、成组堆码法

    成组堆码法即采取货板、托盘、网格等成组工具使货物的堆存单元扩大,一般以密集、稳固、多装为原则,同类货物组合单元应高低一致。这种方法可以提高仓容利用率,实现货物的安全搬运和堆存,适合半机械化和机械化作业。提高劳动效率,减少货损货差。

    二、货物堆放的原则

    1、尽量利用库位空间,较多采取立体储存的方式。

    2、仓库通道与堆垛之间保持适当的宽度和距离,提高物品装卸的效率。

    3、根据物品的不同收发批量、包装外型、性质和盘点方法的要求,利用不同的堆码工具,采取不同的堆码形式,其中,危险品和非危险品的堆码,性质相互抵触的物品应该区分开来,不得混淆。

    4、不要轻易地改变物品存贮的位置,大多应按照先进先出的原则。

    5、在库位不紧张的情况下,尽量避免物品堆码的覆盖和拥挤。

    三、货物堆放操作的要求

    1、安全:堆码的操作工人必须严格遵守安全操作规程;使用各种装卸搬运设备,严禁超载,同时还须防止建筑物超过安全负荷量。码垛必须不偏不斜,不歪不倒,牢固坚实,以免倒塌伤人、摔坏商品。

    2、合理:不同商品的性质、规格、尺寸不相同,应采用各种不同的垛形。不同品种、产地、等级、单价的商品,须分别堆码,以便收发、保管。货垛的高度要适度,不压坏底层的商品和地坪,与屋顶、照明灯保持一定距离;货垛的间距,走道的宽度、货垛与墙面、梁柱的距离等,都要合理、适度。垛距一般为0.5-0.8m,主要通道为2.5-3m。

    3、方便:货垛行数、层数,力求成整数,便于清点、收发作业。若过秤商品不成整数时,应分层表明重量。

    4、整齐:货垛应按一定的规格、尺寸叠放,排列整齐、规范。商品包装标志应一律朝外,便于查找。

    5、节约:堆垛时应注意节省空间位置,适当、合理安排货位的使用,提高仓容利用率。

    四、货物堆放的五距

    货物堆码要做到货堆之间,贷垛与墙、柱之间保持一定距离,留有适宜的通道,以便商品的搬运、检查和养护。要把商品保管好,“五距”很重要。五距是指顶炬、灯距、墙距、柱距和堆距。

    1、顶距是指货堆的顶部与仓库屋顶平面之间的距离。留顶距主要是为了通风,乎顶楼房,顶距应在50公分以上为宜。

    2、灯距是指在仓库里的照明灯与商品之间的腔离。留灯距主要是防止火灾,商品与灯的距离一般不应少于50公分。

    3、墙距是指货垛与墙的距离。留墙距主要是防止渗水,便于通风散潮。

    4、柱距是指货垛与屋柱之间的距离。留柱距是为防止商品受潮和保护住脚,一股留10-20公分。

    5、堆距是指货垛与货垛之间的距离。留堆距是为便于通风和检查商品,一般留10公分即可。

    经过小编的讲解,您是否对仓库货物堆放有所了解了呢?物联云仓是专业从事仓库租赁、仓运配、供应链金融、云端应用、现货批发的一站式仓储电商综合服务平台。平台以日均25万平米的速度汇聚全国仓储资源,拥有月均超过100万平米的在线仓库需求,在线仓源1亿多平米,拥有PC端、仓佐盟APP、微信服务号等终端依托,为企业/个人提供精准的仓库租赁解决方案,解决了传统找仓库难、找仓库慢、信息不匹配、信息不安全等问题。好仓库,尽在物联云仓!如果您有仓库租赁需求,欢迎咨询物联云仓网站客服,我们的工作人员将竭力为您提供最适合您的仓库租赁方案。

    声明:本文内容、图片、数据来自于网络,版权归原作者所有,本文仅供交流学习,不做商用,若有来源标注在错误或侵犯到您的权益,烦请告知,我们将立即处理。

    展开全文
  • 数据中心运营规划的基本原则

    千次阅读 2019-12-09 13:50:14
    企业需要为数据中心成功的运营制定一个有效且适应性强的计划,需要采取具体的原则来指导IT人员全面考虑其运营目标以及如何实现这些目标。但很多企业的数据中心运营的规划与努力绝大多数是放在结构设计和开发方面,而...
  • 等保基本要求三级通用要求

    千次阅读 2020-02-03 12:29:52
    本项要求包括: a)机房场地应选择在具有防震、防风和防雨等能力的建筑内; b)机房场地应避免设在建筑物的顶层或地下室,否则应加强防水和防潮措施。 1.2 物理访问控制 机房出入口应配置电子门禁系统,控制、鉴别和...
  • IT供应商评估规范

    万次阅读 2010-11-30 15:37:00
    一、 概述 该规范主要包括两方面内容:供应商的选择原则供应商的评估标准。二、 目前存在的状况 传统的评估方法往往主观的成分过多,有时往往根据供应商的印象而确定供应商的选择 供应商选择的标准不...
  • PMP 考试原则

    千次阅读 2019-12-08 10:54:11
    问题和变更日志、需求文件、可交付成果、活动清单、预算表、质量指标、干系人、风险、供应商等等都涉及到分类,亲和图可用于分类。 通过排序工作,项目经理能够在抓住重点和关键的基础上兼顾一般。帕累托图可用于...
  • 硬件原理图设计规范——基本原则

    千次阅读 2017-12-22 08:37:00
     原理图设计是产品设计的理论基础,设计一份规范的原理图设计PCB、跟机、做客户资料具有指导性意义,是做好一款产品的基础。原理图设计基本要求: 规范、清晰、准确、易读。
  因此制定此《规范》的目的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 27,933
精华内容 11,173
关键字:

对供应商的要求的原则