Wahoo Fitness: Successful Upchain Implementation

PRANIT NAGARE: Hi, and welcome to a case study presentation on how Wahoo Fitness had a successful Upchain implementation. My name is Pranit Nagare, and I'm a mechanical engineer at Wahoo Fitness. And I'll be going through this presentation with you.

So starting off just to give a brief background on what Wahoo Fitness is and what products would make, so Wahoo Fitness is a tech-fitness company, and we have an ecosystem of indoor cycling, trainers, bike trainers, heart rate monitors, cycling computers, watches, pedals, and science-based training platforms.

So we create all our designs in-house. So we needed a cloud PLM solution to speed up our production process. We had an existing system, but on further investigation, we found that the Autodesk cloud PDM/PLM solutions, specifically Upchain, was a very good solution for us.

And we'll demonstrate how we efficiently implemented this, starting from product engineering and into product management and what successes we had, what landmines we avoided, and what you could do to have a successful implementation as well.

So just to briefly summarize what our key learnings will be from this presentation. The first, you will learn about what our decision making and selection criteria were and how we went about finding Upchain and deciding on the product.

The second point would be, what would be the best practices to implement Upchain within three to six months? And what would be the best iterations that you would need to go through to get to that? The third is, what business outcomes you can gain from using Upchain? And I'll split them according to the phases so you would know at each point if they have addressed the outcome that you needed.

To go over the timeline, we started looking into different solutions around 2020 quarter 2. So this was during the pandemic. And so we are re-evaluating our business needs and how we went about efficiently managing mostly remote team. So that included identifying our challenges and evaluating different options.

Then we spent about 3 to 5 months testing out Upchain in a sandbox environment and understanding the intent behind the workflows. Then we had an implementation phase in which we went about getting the core team set up and running within six months, and then we expanded the product out to the other users in the team so we could get more users using it on a daily basis and providing input.

So looking at the decision process, the first thing we would need to do before that is identify the challenges of the existing system. And this was done by getting input of everyone who used the system on a daily basis to make sure that the major pain points were at the forefront of the decision process.

So the first issue that we had was the licensing and role assignment of the existing system was very rigid and tied each license to a specific user rather than just giving us a bunch of licenses and saying, assign it how you want and switch them around. So there was a lack of flexibility in that, which also meant that there was limited options when users switch teams or switch roles. For example, an engineer going into product management. So that was a big pain point for us.

The second was the system had the capacity to do anything, which also meant that there was a large level of administrative involvement required in the initial setup as well as on an ongoing basis. It allowed us to fail again and again, or basically, you would say it allowed us to go through a lot of trial and errors before finding something that worked, which, for a smaller team, was not the optimum use of our time.

The third issue was the product data management, or the PDM, system was not well integrated with our CAD system, which is SolidWorks. And that meant there was an additional clicks and time spent in just getting the data into the system and out of the system. And engineers being adept at finding workarounds, it meant that a lot of people just went through the administrative process to get things in and did not learn the process as it was intended.

The fourth issue that we used to run into was the release process was suboptimal, and it wasn't intuitive to the level that people could just click through it. And it required a lot of manual intervention to push it through the system. And even at the end of that, you needed additional time to gather all the output data to send out to your supplier, which was not the optimal use of our time either.

And the fifth as something that always comes down to is the costs involved in the system to get the level of functionality we needed. So for example, we could run a change request, but there was no way to get a PDF of that up. And it required an additional module. So that felt like an unnecessary barrier for a basic level of functionality.

Keeping all these in mind, we decided to set our operating goals. And we'll look at those next and how Upchain addressed them. So looking at the goals for our new system, the first was getting a licensing system that was flexible enough to address our needs. And what that meant was that, as people changed their roles, you could easily change their licensing and role assignment without having to buy an additional license.

The solution that Upchain provided addressed that because it was tied to the tenant and not to the user. So we could just get the number of licenses we needed. What was also good about this was the tiers in the licensing system were very straightforward. So we could basically have our power users at the top license, our project managers next, then our product managers and quality managers, et cetera.

