I think the coolest big change in the evolution of PLM from those original separate developments is exactly that integration that occurred and the continuously-maintained availability of all the modules' data. And thanks, Rob for the reminder that so much of this data on what works can be fed back into the design process.
You bring up a good point about workflow, Beth. I've seen really interesting work done with workflow that is parallel to re-using proven design. If the workflow on a manufacturing project is successful, it can be transferred to another plant - with some adjustments -- and it will save tons of work on the front end.
Workflow software has also been used to capture the knowledge of experienced operators before they retire and take their knowledge out the door. Even something as basic as how to shut down a plant for maintenance is getting captured in workflow software.
I think you're right, Ann. And beyond the integrated nature of the modules, there is this whole notion of workflow so that the same data is continuously available to all the constituents throughout the lifecycle of a product's development, from early requirements planning all the way through managing quality control in the field.
Yes, I get the impression from looking at what I wrote about back then compared to what's available now, that what happened at first was some separate development in individual areas--which have now become modules--before the idea of merging them all into what's now called PLM.
Interesting point, Ann. What you're describing could well be any of these PLM extended modules around quality and service, just like the PTC Windchill product mentioned here. By integrating these capabilities as part of a broader PLM platform and repository, you can achieve the cradle-to-grave view of a product and create a closed-loop system that feeds quality and service data directly back to engineering so they can address issues as part of future development efforts.
That time period sounds right. In the early 90s, I was writing about various efforts to make TQM (total quality management) a reality in US companies, and related efforts that sprang up around those efforts. Most of the initial work I wrote about then was focused on being able to trace components all the way through a product's design and development process and out the door into the field, to first analyze and then reduce causes for field failures. While much of this was prompted by mil/aero apps--and became today's incredibly complex part tracking system in commercial aircraft manufacturing--there were also attempts at integrating other databases, like manufacturing and test data, having to do with other aspects of the product's/system's life cycle before shipment to the customer. Needless to say, the technology for doing so was quite primitive by today's standards.
It is interesting to watch the progression. I've been covering this stuff since early 2000 when it first started being discussed in its own right as a formalized business software category and business process. In some ways, while the technology has come a long way, it's really just now starting to do what it was positioned to do more than a decade ago. I guess what I'm saying is the PLM vision may be a decade-plus old, but the reality of the platforms supporting that vision on a broad, enterprise scale is really just coming into its own.
Thanks for the clarification, Beth. A long time back I wrote about some of the earlier attempts at managing such life cycle data and integration of databases, so it's interesting to see how this all worked out.
Ann, PLM definitely came into prominence via big companies, particularly those in the aerospace and automotive sectors, where development projects are large and complex and frequently involve a network of design partners. Today, PLM has evolved, both as a discipline and as a technology, where it's offered in a format that has appeal and value even for smaller manufacturers.
The idea is centralizing all product-related data and materials so there is a so-called "one version of the truth" and the different disciplines are working off the same vision of the product. As a platform, in addition to the central repository piece, PLM constitutes capabiities for creating cross-functional workflows as well as a variety of extended modules for handling everything from early requirements gathering to field service and support procedures and processes as part of the same integrated system.
Beth, it sounds like PLM is mostly useful in larger companies with lots of different products and product lines to manage, is that correct? And perhaps also products with lots of different, or differently-sourced, components?
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.