Total Integration and the Future of PLM

I love the new boutique names for Product Life Cycle Management in this article. I think PLM has always been about the entire "Product" Lifecycle. The "Product" is the layer to solve with integration. This includes concept through end of life,lifecycle. It can touch HW/SW functions, Purchasing, Service Engineering and Sustenance Engineering to name just a few. This is a very broad based definition that is functionally agnostic and frankly by nature supplier agnostic. No one has the platform that does it all and no large global company has a green field from which to start. The issue is that all suppliers want to own the entire system and in turn, make big revenues and lock in territory. That's a great goal for PLM companies, but I don't subscribe to the "Big Bang" thinking, sales talk or approach. It laughable every time I hear it. The result of this "big bang" thinking is that PLM platforms can be closed and in turn not address the true product level integration required by the market place to be successful and drive ROI for a global company. At Carestream we have been pushing for a "Comprehensive PLM" deployment that includes process integration from Concept to Release, BOM Management, Engineering Change (Request, Notify and Implement into ERP). It will integrate both Hardware and Software tool platforms with the Defect and Engineering Change Business Processes as a start. The project is multi year and will involve a internal support model for continuous improvement using an AGILE development approach to new Business Process development and IT platform configuration. It could never be accomplished with one platform or by focusing on one functional group like Current Product, SW or HW. It will integrate platforms from four great suppliers that have sweet spots in very specific areas. Each has offered us licensing schemes that fit what we need and can scale up properly to what we want long term. The day I see a single supplier that can offer a complete PLM platform working at the product level as a "Big Bang" I will be in heaven...... unless the real "Big Bang" is the gun going off when the users execute me then maybe I'll find myself somewhere else! (ok its a bad joke....)

David, Appreciate sharing your thoughts and ideas. Furthermore, interesting to learn again how you position and plan a global Carestream PLM implementation. I agree with your notes about "big bang" approach. I think, most of the people in enterprise software business these days understand the "utopia" of a single system for a company. Cloud and web just speeding up this process. The integration between different models, systems and silos is the right way to go. Just my opinion, of course... Best, Oleg

Sorry for the subterfuge regarding the name -- I always use my real name and somehow on this blog I ended up with tmurphy58 -- didn't mean anything by it.  My full name is Thomas J. Murphy and I am a participating member on many PLM, Lifecycle Product Support, PBL, and other such Blogs, Wiki's and Groups.

I think Mr. Denis and I think alot alike on many things -- I tend to think of things with a Total Lifecycle Systems Management (TLCSM)/Systems Engineering perspective and not the traditional "Design & Manufacturing" vs. "Aftermarket/Sustainment/Product Support" - separated - perspective.

While we are exchanging graphical characterizations of things we are passionate about - I'd like to add to the growing pile -- some of these are very similar to Mr. Denis' pics but these are "foundational" to me when you are really taking a Systems Engineering approach to System Design and Lifecycle Product Support Design as simultaneous and collaborative activities.

Also, our newly designed DoD Acquisition "System" Wall Chart is now called the Integrated Defense Lifecycle Management Chart - https://ilc.dau.mil/

I also think that this community that follows Oleg Shilovitsky might also benefit from doing a little exploring of the Defense Acquisition Guidebook (DAG) --  https://dag.dau.mil/Pages/Defa...  -- to get a feel for the TLCSM perspectives.

I'd love to participate in a group that was focused on TLCSM and not the traditions of the past and present.

Thanks for the opportunity to colllaborate with you folks.

Thomas, thanks for sharing links and comments. Will take a look on this and think to come with some thougths / write-up. Hope to see you commenting on this as well. Best,Oleg

Tom the Aircraft Lifecycle Wikinomics forum on Linkedin focuses on TLCSM

Yes sir ... I've been a member of your group for about 8 months or so I think.  I enjoy it very much but sometimes a little too much "Aircraft" focus for me --- I guess I'm a bit more of a generalist and lean more toward all types of DoD platforms and weapon systems and enjoy the variability.  I spent the last 22 months or so as an Industry representative on the OSD L&MR Product Support Assessment Team (PSAT) and was very involved in the development of several of the new Guidebooks and Governance related documents related to Life Cycle Management and the new Product Support Business Model (PSBM) - so that's probably why I'm more "generically" focused.  Thanks for the dialog and look forward to more interactions.

