PDMGuru

I'm on twitter (a bit)

2011-11-20T07:14:00.003-05:00

Hi all

I know it's been a long time and I'm still working on the PLM book (see previous post).

In the meantime I've been tweeting plm tip of day (not every day - but hopefully some are useful). You can follow me on @pdmguru

Enjoy...

Paul

PLM PDM book

2009-02-24T18:31:00.006-05:00

I've been talking about putting this together for a few years. In the early part of last year I had some discussions with one of my former bosses (while at Ford) about this.

Anyway I had some brainwaves last weekend and have a fairly detailed set of sections/chapters planned.

I think I'll post the headings etc here for comment. Let me know what you think (I'll probably add them to this post later in the week.

PLM Book

Section1 - Executive and historical perspective
- What is PLM
  - Right information for right people at right time
    - Right Information
    - Right people
    - Right time
  - So what is the difference between PLM and PDM?
- History of PLM products and ideas
  - The early days
    - Metaphase
    - Product Manager
    - IMAN/PSIMANAGER
  - Late 90s
    - Agile
    - MatrixONE
    - SmartTeam
  - Mergers/Acquisitions
    - Windchill/The "Links"
    - Teamcenter(s)
    - ENOVIA
  - Brave new world?
- Identifying ROI
  - How much does design really cost?
  - What keeps you awake at night?
  - Areas where PLM can help
  - Areas where PLM cannot help!
- Summary/Conclusions
Section 2 - The Building Blocks
- Basic data management
  - Introduction
  - Document management
  - Complex data management
  - Benefits and risks
  - Summary/Conclusions
- BOM management and effectivity
  - Introduction
  - Useful terms and concepts
    - Effectvitiy
    - Phantoms
    - Multiple views (EBOM/MBOM etc.)
    - Bucket of parts
    - Static bom (precise)
    - Non static bom(Imprecise)
  - Who owns the BOM?
    - Design v Manufacturing v Maintenance
  - Benefits and risks
  - Summary/Conclusions
- Workflow and change
  - Introduction
  - Workflow v Change Management
  - CMII benefits/risks/costs
  - Benefits and risks
    - Automation of bad processes
  - Summary/Conclusions
- Integration to other systems
  - Introduction
    - Types of links
      - Interface
      - Integration
      - One way/bi-directional
  - What should be integrated?
    - CAD
      - Benefits and risks
      - Summary/Conclusions
    - ERP
      - Benefits and risks
      - Summary/Conclusions
    - Suppliers/Partners
      - Benefits and risks
      - Summary/Conclusions
  - Benefits and risks
  - Summary/Conclusions
Section 3 - Bringing it all together
- Implementation methods
  - Why does it matter
  - Vendor v independant
  - Scope and scope creep
  - How to be sucesseful in implementations
  - Benefits and risks
  - Summary/Conclusions
- Dealing with change
  - Benefits and risks
  - Summary/Conclusions
- Methods/Post Go live/Updates
  - Getting ready for PLM
    - Selection process
    - Setting the right expectations
      - With Management
      - With Staff
      - With yourself
  - Planning
    - Infrastructure
      - In the data centre
      - Client
    - Education
      - Classes etc
      - Methods development and maintenance
  - The role of mentoring
    - Who should mentor
    - Why is it important
    - How long?
  - Benefits and risks
  - Summary/Conclusions
- Customised Solutions
  - Introduction
  - Benefits
  - Upgrade paths
  - Benefits and risks
  - Summary/Conclusions
Section 4 - Closing remarks
- Benefits and risks
- Summary/Conclusions

youtube - a great resource for PLM

2009-02-08T17:52:00.002-05:00

Hi all

So I was just thinking I'd be revolutionary and create a channel on youtube for PDM and PLM. So I added one here

http://www.youtube.com/user/pdmguru

But then when I looked round I found quite a lot of PLM stuff already there. Imagine my surprise.

Of course you need to talk all this stuff with a pinch of salt since a lot of it is pure marketing for the plm vendors etc, however instead of reading through large boring turgid whitepapers you might be able to glean useful stuff from youtube.

I'll make a survey of what's there in a few weeks and post on my website. At the moment I just grabbed some highlights including a great anti-plm one from Carl Bass the CEO of Autodesk.

Enjoy and have a nice week!

Implementing PDM

2009-02-07T16:21:00.003-05:00

Wow so I was just thinking about PDM/PLM and it came to mind a number of disasters I've seen and also a number of successes as well.

What makes the difference?

Well quite simply I think three things make s difference and here they are.

