The following 10 items, in no particular order, are presented for your consideration in preparing for PLM projects. The list is not exhaustive and the objective is not to provide definitive answers but to foster the critical conversations about PLM that will help make your organization more successful.
- Is you organization Product (part) Centric or Document Centric?
- Mechanical, Electrical, Software or System?
- How many Bills of Materials does it take to make to make a product?
- Is this where Program Management and New Product Development meet?
- What is Master Data Management and don;t we do this already?
- Are you an engineering company that builds things or a manufacturing company that design things?
- Customers, partners, and Supplier Collaboration
- Integrate application of Best of Breed/
- Organizational Readiness - matching vision with reality
- Jut how much of this 3D stuff do we need?
1. Is your organization part-centric or document-centric?
Many companies are in a state of transition from a document-centric to a product -centric approach when it comes to product data..
Here's one way to determine your current sate. look at you engineering change documentation. What's the key piece of information entered to initiate a design change? The drawing number affected to the part number affected? If you're generating a changes against the "drawing" you're probably document-centric. If you're initiating design changes against a "part" number and then identifying the drawings that need to be changed you're more likely part-centric. One more quick test, are you generating #D models in design or analysis and then turning them into 2D drawings for release? If so, you're probably document-centric in your processes.
Leading PLM systems today tend to be product-centric. You need to understand the impact on your organization business and engineering processes when you introduce this new point of view to data management.
In a product-centric application the “part” is the essential item to be managed. The definition of the part, regardless of format(s), is always related to one or more parts. Parts are related to other parts in parent child relationships to form product structures often referred to as bills of materials. Other documents and additional attributes such as cost or weight are all associated directly or indirectly to the basic element “part”.
Once you recognize that product–centric data management is where you’re headed the rise in importance of graphical data, and specifically 3D visualization capabilities, becomes easier to understand. (See number 9 below for more on the rise of 3D)
By the way, many companies are served quite adequately by engineering processes that are document-centric. After all, we operated that way for decades. Just recognize the difference and think about how you want your organization to operate.
2. Mechanical, Electrical, Software, or System?First, I would offer a brief history lesson. Product Lifecycle Management (PLM) tools were born of Product Data Management (PDM) applications that originated from the need to manage the then new computer aided design tools. The whole industry is less than 30 years old. That’s the genealogy. Great if you’re a mechanical design based organization with little electronics and little software code in your product but that’s rarely the case anymore.
Please recognize that no single application manages the design data generated by the different engineering disciplines equally well. You should plan on integrations to support engineering analysis, software engineering, electrical engineering, and systems engineering depending on your business and existing tools. These authoring tools may have specific data management capabilities but the final results should be managed through a backbone system like PLM. Ambiguous “sources of the truth” or multiple “systems of record” are sand in the process gears of an organization.
Interoperability remains a myth and standards are great because there’s one for everybody. Remember there is no compelling business reason for an authoring tool provider (CAD, CASE, ECAD, etc) to make their tools interoperable with a competitor’s product. All providers will declare their adherence to “standards” for data exchange but none is going to give up a competitive advantage in the name of complete interoperability.
That said, most modern PLM tools have reasonable integrations to leading computer aided design and analysis tools as well as other enterprise applications like ERP. You need to understand where the bulk of the work is done in your organization and then leverage the best integrations. It will always be a moving target.
All modern PLM applications do a pretty good job of managing released data but don’t forget that work-in-process management is often the most difficult part. How do you determine that something is ready to share even if it’s not ready to release? We want downstream users of our design data to get early access for speed and feedback but we’re not always ready to share the unfinished product. PLM systems can help or hinder this effort by providing granular level control to exposure of the data. This early view can be based on a maturity state but can also easily overwhelm the data consumers with changes.
Your organization cannot spend enough time deciding how and when to share “unreleased” or work-in-process data with downstream functions.
3. How many BIlls Of Material does it take to make a product?
This is one of those question that will be sure to start a heated discussion amongst PLM practitioners (the other is about “smart or dumb part numbers” but we’ll leave that for another day). Deep Bills, Shallow Bills, Functional Bills, As-Built Bills, the list of possibilities is endless.
Experience tells us that there are as many bill of material “views” as there are people in an organization to ask for them. Each function has unique data requirements that are based on the product structure or “bill of material”. Not only are their function specific views like engineering and manufacturing there are time-specific views as well; As-Designed, As-Tested, As-Planned, As-Built, and As-Serviced. The list of bill of material acronyms can easily use up the whole alphabet.
PLM and ERP tools are primary bill of material creation and maintenance tools. While desirable, creating and maintain a single Bill of Material with multiple views has so far proved problematic. Lots of fields to be entered, lots of filters to be written for specific views, lots of players responsible for maintain data in a single structure. The jury is still out on the right answer. You need to understand your business needs in terms of views and your PLM application suppliers strategy for Bill of material maintenance and creation or you’ll just end up in the bar fight.
4. Is this where Program Maangement and New Product Development meet?
For the first twenty year of PDM, and now PLM, the functional Holy Grail was an application that would manage engineering tasks, resources, and schedules holistically. PDM tools were good at managing workflow and deliverables but knew little of resource loading or project schedules. Program Management tools scheduled and resourced tasks but were not aware of their status. We made up for this lack of visibility by placing “people were in the loop”. People completed project tasks, or made changes, in the PLM system and then (hopefully) updated the schedule, or (hopefully) informed those who did. This was also the process when project plans changed only in reverse. In my experience, this is neither a timely nor accurate way to manage tasks, resources, or schedules.
Modern PLM systems provide the tools to enable this cross-functional integration. Completion of a deliverable in the PLM domain can automatically update the project task status. Model/Drawing released? Analysis results complete? Update the related program task automatically. Then populate task status in a program dashboard on demand. All from one integrated set of data.
Be sure to match the level of program management functionality in PLM with the need for program management in your organization. Project driven organizations with long development cycles will benefit most from this advanced capability.
5. What is Master Data Management and don;t we do it already?
Master Data Management is essentially a set of processes and tools used to keep the meaning of data in multiple systems consistent. The more applications the more difficult it is to rationalize the data definitions. One applications’ “Part” is another applications’ “Item” , each with their own set of associated attributes which may differ as well. This lack of consistency makes sharing data and maintaining data integrity difficult if not impossible.
For example, every software application in a manufacturing organization wants to control the “part” master data (sometimes referred to as the Item Master). Parts are the DNA of the product and therefore every system wants to control it to maintain accuracy and integrity of the data in that application. While there may never be one master application, to have more than one master for each element of product data is a recipe for cost and chaos.
PLM products are designed specifically to manage our most basic product information. What does the product do? How is it made and what is is it made of? In manufacturing environments, regardless of industry, the part, and its definition, is the atomic level data from which all products are built.
The good news is we can manage parts well in modern PLM systems; the bad news is that every application that deals with the product wants to be the master of this same critical data. We can’t get around this as no one universal application exists to support all the functions required. The best we can do is make sure that there is a master data management plan which defines which system is the master of which data, who is responsible for its maintenance, and that its intent is consistent across all using applications.
While we’re on the subject of master data management we need to discuss the issue of data retention. While some organizations need to maintain historical data on their products for decades, others do not. A serious conversation about retention requirements for product data needs to occur. Clear guidelines for archival and retrieval need to be defined and whenever possible built into the managing applications.
6. Are you an engineering company that builds things or a manufacturing companty that design things?
Your PLM applications should match your businesses strategy and driver characteristics. The technical sophistication, development cycle time, design volatility, support horizon, and regulatory environment of your products each impact allocation of PLM functionality to software applications.
Some organizations may be well-enough served by PLM capabilities in their existing ERP systems. This requires different integration points with design authoring systems and may require additional ERP module licensing but can work. This approach primarily works in Make-to-Stock organizations where product designs are relatively stable and product variation is limited. Using an ERP application to perform primary PLM functions does not eliminate the need for authoring tool specific managers to control work-in-process design and change control.
Engineer-to Order and Customize-to-Order organizations with highly lengthy development cycles, and high product variability benefit most from PLM specific applications. These types of organization typically undertake significant development activity and produce large volumes of data long before the product is turned over to production. Operations managers are often reluctant to introduce volatile development data into their primarily manufacturing ERP systems creating an increased need for PLM applications to manage these product development activities.
7. Customers, Partners and Suppliers and Collaboration
There has been a lot of buzz in the last few years about collaboration. Design teams, suppliers, business partners, customers are all targets for potential collaboration. “Real-time collaboration” is a bright shiny object in the engineering information technology sky at the moment. When asked however most businesses cannot define specifically who or on what level they want to collaborate.
The first question is who are you trying to connect with your collaboration efforts? The internal design team spread across a building, campus, or remote locations? Development partners with significant design responsibility for some portion of a product? Suppliers providing build to print components under a purchase order? Customers providing feedback on new product offerings or design changes? All of these represent some form of collaboration and each requires different enabling tools and infrastructure.
Organizations also struggle with the time factors in collaboration. We speak of real-time collaboration a lot but the practicality, and necessity for, real-time interaction is often overstated. More often than not the ability to share information asynchronously is more than adequate. Real-time interaction is most often limited to team alignment, information sharing, or status reporting rather than interactive design work.
Once again the challenge is to match the tools and methods to the real needs of the organization. Collaboration should be supported by a toolbox of available options rather than a single application to be deployed. Effective collaboration requires a thorough understanding of the capabilities and objectives of the collaborators. Trying to collaborate with participants of sharply different capabilities and objectives will lead to user frustration and drive unnecessary cost.
8. Integratied applications or Best of BreedThis is a decision which may already have been made for you. Organizations typically have a preference for using commercial off-the-shelf (COTS) IT solutions or building their own applications. Valid cases can be made for either approach but it is critical that the PLM solution be consistent with your organizations preference.
The COTS approach raises the question of integrated systems (e.g. SAP) or a collection best of breed applications. Once again a valid case can be made for either approach and understanding your organizations preference, and therefore support abilities, must be understood and respected when planning for PLM deployment.
On this item, going with the flow (organizational preferences) is usually the best choice.
9. Organizational readiness - matching vision and realityWhen organizations have a vision for their “engineering” environment it is most often fostered, or at least influenced, by the latest sales pitch, competitor envy, or the latest consultant whitepaper on the topic. All too often the gap between the vision of what is possible and the reality of what is currently achievable is not technological, it’s organizational.
Engineering organizations have had access to and 3D design tools and have been designing in 3D for years but we’ve only scratched the surface in most cases when it comes to exploiting the resulting models. Today 3D is everywhere – TV, Movies, Gaming, and yet most of our business processes still rely on 2D representations and textual descriptions of our products. The adoption of 3D in non-engineering functions will grow rapidly as new generations of 3D savvy employees enter the workforce.
As we move to product-centric PLM tools the usefulness of 3D based definition for our products will become more self-evident. After all, there’s little need for a three dimensional representation of a document. Technologies like 3DPDF makes using and viewing 3D models available to almost anyone with a computer. These 3D graphics can be used directly or imbedded in other documents like manufacturing work instructions or maintenance manuals.
We need to exploit the significant effort put into developing 3D models in design. Model fidelity and content must enhance to support processes beyond engineering. 3D models can then be used to improve all aspects of our businesses from sales and marketing to field support personnel. A picture truly can be worth a thousand words when used to communicate a difficult concept or clarify a tricky procedure. These models can support our ability to simulate manufacturing and maintenance activities or walk a potential customer through a simulation of their product. We will be able to replace pages of text instructions with graphic rich (including imbedded 3D graphics) work aids.
Exploitation of 3D model definitions will require more content than currently required by engineering but the benefits to the organization from reuse should more than compensate.
In Conclusion
We hope the items presented here were helpful to you. This is certainly not an exhaustive list of items to be considered but if this information makes you think about, and be more engaged in, your organizations’ PLM activities then we’ve succeeded. The introduction of PLM technologies and the associated process and organizational changes that result is not easy. The benefits however can be broad and far-reaching for your organization.
i look forward to your comments and feedback on future topics.
For more information, or help with a specific PLM topic you can contact me through : http://gblouin.blogspot.com
One leading example is the vision of a completely digital product definition based on highly accurate and detailed 3-dimensional models used consistently from concept through support. This is currently technically possible. Despite the availability of the required technologies few organizations have been able achieve this vision. Organizational readiness is a lowest common denominator, or some would say a bottleneck constraint, problem. Until the participating design, supply, production, and support chain processes are re-engineered, personnel trained, and infrastructure installed will we be unable to achieve the full benefits of this vision. We can make incremental improvements but the full benefits will be throttled by processes un ready to utilize the new definition. Technology road-mapping is a proven methodology for achieving a desired future state but it must be based on the shared vision of authors and consumers of product data to be successful.
10. Just how much of htis 3D stuff do I need?
No comments:
Post a Comment