Switching to Onshape: Building a Business Case

00:00 All right. Good morning, everyone, and welcome again to LiveWorx 2023. Hopefully you attended the keynote speak earlier this morning, which was amazing. To say, we're thrilled to have you join us would be a gross understatement. My name is Maureen Carroll and I am a strategic customer success manager with Onshape. I work very closely with our strategic tier of customers. Dexcom is one of those customers that I work very closely with. Today we have Adrienne Velasquez with us.

00:32 Adrienne is a CAD engineering manager at Dexcom and he's going to share with us the ins and outs of how you can make a data driven, measurable and convincing business case to justify your request for a new CAD solution. And without further ado, Adrienne. Thank you. Thank you, Maureen. We'll go ahead and get started. We had a pretty packed presentation. So this is basically our implementation strategy from like testing

01:05 and piloting early on through like a full support for a transition as our main CAD package from SolidWorks to Onshape. So like Maureen said, I'm Adrian Velasquez with Dexcom. I have about 20 years experience in the CAD space from designer admin and then manager of different teams that are kind of elevated version of what our cat admin would normally do at Dexcom. Focusing more on like the business side of the Tool Cat and PDM into into making

01:38 the most of those tools. So I have previous experience transitioning from different systems. I like my first company I worked while I was in college. It was a sheet metal shop, so that company I transitioned from like drawing sketches to AutoCAD. And then I my next company, I transitioned from AutoCAD to SolidWorks, and at Dexcom we're transitioning from SolidWorks to Onshape and then being part of PLM implementations, European implementations. So a business case is kind of a pretty common thing and it projects is nothing that

02:11 I invented. It's just kind of apply to a Cat implementation or a CAD proposal as a business solution. So I have a degree. I'm not an engineer by trade. I've been a designer and been in the design space, but my degree is in business and organizational management, so there's a lot of that in this. And I'm also Onshape ambassador and SolidWorks champion. I don't know if there's any more of those. They have those two recognitions. So Dexcom is a medical device company, about 8000 employees worldwide,

02:45 and we have a product that's a continuous glucose monitor. We're not going to be touching a lot about Dexcom and our product is again, this is more about that specific business case. So Onshape and Dexcom, we've started piloting and exploring Onshape very early on since I think pre public beta, I requested access and then we've been just gradually growing that usage from pilots. A couple of pilots we did with specific projects and then in 2019 we transitioned one of our teams that does test equipment

03:17 and design fixtures fully to Onshape. So that's a team of about 10 to 15 users on and off, and they've been using Onshape exclusively for almost four years now. And then in 2021, we put together this business case out of all those years and pilots and data that we collect from the CAD engineering team. And then we last year we, we initiated our formal transition to to Onshape.

03:47 So why a business case and what's a business case? So a business case by definition, as you can see here, is just a formal justified wide proposal to request resources or financials, financial funding for any initiative that's business related internal to a business. So in this case, the cat transition to cat implies some effort in terms of the migration or the the learning curve and also funding as far as we're shifting our funds from paying software subscription to paying

04:19 for Onshape licenses. So the structure of a business case is administrative details is just your your you lay out your sponsor, the team you're working for. This proposal. The executive summary is just a recap of everything that's in the business case, but the meat of it is defining the problem, formulating the idea or solution with data showcasing additional benefits, analyzing the risks and then justifying the investment.

04:50 So the preparation for this business case and why it might be kind of special is because it's data driven, leveraging data from our existing systems. So our PDM, our PLM system, any sort of measurable report that we could get from any other systems like a ticket system that we have for our team for support some some of you might be familiar with like support tickets for your kind of Onshape support your other

05:22 software or tools you have maybe, maybe from it. So that ticket system, we we pull out a report and we measure like who's requesting, what type of requests we're getting, how many requests, what teams, all of those things we're gathering daily from our CAD users. So that was the bulk of the data. We use some from PDM. We really don't have a kind of very consistent way of pulling data from PDM that we could leverage in terms of like. Though the amount of action check in, check out.

05:54 So activity basically. And then we also ran a few surveys. So that's kind of the difference between data driven, what I call or what's called like a quantitative type of data, which is something that's just number and then qualitative, that's more like the user experience opinions of the users, testimonials where they're expressing like how they feel about the current tool or the current environment. So those are the two types of data we mainly use.

06:24 There's also some others that we pulled like from articles online and just industry and industry type information. So this is our our ticket form or one of the representations of our ticket form. This is hosted in SharePoint. I think we started in SharePoint. It's just a form in SharePoint that goes to a list and then the list we pull data from power VI and another Microsoft product.

06:55 All right, So this is the executive summary. I just kind of blanked out a few things, but this is pretty much what our business case was. So even though the the executive summary is the first thing on your business case is the last thing you put together, just because it's basically a recap like the name says of the entire document. So in our case, it was like a 16 page document showcasing all the data and all the metrics that we use and the justification part of it. So this is kind of like the the structure of it.

