产品配置的概念和实际意义

原帖由 zhizhi 于 2006-4-18 11:26 发表
欢迎讨论技术问题。
不涉及技术问题讨论的话，就没有意思了。

看看你自己在e-works上的精彩表演：

“zhizhi  
头衔:副版主

发帖数量：1070
  积分：1130
           2006-4-19 22:37:21  

号称“产品生命周期管理”，却没有“生命周期管理”的具体功能模块。
十分有趣。”




你这个也叫讨论技术？你自己可以在别人讨论技术的帖子里面发表这种言论，我不过是向你学习而已。

你对teamcenter了解多少？就在那里胡说八道？拜托你对于自己不了解的东西不要胡说，行么？

看看你自己在e-works论坛上的一些表演，自以为是，到处发表自己不切实际的论调。你是每一个领域的专家么？对于自己不清楚地事情最好还是闭嘴！

“======2006-4-18 21:50:37 zhizhi在帖子中写道： ======
这样的要求不合理。

=====================================

为什么不合理呢？

是否因为这样一来就终止了软件公司的行骗——不管是自觉的还是不自觉的——行为？


------------------------------------------------
无  

zhizhi  





头衔:副版主

发帖数量：1070
  积分：1130
           2006-4-19 12:15:11  


客户把风险全部转嫁给供应商。供应商就不承担风险么？客户损害供应商的正当利益，吃亏的终归还是自己。


------------------------------------------------
MSN: erphome01@hotmail.com  

lxcapp  





头衔:助理工程师

发帖数量：117
  积分：117
           2006-4-19 15:15:09  


好一个客户把风险全部转嫁给供应商。供应商就不承担风险么？似乎原本CAPP供应商都是这么干的：先签定合同，明确需求，待项目开发成功且验收通过后，企业却不付钱，于是乎CAPP供应商痛定思痛，万般无奈之下才出此让企业承担风险的下策，是这样吗？zhizhi?

就如同机械制造行业为自己的客户定制机械产品需要大量的投入一样，CAPP供应商为自己的客户定制CAPP也需要大量投入，但是——这决不能成为CAPP供应商也可以向企业要求预付款的理由，原因就在于，供应商所害怕的开发成功后企业不付钱的风险与企业所害怕的付钱之后供应商开发不成功的风险完全不是对等的，前者几乎只在理论上存在，而后者却在事实上大量存在。

亏你想得出用客户损害供应商的正当利益，吃亏的终归还是自己这样的话来规劝企业乖乖地付钱给供应商。其实你还可以摆出一付长者姿态，用这样的劝善良言来谆谆教诲企业：你们不用担心我们供应商拿了你们的预付款却因开发失败而打水漂，就算这次你们的钱打了水漂，那我们在市场上的声誉就会变坏，以后就做不到生意了，这样一来，吃亏的终归还是我们自己。不过，这可需要极端的厚颜无耻才行。

不管如何，你最想说的一句话就是：如果你lxcapp是CAPP供应商，你愿意那么干吗？如果你直接在贴子里问这么一句，我马上答复你，怎么样，zhizhi。

------------------------------------------------
无  

zhizhi  





头衔:副版主

发帖数量：1070
  积分：1130
           2006-4-19 18:28:46  


要么你不信任供应商，干脆就不签合同。要么你信任供应商，就应该有公平的合同条件。对投标来说也是一个道理。至于拿客户的钱开发失败，也不无可能，如果明摆着开发有风险的话。有不讲商业道德的供应商，也有不讲商业道德的客户。但是一般来说，买的没有卖的精。客户不要说占供应商的便宜，能不吃亏就不错了。

------------------------------------------------
MSN: erphome01@hotmail.com  

lxcapp  





头衔:助理工程师

发帖数量：117
  积分：117
           2006-4-19 21:23:18  


要么你不信任供应商，干脆就不签合同。
在上一个帖子里你说：客户损害供应商的正当利益，吃亏的终归还是自己。这听起来还有点靠讲道理来说服企业支付预付款的味道，而现在呢？完全是一付这样的嘴脸——我就是要收预付款的，你不要就拉倒。论坛上是否有二个zhizhi？

