Using A360 Capabilities to Successfully Build a Knowledge Repository

JAMES MCNICOL: I've got to say, I'm impressed. When I saw that the time slot for this was the dreaded 8:00 AM after the company party-- oh. That's impressive. Thank you all for being here today. So my name is Jim McNicol. I am a consulting manager with the Autodesk Consulting America's Team. We're part of the Customer Success organization.

And with me is Ram Ramalingam. He is the manager of our solution architects team in the same Autodesk consulting group. And what we're going to do today is talk about how we have leveraged one of our own tools, A360, and we know there's a title change, the product. But we'll talk about that.

But we're going to talk about how we've used that in our environment to help manage some of our own processes and get a handle on, really, a large amount of data that we generate as part of our work with customers, as part of our work to create intellectual property. And we're going to do this today. The abstract is-- I'm not going to read it directly.

But it is a platform. We've been able to take this and solve one of the problems that we've historically had, which is around trying to share information on a large scale in a consistent way. As we went through this process, we learned some things along the way. We made some decisions that really helped us out, that have gotten us over what I would consider a problem of where typically repositories of information go. We've had success. And it continues to grow. And we're to talk about that today.

So in terms of the agenda, we are going to keep it, kind of, straightforward around what our situation's been and the approach that we took. Ram is going to spend some time going through the tool itself, the choices that we made, and some of the things that are kind of new that we're excited about. And then I'm going to talk about the getting back to the decisions, how we've configured it, how we're using it, how we're actually continuing to be pretty successful with how we're going by about it.

We are not going to-- this is not going to be a very deep technical talk. If you're interested, either one of us can try to answer questions offline, or we can introduce to you to some of the product managers who could talk about B360 Team. So that one is going off the cliff. And the other thing that's kind of important is A360 has been rebranded. So when we actually proposed this talk, it was still A360. And you'll see that vernacular kind of come in and out. But it really is the B360 Team as we go forward.

So a little bit about us. We are a group. We're part of what's known as the Customer Success organization. And within that, customer success is really around everything on support. So if you deal with enterprise party support-- premium support-- customer success managers, as well as us. So we are customer facing.

All of our work is based on our key product areas of Autodesk, including the AC products-- manufacturing, visualization-- heavy into Forge now, so we've got a team that's actually quite strong. We've done a lot of work with Forge and we're pretty excited about what that can do.

We're about 200 people worldwide, so it's not a huge force, but it's enough to have a lot of professionals who have come out of the industry to have a perspective that we have to tap into as a group over and over. So let me start with the situation now, in terms of the background of where this journey began for us. So we get involved with-- really at the point of where our sales team are working with you, as customers, to come up with a situation. Really, what do we want to do? What kind of solutions do we want to put in place? What problems are we solving?

And you can see we've got a happy customer and a happy sales guy, except I'm not sure which one is which. Now we know the guy with the money is the sales guy. Womp womp. OK.

So once that happens, we get involved with the customer and start thinking about going through our processes around the systems-- the solutions we want to deploy-- the business problems we're looking to solve. And doing that, we start leveraging a lot of information heavily, the first of it being out of salesforce.

So salesforce, for us, is really how our sales processes are built around. Many of you are likely familiar with salesforce. It's a big, heavy product. But when we need to access it for who we're meeting with, who are our key customers, who are the people that we're after, we go there. And it serves as kind of our point of reference, especially around the limits of the kind of work we're taking on to do.

As a group, historically, we have leveraged a number of systems to pull information from. So how many of you have used Buzzsaw in the past? So Buzzsaw was a pretty big part of our Team DNA, especially on the AC side. We use Buzzsaw to capture a lot of the project work we're doing, and it's been historically good for us for years. Also use things like box. You know, box is one of many kinds of shared cloud drives that you can quickly stand up and use and share, so that has proliferated quite well within our organization.

From the consulting front, we had two different primary tools. So the Americas-- we use SharePoint. SharePoint has been in Autodesk. It's kind of the home environment-- home system-- and many companies base their work or their infrastructure on that, as well. That was ours, rather heavily. So anytime we have projects, we created just a multitude of folders and we've created all kinds of other reports. So things like that. SharePoint has got a lot of access control, which is nice, but at the same time, it is heavy and there are some limitations for us that we-- by policy from our IT team that's come into play.