And they also had a preview license that you could have your customer support team or your suppliers who only need to access the release data. So that was a very flexible and additional bonus that we found that Upchain had.

The second was the level of administrative involvement needed to be at an occasional level. So you wouldn't need someone dedicated to be the admin to be looking at and massaging the system through.

Upchain being cloud based, so the data is hosted on their servers, it meant that they had a level of backend functionality that our previous system did not. So their admin control at the time was more about customizing the out-of-box workflows rather than setting everything up from scratch. So this would potentially save us a lot of time.

The third, which was something that the mechanical engineering side really wanted, was a well integrated PDM system. That is, something that is just there in front of you while you're working on the model and not a separate window that you have to click to get to. So that was a pretty big requirement for us.

And the SolidWorks adding that option demonstrated in the demo was pretty simple and intuitive. I had a simple check and checkout process. And we'll look into how that worked out as we go further into the presentation.

And same as the PDM system. The release process also needed to be just simple and easily configurable and intuitive. Just click through and it does its job as needed. The next one that we really wanted was efficient customer support system.

And what that meant was not something that you just tell them and they would do the stuff but something that would have a two-way communication with us and explain the intent behind the system as well as understand our needs and find a way to bridge that gap. The demo that Upchain had showed promise in that regard.

And one of the major requirement was that most of the basic functionality that we needed needed to be out of the box and not be at an additional module that we needed to buy. The primary aim of this was to have a quicker speed to benefit and get as many users into the system as early as possible so that we could get the proper use out of the system.

To summarize this phase, how do you go about doing this? Is first, you need to get your team together and identify your existing challenges and then set the goals accordingly. The business outcome from this for us was that we identified that Upchain could address our needs based on the demo and the initial research that we did, and then we decided to evaluate it and test it further and work with them to figure out exactly how to implement the system.

Going on to phase 2, the testing and evaluation. The first thing that we ask Upchain was if we could set up a sandbox environment where we could test rather than just going off the demo and making a purchase decision based off of that. And our team were very ready to provide us that environment.

So what we did was they set us up into that tenant environment and allowed us to just put our own assemblies in. So we could figure out if there were any differences or any issues with that and how easy it was to use on a daily basis with our parts and assemblies.

The other thing that's allowed us was to also test the CAD add-in on SolidWorks and how it worked on a daily basis. At this time, we still had our previous system. So that allowed us to do a side-by-side comparison to evaluate exactly how Upchain did things. And that helped us build confidence in the solution that Upchain had.

A big part, as I referred to previously, was a collaborative working relationship with the system. So Upchain was very kind enough to work with us and eager to understand our workflows as well as explain the intent behind their own out-of-the-box workflows and how the system was set up to help with that.

What that meant was they were able to explain their processes, which enabled us to switch our workflows around to match the system. So we work with it. However, this did not mean that we were tied to using their out-of-the-box workflows and had no wiggle room at all.

Instead, what happened was, because we had this communication going, both teams were able to realize what the gaps were and change either Upchain's process or our own process to bridge those gaps. So one of them would be customizing, say, the release workflows because we did not have 10 people needing to sign up. So we could have a much more simplified workflow, for example, or complicated as much as you need.

The changes on our end was to change our design workflows. For example, changing our drawing templates, changing how we use master models, for example, to make sure that they work smoothly with how Upchain intended them to be used.

So this phase 2 lasted about 2 to 3 months, where we made sure we tested out as many things as we could. So that's the intent behind this phase, is to do as much sandbox testing upfront with your own assemblies if possible and to set up a collaborative workflow with the Upchain team.

The business outcome we would get from this is an assurance that Upchain could address our needs, as well as the interaction with the team also gave us confidence that there was a capability to scale up as our business scaled up. So the business outcome from this was we decided to transition away from our existing system and buy Upchain licenses.

