A related Japanese term used in the manufacturing industry is “Poka-Yoke” (poka joke) from the words “poka” (which means inadvertent mistake) and from “yoke” (which means to prevent) means “fail-safing” or “mistake-proofing”. “A poka-yoke is any mechanism in a lean manufacturing process that helps an equipment operator avoid (yokeru) mistakes (poka). Its purpose is to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur. The concept was formalised, and the term adopted, by Shigeo Shingo as part of the Toyota Production System or Lean Manufacturing.” [http://www.shmula.com/category/lean/poka-yoke/]. Mistakes are inevitable; people cannot be expected to concentrate on all the time, or always to understand fully the directives they are given. On the other hand, defects result from allowing a mistake to reach the end-user, and are entirely avoidable. The goal of Poka yoke is re-designing/engineering the process so that mistakes can be prevented or immediately detected and corrected.

Why would you want to poka-yoke your PLM application?

So you have bought a commercial PLM application which has been reasonably well-developed and well-tested and you have it implemented in your company. Why would you then want to poka-yoke (mistake-proof) your PLM application (apart from regular testing that happens before it goes live)? Two reasons:

1. Reduce support calls after system goes live: PLM administration is costly because it needs a highly trained/experienced person to administer the installation and troubleshoot issues – You do not want to burden the administrator with frivolous snags because the end users are breaking stuff all the time and need help.
2. Garbage In – Garbage Out The quality of the data in the PLM systems is as dependent on what goes in. As the book Universal Principles of Design says: “The garbage-in metaphor refers to one of two kinds of input problems: problems of type and problems of quality. Problems of type occur when the input provided is different from the input expected. Problems of quality occur when the input received incorrect information in the correct type.”

Poka-Yoke in Software Development vs. Poka-Yoke in Enterprise Software Implementation

Software developers like Harry Robinson in “Using Poka-Yoke Techniques for Early Defect Detection” and Gojko Adzic in “The Poka-Yoke principle and how to write better software” and Aaron Swartz in The Pokayoke Guide to Developing Software have advocated the use of poka-yoke in software development. However enterprise software deployment/implementation is different – there are now and then way too many users and a plethora of permutations/combinations which they can (or would) use/misuse the software – such use cases are sometimes hard to predict upfront (while developing the software) and hence the need to implement poka-yoke devices during the real life implementation. I cannot comment about users of other enterprise applications, but PLM users often work in situations necessitating substantial technical skills, where training/adoption or employee turnover cost is high and where interruptions and distractions are all too common. Such settings result in human error (whether due to Distraction, Tiredness, Confusion, De-motivation, Lack of Practice/Training, Uncertainty, Lack of standardization, Willful (ignoring rules or procedure), Inadvertent or sloppiness etc. is a different issue altogether) which might as an end result lead to GIGO and more support calls.

Poka Yoke Before or After Implementation?

Mistake proofing can be done upfront only till the point where it is known what mistakes might be made (which can happen only after a thorough system testing). However to add a good poka-yoke solution for a problem, the problem needs to be defined first (along with things like when where and how it occurs, and how many defects are produced etc.) which can only be done when the system goes into production and a good grasp is made of the issues users are having.

How to create good Poka-yokes?

There are way too many resources out there about good interface design or human-computer interaction.  Obviously covering them is out of scope for my small blog entry but I do want to cover a few aspects that I have seen in real-life implementations:

PLM Infrastructure Poka-Yoke:

1. Disks Running out of space: Quite often vaults and log files grow so fast that disks run out of space and one doesn’t know about it until late. A good poka yoke in this case would be to get one of those disk monitoring software to send an alert out when free disk space falls below a particular threshold.
2. Status Page of servers: A full-blown PLM implementation would have a number of servers which keeps on going higher as one starts adding redundancy/fail-over mechanism and remote site replicas. A good poka-yoke device here would be to implement something akin to Facebook Engineering’s cache monitoring tool Claspin

Process Side Poka-Yoke:

A typical PLM system would host a number of workflow processes – NPI, Change Management, Document Approval etc.  While implementing Poka-Yoke here, remember the 1-10-100 rule – one dollar spent on prevention will save 10 dollars on correction and 100 dollar on failure costs. The trick is to just fool-proof the parts of the process that repeatedly cause defects. Some examples:

1. Process health monitoring tool – Similar to the Status Page of servers mentioned above. Facility to drill into active workflows can be helpful.
2. Fail Over Mechanism – What happens when a user resigns from the company, his/her user accounts are deleted and a task was assigned to that user in a workflow long time back – Does the workflow get stalled now or a message goes back to the process initiator (or administrator) to do something about the task?
3. Redundant Data Entry – Sometimes due to poor workflow design there redundant data entry over the life cycle of a process – immediately mistake proof this by having data entered only once and propagating that data downstream (once it’s reviewed or approved).

Application Side Poka-Yoke

Off course end-user interaction is the most crucial part of a PLM system – hence the most critical error prevention strategies come at the UI level.

1. Usability – As Oleg points out in his post “PLM Innovation: Who will provide PLM to Boeing in 2015?” “The most disappointing reason is related to usability of PLM systems. The usability of PLM tools is going down, which confirms the fact PLM is struggling from complexity and user experience”. “New” features sell software. For many companies, putting users on the version upgrade treadmill is their business model; its how they generate revenue. Modern PLM systems are vast, and in the attempt to be everything to everyone the UI’s are cluttered and loaded chock full of features (which probably a user will never need) that they look more like an airship cockpit. Such Feature creep/Software bloat might be needed to satisfy a lot of requirements, but which at times might be overkill and likely to result in errors. While I wouldn’t necessarily advise a lock down with an UI being too minimalist to the point of being unusable, I would however go in to say that the UI options presented to the user should at least be configured for the role the user plays. For example if my role is that of a document approver I shouldn’t necessarily see dozens of options related to pushing the bom to manufacturing.

Disallowing Bad Decisions Vs. Creativity?

I read something very interesting here: “Making a process idiot-proof requires that you make it impossible for the users to make a “bad decision”. You do this by either removing all decision-making from the process, limiting choices to a set of known-safe alternatives, or by assigning all decisions to someone assumed to not be an idiot. This eliminates creativity and restricts the users’ actions.” While for some software this argument might hold true, I view PLM as a vehicle to aid users get their main work done – their creativity is shown in CAD or BIM or whatever other software they use for their work. So error-proofing shouldn’t really stifle creativity.

Becoming aware of errors at their source and thwarting their conversion to defects is the elemental principle behind poka yoke. Mistake proofing builds quality, so it is a proactive approach to quality control. Conventional approaches have been reactive, allowing rework and repair as a solution to defects. Considerable problems can be diminished swiftly by applying mistake proofing principles thereby saving time and money spent on re-work at a later stage.

Further Reading:

Poka-Yoke: Improving Product Quality by Preventing Defects

Zero Quality Control: Source Inspection and the Poka-Yoke System

A few days back there was this article in Reuters “Samsung’s advanced TVs go missing en route to Berlin” – big deal? Well presumably so – because it’s being suspected as a case of industrial espionage – “… it may have been a theft aimed at stealing the advanced TV technology, whose loss could cost the firm billions of dollars.” Just to set the background these sets have gone missing while on their way to the IFA consumer electronics trade show which opened to the public on Aug. 31 (and ran till Sept. 5) in Berlin. Samsung’s advanced OLED TV’s that were being debuted in this show were touted as the successor to LCD TV’s with a rumored price tag of $10,000 for the 55-inch model.

Investopedia explains “Industrial Espionage” as “…describes covert activities, such as the theft of trade secrets, bribery, blackmail and technological surveillance. Industrial espionage is most commonly associated with technology-heavy industries, particularly the computer and auto sectors, in which a significant amount of money is spent on research and development (R&D).”  The Independent in its recent article “The art of industrial espionage” puts this succinctly as “…in a world where the biggest corporations easily outstrip the GDPs of small nations, corporate intelligence is almost as grand a game as its government-run counterpart”. In the US the situation is so bad that the FBI has stepped in with a new campaign that targets corporate espionage. The Office of the National Counterintelligence Executive in its October 2011 report to the US Congress on Foreign Economic Collection and Industrial Espionage, 2009-2011 reveals some startling figures:

• Estimates on the losses (to the US economy) from economic espionage range so widely as to be meaningless—from $2 billion to $400 billion or more a year—reflecting the scarcity of data and the variety of methods used to calculate losses.
• Germany’s Federal Office for the Protection of the Constitution (BfV) estimates that German companies lose $28 billion-$71 billion and 30,000-70,000 jobs per year from foreign economic espionage.
• South Korea says that the costs from foreign economic espionage in 2008 were $82 billion, up from $26 billion in 2004.

And one of the most worrisome trends is the Chinese Boom in Corporate Espionage. Apparently as per this ZDNet article which cites Richard Clarke, a former cybersecurity and cyberterrorism advisor for the White House, China has hacked every major US Company!

Some more data

The 2012 Data Breach Investigations Report by the Verizon RISK Team (with cooperation from the Australian Federal Police, Dutch National High Tech Crime Unit, Irish Reporting and Information Security Service, Police Central e-Crime Unit, and United States Secret Service) highlight some interesting details on this topic:

So what’s the point?

The reason I choose to highlight security issue in this article was because many PLM champions espouse of just “good enough” security for the PLM infrastructure or the application for that matter and may IT managers don’t seem to be too much bothered by that fact, which I think is not right. A PLM system has the information of the entire lifecycle of a product from its conception, through design and manufacture (and to probably service and disposal) – you don’t want that data stolen away like it happened for American Superconductor Corp. or Renault. And if you think it cannot happen anywhere near home read about the ACAD/Medre.A worm that steals AutoCAD Designs and sends to China.

PLM Security?

When it involves PLM security, there are a number of things to consider. You might want to consider securing the data (by implementing role based access), securing the application as a whole, securing the database and even securing the data center. Last year I had published a detailed post on various ways to affect this outcome – you can read it here. Essentially several security standards exists (like PCI SSC Data Security Standards and ISO/IEC 27001:2005) and companies should work towards security their “bread and butter”.

Cloud solutions are new to PLM – and there are a number of cloud PLM solutions in the market now. While the proponents have talked about improving the ROI of PLM, by reducing the implementation and maintenance cost, I do not find much being discussed in details about the possible risks. I am not a “cloud hater” but I think manufacturers need to think of the implications deeply before moving their PLM system into the cloud. It is important to note that cloud computing can refer to several different service types, including Application/Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS). The risks and benefits associated with each model will differ and so will the key considerations in contracting for this type of service. I will cover 5 risks here with focus on PLM and Application/Software as a Service (SaaS). From the NIST Definition of Cloud Computing, Software as a Service (SaaS) implies that “The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings”. So what are these risks?