And then our [INAUDIBLE] team uses the one right here called A360. And this was kind of an up and coming product for us. They piloted it, using it within their team's structure, and having some success with it, they advocated and started coming up with rules of order in order to help their teams go forward. But it was really not anything that we were strongly considering as a repository for us. It was kind of business as usual.

And then finally, working with you, we all have places where we manage information, and so those come into play, as well. So this just represents the kind of thing that went on for us, in terms of systems that we used, how we use them, and quite frankly, it's successful. It took the job. We were successful in getting our projects done with customers, but it created problems, especially going to other people in the organization, trying to pass along, well, how have we been successful?

When that happened, you start having people come up like, we have a new customer. What do we want to do? We start asking questions. It would be random, ad hoc work, trying to say we're asking, has anyone done anything like this? We will search repositories of the things that we have access to, but things like Box and Buzzsaw-- if you don't know about it and you've not been invited, you can't find anything. You'll never know it.

We poll the team members on what they could possibly do. We would reuse content from our engagements or things that we would share, especially if it made sense. We saw similarities. We do our best to reuse that, but again, a very one off, bespoke process. And then at times, we would be faced with having to actually create things from scratch. And very much, when we'd had migrations, very complex integrations, this was the case.

So it really creates a situation if you're going from a success like this to-- we have more things we need to do and we're not well organized, a really bad problem. And our consulting team, at times, would be pulling its hair out. Why aren't we doing a better job of managing information, not only on what we're doing locally, but what would be great if we could do this at a global level?

So that started us into what is the problem we wanted to solve? We thought about it and started looking at this pretty seriously about a year and a half ago. We have a lot of good information, but we don't know what to do with it and we can't keep it straight. So we had three things we wanted to do. We wanted to highly do-- promote reuse and standardization of the things that we're doing and how we're doing it very heavily. We wanted to reduce the complexity of the work that we were doing, at least the way we were managing it, to get a straightforward way of bringing information together and getting out of the multiple system situations.

And then finally, we wanted to have something that was open and secure-- something that we knew people could get into, find things, but would have everything we needed in order to keep data very safe. And we needed to do this in a manner that didn't cost a lot of money. The idea of trying to-- we want to build a new environment or do something great from scratch didn't exactly float people's boat because as soon as we started turning from thinking about the problem, we started thinking about what the solution is, and everything started falling into the category of knowledge management.

Now, knowledge management-- when you talk about it, it strikes fear in some people's hearts because knowledge management itself has been a theory and a concept for decades, literally, and how to successfully find, store, retrieve, and share information. But quite honestly, for us, when we've tried this, we've done it in such a one off way that it really became kind of the unicorn for us. We've heard how KM could save the day for us. We just have to get a right process and everyone buys into it.

But the problem is it's such a hard thing to do to try to get everyone bought in on a singular way of doing things. I've personally been involved with initiatives to try to just get things down to the nth level, and it always starts off by boiling the ocean-- wanting to do everything at once, trying to make decisions based on the tool, trying to do things with technology that may or may not be becoming obsolete, trying to get everyone in agreement. And not just here in one operating theater in North America, but now throwing in Europe, throwing in Asia-- it's a hard thing to do.

Things aren't necessarily built for a changing organization. We change structures, we change teams, mix things up. But it doesn't stand the test of time. Adoption is always an afterthought, and then finally, if you aren't maintaining it-- an environment-- it really does go from a great idea to what we show is kind of a data dumpster. And then that's why, for us, many times, knowledge management is where ideas go to die and we definitely did not want to do that in this case.

So we stop back-- the context of what we could do with the problem we needed to do, which was starting to collaborate, not having-- [INAUDIBLE] being able to start from scratch and knowing that we've had situations that haven't worked. We started thinking about in terms of what do we really need to do, which helped us start turning the corner on how to be thinking about a repository that's going to hold up for us.

And there were four things that really stood out that we needed to look at in order for this to be successful. First, it's around-- the system had to be open. It had to be accessible to everyone. It was something that, by default, you can get into. It had to be searchable. The ability to actually have a focused way of finding information. It had to be timeless-- timeless in the sense that we're not going to be dealing with a platform we know is going away in two years or just has no real future around it.

