One Small Step for Man, One Giant Leap for Autodesk PLM 360 Implementation: Sprint to the Finish

AVI ROBBINS: All right. Good afternoon. How's everyone doing? We're going to talk today about PLM 360 implementation. The course is really designed for people that are just thinking about implementing PLM 360. Or for people who are just considering purchasing p 360. And we're going to talk about our use case, how we implement a PLM 360, what we're using it for.

I'm Avi Robbins. I'm the director of Global Product Development for Porex. And we'll go into a little bit of detail of our use case. With me here, today, is Ian Haddon. He's a Solution Architect from Autodesk. He helped us implement PLM 360. And, of course, Brian Schanen, who will be moderating the class today.

Just a little bit of a administrative work. This session is being recorded live. And it is being streamed online. If you're in the room and you want to ask questions, you can just login, check in to the mobile app and type in your questions that way. Or you can-- for all the online viewers-- you can just send a question via Twitter.

Brian will be monitoring the Twitter feed and the check-in questions. And periodically, we'll be stopping to answer any of your questions. And, of course, don't forget to fill out the survey at the end of the course. We really use that feedback to shape the courses that we offer next year.

So just a little bit about myself. Again, I'm Avi Robbins with Porex. I've been about 10 years in industry-- in medical, consumer, industrial electronics industries, in various roles from product development to sales and operations. And right now, I've been responsible for spearheading the PLM 360 implementation and the selection process at Porex.

IAN HADDON: Hi. My name's Ian Haddon. I'm a Solution Architect with the Autodesk PLM Consulting Group. I've got 10 years now, PLM experience, with various different PLM products. I Was actually on the implementation at Porex as the solution architect, worked very closely with Avi, laying out the solution that we've implemented there.

AVI ROBBINS: And we have Brian Schanen from the PLM Technical Marketing team. He's really the PLM, PDM veteran. The evangelist and nurturer. If you need to any assistance with PLM, Brian's the guy that's going to get you through, make sure you know how to use the system.

So what we're going to do today is just talk a little bit about our use case. What's Porex doing with PLM 360? What are the steps involved in implementing PLM 360? A little bit about integration, you know, how to integrate. We did it to our CRM and our planning for our Vault Professional integration. And then some tips and tricks.

So the first two steps are a little bit more high level. Then we'll get into some tools that we used within the implementation and integration process, to help us do that more quickly and to help us with our change management process. And then at the end, we'll go into the tenant, show you our demo tenant and some of the innovative use cases that we're using PLM for today.

So our PLM journey-- Porex is a manufacturing company, but we're really a new product development company. We develop about 600 products a year. We're making porous plastic. And what is porous plastic? It's plastic components that have microscopic holes in them. This is used for wicking, venting, filtration, diffusion.

And where you might have seen it is in children's coloring markers. The tip is porous plastic. It allows the ink in the barrel to wick through to tip. And it allows you to write it on paper, without getting all mushy like the old felt tip pens you used to use. It's also the medium in the plug in air freshener that brings the oil from the bottle up to the fan that disperses the fragrance into your room.

If you're big into sports, it's in your sports bottles. You have a black carbon filter to filter out the chlorine taste. We make those filters, as well. So we're in tons of industries. I mentioned a few consumer products, but we're in electronics, industrial, medical applications. It's really a functional component that allows our customers' products to work.

And in order for us to manufacture these products, we have to develop and define them. And we do this across the globe. We have four manufacturing facilities. One in the US, Germany, Scotland, and Malaysia. So you imagine, we have a pretty distributed development and manufacturing team that's trying to get these products to market.

At any time we're producing thousands of SKUs to make 30 million components, daily. So we really have a pretty big operation for a small company-- 750 employees, globally. And really rely on our systems to help us meet the needs of our customers. So what are our business challenges?

Well, growth, of course, is everyone's challenge. How can you grow faster? And really, when I came into my role, I was tasked, how do we grow product development and really globalize our organization? We were really regionally. We had our team in the US. A team in Germany, Scotland, and Malaysia. Everyone was acting independently, developing our products, using our own systems. And we really needed a way to bring that together so we could properly prioritize our resources, but also to gain a common knowledge from a development that happen in one region, why reinvent the wheel somewhere else?

