首页 > 其他分享 >《目标》读后感,一本小说体的管理学著作

《目标》读后感,一本小说体的管理学著作

时间:2023-06-05 16:04:52浏览次数:35  
标签:读后感 迭代 瓶颈 管理学 一本 目标 零件 TOC 工厂


《目标》读后感,一本小说体的管理学著作_贪心算法

 

《目标》一书出资美国管理学大师高德拉特的手笔,为什么会看这本书,最早是字节的一个朋友推荐了一本《抉择》,读完后,感觉《抉择》这本书虽然拗口,但是还是有很多深刻的职业哲学的,从《抉择》的目录推荐里看到了《目标》,目标是高德拉特博士的成名作,因此就感觉得买来瞻仰一下了。看了下豆瓣的评论,大量的好评,一本管理学著作能让很多人好评确实也不容易。

《目标》读后感,一本小说体的管理学著作_贪心算法_02

高德特拉博士


“艾利·高德拉特(Eliyahu M. Goldratt,1947年3月31日-2011年6月11日),是以色列物理学家、 企业管理大师,“TOC制约法”(Theory of Constraints)的创造者。 高德拉特博士被业界尊称为“手刃圣牛的武士”(Slayer of Sacred Cows), 勇于挑战企业管理的旧思维,打破“金科玉律”,以崭新的角度看问题。”


高德特拉是一名物理学家,很神奇的是我比较喜欢的特斯拉CEO马斯克也是读了物理学,马斯克非常推崇的第一性原理,也在他多次演讲中提到,要用物理学的底层原理来解释世界万物,就能抓住事情的本质。物理学还真是一个底层的自然学科,值得深入研究。高德特拉的《目标》一书里,就有很多从物理、化学的角度来阐释对事情的分析,就很不足为奇了。只是非常可惜,高德特拉只活到了63岁,英年早逝。

TOC制约理论


“TOC制约法,theory of constraints,以色列籍物理学家和企业管理大师高德拉特博士 所发明的一套企业管理方法。其管理方法的关键词是constraints,即制约。 其理论核心在于:整个系统的绩效通常总由少数因素决定,这些因素就是系统的制约因素。”


TOC制约法应该是高德特拉企业管理的核心方法论了,基本上这个思想贯穿了《目标》这本书。其通俗易懂的解释,就是在生产流程内,系统的生产力由少数的瓶颈决定的,这些瓶颈制约着这个系统的产出。有点类似“木桶效应”,即木桶的最短板决定了整个木桶的盛水量。

《目标》读后感,一本小说体的管理学著作_迭代_03

《目标》小说核心内容

为什么《目标》这本书我比较推崇,一个非常重要的原因就是写法非常独特,用一种小说体的方式来描述一个濒临倒闭的工厂厂长罗哥,是如何在物理学家、企业管理学家钟纳的的帮助下,和工厂全体员工通过目标、瓶颈制约治理的方式使得工厂起死回生的故事。

同时融入了罗哥和领导的冲突、罗哥和家庭的冲突、罗哥和竞争对手的冲突,通过一个虚拟角色“钟纳”的指导意见,罗哥融会贯通,解决了生产问题,从原来的大幅度亏损在三个月内变成了大幅营利,并且成功晋升成事业部总裁。

目标

首先一个问题,工厂的生存目标是什么?提到目标,很多人都会说一个公司大大小小的事情非常多,目标可能是多个,比如制造业非常重要的一件事,就是购买原料,因此合乎经济效益的采购是不是工厂的目标?企业需要优秀的人才,给社会提供的很多的就业岗位和就业机会,那提供就业机会是不是工厂的目标?盖工厂的就是为了生产产品的,那么生产产品是不是工厂的目标?产品质量是不是公司目标?效率是不是公司的目标?销售是不是目标?市场占有率是不是目标?

都是,也都不是。工厂的目标应该只有一个,那就是“赚钱”,上面的其他所有事情都是为了实现“赚钱”目标的手段而已。因为如果工厂不赚钱,任何附属的项目都没有任何意义,工厂也没有存在的意义。因此定义什么是公司的生产力,那就是但凡朝着公司赚钱的目标走的就是生产力,反之就不是核心生产力。

净利润、投资回报、现金流

净利润、投资回报率和现金流是了解公司是否赚钱的三个重要指标。所以这就是衡量的目标是否达成的具体指标参数。