And then finally, it had to be extendable in the way that, as situations change, as you get into a maybe different team, different dynamics, different people coming aboard, that if we needed to do something, we could. We weren't just beholden to one particular structure of information.

So that led us to actually look at the systems that we were using as a larger group, and in that, we took a look at the core systems from our organization that came into play. We looked at what we're doing in terms of our overall customer success organization to where we're keeping our offerings for our services catalog, what our premium support team uses, some of our legacy consulting, and just the different flavors.

And then we started talking to people within the group about this, just asking questions. What's important to you? How well you're doing it. And from here, we came up with a score, and we use red, green, and yellow to kind of-- how well certain things work. And what we found was really a lot of the basic questions. We got right down to-- I can't find anything. I don't know who to ask sometimes. I don't even know if this is relevant to my customer or not.

So taking that back, there was no real perfect solution that was going to satisfy needs-- complete. We literally had one green, and that was an open site that was based on some processes. But everything else had a level of-- we're not quite there. But that's OK. It was still enough for us to say we're not going to rule things out. The red was a little bit of a dead zone for us and allowed us to really-- we've got to be careful on those kinds of situations.

So we took that analysis and then started thinking about it in terms of requirements. So the Dilbert joke about this is where we hide the bodies, pretty much. So under requirements, we ended up with somewhere at about 35 really strong requirements that we wanted to see that needed to be satisfied in whatever we were going to propose, do-- try to put that out there to see if it's going to work.

That 30 something turned into five core requirements, and these were the must haves. That was being able to have partners access their information. We do share information with our partners. Customer access is something we haven't been able to do with SharePoint and other areas. Collaborating as a group, creating communities of practice, and then being able to search.

So really kind of simplistically, we looked at the solutions that we had. Everything we did about were certain things not going to make it, how do we keep things-- keep this process going, because we wanted to try something. So with our SharePoint, SharePoint can be an open system, but for us, it's not. It's just an IT mandate. So that one was really eliminated from that for our choice.

Box-- Box is not timeless. Box is something that actually, for us, is going to be going away because there's other competing products that are coming into the IT spectrum. So while box is great, especially for smaller level collaboration, it's really not anything-- if I don't know it exists-- it isn't there, I'm not going to be able to find it.

Buzzsaw. Buzzsaw is a product that we're really not supporting much anymore. It's something-- we know that the technology life is very limited, and so for us, that was a little bit of dead on arrival. And then finally, salesforce, and if you worked with salesforce, it's not fast. It's not cheap to do anything, and to implement any kind of customization was a bit of a problem for us. So that one was kicked out, which left us with A360 as the choice for us to be able to start putting some plans together of how we want to collaborate. And with that, I want to turn it over to Rahm, who's going to talk a little bit about that right now.

RAM RAMALINGAM: Right. Thank you, Jim.

JAMES MCNICOL: OK. RAM RAMALINGAM: So is there anybody who's been first time at AU this year? OK. I've been a [INAUDIBLE] artist since '99. I missed only four years till now. And then last night-- before coming in, I thought, this is yet another Wednesday night. It's going to be one more party.

But every year, it surprises me. This company can throw a party, different every year. [INAUDIBLE]. So anybody went to [INAUDIBLE] nightclub last night? That was hopping. There was a big line in the back. It was the place to be.

So, Jim, can you advance it? So what I want to talk about is-- Jim talked about process, people. I'm talking about technology. So when we talk to our customers, why do you need to use BIM 360 Team, which is what it's called now? If you are a manufacturing customer, it'll be called Fusion Team.

So we've got-- same thing, we've got four things we looked at from technology perspective. Everybody, traditionally, you get into collaboration with email. You always start sending information across through email. Messaging is the primary mechanism. No matter what technology, which organization you are in, messaging is something that you always use.

So we thought about how is it that everybody is doing it within our organization? And why do you think 360 does slightly better things than that? So we wanted to harness that primary mean of communication, which is getting lost with point to point messaging. You can't harvest it, and keep it for the future. So that was one thing you will find in your organization too. You will find you can stop email, but it's just that you can't harvest it.

And then we always talk about SharePoint. SharePoint is very good at what it does. But then it has its own idiosyncrasies. So I've seen customers who've really done good things with SharePoint. Really good stuff with no double forms on it, made people use certain things.

Especially when you are looking at multiple forms of data. There is design data. There is knowledge along with it. How do you marry these things?