Using someone you can trust to do the implementation. It's a fallacy that anyone can implement PLM/PDM. The success of your project depends on finding the right people. This might be MORE important than choosing the right PLM tool. Be careful in your choice, a rookie (inexperienced person) is a HUGE gamble. It could cost you more than money, it could mean the difference between your company surviving and going under.
Implementation methodology and project management. Again these are closely tied to choosing the right people. Check that the methodology used is REPRODUCIBLE that they have used it before and that they can demonstrate it hits all the right areas that typically cause PLM implementations to fail; namely scope creep and user acceptance.
Finally (and no one in the industry will thank me for this) LUCK. Yep sometimes things are either with you or against you. I've seen well managed implementation with the right tools/methods etc go belly and conversely "I've seen seat of the pants" ones where everything is chaotic be roaring successes. The point here is QUANTIFYING and MANAGING RISKS. If you don't develop risk assessments and risk mitigation then you are condemning yourself. Be careful and smart

Good luck!

Recession - a good time for PDM and PLM?

2009-01-25T07:46:00.003-05:00

Hi there.

It's been quite a long time since my last post, so I thought with the global credit issues I'd drop the blog a line and talk about how this technology could help in these cash strapped times.

First of all I believe that lower costs by getting rid of employees can be a false ecconomy. I do understand it is a necessary evil, but I also believe that before doing that companies should be more creative about identifying cost savings. Some ways are not necessarily anything to do with PDM, such as asking skilled people to consider wage cuts (not popular, but preferable to losing all your salary for six months!).

However the main focus of this article is around how PLM and PDM can help. In a number of discussions with former colleagues we've discussed can the technology really cut costs. My general feeling is it can, the main problem is that most engineering companies work without realising how much time people waste looking for information. I think I've mentioned the "2 hour 20 minute" rule before; where people spend 2 hours looking for a part when it would take 20 minutes to re-create it. So if you implement PDM you would save that 2 hours. Well maybe.

First off for company manager's I would suggest looking at what time this is. I think many people would be suprised. So how can you get around this? Parts classification where you document the attributes of a part such as length, shape, function. material etc. can have significant benefits. The down side is that the results obtained are only as good as the data input. Also there is a reliance on engineering people adding these attributes. This is a difficult sell sometimes since designers often only see additional time and no real benefits. This is why it's critical to know how much time people spend looking. Some companies are now offering graphical query tools where you can draw a shape and ask the system to find similar parts.

The second part of the picture is understanding how much it costs your company to create a new part. This can be very large indeed, so being able to reduce duplication of parts can benefit companies.

Design re-use is another area where companies typically do not know what types of cost savings can be made.

Also PLM/PDM is ideal for capturing processes and insuring people adhere to these. I would say that the efficient use of engineering change within a corporation can save a great deal of money, but you will need to understand what your current costs are and also if the tool can really deliver savings.

So implementing some areas of PDM/PLM can assist in elimination of these issues. But be careful, full blown PDM/PLM implementations are expensive! So in the credit strapped times I would propose working with a good consultant or company to identify "low hanging fruit" such as part duplication and BOM->ERP transfers (see earlier articles). Once you have some savings and have built up an understanding of the technology then it would be good to move on, and maybe the recession is over by then too!

KISS - Keep it simple stupid!