但是这三个衡量指标,如何才能表达给工厂的所有员工?就如同作者举例,工厂的生产线领班艾迪,就只知道每小时产出零件数量、工人每小时完成的订单数、明白损耗率、明白作业时间、出货时间,但是对净利润、投资回报率和现金流完全没有任何概念,因此就需要把目标衡量指标用工厂运营的方式来阐释。

衡量指标一方面可以充分体现出赚钱这个目标,另外一方面能够从中开发出工厂运营的基本规则。即“有效产出”、“库存”和“营运费用”。

有效产出就是整个系统通过销售获得的金钱;库存就是整个系统投资在采购上的金钱;营运费用就是系统为了把库存转化为有效产出而花的金钱。

同时需要把工厂的所有事情归纳到这三个指标中。制作这个指标一定要把眼光放在整个组织上,而不是只谈制造部门、或者是一个工厂、或者是工厂里的一个部门,需要有全局思维框架,一定不能着眼于局部效益。


例如我之前就在思考行政、后勤、安保这些职位到底在公司的价值是什么?通过上面的归纳指标就很容易了 ,这些都是为了把库存转化为有效产出而需要付出的直接或者间接的运营费用,因此不同阶段不同规模的公司 就要对这块的运营费用占比做非常严格的稽核管理。


机器人的三个基本问题

工厂引入了机器人,看起来好像是提高了生产力,但是实际上是否真的提高了生产力,需要回答下面的三个问题:

  1. 有没有因为安装了机器人而多卖出去任何产品?
  2. 有没有减少雇佣的人工数?
  3. 库存有没有下降?

这个三个问题就对应目标的三个衡量指标,即有效产出有没有增加、有没有裁员带来的成本下降、库存有没有下降?

而实际上,机器人只带来了局部效用,没有带来全局效用,因此机器人的引入就是不符合提升指标的目的,因此是一种对公司无效甚至是降低效用的方式。

每个人都会认为机器人大大提高了生产力,而如果从目标的角度来看,机器人毫无生产力可言,实际上运用机器人的方式根本就是在降低生产力。

每个人时时刻刻都忙碌的工厂是非常没有效率的工厂

很神奇的理论,实际上,我们听过已经倒闭的互联网公司都往往都是996甚至007的公司,比如乐视、暴风影音、迅雷等等。

实际上过多的人力往往带来过多的库存,从而增加成本。最佳实践是应该用目标来管理产能。大多数厂长都倾向于尽可能的调节产能,不让任何资源闲置在一旁,比如机器资源和人力资源。

因为目标不是降低单一的指标,而是应该降低营运费用、减少库存同时增加有效产出综合三板斧同时生效才能达到目标。而平衡产能不会影响到其中任何一项指标,


很多大厂的基层主管都被会要求严格管控一线员工的人力,不能允许员工无活可干,甚至资本家一度希望员工 全部007,不吃不喝,但是实际上可能和公司的整体目标背道而驰。


依存关系

制造业中充斥着各种依存关系,一个工序完成以后,才能进行下一个工序。零件是依照一系列的步骤制造出来的,在乙工人能进行步骤二之前,甲机器人必须先完成步骤一。在装配产品之前,必须把所有的零件都做好。必须把产品装配完成后才能出货。以此类推。

不仅是制造业,其实所有的事情和角色都不会是孤立的,都有相互依赖的关系,有的必须串行有的可以并行,就如同一张价值网络一样,各个节点相互依存,并且又动态调整。

例如工作台的产品功能发布,一般情况下调试前后端互相依赖,发布时,后端要先发布,然后前端才能发布;业务上线时,要前端先灰度,业务开关才能灰度等等。

在超大型项目发布中,往往按照规划,按照预期的编码开发和测试流程,而往往某些没有预见或者评估失误的卡点而导致整体项目DEALY,这就是依存关系非常明显的一个例子。

寻找系统瓶颈

用量化、多视角的方式寻找系统的瓶颈。比如在从工厂里会有的催货员的角色,只要找到催货员最频繁催货的地方,就找到了系统瓶颈。

必须想办法为瓶颈找到足够的产能,使得产能更接近需求。如何充分运用瓶颈,有两个基本的原则:

  1. 绝对不可以浪费瓶颈的时间。比如不能让午休期间瓶颈停工;不能让瓶颈处理不良的零件;不能让瓶颈处理不需要的零件。
  2. 减轻瓶颈的负担,把部分工作交给非瓶颈的生产资源。判断一个零件是否一定需要瓶颈来处理;有没有其他机器可以进行同样的工序