要么你信任供应商，就应该有公平的合同条件。
坦率地说，我lxcapp就是CAPP供应商，我怎么一点也不觉得用户不肯付预付款就是不信任我这个供应商呢？我怎么觉得用户不付预付款就是公平的合同条件呢？恰恰相反，我认为用户与我签定合同就是对我的信任，象征性地支付定金更是对我的信任。赶快大喊大叫吧——lxcapp真是太贱了！

拿客户的钱开发失败，也不无可能
拿客户的钱开发失败这样的情况，仅仅是不无可能这么轻巧？难道现实状况是成功案例比比皆是？而不是相反？

有不讲商业道德的供应商，也有不讲商业道德的客户。
这里根本不存在什么商业道德问题。如果供应商有能力开发而不愿投入开发，这倒是商业道德问题，可事实情况是这样吗？难道企业不愿意支付预付款是因为企业怀疑供应商希望将CAPP项目做得让企业满意的诚意吗？非无愿也，实无能也！

客户不要说占供应商的便宜，能不吃亏就不错了。
如果你是我们公司的员工而对客户说这样的话，我在股东会上第一个要求老板将你开除。客户不会指望去占供应商什么便宜，他们希望的只是顺顺利利地获得适合于自己的CAPP系统，然后痛痛快快地把钱付给供应商，对他们而言，只要系统真的适合自己用，便宜有的是。能不吃亏就不错了算是什么意思？难道要客户接受预付款打水漂这样的所谓就不错了的糟糕局面吗？

看了你的回复，我有一个感觉，你根本不是在有针对性地进行回复，而是在自说自话，对于我在前面的帖子里所说的——供应商所害怕的开发成功后企业不付钱的风险与企业所害怕的付钱之后供应商开发不成功的风险完全不是对等的，前者几乎只在理论上存在，而后者却在事实上大量存在——视若无睹，而这，恰恰是机械制造行业对自己的客户总要先收预付款而对CAPP供应商却希望不要支付预付款的根本原因。

末了，我在此声明：我对以上说的付全部责任，我的联系方式：0510-85580715,宋红星。

------------------------------------------------
无  

zhizhi  





头衔:副版主

发帖数量：1070
  积分：1130
           2006-4-19 21:51:36  


呵呵。有趣。
不收预付款是你的策略。别人也有要求收预付款的自由。各人有各人的考虑，各有各的道理。你这么慷慨激昂干什么？

------------------------------------------------
MSN: erphome01@hotmail.com  

lxcapp  





头衔:助理工程师

发帖数量：117
  积分：117
           2006-4-19 22:51:05  


有趣？慷慨激昂？
针对我的无风险的工艺方案，说这样的要求不合理的谁？
针对我的为什么不合理的诘问，说客户把风险全部转嫁给供应商。供应商就不承担风险么？客户损害供应商的正当利益，吃亏的终归还是自己这句话的是谁？
针对我的反驳，横下一条心说要么你不信任供应商，干脆就不签合同。要么你信任供应商，就应该有公平的合同条件。对投标来说也是一个道理。至于拿客户的钱开发失败，也不无可能，如果明摆着开发有风险的话。有不讲商业道德的供应商，也有不讲商业道德的客户。但是一般来说，买的没有卖的精。客户不要说占供应商的便宜，能不吃亏就不错了的又是谁？
既然你最终要以不收预付款是你的策略。别人也有要求收预付款的自由这样的话来和稀泥，要以各人有各人的考虑，各有各的道理这样的话为自己在论辩中的退却作注脚，你又逞什么能，对于我的无风险的工艺方案回复这么一句——这样的要求不合理——呢？难道我不知道别人也有要求收预付款的自由。各人有各人的考虑，各有各的道理？
有趣的人是有，可他到底是谁呢？


”

原帖由 amd 于 2006-4-20 09:34 发表
号称“产品生命周期管理”，却没有“生命周期管理”的具体功能模块 ...

哈，一个号称“产品生命周期管理”的系统，用什么具体功能（包括一组功能，也就是功能模块）解决“生命周期管理”的业务需要，不是技术问题吗？
什么是“产品生命周期”，也是技术问题呢。

原帖由 PROD 于 2006-4-4 16:51 发表
设计师查询元件时，要么知道编号，要么只有通过模糊查询，在元件的描述中搜索。但这些描述也是研发部门写的，ERP并没有增加什么设计师不知道的东西，所以设计部门也就不太关心ERP了。

