In Pursuit of the BIM Lifecycle Dream—Revit to BIM 360 Glue to BIM 360 Field to Building Ops

BRETT NAYLOR: All right, then, can everyone hear me OK at the back? Good afternoon, and firstly, thanks every so much for choosing to come and see this session, especially when there's so much on offer out there. And no doubt, you [INAUDIBLE] like me, you've got about three things all that you want to see at the same time, so I really appreciate you coming along to see this.

The presentation that we're going to be looking at is actually based on a real-life project. It's the first of three that we've started to deliver, and it's going to be handed over in December, all being well. We're effectively looking at the movement of data through four different applications. So that's Revit, Glue Field, into Building Ops, with the intention of having a really good data and asset handover for asset management and operational purposes.

We're going to be undertaking, just for the first few slides, just a quick poll. Well, actually, sorry, it's in a couple of slides-- a poll just to understand who's actually in the room. It will be really interesting to see which industries you're from, what your interests are about attending this session as well.

But just as a bit of a first overview on Beca-- so I'm a technical director with Beca. I'm responsible for the-- I suppose, the technical implementation of building information modeling within our business. And that involves implementing the latest technologies, making sure the processes are all in place for people to use the technology effectively, and also working with our clients, as well, to help them understand what building information modeling is and what benefits that they can get out of that process through design, through construction, and into asset management as well, and operations.

In terms of who we are, we're based in New Zealand. We've got about 3,500 staff now. The headquarters are out of Auckland, and we've got about 2,200 staff in New Zealand themselves, and you can see about 500 in Australia. And there's probably about 500-ish over the rest of Asia Pacific. We're one of Asia Pacific's largest employee-owned engineering consultancies.

So I'd really like just to get a bit of input from you, to start off with, please. So I'm sure you've seen some of these presentations before, using PollEv. So you can either text the number at the top there, or if you've got a mobile or an iPad, which you've got internet connection, if you just type in PollEv.com/brettnaylor451. Apologies about the long web address there-- I didn't quite know how to actually change that, but hopefully it won't take you too long to dial that one in. So it will be really interesting to find out whereabouts you're all based-- wow, OK.

Still going-- so a really strong contingency from North America; a few of my colleagues, down in the front, from New Zealand; and a couple of others, OK-- that's great stuff. Thanks for contributing to that. Next one-- what's your role in industry? Are you an asset owner? Are you an FM provider? Are you in design and engineering consultancy, subbie, contractor? Or are you a software provider?

And I suppose the final one is, what kind of experience have you actually had on the technologies that we're going to be talking about today? So have you used the likes of BIM 360 Field for just the construction management side of the application? Have you used it for construction management and information delivery for asset management? Have you used it for pushing into Building Ops, or have you just purely been using Revit and pushing that into Building Ops as well?

OK, that's pretty interesting to see, actually, that most people who have been using Field have been purely for the construction management side of it. So obviously, today's presentation is really focused around how we've been moving data from Revit into Glue, just as a process, then through into BIM 360 Field, capturing the data from the models that are already there, that's useful, and then also adding extra data in that's not necessarily input in the model environment, but that's put in outside of the model environment, but you want to be linked back in. So OK-- hey, thanks, everyone, for your input into that.

OK, so a bit about the client that we've been working for in delivering these projects-- they're a company called Precinct Properties, based in New Zealand, headquartered in Auckland as well. They've got about 12 buildings in their portfolio at the moment, and approximate value is about $1 and 1/2 billion, although that's increasing rapidly, because they've got quite an aggressive build plan. And they've got about 17,000 people employed in the buildings that they own across New Zealand as well.

The project we're actually going to be talking about today is this one in the bottom left-hand corner here. This is called the Mason Brothers project. It's on Wynyard Quarter in Auckland, down on the waterfront. And we've got a second project that's just starting up in January. The code name for that is 5A.

