Working solutions to assist global product development ...

Martin Ohly

I have worked now for over 30 years in engineering, software development and system deployment, mostly for technical applications and 13 years in the realm of PDM and PLM (including that from MatrixOne, SAP, Siemens PLM/UGS and Dassault Systems) and been involved in some way with almost all industry sectors. At gedas starting in 1996 I worked closely with MatrixOne developing and supporting integrations. I spent a period with the professional services division at Siemens PLM working as IT architect in the worldwide rollout of Teamcenter Engineering at one of the worlds largest companies. Currently I work at Bombardier Transportation in their SAP global competency center, concentrating on Engineering/PDM/PLM applications is SAP and their integration in the manufacturing and logistics processes. Some of the companies where I have been involved in PDM/PLM initiatives to different extents include VW & Audi, IVECO, Johnson Controls, Textron-Kautex, Arvin Meritor, Valeo, Faurecia, John Deere, Proctor&Gamble, Kion Group (Linde Materials Handling), Siemens Transportation Systems, Hallibuton, Heller, Siemens-Dematic, Nokia, 3-COM, Alcatel, Quante (3M), Apple, Elsag, Elettronica, entegris, Avaya, Lucent, Tyco, RIM, ATI and ETAS. Hence, good coverage of automotive, electronics, telecomms and other manufacturing industries.

My interests and skills lie mostly in the implementation of PLM - in the provision of effective, truely useful, usable, performant, reliable and working systems. What I wish to provide here over a period of time is a summary of ideas of how to achieve effective global PLM implementation: through use of PLM Patterns, following a topdown strategic approach coupled with a parallel Pragmatic or Grassroots bottomup approach to PLM. It is a summary of things that I have been thinking about over this time. These are ideas resulting from running actual systems, the many projects, pre-sales work, presentations to prospects and the many discussions with colleagues, partners and most all from my customers. Of course, the ideas presented here have been stripped of confidential information - that concerning details of PLM systems or customer projects obtained in the context of work at past or present employers and partners.

What I have noted over these years - the many companies and projects - is almost always a strange sense of déjà vu. In each project it seems that a new set of bright young consultants (Jugendforscht) are trying desperately to re-invent what has been painfully tried and proven by their forefathers in EDM, PDM, PLM or whatevever it has been called. At some stage I would like to present what I consider the fundemental issues of PLM that seem to occur in most projects. There is no unique or best solution to each issue. The pros and cons needed to be weighed up. However, having a catalogue of known PLM solution patterns - together with real case-studies and retrospective discussion of benefits and pitfalls - would definitely help to reduce unnecessary waste of time and hopefully improve the chances of success for future PLM initiatives. Ideally I would like to put this together in the form of a Wiki such as "97 Things Every PLM Solution Architect should know". Maybe I'll get around to this in the new year - or the next.

Some of the quotations and illustrations shown here have been borrowed from presentations available around the net. I am a firm believer in learning from what others have done - there are many clever people around and many good well tried ideas. Please let me know if you are the owner and either wish to be further accredited or wish these references to be removed. Better still, if you are willing to share any fitting presentation or if you have useful comments please also let me know. Sharing practical examples of successful implementation would certainly help others: case studies, best practises - showing just what PLM could really be.

There may be contradictions in my text - the real-life worlds of corporate IT and product development are truely complex and every day brings to light some new aspect or point of view - however, one day I may get to iron out the text and come to a final version.

And why isn't this a blog ? Simply because Jos, Oleg and Jim do that much better than I ever could !

Current books ...