2006-11-04T04:40:00.000-05:00

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 custom environments too! Some companies are held at very old releases due to the costs of moving their custom code (I've seen a LOT of these situations). It means that people are often working with buggy releases that the PLM companies do not even support anymore. This can lead to frustration in the workforce who use the tools.

Also custom solutions introduce errors on top of the ones from the standard product, these often lead to fingerpointing over where the actual problems lie, your fault or theirs...

The benefits of the KISS approach mean that you can almost instantaneously deploy newer releases and fixes.

I know most tools suffer from these issues but (along with ERP) people seem to feel a need to customise PLM tools to distraction.

So in closing please think about KISS whenever you are looking to deploy or update your data management tools...

Have a good weekend

Implementation methodologies for PDM

2006-10-08T08:45:00.000-05:00

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 well controlled. So the second question is how does the implementation methodology manage scope creep? One of the best ways I have seen is to make sure that the scope is firmly identified early on in the deployment and is re-visited frequently - in JAD (joint application development) it is agreed on in stakeholder meetings and presented to senior management at key stages in the implementation cycle. When we were working on deployments it was the first thing we did: and subsequently revisited at each checkpoint meeting.

One other problem I've encountered is companies constantly changing their methodologies - this can lead to confusion in the implementers and also means that reproducibility on deployments is compromised.

Some methodologies rely on too much documentation. This can look impressive, but can often hide the problems in a deployment. It is good to document issues and have a good statement of work (showing main deliverables and who is responsible from them); but other documentation can be redundant.

...

Weekly(ish) PDM postings - BOM Reconcilliation

2006-09-30T04:29:00.000-05:00

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 that the ERP need to populate a generic plant and then allowed other sites to copy this bill and work on it. There was no reverse transfer from ERP back.

So why bother doing this. In one word duplication! At the current time most companies - including many large multinationals I've worked with - still print out the engineering bom and rekey it into the downstream systems. This still amazes me since the tools to transfer are getting better and better.

Let's make use of XML/XSL and stop this madness.

... more to be added on this one

Useful Reading

2004-12-30T13:08:00.000-05:00

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 - The essentials of user interface design (Alan Cooper) - This classic book on interface design should be read by anyone who is developing any kind of user interface. Love it or hate it - it does provoke serious discussions of the "intuitive" user interface. It probably needs to be updated but who can argue with one of the designers of Visual Basic!

Practical CM (David Douglas Lyon) - Great book on all things change. It's interesting to read since it does not tie one down to any specific PDM system.

Bills of Material - Structured for Excellence (Dave Garwood) - Great book on BOMs, the goal being to get everyone in a company to accept working from an single electronic bom. Some great coverage of terms and case studies in here.

All I need to know about manufacturing I learned in Joe's garage (William B Miller and Vicki L Schenk) - SERIOUSLY this is a great book to introduce manufacturing terms and processes to a novice, a great intro to the dark art of making things in a competitive market. Some great coverage of terms such as KANBAN and Poka-yoke!

Bill of material Management white paper

2004-12-30T13:00:00.000-05:00

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 difficult especially when using computer-aided design (CAD) and Product Data Management (PDM). CAD and PDM use closely related but subtly different structures. A conscious effort in designing and maintaining products is needed to consolidate manufacturing and engineering into one of Bill of Materials. The resistance to this change in some companies can be huge.

A less elegant solution that is proposed by most PDM systems is to use multiple bills of materials or multiple views of a single Bill of Materials. A number of challenges arise from this solution. The major challenge is bom reconciliation. What is meant by reconciliation? Usually manufacturing Bill of Materials (MBOM) and engineering Bill of Materials (EBOM) vary significantly. Either of these two bills can be changed and sophisticated tools to compare and determine the differences are needed.

Another tool that is of great use is the ability to markup a Bill of Materials. A number of PDM tools have this functionality.

The final challenge with multiple views is which one is transferred to the company's ERP system. Should there be a specific bill for this purpose or should the manufacturing Bill be transferred?

Ownership ownership ownership!

The major problem with the transferring information between systems is which system owns data. The easiest solution is to choose one of the systems and designate that one as the master. The other alternative is more complicated because if both systems can act as the master it is harder to insure data integrity.

One idea is to keep the engineering view in PDM and the manufacturing view in ERP. In this scenario you export the engineering view to ERP and then restructure and add phantoms in ERP. Another way to do this would be to create both at the engineering and Manufacturing views in PDM and then just transfer the manufacturing you to ERP. The choice depends on

how easy it is to restructure the bill of Materials in the ERP system (this is sometimes quite difficult).

reconciliation of changes for example if the engineering view changes how do the changes get transferred to ERP? The situation is slightly simplify its both views are in the PDM system, however this depends on whether the PDM systems has a good bom reconciliation facilities.

The process of integration between ERP and PDM systems will be discussed in a future white paper.

BOM line attributes

BOM line Attributes also present a challenge. What do I mean by a bom-line attributes? This refers to Attributes that are associated with a specific line (or usage) on the bill of material. The most obvious example is quantity, quantity is associated not with the part but with the instance of the part in a bill of material. Another example is the use of "reference designators" in the electronics industry. PDM systems need to be able to accommodate as many of these attributes as necessary. Obviously these attributes must be available on transfer to an ERP system. This issue also plays into the customisation scenario that will be discussed in the future white paper.

Unsupported Systems

2004-08-28T11:00:00.000-05:00

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 stress enough that there are systems and migration paths out there (and obviously people wanting to take you money to do it :-) ) but please do it!

Choose a new system based on the track record of the company. You are going to store your company's second most valuable asset in this system so you need to know that the company will be there for a long time.

.........

First thoughts...

2004-08-08T20:01:00.000-05:00

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