And then we've got a project on the right-hand side, which we're talking to them about-- that nice, new, shiny glass tower block called Downtown or Commercial Bay, and that's worth about $400 million. So they're a pretty comprehensive asset owner. The project, in terms of giving you a bit of relationship of where the project is on the site, the darker-colored orange building there is Mason Brothers, and you can see the other developments that are all scattered around that particular area.

And just to show you an older version of an area pano-- I hope that doesn't make you feel too sick. But this is the waterfront, the Wynyard Quarter down in Auckland. And this is the building that we're talking about. So it's actually an existing building that was stripped, gutted back, and then completely refurbished from top to bottom, and with a bit of an extension to that as well.

OK, the role of what we were doing on the job-- because Beca are an engineering consultancy, so you're probably wondering, well, why are you implementing Glue and Field through the construction phase and actually doing the asset information handover? Well, the client was obviously really interested in actually getting a decent handover for their operational activities, but they weren't too sure how to do that. So they actually engaged with us to walk them through that process, help them understand what they could get, and then the best ways to do that.

So we define this role on the project as being an information manager, effectively. So we started with them. We looked at what information was critical for them, for operations, and maintenance, and asset management. And then once we'd done that, we then chose-- the best products to use to actually deliver this information through the project lifecycle was going to be BIM 360 Glue and BIM 360 Field.

Then as part of that, once we'd implemented and set the technologies up for asset information capture, we actually trained the subcontractors and the contractors in the supply chain on how they were going to be inputting that data into BIM 360 Field as part of that progress, as part of the project progression. And then when we were going through the project, what we didn't want to do is just get to the end and hope that we had all the information within the models and within the field environment that we needed for handover. We needed a way that we could actually start to report on the data completeness that was, A, going to be generated within the model environment, and, B, also generated outside of the model environment.

That was critical for us at management, and I'll show you some of the ways that we've actually achieved doing that as well. The whole purpose of this was to give them a good handover. The client had reviewed several different applications around the marketplace. But they were either too complicated, they were too expensive-- nothing really worked for them.

So when we initially started these conversations off, Building Ops wasn't around, OK? It hadn't even been released yet. So we were intending to give them, effectively, a neutral information drop that they could then use in whichever way that they wanted to when they decided on the application they wanted for operations and maintenance.

Then Building Ops came on the scene. The client, being quite proactive, actually found out about this. We went down to see them, ran through a proof of concept with how this could potentially work for them, and that was chosen as the methodology that we were going to be delivering into. And so this presentation is going to walk through the whole process that we've actually gone through to get the information from, actually, the models, through into Building Ops for a handover.

In terms of the process then, luckily, in New Zealand the primary products that we use are Revit, across most of the industries, most of the services. In the construction stage, the structural model was Tekla. But that wasn't really an issue. We just used an IFC model that came through into Revit, converted that, and then we were able to federate all the data within one Revit model, effectively.

And then we pushed the file straight through into BIM 360 Glue, which, if any of you are familiar with that, it's a cloud-based application, which is really useful for coordination and collaboration between dispersed project teams, OK? So once the information was in there, we effectively pushed the data through into field. Just before we did that, though, within BIM 360 Glue, we were able to start to specify all the assets that were in the model that we actually wanted to know about for handover, based on the client's requirements.

So we set up a whole load of these called equipment sets, OK? So you basically-- it's like a search set whereby you say, find me all of the fan coil units, or find me all of the chillers, or find me all of the distribution boards. Then once we've done that, we then push the information through into BIM 360 Field, which is, again, another cloud-based application.

And in there, you then start going through this process of pulling out information that's already in the model because, as you know, you don't want to recreate information if you've already got it available to you. There's just no point. And that's where we actually set up the rest of the templates, within the field, for people to capture the extra data against it that we want it to capture.