I find your comment on Continuous Implementation interesting. I was thinking that I was the only person who saw this as a real condition and, or preferable approach.

Michael, I have a team that works with the business on the continuous development and implementation of process and supporting systems since 2004. We have fairly stable funding each year and work on integration and improvement of internal process and tools that support commercialization. We provide maintenance releases for several systems about every quarter for the first few years and then it goes to 2x per year and then stabilizes and we work on the next platform. We standardized the platforms slowly and moved up the food chain over time as more users came to the central systems. Now we have several teams working on many systems at once with an eye on integration across the key systems. We are now realizing as we are called on to implement more complex systems like PLM that the model is very similar to developing software platforms so an AGILE methodology (iterative development) addressing the requirements development, testing and prototypes really suits this space and brings users into the picture rapidly clarifying the requirements. We are just moving in this AGILE development direction for PLM and Service systems with some success but we are still learning. We have always seen the value in developing continuously until the users enhancements slow. A good read->Agile and Iterative Development: A Managers Guide by Craig Larman.

David, Thanks for pointing on this book. I've read about Scrum in the past, but never came to this book. I'd be interested to learn more about your "continues implementation". I want to think about possible technological and product requirements as a consequence of that, and how it may impact applications/products/infrastructure development. Is there a chance we can find a time to talk about that? Best, Oleg

"Continuous implementation" is something very important, in my view. In the life of "system upgrades" and "data model changes", the only way to make system works is to support "continuous implementation mode". However, it is 1/complicated: 2/contradict many vendor's policies of "charge per release". So, I can see some promise from the cloud systems here, but it will not come simple. Best,Oleg

Here's a pix on PLM to ERP (MRP / MRP II) to MRO to SLM versus the elements that effect aircraft / asset availability over the life cycle time line.

Picture of PLM versus SLM

Michael, thanks for sharing the picture!

Oleg, Tmurphy58 has a good point - which is very evident in Robin Hancock view of "Beyond PLM" - the total lack of appreciation for Service or Sustainment Lifecycle Management (SLM).

I'm surprised a senior executive at a PLM vendor - who I assume is cognizant of the significant push toward Total Life Cycle Systems Management in the military as well as A&D OEMs in the civil industries to get farther and farther into aftermarket MRO, SCM and ECM/CMS. 

A recent Economist article http://www.economist.com/node/... is an excellent example of the shifting business models that PLM vendors seem to be oblivious to (although RR, GE and P&W did this shift a decade ago - now airframers and component manufacturers are getting into the Total Care business).

Along the lines of PLM (Product / manufacturing view) versus SLM (Service or Sustainment / operator & maintainer view) - I was recently asked about how xLM systems do (currently) or should (in the future) manage
RINs (Retirement Index Number) used in the helicopter industry.

RINs are like LLP (Life Limited Parts) in that they use algorithms based on helicopter use and maneuvers that exert "excessive" conditions (normally torques on the dynamics sections) of the aircraft.

If equipped, helicopters with HUMS, IVHMS, IMD, AHM, eieio - condition monitoring systems automatically track the event and degree of vibrations and torques and can calculate impact parameters and transfer these outputs to a SLM (near board or off board) system - which then both tracks the life retirement reduction against select P/Ns as well as triggering maintenance inspections required.

In most helicopters, where HUMS / AHM devices do not exist, log write ups (paper or electronic) are manually entered into off board SLM systems - or just manually tracked.

PLM systems, used properly, codify form, fit and function (including upper and lower control limits) - they are not designed to capture and track the teradata of in service operations parameters, maintenance
accomplished or forecast maintenance required in the future.

I think what we will see - as OEMs move more and more into the aftermarket sustainment market is the direct connection of PLM and SLM systems.

In My Honest Opinion (IMHO) - or maybe that should be IM Hopeful O

Michael, Thanks for this insight! I agree, Tmurphy58 (Btw, G+ "real name" policy is the right one :)) made some valid points. Let me separate the feedback into two aspects. The one is obvious - blog capacity. This is something I'm thinking for the last few months- how to increase the blog capacity by inviting more people to blog and discuss things. Some news about that will be coming later this year (Shh... Don't tell anybody :).