1. Cloud Uptime

I think the biggest concern would be system uptime.  How much would the business suffer if the system uptime deviated considerably from the agreed SLA’s? If you are one of those who needed to blog “Life of our patients is at stake – I am desperately asking you to contact” during the Amazon EC2 outage in 2011, then you need to think about service interruption seriously. While outages of mission critical applications are nearly never excusable and undoubtedly hurting to business, I think the biggest learning from outages of EC2 /Azure etc seems to be the lack of real-time response and qualified explanations. A privately hosted system would have unscheduled downtime too, but in that case the organization’s IT staff would have much more be in command of in resolving it. What options would a cloud PLM vendor offer to offset any such business disruption? How much would it add up in additional costs? It is off course to be expected that when moving from a system with guaranteed availability of 90% (with downtime of 36.5 days/year) to one with 99% availability (with downtime of 3.65 days/year) or with 99.9% availability (with downtime of 8.76 hours/year) costs would naturally increase. Would such costs be in line with expected savings of going live with PLM in the cloud?

2. Enterprise Application Integration

A few months back I had written about this topic: “Cloud Based PLM and Enterprise Application Integration” where I wrote “PLM being an upstream enterprise application (design usually preceding manufacturing/sales/procurement/service) needs to draw upon several collaborating systems…Typical application integration scenarios which are routinely met would include: CAx and Office Suite Integration, Legacy System Integration, and MRP/ERP Integration.” The current bunch of cloud based PLM systems seem to be lacking in addressing this aspect.

 Apart from this, another crucial aspect to be evaluated is the ability to effectively manage complex, multi-CAD data. The system must be capable of integrating the BOM and enabling multidisciplinary 2D/3D visualization of such heterogeneous/multi-CAD data in a single product structure and make it easier for design teams to find, reuse, and synchronize accurate data with their MCAD/ECAD tools.

