It is time to debunk the myths around the painting of the Golden Gate Bridge. I was told during a city tour long ago that the painting of the bridge was a continuous process, once they were finished at one end they would start over at the other. It turns out that after the bridge was completed in 1937 it wasn't painted again until 1965. Advance corrosion required that the original paint be replaced with an inorganic silicate primer and an acrylic emulsion topcoat. This program was completed in 1995 and since then continuous touch ups are required on corroded areas. While this version of the story doesn't quite match up to my original belief about the bridge it does tend to better mirror what goes on with the adoption and continuous tweaking that tends to happen with product lifecycle management(PLM) systems. Since I spent the week in San Francisco at the Oracle Value Chain Summit using the iconic Golden Gate Bridge as a symbol for successful methodologies in relation to PLM seemed like a natural. This article will wrap up my time at the summit and discuss the best strategies to employ when maintaining and expanding the PLM footprint.
We have discussed the need for continuous improvement in numerous previous articles. The recent "Sharpen Your Saw "article touched on this topic. I think it is important to recognize that PLM is a continuing journey and not a destination. This thought was driven home to me as I watched Alex Dye's presentation at the summit. Alex is Senior Manager for Customer and Product Value Chain for Fortune Brands (Masterlock's Parent Company) and has been largely responsible for the AgilePLM deployment at Masterlock and was discussing their experiences around the integration between AgilePLM and Oracle's E Business Suite ERP package. While discussing the integration he also discussed their ongoing plans around incorporating different aspects of PLM into their plans and it struck me that this has and would continue to be an ongoing effort on their part. Some might view this as a bad thing but as long as you are gaining value as you go I think this is preferable to time locking something in place and then making a wholesale replacement once it becomes obsolete. The problem with this approach is that business process and the opportunities for improvement are really never ending and you are missing out on the benefits if you view your system as finite. Moreover, the level of obsolescence will have to be significant for you to incur the pain and cost that full replacement represents. I had a similar discussion with one of our other customers while at our booth. I had mentioned this customer's approach in my previous article on the conference "Gridiron Hijinks at the Oracle Value Chain Summit-PLM and Madden". They have decided to break up their implementation into small pieces to ensure that they do not have to compromise on functionality and can make adjustments as they gain better understanding on how PLM mesh's with their business requirements. They have a long list of objectives for PLM but recognize that these are best accomplished in incremental activities as opposed to trying to do everything in one fell swoop.
This type of approach can also aide adoption within a company by reducing the initial cost of deployment. The key issue is that you must understand that your purchase is just the beginning and whatever solution you choose must have the flexibility and breadth to accommodate the changes and additions you will make going forward. For example, let's say you are a startup company with no plans on exporting your product in the near term. Does this mean it is ok to choose a PLM solution that offers very little or no capability around governance and compliance or global supply chain management? On some level it depends, you certainly must be careful about overspending when you are a young company but at the same time you don't want to paint yourself into a corner. You must recognize that at some point these things could become critical to your business so while you don't need them today you should probably choose a system that has the capabilities for future expansion. The same kind of logic could be applied to Product Portfolio Management, Analytics, integration with ERP and CRM. All of these things might not be considered critical when you are making your selection today but down the road it could be very important. Where would Masterlock be today if they had selected a PLM solution without these capabilities? They would most likely be implementing an entirely new system and effectively starting over on some levels.
Beyond just additional modules it is also important to understand what is involved in changing the core system itself. Things like permissions, attributes, workflow etc. are going to need to be modified as you move forward. What does it take to make these types of changes? Do you need external resources in order to make adjustments to your PLM solution? One consideration is that there will be times when external resources are required to accommodate changes. If you change ERP systems or add new business units it might be unrealistic to expect your internal personnel to make these changes. In many cases it is not a question of whether they can make the changes, many systems have fairly straightforward administrative clients and their development languages are well documented, it is a question of whether they should. Is it really a good idea to maintain staff capabilities on this level or should your resources be focused on developing and delivering your company's products in the most effective manner? I expect if you look at the true value propositions for your company it may be more profitable to focus on your company rather than manipulating the technology that supports your company. I will concede that some larger companies can and do justify this overhead but the analysis should be carefully conducted and reviewed before you decide to take on these types of projects internally. There is usually something more valuable employees could be doing.
When I was younger I went through Tony Robbins' Personal Power series. One of the things he emphasized was an acronym, CANI. It means constant and never ending improvement. Obviously, it is not an original concept, according to an article I found on Ezine by Chris Knight Robbins was influenced by Dr. Edward Deming who I am sure most of you are familiar with as one of the thought leaders that assisted Japan's transformation into one of the world's leading manufacturing nations. "Kaizen" is the term Deming and the Japanese coined for this approach. The idea is to not be overwhelmed by grand visions and to allow companies and individuals to focus on shorter term outcomes. This doesn't mean however that you completely disregard the big picture. Like most things there is a balance to be struck between the near term results and the overall objectives. You must think beyond just installing your system and where it is going to take your company. Sometimes it can be impossible to anticipate the future but if you never try you will certainly fail. My take aways from the presentations and discussions at this year's Oracle Value Chain Summit is that PLM is a journey not a destination and you should try and anticipate where you are going. Think about the Golden Gate bridge and the fact that despite all the upfront planning and effort it is an ongoing task to keep it viable. This is the condition of PLM as well. Look for the opportunities to apply paint to problem areas within your business. I want to thank everyone who stopped by the booth to say hello, I really enjoyed the conversations and was happy that our book, The PLM Primer was so well received.
|
Comments
Please send me the copy of The PLM Primer.
Thanks
Sandeep
Thank you for the summary from the conference. It was certainly good seeing you and having some time to talk. One important need for companies implementing PLM in an ongoing process is to ensure they are setting up their overall business environment to be able to proceed with phase 2, 3, and 4. This may mean that paying attention to metrics, Organizational Change Management, and internal communication is a more important task right now than tweaking the Agile PLM configuration. As you state, there are often time where some of this work could be more efficiently done by a contractor, but it could also be that the precious time of that internal employee should be spend differently to be more effective to the success of the overall program. I do think this idea of long term planning is needed for our customers as they look at how Agile PLM will help them continuously improve their Engineering and Supply Chain operations.
Regards,
Shane
At first, I totally agree with the thought in the article. there has been such instances where in PLM Service organization has to explain and educate the customers about the significance and benefits that they see on overall basis when it comes to importance of configuration management. Unfortunately, This view is clearly visible at program level engagement rather than project level. In program level, it certainly pays of as the configuration management org is a collaborative piece with between development and service especially, when Business, Development and Support organization are Designing and Services on the lines of ITIL.
Also, I would like to know your thoughts and understanding on the big picture of integrations and how that is being leverage for PLM SOA and Ontologies. Is there any thing that you can share on PLM SOA and Adaption to PLM Ontologies in the big picture. like agile PLM adapation to Rosettanet PIP model or totally custom make like Organization specific model which is typically on the line of OAGIS standard.
Regards,
Paritosh Deshmukh
Cheap preparations can, generic advair, Discounts and Bonuses. Online pharmacy, buy allegra no prescription, low prices. Antibiotics as well as, allopurinol without prescription, treatment Effectiveness.
We have given away the book at events but normally it is purchased. Here is the link if you would like a copy.
http://www.amazon.com/gp/offer-listing/0988618303/sr=/qid=/ref=olp_tab_all?ie=UTF8&colid=&coliid=&me=&qid=&seller=&sr=
As always I enjoyed the opportunity to discuss PLM. You definitely bring up a key ingredient to PLM success. Metrics can be a powerful tool in prioritizing and justifying process improvement and this type of activity is usually best done by internal personnel.It can be difficult for an outsider to gather credible, relevant data. When determining where to use consultants it would be wise to consider the impact that can be made both by the consultant and by freeing up internal resources to pursue higher value add work.
I am glad you have seen validation of the article in your work. One of the key reasons PLM fails is the lack of understanding around how it impacts the company. Too much energy is spent on the features of the software or the lack of features and not enough time is spent on strategic thinking about how to improve process.
As for your questions around integration obviously Oracle has their own approach leveraging SOA via their Fusion platform. In reality for Agile PLM the Design to release PIP is the main manifestation of this. Additional PIP's have been released for SAP and JD Edwards but they are not as robust as the EBS PIP. Much work still needs to be done here as many companies still rely on custom programming and other third party solutions to achieve integration. This is true for the majority of PLM platforms. It is difficult to find standards given the rivalry of the vendors and the variety of tools and technology.
RSS feed for comments to this post.