Now we get to the meat of the presentation in terms of how we implemented this and got up and running. So the first step was that before we started working in the system, we needed to train the core engineering team so that they would be able to benefit from the system as soon as possible.

So the first part of that was to basically give an understanding of what the different systems were. The PDM part of it was our daily use case in which we are checking in and out of and the PLM part of it, the product life cycle management part of it, was the release process.

And so this understanding was developed primarily to ensure that our workflows were clear in everyone's mind. So that was like an internal training session. The second was training onto the system itself. And this is where Upchain had a really good resource as an introduction, which is the Upchain Academy.

And what that is just a good amount of videos and documentation that users could access at their own pace and gain an appreciation and understanding of how the system is laid out, how the UI is. And that enables-- or minimizes the surprises that someone would get when switching systems.

The third was, which was a really good solution that Upchain came up with, was the Connect the Chain program. And what that was were that you would have a group of people from different companies on a call with Upchain's team to demonstrate the features and answer any questions. And these sessions were role specific. So they had a session for administrators. They had a session for project managers, a session for the mechanical and electrical engineering team and so on.

So that enabled that any questions that someone testing in the sandbox did not come up with were still addressed or at least brought to the attention of Upchain and something they need to work on.

Once the team was trained, the big part was getting all the data migrated from the old system to the new one. So this was split in two parts. The electrical team had a slightly different need than the mechanical team. So the electrical team had this huge electrical library with your resistors, your capacitors that are the same part used across multiple boards.

So for them, they needed to retain their part numbering scheme as they were component specific, and they referred to the specification of the component itself as well as being used under multiple boards. So recreating that from scratch was not an option.

In terms of getting that set up and imported, it was decided that it would be much easier and faster to have it set up through the Upchain customer team. So what we provided to the Upchain support was just basically an Excel list of all the components, all the boards where they are used, and then Upchain took that list, went to the backend, created all those bolts and components. And we had the full library ready to be used on day one. So that helped save a lot of time from the engineers who would have ended up having to recreate each and every board in the system otherwise.

Going to the mechanical team, we were not as tied to part numbers as the electrical team. So what we decided was to just import the individual projects through the BOM through the CAD add-in to create the bill of materials automatically with a new part numbering scheme that we had set up.

This process was also useful because it also allowed us to exclude things from the bill of materials that we did not need. For example, reference models that we would use for creating our sketches. So this enabled a clean transition over rather than having to stick to the old part numbering scheme and having to manually recreate that again.

Once we had the system set up, there were a few initial benefits straight off the bat. So I've split them up in benefits during daily CAD usage and then benefits on the web app side. So looking at the daily CAD usage, a big time saver was the mapping of revision attributes.

So Upchain has this really cool way of putting [INAUDIBLE] as curly codes onto your drawings which would get translated on release. To show an example, so this is how you would-- so the top part is how you would have it on your drawing with just the curly codes in, and the bottom part is how it would fill out upon release.

And what that helps is that means the user does not have to manually fill out the revision table or keep adding a line every time you revise it. You could just have this four column set up permanently on the drawing template. And what it does it ensures consistency between users and also removed a source of user error because while typing, you could easily type a different revision than what you intended to release it at, you would put some revised date, some release date which would not match in the end.

So this helped save a lot of time, removed a lot of user error, and it just made for a very clean drawing template to have because you would have a consistent revision table. You would have a consistent title block. So that was a very good benefit to have right off the bat.

The second was the SolidWorks add-in, I've already referred to it as being unobtrusive and intuitive, but in daily usage, it really showed its strengths because, as you can see, it's just off to the side. It's in a side manner which you can collapse when you don't need it, but you can easily expand it when you need it. And it's just a simple checkout, check in load drawing.

The really unique part of this is the Add to Cart feature. And what this does is, as you finish working on parts and getting ready to release, you can add them to cart and just send them to release all at the same time instead of having to, again, go back and select each part and send them individually to a release process. So that intuitiveness and attention to detail was really appreciated.

