Posts

Basic CAD data management

Introduction Since it has been a while since I wrote a whitepaper I thought I'd write a short paper on basic CAD data management. I will start with some definitions about document management and also some caveats and assumptions. CAD is always the most controversial part of PLM implementations and people are much more passionate about CAD than any other system/tool that is in general use inside engineering. Document management overview - what is it? Structured Documents There is an oversimplification that abounds about document management. When I refer to document management I mean rich content documents which are made up of multiple types of data. For example a book might be made up of several word documents (one for each chapter), there could be pictures/illustrations etc and possibly other content. Document management is the process of managing the versions of each of the items that makes up the “document” and insuring that a version of the document has all the corre

New to PLM – PLM Basics (Part No, Workflow/Lifecycle, Attributes)

Introduction While I've been working on the PLM book (still quite a way to go) I've neglected the white-papers. I wanted to write a very basic paper for people starting off on PLM adventures. In this article I'll cover some key concepts and ideas needed when you are kicking off. What is PLM So my definition of Product Lifecycle Management (PLM) is as follows. “Delivering the right information for people to do their job at the right time.” I have used this definition for a long time and I still think it holds true. I don't intend to go into details in this white-paper but basically PLM allows companies to better manage product data and share it throughout their organization. For many years companies have undervalued their intellectual property (IP) and especially the design component of IP. It makes sense to manage and utilize design data as efficiently as possible and PLM facilitates this. Main drivers for implementing PLM There are several things

Phase two of PLM

Introduction I wanted to write a paper on what to do after an initial (hopefully successful) PLM project. Clearly you want to build on what was already done and hopefully you developed a vision of multiple phases when you pitched the original PLM suggestions to the senior management team. It is critical to have a good multi-phase plan to deploy the technology in your business. Planning If you already have a multi-phase plan you should review this and see if it still makes sense. It is a good time to revisit your vision and thoughts and refine them. I'll touch on this in the next section. As with all PLM project planning you should insure that you are delivering ROI and also solving real business problems, not just perceived ones. You should do all the due diligence you did in the initial project (and more) since you do not want to break what was already accomplished! Building on initial project Hopefully your initial deployment went well. It is likely that you

ERP integration pros and cons

Introduction I wanted to write a short article on the integration between ERP and PLM systems. I feel this topic does not get enough discussion and there are some considerations you need to make on what to do and how to be successful. This topic should be read in parallel with an upcoming paper on bill of material management. Why integrate PLM and ERP So why should you integrate. In the next couple of sections I'll cover pros and cons, but before I do this some initial thoughts. Integrating ERP and PLM should not be taken lightly. It is the endpoint of the value proposition of a PLM implementation. It fully completes the circle of the product development; linking design and manufacturing. As such it holds many benefits including building what you design and designing what you build. To successfully accomplish this needs a strong arm and a lot of concessions from the two major players in the business. Everyone will need to give up something if the implementation is t

Planning PLM projects and upgrades

Overview I wanted to discuss some ideas on PLM Projects and Upgrades that I've seen over the years. I've been involved in upgrades as a developer, a consultant and even as an interested observer watching customers do their own projects/upgrades. In house or consultant? A number of factors will influence the decision of whether to use in-house resources or consultants (either vendor or independent/partner). The risk sharing of using a consultant and also the previous experience of the consultants can be very helpful. It's also helpful if your team does not have the necessary skills. For a customer who has lots of experience and proven success you would probably choose to do things yourself, unless it is a new area where you do not have experience. Cost versus risk always comes into play in these decisions too; a vendor led project can be costly, but (usually) the risks of a vendor led activity are less since if things are not straightforward they will have mor

Successful PLM approaches

Introduction I thought I'd like to put some ideas down to help people be successful in their PLM implementations. I've come up with some suggestions I've seen that have helped me in the past, also some of the unsuccessful implementations where using these approaches would have helped. Voice of the customer - insure buy in Making sure that there is adequate involvement in the process is key to any PLM implementation. There are going to be many changes to the fundamental way people do their jobs in an implementation and keeping everyone on board is key to being successful. Remember that all users of the system are effectively customers and you need their buy in for the ultimate success of the venture. All through implementation I've seen many implementations that start off including people from various departments for example during the definition of scope and requirements. But this is just the beginning. If this is the last contact with end users the project

Is it worth changing PLM tools?

Introduction I thought it would be interesting to look at why people and companies might consider changing PLM tool. You might not think it is usual but it can happen for a number of reasons. I'd like to make some comments and suggestions on how to do this. Why change Choice or necessity? Choice It might be that you realize that you made a mistake in choosing the current tool and/or it might not be fit for purpose. Clearly this is a big step and I would always suggest trying to avoid this. I'd recommend working with the current vendor to see if the situation can be remedied. It is very likely that your company has already made significant investments in the tool and training so to throw all this away should be avoided at all cost. I think most vendors would do all they could to help you in sorting out problems with the current system. It might be that there are irreconcilable issues between you and the vendor and their tool and you decide to move to another syst