SharePoint doesn't do very well in marrying these two things. That's one of the things which is happening with SharePoint. And then network drives. I still use network drives. Like Jim said, there's Box and other things, which is cloud-based storage.

But network drives is not going to go away. It's going to be there forever. But still, how do you even make people really move slowly away from that, especially when you're doing projects? Whether it's construction or manufacturing, where you're a team of people together, how do you even try to make them use one kind of knowledge well?

That was the key thing for doing-- why is it something which you can force an organization to change the way it does business? And then as I told you, cloud storage, it can do quick collaboration, but it really has not gotten to a point where it can recognize all the forms of knowledge, and visualize it, make it a lot easier. It's getting there, but it's not.

With Forge, we are enabling Box to see designs natively in Box now. So that means that in the future, you will see some of this cloud storage being very intelligent about your design data. But it's not there yet. So that's one of the four main things we generically transform. From what Jim was talking about, our internal evaluation was the product goal.

Can you go to the next slide? So what happened was we were talking to the project managers just two weeks ago. And then the first thing that he comes up with is saying, hey, we don't call this thing anymore, A, or B, or C, or D. We just said, oh, now it's going to be rebranded and also tailored towards your industry, which is-- if you're managing BIM data, there's BIM 360 Team. And then if you're managing manufacturing or fabrication data, it's going towards Fusion Team.

So it's not only changing the logo and nice icon, but also there are workflows tailored towards that. That's what they've done, as recent as two weeks ago. So when you go back, and you look at it, you will see that if you have not tried it, and you don't even know you have access to it because it's part of everybody's-- well, if you go and buy any product or orders, the team is always available to you if you want to use it.

So all this is making everybody go test drive this all the time. Try it out, give it to your users, see how your project team works together. And we really don't recommend that, OK, now let's ditch all the old processes and then go to this new shiny thing.

But we are really trying to say that if you want to improve design collaboration, this is something which is going to be available to you. It's not something which you need to go and buy off the shelf or something. It's available as a customer.

And also-- go back once. So on top of it, which I'm talking about, is that it's available in different tiers, which just means that there is-- you can go and try a single user and see if you like it, and then roll out to a smaller project, and then across the organization, and division, and everything.

So it's not something which is going to make you cringe and say, hey, I don't know how I'm going to deploy it. Your IT probably will have very minimal problems or pain point to roll this out, because there's no footprint in their organization. It's just browser-based, obviously. And then it's going to be available based on enabling a more secure way for your information to be kept accessible within your organization.

So that means your IT, all they have to know is, is information getting leaked out for some reason? That's the validation they will go through, but otherwise, they're not going to set up on a server. Nothing is going to happen. You just click on it, test drive it, move on.

Go to the next one, Jim. So what I'm going to do is-- we're going to play the old view video on this, and then I'll give you a talk of what are the things you want to look at from the technology point of perspective. So with this, it is heavily talked about. It is a big design collaboration enabler.

But obviously, from internal [INAUDIBLE] perspective, we do have design data we which we collaborate with our customers, like you. But for us, it was a lot bigger goal, in the sense that we've got a lot more non-designed data, which we want to make sure that the knowledge is captured and everything.

But what does it mean to you? It is, basically, that if you want to use this tool, your primary attraction to it is that in-place design collaboration. So that's what this tool allows you to do. You won't even know this tool exists. The user is going to go navigate to the folder or search to it, and then be able to just open up any design, and then just start looking at it, send an email to somebody, say, hey, I want you to look at something on this case.

So very simple collaboration enabler is available right out of the box with absolutely no configuration. It can read all the attributes you want in your Rivet file, in your inventory file, in your DWG file, and make it available to you right there. So the four things which we definitely want you to think about is-- like searchability. This is pretty good in different type of searchability attributes.

As he's doing, you can really share it by a link. You don't need to send any files by email or anything. You just have to do a short tiny URL to do it. And also, you can see that it's multi-platform enabled. So that means if you're on a desktop, or on a tablet, or on the phone, you should be able to get somebody to pull it up.

There's no excuses for somebody saying, oh, I'm going to go to the office and look for it. No, you can pull it up anytime with any kind of form factor. And the key thing, which it showed is the viewing part, is that as long as they can see and get access to information right there, wherever they are, whether it's 2D or 3D, then it just speeds up the collaboration.