January 2010 - I am currently reading (or have just read!) the following books - all of which are extremely interesting and to be highly recommended to anyone serious to understanding product development ...

  • August-Wilhelm Scheer, Manfred Boczanski, Michael Muth, Willi-Gerd Schmitz, Uwe Segelbacher: Prozessorientiertes Product Lifecycle Management A good overview of complete PLM processes (not just CAD oriented) as supported using SAP software. The authors all appear to be or have been consultants from IDS Scheer - the company founded by Scheer - which is most famous for the ARIS process modelling software - and hence the process bias of this text. Good case-studies - but as often these are treated in insufficient depth (see other books below).
  • Ulrich Sendler: Das PLM-Kompendium: Referenzbuch des Produktlebenszyklus Managements. Unfortunately only in German. A very good survey about PLM - covering industrial experiences, software products and academic research. The only critic is that I would have wished a bit more depth in the reports of industrial experience. As I know this is probably difficult to attain - companies are extremely wary about giving out too many details of PLM and product development strategies - or experiences, whether positive or negative.
  • Hartmut Esslinger: A Fine Line: How Design Strategies Are Shaping the Future of Business. A different vew of product development - from the founder of Frog Design - the company famous for the design of products such as Apple computers, Lufthansa airline firstclass interiors, SAP's newer GUIs etc. Not yet well into this book - hence too early to return a verdict !
  • Martin Eigner, Ralph Stelzer: Product Lifecycle Management: Ein Leitfaden für Product Development und Life Cycle Management. Eigner is the German Pabst of EDM, PDM and PLM. From his company Eigner & Partner, his innovative ideas and the resulting leading EDM / PDM software he has defined more than any other the German way of using IT to aid product develpment. As with German Engineering in general there is a welcome attention to the details - real approaches are described. Not the helicopter/powerpoint views of PLM that dominate other texts. A definite read - but unfortunately only available in German.
  • Henry Petroski: Success through Failure: The Paradox of Design As an engineer at heart - this provided for me a confirmation of my belief in the study of failure (see also the section under software development, concerned with software project failure). This main theme followed in this book (as in the title) is also echoed in the next book.
  • Donald G.Reinertsen: Managing the Design Factory - A product developer's toolkit Fantastic book - one of my all time favorites: There are no best practices - the focus of this book is on tools, not rules. Includes very interesting application of queueing theory and information theory (it's all about information) and system theory (just add feedback) to the subject of product development. The chapter on design of experiments during product development illustrates this: we cannot maximize information generation by maximizing the success rate of a test. We maximize information content of the test by approaching a 50 percent failure rate. Our testing processes need to have an adequate failutre rate to generate sufficient information. Reinertsen goes on to assess organization forms, design processes and product architecture, tools, process metrics, risk management in an extremely intelligent and illuminating manner.
  • Vincent C. Guess: CMII for Business Process Infrastructure. Available online from GfKM - CMII Europe. Essential for anyone serious about Configuration Management. I use this constantly as a reference. Download and refer also to Standard CMII-100B - CMII Standard for Enterprise CM and Integrated Process Excellence

Topics I'm working on, thinking about and would also like to elaborate is on - any help or comments welcome !

  • Communication of changes engineering --> manufacturing - issues particlar to global vs. local engineering
  • EBOM / MBOM synchronization / reconcilliation
  • Impact of changes, dealing with changes, minimising impact of changes
  • Form, fit and function revisited - revisions held in inventory ?
  • Reduce IT system interfaces. One big system: good or bad ?
  • Patterns of successful collaboration and data exchange
  • Sub-contracting to big IT consultancies/system integrators
    • False economies: contract based on lowest day-rate - can lead to more expensive in the long term
    • Consultancies that organize you: make endless Excel sheets, task lists, chase you up, make problems but rarely themselves solve anything
  • Outsourcing PDM/PLM: can someone tell me where the benefits are ?
  • Can we find a correlation between companies with excellent products and their PLM strategy/implementation ?

Initial structuring of personal thoughts about Global PLM ...