这是不正确的。ERP 有很多和产品有关的数据并不来自设计部门。产品中可能使用的元件，也很可能在维护服务工艺生产等业务领域使用。甚至品种范围比产品设计上可能使用的还多得多。所以这些数据也并不全都来自设计部门。

amd，
既然你很喜欢剪贴，请你再看看那里接着讨论什么内容。不要断章取义。不要心怀偏见和商业利益。

原帖由 zhizhi 于 2006-4-20 15:31 发表
amd，
既然你很喜欢剪贴，请你再看看那里接着讨论什么内容。不要断章取义。不要心怀偏见和商业利益。

我没有任何商业目的，我只是PLM从业者而你是一家公司的老板，究竟谁有商业目的？

你是在我在这里发表了帖子后你有急匆匆赶过去补上，你的动机已经很明显。究竟谁怀着不可告人的目的？
现在SAP在大力发展渠道特别是对于中小型企业，你的公司的机会来了？呵呵，你大可以欺骗一些客户了。

我赞成你观点，讨论技术问题。但不是你故意歪曲事实，隐瞒和欺骗客户。再看看你在E-WORKS的文章以及人家怎么评论你。就你原来刚来到E-WORK时还比较公正，但是在你自认为有了一定名气后就开始怀着不可告人之目的经常发一些评论却不给出证据和你的理论依据来误导客户。






zhizhi
头衔:副版主

发帖数量：1074
  积分：1134
           2005-9-7 10:54:41  


有的顶尖 PLM 项目，耗资几百万，过了几年，结果是：
1。最基础的文档管理用得乱七八遭，用户上上下都承认，里面全是垃圾。总工程师说，我从来不看这些垃圾！
2。机械电子电器设计工艺加工制造等多个专业中，仅机械 CAD 有可能建立 BOM。其他的则完全不管。而机械 BOM 也基本没有建立。已经建立起来的所谓 BOM ，靠几个字符串字段描述而不是唯一编码区别对象，且完全手工输入，没有任何用菜单或列表方式选择的功能。就是说，产品结构中 100 次出现同一个螺栓 GBxx-xx M20x80 ...，设计人员就必然要100次重复向系统输入同一描述--螺栓 GBxx-xx M20x80 ...。结果是一个品种的螺栓有几十种写法。（任何空格有无的区别，大小写的区别，标准年号的区别，。。。都能造成不同的描述字符串）结果是计算机根本不可能靠这样的数据识别同一对象。结论是，设计人员用高劳动强度在 PLM 中生产垃圾 BOM。实际工作中 100% 的 BOM 是用 word 编辑产生的。上了 PDM 还要用 word 手工编辑 BOM ？？？ 事实如此。
3。无工程变更管理功能。
4。无产品变型管理功能。
5。无产品配置管理功能。（无论高级低级）
6。无分类检索功能。
7。无数字样机功能，当然也无可视化的协同设计。
8。无红笔圈注功能。
9。无文档分发功能。
10。项目不是100个，而是仅有几个，项目管理已经进入彻底失控状态。项目活动的前后衔接关系已经因无法维护而全部删除，完全谈不上计划调整和关键路径--项目管理实际上成了一个工作任务列表--用 word 也能编辑。
11。用户几乎不能做任何定制修改和开发
。。。
为什么没有提供必要的功能和业务运行支持服务？用户不懂 PDM，当然也提不出这些要求！当然 PLM 也就暗中窃喜。这就是“系统实施时的业务建模”的奥秘。

我也许就是“纯属吃饱饭没事干的那种”。看着如此 PLM 项目的实施现状，顶尖 PLM 还使劲地强调其不可替代的伟大历史性作用，“心里过不去！”

这个话题会激起某些人的愤怒，是不是因为“商业利益上过不去”？我不知道。


------------------------------------------------
MSN: erphome01@hotmail.com  

smardoing  





头衔:工程师

发帖数量：219
  积分：206
           2005-9-7 11:50:16  