We really needed tools to help us collaborate. And that's, really, a big part of product life-cycle management. So before we even picked PLM 360, we really decided that we needed a product life-cycle management tool to help us house this information. When we're going through our development cycle, we're creating specification, creating tools, developing all these different pieces of information and putting them in buckets all by themselves-- some in Excel, some on pieces of paper, some through email, some in custom software that we wrote.

And we really didn't have a good way to put all that together. So at the end of the process, when we need to turn our products into production, we have to go back and search through all this disparate systems and really reinvent the wheel, at the end of the development cycle, before manufacturing could take over.

So product life-cycle management is going to help us tie all these pieces together. The product will be linked to the project, which will be linked to the quality documents, which is linked to the manufacturing documents. And when sales is out on the road, they can easily login, see all the information they need. When product development is out visiting customers, they can easily login and see everything they need.

And so here's a snapshot of the mess I describe a few minutes ago. If you pay attention to all the dotted lines, that's a manual transfer of information. You see email moving to our CRM, our CRM tool. We see manual information going into our share drives. So we were storing a lot of information on shared folders, but not just one shared drive, right?

Product development was putting their information somewhere. Manufacturing another place. Quality another place. We're using Access databases, Excel, different pieces of CAD software. We have two different ERP systems. We have a manufacturing execution system.

So we have a lot of information that's being authored, put on paper, typed into another system. And we really wanted to clean this process up. So we decided that PLM should be the single source of truth for our information. We're going to create the product record, the item master, in PLM, and it's going to own the product life-cycle, from creation, to change, to obsoletion. That will all happen in PLM and we'll push that information to our other systems.

So we have one place we can control all the information. Everyone in our different regional offices can access the same information and always have real-time information on what's wrong with our projects, what's going with our quality records. It's really going to be the way for us to be more efficient in the future.

So aside for manufacturing, a big part of it is project management. How can we take 600 projects that are in the pipeline and make sure we're working on the right one? And with a small team of engineers, we really need to prioritize our resources, make sure we're working on the projects that are going to be best for our organization. And when a customer has a need, how can we make sure we can prioritize our resources to meet our customers demands? So without having this global transparency, there's really no way to effectively accomplish that.

And here's the to-be system, right? With the use of Autodesk PLM 360, this is what we hope to accomplish. Very few pieces of information leaving one system, moving to the next. And most, that is, is actually being done in an automated basis. So PLM, here, is in yellow. You can see it's going to take over our new product introduction process. It's going to look at our management reports, issues management, ECO, the Change Order process, manufacturing quality.

Eventually, we're going to implement Autodesk Vault, which will store our CAD data, which will be linked to PLM, so that our project and product record is linked to the CAD that defines it, for manufacturing, and linked to our ERP. So we develop a product, develop a specification, and it gets pushed, automatically, for transactional information to happen in our ERP system. And, of course, we'll link that to our MES system. So you define the product, how you're going to manufacturer it. And then MES Manufacturing Execution, will control our batch records.

And the good thing about PLM 360 here is, we have different business needs, right? Each region is very similar in the way we operate, but we're not all the same. So we still have this need for homegrown solutions, or different business processes. But PLM 360 acts as a foundational development platform for us.

So if you want to build a homegrown system, you can do it in PLM and all the data will link together. There's nothing wrong with that software that you wrote to do exactly what you want. The problem is, how do you get the information, natively, between departments? And that's where PLM is going to offer us the solution.

So what are we doing with PLM 360? I mentioned a little bit about this before. But project management, the new product introduction process, is a big part of this. We're using it to control the product, or our item master. We're going to use it to look at our customer and contact information, so that the product development engineers know who they're working with and can keep track of the customers that they're dealing with on a day-to-day basis.

We've implemented an integration to our CRM system. And we're using it for a reporting, as well. So our monthly metrics reports and other pieces of information that we need to gather on our pipeline process, we can pull out of PLM 360. In the future, we're looking at materials management, sample order management, document control, tool design, tooling orders, our quality system, costing. I mentioned integration to Vault. And eventually, integration to ERP. And so we've completed Phase 1A, we call it, what you see in the blue box, here. And we're actually, in January, going to be launching our Phase 1B.

So this is just to give you a context of where Porex has come from in our PLM journey. And when we talk about it this afternoon, we'll be, how have we learned from this process? How can we help you when you're planning your integration or your implementation of PLM 360? Are there any questions, so far, Brian, about our journey?

BRIAN SCHANEN: No, none so far.