The second portion of my feedback is related to my view on SLM. I think, one of the biggest problems in PLM strategies to proliferate and expand to the areas beyond Design and Manufacturing use the old and outdated approach to data management. This is why I favorite "total integration" discussion by Siemens, since "total integration" approach cannot (by definition) disregard the concepts of global data management and stable data modeling concepts, including identification and linking of disparate sources of information. All systems you are talking about needs to rely on the ability to identify and link different sources of information. Can you point me on publications or known practices in this space? Again, thanks for your support on the blog! Appreciate it. Best, Oleg

I think that after 4 weeks of following this Blog I will plan to discontinue following due to the extreme "traditional" focus on PLM for Design and Manufacturing and the total disregard for the concepts associated with Lifecycle Product Support, Design for Lifecycle Affordability, Design for Lifecycle Supportability and Affordable System Operational Effectiveness.

I have been involved in the US DoD world of Weapon System Acquisition and Lifecycle Support for 30 years now and I'd like to see this community begin to focus on the "closed-loop" processes of Total Life Cycle Systems Management (TLCSM) and the melding/integration of the traditional Design Engineering, Manufacturing Engineering processes with the Lifecycle Product Support Engineering processes into a true Systems Engineering process where we are "designing" Reliable, Maintainable, Supportable, Affordable and Capable Systems simultaneously.  This melding/integration should be occuring for the entire System Lifecycle (which is what I call "Lust to Dust") --- it's time to stop acquiring, designing and producing systems and throwing them over the wall to the "Aftermarket" or "Service" or "Product Support" folks --- we need to understand how PLM-enabled Integrated Data Environments allow us to "Design" Affordable, Reliable, Maintainable, Supportable and capable complex systems that will be with us for 40-50 years --- time to bring the Product Support Engineers to the table very early on to help "Design" these systems.  Lots of tremendous thought realted to ERP vs. PLM has gone on in the Defense market over the last 5-7 years and I would recommend that perhaps folks who read this blog may find those papers and case studies very interesting -- these two very different enabling technologies are considered VERY complimentary -- PLM is considered the Intellectual Property and single source of truth enabler and ERP is considered the Physical and Financial Transaction enabler (see graphic below).

It would be very good to see this Blog show some focus on true Total Life Cycle Systems Management (TLCSM) and Affordable Systems Operational Effectiveness (ASOE) and how modern PLM technologies enable these compex, CM-based and collaborative processes vice the traditional focus on Design and Manufacturing.

Is this a possiblilty?

Tmurphy58, Thanks for your comment and opinion! I think, you raised some valid points that probably missed on my blog. If you can provide some links on the discussions and materials related to these aspects of PLM development, I will try to support the conversation about these topics as well. In addition, if you are interested in "live talk", share your real name on the web. Hope to see you back on my blog. Best, Oleg

It is a nice perspective Siemens is offering. Doing such a system afforts a continious automatated update strategy witch helps to finish the project before the next version needs to start early in the process.
Alter having worked with Teamcenter for a long time, I am convinced that Siemens has to get rid of a lot old staff.
I think that this strategy will be the future, but this can only be done with a modern Software. And Software can only be modern when you cut all the old staff. In this case the model based SOA from Aras with a open strategy could help to move forward quickly.
We see much more sucess working with Aras Innovator. 
 

Reinhard, you are right. Simens keeps lots of old stuff. In my view, this is a result of supporting a significant customer base with long lifecycle of implementations. To cut the old stuff is not simple. Manufacturing companies have long implementation and upgrade statuses. In addition, the level of customization in systems like Metaphase is significant. On the other side, Aras is new. It is simpler to them. Btw, can you, please elaborate, what is so special in the model based SOA from Aras that not supported by other PLM vendors? Thanks for commenting! Best,Oleg

Oleg – Nice post.  To your question, “can you, please elaborate, what is so special in the model based SOA from Aras that not supported by other PLM vendors?”… 

Our SOA is different because it’s not simply an integration interface. Our entire system is 100% Web services in a loosely-coupled, federated architecture which is entirely Web-based.  This provides a highly scalable, extensible and robust foundation that partitions well for distributed global deployments and integrates easily in the diverse technology environments that exist in most enterprises.