The details may be as yet missing - but I hope the links to the works of others, the experiences of others helps you in your enterprise with Global PLM. Any feedback is more than welcome - please send to and I will endeavor to reply.

  • What is PLM ? Aren't we doing that anyway ?

    • There are many definitions available - some of these are listed below. I'm still not sure whether anyone is really doing PLM, or if we are all in fact doing PDM, or whether there can be ever be a PLM software product. At the end of the day I do not think it really matters and from my point of view, regardless of how sophisticated the IT approach is, we in the IT departments of all enterprises that produce tangible products are all doing it.

    • Wikipedia:Product lifecycle management (PLM) is the process of managing the entire lifecycle of a product from its conception, through design and manufacture, to service and disposal. It is one of the four cornerstones of a corporation's information technology structure. All companies need to manage communications and information with their customers (CRM-Customer Relationship Management) and their suppliers (SCM-Supply Chain Management) and the resources within the enterprise (ERP-Enterprise Resource Planning). In addition, manufacturing engineering companies must also develop, describe, manage and communicate information about their products (PDM).
    • CIMdata
      • A strategic business approach that applies a consistent set of business solutions that support the collaborative creation, management, dissemination, and use of product definition information
      • Supporting the extended enterprise (customers, design and supply partners, etc.)
      • Spanning from concept to end of life of a product or plant
      • Integrating people, processes, business systems, and information
    • John Stark
    • Siemens PLM: At Siemens PLM Software, we view PLM as at once an information strategy, an enterprise strategy and ultimately a transformational business strategy. We see it as a comprehensive approach to innovation built on enterprise-wide access to a common repository of product information and processes.
    • Dassault Systems: A business strategy that helps companies share product data, apply common processes, and leverage corporate knowledge for the development of products from conception to retirement, across the extended enterprise. By including all actors (company departments, business partners, suppliers, OEM, and customers), PLM enables this entire network to operate as a single entity to conceptualize, design, build, and support products.

    Global PLM

    Global PLM

    Nokia PLM

    Nokia PLM

    Global PLM

    Perhaps to summarize: PLM that we are all doing and have been doing for a long time, is all about providing system support for the optimal development of products; ensuring the fastest time to market, the lowest development and production costs and the highest quality. PLM encompasses:

    • Products - the support for the development of products - quite simply: most companies exist because of their products.
    • People - companies and hence products only exist through the efforts of their people
    • Processes - processes are the necessary evil, the contraint to artistic talent, that are required to restrict the effects of chaos, to ensure dependable, repeatable results
    • Data, data and data - the core of a PLM strategy - consistent, current, trustworthy, structured information concerning the product, providing the basis for configuration management, a central point to access to all sorts of useful information such as product status, costs, breakdown of components, digital respresentations for all sorts of analyses, documentation, project progress, ...

    Perhaps the greatest challenge with PLM is that it has the tendancy to cover or touch everything a company does. It is unlikely that any one person will understand in sufficient depth the whole picture - to define and drive the strategic vision. It is even less likely that any one person will understand not only the business processes to the required level of detail but also the technical challenges that are to be expected in any realistic PLM endeavor.

    Global PLM

    Global PLM

    Global PLM

  • Challenges of PLM and relation to MRP, ERP, CRM, EAM, MES and whatever else exists ...

    • Each industry has it's particular requirement for PLM: depending on whether products are mass produced; engineered to order (ETO); are composed of relatively few components; are highly complex; whether stringent configuration management is required (aerospace, defense); whether variant configuration makes sense; whether there is a prototype phase in product development; whether DMU can be used; whether concurrent engineering or even concurrent engineering, planning and manufacturing must be supported. Certain challenges for PLM would however apply regardless of industry sector - for example the need to support initiatives for reducing product development and manufacturing costs - reducing time-to-market. Such initiatives may be supported by PLM through global master data definition, efficient (variant) structure management, global change processes, digital prototyping, enhanced collaboration between engineering, planning and manufacturing. Hence to be effective - to provide effective support - PLM must touch on the domain of many other systems - be they ERP, CRM, EAM, MES or other. This leads to the immediate issues:

    • Which processes, data, functionality belongs in which system ?
    • The eternal question + argument: One big box or best-of-breed systems and interfaces ?
    • Clear boundaries between systems and concepts ?
    • Can or should PLM be incorporated in ERP ?
    • Can or should classical ERP functionality be incorporated in PLM ?

  • What is Global PLM ... Think Globally, Act Locally - applied to PLM

    • From my point fo view this quite simply concerns the application of PLM (strategies & technologies) to the optimal support of product development in a global setting - if fact almost all larger companies, and even many medium size enterprises either already have a global PLM or are in desperate need of global PLM - as stategy, as system, and as lived in every aspect of the product life-cycle - starting with development. PLM for modern patchwork enterprises - the glue that holds their products, their daily work together. However, there remains a critical question to answer regarding global PLM: does global PLM mean global process definitions, a global system, centralized support ? This can work well for some enterprises - but not for all.

    Global PLM

  • Real-life example of prime concerns, requirements, strategies for IT and Global PLM

    • Notes taken from the presentation by Guus Dekkers, at the time CIO at Continental Automotive at the Pro STEP iViP Symposium, in Berlin, April 2008.

    • In summary:
      • current: only a few tools match
      • focus rather on adjusting data as this pays quicker
      • master data needs to be standardized across disciplines, divisions and business units
      • processes related to connected ERP systems need to be standardized
      • alignment of SAP represents a larger challenge, taking time to resolve
    • The "take aways" as summarized by Guus - I understand all of these bullets - even if they are easy to quote, but often difficult to execute:
      • Speed is key
      • Bringing value for the new organization imposes that your organization is ready to take that challenge – A quick full integration of the IT-Teams is therefore a must
      • Stop the "religious wars" on key-toolsets quickly and decide !
      • Cost to the organization not taking a decision is much higher then eventually having to correct a mistake later on.
      • Do not start architecting 2-years+ monster-projects, but decompose and focus on quick deliverables – Rather imperfect intermediate steps providing value
      • Data, Data, Data !

    A couple of comments. Firstly a small correction - the subtle but all too important distinction between information and data. What is important is information - not redundant data - and perhaps this is one of the most important aims of PLM is too ensure we present the required information. Secondly, the pragmatic realization that the IT landscape of most medium/large global enterprises have developed in time, through mergers and aquisitions into a complex web of legacy applications. Often clean cuts are not made and old systems/implementations live on even following the implementation of global templates and systems to replace these. There is always the argument coming from business (by which I mean here the departments/divisions in the enterprise that use the systems) that they depend on their system and a change will cause delays in their new project, cause loss in revenue, etc etc and that anyway the prosposed global replacement is a compromise and they will miss important functionality - that strangely only they are the ones that need it. Hence, I guess Gus faced these issues as CIO at Continental. Many ERP/SAP systems, similar business units, but every division/plant customizing and using the same system in different ways.

  • A Starting Point for Global PLM: Just Simplify IT !

    • I have seen so many companies, so many IT strategies and PLM initiatives and perhaps one conclusion that seems to universally hold is: Simplify IT ! What I mean is nothing less than the same old engineering wisdom of "less is more" or "keep it simple". For some reason in the development of IT strategies and in particular for PLM - there is a tendancy to forget this age old advice. There is often some reason which causes the failure of the most logical IT stragegy - the one that would have resulted in the the cleanest architecture, the most efficient of applications, the best support for the business needs. Politics often play a role here: the wish not to offend important business sponsors; the department or division heads needing to maintain their empires.

    Global PLM

    Global PLM

  • Core building blocks/architecture for a Global PLM stragegy - services for:

    • These may sound relatively basic low level requirements, but in my opinion if you are starting off without any of the following in place, you are heading for difficulties. Perhaps it is necessary to understand the diverging, contradictory requirements of modern day industrial design, development and manufacturing complexes. On the one side is the need for local automonony, for competition between sites, countries - each being their own profit center and each wishing to produce the next contract - to ensure the guarantee of local jobs in hard times. On the other side is the need for efficiency, avoid duplicating efforts, re-use what you already have. For me the following are essential centralized services. If you cannot agree on centralized control of the following, then global PLM is not for you:

    • Global part numbering service
    • Global management of corporate standards, standard parts, standardized part descriptions in multi-languages
    • Support for global project / program management, controlling and metrics
    • Access to current synchronized CAD, viewing (JT) data, drawings - avoiding replication, copying
    • Efficient support of global change processes

  • How to achieve Global PLM ...

    • This leads me to the idea of Pragmatic, Grassroots PLM
      • Bottomup pragmatic, grassroots approach vs. big consultancy, mega initiative, 100 millions $
      • Tools based, extendable, adaptable vs. rigid mega-system
      • Support users with no more than enough workflow process contraint, be easy to use, non-intrusive
    • Skills required: more than a basic understanding of the business processes and a mastery of the technology to be used
    • Deploy proven technology that works
    • ...

  • Perfect PLM, the perfect PLM tool ...

    • Providing optimal support for consistent product development ...
    • Flexibility, adaptability, extendability ...
    • Usability ...
    • Functionality ...

  • Supporting Tools, or tools that support ...

    • Who bemoaned that if only the maximum size of an MS-Excel spreadsheet was not limited to 256 columns and 65536 rows, then there would be no need for PLM ?
    • What is wrong with Excel based product structure, Lotus-Notes ECR/ECO applications, Sharepoint collaboration ?
    • ...

    PLM Excel

  • Why is PLM so difficult ...

    • True PLM needs detailed considered of not only the needs to ensure efficient product devlopment - but also needs to consider the requirements for planning, manufacturing, quality assurance, logistics, supply chain management, product servicing. It is very unlikely that one person can hope to understand in the required detail all the business processes involved or that concensus throughout the enterprise on such an endeavor can be easily achieved.

    • Fundemental issues - detailed below
    • Integration between tools
    • Software product quality, performance, stability
    • Ease of use / Usability
    • End-user resistance: "this tool only means more work for me - what is my benefit ..."
    • Software product adaptability
    • NIH - the "not invented here" syndrom
    • Internal politics / conflict of interests / internal empires
    • Costs / Unclear ROI
    • Availability of internal resources (persons in company who understand what is actually required, what will work)
    • ...

  • Why do PLM projects fail, underperform or succeed ...

    • This is an extremely interesting issue - my very rough and prejudiced estimate is that 50% of all PDM/PLM projects seriously under achieve, or fail completely. Of course, this depends on your definition of failure or under achievement - but I do have the feeling that PDM/PLM projects have a much higher failure rate than projects in other IT areas. The general reasons for project failure have been discussed in many other places. There are several possible reasons for the susceptibility of PDM/PLM projects.

    • Beware of the research project. Beware of too many Phds. If I can't understand it, what chance have the end-users ?
    • Projects succeed through hard work and mutual trust by dedicated, competent and communitative teams (that include the customer, the consultants, the implementer, the SW vendor)
    • Projects rarely fail through technological reasons, although this is often the excuse
    • But in spite of this - do not accept low quality S/W or bad performance
    • The problem of understanding the requirements when these are not defined
    • Who controls the PLM initiative: does it come from IT, does it come the departments, does it come from document control, ...
    • The perils or success factor of offshore implementation
    • PLM lives through people - must support the end-users
    • Leveraging your investment - make the most out of the system !
    • Multiple tools, tool/system ownership
    • Solution complexity - too many clever people designing complex automation for users who do not really want to have another system automating their work
    • ...

  • From Design to Planning, Manufacturing, Logistics and Customer Service ...

    • ...

  • Reaching the Limits of IT in Product Development ...

    • Pertinant comment from Kenneth B. Amann Airbus 380 lessons While there will be some who say that having all designers/engineers use the same release of the design tools, this is not the core problem. Using different tools, or different releases of the same tool, is not the problem -- many very complex products have been successfully designed and produced using diverse tool suites. Failure to properly collaborate during the design process and to identify and address design issues early is the real issue.

  • Abstraction is a double-edged sword ...

    • Abstraction is a useful tool in all areas of IT - not having to always deal with the sordid details helps us to efficiently focus on the particular areas of interest. But be aware, abstraction is a double-edged sword. Ignore the details at your own peril. It is surprising but of all the companies that I have observed, those that are most successful at getting the most from their PLM strategy/implementation usually have one or two persons who really understand what they are doing at all levels. They are absolute masters of their tools. They are not afraid of the technology. They use Perl, Excel, Java etc whereever appropriate. They deploy open source - Tomcat, Apache etc. Their applications runs well and truely support the business needs. This is the way to work. The opposite case are companies with excessive layers of management and change control boards - layers of people who neither understand the needs of their business, nor command an understanding of the tools, the systems. These are people too frighted to change, to adapt the software and who hide behind consultants, best practices. These are people who rarely take the risks and are quick to place the blame when things go wrong - which they will.

    Process Levels

  • Focus of PDM/PLM (everyone has a different focus, different needs)

    • BOM / product structures / variant management / configuration management
    • 3D - CAD process oriented / DMU / ... / design quality assurance
    • 2D Drawing management / release processes
    • Engineering change processes
    • Manufacturing processes
    • After sales / service processes
    • Supplier management processes
    • ...

  • Requirements of different Industry Segments and Manufacturing Models

    • Automotive OEM
    • Automotive Supplier
    • Electronics / Hightech
    • Mechanical Equipment / Plants
    • Telecommunications
    • Consumer goods / Apparel
    • Process industries
    • ...
    • Contract development - Engineer-To-Order (ETO) is a manufacturing philosophy whereby finished goods are built to unique customer specifications. Assemblies and raw materials may be stocked but are not assembled into the finished good until a customer order is received and the part is designed. Engineer To Order products may require a unique set of item numbers, bills of material, and routings—and are typically complex with long lead times. Customers are heavily involved throughout the entire design and manufacturing process for engineer to order products.
    • Mass production (flow production, repetitive flow production, series production, or serial production)
    • Fast Moving Consumer Goods (FMCG), Fast Moving Consumer Electronics
    • Serial manufacture with limited run
    • High variety manufacturing, Highly configured product
      • Build to order
      • Assemble to order
      • Configure-To-Order (CTO) is a method of manufacturing which allows you, or your customer, to select a base product and configure all the variable parameters associated with that product. Based on the configurable items on each quote or order, Configure-To-Order (CTO) systems typically generate the manufacturing routing and/or bill of materials based on features and options such as color, size, etc.
      • ...

      ETO
      Reference: Donald H.Sheldon: World Class Master Scheduling, Best Practices and Lean Six Sigma Continuous Improvement

    • Required Functionality / Support from PLM:
      • Customer interaction in PLM process - e.g. Mass serial manufacture vs. Contract based/design-to-order (contract or project structured approach)
      • Customer involvement in contract, release + change process
      • Supplier interaction in PLM processes
      • ...
    • Impacts of Organizational Models:
      • Global products, global manufacturing
      • Distributed development
      • Contract or program oriented product development
      • Does collaboration really take place / simultaneous engineering teams
      • The needs for secrecy / security in product development / protection of intellectual property
      • ERP/Manufacturing model: centralized vs. distributed

  • Which of our questions does PLM need to be able to answer ? What does PLM need to ensure for us ...

    • Where are we, what is going on, when will it be finished, what do we need to do ?
    • What are the impacts, what will it cost ?
    • Will it fit, will it work ?
    • ...

    Product development process

  • Product Development Processes / Collaboration / The extended enterprise

    • Key to optimal product development is collaboration. Collaboration between engineering teams, with planning and manufacturing, with the customer, with suppliers. What is the reality of product development ? In the 90's I worked extensively on something called CSCW - "computer supported cooperative work" - a term that we no longer hear much about. I remember a quotation from then that damped down the naive enthusiasms of the computer scientists and still has relevance now: "Fundemental and subtle social processes in work strongly influence the ways in which CSCW applications are adopted, used, and influence subsequent work [...] In practice, many working relationships can be multivalent and mix elements of cooperation, conflict, convivality, competition, collaboration, commitment, caution, control, coercion, coordination and combat" Rob Kling, CACM Vol34, No12, December 1991.

    Collaboration
    Reference: Ford: Collaborating for Superior Products

    • About optimal product development
      • Supporting diverse teams
      • Simple tools: conferencing, Wiki, instant messaging, Web2.0
      • Front loading design
      • Ideas learned from software product development
        • Simultaneous engineering
        • Release processes / Daily build
        • Object-oriented influences in CAD methodologies
      • Collaboration and extended enterprise
      • Patterns for optimal supplier integration / collaboration
    • Structuring Product Development: Program / Project Management
      • Program / contract based development
      • Development processes in automotive industry; hightech; ...
      • Product vs project engineering
      • CMMI type approaches to development
      • Product costing / cost management
      • Tracking / Issue management / Development Topics
      • Metrics / Statistics / Reports
      • Team visibility / Team specific access rights
      • Visibility of project status - where are we ?
      • ...
    • Donald G.Reinertsen in "Managing the Design Factory - A product developer's toolkit":
      • Product Achitecture: The Invisible Design ... In many ways the importance of product architecture is a well kept secret ... There are three key underlying factors that we exploit when we try to use architecture to achieve our economic objectives. First we must make decisions with regard to how modular to make the product. second we must partition the design to control the impact of variability. thirs we need to manage the internal interfaces of the design ...
      • Get the Product Specification Right ...
      • Use the Right Tools ... Technology impacts development processes in three ways: it accelerates information flows, it improves productivity, and it reduces delays ...
      • Measure the Right Things ... Control and reduction of variability are only valuable if they impact our economics ... If our business-level analysis suggests that most of the economic leverage is in schedule, we should focus our control effort on schedule; if we discover most of the economic leverage is in cost, we should focus on cost. We can only determine where to focus our control effort by finding out what parameters most influence the economics of the project.
      • Manage Uncertainty and Risk ...
        •

    Product development process

  • Requirements Management

    • ...

  • Configuration Management


    • Reference presentation: Effective Configuration Management through Standardisation, Matthias HOFMANN CIMPA, Frank MÜLLER EADS

    A core concern in product development - refer to the classic reference from Vincent C. Guess: CMII for Business Process Infrastructure:

    Configuration management (CM) is the process of managing an organization's products, facilities and processes by managing their requirements, including changes, and assuring that results conform in each case. CMII expands the scope of CM to encompass all information that could impact safety, quality, schedule, cost, profit or the environment. CMII shifts the emphasis of CM to

    • (1) accomodating change,
    • (2) accommodating the reuse of standards and best practices,
    • (3) assuring that all requirements remain clear, concise and valid,
    • (4) communicating (1), (2) and (3) to each user promptly and precisely and
    • (5) assuring conformance in each case. Process improvement, per CMII, is measured by ability to "change faster and/or document better."

  • Architecting products, Product Structures and the Management of Complexity

    • Structuring of products is central to PLM. A successful PLM tool must manage effectively the true complexity of product structures. It must effectively represent different product variants; different development maturities (prototype, milestone X etc); different release states: latest working, latest released; maintain history and baselines. It must provide this all optimally in a user interface with ease of navigation and performance of exploding the structure, and ideally - like Teamcenter Engineering - visualize the selected product configuration.

    • Part-centricity: Towards a digital product representation - the end of drawings
    • Product structure or BOM ?
    • Parts or Documents: do we need documents to describe a product ? what is the difference ? do we need to differentiate ?
    • Part / Document relations (N:M relations)
    • Document (CAD) structures vs. Part structures
    • What types of structures and BOMs - aims + strategies of structuring
    • Organizing structures and products, product lines, utilization of architectures, platform or modularization
    • Functional vs. WBS structural breakdown
    • Maturity of structures: early conceptional designs, prototypes, detailed design, production
    • Early BOM / Front Loading
    • Costing
    • Reporting
    • Process oriented / manufacturing
    • Derivation of MBOMs / colored MBOMs
    • Complex products: mechanical, electronic, software: can these be brought together ?
    • Reaching a single product structure
    • Complexity management
    • Product variance / Variant Configuration
    • Verwendungsstelle
    • ...

  • Variant Configuration

    • Variant Management
    Reference presentation: Sobhan Vemulapalli of Radinnova Inc. to be found at SAP Configuration Workgroup

    Variant Management
    Einsatz der VC in der Modellierung und Pflege einer komplexen Produktstruktur Integrierte Softwarelösung für Vertrieb und Konstruktion, Lech Kochanowski, Krones, 2009 European CWG Conference, Berlin, 20-22 April 2009 SAP Configuration Workgroup

  • EBOM, MBOM, Structures + Reconciliation of differences

    • Requirements for different structures
    • One global structure
    • EBOM / MBOM Reconciliation
    • Communication / visibility of changes
    • Automation of structure synchronization (Fundemental rule: you can only automate what is automatable)
    • Data consistency - of structures, meta data and files - across multiple systems - guaranteeing process safety
    • Prozesssicherheit
    • ...


    Reference presentation: ProSTEP iViP Symposium 2009: Download of presentations Successful Applied Structure Mapping Based on Semantic Networks
    Andrea Denger, The Virtual Vehicle Competence Center Manfred Pircher, MAGNA STEYR FahrzeugtechnikAG & Co KG Dan Brisson, MecanicaSolutions Inc.

  • Change Management / Release processes

    • Changes are inevitable and almost all changes cost money - but through the support of global change processes, and through the improved visibility and communication of change information the necessity and impacts of changes can be limited.

    • Changes cost money: the biggest challenge - reduce changes
    • Rigid+complex or flexible+minimal change process: finding the right balance between agileness + need to control and document
    • Change strategies: form, fit, function vs. change the screw and create new revision of the car
    • Relation of supplier + customer in change process
    • Small/cosmetic changes
    • Effectivity / Releases - date, serial effectivity
    • Tracability / Document Control
    • Tracability and part serialization
    • Form, fit and function
    • Impact of changes: modify the screw and rev the end product ?
    • Release each part-usage
    • Visibility of changes
    • Global Workflow / SOA
    • KPIs of engineering/change processes
    • Early Visibility - to purchasing, production, ... of proposed changes
    • BPM - business process monitoring
    • ...

    ECR/ECO

    Effectivity
    Reference presentation by Donald N. Frank: Configuration Management in Aerospace and Defense

  • Product Documentation

    • Generation of documentation; service manuals; spare parts catalogues
    • Language variants
    • ...

  • Logistics and Production Planning - Relation to ERP/MRP/SCM

    • ...

  • Change Processes in Manufacturing

    • ...

  • After Sales / Service / Tracability / Serialization / Relation to EAM - Enterprise Asset Management

    • ...

  • Fundemental Restrictions / Tradeoffs in PLM

    • Process Integration: impedance mismatch between design/engineering and production/logistics
    • Limits of complexity of application
    • Limits of workflow automation
    • Flexibility vs. control - placing contstraints on the "artistic" flexibility of designers - forcing them to conform to clumsly and rigid processes vs. total chaos - nobody knows what changes have been done for what reason and what changes are incorporated in this revision of the product
    • ...

  • Strategies for re-use

    • Re-use and design to order - mutually exclusive ?
    • Serial effectivity vs. re-use/platform strategy - mutually exclusive ?
    • Carry over parts - the dilemas facing re-use / NIH syndrom / change costs
    • Platform / module product decomposition
    • ...

  • CAD Data Management / the core of PDM/PLM ? (excluding process industries)

    • The problems with CAD tools ...
    • The problems with integrating CAD tools ...
    • The problems with Web architectures
    • CAD methodologies
    • Digital Mockup
    • Supporting the digital factory
    • Data transfer (supplier integration)
    • Standards
    • Data conversion, neutral formats, PDF, TIF, stamping, 3D viewing formats, JT, distributed conversion services
    • ...


    Reference presentation: ProSTEP iViP Symposium 2009: Download of presentations Dr.Andreas Queckenberg, Rollout of a JT Based Process Chain

  • Implementation project strategies and methodologies

    • Choice of implementation partner: software supplier, large IT consultancies, specialized PLM consultants, in-house consultants
    • For and against using large IT consultancies
    • For and against using professional services of the software supplier
    • Developing a roadmap
    • ROI argumements & metrics
    • Contractural options - fixed price, time & materials, mixed forms
    • Definition of scope
    • Analysis/Specification/Deployment Methodologies
    • Gap analysis
    • SAP ASAP based: Business Blueprint, Quality Checklist, ...
    • Use-case focused approaches
    • Project documentation / shares / sharepoint
    • Analysis/Paralysis
    • Acceptance/sign-off
    • Handling issues / issues lists / prioritizing
    • Training / key-users / train-the-trainer
    • Transition to maintenance
    • ...

  • Implementation Methodologies / Issues

    • Top down (from upper management) or bottom up (from grass roots)
    • Bigbang or incremental/organic growth
    • Invest upfront in extendability vs. deadend solution
    • Intercultural issues in global projects
    • Project size: law of diminishing returns
    • Optimal deployment: The use of checklists
    • "Churning" - rapid implementation cycles - quick results
    • See section development
    • ...

  • Models / Methodologies specifically for PLM


    • Reference presentation: ProSTEP iViP Symposium 2009: Download of presentations Claus Thiede, Continental


    Reference presentation: Meier, Bosch

  • Implementation of PLM: Architectures

    • Solution Architecture: role of the solution architect - the success of your implementation will primarily lie with the skills of your solution architect
    • Technical Architectures: IT Architecture / Software Architecture

  • For and against ...

    • I have worked extensively with Matrix - from version4 till 11; with SAP from 3.0E till ECC6.0; with IMAN, Teamenter Eng, Teamcenter Unified Architecture; with VPM. None of these tools/software systems is perfect - each has is strengths and weaknesses, its place in the world. Unfortunately I have not worked with Windchill, Agile or Smarteam. Perhaps someone can help here and provide the strengths and weaknesses as based on years of exerience.

  • Criteria for Tools ...

    • Performance, stability !
    • ...

    Beiersdorf SAP

  • Technical Architectures

    • Web architectures
    • Fat vs. thin client
    • Central database vs. autonomous locations
    • Enterprise PLM backbone + distrubuted TDMs vs. one PLM
    • Decoupling: one big system - all in one box, or decouple and allow flexibity
    • TDM, PLM, ERP all in one box: tradeoffs ... Issues with S/W release cycles & changing requirements / flexibility / compromised solution
    • Tool supported (Excel, ...)
    • File server strategies (for CAD - providing large scale, high available, fast access, fast recovery, dependable and secure storage at reasonable cost)
    • ...

  • Technical Issues / Integration

    • Issues with Integration
    • Integration and SOA
    • Impedence mismatch between systems e.g. ...
    • See section soa
    • You can only automate the automatable, the information has to come from somewhere
    • Issues concerned with usability
    • System Development
    • Deployment, Rollout strategies
    • System Performance
    • System Monitoring
    • ...

    Process coupling

    Process coupling

    Technical Architecture

    Technical Architecture

  • Technical Implementation approaches

    • Toolbox based vs. out-of-the-box (one box fits all)
    • PLM platform approach
    • Supporting users, integrating popular tools
    • Tool/process integration: deep "online" integration vs. import/export interfaces
    • The power of automation / the usefulness of "small languages"
    • Role of MS-Excel, MS-Access, Sharepoint, Lotus Notes databases + workflows
    • Role instant messaging, app sharing, blogs, wikis, etc in product development
    • ...

  • Product data exchange and related standards

    • STEP, ISO 10303 AP 214 ...
    • PDX ...
    • ...

    Boeing Standards

    Boeing Standards

    Boeing Standards

  • Security / Identity management

    • Single sign-on
    • Strong authentication
    • Reverse proxies (WebSEAL, SiteMinder, ...)
    • ...

  • Access rights / roles

    • Project based access rights
    • Secret / invisible data
    • ...

  • System modelling / description

    • Data-modelling approach
    • Use-case oriented approach
    • Process modelling
    • ...

  • Rollout Strategies

    • Bigbang vs. staged
    • Phased in rollout: Ongoing synchronization of data between systems
    • ...

  • Data Migration

    • Tools / Power of script languages
    • My rule of thumb: plan for at least three attempts
    • ...

  • System operations:

    • ITIL
    • System administration, monitoring
      • ...
    • System performance
      • ...
    • System maintenance
      • ...
    • Disaster recovery strategies
      • ...
    • Archiving / Data retention
      • Legal requirements
      • Against offline media and HSM - hierarchical storage mechanisms
      • Moore's law - keep everything online - just copy every 2 - 4 years
      • ...

  • IT Strategies:

    • Refer to strategy section ...

    • IT strategy: patchwork IT (minimal investment - just keep the things going) vs. strategic harmonization
    • IT budgets / PLM proportion
    • IT control / governance - who has the power / who controls the budget
    • IT architectural complexity vs simplification
    • Change processes in IT
    • Decision processes in IT
    • For and against outsourcing
    • Levels of outsourcing; true costs of outsourcing
    • Centralized IT - or local IT that understands local needs ?
    • Centralized standards / architectures / frameworks / interfaces / process definitions
    • Why do many companies make the simple things complicated ? Why do so many people have difficulty in simplifying ?
    • Outsourcing models
      • ...

  • The future:

    • PLM 2.0 ?
      • PLM applications are web-based (Software as a Service)
      • PLM applications focus on online collaboration, collective intelligence and online communities
      • PLM expands to new usages like crowdsourcing and real world web, extending the reach PLM outside the enterprise
      • PLM business processes can easily be activated, configured and used, with online access
    • Is this the future ? Does this address the real issues ?
    • Open source
    • Software as a service - SAAS / on-demand
    • Virtualization
    • Complete digital product representation
    • Global PLM ?
    • ...


    Reference presentation: ProSTEP iViP Symposium 2009: Download of presentations Ralf Lamberti, Daimler , Characteristics of a future mechatronicproduct creation process in the automobile industry

  • PLM Governance

    • Refer to strategy section ...

    • What do we mean by PLM or IT governance ?
    • Putting business first and not IT. Business makes the decisions and hence before having long arguments regarding whether to implement a feature, or to use a sexy new technology, or to conform to a corporate IT architecture standard - always ask the question: does this mean that we will sell any more of our products ?

  • PLM Benchmarking

    • ...

  • PLM ROI

    • ROI models
    • Operating costs
    • Costs per seat
    • ...

    Nokia PLM

    Nokia PLM

    Books / Blogs / References ...

© 2007-2010 Martin Ohly • All rights reserved • Last updated: 01.01.2010

Disclaimer: The contents of this site are based on my own experiences and do not necessarily reflect the opinions of any of my employers past or present.