Advanced: using Release Management (PDM) AND a PLM system side-by-side

andres_dandler

Hello all,

This might be a little advanced for some, but I hope it triggers a good discussion that I can learn from.

We are are medical device company and we use a PLM system (Propel) company-wide to release documents officially (not just drawings, but ALL company documents, down to purchase orders and employee training records).  The PLM system is the official record as far as our Quality Management System (QMS), and it's subject to FDA audit.  That's where we generate part numbers, route ECO's, and handle approvals company-wide.  The Onshape database, even including Release Management, is not part of the QMS.  However, we are using Release Management in Onshape as well.  (I have done this in past lives, using for example SolidWorks PDM in conjunction with Agile PLM or Omnify PLM.)

I'm writing the procedure (SOP) for us to do this, but I was wondering... is anyone else out there using both?  Any chance we could discuss your SOP?

The trick is how to keep the two databases synchronized so that the revisions match.

My method is as follows:

1. Create a Rev in Onshape.  Make sure everything is tip-top including drawings and their BOM tables.  This can be tedious especially when it's an assembly with subassemblies and lots of parts, but so be it.
2. At the same time, I put together an ECO in the PLM system, making sure I'm correctly getting all of my part numbers, revisions, and BOM structures.  I upload PDFs of the drawings, as well as STEP files of any custom parts.  Note: I do not use the watermarks on drawings.  In my revision table, I have an approval box, but it just says "See ECO" because that's the official QMS record.
3. Once I'm comfortable that there's perfect agreement between my ECO (in our PLM) and the Release (in Onshape), then I FIRST kick off the Release in Onshape and push it into approval.
4. In the Release, I ask my colleagues to review and approve through Onshape's Release Management.  IMPORTANT:  The trick is that I ask my boss to act as the "gatekeeper": I ask him NOT to approve it in Onshape until it's been approved in PLM.  (I will explain the importance in a few lines below.)
5. If any of my colleagues (or my boss) reject it in Onshape, then I can go back into Onshape and fix whatever needs to be fixed.  The ECO in PLM is not in circulation yet, so it can also be updated if necessary.
6. If all of my colleagues approve it in Onshape, then I ask my boss to review it as well.  If he approves it, I ask him to just send me an e-mail, but NOT approve it in Release Management yet (see point 4 above, about the "gatekeeper").
7. Now I submit the ECO in our PLM system for circulation, review, and approval.
8. The best outcome is if the ECO is approved without any changes.  If that happens, then I ask my boss to go ahead and approve in Onshape as well.  That way, the two systems progress to the new revision in a synchronized way.
9. If the ECO in PLM is rejected, that's OK because I can go back into Onshape and make changes, because the Release was not approved yet!  That's the beauty of the "gatekeeper" concept, as tedious as it is.  So I can go back into Onshape, make changes, then go back through the cycle starting at step 3 above.

I have found that this is a good way to keep the two databases synchronized.  Otherwise, if either the ECO or the Release gets approved before the other, then you can have the two revisions get out of sync, and you have a mess.

Are any others using any similar system?  Is there any other way to keep the revisions synchronized when the two systems are not actually talking to each other?

Thanks!

  -Andres

Jolly

I think that system makes sense. At a prior company with Solidworks, PDM, and Oracle we did something similar. It is tedious but not more tedious than correcting errors by going through an additional revision step and justifying why "revision C" was bad and was done because things got out of sync.  Most of our prior processes were digitial, but each ECO had a paper copy with a checklist of the order of things.  Keeps it simple and the checklist would get passed around to the appropriate people.  Generally one person (me for a long time but not at the end thank goodness) was the primary pusher of the "Blue ECO Folder" to get people to finish their parts. 

tim_hess427

We're trying to work through a similar issue (also medical device). However, instead of having a PLM system, we are using a paper-based QMS. It generally works like this:

1. create drawings
   
2. create ECO
3. iteratively review ECO and draft Drawings to make sure everything is good and everything matches.
4. Create and release revision in Onshape (not officially reviewed/approved at this step)
   
5. print PDFs, attach to ECO
   
6. approve, sign, and file ECO. 
   

@and@andres_dandler - I thought that Propel had some way to integrate with Onshape directly. Does that not help in this situation? 

I really think there's a lot of potential to integrate things like this, but some roadblocks I've found are:

• When all documents (not just drawings) need to approved/controlled, it can be tough to implement two separate types of approval workflows: one for drawings and one for other documents. 
  
• For a small company, it seems unreasonable to pay for a whole CAD license just so that quality manager can approve some drawings. 
  
• without upgrading to "enterprise" the release workflow isn't very customizable.
  
• The need to validate any computer system used in the document control process and meet FDA digital signature requirements. 
  
• Audit trails without upgrading to enterprise. 

andres_dandler

@Jolls, thanks for the discussion!

@tim_hess427 , your process seems similar to what I've been doing.  Do you mind if I ask you to elaborate on a couple of points?  

• Could you explain what happens if someone rejects the ECO during your step 6?  That's when it gets circulated not only to the engineers, but also to others in the company.  Someone might reject it for whatever reason.  If you have already released the Onshape drawing (your step 4), then you would have to pull it back to unreleased in order to make changes, right?  I'm not sure you can do that in Onshape (at least I know that you CAN'T do that if you're using Onshape's "release management" functions.
• Are you using watermarks of any kind on your drawings?  I don't.  And by watermark I mean anything that indicates the   In my magical dream world, I would have a watermark on my PDF drawings that says "unreleased".  However, as soon as the ECO is released in PLM, that watermark would disappear!  (But without changing attachments - that's the rub!)
• How do you store CAD files if you’re paper based?  CD-ROMs like in the ’90’s?  Floppy disks?  :-)

