I have just started work for a small company that needs a system for issuing part numbers, and handling engineering changes/controlling drawing revisions. Has anyone used a software application that they would recommend? Thanks
How small is 'small'?
How many designers/Creo users do you have?
Is there a lot of sharing of parts between assemblies?
Certainly Windchill PDMLink Essentials can handle it, but it is still a system that needs someone to understand how it works.
I am the only Creo user, though with expected growth, there may be a couple more in future years.
I used Windchill at my last employer, and I think it would be overkill for this company. And, I didn't like it.
I don't think we are ready for a vaulting system; I need something fairly rudimentary system that can either issue or record part numbers and handle simple change orders and track revisions. It needs to be something to prevent multipe uses of the same part number and a way to check the current revision of a part/drawing.
Without a Windchill baed solution, PDMLink, PDMLink Essentials or Intralink, you are left to rely on manual entry into a secondary system for that data. The PTC Cloud Intralink is still Windchill-based.
Excel spreadsheet is the easiest or with some [programming, Access DB can handle most of what you want for tracking purposes.
I am from the world before computers. Engineering change orders where managed by redline paper documents. These became the document master until such time that the drafting group could incorporate the ECO onto the drawings. This is pretty much the system I've adopted for my sole propriertorship company. Maybe not as formal but certainly looking at it from this perspective. Therefore, a "plan" for incorporation of the change is the real key, not the CAD system by which you actually do the work. There are a lot of other considerations when it comes to history storage, data reliability, master repositories, etc. but as to the actual incorporation, there are few trick within Creo to make this manageable. Just know one thing; you will be highly reliant on how Creo manages In-Session data. Crashes in the middle of an ECO incorporation can be very time consuming.
I keep all revisions with the exception that the historical drawing file may not pull up exactly as they were stored. This would require a lot more data storage and a lot more data manipultion. The master of previous and superceded revisions will always be the released PDF. There is little justification to ever go back to an obsoleted revision of a specific part or assembly. I say this with one caveat; you must follow one of the conventional procedures to creating and managing engineering change orders. The latest that has worked for my clients is "bin compatable" when it comes to part number change vs. revision generation.
This is obviously a huge subject within Creo fo those of us who really manage a few seats. Is there a S/W solution... I doubt it. I find diligence and awareness go a long way to managing very large projects within a small group.
For most small groups of designers and engineers, the companies I have run across create their own custom solutions composed of:
I don't know of a solution that fits a small companies needs. Maybe something based on Microsoft Sharepoint would work...
We are a small company also, and years back I was tasked with this problem. I looked at purchaseable software solutions, but found that they were very expensive and not really suited to our process. We couldn't justify the massive outlay of capital you need to set up a Windchill server. So, I wrote my own, using a database server and a Java application. It's worked for us, handles all the pertinent documents and their changes. Not an off the shelf solution, but when I need software updates I find the developer rather accommodating.
Could you please explain a bit more in detail how exactly are you doing this? We would like to implement something similar..
It's not a simple thing to explain, but the gist of the method was:
(1) Figure out what data you really want to be storing for the drawings (and other documents) themselves. Stuff like title, author, date, etc. Try to make as many things as possible auto-filled out when someone enters a record (i.e. use the date on the system and the username as default values)
(2) Look at revisions for documents, and set up what kind of data you want for those, too. How can you automatically update revisions (i.e. -, A, B, C, ...) when a change to a document is made.
(3) Pick a database program to serve as the back end. I like MySQL because it's the most solid piece of software I've used.
(4) Map out what kind of tables and columns you're going to use to represent the data you specified in steps 1 and 2.
(5) Pick your language. I used Java, mostly because there are a lot of nice libraries of functions available and it's portable, etc.
(6) Get the interface module (API) for the database server you are running, so you will be able to access your database programmatically.
(7) Write tons and tons of code to handle the database manipulations, user interface, and all the other functions you need. The hardest part of this and most programs is making the interface easy to use but powerful enough to do somewhat sophisticated operations. And, despite all your best efforts, a user will inevitably do a bad thing that you will say "but, WHY would you ever do that?".
(8) As with any such complex undertaking, I learned that it's best to take the time on the front end to really get the database tables as small and efficient as possible, and put as much error checking (and prevention) as possible. Comes from past programming efforts where my co-worker who tested my stuff was a hilarious purposely mischievous user. It was a game for me to thwart his efforts to break things. Fun stuff.