And obviously, once we've done that, even though it's a cloud-based application, we can still pull those models and all the data down onto an iPad that we can take out onto site. So we get the latest information to site. And we can also access all of the asset information, that you've been mapping in the previous steps, through a web browser. So you've got flexibility in terms of how you get the information and how you also populate that data back into the model environment as well.

I'm just going to go into a little bit more detail now, through the presentation, on what we actually did to achieve that. As we weren't effectively working on the project, in terms of delivering models, as this information manager role, we would receive all the discipline models through weekly or every other week, depending on the progress of the project. So we had individual discipline models.

And then what we did is, we set up a federated Revit model. So this was, effectively, a container file where we brought all the different discipline models into the one area. And this was the easiest way for us to contain and control new revisions of the models that were coming through in this particular stage here.

And it's within here that we set up, actually, most of the setup for moving the information through into Glue, into Field, and then into Building Ops. And the process that I'm going to be talking to you about during this presentation is just one of the ways that you could do this, but it was probably the most effective way. We actually looked at all sorts of different workflows, at different stages of the project, to see if we could do things differently. But we actually settled on this as being the most effective.

So once we'd done that within Revit, we then created a whole load of 3D views, effectively, of all the discipline models. So we started to split those all out. And then within there, we also started to split out the individual floor levels as well. And the purpose for doing that is probably twofold.

The first one was actually-- when you're taking quite large models down onto site on an iPad, you don't wan to have a whole building model on there, because the iPad will struggle, and it will crash. So that's going to stop your progress straight away. So we split the models down, so they're more easily handled by mobile technology.

Then once we've done that, we push those models from BIM 360 Glue, from the model area into the merged model area. So effectively, we take the architectural level at ground floor, the structural model at ground floor, the building services models, all at ground floor, and federate them all in together, into one file. And then once we've done that, we can push that through into BIM 360 Field, where we start doing a lot of that advanced asset and equipment mapping, getting it ready for handover. Once we've done that, you can then make it available for the iPad and, obviously, through the web interface as well.

Naming conventions-- we had a quite a strict naming convention for the models that we're getting as well. When we came onto the project, there was no convention at all. But as soon as we came onto the job, we actually put in place a naming convention for the models. And that model naming convention also fed through into the naming convention for the views that you can see here.

So we effectively set up an individual view within Revit, which was specifically for structure, architectural, mechanical, plumbing, electrical, and fire, ground floor, first floor, and second floor. And so we had a consistency of naming conventions, whether it was a model or a view. Now, the reason why we did this is, you'll see a bit later on, it's how this data and this information is displayed within the likes of BIM 360 Glue.

As part of that setup, we actually created a whole load of view templates. And this was the easiest and most stable way for us to start controlling the look and feel of that information as well. So we had a whole load of individual view templates for the 3D views, effectively. As you can see, that's highlighted in that red rectangle.

And in there, we effectively-- the only thing we did was to control the visibility of the models that were displayed. So in this example here, I've got a Level 00MH mechanical drawing-- mechanical model, and it's only showing the mechanical model. So we hid everything. So we had a view which just had the information that we wanted about mechanical information.

And again, we also set up a whole load of floor-plan views. And again, I mentioned earlier on, we wanted to section our building into floor plans, effectively, for the use in Field. And actually, also, we needed to consider, further down the line from that, what we were going to do in Building Ops and how that information was going to display.

So we had three floor-plan views, effectively, at each level-- one for architecture, one for services, and one for structures. We'll come onto why we did that. So in those view templates for each of those levels, for each of those disciplines-- say, architecture, services, and structures-- the view template, we only really use that to control the view range. So as you can see here, unlike the previous view template for the 3Ds, everything's selected there because it didn't affect it.

But what we were concerned about is the actual view range themselves. So it was in here that we set up a whole load of different parameters for our view range, depending on what level the particular 3D view was requiring to be at. And as you can see on the right-hand side, those are just some screen shots from the particular view templates, depending on if they were at ground floor, or first floor, or second floor.

