Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Engineering Change Requests - ECR
michael_bromley
Member Posts: 110 PRO
In the past I've used separate systems to track engineering design change requests. Essentially a ticketing system such that the proposed change, implementation, and verification that the change occurred could be tracked in a central location. It would be nice to integrate all of this into Onshape as I believe much of the framework is already there. We could use the comments tasking feature to propose the change and assign it to an engineer. They can mark it as resolved and even potentially respond with the release that the implementation is contained within. The missing piece is getting a high level view of this. The change requests would exist in all different versions and across many documents.
I'm proposing a query on the main dashboard that could filter out these "Change Requests", show the status, related part(?), document, version, and assigned person. I believe this may require an additional piece of metadata in the comments to select whether or not it should be considered a change request.
Thoughts?
I'm proposing a query on the main dashboard that could filter out these "Change Requests", show the status, related part(?), document, version, and assigned person. I believe this may require an additional piece of metadata in the comments to select whether or not it should be considered a change request.
Thoughts?
6
Comments
I would also like if these change requests could then be referenced in the release candidate creation form. That way, we could have full visibility to when changes were requested, implemented, and then actually released.
If an ECO numbering system can be configured (like part numbers), as well as a few status codes (change request > change order), and other things like Change Class (Document only / Interchangeable / Non-Interchangeable) and Change Type (Meet product spec / Exceed product spec / Reduce Costs), that should provide a lot of capability to filter and track the requests.
Imagine if the change request/order process can be graphed out with Onshape to track volume of requests/changes processed, average number of days from change request to change released (or request declined), and track and record information relevant to the request all the way through (discussions, markup, photos, etc.), with change numbers automatically populated on new or revised drawings, automatic notifications to requestors upon status changes, etc.
A few years back I made an improvement request to Onshape (for something entirely unrelated to this), and then promptly forgot about it. Half a year later this improvement got implemented in one of the regular platform updates, and on that very same day I received an automated email informing me my request had been added. That demonstrates to me that Onshape themselves must be using an excellent change request tracking system, and hope they intend to apply functionality just like it in the core Onshape platform, for engineering design change requests.
Twitter: @onshapetricks & @babart1977
Twitter: @onshapetricks & @babart1977
Add to that the torturous process of trying to keep Revision Tables up-to-date in drawings, and it's far too much work.
Maybe the pure joy of the rest of the work with Onshape makes up for it though!
To the external tracking of ECO (or in my case, just part numbers): I use a Google sheet for that. Since I had to do so in SolidWorks, I have continued it now that I'm doing all new work in OS. That Sheet is fast and easy to search to find a part number. Easy to put links to the OS document that the part was created in, too. Makes an easy place to start looking for CAD if I come across a physical drawing, or someone references a part in an email. For now, I'm the only CAD user in my organization, so tracking ECR / ECO are less important that part numbers / relationships.
Hopefully the Onshape team is working on something to take care of all these things!
There is a really easy way to update all the drawings in a document:
Click add version up in the top left corner.
Click update drawings.
Click cancel.
IR for AS/NZS 1100
Yeah - I'm familiar with that one for updating the referenced part in all the drawings.
I was talking about adding the revision rows, description, changing "in progress" to "released" on the last row after I've done the release etc. The revision table workflow is entirely manual right now, and it's a lot of work to keep it maintained properly. The Revision table is very important for me for long-term ongoing projects...make sure I can piece together what the state of a part was at a given time. (I know I can look at the Onshape doc, but literally nobody else in my company can do that, but everyone can find a Released PDF of one of our parts).
I have an IR about this here: https://forum.onshape.com/discussion/11564/revision-table-automatic-behaviour#latest that might explain it a bit better.
I agree that having a dashboard or some other high level view outside of the documents would be great. As others have mentioned though I would want the ability to tag specific parts, assemblies, etc. with the change request as applicable.
@brucebartlett we struggle with that as well. We also run into the scenario where someone will assemble a big release package after a design review has been completed. Then one small error is caught in the review of the release package and the whole thing must be discarded or rejected and then compiled and resubmitted.
Although Onshape could handle these types of requirements, there are Form and Workflow products out there that cannot only handle this, but are extremely customizable to your own requirements and needs. Onshape provides a very robust Application Programmers Interface (API) that can be used to Create, Read, Update and Delete almost any content within Onshape. Putting this together with the Forms and Workflow provides an unlimited set of options for not only managing data within Onshape but the ability to implement any type of business process, including ECR, Release Management, New Product Introduction, etc. A perfect example of this is ERPlinc, which can be found in the Onshape App Store. This product would be ideal for this type of process having the Form and Workflow capabilities as well as the direct integration with Onshape.
our ECR process is very simply.
ECR number (scrolling Auto generated number)
Reason for the Change
Revise and release CAD parts and drawings.
Approver Validates physical parts to CAD.
I also have the question where do you start the ECR process, can it be tagged to the release candidate.
Or does it need to be separate, do i need to create a category for this ECR process.
To be true full i'm lost with all of this work flow .json files, i understand how they work (sort of) but i don't understand how to implement them correctly.
I've created all of the Custom properties but where do i go from there.
Any help or a point in the write direction would be of great help.