07:28 First you state the problem, then proposes the proposed solution, and then in the middle part you explain the the return on the investment. So how much is it going to cost, cost to transition to Onshape and where are you getting that benefit from in terms of the moving to Onshape? So some of the metrics that are used in industry are like net present value. I'm not a finance expert. Those are just formulas I got online because that's kind of the IT

07:58 standard. Also, the rate of return is another number that I wanted in there. Again, I don't know why, but I pulled the formula. You guys can do the same online and that goes in there. That's basically how it measures the or leadership in this case measures kind of the the validity of the project or the proposal with financial data. And then we also cover the risk part of it,

08:30 because a good project proposal should always include some risk assessment and or mitigation proposals. So that's the part of where we're talking about like for migration, we're going to allow budget for resources in terms of people that come in support with the migration activities or any other tool. Like in our case, we started with Cassini and right now we're exploring Monarch for like the migration support. So those were accounted for as part of the proposal needing those resources or additional tools.

09:02 And then this wouldn't be a business case if you wouldn't be proposing an action plan. So an idea or your typical projects typically end at the risk because like, oh, Onshape is great, it does this, it does that, but then you never put together any sort of proposal. So that's where a lot of proposals come short with leadership, is that if they don't see like how long it's going to take, how much is it going to cost, who's going to do it, when are we going to do it? How are we going to do it in terms of project activities or ongoing activities?

09:34 So that's where the probably the biggest differentiator from a formal business case from your typical just ad hoc presentation. All right. Any questions so far? I know there's a lot of information, but we only have 30 minutes. Again, that was the. The structure of a business case and the back the background behind it. But we're going to move on to defining those problems and ideas and all of those,

10:05 so how we use the data we had. So the first thing is in the problem, you don't want to be focusing too much on like showcasing Onshape or the tool you're proposing. You definitely want to be focusing on what our problem like what's wrong with us? Why are why are we not operating more efficiently or cost effectively? Why do we have so much downtime? Why do we have so much licenses? And like all of those things that are the pain points. So you don't want to go off the bat and say like, Oh,

10:37 we need to switch to Onshape because it's great. Does this does that. First, you want to define the problem and be very thorough about that. So this is where we use the surveys and also our our reports from our ticket system. So we we tracked on like what are the pain points that we see as support, internal support for SolidWorks that our users are having because we have over 300 spread users across multiple teams, engineering teams across the organization. So any given user or any given team, it's not going to realize like, Oh,

11:10 we're crashing, I don't know, ten times a day. Maybe a user is once a couple of times a week, but then when you compile 300 users across 20 plus teams, it turns out they're crashing like over 100 times a day. Right. Or they're losing over over X amount of minutes just tracing files or trying to download files or accessing PDF this and that. So that's the benefit of having a centralized sort of repository for those things, especially if you have teams spread across multiple departments,

11:42 multiple units you want to be make sure you centralize that information to showcase the current state. So in our case, like file version issues, merging designs, collaborating internally and externally, mismatching versions of SolidWorks crashing installs like installs is a big problem for us with SolidWorks because we get new users every week and then our policy and it typically is if there's an issue with a computer, they'll reimage it,

12:13 they'll they'll give you a new computer. So that means that our users are getting like a new fresh computer like every other month. So when that you spread that across 300 users, we're basically doing installations for SolidWorks every day. And it's not just time that we consume from the support side, it's downtime for the engineers. So if engineer is waiting for a new computer, they're waiting for a reimage for the installation of SolidWorks for the setup of SolidWorks. PDM. So that's about like every time that happens, it's like an hour or two of downtime for engineering, which is again,

12:44 when you start adding that up across 300 users, that's a lot of time wasted. So this is where the surveys come in. Another big thing is the collaboration part. I don't know if you can see here on Question eight, how do you currently share CAD files? So that's the biggest thing. And the biggest benefit of Onshape is like everybody is sharing through email either internally or internally, even though we have PDM, even though we have policies, everybody when they're collaborating, like they just shoot a file through email.

13:16 And the reason that number is not higher is because of the size, the file size limit on email. If anything, it will be bigger instead of spread across this other other options. So that was one big thing. Again, also we asked them about the downtime, the experience, like missing files, missing references. All those things are downtime, downtime, downtime, downtime for our users. So again, this is just a compile of that. And then the CAD support ticket, this is the dashboard we have from Power BI. So it just basically validates the survey, like what the users are expressing.

13:50 We have the data to support it, so we're tracking what application they're asking for support or having issues with. And you can see here the biggest number for our support tickets is installs workflow issues or support and file management. So those are right there directly things that Onshape would address. Of course, we're not talking about Onshape yet. We're just showcasing the current state. So the top four items are just inherently issues with a traditional CAD system or