And this is here. This is structures, so the previous one was architecture. The structural one is slightly different. The reason why they're all slightly different is we found that we had issues later on down in the project lifecycle of creating all this information and mapping all this information. We wanted to see in BIM 360 Field, when we took the iPad down onto site, we wanted to see the floor slab of the floor you're on. And we also wanted to see the floor slab of the level above as well. That's definitely what you want to see.

But when you push that information through into Building Ops, the last thing you want to see is just the floor slab above where the piece of equipment is that you're actually looking for. And then if you actually look from underneath, there's a ceiling there, so you actually can't see the asset. We'll come on to that a little bit later on.

An interesting one was actually the one that we set up for the services, because later on in Field, when we were pulling asset information from the model about all the services information, there were some assets that were sat on a floor level. So it could have been ground floor or first floor. And if we'd have cut the view templates at exactly the floor level above and the floor level below, it was double counting the equipment information, because it was cutting through the very bottom. So we actually went through, probably, about a day of understanding why we were getting duplication of information and things weren't mapping properly.

So that was a bit of a hard-learned lesson, but we got there in the end. So we've all got these slightly different cuts. But the good thing is, is when you bring all these models together on top of each other at different levels, they all join up.

So as an example, there we've got a mechanical duct-work model, and that's, effectively, a view. And you can see the top right-hand corner is just a screen shot of the whole model itself. That's showing everything at ground, first, and second floor. If we move down and look at the image below, we can see that's literally just showing that mechanical duct-work information at the first floor.

So in that view, what we did, we aligned the 3D view to the floor plan, which we created underneath this services template. So what that did was, effectively, used the view range from the floor plan for first floor. So that's why we were using the view range within the floor plan. And the reason why we're doing that is because that then we've got consistent cut information across all the levels, across all the disciplines, because we could have done the section cutting by eye. But you can guarantee you'd have had quite a lot of overlaps, or you could have even had disjoint between the different floor levels as well.

We actually went through several different iterations before we actually settled on the cut view ranges that we actually did, and that was just through trial and error. So when we get into BIM 360 Glue, we've got all these views here. So you can see on the left hand side, we've got the ground floor, starting at the bottom here.

We've got the mechanical. We've got plumbing, structural, fire, electrical, and architecture-- all separate views, so they're all individually controllable. You don't want to merge everything together, so you've got no control.

And then what we were able to do in Glue, once we push those models through, is we can create one merge model for the ground floor. And we did that across all the levels. So the large image on the center right-hand side of the screen is showing, in Glue, if we're sat in the ground floor model, you can see we've got individual ability to control, turn off, interrogate the different discipline models, as and how we wish to.

An then, as I mentioned, we did that, effectively, three times. So we, effectively, had three federated or merged models for each of those individual levels as well. Once we'd got into there, in that stage, we were happy that we could start pushing this through into BIM 360 Field. And that's when-- BIM 360 Field, we wanted to start mapping over that equipment and pulling through the asset information that was vital for asset management.

And just as a note, we actually didn't use BIM 360 Field for the construction management side of the application, which is incredibly powerful to do, and it's incredibly good at. We thought it was just one step too far for the contractors and supply chain to undertake. So what we looked at was actually maximizing the value that the client was going to be getting out at the end, and that was actually getting a good handover of information.

So jumping back, sorry, into Glue, to start setting up the equipment's mapping to say, we want these assets, and we want to pull them into BIM 360 Field, we were creating these things called equipment sets. So we looked at the different properties that you could select and use to create these equipment sets. You could use the family type, the family name, maybe.

There's a whole load of different parameters, and the one we settled on was actually the OmniClass title. We could have used OmniClass number, but we used title because the information comes through nicely into BIM 360 Field a bit later on. And we also, when we were naming the equipment sets, we decided to just to prefix the name of the equipment sets with the level that they're associated to. And that was just as a bit of an audit type of trail because when you get through into BIM 360 Field, and you're looking at all the equipment that's coming through, you can quickly verify to make sure that you've got the right data coming through, from the right levels, to the right places.