Now, looking at the web app side, the first was the release workflow was very straightforward. And how it was displayed in the web app itself was very clean, and it easily allowed us to track how the process went through the system.

The second was the automatic translation. So whenever we checked in any part, Upchain would automatically generate a PDF for a drawing, a step file and an STL file for the 3D CAD. And what that meant did not have to spend time in SolidWorks manually exporting each one out. It was just there available in the system.

So for individual parts that you can look on the right side, they were just available in the side panel. You could just download individual ones, and any user with access to the system could do that. The second was the bulk export, which is for large assemblies. If you have 500 parts, you do not want to download each drawing individually.

So what the bulk export work was just go to the top-level assembly and just click which file formats you want and export it all out at one go. The third was the Upchain web app viewer and this was able to display even our larger assemblies that you can see. And this really made it easy to share data because the previous process would involve someone having to come up to an engineer's desk and, hey, can you show me the latest thing you're working on?

Or having to send them a neutral step file, which as mentioned before, you can still easily access here. But having the web viewer meant that anyone-- and this, as I referred to before, this was during the pandemic. So having the web app meant that anyone around the world could easily access this data and look at how the design was progressing and give any input that they needed to.

Now, with any new system, there are always going to be challenges and pitfalls to avoid. So I've split those into what we had issues on-- the electrical engineering side and the mechanical engineering side-- because they're a slightly different thread to both of them.

So on the electrical engineering side, while we did do quite a bit of sandbox testing, our electrical workflow testing wasn't thorough enough. And what that meant was there was a difference between the process and the workflows in terms of what we anticipated and what we found. This led to a bit of friction, as there was-- the difference in process led to some data mismatches. And that meant that there was quite a bit of lost time spent in re-creating those things.

The solution to this was simply to work with the Upchain team to figure out what the gap was and how to work around them to make sure that we avoid those issues in the future.

Now, the second point that we had was the electrical engineering CAD add-in wasn't as intuitive as the SolidWorks CAD add-in and had a bit of limitations. So Altium, which is the system that we used, had its own restrictions, which played a part in that. But the smoothness of the process wasn't as anticipated.

As an example, the add-in input only packaged up the boards, but it could not upload them to Upchain directly. So you still had a manual step in there that you had to upload and name the files. So that had the potential for user error, which did happen a few times.

The other issue was the electrical data types that were part of Upchain had a few limitations. One of them was having an eBOM-specific attribute, such as reference designators, which is basically just a list of locations of where a particular component is used on a board. And it needs to be eBOM specific because it differs from board to board.

That was not part of Upchain to begin with. So our solution to this was we worked with Upchain's team to, one, make them understand what our need was exactly in terms of the data type, and then having them implement that on the backend, having us test it, and then refine our template so that we had as minimal error as possible in terms of the upload process, as well as we had the data that we needed in the system.

So for example, an issue that we found while testing was the reference designator attribute that they added did not have a big enough character limit to fit our-- there were a few boards which had a ridiculously large number of characters. So that was something that the Upchain's team was very willing to work with us to figure out and implement because it also helped them make the whole system better for all their other users at the same time.

The third issue that we found was that the reporting options, while good, were a bit limited on the EE side. Mainly, it was the supply reports, which were frequently needed to be sent out. And it wasn't something that was easily available out of the box.

So after a bit of trial with the Upchain team, we figured out a custom report template that we could add to the tenant system that would enable us to get the data out that we needed. What's good about it now is that recently, Autodesk has actually added the custom report functionality on the admin side. So it does not involve the Upchain-- or it does not need us to involve the Upchain team to actually tweak minor details. We can do those on our own easily. So that has enabled a very good level of customization now.

The last-- so these three issues kind of feed into the last issue, which was that due to the limited access to the administrative side, it required us to raise multiple tickets for a couple of months just to fix the issues on the backend. So that would either be a wrong part added or a wrong part number or to delete a part, et cetera.

