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