The Mechanical Engineering Stack and Onshape Strategy

"What pieces are missing from our stack?"

"What data should we migrate?" "Should we be using the API or FeatureScript?"

These three questions were asked to me recently during a few consulting calls with Onshape customers. On their own, the solutions are an integration, a migration tool, and Onshape automation (by FeatureScript or API app). But taking a moment to zoom out and evaluate the bigger question has made me rethink each of these questions. The real answer and the line between each of these questions is strategy. I get introduced to companies who have already found a weakness in their Onshape strategy, but I wanted to take a look at how my experience solving these smaller problems might help others identify the missing pieces. But what I really want to do is convince you, the reader, to evaluate your Onshape Strategy.

The Stack

A "Stack" is a term commonly used in software engineering. Its a term to describe the collection of technology used in a project. Programming language, frameworks, hosting, deployment, logging - all of these are decisions that need to be made when architecting a solution. Understanding how they all fit together can define the success of the project.

While on a recent call with a customer, they showed me this massive flow chart of every technology the company was using. CAD, ERP, PLM, MRP, CRM, and a bunch of other acronyms. I had never seen someone visualize a mechanical engineering workflow this way. But it makes sense. None of these technologies exist in a vacuum. Asking the question "But how do these all fit together" is the first step in a bigger vision - and eliminating pain points.

Here is a useful exercise - make a map of every platform your company uses and the basic purpose. When data originating in one system is used in another, draw an arrow for that data flow. Some systems automatically work together. Tools like Slack, Box, Clickup, have out of the box integrations. But how many arrows are "manual data entry"? In this new Cloud era of software, manual data entry should be eliminated. Software should work together. Highlight each of those arrows - because that is an opportunity for improvement.

Breaking down Silos

Last year I attended a talk with the subject "Breaking down Silos". At the time I felt like it was typical corporate mumbo jumbo, like synergy. But I've come to realize the real message behind the slogan. Typically talking about breaking down silos is about removing barriers between teams within a company. But those silos are put up by the technologies that each team uses. When only the design team uses Onshape, the downstream teams that need that data become reliant on them and the technology they hold the keys to.

The best way to break down a silo is...integration. Ensuring easy (and accurate) data flow between teams is what I think the real take away is. Breaking down silos isn't about getting people to be friendly to each other - most people are just fine working with others. Friction comes from what is being requested. If data flow is a pain point, the relationship representing that flow will suffer. If I had a criticism of Onshape, it is that data doesn't flow out of Onshape very easily - at least not out of the box. The only standard integrations are dropbox, google drive, and one drive.

Onshape's API on the other hand gives incredible opportunity for breaking down silos. Here at SmartBench Software, we regularly connect Onshape with all sorts of technologies. Onshape to ERP being the most common, followed closely by file repositories such as Box. Connecting Onshape with other systems allows designers to easily grab new part numbers without leaving Onshape, Sync BOMs for accurate data (maintaining a single source of truth!), saving time and reducing errors.

Migration

"What do we do with our 200,000 files?"

Many Onshape customers are not new companies. Companies are dropping their out-of-date, desktop burdened CAD systems to make use of everything Onshape has to offer. Making that decision can be tough because it requires a rethink of the entire stack, but the biggest hang up is legacy data. Years of CAD data can't just be thrown away. So what can be done with it?

Migration between any CAD systems is made additionally difficult by the fact that parametric CAD files are almost always in proprietary formats. Migrating can mean a loss of design intent, configurations, and other platform specific features. Add to that the time and effort to actually move the files. CAD migration isn't something that can happen in a day. Making a migration plan is imperative to prevent project delays, data loss, and frustrations in the team.

As someone who was development lead on two different (now defunct ☹️) Onshape Migration products - I've learned the challenges in this area. The start to any migration strategy is to ask the following questions:

• Which files should be migrated, and which should be made natively in Onshape

• How to handle configured files?

• Import just parts or parts and assemblies?

• What metadata is critical?

• Is our metadata consistent? Is there missing data? Should the metadata be updated to a new standard?

• How should data be structured in Onshape? Do we keep folder structure?

• Do we migrate drawings? Do we export PDFs, DXFs, or other formats?

• During long migrations - how do you maintain a source of truth between the legacy system and the new Onshape implementation?

• Do we import everything at once or just files as we need them?

• How much time do we have? How long will it take? How many files do we have to move?

• Is there an opportunity to fix old mistakes?

Migrations require a lot of prep work and decision making up front because you only do it once. Its possible to take your time and start slow, but files are going to be imported once, and never again. Its not something that can be iterated and improved upon. There is some element of risk getting it right the first time, because having to redo a large migration could mean a loss of weeks or months of time.

Here are a few tips for tackling migration

• Remodel the highly configured, highly used models. Parts such as fasteners should absolutely be modeled natively in Onshape. Start off on the right foot by leveraging Onshape's powerful configuration system.

• Use a migration tool. Manually uploading files will make a mess, create duplicates, and waste a ton of time. SmartBench Software offers customized migration tools to fit your needs. Moving to Onshape is a clearing of the slate for many companies, don't bring past mistakes with you!

• Import as you go. It is tempting to just import everything at once, but unless you have a small file count, that could be difficult. Onshape has limits to its API and uploading all 500,000 files could take a very long time. As part of your strategy, decide what to prioritize in migration to ensure that designers aren't waiting for what is actually being used.

Automation

Seems obvious, but if you have automated processes in your legacy system, you'll need to move them into Onshape. But a Macro and a FeatureScript aren't one to one. The technology is quite different, and the solutions can be too. It can take some knowledge of FeatureScript and the API to know what the correct solution is, but if you need help - SmartBench has you covered.

Part of an Onshape strategy for customers moving to Onshape is not just to look at what is currently being automated, but also what could be automated. FeatureScript and Onshape's API opens up new opportunities for both what is possible to automate and what is economical to automate. Geometry automation in desktop CAD can be a challenge, where as FeatureScript can make it trivial.

Like the exercise with evaluating your "Stack" - what tasks exist within your Onshape process? Which tasks lead into other? Which get repeated the most? Where do the most errors exist? Evaluating what can and should be automated is an entire rabbits hole on its own. What I am going to leave the reader with is - take some time to zoom out and evaluate the greater picture of how your company is using Onshape and ask the simple question - how can we do this better?

Migrations, Integrations, Automation

These three pillars are what I built SmartBench Software on. Onshape is a great platform and I believe is the future of CAD. But one size is never going to fit everyone. Take a moment and evaluate how Onshape fits into your companies bigger picture, what silos can be broken down. New technology like Onshape sometimes requires a rethinking of the entire engineering and design process, but that just means your Onshape journey has an upward trajectory.

Interested in how you can make the most of Onshape, or break down silos with an integration? Reach out to caden.armstrong@smartbenchsoftware.com.