So all we're saying is that we found that there's one thing everybody wants to do. It's that no excuse to collaborate. And that's a very good solution to just take that one problem and then solve it for the project team. Because a lot of those project teams, you will start thinking about how do I do approval process, how do I do axis control, how do I do other things?

But it is very important to do one good thing and then increase productivity and efficiency very fast. So as I said, why do you want BIM 360 Team? Why not something else? So we talk about three things which you-- if you can do three things with this, then you probably can measure that very easily among the project teams and be able to get to where do you want these people to get to.

So that means you can take the-- people start throwing things in the cloud, but in this case, it is lot secure, lot organized. And then, obviously, it doesn't tax your IT anymore. It's something which is available to you as part of your subscription. And also it is managed by Autodesk. It's actually 24 by 7 by Autodesk.

And live access to everywhere. And the other thing is it doesn't matter-- we have talked to customers who have got very, very large sites. And they managed information very effectively with this thing. They can go anywhere they want, and there's no excuse for not accessing it.

So going to the next one is, basically, if you start using it. Do I have a future with this product? Obviously, yes. So what we are saying is that though you're enabling collaboration, you still will be thinking about some of your corporate systems, which need to share information from the designs, from your files, from your correspondence, from your reports, everything which you're going to store in BIM 360 Team.

How do you even get to some of the other third party tools which you're already using? So that's why the team is already built to give and take information through Forge services. And Forge services is another thing. It's like you don't have to worry about what Forge is because it is something which is available to you.

All you have to think about can I get my information out? And yes, you can. It is it's a connector which is available. And you can just go and tie it to one of your corporate systems and then be able to exchange information for pretty straight. So if you start implementing 360, that should not stop you, saying, oh, I'm going to put this in another canister, and nothing can come out of it. No, because that there is a way to get things out with minimal configuration.

And when we talk to our product guys, saying, OK, what's going on? What is new? Which is as recent as last week. And if you ever use Team on your current organization, you will see that there is something called a connector or desktop installer, which has come right now.

What happens is that you will find your users saying that, oh, I've got to go to a browser. I've got to drag and drop into the browser. I've got to start organizing my folder, all those things. What our project team has done is, basically, they created a very small footprint installer for Mac, and Android, and also Windows, where the cloud structure is available to you on your desktop, as a virtual network drive.

So basically, now all you're doing is opening up a Windows Explorer or Mac Explorer and then dragging and dropping within your Mac Explorer. And automatically, it is going to sync to the cloud. So you are not really asking your users to go out of their native environment to do it. Even if you see-- you pull up your phone, and if you want to move some data, and then try to-- you don't have to pull a browser, or drag, or drop on anything because it is natively available as a forward mechanism in your phones into one of these drives directly.

So that's a cool thing about it. You have field person taking pictures, they can upload it right there. They don't need a browser or anything. So with this desktop connector, it's available. Some of these things make it a lot easier to push and pull data. So in our case, we are doing something very similar.

So we're talking about [INAUDIBLE] what was our problem, why we chose this, and then I tried to give you a little bit of taste of what that product is all about. But what is in it for you? So in the sense that-- what can you do after you get out of this class?

So one of the key things, which I didn't talk about it, you can definitely do, is that it has got-- you use Autodesk products all the time. And your users always are asking you, saying, what's new with it? How do I do this thing? Or where is this video to do something, which I want to do to make my life easier?

So there is always a need for disseminating Autodesk product knowledge to your users. One of the things this tool does is it's called wiki pages, a mechanism which will allow you to really compress all this information and provide it in a portal format to users who are specifically using Autodesk products or design collaboration. So this is one of the ways where if you have your own BIM standards, if you want your own guidelines and best practices, today you have to put it up on your portal.

That means you have to get a dedicated IT page, which IT has to enable you to do it. In this case, the simple wiki can allow you to do that just very, very easily. So when I post this handout, I should be able to-- some of these links are enabled, so basically, it will teach you how to get started pretty quick.

So that's one thing which you want to do. You want to get out, and then start trying out. But also, this is something which people forget, even if you don't collaborate that much, there is a value in going and disseminating all of this product information. OK, Jim, continue the journey.