3.Vendor Lock-In/ Data Porting

Customers switching PLM platforms due to shifting business needs is not uncommon – Such migrations need tools, procedures, standard data formats and services interfaces that promise data and service portability. In case of cloud PLM if there is a need to migrate from one provider to another or migrate data and services back to an in-house IT environment then such options needs to be validated. A few months ago Stephen Porter in his “Zero Wait-State” blog wrote about the harrowing experience one of his client went through when migrating from a Cloud based PLM system thereby highlighting the fact that cloud providers may have an incentive to prevent (directly or indirectly) the portability of their customers services and data. Hence it would be prudent to know certain things in advance and if possible in the form of a formal agreement:

→     How to get data back if you stop subscription,

→     Availability of API calls to read (and thereby ‘export’) that data,

→     Any extra costs associated with exporting data (specially heavy CAD data),

→     Availability of data sanitization procedures (a.k.a True Wiping, Secure erase etc.) after the client is no longer a tenant etc.

→     Is there a guaranteed minimum download speed of data?

4. Legal/Regulatory Risks

Over the past couple of years PLM vendors have substantially enhanced their regulatory compliance capabilities   (ITAR, RoHS, WEEE, ELV or FDA 21 CFR Part 820). I worked for a medical devices manufacturer and know complying with some of the regulations is a tough task. Hence there are certain areas customers would need to pay attention to when appraising contract clauses for cloud PLM services (though on a case by case basis):

→  Where will the data be physically located? Would access control to technical data be based on user citizenship, physical location etc so as not to violate any ITAR or EAR restrictions? This is important from jurisdiction perspective over data protection and ownership and for law enforcement access.

→  Can the provider make available a full audit detailing technical data exports to satisfy regulatory compliance reporting requirements?

→  If the provider patches the system for software defects or upgrades it to the new release, can the customers in some way validate it in lines with FDA guidance on software validation and avoid 483s and/or Warning Letters

5. Supplier Stability

 Some time back IndustryWeek in an article “Understanding Risk: Avoiding Supply Chain Disruption” noted “A supply chain disruption can cost a manufacturer up to $5 million, irreparably harm a brand and drive customers straight to the door of a competitor.”  Cloud PLM is still an emerging market – and as with an emerging market, supplier consolidation and business casualties (like bankruptcies) can happen. Acquisition of the cloud provider could amplify the chances of a strategic shift and may put non-binding agreements at jeopardy while supplier collapse like the company ceasing to exist has the potential to nullify any signed contracts. So what happens to the vital IP in the cloud PLM system in such cases? Source code and data backup escrow might offer some solace thought it is not likely to be the silver bullet.

An old Chinese proverb says “One cannot refuse to eat just because there is a chance of being choked” – likewise the above are risks – With appropriate risk management strategy in place they surely can be contained.

Over the weekend while searching for home office furniture I stumbled upon Herman Miller’s website. What I found interesting was that they had not only put 3D Models and CAD information (3DS and DWG files) but also enormous amount of product specific environmental information. For an example look here at the page for Mirra Chairs – On the right hand side you can see how recyclable that product is, Environmental Product Summary and Recycling Instructions, the LEED Calculator and various certifications including BIFMA level™, GREENGUARD and MBDC Cradle to Cradle. They also have an ecoScorecard calculator which lets the customer know how sustainable their products are. Apart from manufacturing location and environmental certifications, the scorecard also tells about the environmental characteristics of the product like pre-consumer recycled content, post-consumer content, and whether life-cycle assessment was completed. Herman Miller efforts to promote sustainability as won it many awards and the company is recognized as a leader in the ecodesign space.

Another company doing similar work is Apple. Apple reports environmental impact expansively and have “Product Environmental Reports” for all currently shipped and obsolete products wherein particulars of the products environmental performance as it relates to climate change, energy efficiency, material efficiency, and restricted substances are documented. Further examples would include AmazonGreen which is a cross-category program that includes a list of products that customers have selected as the best green products offered by Amazon.com and Nike’s “Considered Design” products.

It is not very frequently that one sees such comprehensive environmental reports about a company’s products. Sustainability is just not a fad – customers are progressively demanding more sustainable products on one hand and environmental regulations are getting stringent on the other. Business intellectuals like late C.K. Prahalad advised (in the article “Why Sustainability is now the Key Driver of Innovation”) that “Sustainability isn’t the burden on bottom lines that many executives believe it to be. In fact, becoming environment-friendly can lower your costs and increase your revenues. That’s why sustainability should be a touchstone for all innovation”.  Even governmental agencies like U.S. EPA have programs like Design for the Environment to “help consumers, businesses, and institutional buyers identify cleaning and other products that perform well, are cost-effective, and are safer for the environment”. 