And so this did mean quite a bit of time and delay while stuff was getting fixed. The good thing about that now, the solution to that, if you will, is that as time goes by, Upchain has become more robust. So the issues on the backend happen less frequently. And while they have done that, they have also provided additional administrative-level access as well as API access.

So there are things that we can do on our own backend. Something as simple as just changing the file name or removing a file from an item can now be done on our own without having to involve the Upchain team. What's good is the support team is still there, accessible, still as responsive. So it's not completely thrown on us to figure out our own solutions. But it does help having that option.

Now, going on to the challenges on the mechanical engineering side, they were mostly process related. An early issue that we found was SolidWorks' configurations were not supported. That has been added in later revisions. But at that time, it wasn't supported.

And what that meant was that for a few of our assemblies, such as, say, our pedals, which had different spindle lengths, you could not have a single model driving all the spindles. Or the only solution we had at the time was to just split out our models and maintain them each individually.

So this could be a bigger issue if your system-- if your process uses a lot of configurations. But looking at our projects, what we found was there was a very small number of parts in which we actually used configurations as separate parts. So we decided that for us, splitting out our models was the more optimal solution rather than waiting around for configuration support. But as I said before that it's supported now. So that may be less of an issue if you are looking into getting Upchain.

The second issue that we found on the mechanical engineering side was the master models that we used did not behave as expected. So it was a bit inconsistent. And part of it was the way SolidWorks references derived parts versus how Upchain references them are slightly different.

And what that led to was-- so ideally, you would not want your master model or your reference model to show up in your bill of materials. But the way this mismatch was happening in terms of references meant that we consistently ran into issues where the master model would just not show up as a part on Upchain's side. So we would lose our references and have to reimport and redo all the changes.

The solution that we figured out had to do with refining our process a few times. But what we ended up was to make the master model as its own item that we can release and check out. But because the Upchain system allows us to exclude items from the BOM separately, that helped us to have the master model released and then removed from the BOM. So we could still maintain a clean eBOM to send out, while not having the references being lost on SolidWorks.

The third issue that we had was the bulk exports that were referred to previously were a bit inconsistent and would occasionally fail with larger assemblies. So then you would have to go in and manually export out each individual drawing, which was a really big time sink.

Honestly, the only solution to this one was just wait for Upchain team to come out with new versions and test it. And happily, I can report that as the versions have gone by, the bulk export functionality has become a lot better. And it works pretty much all the time now. So that has helped a lot in terms of just getting drawings out, honestly.

The fourth issue was the output drawing PDF. So as I said, we went in with using the mapping attributes that Upchain had. So what that meant was our drawings in the CAD system just had those curly codes that I referred to before. And we are reliant on Upchain's release to have the correct formatting and the correct codes out-- split out.

However, what we found was that initially, at least the formatting did not retain itself. And what the problem was that the engine that Upchain used to convert those drawings to PDFs did not recognize the fonts that we were using. So that was, honestly, just changing the export settings and figuring out-- with the help of Upchain's team, figuring out what export settings work best for ensuring that the output formatting did not change.

This is also part of the inconsistent revision attribute resolution that I was talking about. And what that basically meant was on a few occasions, we would have the parts released. But the codes would not switch to the actual values. So that meant we would have to keep releasing it a couple of times to make sure that it generated correctly. And the solution for that was, again, just working with the Upchain team to test out new functionality, refine our templates, as with the previous one, until we got to a position where that wasn't an issue anymore.

So summarizing this, all that I talked about in phase three, the first step involved cleaning up the core engineering team to make sure that they were ready to use the system on day one and not have any unintended surprises. The second was working with the Upchain team to migrate our data into the system, which had a couple of different approaches based on what the data was, whether you wanted to retain your part numbering scheme or whether you didn't.

The third section was about what issues we encountered and how we solved them, as well as what benefits we had from using the system right off the bat. So the business outcome from all this was we finally had all our hardware engineering data in one accessible place with proper access control. And that meant that anyone who needed to access the data knew exactly where to look for it.

