Busting a Move: Changing from Project-Based Manufacturing and Design to a Product-Based Environment

PRESENTER: Well, welcome to Busting a Move, Changing from Project-Based Manufacturing and Design to a Product-Based Environment. This is a case study from Dynamic Structures, where we'll go over our transition from that project-based working environment to the product-based one.

So a little bit of an agenda-- I'll tell you about us and where we come from. We'll discuss the project-based environment a bit so that we can know what we mean by that and what defines a project. And then we'll talk a bit about the path that we took to get to where we are now, which is that product-based environment, and what makes some of the things that you need to be aware of with that.

I'll go over some tips and tricks that are sort of handy things to have, and I would refer you to the handout that goes with this session. I've tried to give more detail on those tips and tricks in the handout.

Then we'll have a section for questions so that I can answer anything that you have. And finally, the images that are from this slide onward are all courtesy of Dynamic Structures. So let's get to it.

So about us-- we'll tell you about our history. I would like to dedicate this presentation in memory of Ben Cornelius. Ben was our CAD manager at Dynamic Structures, had been with us quite a few years. He was the senior lead modeler on many projects and, like I said, CAD manager. He was one of the main members on our progress and improvement committee. He was the one that actually put most of the things into place that we had to learn how to do along the way. And sadly, he was taken from us too early.

So a little bit about me-- I attended BCIT, the British Columbia Institute of Technology, in the lower mainland of British Columbia in the late '70s, early '80s. And my first job out of school was designing race car chassis and heading the construction guidelines committee of the Specialty Vehicle Association of British Columbia, where we said what's legal and what's not legal to do for your vehicle that's driven on the street.

I joined a drafting firm in the mid '80s. And I primarily worked on arenas and convention centers, as well as some industrial projects for various steel fabricators, one of whom was a company called Coast Steel, which is also in the lower mainland. I started working for Coast Steel in the late 1980s, particularly on professional observatories like Keck , Gemini, Subaru-- the large observatories in Hawaii and Chile. And I was onsite in Hawaii to help supervise construction of the Keck II, Subaru, and Gemini observatories. So I have site experience as well. I've worked as all kinds of positions within the drawing office, and I was the drawing office manager for several years, and the engineering systems manager as well.

The company itself was formed as a blacksmith shop in 1910 in Vancouver. They did mostly structural projects through to the 1970s as Coast Steel. And a lot of people, especially in the observatory business, remember Coast Steel. In the early 1980s, they merged with a company called Brittain Steel and started building the professional observatories, telescopes, and quite a few bridges. We did a lot of bridges.

In the early 1980s-- early 1990s, sorry, while working on the Keck observatory, we made a connection with one of the engineers who worked for the Keck Foundation, who later left the Keck Foundation and went to go work for Disney. And this is important because in 1994, our very first amusement ride project, which was the GM test track at Walt Disney World, was a project that we had been the principal engineers, manufacturers, and installers on, thanks to that connection that we'd made with the engineer from Hawaii.

We continued to work on amusement rides from the mid-90s onward. We were acquired by AMEC and renamed AMEC Dynamic Structures-- so that's where we went from Coast Steel to Dynamic Structures-- and built lots of rides, but continued to do that industrial work, continued to build big industrial projects.

In the early 2000s, we had developed our own immersive ride systems and start to build those worldwide. We were acquired by the Empire Group as AMEC divested itself of anybody that actually built anything. They only wanted to work with consulting engineers. And we were renamed just Dynamic Structures, dropped the AMEC part of it.

In 2023, we went through a restructuring and were sold from the Empire Group, acquired by a private owner. We've got one owner now. And we moved from that project environment to the product environment. And we'll talk about that as we get through that.

So let's talk about this project-based environment and what it is and what sort of defines it. So part of the reason for living in that project-based environment is the nature of the projects themselves. Bridges, telescopes, large theme rides all lend themselves to individual project setups, as they're one-offs. They're unique. There's nothing that makes them the same as the next one. They all have unique requirements. So it's sort of natural that that's where we were. Everything we were doing was exactly like that, individual, one-off projects that are custom designed and built for the owner.

Now, that's not to say that we didn't build the same thing multiple times. Disney's Soarin's a perfect example of that. We designed and built and installed Soarin' for Disney in California, Florida, and Shanghai. They are all largely identical. The differences between them are so minor that most people would look at the drawings, they wouldn't see any difference other than the fact that each has its own set of drawings for each and every part on the project.