AVI ROBBINS: OK. So we'll move right along into, what are the steps involved in the Autodesk PLM 360 implementation process? And again, this is a high level look of how we think about what we've learned from the implementation process. And I can sum it all into two lines. Think big, but start small.

It's really important to have that grand vision, like I showed you a few slides ago, how we're going to use PLM 360. All right. And make sure you really understand how you can use it in your organization. But at the end of the day, you can't do it all at once. The big bang approach just won't work in a flexible environment that is required today.

And so what we think about is a three-step approach-- discovery, system architecture, and then making it happen. The discovery process, really, is about starting from the beginning, understanding your business needs and defining your business processes. And it doesn't have to be what your current process is. It can be what you want your process to be.

But for a company like Porex, some of our processes were on paper. So we didn't have a process map. And the big thing, for us, was to take the time to define what the process should be. All right. So putting it into a tool like Visio, or any flowcharting software, so we could really see, what is the process we're trying to govern in PLM? PLM isn't a solution on its own. You need to create the process that you want it to govern for you.

But really, I can't stress enough having the business need defined. What's really that pain that you're going to try to overcome? For us, it was growth. How could we really double in size without having a tool to make our implementation of products faster? I don't know if you have any insights on that process, Ian?

IAN HADDON: Yes, I just want to talk a little bit about the picture that Avi's got up there. I know it's difficult to read in the room. But what we did for Porex was, Autodesk consulting came in. We sat with Avi for about a week, give or take, and just really talked about what Porex wanted to get from their PLM implementation.

So Avi said a few things here, today. He's talked about new product introduction, change control, mentioned quality. So every time that Avi mentioned one of those things, we thought, OK, what is that quality want to do? What is quality at Porex? So the main thing that they wanted to capture as part of new product introduction was the development of a quality control plan.

So as we had that discussion, we drew out a workspace map. And what a workspace is in PLM is, it's a container that holds records that share the same information-- same fields, same workflows, same tabs. So for quality we said, OK, we're going to need a workspace to capture that quality control plan. We're going to need a workspace to represent your projects. We're going to need a workspace for your products.

And we went through, and we built out a map of all the workspaces we thought we'd need to implement everything that Porex wanted to do. This was really that "Think big." Once we got the map put together, that's where we then looked at and said, OK, which workspace do we want to build first? Which do you want to do second? Which ones are we going to do for part a Phase 1? And then we went through and started building out those workspaces.

AVI ROBBINS: And so, really, it allows us to have a modular approach. We could see the big picture. How we wanted all the information to paths between the different workspaces, so that when we're in the project workspace we can link it to the customer workspace and get the information for the contacts of that customer. When we're in the tooling workspace, the tool designer can get the information about the product to see the specifications, so that all the information is link appropriately.

But we don't have to do that all at once. We can start with NPI process, start building that information, because we know, in the future, how we're going to link the other pieces into it. So it really allowed us to start with one piece and move forward. I'll be honest, with our implementation, we thought really big, like you saw. And then we picked a chunk that we thought would be manageable, but involved about 20 or 30 different workspaces.

And so we were getting about a month away from when we want to go live, and we were 90% done with all of the workspaces. But we weren't going to be able to make that last 10%. Because, when you're building out your implementation, you have to think about, you're going to have a pick list with all these values. Well, who's going to populate the pick list? What are the right values? What should the field name be called?

There's all these minute tasks that have to be accomplished, but they have to be checked. And you need to reach out to your audience and make sure you understand what really should be there. And that last little bit of refining and correcting can be a big task if you have such a huge scope.

So we then narrowed it down. Picked one scope of NPI, and decided, let's finish this. We could be done in a week, instead of a month, and roll it out there, start getting the user feedback. And that really comes down to the making it happen part, right? That's developing a core team and process experts.

And what the difference is, the core team are the people that are going to make it happen. They're going to be defining your workspaces. They're going to be building the fields, creating the pick list, reaching out to the process experts. The process experts are the ones that are of your department heads.

They're the people in quality, the people in manufacturing, the people in sales, marketing, product development, in each of your different offices that have a stake in the processes that you're going to be developing and implementing in PLM. And they're really a valuable resource. They're going to help you understand, what's the business process they need you to implement in PLM? What's the information that should be put in, data that needs to be imported?

They're going to be the source of that data. They're going to help you clean and refine the data to be imported into the tool. And really, they're going to be the user acceptance testing people. They're going to help you test the product, give you feedback before you roll it out to a wider audience.