As a note, and this was a real-- it was a horrible thing we discovered one 4:30 on a Friday afternoon, is the modelers, actually, that were creating these models had been using the old OmniClass taxonomy. And we actually asked them to go into a bit more detail, in terms of the granularity, with the naming of the assets. And as you-- I think I heard a few mumbles there in the crowd. We had to actually get them to install the new taxonomy, which then threw out all of our equipment mapping we had created.

So we spent that whole weekend mapping over the new OmniClass names, based on what we'd already done. So just as a-- if you're going to do this, make sure you're using the latest OmniClass taxonomy within your Revit environment as well. That's a hard learn to experience, that one.

So once we'd created those equipment sets within Glue, this is, effectively, the display under the Equipment tab within the web browser. And it's within here that you then start to map information across from the models, and you can actually start adding an additional properties to those assets that you want to capture data against. So you can see here some of the familiar names.

We've got 00-Fire Dampers. So that's all the fire dampers at ground floor, effectively. Part of the other setup that you need to do within BIM 360 Field, if you're looking at the equipment side, is setting up your categories and your types. So top right-hand side of the slide is effectively showing the category of the mechanical equipment. And underneath there, we have several different types, and I'm selecting Fan Coil Unit.

And I'm going to walk through the life of a fan coil unit. And if you've ever seen me present before, you know I always talk about this because it's a good example. So if you follow that green arrow over to the top left there, we can see, when we've selected those equipment sets that's coming through from Glue, we assign them to the type and category of fan coil unit.

Then we move down, and when we start to say, we want to create a dynamic link between the model and field, there's lots of different options. And I would have liked to have been able to choose the asset ID, unique asset ID. But at that stage of the project, we didn't have unique asset IDs for all the equipment we wanted.

So we chose to use the advanced option and choose the GUI. So there's always going to be that link between the model options then, which was cool. So that's the way that we did it.

And that's important because, obviously, if you update your models, you want the GUIs to stay the same. And if you put in extra information within field, you want-- that GUI link is what enables the information to come back from BIM 360 Field into Glue, and then back into the Revit environment as well. This is a slide which is, effectively, showing the column on the left-hand side is the Revit parameter. So if you use Revit, you'll probably be pretty familiar with some of those.

And then the column on the right-hand side is the field parameters. So as I said, there's no point in creating information if it's already there for you to utilize. You might as well utilize it. So it's at this stage here that we start to map information across.

So if you've selected an item in the model environment, if you looked at the layer information, that actually was the level. So we said, well, use the layer information from the model, and display that as the level information within BIM 360 Field, because the object should know, effectively, where they are. And the item type should be the description. We'll come onto that a bit later on, item type.

Again, you've always got to have the mindset of where this information is going and how it's going to be displayed down the line. And I'm referring to how this comes across in Building Ops later on. So this is an example of how we mapped everything across. And again, you can see here in Revit, we've got OmniClass title, and we actually named them Classification Name. We could have been using a different classification system, other than OmniClass, so that's why we named the field parameter as classification in that instance.

So the equipment mapping, once you've gone through field, you can then pull all the information through that you've specified from the Revit model. And you can also add in, as I mentioned, some additional parameters in there which you want to know about, but isn't applicable to be added in in the model environment. So it could be information on barcoding. It could be installer, warranty start date, supplier, all that kind of stuff. So this is where we added in additional information that we wanted to capture.

And then, back in BIM 360 Glue-- and if we've got time at the end, I'll fire up some of these applications-- you get this additional Equipment tab coming on the Properties panel, that you're able to interrogate the property information that's coming back through that's captured in the field, using BIM 360 Field, into the model environment as well. So you can start to see here, this is the data that's effectively mapping back from BIM 360 Glue-- back, sorry, from BIM 360 Field into BIM 360 Glue.