14:22 an on premise server Typekit system. All right. So that was defining the problem like you saw in the problem definition or problem statement section. We're not really talking about Onshape yet. We're just like, hey, these are all the issues we have. What if there was a way to address all of those? So that's where the solution comes in, and we are basically targeting those specific problems.

14:55 So the idea is or was presented to to migrate to Onshape. And because we align those specific capabilities of Onshape to the specific issues that our business has, that's where you make your idea more, more robust case. So you don't want to just randomly start talking about Onshape like, Oh, it's great that this again, it's not about Onshape, it's not about it's about solving the problem that your business has. So we want to align those benefits of Onshape specifically to

15:28 the problems that you have. So collaboration, the fact that now we can share files just with a URL through email, through message, through any sort of spreadsheet that someone has, any sort of page on Confluence or Jira that people use, they can just throw in a URL there and then they're in the native environment instead of uploading the file, we're just link sharing and basically addressing a big chunk of our problems the ability to onboard external users and internal users.

15:59 It's also been a great thing and that's one of the things that we proposed was like, what about document control, quality operations, manufacturing, project management? Right now, none of those teams have really access or robust knowledge of PDM or SolidWorks. So what? Onshape again, if you put in a hyperlink there in the system, they're in read only mode. They can see the data either 2D or 3D. So that was again a big part of the solution. And then it just go on and on, on like the file version issue or software version issue in building design reviews.

16:36 So instead of putting presentations together in PowerPoint for design reviews, now we're just having the engineers and designers comment and have that design history there between Onshape. So they just basically open up a Onshape document and they have design history in terms of versioning, commenting any branches or any sort of related documents or design they can access through that. That basically one document, either it could be like an entire project if we put all the files or designs their drawings and parts,

17:06 or it could be like a breakout project where we have one document for the assembly and then multiple documents for the components. So those two things work and we do those on different stages, but that's basically how we collaborate. Now for anything that's an Onshape data management that this is again from our end, the biggest thing, the biggest concern was the integrity of the data. So are people accessing the right version? Are people accessing? Because with PDM, we have that issue with SolidWorks where people don't know if they

17:39 have the latest version or they should get the latest version or how do I get an as built of this or was this released with the latest or not? Like even advanced users that do modeling or senior staff engineers they a lot of times don't know PDM and like what is the latest? How do I get the latest? How do I get the built with Onshape again URL and you're in the place you should be or the point in time that you should be of that design.

18:09 And then from the admin side, of course, we're getting rid of all those installations, simplifying the onboarding. So we did implement single sign on through Okta. So we're basically mitigating all the risk of managing access and managing users through that single sign on that it's managed by it. So performance again, consistent across the experience is consistent across all our users and all our teams. Just a question at this point, since you're using SolidWorks,

18:39 did you ever consider switching to. Cloud products of two. So yeah, yeah, that was covered. I think part of the idea I don't cover it because it was a pretty short analysis on that tool. Um, because again, we started this in 2019 , the formal proposal exploration. So at that time we did try the 3D experience product. It seemed like more foreign to SolidWorks than even Onshape is in terms of the design,

19:10 in terms of the architecture, the overhead that we would be solving with Onshape is not solved with the 3D experience because there's still a lot of management that goes into it's not again, I couldn't just log into any device and start using the 3D experience, at least the traditional SolidWorks that the the cloud apps at the time were not even ready for use. So we didn't. But yeah, that was covered as part of the optional solutions.

19:40 But again we mitigated that as a potential solution really quick with a trial. So the next stage the idea is again turning it into like a formal initiative, not just an idea is the implementation strategy. I covered this on the on the summary, but again, we we got to work on like, how are we going to do this? Like if if we approve the project, how are we going to go about implementing it? So in our case, because our projects in the medical device industry are very long,

20:11 multiple years long, we we, it wouldn't make sense to just decide like, oh, we're going to migrate our legacy or we're going to migrate anything that's commercially released into Onshape. We just decided we're going to leave those as a sort of a legacy project. We're still going to have access to Onshape. I mean, SolidWorks licenses even if we stop subscription. So those are going to be continue their life cycle and Onshape and then any new projects we're basically doing like a evangelization of the teams

20:41 as they they go through the project life cycle or the product life cycle of those. And then the resources again, I mentioned the migration tools like Cassini monarch, the support need for drafter technicians, and then the training and the lesson, the learning curve that was considered. So those factors make an idea into like an proposal or initiative that is more appealing to leadership instead of just throwing ideas

21:11 around. We actually have a plan, a proposed solution. So making and continuing the leadership comment. So making the decision easier for someone that's not technical, right? Or they might be familiar with what Cat is or SolidWorks is, but they're not going to know all the ins and outs about the reason behind it. So what we did here to justify even further the solution is a decision matrix.