IAN HADDON: And the one thing that we made sure of at Porex is, we kept that core team small. It was six people, total, maybe seven. But by having that small team, we were able to make decisions very quickly. If we go to a place where it was, "Do we want option A or option B?" it didn't take long for that team to evaluate both options, pick the one they wanted. And then we could move forward with the rest of the implementation.

The process experts, that was the bigger team. If the core team weren't able to make the decision, they were empowered to go to those process experts, get their advice, show them, and then get that decision made.

AVI ROBBINS: Absolutely. And so Autodesk really played a big part in this process with us. They were one of the reasons we selected Autodesk, aside from total cost of ownership, and the really ease of use of the tool was the partnership we felt we could have with them. They really came in, in the discovery process, helped us understand the business needs. Helped us map out the road map for how we could implement such a large scope in a phased approach.

And we'll talk about that in a little bit more detail in a few minutes, here. Are there any questions, Brian, about the overall implementation process?

BRIAN SCHANEN: None, so far.

AVI ROBBINS: Good. So let's talk a little bit about integration, then. What's the integration that we performed? We integrated to our CRM system. And we're planning, right now, the integration to Autodesk Vault Professional. All right. So if you're not familiar with CRM, that's Customer Relationship Management. That's the tool that our sales people use to have the leads or inquiries come in. They manage that process, manage the customer information.

And when they're ready for engineering support to take the product to market, then the data gets pushed into the PLM system. And I'm sure most of you aware, Autodesk Vault Professional is the place where we store CAD data. And linking that to PLM will allow us to pull up a project and see the CAD file, which you'll see here, shortly.

So really, the lesson here is, you can only have one master. You've got to think about, where's the data going to be controlled by? And when we looked at integrating to our CRM system, we had to decide how are the people going to use the tool? How is the sales going to go in and author the information, consume the information? How is product development going to author the information, consume information?

Realizing that we can't implement something to the benefit of product development to the detriment of sales. We need to make our overall company better. And you can't do it for one department at the detriment of another. And so we thought, let's separate the functionality. Let's make sure that sales can go and update the product information, the value of the project, what are the estimated sales, the target launch date. All the commercial information, customer information. But then, own that in CRM.

And then, let's push that into the PLM. So then when product development is developing the product, they know what the value is, so they can prioritize their projects. They know what the target launch date is, so we can move things within the pipeline to make sure we're working on the right projects.

And sales doesn't have to go in to the PLM system, if they don't want, to see the status of their project, because we're taking the status of the project from PLM and pushing it back into the CRM. So what I just described was two one-way pushes of information. So for some information, we're controlling it in the CRM and pushing it to PLM. For some information, we're going to control it, or master it in the PLM and move it into the CRM. And that's true for all of our systems.

So if you think about one single source of truth, the PLM is going to be the master for our item data, right? It's going to hold the product specifications. It's going to hold the quality information, the manufacturing instructions. And it will push that out to the systems that need it. To the shop floor, we'll get a copy, the ERP system will get a copy for transactional records. But really, defining which system will be the master, and for what pieces of information is important.

And what's the deliverable? Who needs it and when, is important, because, just because you can, doesn't mean you should put all the information everywhere. It doesn't necessarily make sense to take every piece of information in the CRM, and just because we can, put it into the PLM. Because then you're going to interrupt the workflow in the PLM, and you're going to start to encourage the wrong habits.

We want to make it easy for everyone to use the tool, but we want to make sure people are using the right tools, and using it in the right way. So when we get further with integration, and PLM now has quality data, manufacturing data, CAD data, you don't have people expecting that to show up in other systems. Certain information should be in certain places, but it should be in other places, as well. And there's a lot of different ways to accomplish that.

You can use event-based sinking. Which means, when I perform this task, automatically push it to one system, but it doesn't always have to be that way. It can be a batch process. Maybe every five minutes, every hour, every week, every month you want to pull information from one system to the next. It really depends on your process. And it could have an effect on the implementation.

So for us, using PLM Connect, we were, within a week, able to connect the PLM to our CRM. What took us the long part was developing the business logic before that to figure out how we were going to push that information. What were all the rules that we needed to put in place for, when something changed, how would it trigger the information push?

So there's pluses and minuses to both ways of integrating your tools. But it really just depends on your unique situation. And that's where Autodesk really helped us to define that process, as well. I don't know, Ian, if there's any other lessons you think we learned from the integration process?

