Comments for The PLMInsider PLM blog http://www.strookman.ch/mywp Peter Strookman's Insider discussion about PLM Technology, Business Strategies and Value Sat, 04 Sep 2010 21:54:19 +0000 http://wordpress.org/?v=2.7.1 hourly 1 Comment on PLM and ERP Coexistence by admin http://www.strookman.ch/mywp/?p=309&cpage=1#comment-14 admin Sat, 30 Jan 2010 15:37:44 +0000 http://www.strookman.ch/mywp/?p=309#comment-14 Oleg, Thanks for your reply. I also published the same post on.... http://insideplm.wordpress.com. I started with this new copy blog because I experience a lot of spam on PLMInsider where you left your comment. This InsidePLM blog is also more mature because I started to use tags, and there are more comments. You may also want to follow me on Twitter under InsidePLM. Back to your comment.. Quite a coincidence that we both touched on the same topic. With repositioning, you probably mean moving the border line. Ok.... What I described is the purest form. The notion is, that there is a Generic Product Structure (GPS) in both PLM and ERP, GPS in engineering may be the base for a contract configuration and the contract configuration may evolve as the order bom for production. The GPS in PLM may be synced with the GPS in ERP, maybe you create a contract configuration in ERP... It just depends and this will move the border line. On PLM vs ERP.., I do believe that there is strong case for Manufacturing Engineering to create what ever they need to create in PLM. In my post I was very clear what it is they do, and also how they depend on the information in PLM. If you need to define the BOP, then you'd better have access to the right product definition. The BOP may either be a contract BOP or a Generic BOP… and the connection with engineering is so tight and the functions need to be rich as I tried to touch on. And this is exactly the reason that SAP bought Visiprise, because their former OOTB process planning and Manufacturing Execution capabilities was not really best in class, and needed a lot of 'tuning'… and with this Visiprise set they can really position PLM as a separate product platform rather than a module. Next time.., Peter Oleg,

Thanks for your reply. I also published the same post on…. http://insideplm.wordpress.com. I started with this new copy blog because I experience a lot of spam on PLMInsider where you left your comment. This InsidePLM blog is also more mature because I started to use tags, and there are more comments. You may also want to follow me on Twitter under InsidePLM.

Back to your comment.. Quite a coincidence that we both touched on the same topic. With repositioning, you probably mean moving the border line. Ok….

What I described is the purest form. The notion is, that there is a Generic Product Structure (GPS) in both PLM and ERP, GPS in engineering may be the base for a contract configuration and the contract configuration may evolve as the order bom for production. The GPS in PLM may be synced with the GPS in ERP, maybe you create a contract configuration in ERP… It just depends and this will move the border line.
On PLM vs ERP.., I do believe that there is strong case for Manufacturing Engineering to create what ever they need to create in PLM. In my post I was very clear what it is they do, and also how they depend on the information in PLM. If you need to define the BOP, then you’d better have access to the right product definition. The BOP may either be a contract BOP or a Generic BOP… and the connection with engineering is so tight and the functions need to be rich as I tried to touch on. And this is exactly the reason that SAP bought Visiprise, because their former OOTB process planning and Manufacturing Execution capabilities was not really best in class, and needed a lot of ‘tuning’… and with this Visiprise set they can really position PLM as a separate product platform rather than a module.

Next time.., Peter

]]> Comment on PLM and ERP Coexistence by olegshilovitsky http://www.strookman.ch/mywp/?p=309&cpage=1#comment-13 olegshilovitsky Fri, 15 Jan 2010 11:53:30 +0000 http://www.strookman.ch/mywp/?p=309#comment-13 Peter, Very good review of the topic. It will be a very interesting to put it as a practice for PLM and ERP integration. However, I think PLM and ERP vendors will try to re-position you diagram. Some of my thoughts on PLM/ERP integration around BOM - http://plmtwine.com/2009/12/16/back-to-basics-plm-and-erp-integration/. Best, Oleg Peter, Very good review of the topic. It will be a very interesting to put it as a practice for PLM and ERP integration. However, I think PLM and ERP vendors will try to re-position you diagram. Some of my thoughts on PLM/ERP integration around BOM - http://plmtwine.com/2009/12/16/back-to-basics-plm-and-erp-integration/. Best, Oleg

]]> Comment on Social Networking meets PLM by pstrookman http://www.strookman.ch/mywp/?p=85&cpage=1#comment-7 pstrookman Tue, 30 Jun 2009 08:58:43 +0000 http://www.strookman.ch/mywp/?p=85#comment-7 Hello Raj, That is great feedback and an encouragement to continue on this path.. Thanks Peter Hello Raj,