So I was talking about how you've got to be mindful of how the information maps across. In this slide, underneath the Asset Identify column, we had unique asset IDs for our fan coils. So that's Fan Coil Unit-L0, level 0, and Fan Coil Unit number 1. This image here, you see in the foreground, is, effectively, a screen shot of Building Ops. So you need to think about how that information's going to display and map across to the Building Ops environment, both in the web browser and on the mobile phone as well.

So you can see the asset identifier that's being pulled through from the Revit environment into Glue, into Field, is then pushed to that larger piece of text that you see in the asset list on the screenshot from a mobile phone. And the description is an interesting one, actually, because that actually changed. I think the mapping of that changed about three or four months ago. But luckily, it was stable for this exercise.

So you can see the description that's coming through effectively from the Revit model there, which is a combination of the Revit family and Revit type. And also, I think, the category, if I remember, from field is displayed just underneath the unique asset ID within Building Ops. This is a display.

If you would have clicked on Fan Coil Unit 1 and then gone into that next display screen on Building Ops-- and again, I'll try and show you this later on-- then this is the displays that you get. So you've got to think about how that information is going to flow through and it's going to look, because you don't want a whole load of jumbled information on your asset list. Otherwise, it's going to be no use to anyone.

Then what we've effectively got here is just showing where that information is coming from. So underneath, on the right-hand side, where you've got the description, it's pulling the Revit name, the Revit family name, into those red boxed areas. The purple-ish bluey color is information that's coming in from the category, back and Field, that we mapped. And the green box is, effectively, the model number for that particular fan coil unit, which is what we named the Revit type.

So we have to be really mindful about, actually, how we named our families and our types as well, back in the Revit environment. There's quite a few things that you need to consider. And again, Building Ops is available based on the mobile phone and through the web browser as well. And you can see, the top is the display of the Fan Coil Unit 1 on the mobile, and top right, larger images, how it displays in the web browser too.

AUDIENCE: Was the strategy for all that naming convention something that was decided very early on and given to the design team?

BRETT NAYLOR: No, and I wish it had have been because we were-- unfortunately, we weren't brought on board until they'd already started building, all right? So this was-- luckily, we were working with a team based in Auckland who specialize in construction modeling, a company called asBuilt. And we were able to really work with them and talk them through the process that we were going through. And they were able to name the assets that we were needing to know about in this way that worked well with our workflow to get the handover. But it would be great if we got all this stuff sorted out from day one.

I have to say that the design consultants models-- you know that BIM nirvana of the design models, just hand it over to construction, and they continue with them? No, they got handed over, and then they got binned. And there was a good reason for that, but anyway, let's not muddy the water.

Just as an aside, we were going through this process one weekend, and we were starting to map all this data through. So we were like, well, we just need to make sure that we're getting all that information out of our models, through into Glue, and through into Field. So myself and a colleague of mine, we locked ourselves in what we called the war room, and we plugged our laptops into a TV, and we used Excel Online-- so effectively, Excel Office 365.

And we listed out, all on the left-hand side here, all the types of assets that we wanted to know about. By the way, this isn't an eyesight test. You're not expected to be able to read any of this. And then what we were able to do is, through Revit, we knew exactly how many assets we had in that environment. So we knew exactly how many assets we needed to be able to map through into Glue, so we were able to check that to make sure that was working.

And then we also knew how many assets that should be ending up in Field. So we were actually able to use this as an interactive way to verify the information flowing through those different applications. Oh, what's that? Just close that down. Thanks, Phil. I've got the man in the room that can sort this stuff, though, thankfully.

And we were able to use this as a process-- really interactive. So we were both working in the same document at the same time, checking the data, making sure, verifying that it was correct. OK, so some of the issues that you do have with these products, unfortunately, you would expect that equipment that knows which space it's in, in Revit, for that information to flow through into Glue. It doesn't.

