- Welcome Page 2 - Update Page 3 - News Page 4 - Brief lines | Welcome to this issue of 2PLM, an e-zine distributed every two weeks on a free subscription basis. This week's article, "Simplicate and Add Lightness", is from Menno Huijben of Technia. But first, some information about PLM Best Practice and the PLM Best Practice Forum to be held in Oxford, England on February 9, 2005. * PLM Best Practice : a Win/Win enabler for successful PLM * These days, companies almost everywhere are focusing on cutting costs to the minimum. As a result, very few are prepared to engage in extensive and expensive customization of their processes and application systems. In this environment, PLM Best Practice provides a Win/Win opportunity for PLM users and for vendors of PLM products and services. There are several parts to PLM Best Practice. For example, part of it assists management to create and implement the most appropriate business strategies and organization structures. Part is applicable to everyday operations. Part is related to application systems, part to processes. Some parts of PLM Best Practice are relatively easy to encapsulate in software. Other parts are more difficult, but, as time goes by, it can be expected that more and more will be put into software. With clearly described PLM Best Practice, user companies know what they are taking on. They can see how the Best Practice works in other companies, and the types of benefits and costs it will lead to. They can see the likely implementation effort and time scale. With PLM Best Practice becoming clear, PLM product and service providers can demonstrate to the outside world the successes that they and their customers have already had in achieving Best Practice, and how they will support it in the future. As Best Practice is used more widely by companies, it spreads throughout the design chain and supply chain, and a virtuous circle is created. As more companies buy products and services to support Best Practice, the prices of these drop, enabling even more user companies to buy products and services, as a result of which, more products and services are developed, etc. Product Lifecycle Management emerged in the early years of this decade, but it is only now that PLM Best Practice is beginning to become clear. Vendors have identified the market size, worked out the investment and sales costs, and started to develop and roll out their offer and launch marketing plans. Users have identified how PLM Best Practice could benefit them, and are looking to implement it. PLM Best Practice Forum In view of the high level of interest in the subject, the PLM Interest Group is organizing the first Forum on PLM Best Practice in Oxford, England on February 9, 2005. Why not attend the PLM Best Practice Forum and find out more about PLM Best Practice and how it can benefit your company? (details). For more information, please contact Roger Tempest. The Proceedings of the Forum will be published, and will provide a snapshot of the status of PLM Best Practice in early 2005. * Simplicate and Add Lightness * I lately read somebody quoting the maxim "simplicate and add lightness". While my spellchecker and the editor of this newsletter barked at this formulation, it seems that this maxim can be traced back to Ed Heinemann, a famous aeronautical engineer and aircraft designer from the 1930s to the 1970s. Definitely, "simplicate and add lightness" should be the motto of any PLM initiative, as I will illustrate with a few examples. Firstly, PLM as a system provides ways to manage the complexity of change management. A change in a product design will affect multiple resources and stakeholders. You will have to: update your product documentation; ask suppliers new quotes; retrain service personnel; review manufacturing systems; inform the customer; etc., etc. This is a comprehensive chain of events. Managing it well is complex and mistakes can be very costly. PLM can simplify change management by providing a single view on all the related product data that is affected by the change, and by offering workflow capabilities to ensure that all necessary steps are taken. In this way, PLM 'adds lightness' in the organization: there is less effort required for change management control and corrective actions. Secondly, our 'simplicate and add lightness' is good to keep in mind when deploying a PLM system. To increase user acceptance, complexity should be reduced from an end-user perspective. However, there is a risk to overdo it and end up in the, let's call it, 'reduction-of-number-of-mouse-clicks' trap. Yes, it is nice to make it easier for the user to combine a lot of frequently used transactions into one button on the screen, and it will be a selling point to overcome change resistance. Nevertheless, the PLM system needs to execute the now more complex underlying transactions. Error handling and rollback functionality (the 'oops' button that is so often wished for) are then not always easy to realize. So, reducing complexity at one place can increase it at another place. Our mouse-click example might simplify from a user perspective, but it did not 'add lightness' in the PLM system. Thirdly, the maxim applies to the products managed in the PLM system, as they are also a source of complexity. Demands for mass-customizable products lead to products that are designed with many options, variants and add-on features. As a result, as many different customers as possible can be served with the same product platform. Typically, such a product is surrounded with sales configurators, rule-engines, and option modeling tools. When engineers are let loose to develop all these supporting tools, you can be sure that the outcome is a very complex 'black-box' that in no time configures a product to the wishes of the customer. This is a great simplification from the user perspective, but did it add lightness? Probably not. The black-box rule engine is understood by only a few engineers, and when designing a new product platform, the black-box will have to be re-designed, or worse, reinvented. Still, it might be the right thing to do, but do weight the expected benefits against the increase of complexity. A sound example of adding lightness in products is conducting the good old DFMA (Design For Manufacturing and Assembly) type of analysis. Reducing part-count in the design not only saves logistic and manufacturing costs, but also makes PLM system introduction easier.  Reducing complexity is a balancing act. Simplifying one area can cause an increase in complexity somewhere else. In our PLM world, when 'adding lightness' to the management of product lifecyles, the increase of complexity is naturally in the underlying PLM system itself. How well the PLM system deals with this complexity is correlated to the Total Cost of Ownership (TCO). The TCO can be affected by keeping things simple:
For questions and comments, please contact me by mail or call +358 424 7221. Menno Huijben is a consultant at Technia, a leading supplier of PLM solutions in the Nordic countries. * Feedback on the previous issue * Menno Huijben's article in the previous issue of 2PLM led to the following response from Ravi Rangan of Product Sight Corp. "Menno Huijben has cogently articulated the perils of getting caught off-guard by the data migraine problem. The process of manually extracting and populating PLM structures from legacy data content is usually a staggering ordeal, and is often relegated to background IT efforts under titles like "data migration", "data conversion", etc. Deploying an empty PLM system does not deliver business value. Unfortunately, the brute force approach that one must use to manually discover, gather, decipher, and restructure the information to load the new PLM system often makes data loading efforts unscalable from a time, cost, and resource viewpoint. Many of us have seen several PLM projects fail and deadlines go unfulfilled due to under-estimation of the data loading effort. While it is important to understand and scope the data loading tasks, we need to eliminate this data migraine - Mr. Huijben's simple example is just the tip of the iceberg. ....." More Don Frank (dfrankasso@optonline.net) offered the following thoughts on: "Data Migraine": "Rather than go thru the thousands of parts to establish data integrity, it may be more efficient and fruitful to embark first on a part standardization program that will identify the duplicates and 'look-alikes' among the myriad of part numbers and then consolidate them, using standardized descriptions in the PLM mode, before upgrading the rest of the 100 odd data elements in part master records used for ERP. To keep the audit trail intact, the legacy part numbers retired in this process should have their description read "replaced by part number nnnnn". With today's technology, one can use simple sequential numeric part numbers, with good standardized descriptions rather than so-called intelligent part numbers, for all new parts and even, by using part number aliases or alternate keys, let the system access scrubbed legacy parts by either the legacy part number or the simple sequential. Any new or upgraded PLM/ERP implementation should have a line item in the project plan to do this standardization." |
