Sorry for the confusion on changing the setup of this site, but the layout I had was not conducive to having tables and images. This new layout allows my content onto the site much more cleanly. Now that this is working better I will be updating some of the older postings to make the images more legible.
March 22, 2007
March 20, 2007
The Key Differences between PLM and ERP in meeting corporate objectives
There is a historical tension between a corporations need to innovate and its need to produce. Fostering innovation is not possible within the rigor of production demands and successful production practices are not possible within the highly flexible framework of good innovation. This tension has been studied and analyzed over the years. The conclusions of the studies are that the most highly successful companies in the areas of both innovation and production, are the companies that embrace both sides of the coin – fostering a culture of innovation while observing the required rigor within the production framework.
When this is understood it becomes more clear why PLM and ERP system MUST support different corporate needs:
It is these very differences that show it is a myth to believe that the systems designed to manage your physical inventory with rigor and structure, could be manipulated to become the flexible systems needed to foster innovation. The PLM vendors don’t even pretend to do the business of ERP systems – why is it that ERP systems believe they know how innovation in design should be managed?
Copyright 2007, LR Hirr
March 14, 2007
Top level criteria for PLM System Selections
There are many readily available references to ERP Selections, CRM Selections and so on… The principles are generally the same for PLM. First and foremost – technical requirements and technical qualifications are not the ONLY criteria by which to judge a system. Neither is price. The canned demonstration is also not the best means to select a system (it’s too easy for vendors to use smoke and mirrors).
Generally when we examine solutions for the customer we make sure the following criteria are included in the analysis and we work with the customer to assess:
Technical Qualification – The technical qualification is still a first qualification and always will be. But the qualification should be based upon a clearly defined requirements matrix that the vendors must show evidence of meeting, making distinctions between out of the box functionality, configurable functionality, and customized functionality. Requirements should be weighted based upon business need and vendors should be evaluated with regards to those needs. Do not use the canned demo as evidence of meeting the requirements. Walk thru every requirement in detail with the vendor showing you exactly how that requirement is met.
Business Standing – How long has the vendor existed, how have they funded growth and development? What percentage of the customers are paying maintenance (i.e remaining current)? If publicly held – what are the analysts saying. Are their customers in the same industry verticals as your company or are the customers similarly modeled as your business? Will the vendor be there for you in 5 years? in 10 years?
Customer Support – How well are the customers supported? How is helpdesk support provided for you as a customer. What forms of training are available? Is there an “active” user community and how is it controlled/supported by the vendor? Are there local groups or readily available forums for end-users, administrators, etc. Are there larger events where training, exchange of experiences, and networking is supported?
Referenceable – Does the vendor have referenceable customers in your business sector or of your business size, using versions of the system you would be considering? When a vendor gives you a reference name it is often an executive who purchased the system, ask to speak with members of the deployment team, and to end users – that is where you will get the real story. How long has that customer been a customer – are they actually in live production use of the system or are they still in the honeymoon of getting the system set up?
Roadmap – Does the vendor’s roadmap provide a path for your company to grow with the vendor as a “partner”- what happens with your data when you “outgrow” the current toolset. Are there modules that scale with your business growth? Does the platform support appropriate technologies to remain current on your overall enterprise infrastructure requirements? How has the vendor demonstrated commitments to past roadmaps?
A system could meet every one of the technical requirements and come up severely lacking in the other criteria and without a thorough examination of all aspects of the relationship you could be throwing good money into a system that will fail due to the non-technical aspects listed above.
Copyright 2007, LRHirr