So to get around that, we looked at a couple of different options. The first one was using BIMLink to pull the space name and space number of the object out of, I suppose, the in-built Revit parameters, and into two shared parameters which we set up for space name and space number, OK? And because they were shared parameters, custom shared parameters that we had set up, that information then flowed through Glue and into Field.

For them, there was a better way. So we actually were able to use Dynamo, far more automated. So every single time we got a revision of models coming through, we could run it through the Dynamo script. The Dynamo script would look at the models, suck out the information from the default Revit space name, space number, push that information into our custom parameter, job done. So it was just a more efficient way, even, than the BIM link, which is obviously a great application, for those who use it, as well.

Right, so what about the data flowing back the other way? So how did that work? We didn't just go--

AUDIENCE: [LAUGHTER]

BRETT NAYLOR: Oh yeah, you kind of expect it to work like that. It didn't, but that was all right. Actually, it worked pretty much easier than that, to be fair. So we were expecting that you could drop a whole load of models out of BIM 360 Field. But what we want to do-- and as I say, we're handing this project over in December-- is we want all that really good data we're capturing through construction to go back into the Revit models because if there's ever work done in the future, then the designers have got the information that they need.

But we also want some Navisworks files, and that's easy. So to get the information back into the Revit environment, we didn't go through Glue, from Field, go into Glue, back into the federated environment, back into the federated model. Quite simply, you just open up the last issued, as-built, single-discipline models. And in Revit, you can just import that equipment straight back in, easy.

And in Navisworks, you can just pull the data back down if you want a federated model. But once you've got to this point, to be fair, you just create an NWC file, NWD files, and have a federated model. And away you go, easy.

OK, so just some of the lessons learned along the way-- as I mentioned earlier on, you don't necessarily want-- you want the floor slab of the level above and, obviously, the level you're on in the scene. But when you push this stuff through into Building Ops, actually having the floor slab of the level above-- and I'll show you-- in the way is actually kind of counterproductive, because you can't see what you're actually needing to see. So you sometimes want that in Field, but you don't necessarily want it in Building Ops.

So before we did this final-- or we will do, and we've already tested it-- well, before we do this final push of the last model information from Revit, through to Glue, through to Field, and into Building Ops, we're actually going to do a little bit of tweaking of some of the models within Revit. So we're going to actually make some of the ceilings transparent because, again, there's no point in being in Building Ops and looking up at a ceiling when you're trying to see a piece of equipment. We're also going to-- we actually, originally, had some specific view templates set up, specifically for the export to Building Ops from Revit. But it was a bit heavy handed, to be fair.

So we're going to prep some of the models a little bit before we do the final push to get them through into Building Ops for handover. So I've mentioned ceiling transparency. There is a bit of a difference between the web and the iPhone. We'll come onto that.

Materials appear on the web. The graphic-- I think it must be the large-model view of the graphic, the 3D model that you get within the large-model view is brilliant, to be fair. The quality is superb, and it maintains the materials. But on the Building Ops, because it's a different model engine, it brings through the default colors. But I don't really think it's too much of an issue.

If you try and hide objects in Glue to think, well, if I hide the floor slabs in Glue, and push it through to field, and then into Building Ops, that'll be good-- doesn't work. So that's why we have to do it back in Revit. Transparency overrides is the same.

So if you make change of color in Glue, it doesn't retain going through Field and into Building Ops as well, hence why we did the final manipulation in Revit. And section overrides as well-- yeah, they don't work, unfortunately, hence going back into the Revit environment for that final push through. These are all hard lessons learned, with quite a lot of scratching of heads.

AUDIENCE: Should you submit those to Autodesk, or that's not an issue?

BRETT NAYLOR: Yeah, we've actually-- to be fair, Autodesk has been awesome. So we've been working with their development team on Building Ops, met them earlier today. And we're in really close connection with them, and we're helping them work through some of these issues.

