老翟书摘:《丰田生产方式》

这本书的作者是大野耐一,原丰田汽车工业公司副社长。里面写了大多是一些生产过程中的原则和看法。但是,这些原则和看问题的角度是通用的,即使我们是软件行业。同时,在看完这本书之后,你会对市面上的那些”精益”理论,会有不一样的看法,也不至于盲从。 序 我们的初衷是找出一条适合于日本经济环境的独特的方式,但又不想让别家公司,特别是不想让先进国家轻易地了解它,甚至不让他们留下一个完整的概念,而一直推行和强调“看板方式”或“包括人的因素的自働化”。因此,人们难以理解它,也是很自然的。 第一章:丰田生产方式的诞生 我认为只要杜绝浪费,生产效率就有可能提高10倍。这种想法,正是现在丰田生产方式的出发点。 “彻底杜绝浪费”是丰田生产方式的基本思想,而贯穿其中的两大支柱就是: (1)准时化 (2)自働化 所谓“准时化”,就是在通过流水作业装配一辆汽车的过程中,所需要的零件在需要的时刻,以需要的数量,不多不少地送到生产线的旁边。 究竟怎样才能做到“准时化”? 我们进行了各种试验,最后总结出以下做法:以生产工序的最后一道总装配线为起点,开始给装配线提出生产计划;而装配线上用的零部件的运送方法,也从过去由前一道工序向后一道工序运送的方式,改为由后一道工序在需要的时刻到前一道工序去领取,而前一道工序只按后一道工序的数量生产。 “看板”方式则是顺利推行丰田方式的手段。 丰田生产方式的另一个支柱是“自働化”,但不是单纯的机械“自动化”,而是包括人的因素的“自働化”。 丰田公司的“包括人的因素的自动机器”就是指“带自动停止装置的机器”。 因为当机器正常运转的时候用不到人,人只是在机器发生异常情况、停止运转的时候去处理就可以了。 “自働化”的作用主是,杜绝生产现场中过量制造的无效劳动,防止生产不合格品。 第二章:丰田生产方式的精髓 “为什么会出现生产过量的浪费呢?”针对这个问题,会得出因为“没有控制过量生产机能”的答案,据此展开便生产“目视化管理”的设想,进而导出“看板”的构思。 彻底杜绝浪费,最重要的是充分掌握下述两点: 第一,提高效率只有同降低成本结合起来才有意义。为此,必须朝着以最少量的人员、只生产所需要数量的产品这一方向努力。 第二,关于效率,必须从每一个操作人员以及他们组织起来的生产线,进而以生产线为中心从整个工厂着眼,每个环节都要提高,才能收到效果。 以运用丰田生产方式为前提,需要彻底找出无效劳动和浪费现象: 1. 过量生产的无效劳动 2. 窝工的时间浪费 3. 搬运的无效劳动 4. 加工本身的无效劳动和浪费 5. 库存的浪费 6. 动作上的无效劳动 7. 制造次品的无效劳动和浪费 我是彻底的现场主义者。这是因为我从年轻时起就是在生产现场的不断磨炼中长大的。当了负责经营的管理者以后,就更不开企业的主要数据来源的生产现场了。 我们曾反复提及“准时化”和“自働化”是丰田生产方式的两大支柱,把这一体系的运作工具称为“看板”。现在,让我谈谈它的由来。 实际上,“看板方式”是从美国的自选超市得来的启示。 前面我们已经谈到,这是从自选超市中得到启发的。自选超市使用“看板”后会出现什么情况呢? 在计价器将顾客购买的许多商品计价以后,要把记载着销售出去的商品的各类和数量的卡片(相当于“看板”)送到采购部。这样采购部便可以迅速地补充商品。这种卡片,拿丰田生产方式来说,就相当于“取货看板”。自选超市陈列的商品,就相当于生产现场的工序贮备。 丰田生产方式通过“看板”便可以完全杜绝“过量生产”的现象,不需要超出需求量的库存。不需要仓库,也不需要仓库管理人员,而且,也不需要散发许多单据、传票之类的东西了。 “看板”是“准时化”的一种手段。也就是它是以实现“准时化”为目的的。“看板”是生产线的反射神经,生产现场的作业人员可以根据“看板”开始作业,并判断所需加班时间的长短。 “看板”也能使用管理者、监督者的职责明确化。 “看板”的使用规则第一条是“后一道工序要到前一道工序去领取产品”。 “看板”的第二条使用规则是“前一道工序只生产后一道工序所需要数量的零部件”。 实际上,如果不遵守这些规则而只引进“看板”,既发挥不了“看板”本来的作用,也不能降低成本。这种孤立使用“看板”的做法是有百害而无一利的。 企业越大越需要要具备很好的反射神经。对于计划的微小改动,要做到无需大脑发令也能采取相应的行动。就是说,如果生产管理部不发指令或者不发计划变更通知便不能改变作业,不能采取行动的话,企业就不能避免受创伤、遇大害,并且还会贻误大好时机。只有企业具备无意识适应变化的微调机能,才可以说真正装上了反射神经。我确信:通过“目视化管理”和“准时化”、“自働化”丰田生产方式这两大支柱,将会更好地锻炼这种反射神经。 第四章:丰田生产方式与福特生产方式 丰田生产方式同福特生产方式一样,基本形式是流水作业。索伦森在放置零部件的仓库上颇费一番苦心,而丰田生产方式却不需要仓库。 把同一品种和同一型号的零部件凑在一起,即把批量加大,不换冲模,尽量多次连续冲压进行大批量生产的作法,现在仍是生产现场的常识。福特生产方式大批量体系的关键就在这一点上。美国汽车企业一直证明,有计划地进行大批量生产对降低成本最有成效。 丰田生产方式与此相反,而是“尽量缩小批量,迅速变换模具”。 福特生产方式要加大批量来提高产量,所以,在各处都要有工序间的库存贮备。丰田生产方式则不同,其考虑方法是把这些库存可能导致的生产过剩的无效劳动和浪费,以及管理这些库存的人员、土地建筑的负担完全清除。 福特生产方式和丰田生产方式任何一方都有自身的优点,而且两者都在日日求新与改革,无法下结论说哪一个更优秀,但是我个人深信在低增长的时代,以丰田生产方式较为适合。 老翟评书 市面上有一本有名的书叫《看板方法》的书。说实话,这本书,我没看完。是我看不下去(你可以想象背后的原因),所以我不好评论。为什么要提《看板方法》这本书呢?因为我见过不少把《看板方法》里面的“看板”与丰田生产方式中的“看板”看作是一样东西,包括我自己。所以,我建议大家先看这本大野耐一的《丰田生产方式》,再看《看板方法》。大野耐一说了,他的看板是从美国自选超市得到的启示,是为了实现丰田生产方式的支柱之一:准时化。所以,我也希望大家能从《看板方法》里找出它说的“看板”的根源。 不知道有没有注意到作者在序中说的:但又不想让别家公司,特别是不想让先进国家轻易地了解它,甚至不让他们留下一个完整的概念。这点时刻提醒着我自己,有时我们看不懂别人的理论,并不是我们读者的问题。而是有可能作者有意,或者他自己根本不懂,所以无法表达清楚。 老翟书摘说明 书摘内容完全来自原书,如果原书的作者或出版商觉得我侵权了。请通过开源中国 @翟志军 联系我。 老翟书摘旨在通过一种书摘的方式让大家花最少的时间了解一本书,从而决定要不要继续读下去。书摘的每一本书都是本人亲自读过并理解的。