Having worked with PTC’s former “Environmental Compliance Solution” a few years back I know a thing or two here. Traditional tools in this space cannot effectively handle the product analytics requirements of complex products both for functional requirements like Supplier Declaration Management, Material/Substance Management, Reporting, Instantaneous Compliance and Environmental Impact Analytics, Business Process and System Integration, Workflow and Notification Management or for non-functional requirements like Performance & Scalability, internationalization and localization, Usability etc.. Manufacturers need to embrace “design for environment” strategies and processes that facilitate them to more effectively and efficiently improve the environmental performance of their products is real, and they will need to identify a best in class and modern solution to help them meet that goal.

Definition of Customization

I would conceptually characterize customization as an alteration put into place because the “vanilla software” PLM solution does not reflect the “desired” business needs. Changing packaged software to meet user needs is the essence of customization.

Decision to Customize

PLM systems are packaged software solutions and not customized systems. Packaged solutions traditionally involve software and/or services tailored to achieve a specific scope of work and are intended to meet the broad-spectrum needs of a class of organizations, rather than the unique needs of a particular organization, as is the case in custom software development. By adopting standard packages, organizations substantially reduce the costs, risks and delays associated with custom software development, and benefit from the on-going support services provided for packages by vendors. Conversely, packaged solutions come with built-in assumptions and procedures about organizations’ business processes. These suppositions and rules seldom tie in with exactly with those of the implementing organization’s existing processes. The so-called “industry best practices” embedded in PLM systems is hardly universal – the misfits between business requirements and PLM capabilities can be company-specific, industry-specific, or even country-specific. Any successful PLM implementation requires a fit between the PLM system and the organizational processes it supports. A divergence can have substantial bearing on organizational acceptance, and could be one of the main reasons of a PLM implementation failure.

More often for misfits, customization is the way out. PLM system customization can ensue either during the implementation phase when the gaps are well-known or after roll-out, when the system is operational, and as a response to changing business needs. Customization at times offers the ability to obtain competitive advantage vis-à-vis companies using only standard features. However they come with a cost and risks. Hence the assessment to customize is complex and is so made with a trade-off in mind.

Types of Customizations

I would categorize most of the customizations I have seen or done in the following order:

1. Configuration Customization,

1.1. Pure Configuration Update

1.2. Bolt-On’s

2. Process Customization (Workflow Programming), and

3. Technical Customization

3.1. Extended Reporting,

3.2. UI Customizations,

3.3. PLM Programming,

3.4. Interface development,

3.5. Package Code Modification

Let us look into each in more detail:

1. Configuration Customization: I would subdivide this customization into two sub types:

a. Pure Configuration Update: This type of customization involves setting of parameters, properties etc. Examples: Server settings, logging parameters etc. It usually is benign, and affects the application and sometimes the database layer. Such updates are vendor supported too.

b. Bolt-Ons: Bolt-Ons are third-party packages designed to work with the PLM system from independent software vendors (under license agreements with the original PLM vendor) to meet the needs of a particular customer segment and provide specific functionality. Example: The ShapeSpace 3D Search tool for Aras PLM which extends the searching capabilities of Aras to enable searching by shape or FLUENT for CATIA V5 software brings fluid flow and heat transfer analysis into the CATIA V5 product lifecycle management (PLM) environment. The quality of the bolt-on depends on the quality of the relationship between the PLM vendor and the bolt-on developer. Note that there may be a “release lag”, where the bolt-on vendor is supporting an older release of the PLM system that the one the PLM vendor is currently offering to customers. This is likely to be an issue during PLM system upgrade.

2. Process Customization: This type of customization involves Workflow Programming – Creation of organizationally unique workflows or customized logic in standard workflows. Example: Set up automated engineering change order approval process. This typically affects the application layer and/ or database layer.

3. Technical Customizations: These are code changes that the vendor usually does not support and can be split into 5 categories:

a. Extended Reporting: This type of customization is programming of extended data output and reporting options. Example: Design a new report to show the health of each project and compare it to the time taken in each portion of the change management process for specific criteria. This typically affects the application layer and/ or database layer.

b. UI Customizations: This involves changing the UI Look and Feel or functionality and changes to terminology and layout. Such customizations might occasionally add extra business logic specific UI validations too. I was consulting for a major medical devices manufacturer in 2006 – they had decided to upgrade their old PLM system with two major versions in a single upgrade. Fearful of adoption and training issues in their 7000+ user base they resorted to reprogram the UI to look as much as possible as the original system even though the new system provided with lesser picks and clicks.

c. PLM Programming: I would define this as programming of additional applications, without changing the product source code (using the computer language used by the vendor). For example if there is a requirement to detect when a particular event happens in the lifecycle of a drawing or a product and to take further actions based on that (which the PLM system doesn’t support) then one would need to resort to such programming. This typically affects all layers.

d. Interface Development: Programming of interfaces to legacy systems or 3rd party products when such interfaces are not available off the shelf. I have implemented interfaces with custom-build MRP package or with an archaic CRM package. This typically affects the application layer and/ or database layer.

e. Package Code Modification: This type of customization is atypical, and involves changing the product source-code – ranging from small changes to changing whole modules / functionality. An example would be changing of the system behavior when a CAD file is checked into the system from a CAD tool. In 2004 I was consulting for a Taiwanese OEM and the PLM tool they were using was quite immature as compared to their requirement – leading to vast amount of changes in the underlying product. Product source code was not available – we had to decompile the code to make modifications. Needless to say such customizations point towards a bigger issue which I will discuss shortly.