And in fact, some of the issues with the model transparency and the differences that you get, talking to some of their developers today, they're like, oh, we reckon we can sort that, which is awesome. So no, they've been really responsive. I mean, what a product. It wasn't even around a year ago.

What is it, $150 per user, per month, compared to some of those big enterprise solutions? It gets you thinking, doesn't it? OK, so this is a view, effectively, from a mobile phone, looking at me old fan coil unit that you can just about see, in blue there.

At this stage, I haven't made the ceiling transparent, admittedly. But you can see, this is the large model viewer on the right-hand side, showing the kind of graphic quality that you can get in there. I'll come on and display those live, if I can do, if the technology works, in a minute.

But I mentioned earlier on, we're acting as this information manager role, and we wanted this digital handover of asset information to the client. So what we didn't want to happen was the contract to be-- yep, it's all there, subbie's saying, yep, it's all there-- get to handover, information's not there. I'm sure if you're a project manager or an owner, operator, of facilities, then you've possibly been in a similar situation to that.

So what we're able to do is we're able to start to utilize the data that we've been collecting and reporting on it. So the first step of that was actually exporting up in 360 Field, the assets and the asset information that we wanted to know about, into Excel, which was all right. You could do pivot tables and things like that.

And the next step on, I had a chat with my colleague Phil down at the front here, who put me in contact with one of the guys within Beca who-- you know, part of the team that actually writes software for the military. So it's pretty diverse engineering company that, actually, I work for. And then we start to look at Tableau for dashboarding. And we dropped a whole load of static data out of Field and we put it into a dashboard within Tableau, and we were able to digitally report on percentage completeness of the digital information against the assets that we needed to know about.

Then we decided to take it one step further. We didn't want to have to necessarily do that every single time we wanted to report. We wanted this thing to be automated, right?

So some of our developers took the BIM 360 Field API, API directly into BIM 360 Field. We then hosted the data onto Azure, SQL Azure. And then we pushed that through, live, into Tableau. So we could do this every minute. There's not much point. So every midnight of every day, we do this pull from Field, onto Azure, into Tableau.

I'm going to show you that now, what that looks like. Now, there's a few iterations and changes I'm actually going to be making to this when I get back to Auckland. So hopefully this will come across. OK, PowerPoint doesn't like to be closed down on this machine, for some reason. Please bear with me a second. Righto.

There we go, good. Sorry, guys. Where's my mouse gone now? Next problem-- there we go, OK. So you can see all the applications that we use along the top there, from Autodesk.

If I click on Tableau and sign in-- so this is Tableau online, effectively. So we're going straight to the cloud again. So what's interesting-- I've just been showing you a project that's based in Auckland. The information sat on a server on the West Coast of the States, and we're in Las Vegas. And we could comment and review, check the data, check the information.

So we're going to dial straight into Tableau online now, just to show you what we're doing. This is digital reporting of information, so we can actually see how things are tracking. We've got transparency on that really important deliverable.

That's the project. Again, please excuse me. There's a few-- it still, it's 90% there, but you'll get the gist of it. So this top area here is, effectively, a list of all those types of assets that we wanted to know about. That's coming through from BIM 360 Field, so that's the stuff the client needs to know about for asset management and operations.

And if I hover over Fan Coil Units, you can see that we've actually got 54 fan coil units in that facility, which is cool. If you just scroll the mouse up a little bit, you can see that on average, across all those fan coil units, we're 42% complete on the data that we require for asset management. Down this left-hand side here, these are all the fields. And you can see an average across all those assets that's complete.

So basically, a blue bar is 100% complete. And the less of the blue that you see, the more incomplete that particular asset is. If I click on those 54 fan coil units there-- good, it didn't crash through the web interface. Then you can actually start to see, just for those fan coil units, the percentage completeness.

And if I jump over to type complete, we're actually adding in some extra features and functionalities of this as well. Then I can choose the type of asset that I want to interrogate here. So I'm just going to look up my fan coil units.