JAMES MCNICOL: All right. So thank you, Ram. So we talked a little bit about the tool itself, what we were doing. What we started doing, with respect for our approach, was we-- first of all, really want to keep in mind that we did not want the data dumpster. We're doing everything possible to not get to a point where this is going to be a mess. It's 12 months out.

And so we had four different areas that we tackled, first one being defining the repository. What role do we want the repository to play in our practices? We can't boil the ocean, but there's certain things we could do with it and do things well. The naming conventions, which became really important for us, that was something that has helped keep ourselves organized, and, quite frankly, is probably the most important decision we made and how we're handling things.

Our ability to search and some of the things that we did for searching, related to naming conventions, that's actually been a benefit in using B360. And then some of the norms that we have, the processes that we put around. Not very heavy processes, but enough to be able to ensure that we have a good start for our projects.

So when we talked about the first item, managing the role, what did we want this to play? We thought about everything that was getting stored and how we were doing it. And so we came up with things that we wanted to see as part of this repository, which really around the shared things that we're doing-- the customer deliverables, our meeting materials, presentations, things like that.

We also came up with things that we didn't want to see proliferate in the environment. And that is related to a lot of personal stuff, things that you create that you aren't necessarily ever going to want to share-- non-project data, reports, a lot of financial reports that get generated. We didn't want that to proliferate this environment.

And then the last two-- private projects, we really discouraged, and then a freeform creation like a wiki. And I'll talk about how we're actually interfacing on that in a few moments. So for us, the naming standards really centered on trying to come up with a couple things to designate the project. We've settled on about eight or nine different terms or categories, including hub projects, which are things that are related to the-- for anything anyone needs for help.

Internal projects, these are actually customer-facing projects that we manage our internal information on. Customer projects, so this would be where we're collaborating and people with the outside in a very secure manner. And I'll talk about what's going on with that. Team structures, initiatives, our offerings-- so everything had a category. And we have adhered to this in order to be able to look, and categorize, and see how projects are actually being created, how we can keep track of things.

And most importantly, especially on the collaboration, which we weren't able to do before with SharePoint. For a given customer, we create two different sets of projects. One of the features around the 360 platform is access control is at the project level. So in order to be able to have a secure place for customers and team members, as well as internal things that we want to harvest, we actually have two different projects referring to the customer.

This one is internal. It's open. It actually allows-- if I were not part of the project, I could look and see what's going on, with respect to the deliverables, the contracts. We also have a customer project, and this is one that is closed. So if I'm not part of this project, even though I'm Autodesk, I can't see it. We value the privacy of our customers.

So they can get into this project, share information with the consulting team, and that's not going to be shared or searchable. Unless you have a reason to be in there, you're not going to have access to it. That helps maintain that level of confidential information. Things that can be shared, like contracts, and things like that, we make that searchable internally.

We also have been able to use, from the searching feature, by adding-- the underscore has helped us be able to locate key items a bit further. So for example, I was looking-- this was an actual search I did as part of this for a template that we use to catalog some of our projects around Forge. I searched Forge without it and Forge underscore with it.

And the results, actually, I was able to get to the Forge catalog template among my first couple hits versus it was a little bit further down. By actually instituting the underscore on certain key projects, it's helped us be able to get to the content a lot faster. It is just a unique way of categorizing.

For our procedures, the things that we've done for procedure perspective, everything has got the projects created, as default, as open. The environment itself creates projects closed, but we've made some changes to allow that to-- by default, if you're going to create something, it's going to be open. We have a small group that actually creates all of our customer projects.

So it's a standard uniform way. It's just a small amount of overhead, but in that manner, we can make sure that all the folders look alike. Everything is pretty well uniform. And then a number of us in Americas and EMEA play traffic cops. We see projects that are created that don't have the nomenclature. We ask them to fix it. It's not a lot of time, and once people are into the groove, it's keeping our environment quite organized.

So our overall lifecycle, how these things come together around BIM 360 Team, it really starts with the library concepts that we're creating on our roadmaps that we share-- our offerings, our training, our planning materials for project creations, to our mobilization, how we engage. And this is where we're back and forth, in terms of the kinds of things working-- the deliverables, how we harvest information, and that includes coming back with any kind of things we want to share for IP, success stories, and then finally, how we share, which is the Team repositories and best practices.