So the first thing that sort of stands out about this project-based environment is that you have all these unique sets of engineering calculations and drawings for the project at hand. And that includes things like individual drawings for each and every part. And sometimes, on some projects, you'll have the same part that is redone multiple times because it's used in different areas.

And all this stuff shows up in the title blocks on your drawings. The title block makes the drawing unique. Sometimes, that's the only thing that makes a drawing unique. There's little to no transfer of information between jobs.

So when we built Soarin' for Florida, it's different than Soarin' in California, and there's no information that that's really copied over. It's all recreated new. You might copy a drawing, but it goes through the checking process again. So all the sets of eyes look at it again.

And it doesn't end there. You have charge codes for the type and area of work, largely for accounting purposes. Our shop floor had all these charge codes that they had to charge their hourly time to on the time clock. And that was really just for accounting, because the work they were doing didn't change between area. They wanted to know how much did this area cost to build.

And then all the contact information and experts on the design assembly could be different between projects. So even though you're building the same thing again, or something that's very similar again, you may have a whole different group of engineers on it. You may have a whole different group of draftsmen and checkers on it. So while systems can be set up to capture the similarities, our experience has always shown that every project became truly customized and a unique instance of the project itself.

So I'd like to take a look at a couple of specific things that illustrate what makes it a project rather than a product. And just keep in mind that the differences between our design and manufacturing environment will likely differ from yours. But you should see enough similarities that it's relatable.

So from our project-based environment title block, the stuff that's unique-- you can see there's a customer listed. There's a project listed, the area that we're working in. Title is-- that's probably something that you're going to keep the same. But those other areas-- the project number, the code or sequence number-- those are all project specific. And because of the way that you're doing things, you might not have the same team. All your designer, who drew it, who checked it, who approved it, that may all change as well, and things like shop finish.

Other things that are on your drawing-- and you may or may not have these next assembly reference blocks on your drawing-- but where a part is used next is a project-based thing. And you're only showing the quantity and the assembly that that particular part is going to be used on for a particular project. In a product environment, you can't have that. Total quantity of parts is something that you show up on your bill of materials that tells you how many places a particular part is used.

Now, as we're going through that early 2000s and we're producing our own version of a flying theater, we started to go, there's got to be a better way to do that. And so that brings us to this path to the present, what we did along the way to get ready for this product-based environment.

And we could tell that something needed to change, because in the amusement ride market, it's very cutthroat. It's very competitive. You have a lot of different people making amusement rides in the world. And we want to improve upon our processes so that we could increase our productivity and our profit margin.

And a big part of that was in how we handled our data. We've been Vault users since it was first released as Productstream by Autodesk. We used many, many, many of its features and, in particular, things like the built-in auto-numbering systems.

We've developed all our groups and our states. We have engineers, we have production, we have the designers, we have project management, and everybody has their own appropriate permissions and who can do the transitions between one state and another.

So when we're a work in progress, who has permission to change it to ready for checker review. Who has permission to change it ready to engineer review? Who can roll it back from engineer review to work in progress? All of that stuff, we set all of that up within Vault. And those are built-in features in Vault that you can customize.

And we've also built and constantly improve our library of commercial off-the-shelf parts and fasteners. Vault comes with-- and Inventor come with large fastener libraries and hydraulic parts and electrical parts. There's huge libraries available for it.

But we wanted to make it work for us. So we store all our libraries in Vault, and we've organized them the way that we want and add to them as required as we come up with new parts that we need to buy.

So taking a look again at what everybody does and where could we make improvements-- this is part of what our process improvement committee did was to look at each department, and how can we improve on things. So standardized methodologies developed within the design group allowed us to ensure that all projects were done in the same manner. And remember, we're not at the product environment yet. We're still in projects. But by doing each project the same way, we started to see commonalities between projects and where we could start to see those cost savings.

And by standardizing our methodologies, it became easier for us to acquire certifications from TUV and CSEI, governing bodies that became confident in our processes because we always did it the same way. Those are groups that have to certify rides before we can make a ride available for the public.

In our data systems, by storing all our documentation in Vault, we could start to see where we copy information from one project to another. One set of calculations for seismics in California would be good for another project built in California for seismics. And we could start to see that kind of stuff, and we could also start to see where we could use assemblies with little to no modification.

And a good example of that is locking pins. We have a pneumatic-controlled locking pin that became standardized between different types of switches. And I'll show you some of those different types of switches in a bit.

