Description
Key Learnings
- Learn how to effectively transition data to Inventor and Vault from competing software.
- Learn how to implement Inventor and Vault effectively, enhancing workflows and data management.
- Learn about best practices for data integration in Autodesk tools.
Speaker
- OHOliver HarbidgeI am a Digital Development Engineer at Playdale Playgrounds in the UK, where I leads large-scale software implementation and automation projects across the company. With a focus on improving efficiency and streamlining processes, my expertise lies in transforming business operations through digital solutions. My work ensures that Playdale stay ahead in the industry through the use of technology to drive innovation and optimize workflows.
OLIVER HARBIDGE: Hi, welcome to Connecting The Digital Dots, Achieving 10% Year on Year Growth. My name is Oliver Harbidge. I'm a digital development engineer at Playdale Playgrounds.
Just a quick note about us, about me, I've been a digital development engineer here now for maybe two years, I would say, maybe focusing on kind of large scale digital change in my company, as well as smaller scale digital change, automating little roles in people's jobs that maybe get in the way of them doing the fun roles that they really enjoy doing. Playdale makes designs, manufactures playground equipment, which we export all over the world from the UK to the US, UAE, China, Hong Kong, everywhere, and we have a real commitment to innovation and quality.
So what I'll be doing throughout this talk is kind of giving a case study on us, what we've done with the Autodesk products, what we're planning to do, and the challenges and things that we've had to overcome in order to really streamline our digital process and really kind of enhance how we work using Autodesk products. So in section one, I'll be identifying the challenges that we face as a company using more traditional methods of CAD software solutions and kind of going over what we've done to overcome those challenges. Then I'll be talking about the top level business incentives that have caused us to have to make a change.
We've thought, you know, maybe we're not working to the best of our ability. Maybe we could be using more with our software. So I'll be talking about those reasons that have forced us to adopt this change and why that change has been good in the long run. Then I'll be giving a more technical implementation, a more kind of talking about the actual products we've implemented, why we've implemented those particular products, and having a look at the future of what we'll be implementing.
Then in section four, I'll be taking a product from concept to launch. Firstly, I'll be going over what we used to do, the challenges involved in taking a product from concept to launch in the old style. Then I'll be going over how we've improved things using the new streamlined Autodesk pipeline that we've implemented over the last few years. Then in section five, I'll be looking over the future improvements we want to make using new Autodesk products and just recapping what we've been over so far.
So section one, identifying the challenges. I think to a lot of people watching, it'll probably be very, very apparent that one of the major, major problems people often have and one of the first things people like to address is version control, and that is something that we really struggled with at first. Now, we would often find that our CAD models would have much different issue numbers to our work drawings. It's because we relied really heavily on word of mouth and email to inform our shop floor operatives that a change has been made to a part or a component, or maybe we would make a last minute change to something before it was to be manufactured. That change wouldn't then make its way all the way through, and we would end up with an old version of something being manufactured when, really, the tech guys have been to all the trouble of designing something new to fix a problem. It's not actually ended up on site, and that's cost us time, and money, and reputation.
We also had huge problems in the past with data migration. So we've tried to implement digital changes in the past, where we've had really old legacy data problems. We've been using different CAD packages, different non-Autodesk packages for over 20 years now. That comes with a lot of baggage from previous iterations of different softwares that we've tried and used over that time. Getting these bits of data, bits of models, anything into new packages is always a real challenge. So we need to do that, ensuring minimal data integrity loss. We struggled with this for a long time, and it's something that we've had to overcome, whilst implementing new Autodesk products.
Something we also have a lot of problems with was, as I previously said, reliance on emails and personal accountability. So not only would this have a risk of errors. It was also just very, very inefficient. We would often have someone would make a change to a component of some kind. They would print out a document. They would walk down to the shop floor. They would hand that document to someone whose job it was then to get to the correct operative, so that they made the component correctly.
Oftentimes, this wouldn't happen, or it would take a while. Someone would maybe wait for a stack of papers to build up on their desk before they decided to bring it down to the operative. It's not an efficient way of working, and it definitely led to some problems for us.
Finally, BOM management was a real problem for us, Bill Of Materials management. We had huge difficulties maintaining accurate BOMs, because we had to manually update them every time in our ERP software. I know for a lot of people, they're probably thinking the same thing, because manually updating bill of materials for very complex parts takes a very, very, very long amount of time, and it really ties up your engineers. You don't want your engineers to have to be constantly, instead of doing the thing they love, which is designing, going through ERP software, manually clicking buttons, manually changing ones to twos, manually changing twos to threes, getting rid of components we don't need anymore, coding up new components. It's a mess.
This can have a real impact on production and costs, and also, it can lead to a lot of mistakes. Personally, when I was working as a design engineer, I made a huge mistake with a bill of materials, where I thought that there was a big tower system that was going all the way across the world. I think it was going to the UAE, something like that from England, and it was, like, a two tower system with a big slide. And it just needed a simple bridge going between two towers, and for some reason, I decided to make that an incline bridge. That was just the difference of one number in the bill of materials that changed the product code from a linear bridge to a curved bridge, and it created a huge amount of hassle for me.
I had to build this thing. I had to drive it over to our distribution center. I had to help them pack it up, and I had to do that in one night. It's terrible system. So anything we can do to alleviate manual BOM entry, the better.
Having a single source of truth was also a major thing for us. There's a lot to be said for single source of truth, and I think there'll be a lot of people talking about this. But it's such a huge thing, and not having a single source of truth can really lead to some challenges in the workplace.
We would often have the master data for some part, or component, or product on some spreadsheet, somewhere on some drive. There would be four or five of these spreadsheets, all on different drives, all everywhere. Some of the single source of truth for something would be in the model. Sometimes, it would be in the RP. Sometimes, it would be on one of these spreadsheets. Again, it's just not a good way of working.
We also had huge internal skill gaps, which really hindered us in implementing digital change within our workplace, and it's just not something that traditionally a lot of stock was put into when hiring new people, and it led to a lot of complacency within the workplace, where if someone was happy with the way of working and thought it worked OK, that's what we would do. We would do it forever, because no one knew what to do to implement this new digital change that we needed in order to innovate and keep up with the rest of the industry. So I'm going to talk about an importance of skill development and making sure that people have the right skills in order to do this kind of thing.
And, finally, obviously, a problem that everyone will have in any industry is a huge resistance to change. I think a lot of people get very, very stuck in their own ways. As I was just saying, my previous CAD manager, he'd used the previous CAD package for over 20 years.
He was brilliant. He was the best CAD engineer I've ever seen in his specific software that he knew how to use, and he found it very scary to move to something new. So overcoming that human change, I think, a lot of people think it's only the old guard, it's only the new guys, and they're not going to want to change. They're not going to have that drive.
But I think people need to remember a lot of the time, a lot of the resistance to change can come from very, very respected members of the industry who maybe just know what they're doing, and know what they like, and don't want to change. So a lot of what I'm going to talk about is overcoming those barriers, as well, talking about relevant training close to the time of implementation. I think a lot of people overlook how necessary it is to get training and relevant training close to the time of implementation for a piece of software rather than just throwing some training at people, saying this is what you're going to be doing in a year or six months.
By the time that software comes into being, they've forgotten everything. They go back to their old habits. They start using the old software, again, because they're not ready to change.
So in section two, I'm going to talk about the specific technologies that we've implemented to help overcome some of those challenges and the specific challenges that have come for us in implementing those softwares. So the first thing we implemented was Autodesk Inventor. Autodesk Inventor, first of all, had a huge benefit for us in that we were already using a lot of Autodesk products, our 2D layout guys.
So we have two main sections of design when it comes to the playground industry. We have the guys who design the products and design all the new components, the bits and bobs that go onto a playground, and then we have the guys that will help our customers find the correct layout for them. They will drop those into a 2D plan, make sure that everything lines up, make sure all the safety surfacing, all the safety areas, make sure that the playgrounds are safe as possible for the children. And what we find is that before, there was a very, very big break in our systems, where before we were using a streamlined software pipeline through Autodesk, we would create a 3D model of a piece of equipment.
We would then have to export that, do a lot of work, top down, DXF, export. Then we would have to draw on layers to make this model work in 2D. Then we would ship that over to the guys at 2D, so they could use that. But there is a break in the connection between those two departments, because then, if something is updated at the 3D level, nothing changes.
There's no flag to anyone that anything has changed in 2D. So it's a very, very manual process. The same would also happen with our 3D visualization team. They were using 3DS Max to create beautiful visualizations for our customers, and for our catalogs, and stuff like that.
Again, we would create-- the technical guys would create a very, very competent working piece of playground equipment that they would then have to sever, export, send to the guys in the 3D visualization department, and again, there was absolutely no note to them that anything had changed. This would all be a very manual process, more exports, more time wasted, less time. The guys get to do designing great products, which is what they love doing, and we also got the enhancement in design capabilities that come with a world class package, like Inventor.
The second piece of software that we've implemented is Autodesk Vault. Now, obviously, that manages hugely what I was talking about with version control. It also creates a very secure and centralized data management system for us.
What we were previously doing to manage our data was just having files in Windows Explorer. There's no version control. If someone starts to work on a component, change a component for whatever reason, there's nothing there to tell anyone else that this component has already been worked on. So introducing Vault was huge for us, because it allowed us to take control of these components that we previously were just hoping and relying on human communication to make sure that no one would do any duplication of work. And we've taken that, and we've really streamlined that process in line with our CAD package and all the other packages that we currently use within the Autodesk suite.
So there were some specific challenges that we had to undertake and overcome to implement these pieces of software, and one of the first ones comes down to what I was talking about before, which is legacy models and converted data from previous CAD packages. Now, I won't lie. This is an incredibly long process. The conversion of models to correct invented part files was quite difficult to figure out for us, but what we wanted to do going into this, going into replacing our entire CAD package with one streamlined package solution in Autodesk was start fresh and have all clean models, everything connected, everything in the same version, everything cleanly implemented together.
So what we had to do was lean on our CAD package reseller, which was CAD Line, now, Arkance, and they helped us write a script along with the help of a common popular AI website. We used ChatGPT to help us write scripts that would take previous models. It would load them into Inventor. We would then pull data from, as I said before, each where and everywhere, our ERP system, and spreadsheets all around the drives, and we would collate that into one big spreadsheet, which we then use via scripting to inject all of these new parts with custom properties.
What this then allows us to do is catalog those paths when we automatically load them into Vault, so that, now, every part is searchable via custom properties. You could search for any part that was made of wood, or any part that was within a certain range, or any part that was classified as a bracket, et cetera. The list goes on. This was a huge deal for us, and it was something that we really wanted to get right first time, which is why this was such a long process for us. But it's been a process that was really, really worth it in the long run. Because if we hadn't done that, then there, basically, would have been no point in doing this from what I believe, and think we've really done this correctly, even though it has taken a bit of time.
Again, another challenge we face in doing this is the user adoption from company stakeholders. Top level company stakeholders are looking at are spending all this time and saying, well, we're wanting to bring in all of this new technology. Why is it taking so much time? I think, when we get later into the presentation, you'll see the results that we've managed to achieve with these processes, and you'll see that what we needed was some faith and backing from our stakeholders. And, fortunately, that's what we got, and it seems to have paid dividends.
So one thing we had to do, as well, during the implementation of these is training, training, training, training for everyone involved. Now, I have said this before, but I need to stress it again. Training programs for staff are absolutely vital. We reached out to our CAD resellers, our accounts, and they talked us through what training we would need, when we would need to do it. They made this so easy for us, and what that meant was, when we implemented the software, people were ready to use it immediately.
We have tried and failed in the past to implement new software, because as I said, what we've done is brought in new software. It's been brilliant, and we've been promised the world. But, unfortunately, our goals haven't been realized, because training has been done too early. People have forgotten everything by the time the software is implemented, and they go back to using old, inferior methods.
So this was absolutely crucial for me in promoting the system usage of these new bits of software for us, and of course, what you then need to do is to support ongoing initiatives that really cement these new processes in place. One thing that we found really useful when doing this was running mandatory, monthly, very, very informal meetings with anyone who was using new softwares, where we would just ask anyone who was using software over a month to note down any little tips and tricks, and we would get everyone into a meeting. And we would say, right, what little tips and tricks has everyone got to share today?
And what this really does and what we've seen this does for us is kind of creates a sense of competitiveness within people, because they want to find the best tips, and they want to find the best tricks, and maybe they'll start doing things with this new software that you didn't even know we could do, because they'll want to find out the best single one and impress everyone when they get to that meeting. And it really turned into quite a nice, warm spirited kind of competitive meeting, where we would really, really, really try and support people using our new softwares in innovative ways that maybe we hadn't thought of before. So I really can't stress-- and I think, if you take away one thing from this seminar, It's maybe just try that, and maybe it doesn't have to be software integration.
But just try that, because, honestly, it worked for us very, very well. Also, I'll just say previously, I mentioned the scripting that we did using our CAD provider and AI. And if anyone would like to talk to me about that privately, I'd be more than open to talk about that. You can reach out to me at oliver.harbidge@playdale.co.uk. Drop me a line. I'd love to talk to you about that, because it's been a very, very interesting journey for us.
OK, so in section three, I'm going to briefly outline the top level business incentives that showed us that we really needed to make a change and change how we were working, because at the end of the day, this is what we're doing this for. We need to move our business forward. Otherwise, what's the point of doing any of this?
So the first thing we really, really needed to do at Playdale was increase our scalability, improve our scalability, because as I previously talked about, we had a huge reliance on emails and personal accountability to do things, like inform other people that models had changed or inform other peoples that drawings had been up issued. One of the huge things for us was finding out that a drawing that had been up issued a month ago was still sat in the drawing office, in the production office, sorry, at issue one. It could be at issue three, and the guys have no idea.
So not only is this really inefficient. It's also not scalable at all. Because if you want to grow your business, you can't have inefficient systems already in place, because they get more efficient, the more people you add it. It doesn't scale linearly. It scales exponentially.
You add more people, more mistakes get made, more people rush to fix those mistakes, which leads to more mistakes. It doesn't work. So what we really needed to implement and what we did implement in Vault was a complete reduction in those errors by making accountability digital and automated. So that was such a huge thing for us.
What we also wanted to do with Vault is leverage data for decision making. So I've given an example on the slide there. It's a small example, but it really shows the power of what you can do with a centralized data system, like Vault, a single source of truth, like Vault, for all of your data, which is now that we had all this data, we could look and extrapolate which parts maybe weren't being used to their full potential.
Say, it would be more efficient, or it would be the same amount of effort to make a bracket. We can make 30 of them, but we're only making five at the minute, because we don't use them. We use 10 a year. And if we made too many of them, they would just start stacking, stacking, stacking up in a warehouse.
What we can now do is look, see which parts are being underutilized from previous ranges in our catalog and decide, you know what? We're going to try and use this in the next project. We can increase efficiency that way and really start to make a difference to our bottom line the same way.
What we also need is a competitive edge, and being forward thinking and implementing new software solutions can really give you a competitive edge, because we know that we're not the biggest playground manufacturers in the market. It's just a fact. However, what we would like to try and do and what we're working towards is being the most efficient and being the most innovative. And if you can show that to your customers, you can really show that you're a differentiator in the market. You can get products to them faster, you can them to them cheaper, and at the end of the day, that's what matters to the customer.
So that's what we're really trying to do. We're trying to be ahead, hopefully, one day the largest, but until we are the largest, we want to be the most innovative. And then all of this, obviously, everything I've just talked about leads to cost savings, leads to less material wastage from fewer mistakes. It leads to more efficient working practices, not just amongst production staff who can now get drawings digitally on a tablet, instead of from a piece of paper, but it also means that your technical teams, your design teams are working harder. They're working more collaboratively together, and all this efficiency builds up and leads to some real world cost reductions, which we've started to realize now after having Vault and Inventor implemented for a few months.
So in section four, I'm going very briefly run us through a system. I'm going to take an imaginary product from concept to launch. I'm going to do it in the old style of how we used to do things and highlight the mistakes that we may have made or the inefficiencies that we had been doing. Then I'm going to take the same imaginary product from concept to launch in the new style, and we'll see how those efficiencies have stacked on top of each other to create a much more efficient and less bulk down approach to product design.
So first thing is concept development. Concept development doesn't change. It's always for us-- it's always pen on paper, sketching things out. It's a thing that's worked all this time, and I don't see that changing any time soon. What I would say, and it's not directly related to this seminar, is that what we have started to do-- and I would urge anyone who's in a design sector, where scale and color aesthetic really matters to you, is to start utilizing VR, because we've been utilizing VR.
What we now do is create our concept work in 3D, part that into VR, and then what we do is show our stakeholders how big something may look. They can see that maybe from the perspective of a child's view, so they can see what it would look like as a playground to them. They can spot colors that they may not like. They can say, we think that bit should be bigger, et cetera.
This has saved us thousands of pounds, thousands of dollars in terms of man hours, not creating prototypes that then get built, installed, put up in our warehouse only for a major stakeholder in the business to say, no, that's not what we envisaged, go back to the drawing board. So not really related to this, but I just had to get that in there, because it's been fantastic for us. Right, so we go through from concept with concept and some piece of play equipment. We would go through to design and prototyping.
What we would see before is little to no automation collaboration within the internal design team. So what that means is, as I said before, we have people. They vaguely know what each other's working on, and they're not going to try and consciously work on the same thing that anyone else is working on. But, inevitably, when you have a large design team, that's going to happen at some point.
So two people are going to end up working on the same part by accident. It's going to be a huge duplication of effort. It's going to be a huge duplication of work, and it's just not efficient for anyone.
Similarly, when you move over, when you've got something ready to be manufactured, we would then find, as I've previously talked about, drawing issue numbers. They would often be wrong. Parts were getting made to old versions, and obviously, this wasn't happening all the time. We wouldn't make any money if we were constantly getting things wrong. But it did happen, and it happened more frequently than we would like to.
So we knew that something needed to change there. We couldn't keep going on and on with drawings constantly showing people to make the wrong part. Then you'd get to production launch. You find you've got through design. You've made the thing. You've prototyped it. Everyone's happy.
You get to manufacturing. You iron out all the kinks. You make sure everyone's working to the right issues. You get to production, and I don't know what's happened.
Your 3D visualization team have got the wrong model from two months ago when you've made some changes to that. They don't know. No one's told them. An image of the old piece of equipment goes in the catalog, and now, you've got to recall a load of catalogs or printing loads of new catalogs and send them out. It's nightmare.
Same thing with our 2D guys who are dropping bits of play equipment onto 2D environments, they're rearranging them. They're making sure that safety areas match. I don't know what's happened. That slide's actually on the other side of this piece of equipment, and now, none of that makes sense.
We've just sold one of these to someone, and it's not going to look anything like what they thought it was going to look like on their architect's plan. And again, this wasn't happening all the time. We weren't total amateurs, but it was happening enough to the point where we knew we needed to make a change.
So this is a new system analysis. You can see that the concept development stayed the same. We're still drawing things on paper. We're still making-- you're still making all the models, still using the VR. But now, when we get to design and prototyping stage, we've got massively improved collaboration within the product team using Vault and using Inventor, because everyone knows what everyone's working on.
You can't work on a part that someone else is already working on, because that part will be checked out of Vault. No one else can check that out. It's already checked out.
Manufacturing preparation, revision control within Vault, it basically means that there is no issue number disparity anymore. It can't happen. The guys are using the Vault Thin Client on the shop floor to look at works drawings. They can only look at those works drawings when those drawings have been approved by the technical manager.
He's sure that everything's working and happy with that. It goes to the guys on the shop floor. If we want to immediately recall something, we can take it away from them. They won't even be able to see the drawings, so they won't be able to make the part.
And then same with the production launch, now, everyone's working to the same drawing. Sorry, everyone's working to the same model. The technical guys who designed the product are working to the same model. The 3D visualization guys, they're working to the same model that the technical guys have just made, and the 2D people are working the same model, because everything links, because it's all in one smooth, interconnected pipeline.
That's worked very, very well for us, and you can see here in some actual statistics of how that's worked. So what I've got here on the left in yellow is our Jukebox Plus Range, which we launched a few years ago, and something we launched this year in blue, the Woodland Eco Tower Range. These are very comparable units. They have the same amount of products in each range. They're both timber.
The yellow one is just a bit older, and the blue one is newer. You can see we managed to reduce the hours to complete. We shaved off roughly 200 hours. These are estimates, but they're well defined estimates. And I think it's pretty accurate to say we've shaved off about 200 hours from the design time of this range.
Our component errors have gone through the floor. These can now mostly be attributed to simple everyday mistakes that every company is going to make on production paths. It happens nowhere near as much. This is specifically talking about specific prototype units.
And I wanted to say that we had no issue number disparity. Unfortunately, there was one. Something slipped through the cracks, but you can see that, basically, the issue number disparity has gone now totally.
So you can see that's 20% faster launch compared to the last comparable project, a 63% reduction in incorrectly made components during an initial run, and almost 100% reduction in issue number disparity. I'd say 100. I hope that's been helpful. I'm just going to recap everything I've gone over quickly.
So the quality of improvements that we've seen by implementing this streamlined Autodesk pipeline is one enhanced team collaboration, huge, the guys work together much more seamlessly now, improved product quality, we're making less mistakes, less issues on site. It's been fantastic. Reduce manufacturing errors, same thing, faster product development cycles, because everyone's working together. We're not having to go back and redo work.
We've got streamlined workflows and processes, and as I talked about with Vault, we now have much easier reuse of design components and data that previously we wouldn't have realized we were underutilizing. So as I said, maybe there's a bracket that we haven't used somewhere that we could definitely make to its full potential. So version control, manual processes, BOM management, and single source of truth, these are the four main key takeaways that I went into this project hoping we would take away, and I can safely say that these are the four things that we have massively taken away.
BOM management, now, all handled within Vault. So if a 3D model is changed, the BOM is changed. We have a single source of truth within Vault for all of our product data. We have eliminated a lot of manual processes before, especially BOM management, and there is now no disparity in version control or very little disparity of version control between components and work straw lines.
The emphasis here has been on making sure that people embrace technological change, because as I've said previously, no, you don't have to be the biggest guys in your sector, whatever that sector may be. But if you're leading change in technology, it's only going to be a matter of time before you are the guys in control, you're the biggest guys in your sector. And look towards your team, look internally into your team for encouragement, for continuous improvement. Get those guys involved, get them coming up with little tips and tricks, make sure that your guys are sharing what they've learned using new softwares together, because that can be invaluable, and it's really led to some good things for us.
So, lastly, I just want to talk about what we're planning for 2025 and beyond. Fusion operations, huge in the manufacturing sector currently. We've talked a lot about making sure that issue numbers and change management are good enough. Could they be better? Yes, they definitely could be.
Fusion operations is going to really help us streamline. Once we've got the guys the information on the shop floor, what do they do with that information? How easily can they access that information? How easily can the guys on the shop floor talk back to technical to tell them that a change needs to be made?
How easily can our production control guys make sure that we are working efficiently in the production office? Can we, say, allocate resource from one section of production to another to make sure that we are keeping up with demand, et cetera? At the minute, this is all still manual, and I imagine, hopefully, next year, I'll be back talking to you about the same thing, and I'll be talking about how we've increased our production x-fold by implementing fusion operations.
Similarly, in 2025, '26, we want to integrate fusion manage into our streamlined pipeline, so that we can really manage our change even more effectively, get rid of that last one that I had in the graph, get that down to zero issue number disparities, and I'll be very happy. And thank you. If anyone has any questions, as I said, my email address is oliver.harbidge@playdale.co.uk. I'd be more than happy to hear anyone's questions, or thoughts, or feelings about this. And yeah, thank you very much for listening.