IAN HADDON: Yeah. I mean, the one thing, while we did some of the integration in Phase 1, we did it very late in that phase. And the reason for that was, we needed to get by the sides of the equation written before we could build the integration between them. So we had the CRM. We didn't have the workspace yet, in PLM. So we couldn't even start thinking about integration until we knew what that workspace was going to look like.

We obviously, as we were planning it, decided-- you know, there's, say, 10 fields in the CRM that we want to move to the PLM, So we needed to make the space for those fields. But we didn't want to build that actual integration too early, because you wanted the flexibility, what if we want to make 11 fields? 12? We to take some away? We didn't want to have to be do any of that work.

So at Porex, we built the workspace. We got all that business logic worked out. We kind of walked through the integration manually. When this happens, we'll move this information to here. When this happens, we'll move this information back. And then once we had everything worked out and manually working, we went in and actually built the integration to automate it.

AVI ROBBINS: Yeah. And that, really, is kind of the approach we're going to take with our Vault integration. As we plan for that now, we're starting to author of the product information. So now it's the time to integrate to our CAD data. So we have a product. We're defining some of the specifications, let's pull in the CAD information that defines what it looks like.

And the way we're going to implement that is, creating an item in PLM, we'll now push the creation of a container in Vault to be created where the designer can go, put in the right CAD data, then push that back into PLM for review, approval, and release to the tooling or manufacturing systems. OK.

So that's really just a high level look at how we worked on our implementation and the integration process. What we'll talk a little bit now is, what are the tools that got us there? What were some of the tips and tricks that we used to accomplish that? And if there's no other questions from Twitter?

BRIAN SCHANEN: Actually, we've got three.

AVI ROBBINS: All right.

BRIAN SCHANEN: So let's go. So the first one, what was the competition to PLM 360? Did you look at other solutions?

AVI ROBBINS: Yeah, we looked at some other big box solutions, some on premise solutions, some of the really big names that are powerful in PLM. And there's no doubt they would have done the job. But what really drew us to the PLM solution, PLM 360 solution, was the flexibility.

As a business process owner, I couldn't imagine sitting down for a month, putting a whole list of requirements on how we're going to implement the solution, then let someone go away and do it for me. What I really love about PLM 360 is, I can get in the system and create a field, create a workspace really, really easily. You can do it in a matter of minutes, right? And there's a lot of tools that allow you to control the system that you're working in. And so that really was a really important part of our selection process.

BRIAN SCHANEN: Good. So the next one, it's a really good one, what were the biggest pieces of resistance internally to adapting PLM 360?

AVI ROBBINS: With any cloud solution, you can imagine, people were concerned about security. Especially our process is driven by trade secrets, so we don't even have patents on our processes. It's all trade secrets. So our management team was really concerned on moving to the cloud and, what are we going to do with all that secret information?

And really, after we got our IT team on the phone with the Autodesk infrastructure team, they were able to alleviate all those concerns. I can't, personally, speak to all the technical details of that world. But I know that once our management understood the security that's in place on PLM site, we were able to move forward with no problems.

BRIAN SCHANEN: All right. So the last one for Twitter is, how many licenses of PLM do you have? And how many do you anticipate you'll end up with?

AVI ROBBINS: OK. Yeah. So we have about 750 employees, about, maybe, today, about 150. We have 150 licenses of PLM. That's going to be our sales and marketing team, our product development team, our manufacturing team, quality team. But that won't be enough. 150 won't be enough for all those users.

But for the first phase, we're probably using about 50 licenses. In the second and third phases, we'll get into the 150. But I would say, in the long run, for our company with 750 employees, we'll probably needed about 200, 250 licenses when we're all done. We want to make sure that anyone that's interacting with any of our business processes can get the information that they need. And so they're going to need to get into the PLM to see everything, in the future. Those are all good questions. Keep them coming, via Twitter.

So really, when you think about tips and tricks, If. You don't know where you're going, any road will take you there. That's one of my favorite quotes. It's really about defining the vision. And we talked about that in the previous slides about implementation. To me, that's all about executive sponsorship.

You've got to have someone that really believe in PLM, and that can really attach this to a defined business need. You know, we talked about that already, but it really is worth mentioning twice. That if you don't have a business need, if you can't define the business need, you can't guarantee the success. But I can almost guarantee that if you have a business need that your company can get behind, that your project won't be able to fail, because your company won't be able to afford to.