But that locking pin, we started to be able to make the locking pin so that we could use the same assembly. We might have to change the mount a little bit. We might have to change the way the key that the lock fit into a little bit. But they were very, very similar, and so it didn't take long before we had a couple of different locking pin assemblies that are standard. And that's the way we use them.

With manufacturing, by giving them access to all the data that we had stored in Vault-- and, remember, we've got these groups set up so they only see the stuff that's released, and different departments, purchasing could see stuff before it was released but knew that they could only buy it when it's been through a certain level of review-- they could start to order materials with more accuracy. They could start to nest better. And projects, the shop floor could see where they could reuse jigs in some cases. And so they became standard fixtures that when we were building this type of a project, we could reuse this jig. And planning became easier for the shop because they knew what was coming their way.

So while we're putting all these systems in place, we're ensuring that we were documenting our processes, that when we came up with a methodology for doing something, we wrote it down, largely with a bit of wording and lots of pictures because we're a very visual species. So we'd create those documents. And then because we understood what we were doing, it allowed us to seek refinement within those processes and improve upon them.

It all led to easier audits for our design and manufacturing for organizations like ISO and AISC. The AISC and ISO would come to our place, and they weren't having to document-- the they weren't having to audit the details. They were auditing our process. Were we doing what we'd written down? And because it was written down, were training people on how we were doing it? And training became easier. We documented our process, and they were able to ensure that we were training everybody on what we said we were doing.

We developed flowcharts to visually inspect where data was being transferred for and ensure that we were doing appropriate checks and balances to those processes. And buy-in from all departments was required. So our process improvement team had members from every department, and buy-in had to be-- everybody had to agree on something before we would make a change, even if it wasn't within their department. And sometimes, we made mistakes. And these were looked at, we learned from them, and would make any changes that we needed to do after we'd made a mistake.

So this is the kind of thing-- this is one of those flowcharts where we go across the top, and it's got all the different departments within the company. And down the side, it's got all the different transitions that needed to take place. And you can see, we've marked it up. This is one of those cases where we made up a flowchart, what we thought we were doing, distribute it from everybody, and comments were made, and we improved upon the process.

So along the way, automation is a good thing. So we automated tasks, like filling in the title blocks. And we made it so that our AutoCAD and Inventor routines were modified. So they used the same Vault properties and also created common databases for AutoCAD and Inventor. And so a fastener has the same part number in both AutoCAD and Inventor for a reason.

And we do run that dual-product environment. While we work primarily in Inventor, you still need to have AutoCAD for things that you just don't want to be doing in Inventor. There are things that you do in Inventor that will slow it down horribly, whereas AutoCAD is really good at it. And vice versa-- there are things that are way easier in Inventor, so you use the right product for the right task. And, of course, because they're so interchangeable, it makes it a lot easier.

We created videos for all our customized iLogic routines. And this is, again, in Inventor because we primarily use Inventor. We've got a lot of iLogic routines and we created videos for how to use each one. And we created extensive help files and documentation for all the processes and routines that we created.

And we embedded those into the ribbons for AutoCAD and Inventor. So in our Inventor, when we fire it up, we've got a ribbon that's got a whole bunch of dynamic structures, routines that are built right into it. You click on the routine, and it runs through the iLogic and does what it's supposed to do.

Our Vault COTS libraries included highlighted cut sheets so that when purchasing went to go and buy a part that we've specified, there's no mistaking it. They're going to get the right one because we've got the cut sheet attached to the part, and it's highlighted, and they know this is exactly what we're specifying.

And for all those project-based data, we kept a legacy Vault and set up a separate one for product. And information is not shared across those vaults in order to prevent cross-contamination by bad data.

And you might think, well, why are we having to worry about project-based stuff if we're moving to a product-based environment? Well, we've got to have warranty on our projects, and we have to keep those-- a warranty on a professional observatory is 50 years. So we have to keep the data and be able to go in and troubleshoot something 50 years later on a project.

I just did something recently on a project that was 20 years old. We had to come up with the drawings for them to replace a part that had worn out over time. They're responsible for the part, but we still had to provide the information and make sure that they got the right stuff to repair it.

There's a screenshot that shows some of our iLogic routines that are built into our Inventor. And you can see we have some general tasks, structural tasks, tasks specific for building coaster track, tasks specifically for drawings. And in front of many of these iLogic routines that run when you click the button, you can see a V and then followed by a bunch of digits. And those are links to the videos.