Now, the “model-based” aspect of our SOA is an innovation by Aras that uses a real-time modeling engine to define and execute complicated enterprise business applications such as PLM processes.  The key advantage of the Aras Innovator modeling engine is that all complex business application data models and process models are defined in XML and model changes are done in real-time using graphical drag & drop editor in a browser… workflows, forms, lifecycles, business rules, even the data schema…

unlike Windchill or ENOVIA (i.e. MatrixOne) which are “model-driven” where you model and then the model produces code which must be compiled, then the objects need to be linked, etc… which by the way, if you ever change the code in Wc or M1 w/o changing the model (and everyone does this) you’ve broken the model and orphaned the customizations… next time you try to upgrade, it’s a re-implementation… and the model doesn’t represent the code base… 

With our/Aras approach even highly customized systems can be upgraded in minutes, not months.

Here’s some links if interested in more info:
http://www.aras.com/technology...
http://www.aras.com/PLM-Softwa...

Hope this helps.

MarcL

Marc, thanks for your comments and sharing links and information about Aras Modeling SOA Approach. As far as I know, in MatrixOne you can dynamically change data model without an compilation/linking. Maybe I'm wrong, but the differentiation is still not clear. I will try to take this conversation in a separate blog post. Best, Oleg

Oleg - Sure thing. Yes, people with technical skills on MatrixOne 'get it' faster than others because there are a lot of similarities.  We have just taken it to the next level; browser-based IDE (we call it the 'solution studio') where data model changes and UI screens are synchronized, not separate, and the foundational 'primitives' are more robust (means can avoid coding customizations). There are other points, but will save those for your separate post. MarcL

Marc, I think Enovia Studio Business Modelers (former MatrixOne business modeler) can do exactly the same. Here is the link - http://www.plmmarketplace.com/...

ENOVIA Studio Business Modeler — Tool to manage the data model and its associated business process including data types, attributes, relationships, security, lifecycle, workflow, and web user interface design.

Of course, devil in details that cannot be explored using blog comments, but "on paper" it smells the same :). Thanks for commenting! Best, Oleg

Yes, "on paper" everything smells the same... like paper.  With Aras you can get the software and validate, head-to-head anywhere, anytime. If you already run ENOVIA MatrixOne, would encourage you to have your best M1 developer download and do a head-to-head where you customize by modeling a complex business processes AT THE SAME TIME in both Aras and MatrixOne (let's say a completely custom enterprise change management workflow for example)... see which system takes less time to model... then deploy them both... see which one is easier to get into your environment... next upgrade them both AT THE SAME TIME... see which one is faster and easier to upgrade your business process customizations. That's the best way to tell.

Would encourage anyone that is serious about a complex enterprise-wide PLM deployment success... don't listen to salesmen with slides... they just want your money and then they don't care anymore and send in other people to deal with all the stories they told... you've got to prove it out yourself.

Just my 2 cents, take it for what it's worth...

MarcL

Marc, it sounds great! It sounds like you are suggesting to have a contest (or competition) to design business process in both systems and compare results. I vote for this activity on your next ACE event. I've seen similar stuff happened for CAD on SWW and other places. I'd love to have an opportunity to watch it. Thanks, Oleg

Absolutely.  We can put that on the agenda if people are into it.  We just need people to bring their full dev environments of other systems.  Anyone interested in volunteering, please contact me directly at mlind at aras dot com

That's why there are some concerns about Total Integration, Multiple Systems Approach and Apple software, which is not about PLM, but we can imagine simple PLM?

Simple PLM? I've been writing about this a lot. However, I never seen it... Did you?

Greg, good thoughts.  I think concurrent engineering has been around for some time with progressive, leading firms.  The challenges have been sharing information in a way that CAD and PLM expertise are not a barrier upstream and downstream.  I believe the most dramatic change is on the doorstep.  That is "portable PLM" supported by technologies like 3D PDF that can be both a means of sharing engineering and design content, but also add business logic by combining (integrating) data from multiple systems into "mini-apps" for consumption by non-engineering end users.  Examples extend beyond ME/mfg and include field service, user guides, marketing, and so forth.  I believe that in 5 years, "portable PLM" will revolutionize the way people get high quality products to market fast.