在钉钉工作台项目管理里,很容易出现前端瓶颈,因此我们经常采用的两个原则,第一是充分利用前端人力资源,不给前端分派不重要的任务;第二是要求服务端一专多能,部分偏中后台的功能直接由后端同学编码或者用低代码的方式来实现。

像美国涉及到午休加班,就有强大的工会阻力,尝试去和工会沟通,换位思考,将工厂的困难情况、影响面同步给工会同时也提供灵活的加班或调休工作方式,还是能够打动负责人。

在实际项目里,也要尝试说服后端同学主动承担起一专多能的工作,首先是对整体产出是有利的;其次是对同学的个人成长也是有利的,追求成为π字形人才。

改革再改革

启动资源不等于有效利用资源。有效资源指的是运用资源的方式必须能够推动系统迈向目标;而启动资源只是像按下机器开关一样,无论这样做是不是能带来效益,机器都正常运转。所以启动非瓶颈资源直到把它发挥到极致,是愚不可及的做法。

这些准则表明,我们绝对不可用试图把系统中的每一种资源都发挥到极致。追求局部效益的系统绝对不是好系统,而是非常没有效率的系统。

《目标》读后感,一本小说体的管理学著作_项目管理_04

知名科普UP主李永乐老师讲解过一例贪心算法的例子,贪心算法的核心思想就是不考虑整体情况下,取当前局部最优的选择,进而实现全局最优的选择。而实际上,贪心算法并不能总是获得全局最优。

在实际生活上,很多精致的利己主义这就是用贪心算法来做决策,而往往长期来看,这些人并不能获得整体最优。

缩短生产周期

如果把非瓶颈处理的批量缩小一半会发生什么情况?

  1. 只有一半的库存在生产线旁等待加工,因此只要投入一半的资金再待处理的制品上;
  2. 和供应商沟通好,可以把所有的库存减半;
  3. 厂里被套牢的现金数目就大大减少,也减轻了现金流的压力;

工作台迭代管理,从原来的月度一迭代变成了双周迭代。开始还不知道为什么周期减小的原因,现在明白了周期减少会带来更为敏捷的迭代。一来产品出的需求会更加敏捷,便于快速小闭环交付和验证市场;二来敏捷交付会更快,同学可以在双周内就马达全开快速实现交付,不会因为时间过长而导致疲倦懈怠;

工厂生产过程可以分为四部分:

  1. 转换时间,即资源为处理零件做的各种准备,零件等候;
  2. 处理时间,即把零件处理成更有价值的东西上;
  3. 排队时间,即当资源忙着处理其他零件时,零件排队等候的时间;
  4. 等候时间,也就是零件花在等待上的时间,但不是为了等资源,而是为了等其他零件一起装配为成品。

任何零件所耗费的时间,转换和处理只占一小部分,在排队和等候上会消耗掉大部分时间。事实上,在工厂里,零件大半的时间都在排队和等候上。

事实上,一个需求从开始到交付,分成了需求评审、交互设计、技术方案评审、研发、测试和灰度。主要时间都在需求评审、技术方案评审和测试上耗时极多,因此我们在迭代里把需求评审和技术方案评审都提前到上个迭代周期内并行完成。

常识管理

《目标》的解决方案都有一个共同特性,都很符合一般的常识,也直接呼应过去我们所学到的一切。马克吐温说过,常识其实一点都不平常。

当你试图说服某个盲目遵循通行做法的人时,直接把答案讲出来会毫无效果。事实上只有两种可能,要不他就是不了解你的意思,要不就是他了解你的意思;第一种情况不会带来什么坏处,他们会当成耳边风,第二种情况可能还更糟糕,他们或许理解你的意思,但是他们会帮你要传达的信息看得比批评还要糟糕。

尽管你说的话有道理,但是别人永远不会原谅你暗箭伤人。

混乱中建立秩序

《目标》读后感,一本小说体的管理学著作_企业管理_05

在古希腊时代,当时的人就假设,在五花八门的各种物质中,一定有一些简单的元素构成了所有物质。希腊人认为是空气、土壤、水和其他物质。

后来有人证明,土壤不是基本物质,因为土壤是好几种不同的基本矿物质构成的。

经过很多年以后,由于化学家的努力,发现了很多基本元素。到了19世纪中叶,已经找到了63种化学元素。但是一团混乱,很多人试图给这些元素排序,但是徒劳无功。门捷列夫,这位化学家决心致力于研究元素之间的基本秩序。门捷列夫选择了一个衡量指标,这个指标不会因为温度或者物质状态而改变,那就是原子量,也就是一个元素和最轻的元素“氢”的原子重量比,这个数给门捷列夫提供了一个独一无二的元素辨认工具。