That is great feedback and an encouragement to continue on this path..

Thanks
Peter

]]> Comment on Social Networking meets PLM by rajpillai http://www.strookman.ch/mywp/?p=85&cpage=1#comment-6 rajpillai Tue, 09 Jun 2009 22:42:44 +0000 http://www.strookman.ch/mywp/?p=85#comment-6 I really enjoyed reading your blog... I am in the PLM for many years, I do believe that Peter provides me value (new) insights how PLM components can be used to bring value. I really enjoyed reading your blog… I am in the PLM for many years, I do believe that Peter provides me value (new) insights how PLM components can be used to bring value.

]]> Comment on Software Configuration Management by Mintjens http://www.strookman.ch/mywp/?p=77&cpage=1#comment-4 Mintjens Mon, 18 May 2009 13:37:58 +0000 http://www.strookman.ch/mywp/?p=77#comment-4 I would like to stress that software should be regarded as a product and therefore be an integral part of a product tree or the traditional bill of material. As a thumb rule, any item that is essential for proper operating or manufacturing of a particular product should be subject to configuration management and part of a product tree of that particular product. It does not matter if one is dealing with tangible physical objects like screws or bolts or less tangible items like software. I would like to stress that software should be regarded as a product and therefore be an integral part of a product tree or the traditional bill of material. As a thumb rule, any item that is essential for proper operating or manufacturing of a particular product should be subject to configuration management and part of a product tree of that particular product. It does not matter if one is dealing with tangible physical objects like screws or bolts or less tangible items like software.

]]> Comment on Collaboration and Enabling Framework by Mintjens http://www.strookman.ch/mywp/?p=113&cpage=1#comment-3 Mintjens Mon, 18 May 2009 13:23:53 +0000 http://www.strookman.ch/mywp/?p=113#comment-3 There are currently several mature products on the market that are both technical as commercial superior then the MS offering. But collaboration is not about tools, it is mainly about people and information as the main company assets. Therefore collaboration should be an integral part of any PLM framework. Too many collaboration initiatives did fail in the past due to lack of integration with the main PLM business systems and underestimating of the cultural impact of introducing such a collaboration tool. Such an introduction should be regarded and managed as a business process change management project and not just as the introduction of a new IT application. There are currently several mature products on the market that are both technical as commercial superior then the MS offering. But collaboration is not about tools, it is mainly about people and information as the main company assets. Therefore collaboration should be an integral part of any PLM framework. Too many collaboration initiatives did fail in the past due to lack of integration with the main PLM business systems and underestimating of the cultural impact of introducing such a collaboration tool. Such an introduction should be regarded and managed as a business process change management project and not just as the introduction of a new IT application.

]]> Comment on Integrated Product Teams (IPT) by Mintjens http://www.strookman.ch/mywp/?p=99&cpage=1#comment-2 Mintjens Mon, 18 May 2009 13:06:46 +0000 http://www.strookman.ch/mywp/?p=99#comment-2 In a product design process one should consider the total cost of ownership not only the technical feasibility. I see Integrated Product Teams as an important vehicle to optimize these costs across the life cycle of a product and to define the cost impact of a design decision. In a product design process one should consider the total cost of ownership not only the technical feasibility. I see Integrated Product Teams as an important vehicle to optimize these costs across the life cycle of a product and to define the cost impact of a design decision.

]]>