Name: Mastering Multi-Supplier Collaboration for a More Resilient Supply Chain
Uploaded: 2026-03-18T15:16:15.984Z
Duration: 1 h 12 s
Description: Mastering Multi-Supplier Collaboration for a More Resilient Supply Chain

Transcript for "Mastering Multi-Supplier Collaboration for a More Resilient Supply Chain": Hello, everyone, and welcome to today's webinar. Mastering Multi Supplier Collaboration for a More Resilient Supply Chain. As manufacturers scale, reliance on contract manufacturers and joint design manufacturers is no longer optional, but it does come with risk. Version misalignment, spreadsheet based handoffs, limited traceability and siloed supplier communication continue to drive delays, quality issues and compliance failures. Today, we'll explore how leading manufacturers are strengthening resilience across their extended supply chain by rethinking collaboration, visibility and control without slowing innovation. I'm Ella Wilkinson, director of BizQuick Studio, the publishers of Supply Chain Digital. And joining us today are Dave Barry from Arena, who works with manufacturers building repeatable collaboration and change processes. Michael Keir and Shirish Joshi from PRG, who will share what happens when design moves from engineering into execution. And Jim Ruger from Fictive, bringing the hands on customer lens. What changed, why it mattered, and what they'd do differently if starting again. So before we jump into today's discussion, if I just run through all of you, tell me who you are, what you do, and why you're expert in this field. Jim, you're on my screen right now, so can I start with you? Sure. I'm Jim Ruga, CTO from Fictive. I have been building these supply chain systems for over a decade now with Fictive, and we were recently acquired by Misumi, and so now we're actually in the phases of integrating supply chain systems different supply chain systems together. Brilliant. Dave, you're next on my screen. Hi, yeah, I'm Dave Barry. I'm a senior solution architect here at Arena Solutions. But my background really has been in engineering, particularly manufacturing high-tech in the high-tech industry. I first came across our solution Arena Solutions I think it was fourteen years ago when I was working for a customer of Arena and we went through an implementation with the Arena PLMQMS system. And since then, I've gone on to help a lot of different companies go through that implementation. So I've experienced a lot of different requirements from different companies, different sectors. So I've got a good background of what companies needs are and what issues and problems they have to solve. Perfect. Shirish, you're next on my screen. Hi, my name is Shirish Joshi and I've been working with Mike and PRD Group for almost, eleven years now. And, lately, for the last year and a half, we've been working with Jim at Fictive. My background primarily is thirty plus years of supply chain and manufacturing experience working at high-tech companies in the Silicon Valley, for example, Sun Micro, Apple, and so on. And, we've been working, most recently with Jim to implement and integrate his supply chain and his ERP systems and PLM systems altogether. Well, lovely to have you. And last but not least, Michael. Great to meet everyone. Thanks for having us. My name is Michael Kehr. I'm a founder and managing partner of Product Realization Group. We've been an active partner of Arena for more than fifteen years now, and my background is thirty plus years in high-tech new product introduction. Relative to this session here, I spent eight years running a contract manufacturer and saw firsthand really a lot of the opportunities and challenges of what it takes to get data from an OEM to a Centimeters so that I could build the product. And I've found that companies that have systems like PLM really were easier to manage than others. And at Product Realization Group, we help companies manage that challenging transition from concept to full scale manufacturing. I call it scaling products, and then also working with processes and systems to scale business. So scaling products, scaling business. And I've been doing that since 2010. Well, we have some amazing expertise here today. So thank you all so much for joining me. Let's start today with where most of those problems begin, the moment that collaboration becomes multi party. So Dave, this question is for you. When you look across manufacturers working with multiple CMs and JDMs, where do collaboration breakdowns most commonly occur? Well, I guess the breakdown really is in communications. I'm sure we've all experienced where the results where parts have been built, say to the wrong drawing or assemblies have been made to the wrong bill of material, and that's because it's just been lost in some communication between the two parties. And of course, if this happens, this is going to be really time consuming. It can introduce time consuming and costly. It can introduce extra iterations into your design cycle, obviously can be expensive as well, and so it's really the level of communication between the design company and the contract manufacturer or the JDMs. It really is sound and robust and the information is shared. Information isn't lost in sort of email trails or now we've got things like Teams or Slack. So easy for instructions to get lost in those sort of environments. You need a robust system in place to avoid this sort of Chinese whispers of effect and we can cause these major issues. And it is easy for things to get lost in email chains as well, I guess overload of information. What do you think is the earliest signal then that things are about to go wrong? Well I think one of the I would say one of the early signals to look for would be if you're finding that your contract manufacturer is coming back for clarification or wanting confirmation from an instruction. This is telling you that that communication isn't working well. So that would be one of the things, one of the telltale signs, you know, if there's a little this your contract manufacturer has to keep asking questions. It's a sort of a signal that you're not really explicitly sharing the information with that contract manufacturer if they have to keep coming back and asking those questions. So you want to try and find a way of removing that ambiguity in the information that you're sharing with the contract manufacturer. So where, I guess, are teams most where do they think they're aligned but they actually aren't? I think it's quite common that you might have a fairly well controlled process internally and that can lull you into that security. Yeah, we're in control of this. But of course now we're suddenly sharing information out with third parties, then the chain and it's not so apparent, it's not so clear that that is well, you know, natural assumption is, yes, we've approved this change order, for example, you sort of almost assume that's been shared out to the contract manufacturer that picked up and understood that and so forth. So you really need to look for ways at which you can get some positive feedback from your suppliers, from your contract manufacturers to be sure that they've understood the change, they've seen the change, they've understood that change, and that you've got a proper system in place that you can track their feedback as well. Jim, I've got a quick question for you then. When you hear emails, spreadsheets, multiple BOM versions, what part makes you nervous? It actually isn't the spreadsheet, email or bill of materials that make me nervous. It's the idea that multiple intelligent people could be confident they're working from the same revision without ever realizing they're quoting, planning, or manufacturing two completely different items. Typically, it's not a single failure mode, but a series of very small, minor drifts from the source of truth that aren't documented. If designs, manufacturing, assembly, or procurement are handed off from one geographic region to another, and they rely on quick notes accessible only in an email chain or a spreadsheet or a Slack message, then details are missed, leading to nonconforming parts that have drifted from the design record. Managing those revisions and bills of materials and requirements within a PLM environment and linking that information to a digital manufacturing platform, you can ensure that every team and supplier is working from the same source of truth. Yeah. Making sure it's all detailed and it's constantly updated, basically. So Yep. Michael, from a product realization and execution standpoint, how do these issues show up once designs move from engineering into manufacturing? Once designs move from manufacturing or from engineering into manufacturing, any data management issues risk turning into a contract manufacturing problem. So earlier in my career, when I was running manufacturing at Pyramid, it wasn't uncommon to receive two different Excel files that had different bill of material parts on them, but they had some difference that maybe it was a date difference or oftentimes it wasn't a revision difference, so they would have to be same part number, same revision, different date. And then as a contract manufacturer, what are you supposed to do? Which version are you supposed to build? So the risk of building a broad product when you have these kind of ad hoc systems and processes in place is high because the contract manufacturer has no clear picture of what is the correct information on the bill of material. Think about, well, how do these then show up in practice on the factory floor? Think about if you don't know what's coming, then you've gotta go back and you've gotta answer questions. That shows up in delays to manufacturing while you're waiting for the back and forth between the Centimeters and the client. Sometimes it results in building the wrong product or the wrong revision because you don't know what product you're supposed to build. This causes additional delays, rework, now you've got to reorder parts, you've to re put things into the factory. And then the last one is purchasing, buys the wrong parts because they just don't have a clear picture of what they need to buy, because they don't have a source of truth. This further delays production, increases costs, and ends up resulting in excess and obsolete material. None of these are good outcomes, obviously. So if you expand that then from, say, a single site to now multi site global footprint and you have these ad hoc processes, you can see how these kind of challenges multiply through the global supply chain. So what I found in my experience is that companies that migrate away from these ad hoc processes and tools into more formalized system, things like PLM systems, single sources of truth that are automated. I would also add SaaS based really can be quite helpful when you're talking about global supply chain because it's easier to log in and and get access to data. And this this now, you know, allows a single source of truth for both engineering and manufacturing to operate from. Yeah. So what areas then do you see the most rework in? Is it requirements interpretation or the communication, or do you think it's in documentation? Well, going back to my manufacturing days, it it it wasn't uncommon to actually build the wrong product because we had the wrong documentation. And then, you know, once you've built the wrong product, because it's physical, it can be quite challenging. Then you've got what are the options? You can rework it if you're if you're able to rework it or you scrap it and then you have to buy everything and start from scratch, and that can take that can take weeks to months. Yeah. So would you say that's one of the most expensive small misunderstandings you've seen? Ad hoc processes translated to manufacturing is a big issue. Yeah. Cool. So Shirish, what do you see as the most common disconnect between engineering intent and supplier execution? And what is it that strong teams do that closes that loop? So without repeating some of the stuff that Mike said, all of which is true, I think I'm with Dave where communication really is the key. In today's environment, you know, you have supply chains spread across multiple geographies. So even if you're using all the right tools without Excel and so on and so forth, Just because you're using the right tools doesn't mean your supplier actually understands what is being said. Right? So maintaining a very, very close communication between the suppliers during the transfer process is very helpful. One of the things that I've seen in most instances that is a cause for problems is, for example, in the mechanical space, not including critical dimensions, not including finish, not including which parts to inspect, where to inspect, is one of the disconnects. On the electromechanical side, one of the common disconnects I've seen, which I've experienced in pretty much every company that I worked at, is the fact that test requirements are not defined clearly. Okay? What an engineer thinks is lab testing, it doesn't necessarily translate into the manufacturing environment. So closing that gap, having all those included in your systems that you're sharing is pretty critical. So those are the common areas that you run into all the time. So let's move then to what good looks like as a multi supplier collaboration in a multi supplier collaboration environment. So Dave, when organizations get this right, what's fundamentally different about how they collaborate with their suppliers? I looked at this. I think we're talking about having a system. There's four pillars that build up that system. Mike mentioned it earlier, you know, we need that single source of truth. Everybody, so there's a common definition. Everybody knows what is the current revision, what's the current release. Everything is explicitly defined within that single source of truth. I think that's one of those pillars. You then need a very structured change management process so that any changes are properly reviewed and properly approved and then properly notified and pushed out to the relevant people. So that's the second pillar. The third one is good traceability. So you have that traceability in the system. You can see who's done what, when, when, you know, that's also important for, you know, looking at your systems. If things have gone wrong, you can look back in the history, look at, see how your design processes evolved. You've got that level of traceability and auditable set of data. And then fourthly, I would say the fourth pillar, having that continuous visibility and the ability to monitor your system. That's also really important. You can't just put the system in place and think the system's going to work. You've got to be able to monitor it. You've got to check that things are happening in the right way, in a timely fashion, by building you up and so forth. We know that mistakes can happen and will happen. We know that engineers can be under pressure at time and that they'll take shortcuts. I'm sure we've all thought, oh, I'll email this red line drawing across to a supplier now, I'll update the release later on. I think it's really important that when you introduce your suppliers to your system, you explain also not about the system, but you also explain your processes and you say, look, you need to encourage your suppliers, you should only respond, you should be only making this part if you see this part properly approved within your system. Don't rely on emails like this if you get a red line drawing. Obviously there will be times when you need to share red line drawings with your suppliers, but you need to make sure that they're very clear about that. You know, this is just for information. It's not yet anything that you should take action on. You only take action on something once it's been properly approved. If you're getting pressure from one of our engineers to do something for you, push back on it and say, no, no, you put that in the system, get that approved for a change order, then I'll make the process. That way you're using your suppliers to help keep you honest, you sticking to your own processes. So which of these pillars then, is it the last one, the monitoring, that you think are underestimated when people are scaling their supplier networks? I think it can be all of them, to be honest, and I know that you know we talk about scaling up and that when you're a small startup organization, small number of people, you may be just working with a single supplier, everything seems quite manageable. Mike was talking about managing things with spreadsheets and so forth and that's pretty much how I think every company will start out, But it is surprising how quickly that can get into a mess. So as you start to scale up, you get more people involved, maybe more suppliers involved. It is remarkable how quickly that can get, you know, mistakes can start happening and start coming into the system, coming into your system as you're starting to roll up. Just to add to that, you know, lot of companies put off the time it takes when they move from being that small startup to moving into a more scaled up company. And they don't sometimes realize how quickly with something like our Arena PLM solution, how quickly we can get them up and running. And I'm talking about, we can do this with small startup companies in a matter of weeks, even larger companies where they even have a larger data set. We can still help them get implemented very quickly with our solution and help them start to gain some of the benefits of what we were talking about. These four pillars of the system, a single source of truth, could change all the process, the ability to monitor and see what's happening with their data. Fabulous. So Jim, I can see you nodding away, when you look at these four pillars from your perspective, which one moved the needle most for you, and which one was actually much harder than you expected? For us, a single source of truth was both the most impactful and most immediately actionable pillar. At Fictive, we work with customers navigating the critical transition from prototype to production all the time. And we consistently see that by the time the customer is ready to scale, they've accumulated real change management debt, Multiple bills of materials floating around, informal design decisions living in email threads, no clear record of what's released versus what's still in flux. Using Arena allows us to offer supply chain as a service, essentially stepping in and providing the control infrastructure that some customers may not have developed internally. We could take a messy prototype phase, design environment, and bring it into a structured control state that's actually ready for manufacturing at scale. The other three pillars, they're all kind of downstream benefits from this central one. You can't have meaningful ECO workflows without an authoritative design record to change against, and you can't trace approvals if you don't know which revision was approved. So it's not so much that any of the others are difficult to implement, it's you have to have the right starting point. So, Dave, what would you say then to someone who says, you know, if we share more, we lose control. Like, many teams worry that when they share their data with suppliers, they'll lose, obviously, their control. How do leading manufacturers balance collaboration with governance here? Well, I would say really just sharing the data. You need to as long as you are in control of your data, you know what you're sharing, you've got to share data with your contract manufacturer, otherwise how do they know what to make for you? The thing is you're not giving them carte blanche to go and modify your data, go and build something that isn't being specified, go and choose some off the shelf components that you have not specified in your approved manufacturing list. That's where the problems come in. So I think, you know, you do need to share data, but you need to know what you've shared with them and share with them the information that they need to manufacture your product. You don't need to share with an other design information, for example, that's something that you keep internally, it's private to your company, it contains your IP, just share with them the information that they need to make your product. When I talk to new customers, and especially customers maybe not very familiar with PLM, I often explain to them and describe PLM, say, just think of it as your company's recipe book. In other words, it's the tool that contains the list of ingredients that are needed to make your product, But not just the list of ingredients, it's also the methods and how to put those ingredients together. That's the information that you need to have under control. That's the information that needs to be properly managed. And that's the information that you need to share with your contract manufacturers. Also bear in mind that that's the information that if you've decided that you needed to become dual sourced or you needed to swap a contract manufacturer, you've got to be confident that you've got all of that information. You don't want any of that information sort of held back by your contract manufacturer or supplier. You want to be able to is your IP, I want to be able to switch suppliers if I need to or introduce a new supplier to be dual sourced. Yeah, so you don't have to give away grandma's secret cookie recipe, but you can give whoever's going to the supermarket the shopping list. Exactly, exactly. So where does role based access make the biggest difference then? It's again you're just controlling what people can see And I think that's the important thing. We wouldn't, you know, with our Arena solution, we don't provide access to the contract manufacturers for all data within this PLM solution. It is based on what they need to be able to see. And you can do the same within your own business. You don't need to allow everybody within your own business to see everything. So you can control what people can see, what they can modify and what they can update. So Michael, a question for you now. From the supplier side, what actually helps CMs and JDMs work faster with fewer errors? Following a little bit what Dave said, the concept of tribal knowledge when I was working back in the manufacturing world really was problematic, right, because everything's in an engineer's desk, that kind of thing. So teasing that stuff out and getting it in the right form is really helpful. So when I put my Centimeters hat on, having a PLM system, as I mentioned earlier, combined with a strong document management process. So the other side of that is if you have a system and you don't have a good process, can automate garbage faster. If you have a good process and you have a good system, then you really have a nice outcome, has been my experience. The other thing that I'll mention just from having lived this on the factory floor is this idea of having the right manufacturer, manufacturing part number so you know what you're actually building. So a lot of, especially early stage OEMs that I experienced would design out of a catalog, things like a DigiKey or Mauser or whatever the case may be. And when that gets translated to the contract manufacturer, we actually have to build to an actual manufacturer, an actual manufacturer part number. So having to convert those convenient part numbers that are in a catalog and then turn them into real manufacturer manufacturer part number takes more time and can be confusing, can lead to errors. So I would encourage OEMs really when they're putting data in, whether it be an Excel file or hopefully a PLM system, that they actually use the right manufacturer, manufacturer part number so that you don't have to go through that translation problem on the manufacturing side. The companies that have scaled the best, in my experience, good centralized tools that allow the sharing of this data between engineering, between operations, it does allow building better products faster with less errors. Yeah. Full visibility across the entire chain essentially. So Shirish, what's a practical way to tighten the feedback loop so the supplier side workarounds don't silently become the new spec? So one thing I'd like to mention here is these days, you know, most of the suppliers are far more mature than they used to be twenty years ago. They're more seasoned, thanks to companies in the Silicon Valley like HP, Apple, Cisco, dictating terms to the suppliers even three levels down. So some of these problems actually don't occur anymore these days. But when they do, it is due to lack of communication and due to lack of expectation setting. Right? So the way to avoid that, especially with seasoned engineering teams and with seasoned suppliers, is during the transfer process to have regular DFM meetings to make sure that any questions get answered upfront, to have regular BOM review meetings so that the details of the bill of material and the approved vendor list are understood. And the expectation to be set is that you do not deviate from the approved vendor list. So you don't make your own decisions, so to speak, right, on the supply side, which can cause all kinds of problems. And I've lived through those. So I think having those tight feedback loops at the early part is excellent in keeping the suppliers honest. On during the process, as we experience, there will be engineering changes. Right? Engineering changes generally affect material, whether it's purchased, whether it's in stock, or whether it's work in progress. And so having the process and having the feedback loop to get, material analysis back from the supplier, making sure that the right decisions are documented, And only then do you say that the issue will be made effective or the engineering change will be made effective. So that ensures that all of the loopholes are closed essentially. Okay, and that's one way to make sure that the supplier doesn't deviate from what is being said. Yeah, no deviation is often good as well. We don't want people making wild decisions on their own. Yes, yes. So Jim, I've got a question then for you: what's the single most helpful thing a manufacturer can do that makes a supplier faster immediately? Well, I can kind of take what Dave said, what Michael said, and what Shareesh said and summarize it in one word: clarity. Right? There should be no ambiguity around what a supplier needs to provide, how it should be made or procured, when it should be delivered, and even how they're getting paid. Using a PLM allows us to manage those first two things effortlessly through a controlled system of record: documentation, CAD drawings, specs, requirements, deviations all consolidated in one source of truth. So let's let's bring this to life then. Let's do a before and after. Are you okay? Okay. So let's yeah, let's do a before and after. Before making changes to how you collaborated with your suppliers, what problems were you consistently running into, and how did it build day to day? So the challenges we generally saw fell into two categories, each affecting the business in different ways. The first involved occasionally building parts to the wrong revision. When that happened, it typically required rework or remakes, which impacted cost and time. This highlighted the importance of ensuring that correct revision is always clearly communicated and controlled throughout the whole process. The second category was a little bit more subtle, but just as important over time, and that was ensuring that all customer requirements were consistently captured and fulfilled. These could range from critical design specifications to smaller administrative details like certificates of conformance, packing slips, inspection reports that match what was shipped. While none of these issues was significant on their own, recurring gaps often stemmed from requirements being documented informally, generally in things like Slack threads or notes or emails, rather than within a centralized controlled system. And it's never a big thing as it's always little things that stack up and become overwhelming. So what specific changes have the biggest impact on resilience and execution then for you, and how did you roll them out without actually disrupting everything? Centralizing design data and bringing the suppliers into the process earlier, and actually our very first program illustrated why both mattered. We were still transitioning off of our old way of working when we received our first purchase order through the new system. When our team went to execute, Arena flagged something that would have slipped through entirely in the old model. We had quoted a different revision than the one referenced in the customer's purchase order. The customer released a new revision without a system pulling it into a controlled, visible environment. We would have built the wrong spec and never have known it until it was too late. Because it was caught early, we were able to loop in the supplier, assess the impact to the quote, and process the change order all before it even touched the customer's timeline. That experience set the tone for how we rolled things out more broadly. We didn't try to flip everything on at once. We let the system prove its value in real execution, and that first catch became the internal case study that we got to test got the rest of the system, rest of the team bought in on using the system. So, obviously, you mentioned some of the outcomes there, but what were the measurable outcomes that you saw? Was it the speed, the quality, the audit readiness? And what areas surprised you? The quality of the products and the quality of the data around our production bills have been the most significant measurable outcomes. We've been able to drive better quality for customers since releasing the new system, and we've been able to track design builds and inspections in a single system and report them globally. Arena's investment in AI, automation, and integration with external services enables us to rapidly improve in this area. Yeah, so fewer escapes, fewer fire drills here. So let's talk about the let's connect collaboration directly to distribution readiness because that's where resilience really gets tested. So Dave, how does better supplier collaboration help organizations respond faster to disruptions or sourcing constraints? One of the most important things to make sure you have set up is providing a simple way for the contract manufacturers to log issues back with you. You know, your contract manufacturers are there, they will spot potential risks, they will know probably if, you know, off the shelf components are going end of life and if they're going to have short supply and so forth. So having a system where they can quickly log an issue and allow you to manage that issue swiftly within your organisation. What Shiraz was saying is you can't allow your contract manufacturers to make decisions for you, but you can use your contract manufacturers to alert you to decisions that you need to make. But you've got to provide them a mechanism to feed you that information and try and avoid that just by coming in via email, having it in a system where you can actually log their requests properly, monitor those requests and properly manage and respond to those requests. So that's, you know, one of the mechanisms by which you can certainly put in place to help you respond faster to those disruptions and those sorting issues that may arise. So another thing that you're going to do is switch suppliers: what enables fast supplier switching with confidence? I think it's going back to that single source of truth. If you have a good definition of your product data, have all of the information, that's going to help you switch suppliers when you need to do that. We have in the arena a system that, you know, for electronics components, we have something called our supply chain intelligence tool, which was mentioned earlier, where we're using AI to search into, off the shelf components, which may be at risk, going, maybe on short supply. And we can use that tool as well and to help us quickly find alternatives and bring that into our arena system, go through a rapid change process and push that out to suppliers as well. So next question is for Michael or Shirish. What's one thing that manufacturers can do this quarter to reduce supplier related risk before the next disruption hit? Let Michael answer that question. Sure. One very practical step that I would recommend anybody do, and it's just a good OEM practice, is to get a better handle on the visibility of components and the supply chain and what's happening, especially when it comes to risk parts. You think about parts like sole source, single source, you look at the world today and with all the geopolitical disruptions and energy disruptions and really get a handle on where are the parts coming from, where are the risk points and then how do you mitigate those risk points is something really tangible that I would recommend companies take a look at. If the information is still living across spreadsheets and emails, that can be a little bit more challenging. If that information is centralized into PLM system, it tends to be a little bit more easier to manage. There are some amazing tools out there that can dig into supply chains, put in risk. I know Arena recently came out with a supply chain portal that has risk as one of the elements. But there are other systems out there too, right? It doesn't have to be Arena. So looking at your bill material, figuring out where those parts are coming from, what are the risks, and then actually creating a plan to mitigate those risks is one tangible thing I would recommend companies can do today. Brilliant. I think the one thing I'd like to add to that is really for the OEMs or the customers to understand the architecture of your supply chain. Because you don't just work with one supplier, there are three, four, five suppliers down the chain that you're working with. Figuring out where they're located, is there a risk with where they're located, etcetera, also can be very important to understand in the short term. Brilliant. So, Jim, I have one question for you before I move on to our practical takeaways, and that's what would you prioritize first if you were to start again? Good question. It's easy to create solid, high level process flows, but you can lose the nuance in translation when you convert existing processes into system supported processes. Mhmm. And it's those small details that tend to have an outsized impact. We saw this firsthand at Fictive when we when we moved into Arena. The other thing I'd prioritize is about being intentional about scoping Arena for what it actually is. I wouldn't try to make Arena a CRM or an ERP or a TMS or a quoting engine or a primary communication platform. Even though it has some of those capabilities, evaluate those tools if they work for you, but don't lose sight of the core value. We tried to extend the QMS features a bit beyond their intended design, which caused headaches that we weren't ready for from a process maturity perspective. The important question is, Where does the PLM or any tool actually fit in your new product development process? Get clear on that first, and then let ARENA excel exactly at that. A PLM that does its job really well is more valuable than one stretched into roles it wasn't designed for. A very small example is customs information and documentation. It's a small thing, and our intuition was to put this in ARENA since it ties to item documentation. In reality, this meant that whenever it needed to be updated, users had to run an ECO on an item, which isn't meant for quick updates like an HSN code. It also removed logistics from the working system they were in and removed them to a PLM to complete the work. This caused us to rework that functionality and merge the information into our ERP, where customs information should actually live. So we are running out of time. We've only got a couple minutes left. So on this very last section here it's going to be key takeaways and I'm going to try and challenge you all to give me thirty seconds. So if attendees take away one action from today, what should it be? I'll throw it to you first Dave. Well, I would say align your processes around a good solid single source of truth and a good solid change order mechanism. Perfect, very important thing. Michael. Include suppliers early and treat your supply chain as an extension of your business. If you think about COVID and what happened there, the companies that survived relationships with their suppliers and their supply chain. Harish? The way I would look at it is really defining governance. And by that, I mean having the right set of expectations set up early, having the right feedback mechanisms and constantly monitoring them, and staying in touch with your supply base all the time. Fabulous. And finally, Jim. I would say don't wait for failures. Pick one workflow like ECO management and standardize it end to end. Great. Some great advice there. So we have got time for a few questions. So the first one I have on the list here is how does using Arena change the way engineering changes are communicated, acknowledged and executed across suppliers compared to that manual process? I'll try and answer that question as it's specifically about Arena and I ought to know the answer. Yeah, Arena is a built, you know, it's solution that's been designed and built for this purpose, So it's got all the notification processes in place. So for example, when a change order is approved that can automatically notify your suppliers, both in notify people internally and externally. So it can you and you've got a record, you know that when that person got notified, you've got that in an audit trail as well. And you've got the ability as well of allowing suppliers to raise change requests in your Arena system, raise quality processes in your Arena system so they can give that positive feedback I was talking about earlier as well within Arena. So the mechanisms are there to be used to improve that communication. So our second question here is: from a supplier execution standpoint, what difference does it make when manufacturers use Arena to share controlled bills of materials, documentation and change history? I I think, again, this this goes back to the notion of single source of truth with a approved change control process through it, so that you could make sure your suppliers are always looking at the same released data that they should be working to. I think that's the most important thing. That's the most important takeaway from most of this. It's really, really easy to get out of sync with those suppliers or to release something to them that you think is gonna get approved and send them off in a wrong direction. Yeah. I mentioned the the two Excel files and that kind of thing. So, you know, the the the companies that we worked with that had these kind of organized systems and had ways that everybody could share the single source of truth and work to the single source of truth, work off the same recipe as Dave said, really made it a lot easier to build products in a consistent way and even deal with questions. If there were questions, there was one place where the question was that could get addressed by engineering teams, as opposed to this kind of tribal knowledge ad hoc process where one engineer says one thing, another says another, and then what are you supposed to do on the manufacturing side? So I've got one more question, and I think everyone should answer this and we can just do a little lineage. And it's if a company is early in their journey, where should they focus first? I'll go first. How's that? Yeah, perfect. So I think, really, systems can come later. I think the the first thing is really to make sure that you've picked the right supplies that fit the needs that you have. Right? The second is making sure that you have the right internal, processes to be able to work with those suppliers. Even if you have Excel spreadsheets, even if you have other basic tools, those are more important than having all these expensive systems to come in. And they can come in later. Right? But fixing your processes and finding the right set of supplies is really key. Yeah. I think I can I my I would agree with that? I think the process that you have for controlling change is is most important, especially at those early stages. And, you know, we see a lot of customers going through prototyping. Prototyping is very chaotic. But when they begin to transition to production, that's the key critical phase. And with we see very, very, very different differences between customers that have, taken the time to think about, you know, how do I lock in the design and how do I release it, and, how do I communicate it to a contract manufacturer that this is what I need built, and customers that don't have that in place, and very different experience of working with each of those. And, yeah, I mean, the systems I would agree, the systems are kind of secondary. You need that solid process and that solid understanding of how you're going to control information. Michael? I would I would go even further back to chain. I mean, the the the biggest challenges that I've experienced either working at OEMs or or building products has has really been that the product as designed is not what the market wants. So this goes all the way back to, are you designing and building a product that somebody wants to buy? Can you make money? And when you're talking about technology based companies, is it technically feasible? I've got a company that we're working with right now that we were helping with supply chain and all these other things. And they had an expert come in and it turns out that design as designed was not feasible. It just didn't work. So now they're gonna take a three month pivot and redesign to review the technology. So really understanding the market dynamics as well as technical feasibility to me are the kind of steps one and steps two before you get into processes and systems and all the other stuff. And Dave, I'll give you the final word. What I was going to say, and I was listening to all your answers, that my experience as well as being I've come across companies, sometimes smaller startup companies, were looking for guidance, looking for guidance about what about their processes, what is best practice, what's the way to go forward with the Aribena solution that's been developed, we have thousands of customers all in different sectors, but they're all manufacturing customers. They're all wanting to build a product. So the processes that we've developed over the years at Arena, they're designed to work across the board. They're configurable but not customizable. So the concept, you know, if you're in that situation, you say, well, don't you know sometimes I fear that you can spend too long agonising about how my process should actually be. Sometimes it's better to say well let's get on let's pick up this process' for example that we have in Arena We'll configure that process. We'll work that through. We'll look at, you know, be pragmatic. We can look at sort of iterating that and improving that as time goes by. But if there is benefit to getting your system, your data under control in that single source of truth and getting something in place and probably taking a pragmatic approach is my advice. Brilliant. Well, thank you so much. There's so much takeaway from this conversation today. It's been an absolute pleasure speaking with you all. If there is one theme from today's discussion, it's this strong supplier collaboration is no longer a nice to have. It's essential for resilience, agility, and long term competitiveness. After this webinar, everyone will receive follow-up materials, so keep an eye on your emails. But for now, thank you so much for joining and goodbye. Thank you. Thank you.