For us using product development growth as the business need and reduction in errors and easier access to information, really allowed us to focus our implementation on, what's going to be the best for our users? Really we're spending about 10% of our engineering, sales, and marketing time looking for information that we already created that should be accessible at the snap of a finger.

So that was really what drove us for PLM. And I think having the executive sponsorship was really important for us. Another reason, is for change management. One the biggest thing is I can stress is, change management is important to get your users to adopt the system. And you're going to go through the core team process, the process experts, to really engage people and make them really want the tool.

But at the end of the day, when you try to push out, let's say, a global partnering system that requires everyone to change their systems, you're going to have some resistance. And you need someone that controls that process to say, look, this is the business reason, and we're going to move forward. So as much as you do change management, you need someone that can put a stake in the ground say, look, we're going to move forward down this path. It's going to be for the better, but it might not be the same. And that's really where the executive sponsorship helped us out.

And building the roadmap, we really relied on the Autodesk team to help us with that. It was really, like I mentioned before, a true partnership. To come in, interview our team, understand our processes, and then spit it back to us, to make sure that we realized that they understood the processes we were trying to implement.

And looking at some the tools that they introduced to us, one concept is Swim Lanes, right? That's really about defining your process. So if you look at this, this is our new product introduction process. And it looks at the flow of information across our different departments.

So each lane in the swimming pool is a different department, manufacturing, engineering, quality. And you can see, as the process moves from left to right, there's an exchange of information. And we can, from that process, defining this process, we can start to capture, what are the opportunities for improvement?

So this is our as-is process. We can use that to define the opportunities for to-be process. And really, coming in, doing informational interviews, Autodesk was really able to understand what our business processes were, and what our business needs were. And map that into opportunities, that I mean going to talk about here, in a second.

So any of these tools are available. If you are interested in this, put a message on the Autodesk app, shoot me an email. You could find my information on the Autodesk University website. I'd be glad to share these templates with you. They're all either from Visio or Excel.

IAN HADDON: Just, while Avi's got that out, as Avi said, this was the to-be process. So one of the things that we did is, through those interviews, we mapped, to a degree, the as-is process. We didn't want to spend too much time worrying about the as-is, because we knew the whole reason Porex wanted PLM was to change that process.

So we focused more on the to-be process. Once we built this swim lane, we then combine this with the workflow map that we showed earlier and broke this down into, of all those workspaces we say we need, which bits of this process belong to which workspace? And what will the workflow for that workspace look like? So we took this swim lane and broke it down into a series of smaller swim lanes that we, then, used, when we were building the system, to build the workflow for each of those workspaces.

AVI ROBBINS: Absolutely. And really, defining the opportunities that come out of the to-be process, those are the opportunities. What are the business benefits we can get from implementing this process in a different way? And what we did was, in our case, identified eight different opportunities that were around our business processes. And ranked them, in terms of complexity for implementing. How hard will be to implement that in the PLM, versus the business value. What value are we are we going to get?

So obviously, the easiest and most valuable products should be right there in Phase 1. You should get those big wins. That doesn't mean that item two isn't really important, and we shouldn't include, also. But this really helps you define, what's the most important? And how can you break this huge plan that you have into manageable steps, into the little modules that we call it.

And using this tool, we can identify those priorities. And then put into a business objective road map. And this is really breaking up your implementation into phases and giving them business objectives. So in Phase 1, we want to improve our cross-functional collaboration. This is all about project management and NPI process.

In Phase 2, we're going to establish the product data foundation. This is integration to Vault, change control, document control. And beyond that, connected to the rest of our world, manufacturing, quality, all the rest of that data. And the simple process of taking those opportunities, linking them to phases, and linking them to opportunities, you can then identify which departments in your organization are going to be affected. What systems that you have are going to be affected. Are they can be improved? Are they can be integrated to? Are they going to be replaced?

And it seems like common sense, but if you take the time to do this, what you're doing, really, is saving yourself time, later. Because you're going to need to communicate this to your organization. You're going to need to tell the department, hey, look your tool is going to be obsoleted in the next six months. We need your input on how to design the new tool for you. So this is really your business roadmap to say, hey, here's the benefit of what we're doing. I need to come on board and help me define this, so that we can make your job easier.