Risks of Customization

The risk impact of customizations can be classified as underneath – The deeper the customization the higher is the impact and likelihood of risk.

Risk Impact

If customizations are built as part of a development effort during an implementation time frame, they may have bugs which can impediment development during the PLM implementation, and thus distress a successful implementation (e.g. overspent budget and an unreliable system due to poor quality of customization, unresolved system bugs and insufficient testing). Also note that there is supplementary end user training and consulting costs towards adoption of customized code. By and large, less customization will mean shorter implementation times.

Over-reliance on heavy customization suggests a deeper problem – It can mean that due to poor PLM selection and evaluation process, the software is ill-fitting with the business requirements.

Customization of PLM will have maintenance and upgrade impact too. The more complex a customization endeavor the more likely it is to require greater effort in maintenance and post-implementation. Each time a change/upgrade is required to the system, the effect of the change on the customization will have to be assessed by the organization, as the software vendor will not support these customizations. Many times, this requires bringing in an external expert to help with this assessment. Once the system is upgraded the customizations would have to be manually updated too. These additional requirements reduce flexibility or agility of the system and increase costs.

The following table presents an estimate, based on experience, of the effort needed during system maintenance and post implementation of different customization types.

Another associated issue is poor consultant effectiveness. Poor consultant effectiveness will contribute to mediocre quality of code customizations (and associated documentation) and inferior knowledge transfer of the customizations to the organizations IT resources. This in turn leads to higher maintenance costs. The better the knowledge consultants have about their PLM package, the more likely they are to address business objectives with light (and probably configuration driven), rather than (code driven) heavy, customizations.

Configuration vs. Customization

Customers are almost always better off in choosing a PLM system with an open architecture, one that can often be adapted with relatively uncomplicated configuration changes rather than code rewrites. It is vital to realize the key differences between customization and configuration to appreciate the benefits:

Wrapping up, organizations should steer clear of a dash to customize. It is to be expected that any new PLM system will have inadequacies, both factual and alleged. All workarounds and alternatives should be investigated first before making a commitment to changing the system. It is important to take into consideration that though customization might bring in a competitive gain, there are risks and costs associated with different types of customization. The heavier the customization is the riskier and costlier it becomes.

]]> http://www10.mcadcafe.com/blogs/plm/2012/07/03/understanding-plm-system-customization-2/feed/ 1 http://www10.mcadcafe.com/blogs/plm/2012/06/09/plm-upgrade-the-fota-way/ http://www10.mcadcafe.com/blogs/plm/2012/06/09/plm-upgrade-the-fota-way/#comments Sat, 09 Jun 2012 22:30:32 +0000 Jyotirmoy Dutta http://www10.mcadcafe.com/blogs/plm/?p=87  

I still remember when I took my first cell phone, an “indestructible” Nokia 3310, to the OEM service center to get it “flashed” when it started showing problems. The process took 3 days. A year or two later (when I updated to a newer model) I could do this all by myself with a USB data cables and a desktop software from the device maker. Now-a -days everything is done “over-the-air” – courtesy FOTA (Firmware Over-the-Air) and a bunch of other related technology like FUMO (Firmware Update Management Object), SCOMO (Software Component Management Object), OTA (Over-the-air programming) etc. which enables remote operations, such as install, update or remove for software components in a device  such as a cell phone or a PDA.

Another common automatic update scenario most people regularly see is of Windows Update. All you have to do is turn it on, and you will get the latest security and other important updates from Microsoft automatically. In most cases, the end-user does not have to do a thing. (This Wikipedia article gives an overview of the evolution of this facility from the Windows Update web site to the Critical Update Notification Tool/Utility and then to the current Automatic Updates.)

Automatic software update is becoming an accepted constituent in many software products today – making it uncomplicated and effortless for the users to keep the software up-to-date always, without hassle of having to check for a new version, download, and install manually. Note that in both the above two cases, technology has become so mature that there is almost no risk to user’s data, and that, in both cases the underlying technology is very complex.

Coming to the PLM world, it is a different story all together. PLM upgrade projects can last from a few weeks to a few months, draining an IT department of financial as well as human resources. Agreed, enterprise solutions are not trivial to upgrade because of various factors involved but surely, the PLM vendors need to do something to cut down the time and effort needed. The answer to this issue lays both on economic and technical factors.

I would like not to believe that services revenues play a big role in extending the upgrade projects. PLM vendors (and a whole bunch of service providers too) publicly advertise their strategies and best practices for implementing PLM upgrades (though most of them sound more or less alike). Though the figures are hard to come by, but the revenue garnered from the services part of an upgrade project does add some level of bottom-line impact to the vendors. Services business is usually low margin (until a large percentage of work gets done offshore) – so even if the timelines are squeezed it should not make that big of an impact to the vendors.

From a technical point of view let us what a typical PLM stack looks like. The below example is of Teamcenter architecture:

Assuming requisite drivers like leveraging new platform capabilities or addressing issues with current PLM deployment are present, when an organization decides to go for an upgrade there would be several steps involved including planning, upgrade assessment, impact analysis etc. where there might not much opportunity to compress the timelines. The main prospect of compressing the timeline is during the execution phase and here is what I think vendors need to do:

• Evaluate Platform Bloat: Analyze if the PLM platform has bloated over the years – Featuritis/Second-system effect always makes it painful to upgrade easily.
• Improving Performance of Upgrade Tools: Software efficiency halves every 18 months, compensating Moore’s Law – May’s Law. A large amount of time is usually taken when the database is getting upgraded. There is a need to focus on the bottlenecks and look beyond obvious optimization techniques – like targeting Algorithmic efficiency, Memoization etc.
• Pre Upgrade DB Tools – A major part of time is consumed while making the database upgrade and is resolving issues with the data. Make tools available which customers can run much before the formal upgrade project starts. Let these tools give detailed reports on the problematic areas and how customers can take care of them.
• Eliminate Manual Steps: Maximize automation and cut manual steps – This would also take care of human errors.
• Body of Knowledge: A body of wisdom (domain ontology?)about upgrades could be made available. It wouldn’t necessarily make an upgrade easier or faster. As I noted earlier, there are published best practices for implementing PLM upgrades – the problem is that most of these best practices, as honest they are, has reached the point of platitude. There is a need to move beyond the clichés with upgrade do’s and don’ts grounded in practical customer project experiences.
• Handle Customizations Effectively: Each company has certain unique processes and practices that lead them to a competitive position – This necessitates customization of the PLM solution to a varying degree. A highly customized global deployment in effect requires a re-implementation and data migration which is especially true for major global PLM installations. Tools need to be made available wherein customers can run them before hand and find and if possible fix potential issues with the code (like deprecated API’s, API changes etc).
• Automate Testing – Data validation and performance tests come at the end stages of an upgrade. A bulk of such testing can be done using automated scripts run 24X7.

While upgrading a PLM deployment the FOTA way might not be possible, I think there are many opportunities to address the pain point customers face during such an undertaking. And it would be worthwhile to make things easy and customers happy! Everyone loves easy!

This is going to be a very short post :) I was reading a few articles late night this Memorial Day weekend, which caught my eye. First, one was about “MySQL at Twitter” by Twitter engineers Jeremy Cole (@jeremycole) and Davi Arnaut (@darnaut). As one of the largest users of MySQL, Twitter uses the database software to store most of the data its 140 million users generate.

Second article was about “MySQL and Database Engineering” by Mark Callaghan. Here are some interesting statistics about Facebook: “More than 125 billion friend connections on Facebook at the end of March 2012. On average more than 300 million photos uploaded to Facebook per day in the three months ended March 31, 2012.  An average of 3.2 billion Likes and Comments generated by Facebook users per day during the first quarter of 2012. More than 42 million Pages with ten or more Likes at the end of March 2012.” And, to keep all these running Facebook uses MySQL.

One of the often-heard complaints about PLM is that the investment need is huge. Partially the blame also falls on the database licensing cost. In order to find out what the database licensing costs look like I tried to read Oracle’s Global Price List and their Software Investment Guide and SQL Server 2012 Licensing Overview – and ended up just getting bewildered. There are so many variants like Unlimited License Agreements, Processor licensing, Standard Edition Per-socket licensing, Enterprise Edition Per-core licensing, Named User Plus Licensing, Application Specific Full Use Licensing  etc. I am pretty sure a IT Manager just ends up getting baffled as well!

So why not just switch to MySQL? There are two aspects to this:

1. Does the PLM vendor support MySQL?
2. Does the IT department have MySQL DBA’s?

I am not sure which PLM vendors do not support MySQL yet – but it should not be that hard for them if the demand is there from end customers. Also with experts from the likes of Facebook and Twitter open-sourcing their tweaks of MySQL it shouldn’t be that problematical either to get optimal performance out of MySQL provided an IT Department has MySQL DBA’s.

As a side note, Sun Microsystems bought privately held open-source database maker MySQL in 2008. In addition, when Oracle bought Sun in 2009, MySQL came with the acquisition. So Oracle owns MySQL!

I would like to know from my readers what prevents MySQL from being extensively used in a corporate environment.

I write this post based on my latest experience of buying two products from a leading retailer and then returning them both after scarcely being able to use either one. Every one of us has experienced this common scenario on a regular basis.

The first product was a home water filter made by Fortune 100 chemicals major and the second product was a piece of furniture made by leading producer of “ready to assemble” residential furniture.

In the first case, I simply could not get the product to work as anticipated. After tinkering for an hour or so with it I headed to their website – was extremely dismayed to find no product support/self-help available, had a long wait time to get to their customer care and there were no FAQ’s on what could go wrong and how to fix such issues. It seemed like the “big-company” had forgotten its retail customers or were not very inclined to serve them.  Therefore, I took my receipt and headed back to the store.

In the second case, it was more of unmet expectations. I ordered this piece online and paid much more than comparable item in store, but when I landed my hand on the item, the quality seemed inferior. The nice glossy pictures of their website took me in! In addition, it had taken longer to ship than anticipated (by the time I had lost the euphoria of buying in it), and had extremely complicated assembly with more than 30 different parts needing specific tools for assembly (which I was reluctant to buy). This was not a small product – was over 50 lbs and had extensive packaging to prevent damage while shipping to the store.

Returning these items (for a full refund off course) made me think – especially after the second one: Who was going to bear the cost of packaging, shipping, inspecting/assessing, repackaging, restocking and reselling the returned merchandise? Moreover, how common was this practice? Therefore, I drudged in a little deeper. A study “Time Value of Commercial Product Returns” done few years back estimated: “The value of commercial product returns, which we define as products returned for any reason within 90 days of sale, now exceeds US $100 billion annually in the US.” More recently, “Accenture estimates that US consumer electronics manufacturers, communication carriers and retailers will spend $16.7 billion to receive, assess, repair, re-box, restock and resell returned goods in 2011. For manufacturers this represents 5 – 6 percent of revenues and 2 – 3 percent of sales for retailers.” The Aberdeen Group estimates that high-tech companies alone spend approximately 8% of revenue just to manage their reverse logistics function. Naturally, product returns are a “pain in the neck” for a firm’s supply chain management and bleed overall profitability, costing in terms of both profits from sales and reverse logistics.  The reasons for return are myriad, and industry analysts concur that returns have become endemic in many markets, with rates of 18-25% in some sectors. Return rates will probably continue to rise due to factors that include increases in low-cost, and low contact distribution channels like the Web, customer uncertainty that emerges from a dramatic expansion of product choices, and shorter product cycles. [Managing Returns: Art To Science]