21:43 So we basically laid out six different categories that we're evaluating for this decision. Again, decision matrix is nothing that I came up with. It's just a tool that's out there for different purposes. The one thing that we did is to put a weight into the decision matrix. So this is a weighted decision matrix because we want to add value to those scores. On the things that mattered the most. We don't want to say like, Oh, cost is super important when in reality is like, well,

22:13 if we're using the same money we had for SolidWorks, we're going to use it over here for Onshape Like cost is not like I wouldn't give a multiplier of two plus two cost because it's really not a big issue. So that's why you want to put in the weighted part of it, because if costs say like, Oh, Onshape is more expensive than SolidWorks or vice versa, you don't want to accentuate that if it's not relevant, right? So that's where the weighted part comes. So we gave more weight to collaboration because that's where we have

22:43 the biggest value by going to Onshape. Like we're not going to be better in functionality because Onshape are kind of early adopter stage or at least at that point was. So there's there's still a lot of things that need to be there, like comfort of life, things in terms of just designing and modeling. And you can see that SolidWorks outscore in this matrix Onshape in that area considerably. So that was one of the biggest questions I got when I presented the business case like, Hey Adrian,

23:13 why is functionality not as important as collaboration that makes no sense? Well, it makes sense because we've gone through all the piloting, all the testing, all the analysis, like it covers the basic needs that Dexcom has for modeling and designing. So I'm not going to give it a ten just for comfort of life. Things that SolidWorks does have because it's a more mature product, but again, it covers the basics.

23:43 But where we're really in pain is in the collaboration side. So that has more value right now than just saving a click or two here and there with SolidWorks. So that's one of the biggest questions we had and that's why collaboration has a bigger multiplier than than functionality. So that's kind of a note. And then the other again, IT infrastructure, all the pain points and the cost involved with your your server management, license management and all those things. The outlook of the tool.

24:15 Again, I've been in the CAD community and the SolidWorks community for a long time and my analysis of like where things are going with SolidWorks is not as bright as where things are going with Onshape and PTC. So that's that was to me in my position at Dexcom as the manager of the CAD tool or the CAD system. That is relevant because we want to think of the future. We don't want to just think of right now what like everybody complained, like why are we moving? Like, well, we're not moving for the functionality and we're not moving for today.

24:46 We're moving because we're, we're a step ahead. Like that's one of our mottos, one step Ahead. If we're not looking like five, ten years into this, we're going to hit a wall pretty hard. So that's where again. This is relevant. So extended benefits. We want to highlight the benefit of productivity. So we went through what we call CAD indicators. So what activities are engineers and designers performing that are impacting their productivity or their efficiency

25:18 or their value as engineers instead of just doing data entry? So we we highlighted this activities and then we showcased like out of those activities that an engineer does, like how much more efficient are they going to be with with Onshape. So that's where this kind of cost benefit of productivity and efficiency came about. We measure like how many hours does a typical design engineer use CAD? They do it for, I don't know, ten hours a week, and then out of those ten hours,

25:50 they're going to gain a 15% efficiency in their activity. So that's how we measure this using average salary data that we got from h.R. So that's where those efficiencies that that 15% number that you saw on Onshape live, that's where this comes from for cad activities versus our current system. So the risk part of it again, is you want to make sure you cover the risks, you cover your tracks. So the big one is migration.

26:21 The impact of migration, the time of migration, the learning curve for users. We're learning that it's not as easy as we thought it would be for some of our more experienced users or senior users. But it's more similar to SolidWorks than any other tool out there really. So people start thinking like, Well, not this tool, why not that tool? We're not moving because of the CAD, we're moving because of the business. So that's the. The impact there. But again, going through it.

26:51 External contributors and partners like we made an assessment of how many contributors, external contributors we have and then what would they be willing to use Onshape or have they explore? Onshape And so we did an assessment on that. Also, the app portfolio, again, that's important because we own the full suite of software products with Onshape, that's pretty limited. So we did consider that and consider like third party options for some of the tools that we're using that are part of the SolidWorks portfolio.

27:21 And then the bigger one again security. We went through a formal security review from our IT team. Our IT team has done like cloud analysis or cloud tool analysis in terms of security for any many other business solutions that our company uses. So CAD to them was just like, Yeah, just complete this form, we'll do the analysis and then you're good. So a big one was like single sign on and then again, Onshape provides all the details of their like their uptime and all of that redundancy

27:55 and all that stuff that basically what the analysis is. And then the investment I'll just start shortly. Factor in the return on investment. That's where those industry standard formulas came in. The net present value, the internal rate of return, again, those kind of standard for the company and the important number the the cost of the current tool with subscription, the cost of the learning curve, the migration, the cost of Onshape itself. And then we counter that with those productivity savings that I just showed.

28:29 And we're right on time. Thank you, everyone, for coming up.