并且他没有把元素简单的排成一列,他注意到基本上每第七个元素就表现出相同的化学特性,只是强度不断上升,因此他把元素排成了七栏的空格。

由于门捷列夫发明元素表的时候,并不是所有元素都找到了,因此还留下了一下空格。借着这个分类法,他能够预测这些未知元素的原子量和特性。

刚开始门捷列夫简直是整个科学界的笑柄,过了好几年后,在门捷列夫还在世的时候,所有他预测的元素都找到了,他发明的元素最后一个被找到的时候,是他预测的16年之后。

如今他的元素周期表成为了化学学生的基本道理。

因此如何找到企业内部所发生的内部秩序,则对目标实现大有裨益。

TOC制约理论内容

《目标》读后感,一本小说体的管理学著作_项目管理_06

上面的流程基本上只是常识,那为什么一开始的时候看不明白?原因在于对“瓶颈的本质”的定义发生了变化。从一开始认为瓶颈是机器到了后面的市场。一直没有对瓶颈有清晰准确的定义。因此我们把瓶颈称之为“制约因素”,即要找到正确的制约因素,才是解决问题的核心步骤。

总结下来,一个主管要能够回答三个问题:

  1. 应该改变哪些事情
  2. 要朝什么方向改变
  3. 要如何改变

必须学会这些思考过程,只有到了那个时候,我才真正尽到了我的责任。

TOC制约法的应用

尽管TOC原先是给制造业的生产流程制定的,实际上TOC的思想可以用于任何生产,包括线下和线上的生产流程。

举例来说,我们项目组原先的项目交付一直DELAY,不管是双周迭代还是月度迭代,经过各种努力,都无法正常交付。对于迭代管理来说,交付率是核心的目标,只有100%按时完成,才给业务目标提供了基本的保障,如果交付率都无法准确实现,就不用谈能否实现业务目标了。因此要实现迭代的100%交付,就使用TOC制约法来解决系统目前交付率极差的问题。

第一步:寻找瓶颈

于是我们开始寻找瓶颈,瓶颈看起来有很多,比如前端人力不够、线上异常问题过多消耗研发经历、没有测试同学导致测试效率低下等,但是我们研究后,发现存在很大一个制约因素,就是产品无法按照时间产出确定性的需求,总是在迭代排期的时候才开始评审,甚至评审后的需求根本无法投入生产,当需求都准备好后,迭代可能都超过了一个星期,因此导致整个迭代交付都是DELAY的。这个是出现问题最多也是每次排期会争论最多的问题,我想我们至少找了这个最大的瓶颈所在。

第二步:挖掘瓶颈潜能

针对产品需求不确定的问题,我们制定了一个制度:排期时间还未确定的需求直接不予排期,同时为了尽量能保障需求在排期时需求基本上是确定的,我们在排期一星期前就是开始推动产品运营开始对焦产品需求,经过充分论证和讨论产品的价值、投入产出比、优先级等,力求在此阶段解决产品的瓶颈问题。

和以往的在排期混乱和迭代后的交付率延迟的甩锅不同,我们团队所有角色开始致力于解决瓶颈问题并将瓶颈的潜能挖掘出最大的潜能。比如提供有效信息输入、提供最佳业务实践、提前组织多轮评审等手段

第三步:迁就上述决定

当瓶颈潜能挖掘和释放后,其他流程都要迁就上述决定,即将研发资源、测试资源高优投入重保的需求,确保需求能按时交付和运行,非紧急的故障、答疑问题都迁就业务迭代节奏。

对于外部的临时需求,我们也指定规则,比如需求必须确定、需求先经过初步技术方案评审才流转到产品再评审,防止外部需求不清消耗影响原来产品的排期迭代。

第四步:给瓶颈松绑

充分输入信息,将比较确定性的技术性的机会点输入给产品和运营,提供确定性的技术和业务需求;产出数据驱动报表供产品充分决策;指定线上问题处理专项,让产品集中于核心的产品流程指定,排除干扰因素。

第五步:返回步骤一

目前正在初步尝试,既有可能出现新的瓶颈,按照TOC法,如果出现新的瓶颈问题就返回第一步持续定位瓶颈并治理瓶颈。比如当解决需求不确定性之后,可能还会出现处理线上问题过多导致研发人力不足导致当前需求DELAY的情况,我们采用的是敏捷迭代的方式,可以双周就能判断本迭代的交付率是否有明显的提高。