Though penalties like restocking fee, non-refundable shipping or handling charges, penalty per return etc. exist, a “money-back guarantee” policy or a full refund policy is more common. Relaxed returns policies at most major retailers allow consumers to return unwanted merchandise back to the store for almost any reason. Retailers try to make a customer’s return experience positive (e.g. easy hassle free returns), as this offers a chance to build the relationship with the customer resulting in higher customer lifetime value. Studies conducted show that though product returns are inevitable but by no means evil – a customer’s product return behavior positively affects his or her future buying behavior, up to a threshold. However, the issue in finding this threshold and having an ideal rate of return is that once returned to a retailer, the products can follow one of two reverse channels, where either the manufacturer or the retailer resells or salvages the products. In the second case, it is difficult for the manufacturer to take corrective and preventive measures as gaps along the supply chain thwarts the credible sharing of such information as the product return rate or reasons for return.

Many manufacturers actively take countermeasures against returns, including investments in processes and infrastructure. While my post today does not focus on these methods, I think there is a large scope of improvement where PLM tools can specifically help. The picture below from Returns Management Inc. whitepaper “Unlock Profits In Your Product Returns” depicts the “Organizational environment for product returns”. When you look at the entirety of an organization from the angle of returns management, the connection to PLM is instantly recognizable.

In my view, PLM systems can effectively aid returns management by various means:

1. Pre-Purchase Stage:

Help consumers in their pre-purchase decisions: When customers conduct pre-purchase research, providing better product information goes in a long way. Currently if you look at various retailer websites say for a piece of furniture, garden, or home equipment you get to see only a fully assembled product photo. 2D and 3D product visualization with markups directly pulled up from the PLM system would enable customers to visualize these products better and to understand what effort would go in to put them in use. Information on parts list, tools required for assembling, estimated time to assemble etc. could be put up front too.

2. Usage Stage:

Survey of US consumers found that consumer tolerance levels-for making a device work is about 20 minutes. After that, they tend to give up and return the product. In such cases, manufacturers need to address problems with a product’s design, packaging or instructions. Redesigning a product to simplify the technical complexity imposed on the consumer goes in a long way. As PLM systems evolve, companies can now create and manage technical information aligned with product structures to automate product-specific documents such as installation, service, and maintenance instructions, along with training materials, FAQ’s etc. If a manufacturer has this piece automated then it would be prudent to make such information easily accessible to the customer.

3. Post Purchase Stage:

Encouraging customer feedbacks/complaints to understand dissatisfaction and keeping customer feedback mechanisms simple goes in a long way. Since only a small percentage of discontented customers actually complain, simple questions and short surveys (Amazon style) tend to ease user fatigue and return information that is more reliable. The survey results should directly feed Returns Analyses and in succession Engineering Change and front end processes such as new product/market development or quality assurance.

Reverse supply chain is a complex process and I may have missed some points in my assessment here – I would love to hear from you on this topic! Do post your comments or send me a note.

Putting PLM in the cloud is not enough – What matters most is enterprise application integration.

Cloud Based PLM

There have been a number of announcements lately of putting PLM in the cloud. It started Dassault making its V6 platform available from AWS last year; it gathered much more steam with Arena’s launch of PDXViewer and mostly Autodesk’s launch of PLM 360. I haven’t personally tested PLM 360 yet, but take it from reviews of Deelip and Oleg that end-user experience is pretty great.

The fact that an on-premise PLM implementation is expensive and a time-intensive process remains true (which requires software licenses and a considerable infrastructure and consulting investment) and since cloud PLM solutions are maintained by the software provider, which means set-up is easy and requires no internal resources for updates/upgrades will endow manufacturers to see faster returns on investments. Also as Michael Driscoll notes “The cloud is a more fault-tolerant and flexible operating system than its predecessors. These two advantages derive from the cloud’s two hallmark features: it is both virtualized and distributed. Because it’s virtualized, failing hardware can be upgraded or swapped out, and virtual processes can be migrated to new machines with little end-user impact. Because it’s distributed across thousands of commodity boxes, services’ compute and bandwidth needs can be scaled up or down, and disk storage limitations are almost an anachronism.”

The above being said, I have my concerns with cloud based PLM. I believe the argument that accessing data, processes, and business intelligence in a cloud based PLM platform is easier than a traditional on-premise PLM implementation is more of an IT issue (think getting VPN accounts, security etc). Also the contention that cloud PLM systems are superior at facilitating communication between manufacturers and suppliers by being able to deliver a more streamlined resolution for product data management and change control depends on whether the manufacturers and their suppliers are using the same cloud based platform. Otherwise it’s back to square one again. Another major item which I find lacking is any mention of enterprise application integration (EAI). I will talk more about EAI here.

Enterprise Application Integration

Global corporations need to blend data (in a robust, scalable and secure way) from many existing systems to manage products across their lifecycle. PLM being an upstream enterprise application (design usually preceding manufacturing/sales/procurement/service) needs to draw upon several collaborating systems – None of the enterprise PLM systems ever run in isolation. Typical application integration scenarios which are routinely met would include:

• CAx and Office Suite Integration

Integration with major MCAD, ECAD, CAM, and CAE systems, including AutoCAD, CATIA, I-deas, Inventor, NX, OrCAD, Pro/Engineer/Creo, SmartCAM, Solid Edge, Solid Works, Unigraphics etc. Typical office suite integrations concern MSOffice and Lotus Notes.

• Legacy System Integration

Integrations existing legacy systems and other corporate systems like LDAP.

• MRP/ERP Integration