And about your bullet points:

• Yes, you’re right that it’s weird to have 2 workflows.  That’s why we’re top professionals!  :-). But actually in the ideal world there’s just one workflow, even if it crosses between two systems, like Onshape + PLM (as QMS), or Onshape + paper QMS.
• I agree with you that it’s not worth it to pay for a license just so that Quality people can approve Onshape releases.  I don’t think the free license allows for approvals, but it should!  I can’t remember what we’re doing, but I think we give the quality people a free license, and they can (not must) review the CAD as part of their approval.  Then their approval is captured in the other system (paper QMS in your case).  How many licenses do you have total?  (Just curious.)
• We’re not on ‘enterprise’, so we’re trying to make the standard Release Management workflow work for us.  I think it will be OK but we’re just starting now to release drawings.
• YES!  That’s a sticky issue about validating software systems, but it doesn’t have to be.  That’s the main benefit of the system I explained in my posting:  the repository of record is the PLM system, and that gets audited;  the Onshape database (or any PDM) is NOT.  That’s why we have to put STEP files into the PLM, as well as PDFs of the drawings.  (I should have written that explicitly in my posting.)  I’ve been doing it this way for 15 years with various CAD and PLM systems, and it passes FDA scrutiny.  (Class 2 and 3 devices).
• Audit trails: Your ECO and DHF system (part of QMS) should be enough, right?  Keeping the CAD database outside of the QMS solves a lot of problems.  You just need a good repository for “static” CAD releases, like STEP or IGS files of each revision.  (NOT source files that could be modified like .sldprt files!!)
• And about Propel and Onshape's integration:  I’ve had several conversations with Propel and Onshape people about the integration between the two systems.  It seems that at the moment that is mostly aspirational, not actually fully implemented.  The last time I spoke with them was bout 6 months ago, and at the time the only integration was that you could have part numbers generated through Onshape, but actually pulled from Propel.  OK, that’s nice, but that’s a small benefit (and they wanted extra $$).  I would LOVE for a good integration between the two.  I’ll ping them again.

If your company is thinking about implementing an electronic QMS, I do recommend Propel.  It’s very good and easy to use.  Omnify (now acquired by Arena) is also very good but a bit older.  Agile PLM was awesome, but also older and very expensive (at least at the time).

Thanks for participating in the discussion!

Have others implemented similar workflows bridging PDM and PLM systems?

  -Andres

tim_hess427

Hi @andres_dandler, 

It's helpful to me to read your description of the system you're using. It does sound very similar, except or system relies on killing more trees. 

To answer your questions:

• In our process, we sometimes use the terms ECN and ECO interchangeably. So, really, I should have used "ECN". Before anything is "approved" in Onshape or on the paper ECN, everything is reviewed by all appropriate people in the draft state. Once everybody is happy with everything the paper ECN is signed and the onshape drawings are released "simultaneously". Its not fool proof, but it works OK with a small team where there's only a few people that have to review the documents. Also, we fill out the Rev tables on the drawing manually, so if the revision listed in the Onshape properties was different from the revision listed on the PDF drawing, the PDF drawing would be "correct" because it's the controlling document in the paper system. It would just be confusing for people working in CAD. 
  
• We use watermarks in Onshape only. And that's just in case somebody is looking at a drawing in Onshape, we want them to know if its unreleased or not. The ECN paperwork is all done in microsoft word, printed, signed, and then scanned as pdf. 
• For drawings and documents, we keep paper files and PDFs on a server. 3D models are exported to step files and saved on the server.
  
• Right now, we have 2 full CAD licenses. I'd like to have one "light" license for approvals. 
  
• Your correct on the audit trail comment - our controlling system is the "paper" system and like yours, the Onshape documents aren't part of the "controlled" system. My comments about audit trails and validation were looking ahead to a day when Onshape could be a part of that system and streamline some things.

Thanks for starting the discussion!

tim_hess427

@andres_dandler - A thought that came to mind today. I'm curious what you think about it.

If you're trying to keep two systems in sync, would it be easier to NOT use release management in Onshape? This way you can modify things in your onshape drawings until they are they way you like them, update the revision table manually, update the revision level in Properties, and export your PDF. Once everything is approved in your PLM, you could just go back to Onshape change the state from pending to Released and create a version. 

I've been thinking about this approach because I've run into a couple issues where the drawings look good in the draft state, but then I run into some issue in the release process that forces me to change a linked document or something and creates issues. Or, in some cases, I'm can't fully update an assembly drawing draft until the linked sub-assembly or part is released and updated, which could create other surprises. In one recent situation, someone accidently released an incorrect configuration for a sub-assembly. The configuration only controlled part locations, so the BOM was correct, but the drawing views weren't and I've got no way to change the part number and Revision to the correct configuration. If we weren't using release management, I'd be able to correct this manually.  

The downside to this is less visibility into the release history of a part while you're in onshape. Being able to search for "released" parts should still work, but you wouldn't have the helpful triangle icons throughout the UI. The upside is that I think your release process could be a little more flexible. 

adrian_vlzkz

Hello @andres_dandler, I believe there is already a 3rd party solution to integrate both system as per you describe, where PLM (Propel) is the parent, but you can push data bi-directionally

https://www.youtube.com/watch?v=Jw3Kp8Vy3Qo