更多原创内容,关注微信公众号"ali老蒋",专注于互联网技术架构、职业成长思考分享

更多内容,可以访问网站:http://www.javaer.com.cn/


标签:读后感,迭代,瓶颈,管理学,一本,目标,零件,TOC,工厂
From: https://blog.51cto.com/u_15990596/6416782

相关文章

  • 《构建之法》读后感(4)
      阅读《构建之法》第八章之后,又有了很多的感悟,下面进行总结。第八章重点讲了需求分析,在一个项目中,需求分析是最基础也是最重要的,只有充分了解了用户需求,我们才不会走弯路,才能做出正确的规划,保证项目的进行是按照用户的需求进行的。其中,获取用户需求的方法即用户调查,常用的用......
  • 《构建之法》读后感(5)
    阅读了《构建之法》第九章项目经理,下面进行总结:这一章讲了项目经理的由来和要求,项目经理和其他经理的区别,PM的专业能力。作为一个PM,PM的能力很重要。有能力并且得到大家认可支持的PM才是一个优秀的PM。在这一章节简单地介绍了项目经理是项目团队的领导者,项目经理首要职责是在预算......
  • K8S in Action 读后感(概念简介)
    一、K8S的用武之地今天,大型单体应用正被逐渐拆分成小的、可独立运行的组件,我们称之为微服务。微服务彼此之间解耦,所以它们可以被独立开发、部署、升级、伸缩。这使得我们可以对每一个微服务实现快速迭代,并且迭代的速度可以和市场需求变化的速度保持一致。但是,随着部署组件的增多......
  • 《构建之法》读后感(3)
    阅读构建之法第三章之后,我又有了很多的感悟,这本书的第三章的软件工程师的成长对我的启发很大,在学校,我们需要学的知识和语言太多了。往往给我们一种杂而不精的感觉,但是平时在校期间几乎是没有多余的时间去将所学知识学精的。所以平时老师布置的作业就是很关键了,这是我们学习的一个......
  • 构建之法读后感(1)
    阅读了构建之法第四章,有了很多的感悟,下面写下自身所感,第四章分为两人合作,4.3代码设计规范,4.3.3错误处理。着重介绍断言。编写代码时,如果程序员相信在程序中的某个特定点某表达式值(布尔式)为真,可将其标为断言(assert)。举个栗子:publicclassAssertionDemo{ ......
  • 《构建之法》读后感 3
     《构建之法》是一本关于软件架构设计的书籍,作者是PeterEeles、OliverSims和TracySmith。从一个非常全面而深入的角度,介绍了软件架构的概念、原则、方法和工具,旨在帮助软件开发人员和架构师们构建出高质量的软件系统。在阅读《构建之法》的过程中,我深深地感受到了软件架构设......
  • 人件读后感
    《人件》是一本关于软件项目管理的经典书籍,它强调了软件开发中人的重要性,以及如何创建和维护一个高效、高质量、高创新的开发团队。作者从多个方面分析了影响软件开发的因素,如组织结构、团队文化、沟通方式、工作环境、人才培养、质量控制等,并提出了一些实用的建议和方法。我认为......
  • 人月神话读后感
    《人月神话》是一本探讨软件工程管理的经典书籍,它揭示了软件开发中的一些常见的误区和问题,并提出了一些有益的原则和方法。作者从多个角度分析了影响软件开发效率和质量的因素,如项目规模、时间、人员、沟通、设计、测试等,并提出了一些实用的建议和技巧。我认为这本书对于软件开发......
  • 用户故事和敏捷方法读后感
    用户故事和敏捷方法读后感简要介绍我阅读了一些关于用户故事和敏捷方法的文章,了解了它们的定义,特点,优势和应用场景。用户故事是一种用简单语言描述软件功能的方式,它从用户的角度出发,强调软件要为用户带来什么价值。用户故事通常遵循一个模板:作为一个<角色>,我想要<行为>,以便<目的......
  • 《人件》读后感3
    拜读过《人件)后我感慨:软件工程人员必读书,并不谈软件语言等,全书通算都在说人.《人件) 的着眼点并不在软件开发本身、而是在软件开发中的“人.人件) 提到:软工本质上工作主要问题,与其说是技术问题,不如说是社会学问题,软件的设计本身需要社会,需要“人” 的肯定。当然除了市场上......