And as we talked about before, identifying the core team. Putting it into a simple core team map is a great way to save time on knowing who to communicate to. So taking a look at your departments on the left, and your phases, up here, you can say, look, here's my subject matter experts. Here are the process experts. And here's the representation on the core team. So as Ian mentioned, we have a small core team, but a lot of people that are giving input to that core team.

And here we know, what are the business objectives that we just identify before? And how do they affect different people? So just taking the time to put together the simple map, although it might be in your head, if you're the project manager for your implementation, you need a way to communicate this to the team. You need a way to structure your road map and to communicate the benefits and who's going to be affected by each phase of the implementation.

And it's also a great way, when you get flooded with support questions, to push them back on the core team experts, the core team and the process experts, who already are very familiar with PLM and can, basically, help your distributed user base. Then it's really about showing the value, right?

So when you're going out there for change management, how can you make sure your users are adopting? Well, it's showing them the benefits. It may sound simple. And in some cases, you might be adding steps to the process, instead of taking them away, but there's some advantage to that.

Maybe we're, instead of just using Excel spreadsheet, we're asking people to take data off the spreadsheet and enter it into the system. Well, by having metadata in the system, we can easily search the information. So instead of creating, one big part of our processes is samples. We make a lot of samples to test a lot of different materials to see what the functions are going to be.

But in the course of the 50 years we've been in business, we made hundreds of thousands of different samples. Well, I can almost guarantee you, we've made each sample more than once. But we haven't been able to rely on the test data history, so that we don't have to reinvent the wheel.

So we're basically building a knowledge base. By entering the data in, natively, we can now search and create a knowledge base of information. So when we have an idea in the future, we can go back and search for, let me find a product that has an air flow of x, or a dimension of y. Find a sample we created. And at least we have a starting point. So that's really one of the benefits that we found.

It's also an opportunity to standardized and secure, early. So these are two of the more daunting things that we had to consider. And it's really a good time for you to consider developing new standards. What does that mean? Well, really, like I mentioned before, we're adopting a brand new part numbering system.

So we have four different manufacturing facilities. Each one of them has their own part numbering system. Well, how can we claim to be a global organization? How can our teams work together where I could have a part number in the US that conflicts with a part number in Germany? Right?

We really needed to standardize and commonize our part numbering system, which means a big change. So having the help from the top, we were able to implement a new part numbering system. But we have to start early. You've got to get people engaged in the beginning, understand their needs, understand what are the challenges they're going to face. And maybe we needed to put in more systems to help manage the new information.

Some people were using smart part numbers. So they relied on knowing what the series of numbers meant. But now, that information will be in PLM and available to them. So it's really about communicating the change. And how you can use a new tool to make it easier. But the main point here is, think about that ahead of time. If you're thinking about implementing it, think about what are the processes that you can standardize.

Another one, you can see in this example, is item types. All right. So we sell products in eaches, in thousands, in packs, in linear meters, linear feet, meter squared. Well, that's a headache for capacity planning, for manufacturing planning, for inventory. And it's almost impossible to do business reporting on all these different item types.

Well, we can't pick just one, but we can greatly reduce it. So taking the time, up front, to say, hey, look, global team, we're implementing a new system that will help us control our products. Let's standardize on the types of items that we're going to create. And now we can have a system to help control that. Where before, people to do whatever they wanted, we now have a system to help us control this new standard. And we did that for machine names. There's a whole host of opportunities to do this.

And another thing that can seem daunting is permissions. So if you think about it, you've got, on the left side, here, maybe 20 different workspaces. And along the top, here, 5, 10 different user groups. Well, when you multiply that out, there's a ton of different opportunities to create permissions.

Who should have access to what, in the system? And just by creating a simple Excel spreadsheet, you can really start to see the pattern of opportunities to create these permissions. So instead of creating one permission for each workspace and each group, we can now see a commonality. And see, oh, look, for projects, sales, product development both need to read and write access to this workspace. But they don't need to see this one. And they don't need to have write access to the other. So you can create one permission, now, instead of 10 different permissions.

And if you haven't implemented PLM 360, this might seem a little too deep in the trenches for you. But when you think about any kind of permissions that you're trying to create, you need to be able to control information and make sure the right people have access to the right information. And make sure that other people can edit what needs to be edited, or can view what needs to be viewed.

And really, if you think about it all once, it can be daunting. So really, just taking a step back, mapping it out like this, really helped us to implement it in a much quicker fashion. And last but not least, it's about the user base, right?