Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. 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.

Workflows?

pete_yodispete_yodis OS Professional, Mentor Posts: 666 ✭✭✭
Are Workflows in the plans for Onshape in the data management side of things?  I would assume they would have to be.  If they are, could you provide much more flexibility for changing workflows of designs.  EPDM is quite rigid in this.  I'm not familiar with other programs, but I'm thinking of a scenario where one company purchased another and the data has to be moved from one Onshape account to another.  Exactly how the data moves from one workflow to another (and rev scheme) should be much easier than current systems.  It seems as if current systems never really planned for this event.  It would be nice to see Onshape plan for this accordingly.  Even if the workflow and rev scheme was altered internally in a company - the data should be easily adaptable to new schemes.

Comments

  • Jim_AndersJim_Anders Member Posts: 24 ✭✭
    One of the things that always bugged me with CAD system vendors is the lack of "what are my options in real-world scenarios" documentation.

    CAD systems and associated PDM/Workflow systems are flexible and accommodating by design - and that's a good thing - but when someone is starting out with an implementation it always feels like you're on your own.  So, if you ask a question about workflow or file/part/drawing naming conventions, or revision handling or whatever, you seem to get non-committal and vague answers from the support/training folks. It's all too common to hear CAD managers/users complain how they only wish they knew then what they know now when it comes to initial setup.

    Onshape will present new paradigms for design and collaboration that will take awhile for most to fully comprehend the downstream implications.

    Therefore, I think it's real important for Onshare documentation/training/consulting to provide numerous real-world scenarios that illustrate the range of deployment options or usage workflow patterns that are deemed most likely to occur.

    The watered-down white papers one typically sees about Company XYZ and how they're using this new capability are all too often marketing puff pieces and don't really help with implementation.

    Perhaps there's a scenario of an independent design engineer working alone?  Or a small company where there are multiple design engineers adding their own section to a design - or working together on the same section?  Or a big company with an pre-existing CAD environment?  And for each case, specifically, how did they set things up.

    In any case, I think it would be helpful to have fictional narrative scenarios to show and explain the capabilities.  Maybe this is a separate document or maybe it's a "sidebar" type of thing that comes up with a specific command/capability in the documentation.

    And yes, with the disclaimer that this is only an example designed to get one thinking about the possibilities and consequences.

    -Jim


  • caradoncaradon OS Professional, Mentor Posts: 300 PRO
    edited November 2014
    Funny anecdote from yesterday...

    We had one of our SolidWorks/EPDM VAR consultants come over to implement some major workflow changes.
    At one point he tried to explain how to 'branch off' (those literal words were used...) a design, so multiple users could work simultaneously & independently on their own ideas. It went something like this: 1) Copy tree original design to a new file structure (any parts & assies that need to be branched), 2) repeat copy tree for any other branch, 3) work on ideas, 4) select idea, 5) delete original design files (only those that were branched to start with!), 6) rename files of best idea to original design, 7) set other ideas obsolete... The whole process sounded so convoluted and manual (error-prone?). He must have wondered what I was thinking when I was smiling all the time... :)
    Oh, obviously he didn't even talk about merging...

    Onshape should make it very, VERY clear to potential customers how much easier, more intuitive and more robust such workflows are in Onshape compared to mainstream PDM systems.

    Dries
  • lougallolougallo Member, Moderator, Onshape Employees, Developers, csevp Posts: 2,004
    @DriesV‌ So that is disturbing. I wrote EPDM addins and did consulting on EPDM since 2001 (Conisio) and using CopyTree for any of those situations is a BAD idea.  EPDM does linear versioning so there is no BRANCH. Making copies is the reason people go to using PDM in the first place. 

    I agree that our mission is to show the auto-versioning nature of Onshape while making collaboration as seamless as possible.  Bottom line, if you build it, you won't lose it.
    Lou Gallo / PD/UX - Support - Community / Onshape, Inc.
  • caradoncaradon OS Professional, Mentor Posts: 300 PRO
    @LouGallo‌
    "using CopyTree for any of those situations is a BAD idea."
    That's what I thought too.
    I guess it's the closest thing to branching in EPDM.

    Dries
  • pete_yodispete_yodis OS Professional, Mentor Posts: 666 ✭✭✭
    I can see some of the inherent advantages with branching baked in the cake with Onshape.  I see Workflows as something needed when an organization wants to structure and control the process of numerous folks working on and changing designs.  Workflows or something similar are probably another layer above the current workings of Onshape, but important in how they interact with the foundational level items.  I could see Workflows automatically creating branches on a design as part of a process that companies can customize themselves.  Would I be off base here in my thinking?
  • lougallolougallo Member, Moderator, Onshape Employees, Developers, csevp Posts: 2,004
    @PDY No. Not at all.. Workflows will be necessary to enforce process.  It is the versioning that can be utilized by the design side to capture and iterate on the designs.  Versioning is what was always frustrating with linear systems since it was a game of leapfrog if someone started to work outside of the PDM safe zone.

    Workflows could then apply a layer of process over the version capabilities of Onshape to allow for Revision lock down.  

    Since Onshape is always capturing history and allowing manual version creation, the risk of missing a true Revision capture is less.  Adding Workflow can then enforce that capture while the document continues to evolve.  Of course you could have it lock the file from further edits if that was the intent of the company.
    Lou Gallo / PD/UX - Support - Community / Onshape, Inc.
  • pete_yodispete_yodis OS Professional, Mentor Posts: 666 ✭✭✭
    @LouGallo Thanks.  It seems like the pieces are in place then for something far more flexible and powerful.  Branching with versioning seems to be the difference maker.
  • lougallolougallo Member, Moderator, Onshape Employees, Developers, csevp Posts: 2,004
    @PDY We hope so!
    Lou Gallo / PD/UX - Support - Community / Onshape, Inc.
  • pete_yodispete_yodis OS Professional, Mentor Posts: 666 ✭✭✭
    So, I can assume that because there is flexibility with the underlying structure that changing Onshape designs from one workflow into another workflow (when Workflows become released to us) will be no problem?
Sign In or Register to comment.