（搬家帖）项目管理1：生产管理和项目管理的区别
2011-07-15 22:01:00
生产管理的核心是计划排程，项目管理的核心是沟通。相信有经验的兄弟都会认可。
但是为什么项目管理需要沟通，而且还这么重要，以及沟通什么内容，如何沟通，这就需要对项目管理本质有根本认识了。
我认为生产管理的本质是照着菜谱炒菜，而项目管理的本质是画鬼。
生产管理的特点有三点：可重复的，资源约束是固定的，产品标准是清楚的。
可重复：简单来说，一个成熟厨师昨天、今天和明天炒的宫保鸡丁应该没有区别。
资源约束是固定的：炒一份宫保鸡丁需要的主料、配料一定会准备齐，不然前台就不敢卖这道菜。其他硬件设备，例如炉灶，厨具等等也会配备齐全，小工、案板也会准时到位。
产品标准是清楚的：宫保鸡丁什么味道，什么分量，什么卫生标准那是不但厨师明白，顾客也是明白的。
所以生产管理的主要工作就是：
1、控制质量：也就是你必须保证工艺流程是完成的，例如需要三小时硫化，你不能减成2小时；需要8道工序，你不能三道就完事；需要用一级材料，你不能用二级等等。总之，不能偷工减料，以次充好，敷衍了事。也就是你得在整个制造流程上安上千里眼和顺风耳（现在既有真人，也有各种传感器），把一切尽在掌握中，并有一套高效的数据分析系统，例如什么6σ，预警和判断问题所在，并找到解决办法。
2、控制成本：显然宫保鸡丁标准是3两肉，你放6两肯定亏；如果质量不合格，顾客退货，你也肯定亏。所以控制成本本质上是先制定标准：计划成本或标准成本，然后让你的这些千里眼，顺风耳监督按照标准执行。（本人一般是在企业里实行成本克格勃和成本节约奖励两个手段）这是精细活，属于聪明人使笨力气，制造型企业的利润都是从手缝里一点一滴捡回来的，稍微松一下，就会亏损。
3、控制进度（或产能）：本来三分钟可以出一份宫保鸡丁，你8分钟都出不来，小工在后厨晃来晃去，游手好闲，无所事事，配菜在旁边闲谈抽烟，就是大厨师一个人忙得四脚朝天，这个厨房肯定是计划排程出现严重问题，到处是生产瓶颈，设备利用率上不去，到处窝工，员工劳动生产率上不去，到处闲置，当然生产进度或产能就无法保证了。厨师长会说，不是他们不干活，实在是物料不全，正在等小二打飞的从上海买番茄酱回来。这就是计划排程失败。因为整个生产管理的核心就是计划排程，或者说就是资源最优配置。连物料清单都搞不清楚，原材物料的准备都失误，起码的原材物料都不能实现生产能力匹配，这种管理者只好让他走人。（现在ERP在这方面有系统处理办法，但是使用成功率不高，以后有空再说它的事情）
相比生产管理，我认为项目管理特点是：不可重复，资源约束边界不清楚和没有唯一的产品标准。
不可重复：没有两个项目是完全相同的，就算建两个产品一样，规模一样的化工厂，由于地理环境和资源供应不同，也有很大区别。
资源约束边界不清楚：项目一般都是没有先例可循的，到底需要什么并不能事先列出清单，基本是看菜吃饭，有什么就用什么，能搞到什么就用什么，有时甚至是能抢到什么就用什么。
没有唯一的产品标准：项目由于具有唯一性，又没有参照物，所以项目建设之前，谁也无法说清楚到底要个什么东西，一般只有模模糊糊的一些要求。
例如最近我们在做一个项目，业主提出的要求就很模糊。
“未来10年甚至更长时间主要职责是国务院相关问题进行决策的参谋部，各部委和各省市利益竞争平衡的协调者，各方遵守相关管理规则的监督者，各相关各方的服务者。
为了当好参谋部，就要有能力向国务院提供异常状态动态信息，异常状态的演化趋势判断，对可能出现的问题的预警，以及可能产生灾害的后果分析，同时要有能力向国务院提供可供选择的基于不同风险和成本的应急方案和政策建议，并能够实时展示这些应急方案和政策建议实施后的仿真结果；
为了当好各方利益冲突平衡的协调者，就要有能力向各方提供站在国家整体利益均衡角度，考虑各方互相冲突的多目标在有限的资源约束前提下，满足国家整体利益最大和多目标非劣解的各种协调方案，实现资源的合理均衡配置；
为了能够做好相关各方的纪律执行监督，就要有能力实时监控关键指标的异常状态，并能够及时处理数据，形成预警报告和监察报告；
为了做好相关各方的服务者，就要有能力向各方提供不同等级，不同质量的信息。”
基于这种画鬼思想，项目经理的主要任务就是把心目中的鬼（也在不断变化）通过沟通，销售给客户，让客户相信他需要的就是这个鬼，（沟通不好，客户非要认为鬼必须是椭圆脸，而你只能画出三角脸来，你的项目就失败了）；通过沟通，让下面执行层的总图设计师（系统分析师），子系统设计师（架构师），工程师（程序员），等等理解他们要画一个什么样的鬼。（沟通不好，一些人画出来圆形的脑袋，一些人画出来三角形的身体，根本对接不上，你的项目就失败了）。
实际上目前大型项目实施的失败率是非常高的（失败的定义是进度大幅延后，不断返工，不断修补；预算大幅突破，工作量大幅增加，难度大幅增加；质量大幅缩水，系统功能不断简化或失效，完全达不到预先设计要求等等）。国内信息系统目前成功率只有25%左右，而工业项目也只有30%。
但是为什么项目管理需要沟通，而且还这么重要，以及沟通什么内容，如何沟通，这就需要对项目管理本质有根本认识了。
我认为生产管理的本质是照着菜谱炒菜，而项目管理的本质是画鬼。
生产管理的特点有三点：可重复的，资源约束是固定的，产品标准是清楚的。
可重复：简单来说，一个成熟厨师昨天、今天和明天炒的宫保鸡丁应该没有区别。
资源约束是固定的：炒一份宫保鸡丁需要的主料、配料一定会准备齐，不然前台就不敢卖这道菜。其他硬件设备，例如炉灶，厨具等等也会配备齐全，小工、案板也会准时到位。
产品标准是清楚的：宫保鸡丁什么味道，什么分量，什么卫生标准那是不但厨师明白，顾客也是明白的。
所以生产管理的主要工作就是：
1、控制质量：也就是你必须保证工艺流程是完成的，例如需要三小时硫化，你不能减成2小时；需要8道工序，你不能三道就完事；需要用一级材料，你不能用二级等等。总之，不能偷工减料，以次充好，敷衍了事。也就是你得在整个制造流程上安上千里眼和顺风耳（现在既有真人，也有各种传感器），把一切尽在掌握中，并有一套高效的数据分析系统，例如什么6σ，预警和判断问题所在，并找到解决办法。
2、控制成本：显然宫保鸡丁标准是3两肉，你放6两肯定亏；如果质量不合格，顾客退货，你也肯定亏。所以控制成本本质上是先制定标准：计划成本或标准成本，然后让你的这些千里眼，顺风耳监督按照标准执行。（本人一般是在企业里实行成本克格勃和成本节约奖励两个手段）这是精细活，属于聪明人使笨力气，制造型企业的利润都是从手缝里一点一滴捡回来的，稍微松一下，就会亏损。
3、控制进度（或产能）：本来三分钟可以出一份宫保鸡丁，你8分钟都出不来，小工在后厨晃来晃去，游手好闲，无所事事，配菜在旁边闲谈抽烟，就是大厨师一个人忙得四脚朝天，这个厨房肯定是计划排程出现严重问题，到处是生产瓶颈，设备利用率上不去，到处窝工，员工劳动生产率上不去，到处闲置，当然生产进度或产能就无法保证了。厨师长会说，不是他们不干活，实在是物料不全，正在等小二打飞的从上海买番茄酱回来。这就是计划排程失败。因为整个生产管理的核心就是计划排程，或者说就是资源最优配置。连物料清单都搞不清楚，原材物料的准备都失误，起码的原材物料都不能实现生产能力匹配，这种管理者只好让他走人。（现在ERP在这方面有系统处理办法，但是使用成功率不高，以后有空再说它的事情）
相比生产管理，我认为项目管理特点是：不可重复，资源约束边界不清楚和没有唯一的产品标准。
不可重复：没有两个项目是完全相同的，就算建两个产品一样，规模一样的化工厂，由于地理环境和资源供应不同，也有很大区别。
资源约束边界不清楚：项目一般都是没有先例可循的，到底需要什么并不能事先列出清单，基本是看菜吃饭，有什么就用什么，能搞到什么就用什么，有时甚至是能抢到什么就用什么。
没有唯一的产品标准：项目由于具有唯一性，又没有参照物，所以项目建设之前，谁也无法说清楚到底要个什么东西，一般只有模模糊糊的一些要求。
例如最近我们在做一个项目，业主提出的要求就很模糊。
“未来10年甚至更长时间主要职责是国务院相关问题进行决策的参谋部，各部委和各省市利益竞争平衡的协调者，各方遵守相关管理规则的监督者，各相关各方的服务者。
为了当好参谋部，就要有能力向国务院提供异常状态动态信息，异常状态的演化趋势判断，对可能出现的问题的预警，以及可能产生灾害的后果分析，同时要有能力向国务院提供可供选择的基于不同风险和成本的应急方案和政策建议，并能够实时展示这些应急方案和政策建议实施后的仿真结果；
为了当好各方利益冲突平衡的协调者，就要有能力向各方提供站在国家整体利益均衡角度，考虑各方互相冲突的多目标在有限的资源约束前提下，满足国家整体利益最大和多目标非劣解的各种协调方案，实现资源的合理均衡配置；
为了能够做好相关各方的纪律执行监督，就要有能力实时监控关键指标的异常状态，并能够及时处理数据，形成预警报告和监察报告；
为了做好相关各方的服务者，就要有能力向各方提供不同等级，不同质量的信息。”
基于这种画鬼思想，项目经理的主要任务就是把心目中的鬼（也在不断变化）通过沟通，销售给客户，让客户相信他需要的就是这个鬼，（沟通不好，客户非要认为鬼必须是椭圆脸，而你只能画出三角脸来，你的项目就失败了）；通过沟通，让下面执行层的总图设计师（系统分析师），子系统设计师（架构师），工程师（程序员），等等理解他们要画一个什么样的鬼。（沟通不好，一些人画出来圆形的脑袋，一些人画出来三角形的身体，根本对接不上，你的项目就失败了）。
实际上目前大型项目实施的失败率是非常高的（失败的定义是进度大幅延后，不断返工，不断修补；预算大幅突破，工作量大幅增加，难度大幅增加；质量大幅缩水，系统功能不断简化或失效，完全达不到预先设计要求等等）。国内信息系统目前成功率只有25%左右，而工业项目也只有30%。
22 条留言
1900-01-01 00:00:00
项目管理失败原因总结起来，主要有以下几点：
1、需求不明
一般我们都会首先发现客户对要画的鬼是什么样子不清楚（实际就是对项目的定位、职责和任务不清楚）；其次是对项目要解决的问题不清楚；其三是对面临的症状是什么不清楚；其四是对产生这些症状的原因不清楚；其五是对如何解决这些问题或满足客户需求清单没有共 识；其六谁是各级用户和项目相关各方不清楚；最后是有些什么资源或数据来源支撑其设想不清楚。
2、可能设计不出
一般情况下，应该是客户提出明确的需求及其主要技术指标（例如以汽车为例，客户提出车型是载重卡车，载重量是10吨，最大时速180公里，经济时速100公里，百公里耗油量10升，汽油发动机，最大转速6000，最大扭矩150牛，最大马力200匹，适合寒带到热带，沙漠到水网地区等等）。
这时设计单位根据要求首先将设计出总图，满足上述基本要求；然后进行工作一级分解，例如发动机总成，变速箱总成，车桥总成等等，并包括相应的技术指标及其总装要求技术参数；再然后进行二级分解，例如发动机分解成气缸、活塞、喷油系统、点火系统、降温冷却系统、供油系统、传动系统等等，并包括相应各自技术指标和装配参数等等，如此细分下去，直到每个零件配件，都包括技术规格、数量、质量指标、成本、交货时间和完成单位，并形成各自的分包采购合同，并包括各零配件的质量验收或检测流程、检测方法和合格基准，以及相应的违约责任、支付价格和支付方式。
但是对一个新项目，谁也说不清楚这是个什么东西，应该包括什么硬件，什么软件，都不清楚。当然也就没有计划、没有进度、没有预算、没有参与者清单、没有部件质量标准、没有部件技术指标和主要参数（例如数据格式，数据量，接口特征等等）、没有检测方法和流程、没有验收流程和验收合格标准。
就像不知道汽车的零件、图纸，想组成一辆汽车，可以完成运输任务，谁也没把握成功。
这样也就不会有什么现成的WBS，只能凭项目经理的经验和想象来画：就是在画鬼。
3、可能制造不了
一般造汽车的流程是当分包合同签订后，各个零配件生产商就严格根据合同和相应的生产图纸安排生产计划，根据各自的工艺流程和加工步骤，细分作业流程，绘制加工图纸，安排备品备件采购，工具、模具、器具、夹具等等到位，并进行岗位分工，进行各工序质量控制和监督，并对制成品和在制品不断测试，最终按照合同规定的时间、质量、数量交货，并获得支付报酬。
但是对一个新项目，就算有了WBS，有了设计总图，到那里去找合格的配套厂家，有时是一个非常困难的问题。例如在10年前，我知道一个生产15μ铜箔的工厂，其阴极辊直径3米，全钛合金，精度要求极高，在国内找厂家加工，花了差不多一年半，才找到航天生产火箭的工厂有这么精度高的加工中心。
4、可能组装不上
一般汽车总装流程是先把零配件进行倒数第二层组装，逐步到发动机总成组装，等等，最后总装。由于分解时技术指标和装配参数下达到零配件，零配件又都经过严格质量检测，理论上组装不会有什么问题，但是实际上问题巨大。
搞过大系统的人都知道，大系统研制过程中，最具挑战性的问题不是硬件或软件，也不是材料和加工工艺，更不是材料力学和结构力学，而是系统工程能力----就是如何把一大堆或先进或实用，或国产或引进的设备和技术捏合成为一个整体的能力。
一般来讲在组装过程中，很容易暴露出重大的设计缺陷和技术障碍，导致设计修改甚至推倒重来。这一点在国内很多项目当中曾经多次上演。零配件组装成系统，面临巨大挑战。例如印度阿琼坦克总装完成后就面临散热困难、动力不足、左右变速系统不对称、动力不足等等在设计中根本没有想到的问题。
有些东西没有做过就永远不知道，我们在项目开始前也曾经对可能面对的难题做过这样那样的猜测。结果搞起来之后才发现根本不是这么回事，很多大麻烦都是从小毛病引起的。
5、其他困难
一个大项目可能涉及数百分包合同，数十家研发和几百个生产单位参与，各单位投入力量并不能控制，所以进度很难把握，中间工作质量也很难控制，一旦沟通不畅，协同不力，可能所有前期工作都白费，必须推倒重来。而紧密的沟通和协同在如此多不同单位中，是个天文数字的工作量。
另外大多研究单位都是利用研究生做为基本劳动力，他们一般三年就会毕业，流失，新进来的学生又需要重新开始，极大的浪费资源和时间。如果把系统设计和系统分析安排一年，开发安排一年，整合和测试安排一年，对一个大项目而言，是严重不够的，因为很多模型的建模数据就至少需要三年采样，模型验证又需要三年以上。所以不可避免的需要N代学生前赴后继。而开发人员流失就是必然现象。
实际由于大型项目从用户、管理者、设计者和制造者都缺乏足够的经验，失败风险巨大是不可避免的。
1、需求不明
一般我们都会首先发现客户对要画的鬼是什么样子不清楚（实际就是对项目的定位、职责和任务不清楚）；其次是对项目要解决的问题不清楚；其三是对面临的症状是什么不清楚；其四是对产生这些症状的原因不清楚；其五是对如何解决这些问题或满足客户需求清单没有共 识；其六谁是各级用户和项目相关各方不清楚；最后是有些什么资源或数据来源支撑其设想不清楚。
2、可能设计不出
一般情况下，应该是客户提出明确的需求及其主要技术指标（例如以汽车为例，客户提出车型是载重卡车，载重量是10吨，最大时速180公里，经济时速100公里，百公里耗油量10升，汽油发动机，最大转速6000，最大扭矩150牛，最大马力200匹，适合寒带到热带，沙漠到水网地区等等）。
这时设计单位根据要求首先将设计出总图，满足上述基本要求；然后进行工作一级分解，例如发动机总成，变速箱总成，车桥总成等等，并包括相应的技术指标及其总装要求技术参数；再然后进行二级分解，例如发动机分解成气缸、活塞、喷油系统、点火系统、降温冷却系统、供油系统、传动系统等等，并包括相应各自技术指标和装配参数等等，如此细分下去，直到每个零件配件，都包括技术规格、数量、质量指标、成本、交货时间和完成单位，并形成各自的分包采购合同，并包括各零配件的质量验收或检测流程、检测方法和合格基准，以及相应的违约责任、支付价格和支付方式。
但是对一个新项目，谁也说不清楚这是个什么东西，应该包括什么硬件，什么软件，都不清楚。当然也就没有计划、没有进度、没有预算、没有参与者清单、没有部件质量标准、没有部件技术指标和主要参数（例如数据格式，数据量，接口特征等等）、没有检测方法和流程、没有验收流程和验收合格标准。
就像不知道汽车的零件、图纸，想组成一辆汽车，可以完成运输任务，谁也没把握成功。
这样也就不会有什么现成的WBS，只能凭项目经理的经验和想象来画：就是在画鬼。
3、可能制造不了
一般造汽车的流程是当分包合同签订后，各个零配件生产商就严格根据合同和相应的生产图纸安排生产计划，根据各自的工艺流程和加工步骤，细分作业流程，绘制加工图纸，安排备品备件采购，工具、模具、器具、夹具等等到位，并进行岗位分工，进行各工序质量控制和监督，并对制成品和在制品不断测试，最终按照合同规定的时间、质量、数量交货，并获得支付报酬。
但是对一个新项目，就算有了WBS，有了设计总图，到那里去找合格的配套厂家，有时是一个非常困难的问题。例如在10年前，我知道一个生产15μ铜箔的工厂，其阴极辊直径3米，全钛合金，精度要求极高，在国内找厂家加工，花了差不多一年半，才找到航天生产火箭的工厂有这么精度高的加工中心。
4、可能组装不上
一般汽车总装流程是先把零配件进行倒数第二层组装，逐步到发动机总成组装，等等，最后总装。由于分解时技术指标和装配参数下达到零配件，零配件又都经过严格质量检测，理论上组装不会有什么问题，但是实际上问题巨大。
搞过大系统的人都知道，大系统研制过程中，最具挑战性的问题不是硬件或软件，也不是材料和加工工艺，更不是材料力学和结构力学，而是系统工程能力----就是如何把一大堆或先进或实用，或国产或引进的设备和技术捏合成为一个整体的能力。
一般来讲在组装过程中，很容易暴露出重大的设计缺陷和技术障碍，导致设计修改甚至推倒重来。这一点在国内很多项目当中曾经多次上演。零配件组装成系统，面临巨大挑战。例如印度阿琼坦克总装完成后就面临散热困难、动力不足、左右变速系统不对称、动力不足等等在设计中根本没有想到的问题。
有些东西没有做过就永远不知道，我们在项目开始前也曾经对可能面对的难题做过这样那样的猜测。结果搞起来之后才发现根本不是这么回事，很多大麻烦都是从小毛病引起的。
5、其他困难
一个大项目可能涉及数百分包合同，数十家研发和几百个生产单位参与，各单位投入力量并不能控制，所以进度很难把握，中间工作质量也很难控制，一旦沟通不畅，协同不力，可能所有前期工作都白费，必须推倒重来。而紧密的沟通和协同在如此多不同单位中，是个天文数字的工作量。
另外大多研究单位都是利用研究生做为基本劳动力，他们一般三年就会毕业，流失，新进来的学生又需要重新开始，极大的浪费资源和时间。如果把系统设计和系统分析安排一年，开发安排一年，整合和测试安排一年，对一个大项目而言，是严重不够的，因为很多模型的建模数据就至少需要三年采样，模型验证又需要三年以上。所以不可避免的需要N代学生前赴后继。而开发人员流失就是必然现象。
实际由于大型项目从用户、管理者、设计者和制造者都缺乏足够的经验，失败风险巨大是不可避免的。
2011-07-15 22:02:00 回复
梅菲斯托
2011-11-29 15:35:00
不经意看旧文挖出个好东西。想向忙总请教一下，研发项目管理与一般项目管理相比又有什么异同？有没有比较合适的研发项目管理方面的书籍可以推荐学习一下？
我觉得区别不大，只是需要的专业知识不同，同时研发项目一般时间成本控制更严。流程都是一样的，要点也差不多。
(11-29-2011 03:35 PM)梅菲斯托 提到: _
2011-11-29 16:40:00 回复
airjumper
2011-11-29 20:29:00
追了很久忙总的帖子，先顶一下，再请教：
如果项目管理在开始前并没有一个清晰的概念的话，那怎么在项目开始前做项目的规划和计划呢？毕竟如果计划不清晰，那所做的资源需求和项目预算都可能是完全偏离的，这个应该不是拍脑袋出来的吧。。。忙总如果有现成例子的话，能否讲解一下呢？
如果项目管理在开始前并没有一个清晰的概念的话，那怎么在项目开始前做项目的规划和计划呢？毕竟如果计划不清晰，那所做的资源需求和项目预算都可能是完全偏离的，这个应该不是拍脑袋出来的吧。。。忙总如果有现成例子的话，能否讲解一下呢？
那是你的准备工作太差。我们在项目立项前，会化很多时间来做项目必要性和可行性研究（大概比实施项目时间还要长），根据这个研究，决定是否上项目。这个研究结果就是概念设计。一般项目概念设计都有几百页A4纸，我写过最多的概念设计有700多页，解决了一千多个问题。而且概念设计被通过立项，不过30%。立项后才是系统分析，然后才是系统设计，最后才是你说的执行。
你说的问题应该不会出现。
你说的问题应该不会出现。
(11-29-2011 08:29 PM)airjumper 提到: _追了很久忙总的帖子，先顶一下，再请教：
如果项目管理在开始前并没有一个清晰的概念的话，那怎么在项目开始前做项目的规划和计划呢？毕竟如果计划不清晰，那所做的资源需求和项目预算都可能是完全偏离的，这个应该不是拍脑袋出来的吧。。。忙总如果有现成例子的话，能否讲解一下呢？
2011-11-30 10:24:00 回复
越山
2011-11-29 21:09:00
忙总能否把“本人一般是在企业里实行成本克格勃和成本节约奖励两个手段”展开讲讲？谢谢！
(07-15-2011 10:01 PM)wxmang 提到: _生产管理的核心是计划排程，项目管理的核心是沟通。相信有经验的兄弟都会认可。
但是为什么项目管理需要沟通，而且还这么重要，以及沟通什么内容，如何沟通，这就需要对项目管理本质有根本认识了。
我认为生产管理的本质是照着菜谱炒菜，而项目管理的本质是画鬼。
生产管理的特点有三点：可重复的，资源约束是固定的，产品标准是清楚的。
可重复：简单来说，一个成熟厨师昨天、今天和明天......
成本节约就是定额管理（这个需要很好的管理基础，否则没法实施，中国90%以上企业都做不到，因为管理基础太差），超过定额扣钱，低于定额节约分成；
成本克格勃就是成本稽核（我的稽核分为质量稽核，成本稽核和进度稽核），原理就是在成本控制关键点上有资深（一般是退休返聘）人员监督，不仅仅是物料消耗定额监督，也包括成本，时间，劳动效率监督。他们只是发现问题，并无现场解决问题权力。
这两个东西都需要企业有很好的管理基础，尤其是N年稳定生产的数据支持。民营企业100%做不到。
成本克格勃就是成本稽核（我的稽核分为质量稽核，成本稽核和进度稽核），原理就是在成本控制关键点上有资深（一般是退休返聘）人员监督，不仅仅是物料消耗定额监督，也包括成本，时间，劳动效率监督。他们只是发现问题，并无现场解决问题权力。
这两个东西都需要企业有很好的管理基础，尤其是N年稳定生产的数据支持。民营企业100%做不到。
(11-29-2011 09:09 PM)越山 提到: _忙总能否把“本人一般是在企业里实行成本克格勃和成本节约奖励两个手段”展开讲讲？谢谢！
2011-11-30 10:33:00 回复
水杉
2011-11-30 11:27:00
(11-30-2011 10:33 AM)wxmang 提到: _成本节约就是定额管理（这个需要很好的管理基础，否则没法实施，中国90%以上企业都做不到，因为管理基础太差），超过定额扣钱，低于定额节约分成；
成本克格勃就是成本稽核（我的稽核分为质量稽核，成本稽核和进度稽核），原理就是在成本控制关键点上有资深（一般是退休返聘）人员监督，不仅仅是物料消耗定额监督，也包括成本，时间，劳动效率监督。他们只是发现问题，并无现场解决问题权力。
这两个东西都需......
看过成功的项目很多在建设快，首先看到工艺基本打通成熟，当别人在观察等待时，这边已经下决心开建，别人要三年投产，这边就不到2年，至于建设成本似乎不太重视，当然如忙总所说比较难。
其实如果不是复制一个成功项目，项目管理有点象冒险，经常靠管理者的随机应变或灵感来解决问题，带有相当的偶然性。所以最低成本是山寨成功项目。
(11-30-2011 11:27 AM)水杉 提到: _看过成功的项目很多在建设快，首先看到工艺基本打通成熟，当别人在观察等待时，这边已经下决心开建，别人要三年投产，这边就不到2年，至于建设成本似乎不太重视，当然如忙总所说比较难。
2011-11-30 12:21:00 回复
profer
2011-11-30 20:01:00
搞了一段时间敏捷软件开发，一直不得要领。看到忙总提到的＂柔性＂二字，隐隐约约有了点感觉。整理一下思路，过几天写个汇报贴。
好，我们等你的心得。敏捷软件是不是跟敏捷生产有关？如果是，那可是管理信息系统的最前沿工作。
(11-30-2011 08:01 PM)profer 提到: _搞了一段时间敏捷软件开发，一直不得要领。看到忙总提到的＂柔性＂二字，隐隐约约有了点感觉。整理一下思路，过几天写个汇报贴。
2011-12-01 12:16:00 回复
百分点
2011-12-01 12:37:00
估计不是，他说的应该是为了节省软件生产成本，减少大部分测试职位而还能够保证质量的一种软件开发模式。倒是“敏捷生产”第一次听说，忙总能否介绍下？
(12-01-2011 12:16 PM)wxmang 提到: _好，我们等你的心得。敏捷软件是不是跟敏捷生产有关？如果是，那可是管理信息系统的最前沿工作。
引用:（搬家帖）敏捷制造(Agile Manufacturing,AM)是基于柔性制造和信息系统集成的一种制造方法。
敏捷制造的目的是将柔性生产技术，有技术、有知识的劳动力与能够促进企业内部和企业之间合作的灵活管理（三要素）通过信息系统平台集成在一起，为客户快速变化的需求提供的定制生产。集成的基础是通用数据交换标准、云计算、宽带通信信道。
所以具有高度柔性的生产设备是创建敏捷制造企业的必要条件，例如生产系统必须随时可改变生产流程结构，生产线由可量测的模块化制造单元构成的可编程的柔性机床组；制造过程控制系统完全智能化和自动化，用传感器、采样器、分析仪与智能诊断软件相配合，对制造过程进行闭环监视；用数字计算方法设计复杂产品；可靠地模拟产品的特性和状态，精确地模拟产品制造过程。
并行工程实施。（各项工作是同时进行的，而不是按顺序进行的。也即同时开发新产品，编制生产工艺规程，进行产品销售。）
敏捷制造系统是一种信息高度集成的系统。信息在制造、工程、市场研究、采购、财务、仓储、销售、研究等部门之间连续地流动，而且还要在供应厂家之间连续流动。用户和供应厂家在产品设计和开发中都有发言权，每一个产品都可能要使用具有高度交互性的网络。
敏捷制造另外一个概念是虚拟公司。因为新产品投放市场的速度是当今最重要的竞争优势。推出新产品最快的办法是利用不同公司的资源，使分布在不同公司内的人力资源和物资资源能随意互换，然后把它们综合成单一的靠信息手段联系的经营实体--虚拟公司，以完成特定的任务。也就是说，虚拟公司就像专门完成特定计划的一家公司一样，只要市场机会存在，虚拟公司就存在；该计划完成了，市场机会消失了，虚拟公司就解体。在美国，虚拟公司将运用国家工业网络--全美工厂网络，把综合性工业数据库与服务结合起来，以便能够使公司集团创建并运作虚拟公司，排除多企业合作和建立标准合法模型的法律障碍。这样，组件虚拟公司就像成立一个公司那样简单。
在动态竞争的环境中，关键的因素是人员。柔性生产技术和柔性管理要能够最大限度地发挥人的主动性。有知识的人员是敏捷制造企业中唯一最宝贵的财富。
敏捷制造实际本质就是：柔性可以使企业转变为一种通用工具，这种工具的应用仅仅取决于人们对于使用这种工具进行工作的想象力。大规模生产企业的生产设施是专用的，因此，这类企业是一种专用工具。与此相反，敏捷制造企业是连续发展的制造系统，该系统的能力仅受人员的想象力、创造性和技能的限制，而不受设备限制。
(12-01-2011 12:37 PM)百分点 提到: _估计不是，他说的应该是为了节省软件生产成本，减少大部分测试职位而还能够保证质量的一种软件开发模式。倒是“敏捷生产”第一次听说，忙总能否介绍下？
2011-12-01 13:21:00 回复
ssun1cn
2011-12-01 12:46:00
(12-01-2011 12:16 PM)wxmang 提到: _好，我们等你的心得。敏捷软件是不是跟敏捷生产有关？如果是，那可是管理信息系统的最前沿工作。
敏捷软件是软件开发的一种管理控制方法，其对应的是以前的瀑布法，也就是CMM那套东西。
敏捷开发更强调人在其中主观能动性，强调拥抱变化，沟通上主张小团队直接面对面交流来解决问题，控制上要求不断以小版本递进，要求几周就出一个可以用的版本，不断重构的方式推进项目。
方法上而言，包括测试驱动，则开发具体API前先完成测试代码的开发。认为最好的文档就是代码，要求多写注释，尽量减少文档的使用。座位安排上布置成背对背的环形结构，遇到问题直接座位一转就可以沟通等等。
书可以参考《敏捷软件开发：原则、模式与实践》
Robert C﹒Martin
谢谢，知道了，原来不是什么创新，只是一种项目组织方法，加上一点动态流程控制。
(12-01-2011 12:46 PM)ssun1cn 提到: _敏捷软件是软件开发的一种管理控制方法，其对应的是以前的瀑布法，也就是CMM那套东西。
敏捷开发更强调人在其中主观能动性，强调拥抱变化，沟通上主张小团队直接面对面交流来解决问题，控制上要求不断以小版本递进，要求几周就出一个可以用的版本，不断重构的方式推进项目。
方法上而言，包括测试驱动，则开发具体API前先完成测试代码的开发。认为最好的文档就是代码，要求多写注释，尽量减少文档的使用。座位安排......
2011-12-01 13:28:00 回复
越山
2011-12-01 12:50:00
忙总的话直言不讳，就是太打击人了。
(11-30-2011 10:33 AM)wxmang 提到: _成本节约就是定额管理（这个需要很好的管理基础，否则没法实施，中国90%以上企业都做不到，因为管理基础太差），超过定额扣钱，低于定额节约分成；
成本克格勃就是成本稽核（我的稽核分为质量稽核，成本稽核和进度稽核），原理就是在成本控制关键点上有资深（一般是退休返聘）人员监督，不仅仅是物料消耗定额监督，也包括成本，时间，劳动效率监督。他们只是发现问题，并无现场解决问题权力。
这两个东西都需......
我觉得与其照顾面子绕弯子，把人绕晕，还不如实话实说，不浪费别人时间。
(12-01-2011 12:50 PM)越山 提到: _忙总的话直言不讳，就是太打击人了。
2011-12-01 13:36:00 回复
ssun1cn
2011-12-01 13:44:00
(12-01-2011 01:28 PM)wxmang 提到: _谢谢，知道了，原来不是什么创新，只是一种项目组织方法，加上一点动态流程控制。
在软件行业算创新了，不考虑个人主义的情况，以前都是瀑布法，从CMM3-CMM5，中间有大量的文档和流程控制，如果发生需求变更就很惨。
因为信息产业其实是服务于传统行业的，需要有资深的行业专家才能深刻理解需求，否则就要经历一个痛苦的过程，按照瀑布法，是先沟通需求，然后出需求文档，用户确认后出设计，随后做个大版本出来再给客户看，包括一些小功能这时候也做好了，但是由于沟通问题或者需求理解问题或者其他，绝大多数情况下，用户看到具体东西，操作过才能提出比较有用的意见或者发现问题，再走流程回炉大改，项目就开始失控了，敏捷开发呢，更强调人主观动能，而且强调重构和小步快进，中间也减少了大量本来依赖文档的沟通工作。
国外这个是90年提出，2000年开始比较大规模实践，2003年的时候国内还在流行CMM呢，那时候成天就在吹印度软件业强大，而且那时候要接国外项目如果公司通过了CMM会很有利。
到现在基本就都不提了，印度软件年产值，也就我们的1/4，信息产业出口大头是服务外包。
大概可以这样类比，以前是照客户点菜的菜单炒菜，炒出来客户不爽，还得再炒，浪费严重，时间长；现在更强调个人经验对客户口味的变化估计，不单纯看他的点菜单，而是根据经验和需求，先做点样品试吃（有的餐厅是把厨房开放给客户的，你可以进去参与共同创作），逐步逼近客户喜欢的味道，最后出菜。
(12-01-2011 01:44 PM)ssun1cn 提到: _在软件行业算创新了，不考虑个人主义的情况，以前都是瀑布法，从CMM3-CMM5，中间有大量的文档和流程控制，如果发生需求变更就很惨。
因为信息产业其实是服务于传统行业的，需要有资深的行业专家才能深刻理解需求，否则就要经历一个痛苦的过程，按照瀑布法，是先沟通需求，然后出需求文档，用户确认后出设计，随后做个大版本出来再给客户看，包括一些小功能这时候也做好了，但是由于沟通问题或者需求理解问题或者其......
2011-12-01 13:53:00 回复
百分点
2011-12-01 18:14:00
这个比方很好玩，我是从成本上来看这个问题的:1) 传统开发模式，开发和测试的比例1:1~1:1.5,10个开发加15个测试就是25个人的资源。现在这个敏捷开发1个团队1个测试，人力成本为10个开发1个测试，共11人，是传统模式的44%左右人力成本。
敏捷开发成本只有传统的一半，坚持传统方式的就被市场淘汰了
2) 以前老有忽悠测试指导开发，开发是创意倾向，测试人员是修补倾向的，于是传统的开发模式，10个开发人员对着15个指导他们修补的测试人员，资源被耗干了。敏捷开发就一个测试，再怎么能忽悠也就一张嘴，量是以前的1/15，主要力量还是可以投入创新去
。在这点上传统开发模式被忽悠倒了。打个比方，你捧出了完美无缺的手动档，人家不怎么完善的自动档早就满街跑了3）敏捷开发剩下的那个测试有讲究了，主要提供用户体验，这个就是带文化色彩的东西了，于是在测试行业混的大量亚、非、拉移民被淘汰出局了
(12-01-2011 01:53 PM)wxmang 提到: _大概可以这样类比，以前是照客户点菜的菜单炒菜，炒出来客户不爽，还得再炒，浪费严重，时间长；现在更强调个人经验对客户口味的变化估计，不单纯看他的点菜单，而是根据经验和需求，先做点样品试吃（有的餐厅是把厨房开放给客户的，你可以进去参与共同创作），逐步逼近客户喜欢的味道，最后出菜。
很好，这个接近系统工程里面的二次设计流程了。
(12-01-2011 06:14 PM)百分点 提到: _
1) 传统开发模式，开发和测试的比例1:1~1:1.5,10个开发加15个测试就是25个人的资源。现在这个敏捷开发1个团队1个测试，人力成本为10个开发1个测试，共11人，是传统模式的44%左右人力成本。
敏捷开发成本只有传统的一半，坚持传统方式的就被市场淘汰了
2) 以前老有忽悠测试指导开发，开发是创意倾......
2011-12-01 22:27:00 回复
三千
2011-12-02 08:15:00
相对于传统的开发模式，敏捷开发精简了一些品质保证的过程。举例来说，原来造个机器有十个步骤，必须前个步骤确认通过了才能进行下一步，否则误差或瑕疵积累，到最后就是个废品。而在软件业，随着业者把握规模软件能力的增强，加上开源运动提供了大批基本质量保证的软件代码，产生了敏捷运动。无论是里面的测试驱动还是极限开发，都是通过简化品质验证过程来加快进度的。优点是响应用户反馈的速度快了，缺点是品质保证是通过实际产品运行中叠代解决，而且敏捷开发对开发者要求更高。
(12-01-2011 10:27 PM)wxmang 提到: _很好，这个接近系统工程里面的二次设计流程了。(这个帖子最后修改于: 12-02-2011 08:24 AM by 三千.)
系统工程二次设计就是基于原件质量或可靠性不达标或不理想，通过系统优化配置，提高可靠性和稳定性，也是一种渐进逼近优化办法，用系统性能代替原件性能。所以我们在航天产品上尽管原件水平比日本相差甚远，但是系统可靠性一直远胜于日本。
其他大系统也是大量使用二次设计的，例如我们的大型预警雷达系统，美国的北极星导弹系统。
不过这个技术好像民用产品没怎么用。中国美国都一样。
其他大系统也是大量使用二次设计的，例如我们的大型预警雷达系统，美国的北极星导弹系统。
不过这个技术好像民用产品没怎么用。中国美国都一样。
(12-02-2011 08:15 AM)三千 提到: _相对于传统的开发模式，敏捷开发精简了一些品质保证的过程。举例来说，原来造个机器有十个步骤，必须前个步骤确认通过了才能进行下一步，否则误差或瑕疵积累，到最后就是个废品。而在软件业，随着业者把握规模软件能力的增强，加上开源运动提供了大批基本质量保证的软件代码，产生了敏捷运动。无论是里面的测试驱动还是极限开发，都是通过简化品质验证过程来加快进度的。优点是响应用户反馈的速度快了，缺点是品质保证是通过实际产......
2011-12-02 12:36:00 回复
jerryehc
2011-12-02 12:35:00
敏捷制造实际本质就是：柔性可以使企业转变为一种通用工具，这种工具的应用仅仅取决于人们对于使用这种工具进行工作的想象力。大规模生产企业的生产设施是专用的，因此，这类企业是一种专用工具。与此相反，敏捷制造企业是连续发展的制造系统，该系统的能力仅受人员的想象力、创造性和技能的限制，而不受设备限制。
---------------------------
以软件体系结构的观点来看，相似点有：
1.企业现有的公司架构+规章制度+柔性生产设备《-----》硬件服务器（dell,hp,ibm等生产的）和软件服务器（如http server + java的application sever）
2.虚拟公司（敏捷制造部门）的员工与关联企业和客户之间的互动《------》WEB 应用是如何运转的
3.虚拟公司如何把握客户需求（从数据分析到结论）的过程《-----》web应用的开发过程中如何把握客户的需求，相对应的有瀑布法、敏捷开发等等
4.虚拟公司决策人员《-----》软件公司里面的行业咨询顾问
5.虚拟公司是不断持续运营，自我更新、进化的《----》软件应用的不断升级
敏捷制造本质是信息流，物流和资金流的协同能力，而且是在不同标准，接口之间的企业协同，就像在讲各种语言的人中间协同作战，所以既不是硬件平台，也不是软件技术，而是协同模型的计算能力是核心。
(12-02-2011 12:35 PM)jerryehc 提到: _敏捷制造实际本质就是：柔性可以使企业转变为一种通用工具，这种工具的应用仅仅取决于人们对于使用这种工具进行工作的想象力。大规模生产企业的生产设施是专用的，因此，这类企业是一种专用工具。与此相反，敏捷制造企业是连续发展的制造系统，该系统的能力仅受人员的想象力、创造性和技能的限制，而不受设备限制。
---------------------------
以软件体系结构的观点来看，相似点有......
2011-12-02 13:14:00 回复
jerryehc
2011-12-02 12:48:00
(12-02-2011 12:36 PM)wxmang 提到: _系统工程二次设计就是基于原件质量或可靠性不达标或不理想，通过系统优化配置，提高可靠性和稳定性，也是一种渐进逼近优化办法，用系统性能代替原件性能。所以我们在航天产品上尽管原件水平比日本相差甚远，但是系统可靠性一直远胜于日本。
其他大系统也是大量使用二次设计的，例如我们的大型预警雷达系统，美国的北极星导弹系统。
不过这个技术好像民用产品没怎么用。中国美国都一样。
a......
军品稳定性和可靠性第一，经济型第二。
民用品刚好倒过来。西门子的手机生产就是个例子，追求稳定性和可靠性，结果倒闭了。
可能是这样，当年系统所搞二次设计的张里千老师，试图给某电视机厂推广二次设计，人家嫌麻烦。
(12-02-2011 12:48 PM)jerryehc 提到: _军品稳定性和可靠性第一，经济型第二。
民用品刚好倒过来。西门子的手机生产就是个例子，追求稳定性和可靠性，结果倒闭了。
2011-12-02 13:56:00 回复
ssun1cn
2011-12-02 12:55:00
(12-02-2011 12:36 PM)wxmang 提到: _系统工程二次设计就是基于原件质量或可靠性不达标或不理想，通过系统优化配置，提高可靠性和稳定性，也是一种渐进逼近优化办法，用系统性能代替原件性能。所以我们在航天产品上尽管原件水平比日本相差甚远，但是系统可靠性一直远胜于日本。
其他大系统也是大量使用二次设计的，例如我们的大型预警雷达系统，美国的北极星导弹系统。
不过这个技术好像民用产品没怎么用。中国美国都一样。
这个倒是让我想到了现在的云计算，不要求单台服务器性能多高，都是通过软件来实现集群解决大规模计算问题，搞一堆普通服务器比几台高性能服务器便宜多了，其实就是通过系统优化设计来解决单服务器性能不足的问题。
对，基本原理就是这个。二次设计主要是数理统计为工具，参数设计是核心。
(12-02-2011 12:55 PM)ssun1cn 提到: _这个倒是让我想到了现在的云计算，不要求单台服务器性能多高，都是通过软件来实现集群解决大规模计算问题，搞一堆普通服务器比几台高性能服务器便宜多了，其实就是通过系统优化设计来解决单服务器性能不足的问题。
2011-12-02 13:58:00 回复
三千
2011-12-02 13:17:00
两者似乎有区别。
系统工程二次设计个人理解是，虽然原件质量或可靠性不达标或不理想，但通过系统优化配置，最终可靠性和稳定性是有保证的。
敏捷开发是减少品质保证的过程换取灵活性（需求响应速度，开发速度等等）。至于最终品质是否能得到保障，很难说，但可以通过一些手段提高保障（比如测试驱动、自动测试，采用高质量库等等）。
系统工程二次设计个人理解是，虽然原件质量或可靠性不达标或不理想，但通过系统优化配置，最终可靠性和稳定性是有保证的。
敏捷开发是减少品质保证的过程换取灵活性（需求响应速度，开发速度等等）。至于最终品质是否能得到保障，很难说，但可以通过一些手段提高保障（比如测试驱动、自动测试，采用高质量库等等）。
(12-02-2011 12:36 PM)wxmang 提到: _系统工程二次设计就是基于原件质量或可靠性不达标或不理想，通过系统优化配置，提高可靠性和稳定性，也是一种渐进逼近优化办法，用系统性能代替原件性能。所以我们在航天产品上尽管原件水平比日本相差甚远，但是系统可靠性一直远胜于日本。
其他大系统也是大量使用二次设计的，例如我们的大型预警雷达系统，美国的北极星导弹系统。
不过这个技术好像民用产品没怎么用。中国美国都一样。
那就有问题，如果一种新的工作流程不能保证产品的质量稳定可靠，他就没有未来。因为返工就会让他崩溃。
(12-02-2011 01:17 PM)三千 提到: _两者似乎有区别。
系统工程二次设计个人理解是，虽然原件质量或可靠性不达标或不理想，但通过系统优化配置，最终可靠性和稳定性是有保证的。
敏捷开发是减少品质保证的过程换取灵活性（需求响应速度，开发速度等等）。至于最终品质是否能得到保障，很难说，但可以通过一些手段提高保障（比如测试驱动、自动测试，采用高质量库等等）。
2011-12-02 14:14:00 回复
ssun1cn
2011-12-02 14:11:00
(12-02-2011 01:58 PM)wxmang 提到: _对，基本原理就是这个。二次设计主要是数理统计为工具，参数设计是核心。
恩 比如做敏捷开发的时候，效率优化这块是等功能开发完成后才做的，现在电脑资源多又便宜，多数功能性的代码慢点对使用没什么影响，最后影响核心效率的往往代码量都不到5%，最后单元测试用例一运行，哪些函数调用次数最多，资源开销最大很快就查出来了，之后再安排骨干把这部分代码重构，弄完后继续跑自动测试，看看是不是出错。
对，就算是巨型系统，例如全国铁路调度这种，影响效率和稳定性的参数也很少，只要找到，问题就解决了。只是找到可不容易，大海捞针。
(12-02-2011 02:11 PM)ssun1cn 提到: _恩 比如做敏捷开发的时候，效率优化这块是等功能开发完成后才做的，现在电脑资源多又便宜，多数功能性的代码慢点对使用没什么影响，最后影响核心效率的往往代码量都不到5%，最后单元测试用例一运行，哪些函数调用次数最多，资源开销最大很快就查出来了，之后再安排骨干把这部分代码重构，弄完后继续跑自动测试，看看是不是出错。
2011-12-02 14:22:00 回复
radiohead
2011-12-02 22:24:00
不太同意 三千 朋友的观点：“敏捷开发是减少品质保证的过程换取灵活性.”
敏捷开发或精益开发(来自丰田)，并不是降低软件质量为代价的。
1. 敏捷就是为了更好满足用户的需要。软件就算再强大再稳定，不能更好满足用户的需求的软件何谈质量。在传统的瀑布开发的过程。 定义用户需求，开发，测试，交付。这个过程中，交付后，往往发现有些功能并不是用户想要的。用户的需求也是很难一下定义清晰的。 在开发迭代的过程，用户参与进来，迭代过程中挖掘和完善功能。
2. 减少浪费，降低小组成员交流成本，团队行为也会调整，提高效率。
3.强调测试驱动，测试自动化。保证质量。
敏捷开发或精益开发(来自丰田)，并不是降低软件质量为代价的。
1. 敏捷就是为了更好满足用户的需要。软件就算再强大再稳定，不能更好满足用户的需求的软件何谈质量。在传统的瀑布开发的过程。 定义用户需求，开发，测试，交付。这个过程中，交付后，往往发现有些功能并不是用户想要的。用户的需求也是很难一下定义清晰的。 在开发迭代的过程，用户参与进来，迭代过程中挖掘和完善功能。
2. 减少浪费，降低小组成员交流成本，团队行为也会调整，提高效率。
3.强调测试驱动，测试自动化。保证质量。
(12-02-2011 02:14 PM)wxmang 提到: _那就有问题，如果一种新的工作流程不能保证产品的质量稳定可靠，他就没有未来。因为返工就会让他崩溃。(这个帖子最后修改于: 12-02-2011 10:30 PM by radiohead.)
目前为止，国内真正意义上的敏捷生产尚未有成功案例（至少我没听说），据说相当难。不知道敏捷开发软件是不是很成功的例子很多？如果有，其实解剖一个案例即可。
(12-02-2011 10:24 PM)radiohead 提到: _不太同意 三千 朋友的观点：“敏捷开发是减少品质保证的过程换取灵活性.”
敏捷开发或精益开发(来自丰田)，并不是降低软件质量为代价的。
1. 敏捷就是为了更好满足用户的需要。软件就算再强大再稳定，不能更好满足用户的需求的软件何谈质量。在传统的瀑布开发的过程。 定义用户需求，开发，测试，交付。这个过程中，交付后，往往发现有些功能并不是用户想要的。用户的需求也是很难一下定义清晰的。 在开发迭代的......
2011-12-03 10:40:00 回复
airjumper
2011-12-02 23:28:00
(11-30-2011 10:24 AM)wxmang 提到: _那是你的准备工作太差。我们在项目立项前，会化很多时间来做项目必要性和可行性研究（大概比实施项目时间还要长），根据这个研究，决定是否上项目。这个研究结果就是概念设计。一般项目概念设计都有几百页A4纸，我写过最多的概念设计有700多页，解决了一千多个问题。而且概念设计被通过立项，不过30%。立项后才是系统分析，然后才是系统设计，最后才是你说的执行。
你说的问题应该不会出现。
谢谢忙总的指导，其实很多时候也能感觉到对现状的把握很不到位，可是也没办法，领导觉得是问题，需要解决，但是没有充分对问题进行展开就埋头于规划方案，真正实施的时候发现困难大堆，意外频出，所以公司内部关于供应链的项目基本上没有成功的，还有一个问题想请教忙总，不知忙总怎么评价外聘的咨询公司对企业所实施的咨询呢？特别是在离散制造业中基础数据相当薄弱的情况下去上oracle的全套ERP解决方案，忙总有类似的经验能分享吗？
如果运营流程你们都没彻底搞明白，全地球的所有咨询公司加起来，也不会搞明白。咨询公司作用不过是把你搞明白的事情写成PPT告诉你而已。或者说用你的手表告诉你几点钟。你没手表，他也无计可施。
长虹ERP项目失败就是例子。
长虹ERP项目失败就是例子。
(12-02-2011 11:28 PM)airjumper 提到: _谢谢忙总的指导，其实很多时候也能感觉到对现状的把握很不到位，可是也没办法，领导觉得是问题，需要解决，但是没有充分对问题进行展开就埋头于规划方案，真正实施的时候发现困难大堆，意外频出，所以公司内部关于供应链的项目基本上没有成功的，还有一个问题想请教忙总，不知忙总怎么评价外聘的咨询公司对企业所实施的咨询呢？特别是在离散制造业中基础数据相当薄弱的情况下去上oracle的全套ERP解决方案，忙总有类似......
2011-12-03 10:37:00 回复
raffaello
2011-12-03 11:19:00
在软件行业，我见到的敏捷开发其核心就是尽量放弃传统模式中的用户沟通（因为成本最高，去掉之后对效率影响最明显），转而进行内部沟通，而沟通的核心在现有的环境下无一例外是所谓的“超级节点”，如果不采用这种方式，那么所谓的“沟通”就会成为笑话，信息传递用不了几级就直追街头大妈的八卦质量，正因为如此担任这个工作的人往往对能力要求极高（样样通，样样精），面对的压力极大（随时处在一线，负责各种问题），所以我对这样的模式能否适应大规模，长周期的传统制造业始终很怀疑，因为“超级节点”不能拆分，否则沟通效率马上降低，但是不拆分的话又很难应对更大规模的工作；其实如果把敏捷开发中负责沟通的部分拆开细化，那就和传统方法也差不多了，不知道理解的对不对
(12-03-2011 10:40 AM)wxmang 提到: _目前为止，国内真正意义上的敏捷生产尚未有成功案例（至少我没听说），据说相当难。不知道敏捷开发软件是不是很成功的例子很多？如果有，其实解剖一个案例即可。
有成功例子吗，要大型系统的，有就可以分析解剖。
(12-03-2011 11:19 AM)raffaello 提到: _在软件行业，我见到的敏捷开发其核心就是尽量放弃传统模式中的用户沟通（因为成本最高，去掉之后对效率影响最明显），转而进行内部沟通，而沟通的核心在现有的环境下无一例外是所谓的“超级节点”，如果不采用这种方式，那么所谓的“沟通”就会成为笑话，信息传递用不了几级就直追街头大妈的八卦质量，正因为如此担任这个工作的人往往对能力要求极高（样样通，样样精），面对的压力极大（随时处在一线，负责各种问题），所以我对这......
2011-12-03 11:34:00 回复
乌金沙
2011-12-05 03:53:00
忙总这话跟“假传万卷书，真传一张纸”或“难者不会，会者不难”的意思差不多。
(12-02-2011 02:22 PM)wxmang 提到: _对，就算是巨型系统，例如全国铁路调度这种，影响效率和稳定性的参数也很少，只要找到，问题就解决了。只是找到可不容易，大海捞针。
最重要的东西，都很简单。不简单的，都不重要。那种要几个月才能说清楚的东西，基本属于细枝末节。
所以科大上数学课，第一节最重要，因为老师会讲这门课的基本思想和框架。没有这个鸟瞰，学生经常进了树林就迷路，终身可能都出不来。
所以科大上数学课，第一节最重要，因为老师会讲这门课的基本思想和框架。没有这个鸟瞰，学生经常进了树林就迷路，终身可能都出不来。
(12-05-2011 03:53 AM)乌金沙 提到: _忙总这话跟“假传万卷书，真传一张纸”或“难者不会，会者不难”的意思差不多。
2011-12-05 11:04:00 回复
莫飞
2011-12-05 04:05:00
google里面有些人用敏捷开发进行处理，不过具体案例公开的不多。我的理解是那些成功的团队，如果不用敏捷开发，用waterfall肯定也可以成功。只不过敏捷开发在某些时候能够提高效率罢了。软件开发相对圈子较小，成功与否更取决于某些关键员工的素质, 跟敏捷生产还是有很大区别的。
(12-03-2011 10:40 AM)wxmang 提到: _目前为止，国内真正意义上的敏捷生产尚未有成功案例（至少我没听说），据说相当难。不知道敏捷开发软件是不是很成功的例子很多？如果有，其实解剖一个案例即可。
所以只是一个提升效率，降低控制成本的流程创新，还谈不上开发平台革命。
(12-05-2011 04:05 AM)莫飞 提到: _google里面有些人用敏捷开发进行处理，不过具体案例公开的不多。我的理解是那些成功的团队，如果不用敏捷开发，用waterfall肯定也可以成功。只不过敏捷开发在某些时候能够提高效率罢了。软件开发相对圈子较小，成功与否更取决于某些关键员工的素质, 跟敏捷生产还是有很大区别的。
2011-12-05 11:02:00 回复