And what that led to was just faster and easier product development with everyone is working off of the same data and not working off someone's local data and three engineers have three different versions of the same file. And the web app, the PLM side of Upchain, addressed the need of establishing a proper paper trail. So we had document management. We had bill of materials management and ECN management.

And what that meant was any user could go into the system at any time and track exactly how the product went from initial idea to the final release solution. And that is very useful for when you're working on a new product, just to go back and understand the learnings from your previous product or even for new engineers coming in and being thrown into the system. They still know where to look because of the way the intuitiveness of Upchain helps in that regard.

Going into phase four-- after we had the core engineering team fully set up within six months, phase four was expanding it out to other users. Oops. OK. So going into phase four, the first thing that we needed to bring was the immediate team's next to product engineering, which would be the product management and the quality teams.

So product management would be the ones actually keeping track of the schedule. And so that would then help them to work with the suppliers to figure out timelines based on the releases that were happening in Upchain. And for the quality team, it helped being able to view the data as it was being developed and figure out issues up front and figure out the testing plans so that-- as well as give early feedback on the same, which enabled us to speed up their process, rather than them having to wait for the full release and then finding out the issues. So it helped with their planning of the testing as well.

The second was expanding it out to the non-CAD and nontechnical users. And as I mentioned, the web app before, being able to view the data early on without needing to have a CAD system and-- honestly, you could also-- the web app was strong enough that you could use it on your phone or iPad.

So that also meant that even remote teams-- and we have teams global. So we have teams in Australia, Japan, England. So what that meant was users anywhere could view the data without having to install a CAD system or having access to a CAD system. And that would enable them to provide early input for any design changes that were needed.

So what this did was just freed up the whole engineering capacity because the previous workflow was-- say I'm working on a product. I'll have 10 different people contacting me 10 different times to show the same thing again and again. But what this does was because now everyone knows where all the data is, they could just go there and look at it.

The second was once the data is in a good place and in a particular location, that's when you can establish best practices on how to access and control the data. Otherwise, it becomes a case of five people have five different processes. And nobody knows how to merge all of them together. But when you have all the data in one place, it helps to establish a particular protocol and a practice that ensures that things move smoothly and more intuitively for the whole team. And obviously, team collaboration increased due to the same reason.

So what's next with Upchain now that we have the system up and running and using on a daily basis? Well, the first idea is to expand it to occasional users, which is, as I said, the customer service team or the suppliers, those who-- or even marketing, for that example. So they could look at early design concepts and start figuring out how to convert that.

The other is someone like industrial design because that way, they can look at how their concepts are getting formed and tweak things as we go along. So this is enabling a lot of-- this will enable a lot of back and forth communication and make it a lot, lot quicker to get ideas across.

The second is, as I mentioned before, Upchain has added an API access. And what that means is with some clever programming, you can set up a few automated workflows. You could think of an example of a software app that you just need to send a ECN out to your supplier that's seeing an app has changed. You could automate that process using the Upchain API. And obviously, you can come up with a whole lot of other automation ideas once you have that API access.

The third is-- so when Upchain merged with Autodesk, it also gave us access to Autodesk Fusion Manage, which is an even more expanded PLM system.

So there is a future in which Autodesk Fusion Manage is working with Upchain to give us additional options to work with outside suppliers or even expand it-- expand the whole system out and have much more visible metrics across the system, or also to set up your ISO processes, your quality processes, et cetera. So there is a good future planning behind Autodesk Fusion Manage.

And the fourth is we are already part of the Upchain early access program, which is basically the beta program, in which they give us access to releases that are not yet out in the public. And they have been really good in taking our feedback and keeping us informed of the upcoming changes and working with us to change things.

So as Upchain has grown, they have obviously-- the rate of changes has slowed because there are a lot more users to ensure that nothing gets broken. But they have a very robust testing system. And the feedback system with the users is very well managed. So that has been very good. And I'm looking forward to continuing to work with the Upchain early access program.

That's it for me today. This is how Wahoo Fitness implemented successful Upchain implementation. Thank you. Thank you for your time.