zhizhi所列事实绝对是片面的，就本人参与的pdm项目，都不超过100万，都用起来了，有问题，但是决没有那么严重。我们不得不承认有技术局限，有认识模糊，有制度滞后等障碍，使得我们无法达到理想状态，为此大家都在努力。
为什么PDM/PLM有市场、难道不能并到ERP当中去，由ERP包办吗。如果这样可以大大减少冗余，提高系统效率，缩短实施周期，减少投资，对各方面都好，何乐而不为？可是这实在不是某个人说了算的，即便是用户，一部分用户说了也不算。
请看两个（仅仅看作他们两个)用户的说法
mosesi (来源：https://www.smarteam.cn/bbs):

說穿了也沒什麼大不了 erp沒有生命週期的部分交給smarteam做

erp沒有歷程紀錄的部分交給smarteam做

smarteam只需要傳最新文件給erp 透過資料庫很簡單

那舊有的erp的所有查詢跟報表功能一樣可以運作

主系統以smarteam為主

一來除了keyin和研發部門可以走smarteam  其他部門還是可以根據erp的部分繼續進行

万都信息战略部经理李永宪（Lee Yong-heon）
(来源：https://www.ptc.com/china/news/whitepaper/casestudy_mando.htm)

记者：作为已对PDM有投资经历的公司，您对行业有有什么建议？

李：尽管不是短时间所能实现的，但我仍希望整车制造商采用一种能覆盖所有协作功能的系统。

没有这样一种功能完善的协作系统，各协作公司只能通过CAD数据管理来寻求改进过程整合，我认为这样并不是有效的方法，它应该在更大的框架中进行，并应面向过程控制的各个层次、图纸和文件控制、BOM和设计变更。

关于该话题，我相信PTC所宣布的PDS解决方案恰好是这种情况下的正确选择，我们必须创建一种能为所有参与方带来创新的系统。  




xuheguo  

头衔:技术员

发帖数量：21
  积分：22
           2005-9-7 9:47:32  


我觉得zhizhi纯属吃饱饭没事干的那种。我不太懂ERP，所以我不对ERP妄加评论，我建议你在写那些有关PDM/PLM的肤浅思想之前先去好好了解PLM，或者实地考察几个系统，不要停留在你那仅有的一点点表面理解之上，然后来发表。任何一个稍微有点PLM经验的人都觉得你写得可笑，毫无道理，不屑反驳！试问：你ERP得BOM数据源如何而来？ERP如何同时监控100个项目进度？如何实现可视化的协同设计？你知道PLM是如何实现BOM管理以及产品高级配置管理的？不要告诉我，说有个产品结构就是BOM管理了。还有，什么是数字样机确认？至于你说的什么PLM不应该将功能定位在BOM、文档、流程上，真是好笑！所有的PLM客户案例都使用这些基本功能就足以证明你这些都是废话。拜托，大哥，你说点有意义的，譬如：研究PLM如何做好和ERP的集成，如何实现E-BOM到M-BOM得自动转换，发挥你擅长ERP的优势，为PLM作点服务也是不错的。讨论什么PLM取代ERP或者ERP取代PLM，有意思吗？PLM仍然在发展。你身为斑主，在PDM/PLM板块里，就请多多讨论PLM如何更好地为企业服务，如何更好的实施，是PLM人获取信息的场所，不要成为ERP和PLM的战场。
对不起，语言过激，实在是看你发这种帖子太多了，心里过不去！

[ 本帖最后由 amd 于 2006-4-20 16:53 编辑 ]

to amd,
如果你对“产品配置的概念和实际意义”无话可说，我看你就闭嘴吧。或者哪里凉快哪里去唠叨也行。

不错，谢谢...............

原帖由 zhizhi 于 2006-4-20 17:33 发表
to amd,
如果你对“产品配置的概念和实际意义”无话可说，我看你就闭嘴吧。或者哪里凉快哪里去唠叨也行。

狗急跳墙了？还是原形毕露？

原帖由 zhizhi 于 2006-4-20 11:46 发表

这是不正确的。ERP 有很多和产品有关的数据并不来自设计部门。产品中可能使用的元件，也很可能在维护服务工艺生产等业务领域使用。甚至品种范围比产品设计上可能使用的还多得多。所以这些数据也并不全都来自设计 ...

是有许多东西并不来自设计部门，但在产品中使用，也要将这些东西导入PDM才能在产品中使用。除非一些完全可以替换的东西。

还有，楼上的火药味太隆，各人商业上观点地球人都知，没必要说破。

[ 本帖最后由 PROD 于 2006-4-25 18:13 编辑 ]