And where these things all link together is we're able to take some of these things around best practices and IP development and take that and turn that directly into training, all as part of the same library. So everything's stays maintained in one area, and then same thing, with respect to our offerings that come from the successes and things that we want to be doing in the future, such as more Forge.

Our approach for rollout was pretty straightforward. We created a self-help. Once we got everyone to say we're going to be using this for our stuff, we had, really, four things we did. Self training, we had a lot of user videos.

The project managers who were in our groups, who were responsible for customer projects, all were trained to be able to use this format. It was about an hour training, but everyone was required to take it. Short videos that are out there, then we also use Slack for our communication. So if someone has a question, they're able to get that answered by a team of admins from our group.

And the admins are just us. There's no one really special. It's just keeping track of how we're doing and the health of the environment. So the workflow [INAUDIBLE], I mentioned a couple of minutes ago about this concept of the wiki. So we did try to use the product as a free form wiki tool. It didn't really work for our situation. And over time, there has been a true wiki that's been created that's based on confluence that a lot of merging information is coming together.

This was a little bit of a threat, with respect to how we could continue to create this other-- using BIM 360 as our repository, yet having this wiki in place. The nice thing that we've been able to do is the freeform activity is in confluence. The final deliverable-- so anything that we're attaching to comes into our 360 environment. And this is allowing us to make sure the latest information, the final data, is actually in the environment it needs to be.

This area, the confluence site, is one where it may come, it may go, it may die. But the real final product is there, and it's categorized correctly, and you'd be able to find that. So in terms of our status, we are one of the largest, if not the largest, 360 repository in the Autodesk domain.

We have 350 projects going. We have 120 customer projects going, hundreds of users, a large amount of information, to the point now, we're starting to use the archive feature for some of our older projects, things that we're not necessarily thinking we're going to be able to need, so that we can keep our search results up to speed.

So with that, I invite you to take a look at the product. If you have any questions, I'd absolutely like to answer them. I've got my card up here if anyone wants to ask questions offline. But, please.

AUDIENCE: It's kind of a three-part question. So security, backup, and [? sizing, ?] do you guys have what's stored there?

JAMES MCNICOL: So the security, in terms of just who's maintaining it, how we're doing it-- the security itself, we invite people to projects, and they are then registered. They're able to get an ID to be able to register. We manage that. We delete users if they're not-- or remove them from projects if they're not part of the project team any further.

With respect to backups, that's all being managed by the cloud team. And then on the file size, right now, there's not a restriction. There's a possible restriction coming up. There is an upload restriction through the desktop connector of 2 gig, but other than that, it's fairly open.

AUDIENCE: Did you say it's pretty open right now?

JAMES MCNICOL: Right now, there's no limit.

AUDIENCE: [INAUDIBLE] would it be an extra cost? Or what--

JAMES MCNICOL: There's no cost, yeah.

AUDIENCE: Are you able to restrict two files or folders?

RAM RAMALINGAM: Mhm, yeah.

JAMES MCNICOL: Go ahead.

RAM RAMALINGAM: [INAUDIBLE] once you and [INAUDIBLE] start collaborating, you can make that [INAUDIBLE]. Or [INAUDIBLE] like Google Drive, you can say that if anybody has that link, you can collaborate with us, or even though you have the link, you can't get in until you're enabled and get access [INAUDIBLE] in a folder or file [INAUDIBLE].

So one of the things we were trying to do, if you don't know how to use it, how to [INAUDIBLE], then you can send an email to me or Jim. We can actually set up a test drive file for you guys, and then you should be able to bring in two or three other people and starting seeing how you can collaborate [INAUDIBLE] what's the best option we want on that. So you can send an email to us, and we should be able to [INAUDIBLE].

JAMES MCNICOL: Yes?

AUDIENCE: How does collaboration for Revit fit in this? Is it part of it? Is it a separate--

RAM RAMALINGAM: It's a separate thing. Collaboration for Revit is something that you are using [INAUDIBLE], and then you are collaborating specific designs across the [INAUDIBLE]. This is data restricted for only design Box.

Where we are going with this is that ultimately, every design data [INAUDIBLE] produced is going to get stored [INAUDIBLE]. The [INAUDIBLE] is the file management part of it, and then the team is about sharing [INAUDIBLE], approvals, and [INAUDIBLE].