2015-12-29 · 1 min · 62 words · 翟志军 Jack Zhai

耦合的本质

耦合(coupling)的定义 耦合是对coupling的中文翻译。而coupling是couple的变形,指a connection (like a clamp or vise) between two things so they move together。我相信这就是coupling最朴实的定义。请允许我将其翻译成中文:存在一种连接在两事物之间,以至于这两事物相互影响。 在本文中,耦合可以是一个名词——耦合度的同义词,也可以作为形容词——耦合性的同义词。 软件行业中,耦合从何而来? 至于中文书籍什么时候将coupling翻译成耦合,已经不那么重要了。因为耦合不是从“翻译”而来的。从coupling的定义出发,我们看出不论在哪个层次,不存在绝对不耦合的软件。 软件与业务是需要耦合的,如果不耦合,软件就失去了意义。库存系统是需要和电子商务前端(销售)系统耦合的,否则前端就无法确定是否能供货给用户。如果我们的应用需要使用commons-lang库的StringUtils类,那么我们的应用就要commons-lang耦合的,否则我们没法使用StringUtils中的方法。在函数式编程中,我们的确可以将所有的逻辑(不论技术逻辑还是业务逻辑)封装在没有副作用的一个个函数中,但是我相信这些函数之间还是需要在某个时间点进行耦合。 进而我认为:耦合是“天生”的。 那是不是说我们就可以随意耦合了?显然不是,上述的耦合的例子只是表明耦合的存在性,并没有说明耦合的程度在软件开发过程所起的作用。 所以,和复杂性[1]一样,从根本上来说,我们可以掌握这种耦合,但不能消除这种耦合。 不同级别的耦合 软件是由不同级别的概念层组成,不同级别的概念层具有不同的职责,不同级别的概念层中存在不同的耦合:有方法级别、类级别、包级别、协议级别、语言级别、数据流级别、数据库级别、业务级别…… 方法级别:这不用多说了。 类级别:如果你了解“组合优于继承”原则,你就应该理解什么叫类级别的耦合。这里并不是说继承不好,而面对不同的问题,你需要权衡是“组合”还是“继承”与问题模型更匹配。 语言级别:我们的业务必须使用某各种语言来表达,无论是DSL还是通用编程语言Java、C#。 数据流级别:数据流是指一种我们处理问题的方式:输入数据,然后数据在一条充满处理环节的链上流动,直到完全最后一个处理环节输出处理结果。这很像我们的面向切面编程。 如果P_A要求输入的数据中的日期格式是: YYYY-MM。某天一个新手不小心把在P1中把日期格式改了,那么P_A就会出错。而现实中,我就遇到过一个数据处理流中有将近20多个处理环节,目前几乎没人敢动那块逻辑。另一个例子就是项目使用了Spring的切面编程,由于“切”得太多,到后来调试起来,我不得不遍历所有的切面的逻辑,以确定数据流到哪个环节出的错。 数据库级别:如果你的应用使用到了数据库Oracle特有的特性,那么你的应用就是和Oracle数据库耦合的。想像一下阿里去O的过程。也可以看下这篇文章:http://tech.it168.com/a2015/0417/1720/000001720950.shtml。ORM框架的好处在这方面尤为突出。 通信协议级别:如果通信的双方只依靠协议通信,而不关心实现这个协议的是Ruby程序还是Java程序。这也正是基于HTTP的 RESTFul风格的架构的关键所在。而业界提的微服务思路,其实就是期望各个应用之间只在协议级别耦合,从而与语言、操作系统解耦。通信协议级别上,我们也需要考虑解耦,比如,你的应用能否轻松从HTTP协议迁移到HTTPS。 操作系统级别:文件的路径的写法在各个系统下的不同,所以Java才会有: File.separator 这个常量,在Windows环境下返回\,而在*nix环境下返回/。如果不用此常量来拼文件路径,那么,那部分就是与操作系统耦合的。像: for Windows: C:\windows\system32\cmd.exe for Linux: /var/log/ansible.log 有些人觉得这不如挂齿,看看这条新闻:坚持用 XP 的代价:美国海军付给微软上千万。 PS:使用Ruby的某些gem时就要小心,因为某些gem用到了操作系统的库。 如Nokogiri (鋸) 业务级别:业务级别上的耦合度越高,软件的风险系数越高。假如A公司的领导在职时采用代码行数来KPI程序员,代码行数越多,KPI越好。如果在为这家公司设计HR系统时,你就必须考虑如果A公司换领导了或者原领导反省了,换采用360度评估进行KPI。你的系统能否以相当小的代价实现?又比如政府的某些老系统将一代身份证的身份证号作为自然人在数据库中的ID。可是某天,二代身份证出了,身份证号变成了18位了。那么如果自然人要求更新系统中的身份证号,你怎么办? 比较好玩的是,有时我们的程序有时会和系统用户耦合。 apache-commons-io 下的设置文件的可读/可写权限时,如果使用的是root用户执行此程序会有问题,因为root可对所有的文件可读。 File tmpFile = File.createTempFile(getClass().getSimpleName(), “localities.xml”); tmpFile.deleteOnExit(); tmpFile.setReadable(false); Assert.assertFalse(tmpFile.canRead()); // It would be failed 这个assert将会失败,因为不论该文件是否可读,以root用户执行此程序时,tmpFile始终是可读的。 ...

2015-12-29 · 1 min · 95 words · 翟志军 Jack Zhai