So when you click this button, you get the option to view the video. You can take a look at a video and run through quickly how to do something or other with that particular task. Or, if you've already watched the video, you can just click and run the iLogic routine itself.

So we've done this for many-- and the videos are short. They're only a couple of minutes long. And we find it's a really good way, especially when you're onboarding new people, they can just run through the videos, they can learn all these customized routines that we've got-- a great way to ensure that everybody does it the same way and a great way to improve productivity.

So let's go into this product-based environment and see what it really-- the way we've got it set up now. So we've been able to break down what we build as a product. And remember, we do still do projects, but most of what we do is products.

And we're able to break it down into four groups. And I know there's only three on this particular slide. I'll show the fourth one separately because it's got just as many options as these three put together.

So we've broken it down to flying theaters, track rides, and vehicles. And under the flying theaters, they have their own sub-products, what we call a hammer style and what we call a platform style.

And the hammer style comes in a couple of sizes. They're designed for smaller locations where there's not a whole lot of space, 20 people or 24 people on the ride at a time.

Platform style comes in two different styles. There's the motion theater style, which is for 120 people-- it's largely circular rotation with tilt and rotation-- and the flying theater, which comes in four sizes-- 39 people, 72 people, 78 people, and 84 people. And the pictures you saw earlier are from the flying theaters. The previous slide to this one was for the motion theater.

Track rides, we've got two basic styles. There's one that has a center drive plate and then there's conventional coaster track. The center drive plate, we can either mount it on a pedestal, or we can mount it right on the floor, depending on the ride vehicle and what we're trying to do there.

The conventional coaster track has no drive plate. But we've got a whole bunch of different ways we can drive it. Conventional roller coasters use a chain to lift you up a hill, and then you gravity the rest of the way. They can be linear induction, motor driven, where you use a series of magnets to launch a vehicle. Or they can be motorized where the vehicle has a motor on it itself. And each of those affects the way the track is designed.

And then the backbone for a conventional coaster track can either be round or rectangular. And we've got standardized ways for doing those.

For ride vehicles themselves, it depends on the track style, obviously. We can have programmed robots that are going along a fin-type track and powered vehicles that move along a fin-type track. Or we can have a conventional roller coaster vehicle where it's just falling down a coaster track after it's been lifted up to the top of a hill. Or you can have motorized vehicles that are driving around a coaster track. And we've done some of those.

And then you can have any combination of the above. So you can mix and match whatever suits the client.

So here's some images from those different types. The very top left one is a conventional coaster track with a backbone. The one that's below it is a coaster track with a rectangular backbone instead of a pipe. And you can see that they're indexed differently.

So to get the tilt around one, we're just indexing where the bolt holes go in the plates. The other one, we change the lengths of the tubes between the backbone and the support tubes. On the one that's on the right-hand side is one of those motorized vehicles that's going around a fin-type track mounted on a pedestal. And we've mounted a robot on top of the vehicle so that you can ride a very popular Universal ride.

For the product-based environment switches, they come in many different shapes and sizes that, again, depending on the track design, will depend on how the interface goes. But we have rotary switches, which just simply rotate you around on a flat plane. We have a sideways shuttle, which will move you horizontally or maybe move you down a hill. We've fabricated some of those.

We've got a drop switch, which will drop you straight down. And then we've got a tilt switch, which is sort of like a teeter-totter. You go out on it, and then it tilts. And you either go forward or backward, depending on the direction that you're supposed to go.

They can be used with any track designs, so we can mount them on any type. And they can be used to transfer between tracks to change directions, control your position in a queue, or shuttle a vehicle off to maintenance, all kinds of uses for these switches. And it's one of the main parts of what we do.

So, again, here's an image of three of those things. And remember, these are each their own product line. So we have a rotary switch at the top with a square tube track for a motorized vehicle.

The one that's on the lower left is our high-speed switch, which is for the fin-type track. And that's where the vehicle needs to go across where the fin would cross its path. So the fin has to get out of the way. It rotates out of the way. Timing is critical on this particular switch, but it's called the high-speed switch for a reason.

And on the right-hand side, you can see our tilt switch, which you go out, the vehicle goes out along the bar that's across the top of it. It rotates down. And in this particular case, the vehicle goes backwards out of the switch. And, of course, the staff that had hands in putting that together-- you can see they can be quite large.

