PDMGuru

I thought I'd jot down a few lines about KISS. It seems like people develop a red mist before their eyes when it comes to tools such as PDM/PLM. They don't look on them like Microsoft Word and prefer to customise the heck out of the tools. This does have distinct advantages such as adherence to corporate processes etc. In my opinion, though, people tend to forget about the long term costs of the custom solution. I've worked with a few PDM companies that have taken a long time to see the error of their ways, now producing "tailorable" tools that are out of the box (OOTB) with some things that you can change without the need to resort to coding. The major costs for companies that adopt the custom strategy is long maintenance of the solution. Each time a new major release comes out (about once a year for most of the companies in the field) you need to do some major effort before you can deploy the solution. Often interim releases require large efforts to deploy ...

In my 15 years of using PDM I've seen lots of ways of implementing PDM/PLM. These vary from no methodology to rigorous ones. The first question is why do you need an implementation methodology at all? The reason you should use one is quite simple - reproducibility. Most people will probably choose a partner to assist in their deployment - often this will be the company that sold them the solution, or it may be a partner of the software developer/supplier. In this case it is essential to be sure that the service you are paying for has some track record of success. If a company does not use a methodology to deploy their solution it will be very hit and miss as to whether your implementation will be a success or failure. The main failure of PDM implementations is scope creep. The technology lends itself to overstretching and too ambitious views of what is achievable in an initial implementation. So a good choice of methodology would be one where the scope of the implementation is...

I've deceided to try and write something interesting about PDM each week or so if I can get round to it. Since this is the first week I've decided to look at something that gets very little attention from the PDM companies but I think is fundamental for getting ROI from PDM/PLM; that is bom transfers. The physical process transfering a bom from one computer system to another is not too challenging - the main problem is the possesive nature of the BOM. Engineering people have their view of what should be in the bom and also manufacturing. I refer to a great book (now sadly out of print) Called "Bills of materials: structured for excellence" this is a great bbok arguing for one consolidated BOM for a company. In the book the author outlines the rationale that it is feasible to have one bill in a company. In a previous job I wrote a link between a PDM and ERP system, we basically minimized the overlap to simplify the process. Basically we transfered the minimum data ...

This page lists a number of great books on areas related to PDM(later I'll add links to amazon.com or maybe not !) Rapid Development (Steve McConnell) - Wow what a great book this is. It discusses all kinds of issues associated with development of projects. There are some great case studies of classic mistakes and a section describing a wide range of methodologies you might encounter out there. Palm Pilot The ultimate guide (David Pogue) - This book is a must for anyone with a palm. It covers a great deal of operating the palms, a history of the palms but the greatest thing is a CD that contains hundreds of applications for the palm, some are shareware and other demos. Crossing the chasm (Geoffrey A. Moore) - This book is a great read for any company that has reached the point of selling into mainstream market after having sold into a technical "niche" market. This could be applied to the PDM industry in general....... About Face - ...

Introduction Any company that manufactures a product probably has a bill Materials, or more likely more the one. How the company manages this information is crucial to the success of the company. At a seminar a long time ago I heard a speaker ask "Who owns the bill Materials in your company?" Some people answered engineering some people answered manufacturing and other people answered configuration Management. The speaker said, "Actually the correct answer is the company owns the bulk material!" The bill of Materials is the company's primary asset, if it is lost or corrupted the company is out of business! How to structure? The classic answer to Bill of Materials is to keep it simple. This is often more easily said than done. I would refer the reader to a great book called Bill of Materials structured for excellence. In this book the author discusses how company can manage with one Bill of Materials. For some companies this is very difficul...

As time goes by it never ceases to amaze me that companies find themselves in the position of having their corporate information in an unsupported legacy system. I plead with people to make sure they do not fall into this situation! Many companies have merged/gone out of business/change focus over the years and sometime it can be hard to justify embarking on huge migration projects "just to stay where we are". My suggestion is to be proactive with senior management and convey to them how much intellectual property is tied up in the unsupported system. The simplest way to do this is to develop a risk mitigation plan. The contents of this should address What are the likely failures of the unsupported system The probability that each will happen The action to either mitigate the risk occuring or correct the problem The impact the failure would have on the department and the business Do this on Monday! IT IS THE MOST IMPORTANT THING TO DO! I cannot str...

Well I figured a PDM Blog would be fun. Not sure how long this will go on for. My initial ideas are to put down stuff in here that I find out in my travels about issues in PDM or Product Data Management and PLM (Product Lifecycle Management). Stay tuned for more postings