Integrations with major MRP and ERP systems, including Manage2000, Oracle, Peoplesoft, JD Edwards, SAP, Vantage, WDS, etc., allowing the controlled (uni- or bidirectional) transfer of material master, BOM and other information between PLM and MRP/ERP systems.

PLM vendors typically offer “adapters” for their PLM systems to talk to a few “standard” enterprise systems, or you can use an off the shelf middleware, but if you need to integrate with a “non-standard” enterprise application you have to usually write your own custom code. The functions involved with enterprise application integration include designing and developing (coding or configuring) the integration process, deploying the integration, executing the integration, and then ongoing monitoring and management/troubleshooting. In a multitenancy environment (Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations called tenants), each customer will/might need their PLM system to talk to a whole bouquet of other corporate systems. If you add different versions of such standard/non-standard software to the mix the complexity can be mind-boggling for the software provider. The current crop of cloud based PLM systems seem to be lacking in addressing this aspect. Autodesk for example has PLM 360 Apps store for various product development needs but the model of enterprise application integration is not clear and undeniably would be a concern when considering an enterprise IT strategy.

Another corollary item to enterprise application integration is the prerequisite for system interfaces in cloud based PLM solutions (maybe REST-based APIs), thereby providing a standards-based framework for accessing and integrating with web services-based/enabled in-house systems (or even with other cloud services).  This is another vital aspect of cloud based PLM services: that the software providers make available well-defined, programmatic access for users (read software developers) and partners who want to leverage the cloud service within a broader solution or business context.

Readers following the Consumer Electronics Show (CES 2012) at Vegas this year would have unmistakably noted car makers showing off their latest and greatest gizmos. As MSN noted in its editorial: “Audi, Chrysler, Ford, Kia, Mercedes-Benz and Subaru all used North America’s largest trade show to demonstrate advances in in-car infotainment, showcase next-generation alternative-powertrain vehicles and offer conceptual visions of how technology will power cars not only a few years from now, but well into the future.” And most of the latest innovation in automobiles is being done using software. Wired magazine in its article “Software Takes On More Tasks in Today’s Cars” notes “According to one study, 90 percent of the innovation we’re seeing within the auto industry is driven by advancements in software and gadgetry.” IEEE Spectrum ran an article some time back titled “This Car Runs on Code” where it put out some in-depth statistics: “It takes dozens of microprocessors running 100 million lines of code to get a premium car out of the driveway, and this software is only going to get more complex.”

How and Where Is Software Used in Cars

Table from the article in IEEE Spectrum “This Car Runs on Code”

While LOC (Lines of Code) measurement is always debatable, many studies do show a rough correlation between LOC and the overall cost and length of development, and between LOC and number of defects. And being a software developer I know a thing or two about the latter. A mountain of code would certainly have a ton of bugs (and that is what scares me!). In fact IBM even forecasted that 100 million lines of code at a Capability Maturity Model CMM level 3, corresponds to 2.3 million software design faults. Imagine driving in a highway at top speed with your family and a bug pops up in the powertrain control module or the electronic fuel injection ECU – pretty terrifying thought! “‘Talking’ Cars Are Coming Soon to Keep Us Safe” – yes but that can malware and script kiddies be far behind?

Automotive Software Verification and Validation Standards

However it’s not like the Wild West here – there are certain standards in place. ISO 26262, MISRA, and SPICE are various software standards that pertain to vehicle based software.

• ISO 26262 is a Functional Safety standard. The standard is an adaptation of the Functional Safety standard IEC 61508 for Automotive Electric/Electronic Systems. ISO 26262 is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars with a maximum gross vehicle mass up to 3 500 kg.
• MISRA (Motor Industry Software Reliability Association) on the other hand aims to facilitate code safety, portability and reliability in the context of embedded systems, specifically those systems programmed in ISO C. There is also a set of guidelines for MISRA C++. They publish various development guidelines for vehicle based software.
• Automotive SPICE® Process Assessment Model (v2.5) ((ISO/IEC 15504), also known as SPICE (Software Process Improvement and Capability Determination), is a set of technical standards documents for the computer software development process and related business management functions.

Issues

An OEM typically has a very large number of Tier 1 and Tier 2 suppliers (playing roles of System integrators/System
Manufacturer/Standardizers/Component suppliers etc classically). Imagine a Tier 2 supplier making an ECU whose software development was outsourced to a third party software development firm. It will be very hard to predict how defects in this code will influence say another ECU developed by another Tier 2 supplier when both of them get incorporated into a more complex system. Smarter automotive supply chains have been able to give more visibility, quick response to increased customer demands, cost containment and fillip to globalization drives of the OEM’s. However where they have started lacking is in areas of risk management and quality issues (Toyota’s vehicle recalls being a prime example). “Pervasion of automobiles with digital technology – the integration of hardware and software into automobiles represents the predominant accelerator of increased functionality coupled with increasing complexity. This complexity results in overstrained car development departments, product failures, a cost explosion with respect to guarantee and warranty costs, and impact on customer satisfaction.” (IBM Whitepaper)

ALM-PLM Solution to Rescue?

Application Lifecycle Management (ALM) helps manage the life of an application through governance, development and maintenance. ALM basically integrates requirements management, design and development, testing, and release management and all related processes, and there are a number of tools to do that from a software development perspective. Around a year and half back I wrote an article “Can PLM encompass ALM (Application Lifecycle management)?” – Basic thoughts on tightly integrating Application Lifecycle Management with Product Lifecycle Management for mechatronics system. The way in which automotive products are being developed, manufactured, and serviced is rapidly changing – therefore, Application Lifecycle Management solutions must broaden and augment Product Lifecycle Management for software intensive products.  A panoptic and rigorous approach to software lifecycle management – from development to after-sales support with the precise tools and which fits in the automotive supply chain will be the answer.