So we've moved into this product-based environment. And we've seen a lot of assemblies that we can use across multiple product lines. So seat belts are common between flying theaters, motion theaters, and vehicles. We've made a library of stiffeners, end plates, pipe flanges, gussets. And we've used those across all products. And I'll show you in a bit how we access those things.

Model and drawing templates carry no project-specific information. So once we've released a drawing, we don't have to touch that drawing again ever unless it's going to be changed. And if it needs to be changed, we've established an engineering change order process that's ready to go for when we do that. So if we make a change to a part, as long as that part can be reused in all locations where it's already used, then we go ahead and make that modification. If we need to change a part and it needs to be a different part, then we create a new part for it.

The ability to have interface drawings in the same Vault using only the customized installation requirements for a specific project. We have that ability. We haven't had to use it yet, but when we do, it's ready to go.

So let's take a look at this title block for the product-based environment. You can see we've stripped out all the project-specific information. We've added tolerance blocks so that when we're doing a fabrication drawing or whether we're doing an intermediate tolerance block for an assembly drawing or we're doing a machining tolerance block, they're all there. We just change them out as we're required.

So there's no need to have multiple borders for multiple processes. And we have space for our engineer seals because in some places like China, the drawing has to be sealed before it can be fabricated.

Our BOMs are also changed. We have space for the ECO numbers. A total quantity is not shown. This is an assembly BOM, so it only shows the quantity needed to make one assembly. And I'm showing you the structural assembly BOM here.

There are differences between them all. And again, they're all built into one template. So all you do is right-click on it and say, I want a mechanical assembly BOM, and you get this one-- again, ECO number, no total quantity, different information shown. And again, we're one border. It's just all of this stuff is just built in on what you choose to show.

For a part level, it's only going to show quantity for one part. So there's no need to have quantities on here at all. And the amount of information that's shown is quite a bit reduced.

So let's quickly go over a few tips and tricks. And again, I refer you to the handout, where you're going to see those things. We set up standard families for fasteners. And new fasteners are added to the appropriate one.

We created the iLogic routines for things like changing borders, insert constraints, locking rotation, many, many others. We created routines so that part types have pull-down menus to ensure their properties are filled in.

And a big one was we created a form for commercial off-the-shelf parts so that if you want a new one, the information that we are gathering is standardized-- makes it easier for the librarian. We created pull-downs for those standard parts, like I said, and documentation that shows how drawings should look. So we've got a best practices for creating a drawing, a best practices to ensure that those presentations are the same when you have multiple creators creating information, and, again, as I mentioned, those videos that show step by step.

We only draw what needs to be drawn. So we don't draw parts. If something can be manufactured from the DXF file, we do not create a drawing for it. And sometimes, we don't draw the machine parts, depending on our subcontractor. We've got subcontractors that can work directly from Inventor or Fusion.

So here's the results of some of those things that I mentioned on the previous slide. We've got instructions that have a screenshot that say, on large assemblies, always show two isometric views that are 180 degrees from each other, label the stuff that you can see, make sure you got tension edges turned on and that you're not labeling them.

Below that, we've got one of our pull-downs for choosing a stiffener plate. And all the different beam types are listed there, and not just North American grades. We listed Chinese grades because we fabricate in China. And as you pull each one of those down, the next column over will have the right selection.

And our iFeatures all come from Vault. And we've got all of those things there, plus all the built-in routines for beam copes and HSS copes and pipes and all of that. We've got routines created for all of those.

Here's our flowchart that shows you the drawing and approval process, where it takes you through step by step what's going to happen. When this person does this, what happens next, and where does it go, and when is a PDF created, and what's the PDF lifecycle? It's all on one spreadsheet. This is our entire design and drawing approval process on one screenshot of what we do, right down to when we put the engineer seals on and how we do that.

Keep your Vault organized. That's the biggest thing. So we keep our Vault organized. You can see on the right-hand side here, we've got flying theaters, and they're different types. We keep the service bulletins for the flying theaters under flying theaters. We keep the service bulletins for track under track. We keep the service bulletins for switches under switches, and all of that thing.

We keep our spreadsheets for what needs to be done and what our hourly estimates are, we also keep those in Vault, as we keep our CAD setup in Vault, and we run a program called Vault Mirror that we created that will copy the relevant data from Vault to your computer every day so that if we've done an update to the border template overnight, you get the right one when you fire up your computer the next day.

So we'll take some questions and go from there. For those that are viewing this online, then you can just make some comments on the page for the session. And I keep an eye on that, so I'll answer anything online when we go that way.